MySQL in-app backup does not include all databases

MySQL in-app backup only backs up localdb and does not backup other databases.
In my case I have a database named "matchdb" in addition to "localdb" in the MySQL in-app instance.

This database is not included in the backup, and manually adding the connection string to the backup fails with the error:
Update Backup Configuration
Failed to save backup configuration. Error Details: Error occurred while connecting to the database matchdb on server <IP_ADDRESS>:49245.

Expected:
A documented method for including additional MySQL databases in the backup configuration.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4754bcfc-204a-d398-6b86-e452cd0d44a1
Version Independent ID: 157885c4-2579-8f98-1e85-c3063a861207
Content: Back up an app - Azure App Service
Content Source: articles/app-service/manage-backup.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@dtaylorus Thank you for your feedback! We will review and update as appropriate.

@dtaylorus Thank you for your feedback! We will review and update as appropriate.

@dtaylorus The document calls out that manually adding the connection string will cause the backup to fail.
MySQL in-app DBs should automatically backup without any additional configuration. Where do you see that your additional databases were not backed up?

@dtaylorus The document calls out that manually adding the connection string will cause the backup to fail.
MySQL in-app DBs should automatically backup without any additional configuration. Where do you see that your additional databases were not backed up?

The backup file contents do not include the additional schemas in the in-app database. The backup file includes only the 'localdb' schema. It does not include the 'matchdb' schema as expected in my example above.
In a disaster recovery scenario, all my data in the in-app database would be lost since it's not in the backup file.
My expectation is that the backup process includes the entire in-app database, not just one of the schemas in the database.
Thanks!

The backup file contents do not include the additional schemas in the in-app database. The backup file includes only the 'localdb' schema. It does not include the 'matchdb' schema as expected in my example above.
In a disaster recovery scenario, all my data in the in-app database would be lost since it's not in the backup file.
My expectation is that the backup process includes the entire in-app database, not just one of the schemas in the database.
Thanks!


TimeZone: Layout in advanced filtering should be fixed up

Description
Looks like the timezone dropdown layout may need some tweaking.
See Screenshot below.
Version
Datagrid: v1.0.0-beta.3
Browser: Chrome 64
Screenshots

The second issue has been fixed. The hoist and containerType have been bound down to the timezone dropdown.

No longer reproducible, closing.


Create preset for leisure=bandstand

Fixes #5259

Hey @AndreasHae. Looks good, but you need to run npm run build before pushing any code, this command will build your project and also notify if there is any error. In your case after adding data/presets/presets/leisure/bandstand.json if you run npm run build it will update the following four files :
data/presets.yaml
data/presets/presets.json
data/taginfo.json
dist/locales/en.json
I would suggest you to build the code and push the changes again.
Thanks!!

Thanks @AndreasHae - I'm going to merge and change the building tag from the "tags" to its own field.
Talking about this part:
    "tags": {
        "leisure": "bandstand",
        "building": "roof"
    },

Everything in the tag list is required in order for the preset to be matched.  This means that the way the preset is currently set up, if a bandstand didn't have exactly building=roof it would not be recognized as a bandstand.  So I'm going to put the building tag into a field instead, just in case people tagged it as building=yes,building=gazebo,building=shelter,building=bandstand or some other thing.

The tag building is not is not needed here.


Can't get zeroconf info

Logger: custom_components.yandex_station.core.yandex_glagol
Source: custom_components/yandex_station/core/yandex_glagol.py:237
Integration: Yandex.Station ([documentation](https://github.com/AlexxIT/YandexStation), [issues](https://github.com/AlexxIT/YandexStation/issues))
First occurred: 03:08:15 (1 occurrences)
Last logged: 03:08:15

Can't get zeroconf info
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/zeroconf/_utils/asyncio.py", line 86, in run_coro_with_timeout
    return asyncio.run_coroutine_threadsafe(aw, loop).result(
  File "/usr/local/lib/python3.10/concurrent/futures/_base.py", line 460, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/yandex_station/core/yandex_glagol.py", line 237, in _zeroconf_handler
    info = zeroconf.get_service_info(service_type, name)
  File "/usr/local/lib/python3.10/site-packages/zeroconf/_core.py", line 540, in get_service_info
    if info.request(self, timeout, question_type):
  File "/usr/local/lib/python3.10/site-packages/zeroconf/_services/info.py", line 482, in request
    return bool(run_coro_with_timeout(self.async_request(zc, timeout, question_type), zc.loop, timeout))
  File "/usr/local/lib/python3.10/site-packages/zeroconf/_utils/asyncio.py", line 90, in run_coro_with_timeout
    raise EventLoopBlocked from ex
zeroconf._exceptions.EventLoopBlocked

https://github.com/AlexxIT/YandexStation/releases/tag/v3.12.0


Fix windows installation issues

This PR fixes the following errors:

an error that occurred when decompress was called before a zip file was closed
an error caused by chmod, which is not supported on Windows (Deno.chmod)

Note
Before e8ee08069bfd9b97ce482e478dfa8faaebff4655, the following error was logged in :messages
[denops] [ddc-tabnine] Installing TabNine cli version 4.4.139...

[denops] New-Object : Exception calling ".ctor" with "3" argument(s): "The process cannot access the file 'C:\Users\blyoa\AppDat
[denops] a\Local\xdg.cache\ddc-tabnine\binaries\4.4.139\x86_64-pc-windows-gnu\TabNine.zip' because it is being used by another
[denops] process."
[denops] At C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:93
[denops] 1 char:30
[denops] + ... ileStream = New-Object -TypeName System.IO.FileStream -ArgumentList $ ...
[denops] +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[denops]     + CategoryInfo          : InvalidOperation: (:) [New-Object], MethodInvocationException
[denops]     + FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
[denops]
[ddc] source: tabnine "gather()" failed

Thanks a lot! 🎉  🎉
I'm waiting someone to solve https://github.com/LumaKernel/ddc-tabnine/issues/4 .


:bouncing_ball_man: Day 19 Update

Thanks for holding me accountable :)

You've been awesome, keep going 💪


bump active support dependency and version number

This looks fine to me, but I think Tom has the keys?


[Bitmex] Order type property is misspelled in BitmexPrivateOrder class json annotation

This property is called "ordType" in the actual json response, not "orderType", therefore it is always null.
https://github.com/knowm/XChange/blob/599a3a9e1e1b934f2398fa9e7d58aa8e8f7568ab/xchange-bitmex/src/main/java/org/knowm/xchange/bitmex/dto/marketdata/BitmexPrivateOrder.java#L70
So the order type is lost when getting the orders via BitmexTradeServiceRaw.getBitmexOrders().
Also the getOpenOrders methods in BitmexTradeService have several issues, as they try to convert the order via BitmexAdapters::adaptOrder, which does not even check the type (so it will not notice that is always null), but assumes that it is always a limit order, and does not transfer other important properties used by other order types (e.g. stopPx for stops).
Just using the raw service and the original "raw" BitmexPrivateOrder object without adapting would work fine, were it not for the missing ordType, due to the misspell.

This was corrected


pkg/prometheus: watch configmaps having the prometheus-name selector

Currently, we are watching all configmaps amongst all configured tenant namespaces. This is very costly in certain deployment use cases where we have:
a) many namespace tenants
b) kubernetes controllers running in those namespace doing leader election using k8s intrinsics
Here, we can observe quite a high CPU usage of the prometheus operator of up to 15% CPU "idle" usage:

A profile revealed most CPU time spent in the reconciliation loop:
(pprof) top10 -cum
Showing nodes accounting for 0.03s, 0.32% of 9.33s total
Dropped 359 nodes (cum <= 0.05s)
Showing top 10 nodes out of 271
      flat  flat%   sum%        cum   cum%
         0     0%     0%      6.11s 65.49%  github.com/coreos/prometheus-operator/pkg/prometheus.(*Operator).processNextWorkItem
         0     0%     0%      6.11s 65.49%  github.com/coreos/prometheus-operator/pkg/prometheus.(*Operator).sync
         0     0%     0%      6.11s 65.49%  github.com/coreos/prometheus-operator/pkg/prometheus.(*Operator).worker
         0     0%     0%      3.81s 40.84%  github.com/coreos/prometheus-operator/pkg/prometheus.(*Operator).createOrUpdateConfigurationSecret

In the above scenario we have a lot of configmap updates, namely *-lock configmaps which are being used inside kubernetes to do leader election. In the environment under test (OpenShift), we have up to 3 configmap updates per second:

This fixes the above by watching for configmaps having the prometheus-name label selector only. CPU time is reduced to ~0,7% idle CPU usage:

/cc @brancz @metalmatze

lgtm :+1: thanks!


Update index.md

Changed @when references to after_wp_load.  I think the propensity for package creators will be to assume WP functionality.  If they copy and paste command parameters this will provide that default starting point.
Changed text under @when heading to indicate it supports all WP-CLI hooks.  Again, I think this is defensive wording for the devs that logically approach this from the plugin world.
Finally, added authors example array to the composer.json file near the end of the page.

👍


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/async-component-approvers
/assign knative-sandbox/async-component-approvers
Produced by: knative-sandbox/knobots/actions/update-deps

/lgtm
/approve


[FLINK-1911] [streaming] Streaming projection without types

Since the DataSet projection has been reworked to not require the .types(...) call the Streaming and Batch methods were out of sync.
So, the streaming API projection was modified accordingly.

Nice API feature. LGTM besides that one comment. Fixing that myself and running and running it through travis, because that was also blocked by the infamous test. :)


[Question] Any way to implement it together with dynamic table?

As the title says, I want to implement this whit an alrready done dynamic table in the same screen.

@martin-one can you please describe more about this feature?

@martin-one can you please describe more about this feature?

I'm wishing for this functionality as well. An example use case is a custom nib with a tableview, and having this library drive its logic without requiring that it be presented as a separate view controller. For example, a screen with a title, and a few toggle buttons in addition to a checklist of items.


Develop data pre-processing methods

The goal here is to develop the code to prepare the data for model development.  Existing methods have been prototyped before the start of the project and will form the basis of the methods.

[ ] Develop methods to standardize data
[ ] Develop methods to visualize the data
[ ] Convert exploratory code to Python script that can be deployed in backed of web app
[ ] Ensure documentation is sufficiently adequate for new users to quickly pickup and apply

How do we stand here? @yosoyjay

Generally, it looks good. The only point I think that could use a little work is some docs describing how the classes are expected to be organized.  Specifically, for the --classpath arg in preprocess_chunk_img.py.

Yeah. About that, I think we should mail Dan asking him the actual classification for all the possible pods I've mentioned in the Readme. I'll update as soon as we get the info.

Looking at this, I think if you just move the text from the main README to one specifically for the the preprocessing and this will be all wrapped up. @ZER-0-NE


get rid of logical compare

i think the logical not is only applied to the left hand side of this comparison, so this should be the same check

Merged. Thanks!


missing updated wiki?

I just downloaded mf2 alpha 2.4.5
Im looking for a updated wiki, or at least info about the BASICS.
If you are looking for a co-developer i can help you, i have experience with java but none with mc forge api. If you teach me the basics i can help you a lot with bugs, etc.
I really love this mod, i would like help you to improve it  :)

i saw many videos but neither of thus where about my version :S
I guess i need a hammer to craft bronze pickaxe but how? xD

there should be a book you start off with. that has information


 IF YOU DO NOT FOLLOW THE FORMAT OR MAKE A GENERIC TOKEN REQUEST YOUR ISSUE WILL BE DELETED WITHOUT COMMENT
YOUR JUSTLIST MUST FOLLOW THE JSON SPECIFICATION
#3346
https://github.com/justswaporg/justlists/blob/main/example.justlists.ts
Checklist

[ ] I understand that this is not the place to request a token listing.
[ ] I have tested that my JustList is compatible by pasting the URL into the add a list UI at justswap.org.
[ ] I understand that filing an issue or adding liquidity does not guarantee addition to the justlists website.

Please provide the following information for your token.
JustList URL must be HTTPS.
JustList URL:
JustList Name:
Link to the official homepage of the JustList manager:

Please submit the correct information, invalid information will cause the issue to close


Refactor attachment-related controllers

Motivations

Simplify the logic in the two attachment-related controllers to make it easier to understand.
Make the logic in the two attachment-related controllers more like that in the media controllers in Asset Manager.

Both of the above should make things clearer when we switch over to serving Whitehall attachments from Asset Manager.
Approach

Re-write both controller tests from scratch to make tests easier to understand, to improve coverage, to reduce duplication. In hindsight, I wish I'd done this more incrementally so that the diff(s) would be easier to follow.
Refactor both controllers to use multiple guard conditions instead of the more complex nested conditions.
Add tests to specify the order of the guard conditions (based on the original implementation) and fix the ordering of the guard conditions to pass the tests. In hindsight I wish I'd added these tests at the beginning of the PR, but doing so now would require a lot of fairly unnecessary re-work.

See commit notes for more details.

I'll review this now.


Next js Middleware and Nextjs 12.2

Changes

added middleware to redirect the user to /instances if isAuthenticated is falsy when accessing /instances/* or /profile/*
update nextjs to  v12.2 for middleware

Of the redirect, those pages should load the login if not authenticated. You can leave the middleware though.

Its still the same as before , when isAuthenticated is falsy it will render the login component


fix: crash due to evalMetaUpdate

Description
evalMetaUpdates was undefined, we tried using evalMetaUpdates.length.

It was noticed that when we have dataCloneError, in that case, workerResponse become
workerResponse = { errors: [{context: "someJSON", message:"error message"}]

Here,  evalMetaUpdates is undefined and hence the crash.
This PR fixes the crash issue but the root cause of the issue is yet to be fixed which is dataCloneError.
Fixes #14299
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Manually
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

/ok-to-test sha=e2c4cdd

/ok-to-test sha=89cf571

This is a critical bug . Adding testplan approved label. Testcase will be added latter. @Rishabh-Rathod @Aishwarya-U-R


Improvements to monetization document

Description:
Issue 1
The doc [1] provided the following instruction for configuring workflows

Most of the customers get this step wrong by adding a new subscription creation workflow executor without commenting the existing default workflow executors. Its better to add a note that the existing default workflow executors should be commented or deleted.
Issue 2
The link provided here(in orange letters) does not work.

[1] https://apim.docs.wso2.com/en/latest/learn/api-monetization/monetizing-an-api/
Suggested Assignees:
@Mariangela

Fixed in

https://github.com/wso2/docs-apim/pull/1377
3.1.0

https://github.com/wso2/docs-apim/pull/1376
master

https://github.com/wso2/docs-apim/pull/1378
3.0.0


Wired particle image by ParticleContainer

HI.
Thx for updating new PixiParticle .
particleContainerPerformance can see different screen between  particleContinaer  and normal Container.
it seems because of draw order...
particleContainer draw newPartcile under old Particle.
but Container draw newParticle upper old particle...
so i can see different screen;;
thx.

It looks like ParticleContainer ignores the blend mode of children and only uses its own blend mode - would this cause the effects you are seeing?


Overlay sometimes freezes; stays off/white background on refresh

Some users are reporting the viz could get stuck in a certain position after a while. Refreshing shows a white background, but the viz remains off.
Removing the web source on OBS and re-adding it seems to fix the problem.

This has been tracked down to a memory leak issue, caused by the way we poll the gamepad data.
Benchmark Results
Original gamepad (from resir014/stream-overlays)

Update: It seems that Chakra UI is causing the memory leak. I guess this project is a perfect way to stress-test public design systems...
What we did

Rewritten overlay section entirely in CSS Modules. Chakra UI is still retained for the overlay customiser.
Completely remove polling with useInterval. requestAnimationFrame() has already done the trick.

The fixes mentioned above is confirmed to be working! Closing now.


RedHat ubi container not updating

We are doing this
https://github.com/cockroachdb/cockroach-operator/blob/a65d8e9dcb100035010bbd8ec294529bb29837a7/Makefile#L239
Because the ubi image here:
https://github.com/cockroachdb/cockroach-operator/blob/a65d8e9dcb100035010bbd8ec294529bb29837a7/WORKSPACE#L99
Does not get pulled all of the time.  We need to investigate if we should have a Digest or what.
┆Issue is synchronized with this Jira Bug by Unito

Darn it, wrong repo


Does virtink support mount a PVC into some path in vm?

Sometimes, we want to mount a PVC into the VM to persistent some data. For example, we have a PVC called my-data and we want to mount it into /data path into vm. So does virtink support it?
To do this thing, I think there're two hands:

mount volume from host machine into VM (hostPath or local-path-provisioner)
mount volume from network (directly mount ceph rbd from network into VM)
So does virtink support one of the two method above?

yes, virtink already support PVC, 1) for Block PVC you can use it directly,  2) for filesystem PVC, need make sure a disk image file named asdisk.img  in PVC root path. a better way is use DataVolume, which will create disk.img for filesystem PVC root path automatically. this is an example VM with Datavolume.

But how to specify the volume's mount path in the VM? I've seen the docs about the DataVolume but it seems that I didn't find some examples about specifying the volume mount path

@weixiao-huang To mount a disk to a path inside a VM, you have several options:

Use the mount command to mount the disk manually inside the VM
If you want the mount to be persistent across reboots, you could add it to the /etc/fstab file
You could also use cloud-init to do the mounting when booting the VM, please refer to cloud-init doc for how to do that

All Virtink could do is provide a volume as a VM disk to the VM, but the mounting part should be taken care of inside the VM.

@weixiao-huang I'm closing this issue, feel free to reopen it if you want.


feat: Enable spawning workers dedicated to a specific queue

In a large application, it's possible for there to be a lot of queues, each of which with many items. In addition, some queues may have a lot of items, while others may only rarely have any items. These two factors can lead to starvation of the rarely used queues if they get blocked behind a large number of items in other more heavily used queues.
Add support for spawing workers that are dedicated to a specific queue. This way, users can specify dedicated workers for their heavily used queues, and the rarely used queues can continue using a shared set of workers.

Note: I have another commit stacked on top of this one for a related but separate feature: https://github.com/spencewenski/sidekiq-rs/commit/7e7749f268bf828bff2ec96719ece4d5cca9e38f
I'll post a PR for that once this PR is merged. Just a heads up in case you want to avoid creating separate releases for each PR.


Fixes the issue of not being able to stop scrolling by dragging the content again

Moves the PanGestureRecognizer used to drag the content along both axis to the outer Scrollable subclass.

This solves the issue of the inner Scrollable gestures being disabled while the outer Scrollable is scrolling
Enables the user to stop the scroll movement by dragging the content again

Fixes: https://github.com/flutter/flutter/issues/133529
Pre-launch Checklist

[ ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[ ] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[ ] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I signed the [CLA].
[x] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is [test-exempt].
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on [Discord].

@Piinks Thanks for taking a look.
For tests my first idea was to look into the CustomScrollView tests and replicate them for the two dimensional version.
However, it looks like there is no concrete subclass of TwoDimensionalScrollView in the Flutter package, so I'm not that route would work.
https://github.com/flutter/flutter/blob/e7058f568faf49458f83d479577f66c923bf8445/packages/flutter/lib/src/widgets/scrollable.dart#L1693-L1695
If you can give me some hints of how to go about testing this I would be happy to look into it.

For sure! There are some concrete classes just for testing, see the following for examples:

https://github.com/flutter/flutter/blob/master/packages/flutter/test/widgets/two_dimensional_utils.dart
https://github.com/flutter/flutter/blob/master/packages/flutter/test/widgets/two_dimensional_viewport_test.dart
https://github.com/flutter/flutter/blob/master/packages/flutter/test/widgets/two_dimensional_scroll_view_test.dart

@intonarumori @Piinks any movement on this? Such a critical feature/bug fix. Does this also allow to scroll again to keep momentum / accelerate like in a regular scrollview?
Thanks

almost there!

We have not heard back from @intonarumori on this, so I am going to close it and open a new PR so we can close this bug. Thanks for contributing!

@Piinks sounds good thanks. oh hey, nice video btw on this very feature :)

We have not heard back from @intonarumori on this, so I am going to close it and open a new PR so we can close this bug. Thanks for contributing!

@Piinks  Sorry for the late reply, I've been bogged down by work lately and didn't have the time to come back to this.
Many thanks for taking on this. Looking forward to learn from the new one and hopefully land something better formatted next time.


Added failure if using bad command line options

This add a check if the user accidentally used an invalid option on the command line.
There was a complaint and request in the godot devel chat about it.

I'm not sure if we should warn or error in this situation. Adding an error would break automated build scripts that happen to be passing unknown parameters, especially if the parameters are platform-specific (some people may still be passing them on all platforms).

This also uncovered an issue with the Mono variables, it was creating its own variable instance, so it was not part of the help text. Latest commit fixes that.

I'm not sure if we should print a warning or abort with an error in this situation. Adding an error would break automated build scripts that happen to be passing unknown parameters, especially if the parameters are platform-specific (some people may still be passing them on all platforms).

I respect whatever you want to do, but my personal opinion is that will just lead to confusion when things go wrong, and give allowance for processes to continue doing things incorrectly. Is it that hard for other systems to pass the right vars? Wouldn't they want to know if they are passing the wrong thing? Warnings are basically ineffective in automated systems, no one looks unless its red. Sure if you want to not break previous branches, the backport could be less strict.

mono has a compilation error now that the options are getting added to the main variables, I'll look into what went wrong and switch the hard fail to a warning with the message @Calinou suggested.

I'm of two minds on error vs warning, both have pros and cons. I do agree that if users pass an invalid option, an error is the best way to tell them about it so they can fix their script.
At the same time, it can be fairly easy to pass invalid options for a specific platform/build, because some options are platform or config-specific. For example someone might want to favor LLVM over GCC and pass use_llvm=yes as a generic option to all their builds - but only a subset of the platforms will actually use and honor this setting (others might simply give no choice and use LLVM anyway, e.g. Android, macOS, iOS).
Another potential option is that the removal of some options will lead to breakage of user scripts, e.g. if users were disabling the webm module with module_webm_enabled=no, and we ned up removing it from the tree, they will get errors on upgrade. In such cases, a warning may indeed be a nicer way to notify users that this option is no longer relevant - even if it might take some time for them to notice the warning.
Maybe the best would be a way to show the warnings both at the start and at the end of the build? Users are likely to miss a warning at the start if they issue the build command and then go sword-fighting while it compiles, but if the warnings are summarized at the end of build, they'll see them.

Maybe the best would be a way to show the warnings both at the start and at the end of the build? Users are likely to miss a warning at the start if they issue the build command and then go sword-fighting while it compiles, but if the warnings are summarized at the end of build, they'll see them.

What about some colors instead to make it more noticeable? I noticed godot already colorizes some output so I can leverage existing color code.

Okay I dug into the mono compilation failure, and when mono options go to Update the env, they wipe out the current 'platform' var. I saw in several place you reset this var after its been wiped out. Really you should use a different var for getting the command line value and recording the platform in the environment. This makes it so you can update the env after new options are discovered, and not wipe out the existing 'platform'. I did find and replace "platform" -> "selected_platform"

Partially superseded by #55203.


ibmcloud-cli: 2.17.0 -> 2.19.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.18.0 with grep in /nix/store/k9ajhjn9rwzkm1f5v79z88i6yafgklcn-ibmcloud-cli-2.18.0
found 2.18.0 in filename of file in /nix/store/k9ajhjn9rwzkm1f5v79z88i6yafgklcn-ibmcloud-cli-2.18.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/k9ajhjn9rwzkm1f5v79z88i6yafgklcn-ibmcloud-cli-2.18.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/14eacd5983b91edcbb3896d76cf7de86e947bd8a.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/k9ajhjn9rwzkm1f5v79z88i6yafgklcn-ibmcloud-cli-2.18.0
ls -la /nix/store/k9ajhjn9rwzkm1f5v79z88i6yafgklcn-ibmcloud-cli-2.18.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Hash mismatch 😕

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.19.1 with grep in /nix/store/6m0jmd6avj5lp6ys47v2brm76vnc9wv6-ibmcloud-cli-2.19.1
found 2.19.1 in filename of file in /nix/store/6m0jmd6avj5lp6ys47v2brm76vnc9wv6-ibmcloud-cli-2.19.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/6m0jmd6avj5lp6ys47v2brm76vnc9wv6-ibmcloud-cli-2.19.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/95f307de0d3c108842e715fe1eb28e7e15f82890.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/95f307de0d3c108842e715fe1eb28e7e15f82890#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/6m0jmd6avj5lp6ys47v2brm76vnc9wv6-ibmcloud-cli-2.19.1
ls -la /nix/store/6m0jmd6avj5lp6ys47v2brm76vnc9wv6-ibmcloud-cli-2.19.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.20.0 with grep in /nix/store/6kbyav4i8yp9hqm5293lnamxwmd3qxv3-ibmcloud-cli-2.20.0
found 2.20.0 in filename of file in /nix/store/6kbyav4i8yp9hqm5293lnamxwmd3qxv3-ibmcloud-cli-2.20.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/6kbyav4i8yp9hqm5293lnamxwmd3qxv3-ibmcloud-cli-2.20.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/af38ddf7c7a158b400fb2fcb38cde59e953d4510.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/af38ddf7c7a158b400fb2fcb38cde59e953d4510#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/6kbyav4i8yp9hqm5293lnamxwmd3qxv3-ibmcloud-cli-2.20.0
ls -la /nix/store/6kbyav4i8yp9hqm5293lnamxwmd3qxv3-ibmcloud-cli-2.20.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.21.0 with grep in /nix/store/vnry8a2w1xd273ivrzc4iplc9zlfwi1a-ibmcloud-cli-2.21.0
found 2.21.0 in filename of file in /nix/store/vnry8a2w1xd273ivrzc4iplc9zlfwi1a-ibmcloud-cli-2.21.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vnry8a2w1xd273ivrzc4iplc9zlfwi1a-ibmcloud-cli-2.21.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/efdbbcc856bba41da062b607b60dd382182a608d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/efdbbcc856bba41da062b607b60dd382182a608d#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vnry8a2w1xd273ivrzc4iplc9zlfwi1a-ibmcloud-cli-2.21.0
ls -la /nix/store/vnry8a2w1xd273ivrzc4iplc9zlfwi1a-ibmcloud-cli-2.21.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.22.1 with grep in /nix/store/lpdcdzdv5bxbgk2ig0l3qfdg6cllsawi-ibmcloud-cli-2.22.1
found 2.22.1 in filename of file in /nix/store/lpdcdzdv5bxbgk2ig0l3qfdg6cllsawi-ibmcloud-cli-2.22.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/lpdcdzdv5bxbgk2ig0l3qfdg6cllsawi-ibmcloud-cli-2.22.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/753528a810a06f49473584f10f96ba1735294b38.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/753528a810a06f49473584f10f96ba1735294b38#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/lpdcdzdv5bxbgk2ig0l3qfdg6cllsawi-ibmcloud-cli-2.22.1
ls -la /nix/store/lpdcdzdv5bxbgk2ig0l3qfdg6cllsawi-ibmcloud-cli-2.22.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.23.0 with grep in /nix/store/5bybw7m2srr0hqm4ngcbvm8yr8c0kg9i-ibmcloud-cli-2.23.0
found 2.23.0 in filename of file in /nix/store/5bybw7m2srr0hqm4ngcbvm8yr8c0kg9i-ibmcloud-cli-2.23.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/5bybw7m2srr0hqm4ngcbvm8yr8c0kg9i-ibmcloud-cli-2.23.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/d1932ade09d8176e5ddea57651af2da63dc34627.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/d1932ade09d8176e5ddea57651af2da63dc34627#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/5bybw7m2srr0hqm4ngcbvm8yr8c0kg9i-ibmcloud-cli-2.23.0
ls -la /nix/store/5bybw7m2srr0hqm4ngcbvm8yr8c0kg9i-ibmcloud-cli-2.23.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.24.0 with grep in /nix/store/80vganfs708claw495ndqpzvy40zq2wa-ibmcloud-cli-2.24.0
found 2.24.0 in filename of file in /nix/store/80vganfs708claw495ndqpzvy40zq2wa-ibmcloud-cli-2.24.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/80vganfs708claw495ndqpzvy40zq2wa-ibmcloud-cli-2.24.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/255edd59b823e1bc8463447c9e3342ee0b1aa481.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/255edd59b823e1bc8463447c9e3342ee0b1aa481#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/80vganfs708claw495ndqpzvy40zq2wa-ibmcloud-cli-2.24.0
ls -la /nix/store/80vganfs708claw495ndqpzvy40zq2wa-ibmcloud-cli-2.24.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.25.0 with grep in /nix/store/dkr07z4isd5ha91gb8f19a8shs7yyj9f-ibmcloud-cli-2.25.0
found 2.25.0 in filename of file in /nix/store/dkr07z4isd5ha91gb8f19a8shs7yyj9f-ibmcloud-cli-2.25.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dkr07z4isd5ha91gb8f19a8shs7yyj9f-ibmcloud-cli-2.25.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/61abe5ee223690595073b2a00196c949b9bfebee.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/61abe5ee223690595073b2a00196c949b9bfebee#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dkr07z4isd5ha91gb8f19a8shs7yyj9f-ibmcloud-cli-2.25.0
ls -la /nix/store/dkr07z4isd5ha91gb8f19a8shs7yyj9f-ibmcloud-cli-2.25.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.25.1 with grep in /nix/store/isilkm828njvpsay7qs2c37k3fzbsbsn-ibmcloud-cli-2.25.1
found 2.25.1 in filename of file in /nix/store/isilkm828njvpsay7qs2c37k3fzbsbsn-ibmcloud-cli-2.25.1

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/isilkm828njvpsay7qs2c37k3fzbsbsn-ibmcloud-cli-2.25.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/c34ff37ef6c1b085b34c5c137c478e9b204f50a2.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/c34ff37ef6c1b085b34c5c137c478e9b204f50a2#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/isilkm828njvpsay7qs2c37k3fzbsbsn-ibmcloud-cli-2.25.1
ls -la /nix/store/isilkm828njvpsay7qs2c37k3fzbsbsn-ibmcloud-cli-2.25.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/ibmcloud-cli/versions.
meta.description for ibmcloud-cli is: Command line client for IBM Cloud
meta.homepage for ibmcloud-cli is: https://cloud.ibm.com/docs/cli
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.26.1 with grep in /nix/store/ysddcy5d3b1d1ycf2chvwa24kiw1l1im-ibmcloud-cli-2.26.1
found 2.26.1 in filename of file in /nix/store/ysddcy5d3b1d1ycf2chvwa24kiw1l1im-ibmcloud-cli-2.26.1

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

ibmcloud-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ysddcy5d3b1d1ycf2chvwa24kiw1l1im-ibmcloud-cli-2.26.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibmcloud-cli https://github.com/r-ryantm/nixpkgs/archive/16b7a531cf32a15bf71ef23cba91e31880458a16.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/16b7a531cf32a15bf71ef23cba91e31880458a16#ibmcloud-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ysddcy5d3b1d1ycf2chvwa24kiw1l1im-ibmcloud-cli-2.26.1
ls -la /nix/store/ysddcy5d3b1d1ycf2chvwa24kiw1l1im-ibmcloud-cli-2.26.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

ibmcloud-cli

Maintainer pings
cc @emilytrau for testing.

Already on master.


DEVOPS-834 Cardano faucet package

Description
Beginnings of a faucet for the cardano testnet. This isn't ready yet, but asking for a code review and some help with how the API works.
Linked issue
DEVOPS-834
Type of change

[ ] 🐞 Bug fix (non-breaking change which fixes an issue)
[x] 🛠 New feature (non-breaking change which adds functionality)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
[ ] 🔨 New or improved tests for existing code
[ ] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

[ ] I have read the style guide document, and my code follows the code style of this project.
[ ] If my code deals with exceptions, it follows the guidelines.
[ ] I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.

Testing checklist

[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@rvl these would be easier to address if they were inline :-)

Split up the withdraw function.

I've split out the queue handling parts 59a71c7bb

Can we have at least one token test case?

I'm sure there are some parts that can be sensibly tested now

Needs a little documentation.

There are haddocks on all the main functions and swagger docs (under /docs). What form would you like the documentation in? Do you mean a better README?

Remove _dead code and commented out code

I've removed all the commented code I could find, could you review inline anymore you see and anything you think is dead? 7cabdb9c7

Remove nix files and .projectile.

Done a0158671a

Remove index.html

This is kinda handy to have around for testing purposes... Now that recaptcha is enabled you can't really test with curl or a rest client

Copyright IOHK

Done - found the remaining instance in LICENSE 3d945c61c

There is a missing letter in Withdrawl

Urban dictionary informs me that "withdrawl" is
> What a Southerner suffers when he moves to the North

which isn't quite what I intended. Fixed in 1c2ae37cc

Made a start on a test suite in 67cd2dfeb

Thanks. Can readCaptchaSecret read just the first line of the file and not include the newline characters?

existing-wallet-details.json -- does this file need to be present?

Good catch - removed

Cardano.Faucet.Endpoints.withdraw function

(optional) split out captcha verification handling into a separate function.

Didn't really see any benefit of moving the catcha handling somewhere else, so I've left it.

the use of whenJust with prisms seems obtuse. why not just a pattern matching function?
Cardano.Faucet.Init

Agreed, switched to pattern match.

why is this module called Init? Cardano.Faucet.Init.createWallet

Because it only exports one function which initializes the FaucetEnv

Cardano.Faucet.Init.processWithdrawals
LambdaCase could make it shorter

By one line, didn't really seem worth it..

Can be split up into little functions with descriptive names.

Again - not sure I see the benefit here. processWithdrawals is only 25 lines or so, 8 of which is logging?

the code which posts the transaction should be factored out from the code which gets a payment off the queue and puts the result.

Don't really see the point - it's just another place to jump to in the code if you need to understand what's going on..?
Cardano.Faucet.Metrics
decrWithDrawn isn't used -- can be removed.
Cardano.Faucet.Types.API
Yup, removed.

instance FromJSON WithdrawalRequest -- can it be made to handle a missing "g-recaptcha-response" by providing the empty string as a default value.

I'm not sure I understand the logic here. I could change the recaptcha response to a Maybe I suppose and allow that in the case that the secret isn't set in the config?

DepositRequest/Result -- if it's not currently used then remove it. The same goes for any other dead code.

Removed.

formatting library can be used with logging to avoid having show and pack everywhere.

True - doesn't really seem worth the effort to change now though TBH. Happy to if you want though.

There are some modules with -Wall added. Is it possible to enable that for all modules or too inconvenient?

I've enabled -Wall in the cabal file

Ported faucet branch from develop to release/1.3.0.
Previous version of faucet which is based off develop is on the devops-834-faucet-develop branch.


relocation R_X86_64_32S out of range

When I build a Kernel Os with some crates ,it happend.
Then I tried to give RUSTFLAGS and rebuilded those crates, also failed.
But when I used .cargo/config.toml ,set build-std and env RUSTFLAGS then it did well
Is cargo-xbuild question or have another resolution I don`t find?

We don't pass RUSTFLAGS when building core and the other sysroot crates because we need to set our own RUSTFLAGS. If your project works with cargo's build-std feature, I recommend using that instead of cargo-xbuild.


Simplify some code  in Eureka with java 8 features

Hi, @OLPMO This looks good but could be added to Greenwich release train as well. Can you submit this against the 2.1.x branch?

Do you mean i could synchronize these changes in 2.1.x branch? @OlgaMaciaszek

@OlgaMaciaszek I have synced my changes to the branch 2.1.x .If I misunderstood what you mean,please tell me immediately, I would revert this commit.

Sorry for not getting back to you earlier @OLPMO What I mean is instead of doing this PR against the master branch do the PR to merge your branch to 2.1.x, like this these changes will get included in Greenwich release train as well. We merge 2.1.x to master each time anyway.

It doesn't matter. @OlgaMaciaszek

@OLPMO  It was a good PR, it should just be added to Greenwich release train instead. It's very simple to resubmit the PR against a different branch if there are no conflicts.


Keyword arguments

Hello!
Do you have plans to supports keyword arguments?

Hi, I haven't planned anything keyword arguments. It requires too much effort for now. I think it is better to focus on quick wins like basic modules. What do you think?

Hi, I haven't planned anything keyword arguments. It requires too much effort for now. I think it is better to focus on quick wins like basic modules. What do you think?

I made this implementation for Tengo[1], but still the result of the benchmark was not satisfactory. If you can take a look and tell me what you think it would be interesting. If you consider it pertinent, I can make a Fork and implement this solution here.
[1] https://github.com/d5/tengo/pull/371

Closing this for now. However, I may change the Call method signature or add a new interface not to break backward compatibility in the near future for some improvements. We can discuss this at that time.


feat: Add pending reorg resistance in contracts

Please read contributing guidelines and remove this line.

#7926  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @LHerskind and the rest of your teammates on  Graphite

Benchmark results
Metrics with a significant change:

protocol_circuit_simulation_time_in_ms (private-kernel-tail-to-public): 2,219 (-18%)
protocol_circuit_witness_generation_time_in_ms (public-kernel-tail): 30,843 (+19%)
protocol_circuit_proving_time_in_ms (root-parity): 31,580 (+16%)
protocol_circuit_proving_time_in_ms (base-rollup): 97,010 (+16%)
protocol_circuit_proving_time_in_ms (public-kernel-app-logic): 9,994 (+16%)
protocol_circuit_proving_time_in_ms (public-kernel-tail): 106,946 (+16%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,772
1,561
697
752
768

proof_construction_time_sha256_30_ms
11,894
3,172
1,412
1,444
1,480 (+1%)

proof_construction_time_sha256_100_ms
44,221
12,506 (+1%)
5,690
5,571 (-2%)
5,542 (+1%)

proof_construction_time_poseidon_hash_ms
79.0
34.0
34.0
58.0 (-2%)
88.0

proof_construction_time_poseidon_hash_30_ms
1,535
420
201
234 (+4%)
267 (-4%)

proof_construction_time_poseidon_hash_100_ms
5,692
1,552 (+1%)
677
726 (-1%)
760 (+1%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
4,324
7,844
14,852

l1_rollup_calldata_gas
49,744
92,464
177,680

l1_rollup_execution_gas
1,383,193 (+7%)
2,130,881 (+4%)
3,958,136 (+2%)

l2_block_processing_time_in_ms
262 (+1%)
456
811

l2_block_building_time_in_ms
9,657 (-1%)
18,959
37,597

l2_block_rollup_simulation_time_in_ms
9,657 (-1%)
18,959
37,596

l2_block_public_tx_process_time_in_ms
8,045 (-1%)
17,106
35,689

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
3,001 (+4%)
3,999 (+2%)

node_database_size_in_bytes
12,742,736
16,867,408

pxe_database_size_in_bytes
16,254
26,813

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Function
time_ms
bytecode_size_in_bytes

FeeJuice:_increase_public_balance
95.4 (+1%)
8,139

FeeJuice:set_portal
9.71 (-1%)
2,362

Token:constructor
120 (-5%)
31,107

FPC:constructor
93.7 (-10%)
22,380

FeeJuice:mint_public
78.6 (-5%)
6,150

Token:mint_public
93.3 (-2%)
11,720

Token:assert_minter_and_mint
79.0 (-12%)
8,028

AuthRegistry:set_authorized
8.05 (-1%)
4,537

FPC:prepare_fee
291 (+2%)
8,812

Token:transfer_public
36.7 (+18%)
47,374

FPC:pay_refund
63.9 (+5%)
12,114

Benchmarking:increment_balance
1,027
7,450

Token:_increase_public_balance
10.8 (-6%)
8,960

FPC:pay_refund_with_shielded_rebate
139 (+1%)
12,663

Public DB Access
Time to access various public DBs.

Function
time_ms

get-nullifier-index
0.166 (+5%)

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves

batch_insert_into_append_only_tree_16_depth_ms
2.17 (-1%)
3.93
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.7
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.111 (-2%)
0.111
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
11.6 (+1%)
18.3 (+2%)
32.2 (+4%)
61.6
114 (+1%)

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
287
543
1,055

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.111 (+2%)
0.106 (+3%)
0.104 (+4%)
0.105
0.103 (+1%)

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
14.4 (-1%)
25.7
43.9 (-1%)
84.8
164 (+1%)

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
109
207
355
691
1,363

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.109 (-2%)
0.103
0.101 (-5%)
0.105
0.104 (+1%)

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
16.6 (+1%)
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
132
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
0.106
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
64,756
668,997

Transaction size based on fee payment method
| Metric |  |
| - |  |

@LHerskind #7860 is now in, thanks!!


fix jsonschema maximum tip for issue #1854

What this PR does / why we need it?
fix jsonschema maximum tip for issue #1854
Summary of your change
Please indicate you've done the following:

[ ] Made sure tests are passing and test coverage is added if needed.
[ ] Made sure commit message follow the rule of Conventional Commits specification.
[ ] Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

Codecov Report
Patch coverage: 77.77% and project coverage change: +0.21% :tada:

Comparison is base (6902bfa) 73.25% compared to head (7f8bbad) 73.46%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #1883      +/-   ##
============================================
+ Coverage     73.25%   73.46%   +0.21%
+ Complexity    21526    21469      -57
============================================
  Files           646      634      -12
  Lines         87407    86905     -502
  Branches      19088    19006      -82
============================================
- Hits          64026    63841     -185
+ Misses        15466    15176     -290
+ Partials       7915     7888      -27

Files Changed
Coverage Δ

...ava/com/alibaba/fastjson2/schema/NumberSchema.java
67.60% <60.00%> (+0.70%)
:arrow_up:

...va/com/alibaba/fastjson2/schema/IntegerSchema.java
75.91% <100.00%> (+7.29%)
:arrow_up:

... and 23 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Query parse misbehaving, leading ? is not ignored

Using "query-string": "^4.3.4"
queryString.parse('?intended=sign-in) returns
{
  "?intended": "sign-in"
}

We have a test proving it works: https://github.com/sindresorhus/query-string/blob/27e4fae3e79d179bcf79c32cf3bb404770ac0491/test/parse.js#L5

Sorry, I just checked the code:
Turns out I was actually importing from 'queryString' and it seems it was a valid module within my project so there were no importing errors.
I changed it to 'query-string' and now it works


Cannot startx with kernel 4.2.0-30

Kernel 4.2.0-30
Ubuntu 15.10
Latest patches

After upgrading from 4.2.0-27 to 4.2.0-30 I am unable to startx. Everything freezes - although telling the now 'frozen' VM to 'shutdown' from the menu works.
Anyone else seeing this?

Yes. Creating a new VM, upgrading to that kernel and then installing open-vm-tools seems to be Ok.
Any ideas on how to rescue the 'frozen' VM?


Layout doesn't consider node paddings.

Here is example without paddings - http://jsbin.com/qodotekale/1/edit?html,output , it works as expected.
And here is example with node paddings - http://jsbin.com/qowekuvofa/1/edit?html,output , as you can see nodes are overlaping.
Also for the reference, with simple cose layout nodes are not overlapping, see http://jsbin.com/tejufolire/1/edit?output

@aindlq see paddingCompound option. I think this is what you asked for.


test: test_test::test_file_is_newer_than_and_older_than_itself and test_test::test_newer_file fail when no birth date available

I'm not sure if the failures are related, so I'm posting both errors here. The above tests fail on my linux machine with
---- test_test::test_file_is_newer_than_and_older_than_itself stdout ----
current_directory_resolved:
run: /home/lenny/workspace/external/uutils/uutils/target/debug/coreutils test regular_file -nt regular_file
current_directory_resolved:
run: /home/lenny/workspace/external/uutils/uutils/target/debug/coreutils test regular_file -ot regular_file
thread 'test_test::test_file_is_newer_than_and_older_than_itself' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :
 Some(
<    101,
>    1,
 )

', tests/common/util.rs:199:9

---- test_test::test_newer_file stdout ----
current_directory_resolved:
touch: /tmp/.tmpHeDbat/regular_file
touch: /tmp/.tmpHeDbat/newer_file
run: /home/lenny/workspace/external/uutils/uutils/target/debug/coreutils test newer_file -nt regular_file
run: /home/lenny/workspace/external/uutils/uutils/target/debug/coreutils test newer_file -ot regular_file
thread 'test_test::test_newer_file' panicked at 'Command was expected to succeed.
stdout =
 stderr = thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Uncategorized, message: "creation time is not available for the filesystem" }', src/uu/test/src/test.rs:292:38
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
', tests/common/util.rs:177:9

I wanna note, that my /tmp directory is a mounted tmpfs file system where the creation time is indeed not available. However, I ran both tests manually with gnu's test without producing a 101 exit code or an error message, so I guessed we shouldn't either.

both these tests passed on my box right now. the second might even be a duplicate of #4329 (see https://github.com/uutils/coreutils/issues/4329#issuecomment-2183270776 ) and so is solved.
Who might close this? @cakebaker ?

Same on my machine, so closing this issue.
@kralo thanks for the hint!


🐛 owners set at the domain level in cadet are being associated with source db tables

Describe the bug.
After ingesting the source databases and tables (nomis etc) we have an unintended consequence of how we've implemented owners in cadet.
Because they are set at the domain level in dbt_project.yml and the source tables generated by code are saved within the domain folder structure the owners which was meant for derived tables is also being assigned to source tables.
We'll need to think off an approach that overrides the owner set at the domain level e.g. prison for source models/tables
To Reproduce
No response
Expected Behaviour
No response
Additional context
No response

owners have been removed from each env for source systems and an update to the cadet dbt_project file has been made.
Can move this to done once ingestions have run on 18/10 and we can be confident the source table owners have been removed


[Save-Package-Properties.ps1] Add -RequireNewSdk

Closing. This is addressed in https://github.com/Azure/azure-sdk-tools/pull/6544


Create With_hash module within External_transition modules

In the transition_frontier code, we commonly use the type  (( External_transition.XXX.t, State_hash.t ) With_hash.t). On top of that, we now compose the type with Envelope.Incoming.t and Cached.t. It makes the type unnecessarily verbose and hard to read.
It would be useful to have a module for the type ( External_transition.XXX.t, State_hash.t ) With_hash.t within the External_transition.XXX. We can this module With_hash. As a result, the typed is aliased as External_transition.XXX.With_hash.t. With_hash should have all the getter functions that External_transition.XXX has. Also, there should be a function for getting the hash of the external transition. Additionally, there should be a function that transforms External_transition.XXX to External_transition.With_hash.XXX.
I suspect that the transition_frontier code would significantly be slimmer as a result of this refactor. We repeatedly, make the function calls With_hash.data and we would not have to do that after this refactoring.

Closing this issue as it is stale for a long time.


transformer support soft decoding/encoding

Based on the description, it seems that transformer doesn't support soft decoding. However, we have a business requirement for this. Are there any ready-made solutions available?

MediaCodec supports both hardware and software encoders/decoders, thus Transformer also supports both options.
If you need to only use software encoders, you need to implement EncoderSelector and pass it to the DefaultEncoderFactoryBuilder.
For decoders, you need to implement MediaCodecSelector and pass it to the DefaultDecoderFactory.Builder

I use transformer for video format conversion, but on some mobile phones, the error shown in the image appears. If possible, could you please guide me on how to handle this compatibility issue? My initial thought was that switching to a software decoder/encoder should solve similar problems. @droid-girl

For decoder, you can try to use setEnableDecoderFallback() method.
For encoder, a similar method here


Update pr-reviews.yml to run on pull request target

This will allow for secrets to be used to run the script needed to check for the necessary PR reviews across forks.
Additionally, each time a commit is pushed or auto-merge is enabled, the script will run.

Can you further explain the secrets aspect? My current assumption is that the change will ensure this action to check for appropriate approvals will now run (via synchronize) on every commit and (via auto_merge_enabled) when auto merge is enabled. Is that right?

@mikeCRL In order to query the GitHub GraphQL API, we need to pass in a token into the Go script. This makes sure that we're authenticated and have the privileges to view docs-prs group members and PR reviewers. pull_request_target will run this action in each PR on the base branch (master) instead of the HEAD branch (whatever code is running in the PR). GitHub blocks secrets from running in the HEAD branch for security reasons, and my code needs secrets to function correctly.
Your assumption about synchronize and auto_merge_enabled is correct, but separate from the secrets aspect.

Ah, I missed the significance of pull_request_target until now, and I appreciate all the context. SGTM/LGTM! Thanks.


Remove structlog dev optional dependency in setup.py

Based on this issue, the optional dependency on structlog dev has been removed from the setup.py file.
https://github.com/closeio/socketshark/issues/160
Thank you.

Are there any plans to release a new version with this improvement?
Thank you again.

Released!


block_tree: refactor tree update methods out of fileData

In a future PR, dirData will start using these methods.
Also, a few other cleanups:

Separate the indirect pointer methods of blocks out into their own interface, so we don't have to implement them in CommonBlock and test block types.
Have dirData and fileData use the fields of blockTree for most of their internal fields, to simplify things and avoid unnecessary overhead.

Issue: KBFS-3301

Once again:

interfaces.go
block_types.go
dir_data.go and test (just a refactor)
file_data.go and test (just a refactor)


Checkpoint file on S3?

Hi Christian,
I found this project is super interesting. I was wondering if it is possible to share the checkpoint files [bestmodel.ckpt] on s3 or ftp?
The dvc file in the checkpoint directory does not work for external users.
Thanks for consideration.
Z.

Hm, I since switched workplaces. But let me investigate if there is something that changed.

Hm, I since switched workplaces. But let me investigate if it can be shared somehow.

Thank you so much! Look forward to hearing back from you.
Alternatively, it will be also great if you can share the pre-processed images that external users can retrain the model? As you described in another issue thread, it requires kakadu SDK for processing the large jp2 images, so it's not convenience and not free.


Unsupported primitives FD, FDR, FDS (Xilinx)

I am new with Yosys and after read #448, I found an ERROR. Maybe was discussed in the past (I found nothing related). If not and if desired to solve, I want to help. Please, point me in what to do :P and ask for extra information if needed.
Steps to reproduce the issue
In this repo I added a file (hdl/primitives.v) and Yosys scripts to run with Spartan 6 and Series 7 (examples/s6micro/primitives.ys and examples/zybo/primitives.ys).
Expected behavior
Finish the synthesis without an ERROR or at least using a BlackBox cell model if unsupported?
Actual behavior
It fails with the following ERROR:
2.3.1. Analyzing design hierarchy..
Top module:  \primitives
ERROR: Module `\FD' referenced in module `\primitives' in cell `\inst3' is not part of the design.

If you comment instantiations, it also fails with FDS and FDR.
Extra information
I was playing with Xilinx examples provided in the UG687 (XST User Guide for V6, S6 and Series 7 devices). There some examples used these primitives and failed with Yosys. These works with ISE (xst):
=========================================================================
*                            Design Summary                             *
=========================================================================

Top Level Output File Name         : primitives.ngc

Primitive and Black Box Usage:
------------------------------
# FlipFlops/Latches                : 3
#      FD                          : 1
#      FDR                         : 1
#      FDS                         : 1
# Clock Buffers                    : 1
#      BUFGP                       : 1
# IO Buffers                       : 7
#      IBUF                        : 4
#      OBUF                        : 3

Device utilization summary:
---------------------------

Selected Device : 6slx4tqg144-3

Slice Logic Utilization:

Slice Logic Distribution:
 Number of LUT Flip Flop pairs used:      0
   Number with an unused Flip Flop:       0  out of      0
   Number with an unused LUT:             0  out of      0
   Number of fully used LUT-FF pairs:     0  out of      0
   Number of unique control sets:         2

IO Utilization:
 Number of IOs:                           8
 Number of bonded IOBs:                   8  out of    102     7%
    IOB Flip Flops/Latches:               3

Specific Feature Utilization:
 Number of BUFG/BUFGCTRLs:                1  out of     16     6%

These primitives are described in UG616 (Spartan-6 Libraries Guide for
Schematic Designs) instead of UG615 (which I understand that are the supported). I know, the title says For Schematic but obviously they can also be used with HDL and could be more Xilinx code using it over there :P

That is correct — we only support the HDL primitive library at the moment.  In general, trying to use yosys for synthesis and then bypassing the synthesis (ie. the whole point of yosys) by using schematic entry primitives doesn't sound like a common use case.
The primitives that are in the schematic entry library but not the HDL library are not really primitives — they're either macros that expand to multiple primitives (like the counter "primitives") or dumbed down versions of other primitives (eg. FDR is a dumbed down FDRE — the CE input is hardwired to 1).  IMO the correct way to support them in yosys would be to make a Verilog file implementing them in terms of the actual primitives (or just as open-coded processes etc and let them go through synthesis), and make synth_xilinx auto-include that file into the user design.

In general, trying to use yosys for synthesis and then bypassing the synthesis (ie. the whole point of yosys) by using schematic entry primitives doesn't sound like a common use case.
Yes, I agree, the issue was thinking in legacy code from Xilinx, because several times they use primitives for FFs in their code.

I don't know, what do you think? Does it have sense to support them? (make a Verilog implementation which uses the actual primitive and the inclusion in synth_xilinx seems easy to implement) or a waste of time? The issue can be closed if no sense (but maybe could be added a legend somewhere in the main README about the support of only HDL primitives or something similar :P).
Thanks for your time.

I don't know, what do you think? Does it have sense to support them? (make a Verilog implementation which uses the actual primitive and the inclusion in synth_xilinx seems easy to implement) or a waste of time? The issue can be closed if no sense (but maybe could be added a legend somewhere in the main README about the support of only HDL primitives or something similar :P).

It would be nice to support them, but it's a rather low-priority task — if you want to do the work, go ahead.

It looks like a good exercise to get started.
I will try to implement at least these three at the beginning :-D

@rodrigomelo9 - FYI The SymbiFlow project has a tool at https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/libraries which is suppose to extract the various "definitions" that Xilinx parts support on the 7 series from the 7 Series Libraries Guide PDF document. It would be nice to have a similar thing for Spartan 6 too...

I see, how interesting ... Haha :-P
I will take a look ;-)
PS: is a little confusing to me to catch where Yosys finish and Symbiflow begins XD so, work in these things could be helpful.

Yosys is an independent entity to SymbiFlow owned by Clifford + Symbiotic EDA team.
The "SymbiFlow Project" is a user of the Yosys project. SymbiFlow generates a bunch of configuration information and scripts that can be used with Yosys for doing a fully open source, end-to-end Verilog to Bitstream for a number of commercial FPGAs like the Xilinx 7 series.
I guess you could kind of think of it like the difference between the Linux Kernel and a Linux distro (like Debian). The Linux Kernel is an essential part of making Debian work but also an independent entity used for many other things. Debian takes the Linux Kernel plus things like a C library, init daemon and all the rest to create a complete system for getting work done.
The thing that can make it a little confusing is the FPGA world is a little smaller than the Linux world so there is a much higher overlap between contributors for all these parts :-). Hopefully we will be successful enough in the future to have more specialists!