fix: Add the token's rootcert public key to the list of known keys

Borrowed two functions from docker/libtrust to generate the key ID from the certificate bundle in the same fashion as v2.8.3.

Addresses: distribution/distribution#4470

Trusted keys should be read from jwks', keyed by their KeyID assuming your jwks files have been correctly generated I'm a bit puzzled why this breaks 🤔

That part works, in our setup we did not have the jwks key defined (as with 2.8.3) and that caused the registry not trust any key, even the certificate one.

Thanks for the PR! FWIW, we actually want to avoid any of the libtrust cruft seeping back to this codebase, unless the code references some standard/specification.

I've seen that the ruby implementation of JWT uses just the plain SHA256 hexdigest as kid by default. But also an RFC mentioned, RFC7638.

b887712 is an to add unit tests to the changes. I felt it was reaching a bit too much but gave it a try nevertheless. Let me know if it's too bad and I'll drop that commit.

Took the liberty to implement the JWT hashing mechanism that RFC7638 defines to use it as KeyID instead of the old docker/libtrust impl.
It should satisfy:

the code references some standard/specification.

or at least get closer :sweat_smile:

that caused the registry not trust any key, even the certificate one.

this is what puzzles me...as I said there was a regression that should have been fixed by https://github.com/distribution/distribution/pull/4415 which should have made the cert validation kick in before the KeyID check kicks in 🤔 this is what I'm trying to understand - why is this still broken

Maybe is worth noticing that our token server does not include the x5c header in the JWT Token

Maybe is worth noticing that our token server does not include the x5c header in the JWT Token

Hah! Yeah, that'll do it...

Hah! Yeah, that'll do it...

:sweat_smile: I knew I missed something

Should I write something up in this PR? Or a new one?

I think it can go into this PR, but mind you I haven't had time to look at this PR yet

Ok, let's do two PR's to keep it lightly then. I'll wait for your feedback on this one :)

if the token server is providing JWTs with a kid, then it should also be providing a JWKS url that can be used to lookup the keys

Does distribution supports this discovery mechanism? I could swear only the JSON file path is allowed :thinking:

Does distribution supports this discovery mechanism? I could swear only the JSON file path is allowed 🤔

Correct, it doesn't. It would be nice though, because we could technically then implement key rotation, alas...

With regards to documenting:
in docs/content/spec/auth/token.md there are no pointers to docs/content/spec/auth/jwt.md maybe is worth linking them from item 4 on the list in token.md

The authorization service returns an opaque Bearer token representing the client's authorized access.

What do y'all think?
And in jwt.md I'm thinking on reflecting the x5c header in Getting a Bearer Token > Headers and within Verifying the token list
Stating that the "Signing Key verification" happens first and it goes a little something like:

Ensure that the certificate chain provided is valid. If it fails (due to the x5c header missing):
Ensure that the provided JWK in the JWT is valid.
Ensure that the provided  KeyID is known (as per the configured jwks.json in auth.token.jwks config)
Fail with Invalid Token

Maybe a mermaid flow diagram could illustrate better the logic?

How about ASCII art? (Anything just not to deal with package.json "fun")

Yeah, ASCII diagram would work. I think we have some already scattered around the docs.

Small question, in jwt.md this sentence does not match the implementation in go-jose/go-jose@v4

The "typ" field will be "JWT"

typ is exposed in the jose.Header struct under the ExtraHeaders map but not used in distribution anywhere.
Additionally, RFC7515 Section 4.1.9 defines typ
although it does not mention "JWT" as a value.
It does mention typ = JOSE to signal that there's a JWS contained. Would it be worth to align this value to the RFC?
OOOOR, on the other hand, maybe is mean to be cty = JWT instead?
https://github.com/go-jose/go-jose/blob/v4.0.4/jwt/jwt.go#L189
p.s.: looks like I didn't need ASCII art after all :sweat_smile:

It does mention typ = JOSE to signal that there's a JWS contained. Would it be worth to align this value to the RFC?

I think so, that's an interesting catch

OOOOR, on the other hand, maybe is mean to be cty = JWT instead?
https://github.com/go-jose/go-jose/blob/v4.0.4/jwt/jwt.go#L189

Not sure about that...cty seems to be suggesting content type whilst typ is a media type (which usually starts with application/... so something like application/jwt see https://www.iana.org/assignments/media-types/media-types.xhtml)

aha! found the reference
https://datatracker.ietf.org/doc/html/rfc7519#section-5.1
5.1.  "typ" (Type) Header Parameter

   The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used
   by JWT applications to declare the media type [IANA.MediaTypes] of
   this complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be present in an application
   data structure that can contain a JWT object; the application can use
   this value to disambiguate among the different kinds of objects that
   might be present.  It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.  While
   media type names are not case sensitive, it is RECOMMENDED that "JWT" # <<<--- ding ding ding ding
   always be spelled using uppercase characters for compatibility with
   legacy implementations.  Use of this Header Parameter is OPTIONAL.

There's one piece I don't know well where to put, the Certificate Thumbprint as the Default KeyID of the Certificate configured in auth.token.rootcertbundle.
There are no references of that key in the JWT/Token docs, but it is referenced in docs/content/about/configuration.md.
Any suggestions where that piece would be better written? :thinking:

I would put it into the configuration page and cross-reference it in the token auth 🤷♂

@josegomezr can you please squash and sign your commit?

A pleasure to contribute :) until the next ~bug~ feature 🐞 🚀


[Autopilot] approval for rule kube-system/pool-rebalance-e24c4dbe-4f80-48db-8a1d-17ae2e459fcc rule: pool-rebalance

This is a request to approve an autopilot action. The request was triggered based on an AutopilotRule pool-rebalance defined in your cluster.
What actions will be taken
Action: rebalance
ExpectedResult
Job summary:
-> Provisioned space balanced         0 B done, 60 GiB pending
Rebalance actions:
Replica add action
Volume:<PHONE_NUMBER>08891779
Pool: 4a8ec973-219b-48da-b0a1-b3f45e843789
Node: 6eec1f0a-2679-41a7-a541-bc5f9dec52d9
Replication set ID: 0
Work summary:
-> Provisioned space balanced         0 B done, 30 GiB pending
-> Volume replicas balanced           0 done, 1 pending
Replica remove action
Volume:<PHONE_NUMBER>08891779
Pool: e24c4dbe-4f80-48db-8a1d-17ae2e459fcc
Node: 366acf86-96ec-499c-913d-f5455b1860a9
Replication set ID: 0
Work summary:
-> Provisioned space balanced         0 B done, 30 GiB pending
-> Volume replicas balanced           0 done, 1 pending
Replica add action
Volume:<PHONE_NUMBER>14795156
Pool: 44fbba64-4b10-4fa4-974b-b6dcf491ed11
Node: a53dbf82-faca-40a2-a7bc-3f1c397f1516
Replication set ID: 0
Work summary:
-> Provisioned space balanced         0 B done, 30 GiB pending
-> Volume replicas balanced           0 done, 1 pending
Replica remove action
Volume:<PHONE_NUMBER>14795156
Pool: e24c4dbe-4f80-48db-8a1d-17ae2e459fcc
Node: 366acf86-96ec-499c-913d-f5455b1860a9
Replication set ID: 0
Work summary:
-> Provisioned space balanced         0 B done, 30 GiB pending
-> Volume replicas balanced           0 done, 1 pending
What objects will get affected

StoragePool kube-system/4a8ec973-219b-48da-b0a1-b3f45e843789 (4a8ec973-219b-48da-b0a1-b3f45e843789)

Object Owner(s):

portworx cluster: harsh-pks-demo-38

StoragePool kube-system/e24c4dbe-4f80-48db-8a1d-17ae2e459fcc (e24c4dbe-4f80-48db-8a1d-17ae2e459fcc)

Object Owner(s):

portworx cluster: harsh-pks-demo-38

StoragePool kube-system/44fbba64-4b10-4fa4-974b-b6dcf491ed11 (44fbba64-4b10-4fa4-974b-b6dcf491ed11)

Object Owner(s):

portworx cluster: harsh-pks-demo-38

How do I approve
Once you review the above,

To approve, simply approve and merge this PR
To declined, close the PR

Autopilot will be watching for the merged specs in the cluster and will proceed with the action if approved and declined the action if not.

[Autopilot] Closing PR as the approval kube-system/pool-rebalance-e24c4dbe-4f80-48db-8a1d-17ae2e459fcc was cancelled. The cancellation could be due to one of below reasons:

The approval state was change by a user in the spec to cancelled.
The rule conditions for the object: e24c4dbe-4f80-48db-8a1d-17ae2e459fcc are no longer met in the cluster..


feat: Add template feature

Closes #
📑 Description

✅ Checks

[x] My pull request adheres to the code style of this project
[x] My code requires changes to the documentation
[x] I have updated the documentation as required
[x] All the tests have passed

ℹ Additional Information

Codecov Report
Patch coverage: 52.45% and project coverage change: -3.32% :warning:

Comparison is base (63d411c) 77.07% compared to head (89e8668) 73.76%.

:exclamation: Current head 89e8668 differs from pull request most recent head ad9c5ca. Consider uploading reports for the commit ad9c5ca to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
- Coverage   77.07%   73.76%   -3.32%
==========================================
  Files           9       11       +2
  Lines         711      827     +116
==========================================
+ Hits          548      610      +62
- Misses        133      181      +48
- Partials       30       36       +6

Files Changed
Coverage Δ

response.go
73.13% <0.00%> (-2.26%)
:arrow_down:

service_provider.go
0.00% <0.00%> (ø)

view.go
45.00% <45.00%> (ø)

template.go
57.14% <57.14%> (ø)

route.go
89.18% <85.00%> (-1.14%)
:arrow_down:

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


ngVideo Angular2

Can we use this plugin in angular2  ?

Not yet, but it's in the pipeline.

What is you recommendations for best video playing method in angular2 ?
On Thu, Mar 24, 2016 at 4:04 PM, Adam Timberlake<EMAIL_ADDRESS>wrote:

Not yet, but it's in the pipeline.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/Wildhoney/ngVideo/issues/44#issuecomment-200822465


Adding space age exercise

Nice, I'm loving all the Fortran content!

One sec - these failures are from my suggested changes. Let me take a swing at fixing these

I think both failures are due to implicit typing rules (e.g. any character in ijklmn would have an implicit type of integer)

I think both failures are due to implicit typing rules (e.g. any variable beginning with a character in ijklmn will have an implicit type of integer according to fortran compiler rules)

NEVER use Fortran implicit variables - they are EVIL. :-)
With implicit none this is avoided. The problem was the private vs public in the included module orbital_constants

I think both failures are due to implicit typing rules (e.g. any variable beginning with a character in ijklmn will have an implicit type of integer according to fortran compiler rules)

NEVER use Fortran implicit variables - they are EVIL. :-)
With implicit none this is avoided. The problem was the private vs public in the included module orbital_constants

This makes sense - I thought the privacy rules were file-specific. Probably I had that mixed up with some other language, but good to learn, thanks!


Archetype generated Java topology misses class import

Archetyp misses an import for
import org.apache.stormcrawler.ConfigurableTopology;

resulting in a compiliation error.

I just sent a mail to dev@ asking if we really want to keep these Java-based topology classes in the archetypes. Since it has been broken for a long time and no one has really complained, it is a clear sign that no one is actually using it.


Update regex of CC query param and header policies

$subject

Query params may contain URL encoded values
rewrite path could be "/foo/bar/hello/world"

using the same synapse policy, since it will support {uri.var.petID} format with the PR https://github.com/wso2/product-apim/pull/12670


[webview_flutter] PlatformException on firsttime install

Steps to Reproduce

Define WebView normally
Setup push notification by FCM
Uninstall app and reinstall again

Logs
PlatformException(create_failed, can't create a view on a headless engine, null)

flutter analyze
No issues found! (ran in 3.1s)

[✓] Flutter (Channel stable, v1.7.8+hotfix.4, on Mac OS X 10.14.6 18G87, locale en-US)
    • Flutter version 1.7.8+hotfix.4 at /Users/apple/Development/flutter
    • Framework revision 20e59316b8 (7 weeks ago), 2019-07-18 20:04:33 -0700
    • Engine revision fee001c93f
    • Dart version 2.4.0

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/apple/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Users/apple/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.3, Build version 10G8
    • CocoaPods version 1.7.5

[✓] iOS tools - develop for iOS devices
    • ios-deploy 1.9.4

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 38.2.3
    • Dart plugin version 191.8423
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] IntelliJ IDEA Ultimate Edition (version 2019.1.3)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin version 37.0.3
    • Dart plugin version 191.7830

[✓] Connected device (3 available)
    • Android SDK built for x86 • emulator-5554                            • android-x86 • Android 9 (API 28) (emulator)
    • com.apple.CoreSimulator.SimRuntime.iOS-12-4 (simulator)

• No issues found!

Any solution to this ?

i think most of the time this error will happen if it has to render the NativeView while the phone is asking some permission, and this is particularly happen only on IOS

this happens when the app is requesting for any permission in ios, and the flutter NativeView try to render itself. so as long as the permission dialog hanging there, i think it's considered to be "headless".
i think, what you can do to fix this is basically wait until the permission request is finished, and then try to render / call the build NativeView (whatever it is, could be WebView or GoogleMap). For what i know, ios permission request will only prompt only when the service is called (start motion activity update / get current location from GPS / Notification received)
although this case is relatively hard to reproduce, and considered to be rare occasion (need to have ios permission request script [calling the GPS location / Notification received thus will prompt notification permission request / start motion activity update], and render the NativeView at the same time)

Hi @thanhhuan1990,
Can you please confirm if you still experience this issue on latest Flutter version (eg : dev) and with latest webview_flutter plugin ?

hi @darshankawar ,
I'm so sorry, since my project are released few months ago without WebView because this issue. So I cannot reproduce it now.
So if another members do not face this issue, please close it.
thank for you support.

Since @thanhhuan1990 is unable to replicate this issue. I feel safe to close this ticket.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.
Thank you.


WIP: Hybrid 4.1.10 release

Hi @jogboms . I see that this PR has 2 portions: updates to the Hybrid App Base, and a new document. I'll take the Hybrid App Base changes out of this PR and commit them now myself. Then I will get to the new document portion of this PR later.
If this comes up again, could you please send 2 separate PRs so I can process the quick one easily? Thank you for contributing to the documentation Jeremiah.

I have published the 2 bullets for the Jan 3 release notes. When @smarki returns, he and I can discuss the forthcoming update and its document (which pertain to local bundled resources). I want to make sure this new update and doc are necessary, and not too narrow in use.

Thanks @ConnorLand
I also just repurposed the PR as this now points to v4.1.10 and would be released soon

Is is okay i create a new PR and close this?

Is it okay to create a new PR and close this?

Sure @jogboms . I can close this one.

Closing this so a newer, cleaner one can be submitted.


Constructor injection simpler

Looks like it's already working this way.
It's angular-like, with less code.
Is it ok ?

I'll try to write a test for this.

Whatever, it already exits.


Named actor registration

The current actor registration API only registers UUIDs. We want to be able to designate human-readable aliases for actor references.
Internally, the dispatcher (who receives actor registration notifications) should deduplicate identical aliases. This can be done by simply appending an integer to the alias, e.g. my-alias, my-alias-1, and so on.

API should return a future of an ActorPath with the new alias.
I think it should also allow to prevent the deduplication and return a failure in the future instead, so that people aren't confused why remote paths don't work as expected.

Do you prefer the kompics-defined kompics::utill::Future over futures::Future? v0.1.2 of the futures crate comes with a Futures::wait(...) function for blocking the current thread and awaiting the response.

Yes, use the Kompics Future until the other one stabilises.

We can do that.
But generally we need two different APIs for this.

A future-based one that you can use from the system scope.
A message-based one that we can use from within components (since we can't block those on futures)


xdai bridge

Shows failed, but actually succeed

@zhangzhongnan928 can't reproduce this on my device, also I think this would be an iOS issue


Source code for Neo4jMapper.Core

What is the repo of Neo4jMapper.Core?

https://github.com/barnardos-au/Neo4jMapper/tree/master/src/Neo4jMapper.Core
https://github.com/barnardos-au/Neo4jMapper/tree/master/src/Neo4jMapper
The code for Neo4jMapper & Neo4jMapper.Core is the same. The only difference is the dependencies. Due to issues with differences in NETfx & Net Core APIs the two projects use different ServiceStack.Text packages

See https://docs.servicestack.net/netcore#run-aspnet-core-apps-on-the-net-framework for more info


References not working, keep on loading...

VSCode Version: Code 1.18.1 (929bacba01ef658b873545e26034d1a8067445e9, 2017-11-16T18:32:36.023Z)
OS Version: Windows_NT x64 6.1.7601
Extensions:

Extension
Author (truncated)
Version

vscode-markdownlint
Dav
0.11.1

tslint
eg2
1.0.23

task-master
ian
0.1.39

vscode-nuget-package-manager
jmr
1.1.5

csharp
ms-
1.13.1

team
ms-
1.122.0

debugger-for-chrome
msj
3.5.0

java
red
0.14.0

vscode-gulp
tan
0.0.4

Steps to Reproduce:

Reproduces without extensions: Yes/No

From IEnumerable, I suspect this is C#. Please file this in the appropriate extension repository. https://github.com/OmniSharp/omnisharp-vscode


Rationalize PublishEvent* APIs

Allow passing options such as Content-Type and Metadata in a flexible and future-proof way.
The method PublishEventfromCustomContent is now deprecated and shows a warning in the console when used.
This PR maintains backwards compatibility.
See #174 for context and discussion
Fixes #174
Fixes #164

@yaron2 Here's the PR. If you are ok with how this works, I can update the docs too.
I haven't updated the tests because... without some proper integration testing, there's not much to test anyways, as this just sets some values in a struct that a testing function wouldn't be able to check. However I can look into adding some mock methods to be able to test that the code sets the values as expected.

@yaron2 Here's the PR. If you are ok with how this works, I can update the docs too.
I haven't updated the tests because... without some proper integration testing, there's not much to test anyways, as this just sets some values in a struct that a testing function wouldn't be able to check. However I can look into adding some mock methods to be able to test that the code sets the values as expected.

Thanks, I will review this week.

@skyao also take a look please

ping @ItalyPaleAle

@yaron2 thanks for confirming the changes you wanted. I've made the last change @pkedy requested and I think this should be good to merge

@yaron2 thanks for confirming the changes you wanted. I've made the last change @pkedy requested and I think this should be good to merge

Will come back to this soon.

Hi is there any update on this PR?

@beiwei30 can you please review this PR?

Any updates on this? We're eagerly waiting the arrival of metadata support in pubsub.

Tests are failing but looks like it's an issue with the CI?

I made a force-push but the CI continues to fail because of issues that seem to be related to the CI - something failed to download?

@ItalyPaleAle like network issue, maybe force push again to re-trigger.

@daixiang0 just tried again (second time) and it still fails with some CI issues.

In fact there is an issue you may miss:
run golangci-lint
  Running [/home/runner/golangci-lint-1.31.0-linux-amd64/golangci-lint run --out-format=github-actions] in [] ...
  Error: deprecatedComment: use `Deprecated: ` (note the casing) instead of `DEPRECATED: ` (gocritic)

@daixiang0 thanks for catching that. I've fixed it locally but the CI continues to fail with some issues that seem infrastructure-related, and I am not sure how to address those. A maintainer would need to help please!

@daixiang0 CI finally seems to work. Good to merge?

@daixiang0 CI finally seems to work. Good to merge?

Can we get this merged? It enables a lot of things missing in go-sdk


HB-7778: Prebid keywords

Pass mediation keywords to amazon load and publisher prebid requests

Holding off on merging this. Will do on monorepo directly once ready.


#bug; Stargate Base Error

https://okgraph.xyz/?q=messari%2Fstargate-base
A non-deterministic fatal error occured at block 2165487: failed to process trigger: block #2165487 (0x1076…29a7), transaction 38a90e8ec521d7214b1f656e5a4ddf0a4c9da7355ca6abfa71cb4b262ec52f20: module instantiation failed: attempted to divide BigDecimal `86400` by zero wasm backtrace: 0: 0x4c89 - <unknown>!~lib/@graphprotocol/graph-ts/common/numbers/BigDecimal#div 1: 0x4fb6 - <unknown>!start:src/mappings/handlers 2: 0x1660f - <unknown>!~start

No backfill because no price feed for base yet


flatpak: 1.14.2 -> 1.14.4

Description of changes
this release fixes two CVEs (CVE-2023-28101 and CVE-2023-28100), as well as bringing in bug fixes from 1.14.3.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Builds nicely for me, tests have the same number of test failures as in the previous build  so lgtm.
SUMMARY: total=50; passed=38; skipped=0; failed=12; user=870.2s; system=593.6s; maxrss=447804
FAIL: flatpak/test-run@system-norevokefs,nodeltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-run@user,deltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-seccomp.sh.test (Child process exited with code 1)
FAIL: flatpak/test-run@system-norevokefs,deltas.wrap.test (Child process exited with code 1)
FAIL<EMAIL_ADDRESS>(Child process exited with code 1)
FAIL: flatpak/test-run@system,nodeltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-run@user,nodeltas.wrap.test (Child process exited with code 1)
FAIL<EMAIL_ADDRESS>(Child process exited with code 1)
FAIL: flatpak/test-history.sh.test (Child process exited with code 1)
FAIL<EMAIL_ADDRESS>(Child process exited with code 1)
FAIL: flatpak/test-run@system,deltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-prune.sh.test (Child process exited with code 1)

likewise (this sadly took 3 hours)
SUMMARY: total=50; passed=38; skipped=0; failed=12; user=3372.2s; system=3963.6s; maxrss=439628
FAIL: flatpak/test-prune.sh.test (Child process exited with code 1)
FAIL: flatpak/test-run@system-norevokefs,deltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-run@system,deltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-history.sh.test (Child process exited with code 1)
FAIL: flatpak/test-run@user,deltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-seccomp.sh.test (Child process exited with code 1)
FAIL: flatpak/test-run@system-norevokefs,nodeltas.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-run@user,nodeltas.wrap.test (Child process exited with code 1)
FAIL<EMAIL_ADDRESS>(Child process exited with code 1)
FAIL<EMAIL_ADDRESS>(Child process exited with code 1)
FAIL<EMAIL_ADDRESS>(Child process exited with code 1)
FAIL: flatpak/test-run@system,nodeltas.wrap.test (Child process exited with code 1)

Result of nixpkgs-review pr 225487 run on x86_64-linux 1

31 packages built:

flatpak
flatpak-builder
flatpak-builder.doc
flatpak-builder.installedTests
flatpak-builder.man
flatpak.dev
flatpak.devdoc
flatpak.doc
flatpak.installedTests
flatpak.man
gnome-builder
gnome-builder.devdoc
gnome.gnome-software
libsForQt5.discover (plasma5Packages.discover)
libsForQt5.flatpak-kcm (plasma5Packages.flatpak-kcm)
malcontent-ui
malcontent-ui.dev
malcontent-ui.lib
pantheon.appcenter
pantheon.elementary-greeter
pantheon.elementary-onboarding
pantheon.sideload
pantheon.switchboard-plug-applications
pantheon.switchboard-with-plugs
pantheon.wingpanel-applications-menu
pantheon.wingpanel-with-indicators
vala-language-server
xdg-desktop-portal
xdg-desktop-portal-gnome
xdg-desktop-portal-gtk
xdg-desktop-portal.installedTests

Thanks.

Result of nixpkgs-review pr 225487 run on x86_64-linux 1

31 packages built:

flatpak
flatpak-builder
flatpak-builder.doc
flatpak-builder.installedTests
flatpak-builder.man
flatpak.dev
flatpak.devdoc
flatpak.doc
flatpak.installedTests
flatpak.man
gnome-builder
gnome-builder.devdoc
gnome.gnome-software
libsForQt5.discover (plasma5Packages.discover)
libsForQt5.flatpak-kcm (plasma5Packages.flatpak-kcm)
malcontent-ui
malcontent-ui.dev
malcontent-ui.lib
pantheon.appcenter
pantheon.elementary-greeter
pantheon.elementary-onboarding
pantheon.sideload
pantheon.switchboard-plug-applications
pantheon.switchboard-with-plugs
pantheon.wingpanel-applications-menu
pantheon.wingpanel-with-indicators
vala-language-server
xdg-desktop-portal
xdg-desktop-portal-gnome
xdg-desktop-portal-gtk
xdg-desktop-portal.installedTests


not work --debug flag.

builder code:

path = "C:/Users/pc/Desktop/project/fautom"

# Find the location of the ruby2d gem
ruby2d_gem_path = `gem which ruby2d`.chomp

# If the gem location is not found, specify the path manually
if ruby2d_gem_path.empty?
  ruby2d_gem_path = "C:/path/to/ruby2d/gem"  # Replace with the actual path
end

# Use the full path to the ruby2d gem in the Ocra command
system("ocran #{path}/src/main.rbw --debug --gem-full #{ruby2d_gem_path} --no-dep-run")

# Move the compiled executable to the build directory
system("mv #{path}/src/main.exe #{path}/build/fautom.exe")

Error by ocran:

C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:84:in `+': no implicit conversion of nil into String (TypeError)

      @path = sub(/(\.[^.]*?|)$/) { s.to_s + $1 }
                                             ^^
        from C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:84:in `block in append_to_filename!'
        from C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:88:in `sub'
        from C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:88:in `sub'
        from C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:84:in `append_to_filename!'
        from C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:921:in `build_exe'
        from C:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/ocran-1.3.15/bin/ocran:1307:in `block in <top (required)>'

maybe, i'm stupid ://

Thanks for reporting bugs. This bug will be resolved in the next release.
https://github.com/Largo/ocran/commit/07895c759837f5592c9afbaf56f4c19a7539d1f0

@SetScript 1.3.16 was released so please try again and if it still happens reopen this ticket. thanks!


Incompatibility between Parceler and Error Prone

Hi,
I run into a bug yesterday using NullAway library and my project. I as not able to make ErrorProne and Parceler work together.
It looks like the bug comes from Error Prone, not NullAway.
The original issue, and links to repositories to test, can be found here : https://github.com/uber/NullAway/issues/72
Thank you.

Hello, sorry this didn't get a response when it was reported.
If you're still seeing this with the latest versions of Error Prone and the gradle plugin?

Hello, sorry this didn't get a response when it was reported.
If you're still seeing this with the latest versions of Error Prone and the gradle plugin?


mapbox-upload-validate errors

Seeing in master tests that used to pass but fail after restarting an old job:
mapbox-upload-validate -->

waiting...

not ok 141 is valid

  ---

    operator: ok

    expected: true

    actual:   false

    at: fail (/Users/travis/build/mapbox/mapnik-swoop/node_modules/mapbox-upload-validate/index.js:9:48)

  ...

not ok 142 no message

  ---

    operator: notOk

    expected: false

    actual:   'Tileset does not exist'

    at: fail (/Users/travis/build/mapbox/mapnik-swoop/node_modules/mapbox-upload-validate/index.js:9:48)

  ...

# lib.invalid

waiting...

/Users/travis/build/mapbox/mapnik-swoop/node_modules/mapbox-upload-validate/test/shell.script.test.js:45

        if (err) throw err;

        ^

Error: Command failed: Tileset does not exist

    at ChildProcess.exithandler (child_process.js:658:15)

    at ChildProcess.emit (events.js:98:17)

    at maybeClose (child_process.js:766:16)

    at Process.ChildProcess._handle.onexit (child_process.js:833:5)

Retarted a previously passing job at mapbox-upload-validate (https://travis-ci.org/mapbox/mapbox-upload-validate/jobs/109697960#L569) and it is also failing now. Seems something changed upstream in the test fixtures.

-> https://github.com/mapbox/mapbox-upload-validate/issues/55


Add CI for automated Testing

To further improve code quality and to make development and reviewing pullrequests easier, we will implement an automated testing pipeline with Travis

this is done in pullrequest #52


Error upon build in function clock_gettime()

Environment: macOS 13.1, g++ 12.2.0
Commands:
sh build-mini.sh
./build/4ku-mini

Error message:
<stdin>: In function 'int64_t a()':
<stdin>:11:82: error: invalid conversion from 'int' to 'clockid_t' [-fpermissive]
In file included from /opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/ctime:42,
                 from <stdin>:5:
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/time.h:178:29: note:   initializing argument 1 of 'int clock_gettime(clockid_t, timespec*)'
  178 | int clock_gettime(clockid_t __clock_id, struct timespec *__tp);
      |                   ~~~~~~~~~~^~~~~~~~~~
./build/4ku-mini: line 5: /var/folders/5m/v_lfr66s1mg7l9qhv3mjfkfc0000gn/T/tmp.4DH2RQex: Undefined error: 0

Cause of error occurs in src/main-mini.cpp, line 11:
using namespace std;int b=1<<15;int c=1<<16;int64_t a(){timespec d;clock_gettime(6,&d);return d.tv_sec*1000+d.tv_nsec/1000000;}

In turn this is caused by main.cpp line 52:
clock_gettime(CLOCK_MONOTONIC, &t);

I'll try to avoid this with alternate timing code that won't add bytes, but I don't have high hopes.
Thanks for opening an issue.


Update test_remove_all which was failing after #1036

It started to fail after #1036. This refactors the test a bit, mainly to get the current config dir before setting the DCOS_DIR env variable.

run linux integration tests

run linux integration tests


Issue while exec'ing rkt

I am trying to execute rkt using os/exec. I build my argument list and call exec.Command.CombinedOutput on it. Here is how rkt is being called
/usr/bin/rkt run --volume=etcd,kind=host,source=/tmp/3bab9c0c-0500-1d47-4f7d-b70c8b525362/etcd --mount volume=etcd,target=/tmp/3bab9c0c-0500-1d47-4f7d-b70c8b525362/alloc coreos.com/etcd:v2.0.4 --insecure-options=all --set-env=ONE=/tmp/3bab9c0c-0500-1d47-4f7d-b70c8b525362/etcd/local --set-env=TWO=256 --set-env=THREE=512 --set-env=FOUR=/tmp/3bab9c0c-0500-1d47-4f7d-b70c8b525362/alloc --exec=/etcd --memory=268435456M --cpu=512m

This fails with
invalid value in --volume flag "etcd,kind=host,source=/tmp/3bab9c0c-0500-1d47-4f7d-b70c8b525362/etcd --mount volume=etcd,target=/tmp/3bab9c0c-0500-1d47-4f7d-b70c8b525362/alloc"

When I remove the = sign after volume, it doesn't even recognize the flag
unknown flag: --volume etcd,kind

What am I doing wrong?

@alban helped me with this on irc. The problem was that I was combining --volume and --mount in a single fmt.Sprintf. It worked fine when I used two calls to format the strings.


Type Arguments Error

Steps to Reproduce Issue
Publish the sui_programmatically example of defi/pool And in the CLI, trying to call the create_pool_ method.
The following command is my command; the object might disappear after the next devnet upgrade. Better to replace with your own objects.
sui client call --package 0xe1f9565ef0d24e8194908d8f60acd56a754794e3 --module pool --function create_pool_ --gas-budget 10000 --args 0xba4706ac29a46be29dd4692569fa4aaf1c013e4a 0xc7e9cf1186a2fa3a4c648a3c471f646a1743d78a 0x90708284b86931979d41630462f7851a6b0a874e 1 --type-args 0x2::sui::SUI 0xb98017deb22d367d4de66418fa2a4c16cb8259ba::erc20::ERC20

Expected Result
The pool is successfully created.
Actual Result
RPC call failed: ErrorObject { code: ServerError(-32000), message: "ExecutionError: ExecutionError { inner: ExecutionErrorInner { kind: EntryArgumentError(EntryArgumentError { argument_idx: 0, kind: TypeMismatch }), source: Some(\"Expected argument of type T0, but found type 0x2::coin::Coin<0x2::sui::SUI>\") } }", data: None }

System Information

OS: macOS 12.5
Compiler: rustc 1.62.1 (e092d0b6b 2022-07-16)

The ERC20 is a minimal implementation of the custom token, a variation from the official examples.

Hey @bitweed, do you mind sharing the code for the ERC20 coin? Is it a Coin still?

It looks like the list of arguments passed to the entry function does not include the witness argument. I am not sure if it's even possible to pass a witness from CLI at this point (@damirka, @patrickkuo)?

Ah! Now I see what's the problem! We can't pass a witness in an entry point. Sorry for that. I should redesign pool to either create a custom LP coin which will target a pool or keep as is just remove entry.


Improvement: On README.md add link to project documentation page and FAQ

to here https://github.com/LEL-A/doc/blob/main/README.md

https://github.com/LEL-A/GerAlpacaDataCleaned/discussions/categories/q-a


Reland  "Disable cursor opacity animation on macOS, make iOS cursor animation discrete (#104335)"

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.
[ ] I signed the CLA.
[ ] 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.

No relevant failures on test TGP run. Ready for review.


Fix #blank? and #present? behavior for SingleAssociations

Add SingleAssociation.empty? method so that ActiveSupport #blank? and #present? work as expected for SingleAssociations.

Coverage decreased (-0.03%) to 95.548% when pulling a96ed90a991f24c0688000e951852806634fe0f0 on bayesimpact:master into c2796d67b89295bfe18d3178808cfc9b02316407 on Dynamoid:master.

Awesome.  Have time to add a spec?

Sure, I had to include activesupport as a dev dependency to properly test the behavior, but I just added some specs.

Coverage increased (+1.3%) to 96.874% when pulling 7a7d922eec2d9a1516ec80e41ad19d12a4563f14 on bayesimpact:master into c2796d67b89295bfe18d3178808cfc9b02316407 on Dynamoid:master.

Coverage increased (+1.3%) to 96.874% when pulling 7a7d922eec2d9a1516ec80e41ad19d12a4563f14 on bayesimpact:master into c2796d67b89295bfe18d3178808cfc9b02316407 on Dynamoid:master.

Coverage increased (+1.3%) to 96.874% when pulling 7a7d922eec2d9a1516ec80e41ad19d12a4563f14 on bayesimpact:master into c2796d67b89295bfe18d3178808cfc9b02316407 on Dynamoid:master.

Looks good thanks!


Image: Fix decompressing ETC2

Thanks to @Rriik for finding the bug and its cause.
Fixes #25595.

I tested it again in the 3.1 stable release and the error still persists. The original issue should be reopened.

Cherry-picked for 3.0.7.


Trying to upgrade Digitjal Ocean Droplet from beta.15 to beta.18 gives ENOTEMPTY error

Describe the bug
I am using the Digital Ocean droplet version of Saltcorn. When i installed this a couple of weeks ago I was able to upgrade the oldish version in the droplet to beta.15 with no problem. However, now I am trying to upgrade from beta.15 to beta.17 or beta.18 and I get:-
Starting upgrade, please wait...
npm ERR! code ENOTEMPTY
npm ERR! syscall rename
npm ERR! path /home/saltcorn/.local/lib/node_modules/@saltcorn/cli
npm ERR! dest<EMAIL_ADDRESS>npm ERR! errno -39
npm ERR! ENOTEMPTY: directory not empty, rename '/home/saltcorn/.local/lib/node_modules/@saltcorn/cli' -><EMAIL_ADDRESS>npm ERR! A complete log of this run can be found in:
npm ERR!     /home/saltcorn/.npm/_logs/2024-10-11T09_42_08_559Z-debug-0.log
Upgrade done (if it was available) with code 217.
Press the BACK button in your browser, then RELOAD the page.
When i go back and refresh I am still on beta.15
I noted an item in the wiki with this very error but that seemed to be related to an old node version so I am unsure if I should take that same action (which I think was to delete the node_modules folder and resinstall) on the droplet.
To Reproduce
As above
Expected behavior
Should upgrade to beta.18

Hi, I think you can just delete the folder, even with a newer node version.
But we've added another way to do this, too. When you click the 'choose version' button you should see a dialog where you can select the newest version, and a checkbox to remove the old node_modules directory. Can you try to upgrade with the checkbox clicked

Actually I did try that earlier on today and it appeared to totaly corrupt saltcorn on my droplet which I could not recover. Had some very strange looking stuff in the saltcorn directory - longish strings which looked like they might be corrupted scripts. Fortunately I had a fairly recent backup so I recreated my droplet from the saltcorn droplet image (which  is around 0.9....) and then did an upgrade (the only option available) and that ran smoothly bringing the image up to beta18. I suspect someone still needs to do some work on the droplet image but for the moment my problem is solved.


HotFix - fix to setup.py

I have made mistake of overiding back to template setup.py file in merge request #8.

0001-fixup.patch.txt

Yes, please do, Thanks.

Should I keep patch 0004 for convinience of not messing up someones vscode config?

sure.


How to run at startup/as service?

Hi,
Having problems starting as a service

Here is my /etc/init/py-kms.conf
description "py-kms"
author "myanaloglife"
env PYTHON_HOME=/usr/bin
env PATH=$PYTHON_HOME:$PATH
start on runlevel [2345]
stop on runlevel [016]
chdir /opt/py3-kms
exec $PYTHON_HOME/python3 server.py <IP_ADDRESS> -v DEBUG --logfile /var/log/py-kms_server.log
respawn

Update: So this seems to have done the trick, if you see anything that needs tweaking please let me know
nano /lib/systemd/system/py3-kms.service
[Unit]
Description=py3-kms
After=network-online.target
Wants=network-online.target

[Service]
Restart=always
Type=simple
ExecStart=/usr/bin/python3 /opt/py3-kms/server.py -v DEBUG --logfile /var/log/py-kms_server.log

[Install]
WantedBy=multi-user.target

systemctl enable py3-kms

You could also try:
[Unit]
Description=py3-kms
After=network.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/python3 /opt/py3-kms/server.py -v DEBUG --logfile /var/log/py-kms_server.log
Restart=always
KillMode=process
Type=idle

[Install]
WantedBy=multi-user.target

Then:
sudo chmod 644 /lib/systemd/system/py3-kms.service
sudo systemctl daemon-reload
sudo systemctl enable py3-kms.service

If I use the code by @SystemRage on October 5th will the KMS server run whenever the Raspberry Pi is turned on?

Hi, I have upgraded py-kms to the latest version on my Raspberry Pi 3.
However the service cannot start anymore due to the following error:
May 30 15:58:16 pi systemd[1]: Started Python KMS Server.
May 30 15:58:16 pi python[28247]: Traceback (most recent call last):
May 30 15:58:16 pi python[28247]:   File "/opt/py-kms/py-kms/pykms_Server.py", line 266, in <module>
May 30 15:58:16 pi python[28247]:     srv_main_with_gui()
May 30 15:58:16 pi python[28247]:   File "/opt/py-kms/py-kms/pykms_Server.py", line 197, in srv_main_with_gui
May 30 15:58:16 pi python[28247]:     root = pykms_GuiBase.KmsGui()
May 30 15:58:16 pi python[28247]:   File "/opt/py-kms/py-kms/pykms_GuiBase.py", line 77, in __init__
May 30 15:58:16 pi python[28247]:     tk.Tk.__init__(self, *args, **kwargs)
May 30 15:58:16 pi python[28247]:   File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1823, in __init__
May 30 15:58:16 pi python[28247]:     self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
May 30 15:58:16 pi python[28247]: _tkinter.TclError: no display name and no $DISPLAY environment variable
May 30 15:58:16 pi systemd[1]: py-kms.service: Main process exited, code=exited, status=1/FAILURE
May 30 15:58:16 pi systemd[1]: py-kms.service: Unit entered failed state.
May 30 15:58:16 pi systemd[1]: py-kms.service: Failed with result 'exit-code'.

The service config file /etc/systemd/system/py-kms.service contains the following:
[Unit]
Description=Python KMS Server

[Service]
ExecStart=/usr/bin/python /opt/py-kms/py-kms/pykms_Server.py
User=openhabian
Type=simple
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

(I have also python3 but I get the same error if I change the ExecStart to /usr/bin/python3).
However, if I manually run the ExecStart command from a shell prompt, the server starts in interactive mode without any problem!
Can you please advise how to proceed?
Thanks!

@mobisat
you have to choose if you want to use upstart (/etc/init/py-kms.conf) or systemd (/lib/systemd/system/py-kms.service)
i can't test which really works because i don't have a Raspberry Pi.
@tlc76
https://github.com/SystemRage/py-kms/issues/34#issuecomment-498438644

Below scripts works great on Ubuntu 16.04 with systemctl.
enter the folder:
cd /usr/local/
clone the code:
git clone https://github.com/SystemRage/py-kms.git
create the service script:
nano /etc/systemd/system/py3-kms.service
[Unit]
Description=py3-kms
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=root
ExecStart=/usr/bin/python3 /usr/local/py-kms/py-kms/pykms_Server.py
[Install]
WantedBy=multi-user.target
remarks: do not use the paramater "-v" in the service script.
enable, start and check status of the script:
systemctl enable py3-kms
systemctl start py3-kms
systemctl restart py3-kms
systemctl status py3-kms
After any revision of the service script, please run systemctl daemon-reload before restart the service.
systemctl status py3-kms
● py3-kms.service - py3-kms
Loaded: loaded (/etc/systemd/system/py3-kms.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-04-12 06:45:14 PDT; 2s ago
Main PID: 27885 (python3)
Tasks: 3
Memory: 11.5M
CPU: 145ms
CGroup: /system.slice/py3-kms.service
└─27885 /usr/bin/python3 /usr/local/py-kms/py-kms/pykms_Server.py

Hey, you could also use the new docker image option. Take a look into the docker folder for that. It includes also a restart at boot time.


How to visualize the attention map for Scene-Inst. Cross-Attention like Figure 5 in the paper?

Hi, I am really appreciate the brilliant work!
I just wonder how to visualize the attention map for Scene-Inst. Cross-Attention like Figure 5 in the paper?
thank you very much !

To visualize the activation map for cross attention, you can compute the affinity matrix, which is the N × N matrix obtained by calculating the dot product Q • K in the attention mechanism, where N represents the number of voxels. Then you can visualize the activation of shape N by traversing the matrix.


Use redux toolkit to handle clusters actions

add @reduxjs/toolkit dependency
remove unused types, reducers, actions, selectors
reimplement clusters component to use clusterSlice

I like the @reduxjs/toolkit


Update Module.md file with setup guide and quick start guide

Purpose
Enhance Module.md with a setup guide, token generation instructions, and a quick start guide to improve user onboarding and API usage.
Changes

Added setup guide including token generation instructions with images
Added quick start guide with Ballerina code
Added note about the other authentication methods

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


When will this project continue?

I really this project, since I have lots experience with blazor. I hope this will not stop and continue soon.
Thank

Here is a amazing project forked from MobileBlazorBinfdings by @Dreamescaper .
https://dreamescaper.github.io/MobileBlazorBindingsDocs/maui-blazor-bindings/index.html
It works on MAUI.
I have tried and works very fine.
It is recognized by @Eilon  and the pull request is also approved.
Try the forked project while waiting for the official announcement !

Please bring blazor good feature to client project development. WPF will die, MAUI is daunting. Avalonia is imperfect.
Today client developer is outdated.

Would be great to get some update from someone @ Microsoft. This is a much desired feature. @SteveSandersonMS

this can be very nice for us for systems those not support by maui!
and we need it in countries like india and...


Space after tables in Word

Word tables, like all other blocks, need to have 12pt space after them. The stylesheets attempt to enforce that with margin-bottom, but Word is ignoring it.

... https://superuser.com/questions/728099/how-can-i-add-spacing-between-a-table-and-the-paragraph-immediately-after-it
The magic Word CSS needed is not the standard margin-bottom: x, which Word apparently exports only for forward compatibility with HTML, but mso-table-bspace:1.0cm;mso-table-anchor-vertical:paragraph;: table spacing is treated as an instance of frames in Word HTML.
Modifying all tables with borders in stylesheets. Example tables currently don't need this, because their spacing is being taken care of at the paragraph level, not the table level.


feat(CCTP + FeeDistributor): Logic for both CCTP and FeeDistributor

Adds logic for handling normal vs cctp transfer

Greater than X amount will route cross chain transfer via CCTP. Normal flow otherwise

Adds logic for fee distribution

Array of recipients each with a raw value to define how much fees they get

Most of the file changes are due to the pragma being updated from 0.8.2 -> 0.8.24. I've left it as ^0.8.24 but we can fix the version to 0.8.24
Can ignore scripts/temp directory. Mainly used when debugging during backend integration
Unit tests being updated

we can Salman's PR to push the final changes


[patch] change default value of ShutdownDuration and ProbeWaitTime

TODO

[x] default to 0
[x] add doc

Codecov Report

Merging #28 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           master     #28   +/-   ##
======================================
  Coverage    81.7%   81.7%
======================================
  Files          14      14
  Lines         492     492
======================================
  Hits          402     402
  Misses         79      79
  Partials       11      11

Impacted Files
Coverage Δ

service/server.go
92.81% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 28422ab...b267cc5. Read the comment docs.

LGTM


Break OuterMetaComponent.F90 into submodule files

Types of change(s)

[ ] 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)
[ ] Trivial change (affects only documentation or cleanup)

Checklist

[ ] Tested this change with a run of GEOSgcm
[x] Ran the Unit Tests (make tests)

Description
We break the module in the file OuterMetaComponent.F90 into submodules. Each submodule is in its own file that is located in the new folder OuterMetaComponent.
Related Issue

CircleCI was all sorts of broken yesterday due to GEOSgcm v11.6.

Well this is odd. Why is the ADAS one the only failure?


PopupMenuButton menus inherit the button theme

If the theme inherited by a PopupMenuButton shadows the material app's theme then the menu itself will be wrapped with the shadow theme. In the common case, where only the app creates a theme widget, the menu inherits the app's theme as usual.
Fixes #5572

As discussed, I suspect the other ones need it too because they probably have Material widgets and so forth.
LGTM.


ETH-Precision PATCH to Profile Fails on Moderator Info

When saving moderator info via PATCH to a node that previously had a fixed fee, a invalid profile: percentage moderator fee should not include a fixed fee or should use (FIXED_PLUS_PERCENTAGE) feeType error is returned even though no fixed fee data was sent.
This is happening on ethereum-master 257a3e8
Below is the payload of the call.
{
  "moderator": true,
  "moderatorInfo": {
    "fee": {
      "feeType": "PERCENTAGE",
      "percentage": 50
    },
    "description": "This is just a test account, do not use.",
    "termsAndConditions": "No disputes will be moderated. This is only a test account.",
    "languages": [
      "en-US"
    ]
  }
}

It's a bit mysterious to me how this is happening at the same time as #1879, unless it's caused by saving a fixed fee first, then trying to change it.

This is because the value is 0 instead of nil @jjeffryes since it was set before.

This is still happening for me.
Here's my profile:
    "moderatorInfo": {
        "description": "Describe the scribe.",
        "termsAndConditions": "The terms are germs.",
        "languages": [
            "en-US"
        ],
        "acceptedCurrencies": [
            "BCH",
            "ZEC",
            "LTC",
            "ETH",
            "BTC"
        ],
        "fee": {
            "fixedFee": {
                "currencyCode": "",
                "amount": 0,
                "bigAmount": "1",
                "amountCurrency": {
                    "code": "USD",
                    "divisibility": 2
                }
            },
            "percentage": 0.5,
            "feeType": "FIXED_PLUS_PERCENTAGE"
        }
    },

Here's my PATCH to update it from a FIXED_PLUS_PERCENTAGE to a PERCENTAGE:
{
  "moderator": true,
  "moderatorInfo": {
    "fee": {
      "feeType": "PERCENTAGE",
      "percentage": 0.5
    },
    "description": "Describe the scribe.",
    "termsAndConditions": "The terms are germs.",
    "languages": [
      "en-US"
    ]
  }
}

@rmisio @hoffmabc
This is sorta working as PATCH is intended to work, even if the client is inconvenienced by it. The validations are just complaining about the junk values which weren't getting caught before. What's happening here is the PATCH request is not "unsetting" the percentage value so when you provide the fixed fee amount, the validation is (rightfully) complaining about both being present. I'm pretty sure a zero value being sent in the percentage value would clear this error up.
I get there will be an argument for the API to semantically do the right thing and "fix" the value the no-longer-used percentage because it's enclosing object was provided and didn't contain ANY percetnage value. It would seem our variety of patch does not differentiate between an absent value and a "zero" value. The other side of this argument is that PATCH is intended to only update the fields which were provided. I think we just need to decide what we want the API to do in this case:

Infer from the fee type and reset unused fields to their zero before persisting changes.
Force the client to pass zero-ed out values for the fields they no longer intend to use and continue strict validation.

I have the behavior of (1) mostly worked out and just need to wrap it up in the morning, but I figured I'd raise this point for discussion just in case I guessed wrong.

I don’t believe that the rfc ever mentions or advocates JSON payloads so I’m not sure the true rule here but also it makes me think that if a moderatorInfo attribute is sent that it would override the entire existing moderatorInfo attribute wouldn’t it? Anyways it seems confusing but #1 is probably how the client would like it and makes the most sense to me.

Closing again since PR 1912 was merged.


Add an option to set a custom EDID

We should add an option that allows the user to specify a custom EDID as a var instead of accepting the default EDID.

Fixed in #25


feat: APPLICS-467 - Welsh translation - have your say journey 4/6

Describe your changes
https://pins-ds.atlassian.net/browse/APPLICS-467?atlOrigin=eyJpIjoiMjhlZmNhYjQ2M2IwNDE4ZmExYjg1NWRkZGQxMmMwOGIiLCJwIjoiaiJ9
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 not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[x] I have performed a self-review of my own code
[ ] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[ ] I have provided details on how I have tested my code
[ ] I have referenced the ticket number above
[ ] I have provided a description of the ticket
[ ] I have included unit tests to cover any testable code changes

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.27.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fix chromium on linux prefixing that was falling back to prefixall.

Hello,
I'm using material-ui which in turn uses inline-style-prefixer.
I found out the problem I was having is already reported by issue #84.
Following @sunflowerdeath suggestions corrected the issue for me.
This PR has the modification.

Thank you!


Entity Updates Jan 4 Diana Half

 Change(s):

Adding full name entity mappings back to detections
Splitting account full names mappings into UPN Suffix and name (but also keeping full name mapping as well)

Reason for Change(s):

Increasing entity mappings helps w alert correlations

Version Updated:

yes

Testing Completed:

yes

Checked that the validations are passing and have addressed any issues that are present:

not yet

Hello @ddamenova, Please try to resolve Validation errors


⚠ Processors has degraded performance

In fe8b300, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: Processors performance has improved in 2b5ef28.


Not able to share file+text together on whatsapp

await SocialSharingPlus.shareToSocialMedia(
SocialPlatform.whatsapp,
'Msg text',
media: file.path,
isOpenBrowser: false,
);
ERROR
Unhandled Exception: Exception: Failed to share to SocialPlatform.whatsapp: Couldn't find meta-data for provider with authority com.ks.dev.fileprovider

Hi @ArisChoice
Thank you for issue.
What type of file do you want to share, and have you completed the setup mentioned at https://pub.dev/packages/social_sharing_plus#setup? If so, could you share it?


include_prerelease option

Notes:

copied current node-semver behavior (including https://github.com/npm/node-semver/commit/059a5adec5aefaa764bf4fdb717ae8b42cbbefcd I have no idea what does that mean).
platform-dependent (Rubygems) specs changed too, you need to check if it breaks anything
not sure if it make sense to use keyword arguments (gives argument validation) or hash (easier to pass)

Ping @jsonperl. Just checking if this PR make sense.


Programmatic usage produces empty output

I'm using this script, which I adapted from the README:
const {transform} = require('cjstoesm');

async function main() {
    const input = require.resolve('./fixtures');

    console.log('Running on', input);
    const result = await transform({
        input
    });

    console.log(result);
}

main();

The output is:
$ node tools/codemod/cjs-to-esm/codemod.js
Running on /Users/nheiner/code/tvui/tools/codemod/cjs-to-esm/fixtures/index.js
{ files: [] }

Hi there,
Thanks for making me aware of this potential regression.
Can you provide some more details, such as:

What's your OS/subsystem?
What's the file extensions of your source files?
Or even better, can you provide a minimal repro that causes this behavior?

I will set up some test cases and see if U can reproduce this easily myself, but any details you might have will aid me.

Hi again,
I was able to reproduce and fix this problem easily. A fix has been released in v1.1.0

It seems it's reproducible on v1.1.4 again, it's able to produce output with cli but not with API use. I'm on OSX
const result = await transform({
  input: args.path,
  outDir: 'dist',
  write: false,
  debug: true,
})

console.log('result: ', result.files)

Output:
[DEBUG] Options: {
  input: [
    '/project/reapex-cli/node_modules/react-dom/cjs/react-dom.development.js'
  ],
  outDir: '/project/reapex-cli/examples/counter/dist',
  cwd: '/project/reapex-cli/examples/counter',
  write: false,
  debug: true,
  preserveModuleSpecifiers: 'external'
}
[DEBUG] Matched files: "/Users/yulongruan/project/reapex-cli/node_modules/react-dom/cjs/react-dom.development.js"
result:  []


ERROR TypeError: undefined is not an object (evaluating '_NativeWindStyleSheet.create')

Followed the Getting Started steps here - https://axeldelafosse.com/blog/universal-design-system
Ran yarn native
Got the error above

Any ideas on what I missed or how to fix?

hey @michaelmowry, I want to help you, looks like your setup is not our project,  can you share with me the project link?


Default timeout option not work as when it is set

About my situation
I'm on way to integrate demo app with PostgreSQL database hosted at Amazon RDS (Relational Database Service). Tried to just set hostname, but got timeout, so I tried some combinations of timeout options. It's configuration that works for me:
config :my_app, MyApp.Repo,
  adapter: Ecto.Adapters.Postgres,
  database: "my_app_prod",
  hostname: "my_app.********.rds.amazonaws.com",
  password: "postgres",
  pool_size: 10,
  pool_timeout: 15_000,
  timeout: 15_000,
  username: "postgres"

Here is quote from docs:

:timeout - The default timeout to use on queries, defaults to 15000

It looks simple and it's not stopping my work, but I want just to note that default value is not working like when it is manually set by me.
Precheck

Do not use the issues tracker for help or support requests (try Stack Overflow, IRC or mailing lists, etc).
I already solved it myself, but I want to note about what I found.
For proposing a new feature, please start a discussion on elixir-ecto.
It looks like a bug
For bugs, do a quick search and make sure the bug has not yet been reported.
I tried to search timeout for active issues
Finally, be nice and have fun!
ok :smile:

Environment

Elixir version (elixir -v):

Erlang/OTP 19 [erts-8.2.2] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]

Elixir 1.4.1

Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.):

PostgreSQL 9.6.1 hosted at Amazon RDS

Ecto version (mix deps):

* ecto 2.0.6 (Hex package) (mix)
  locked at 2.0.6 (ecto) 9dcbf819
  ok

Database adapter and version (mix deps):

* postgrex 0.12.1 (Hex package) (mix)
  locked at 0.12.1 (postgrex) 2f8b46cb
  ok

Operating system:

Funtoo Linux (Gentoo based)
Erlang and Elixir installed using asdf

Current behavior
After remove only timeout from repo configuration (so it should use default value that is same as I specified) I got connection closed message:
12:08:07.420 [error] GenServer #PID<0.204.0> terminating
** (DBConnection.ConnectionError) tcp recv: closed
    (db_connection) lib/db_connection/connection.ex:148: DBConnection.Connection.connect/2
    (connection) lib/connection.ex:622: Connection.enter_connect/5
    (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
Last message: nil
State: Postgrex.Protocol
** (Mix) The database for MyApp.Repo couldn't be created: an exception was raised:
    ** (DBConnection.ConnectionError) tcp recv: closed
        (db_connection) lib/db_connection/connection.ex:148: DBConnection.Connection.connect/2
        (connection) lib/connection.ex:622: Connection.enter_connect/5
        (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3

I tried multiple times set and comment this configuration variable and always got same results.
Expected behavior
Set same (as default specified in docs) value in configuration should work as same as not set it. Am I wrong?

Please provide a way for us to reproduce this otherwise we may spend quite some time hunting a timeout bug, which is not exactly easy to reproduce.

From a quick check, the timeout is defaulting to 15000. This is the DBConnection specification we get if there is timeout is not given:
{DBConnection.Poolboy,
 {:poolboy, :start_link,
  [[name: {:local, Ecto.Integration.PoolRepo.Pool}, strategy: :fifo, size: 10,
    max_overflow: 0, worker_module: DBConnection.Poolboy.Worker],
   {Postgrex.Protocol,
    [types: Ecto.Adapters.Postgres.TypeModule, port: 5432,
     name: Ecto.Integration.PoolRepo.Pool, otp_app: :ecto,
     repo: Ecto.Integration.PoolRepo,
     loggers: [Ecto.LogEntry, {Ecto.Integration.Repo, :log, [:on_log]}],
     adapter: Ecto.Adapters.Postgres, pool_size: 10, max_restarts: 20,
     max_seconds: 10, username: "postgres", password: "postgres",
     database: "ecto_test", hostname: "localhost", pool_timeout: 5000,
     timeout: 15000,
     loggers: [Ecto.LogEntry, {Ecto.Integration.Repo, :log, [:on_log]}],
     adapter: Ecto.Adapters.Postgres, pool: DBConnection.Poolboy,
     url: "ecto://postgres:postgres@localhost/ecto_test", pool_size: 10,
     max_restarts: 20, max_seconds: 10]}]}, :permanent, 5000, :worker,
 [:poolboy]}

@josevalim: As I wrote I'm working with Amazon RDS, so I tried to check production configuration before I push it to git repository.
I can reproduce it in simple steps:

Run: mix phoenix.new sample - just new phoenix app with Ecto already prepared
Setup database from 3rd party service
Set configuration as in issue:

config :sample, Sample.Repo,
  adapter: Ecto.Adapters.Postgres,
  database: "sample_prod",
  hostname: "***.******.rds.amazonaws.com",
  password: "postgres",
  pool_size: 10,
  pool_timeout: 15_000,
  # timeout: 15_000,
  username: "postgres"

Run:

MIX_ENV=prod mix deps.get
MIX_ENV=prod mix compile
MIX_ENV=prod mix ecto.create

You should have connection closed error.
5. Uncomment timeout, recompile and try create database (as above). You should have database created.
I also saw source code and was surprised and now I tried this steps to reproduce problem.

Oh, I see that you are using Postgrex 0.12.1 and version 0.13.0 has improvements on how it connects and bootstraps, especially with external services. Can you also try 0.13.2? It will require Ecto 2.1 though. You can use the new phx.new generators if you want an app that is ready to go on latest versions.

@josevalim: I got:

** (Mix) The task "phx.new" could not be found

@josevalim: I got same error message. Here is my list of dependencies:
* connection 1.0.4 (Hex package) (mix)
  locked at 1.0.4 (connection) a1cae722
  ok
* gettext 0.13.1 (Hex package) (mix)
  locked at 0.13.1 (gettext) 5e0daf4e
  ok
* ranch 1.3.2 (Hex package) (rebar3)
  locked at 1.3.2 (ranch) e4965a14
  ok
* poolboy 1.5.1 (Hex package) (rebar)
  locked at 1.5.1 (poolboy) 6b461639
  ok
* decimal 1.3.1 (Hex package) (mix)
  locked at 1.3.1 (decimal) 157b3ced
  ok
* poison 2.2.0 (Hex package) (mix)
  locked at 2.2.0 (poison) 4763b69a
  ok
* db_connection 1.1.2 (Hex package) (mix)
  locked at 1.1.2 (db_connection) 2865c2a4
  ok
* phoenix_pubsub 1.0.1 (Hex package) (mix)
  locked at 1.0.1 (phoenix_pubsub) c10ddf62
  ok
* cowlib 1.0.2 (Hex package) (rebar3)
  locked at 1.0.2 (cowlib) 9d769a1d
  ok
* cowboy 1.1.2 (Hex package) (rebar3)
  locked at 1.1.2 (cowboy) 61ac29ea
  ok
* mime 1.1.0 (Hex package) (mix)
  locked at 1.1.0 (mime) 01c1d6f4
  ok
* plug 1.3.3 (Hex package) (mix)
  locked at 1.3.3 (plug) d9be1899
  ok
* phoenix_html 2.9.3 (Hex package) (mix)
  locked at 2.9.3 (phoenix_html) 1b5a2122
  ok
* phoenix 1.2.1 (Hex package) (mix)
  locked at 1.2.1 (phoenix) 6dc59224
  ok
* postgrex 0.13.2 (Hex package) (mix)
  locked at 0.13.2 (postgrex) 2b88168f
  ok
* ecto 2.1.4 (Hex package) (mix)
  locked at 2.1.4 (ecto) d1ba9328
  ok
* phoenix_ecto 3.2.3 (Hex package) (mix)
  locked at 3.2.3 (phoenix_ecto) 450c7498
  ok

@Eiji7 try handshake_timeout: 15_000 or similar. I think the default is 5_000.

I think the issue is why it works if he sets timeout: 15000 even though
that's our advertised default. :(
José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

@fishcakez: yup, with commented timeout and added handshake_timeout it also works
Is it documented? I don't found it using search field in Ecto docs.

Okay I see the issue. We only pass runtime config when starting the pool so only pass application env values. This means we actually use Postgrex defaults, and not Ecto's, and timeout is the only one that differs. Unfortunately Postgrex defaults to timeout: 5_000 (because it had that timeout before Ecto's was set to 15_000) and handshake_timeout introduced in Postgrex 0.13.0 defaults to timeout, in 0.12 it is always timeout.
Note that passing timeout when starting the pool does NOT affect the transaction/query timeout. This uses runtime + compile time config and is independent of options used to start the pool. The timeout above is occurring on handshake, and not a query, and so technically we aren't breaking what the docs claim ;) but that is a bad user experience. We should make sure to pass runtime defaults to adapters.

Thanks James! Can you point where we should be passing the defaults but we
are not? I thought passing those on child_spec is enough?
José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

@josevalim Oh we do pass compile config in Ecto.Adapters.SQL.child_spec....
@Eiji7 can you let use know the result of the following (it must be same environment):
MyApp.Repo.__pool__ |> elem(1) |> Keyword.take([:timeout, :pool_timeout, :connect_timeout, :handshake_timeout])

Also it seems Postgrex now claims to have a default timeout of 15_000 so we should fix the default in Postgrex - it honours this for queries but not connect_timeout and handshake_timeout.

@fishcakez: With options:
config :sample, Sample.Repo,
  adapter: Ecto.Adapters.Postgres,
  database: "sample_prod",
  hostname: "***.******.amazonaws.com",
  password: "postgres",
  handshake_timeout: 15_000,
  pool_size: 10,
  pool_timeout: 15_000,
  # timeout: 15_000,
  username: "postgres"

In iex (MIX_ENV=prod iex -S mix) I got:
[timeout: 15000, handshake_timeout: 15000, pool_timeout: 15000]

@Eiji7 so we do honour the compile time config / the Ecto default of 15_000. Can you post the exact error when using Postgrex 0.13.2 and Ecto 2.1.4?

oh, It looks like I don't have: :connect_timeout in pool opts from your command:

:connect_timeout is not expected to be there ;), it defaults to :timeout value.

@fishcakez: Without handshake_timeout and timeout in configuration like:
# file: config/prod.secret.exs
config :sample, Sample.Repo,
  adapter: Ecto.Adapters.Postgres,
  database: "sample_prod",
  hostname: "***.******.rds.amazonaws.com",
  password: "postgres",
  # handshake_timeout: 15_000,
  pool_size: 10,
  pool_timeout: 15_000,
  # timeout: 15_000,
  username: "postgres"

I run: MIX_ENV=prod mix ecto.drop and got:
Are you sure you want to drop the database for repo Sample.Repo? [Yn] Y

14:39:06.467 [error] Postgrex.Protocol (#PID<0.174.0>) timed out because it was handshaking for longer than 5000ms

14:39:06.490 [error] GenServer #PID<0.174.0> terminating
** (DBConnection.ConnectionError) tcp recv: closed
    (db_connection) lib/db_connection/connection.ex:148: DBConnection.Connection.connect/2
    (connection) lib/connection.ex:622: Connection.enter_connect/5
    (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
Last message: nil
State: Postgrex.Protocol
** (Mix) The database for Sample.Repo couldn't be dropped: an exception was raised:
    ** (DBConnection.ConnectionError) tcp recv: closed
        (db_connection) lib/db_connection/connection.ex:148: DBConnection.Connection.connect/2
        (connection) lib/connection.ex:622: Connection.enter_connect/5
        (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3

@Eiji7 ah okay, so we do only pass runtime config to the mix task! I was right before, but forgot we started a custom version of Postgrex.
@josevalim we have a few strangeness with configuration.

We pass repo.config at https://github.com/elixir-ecto/ecto/blob/2fa22697bdb8094e8ace82ff773fe74cbab5d4aa/lib/mix/tasks/ecto.create.ex#L36
The callback docs state we fetch application env but we also need compile config: https://github.com/elixir-ecto/ecto/blob/f1df0aee0fbec8d6ce9e73d4212b3ea33c11fec1/lib/ecto/repo.ex#L253

@fishcakez:
One note: I just compared error from issue and error from my comment and I see that in older versions (on which I work) I don't have this part:
14:39:06.467 [error] Postgrex.Protocol (#PID<0.174.0>) timed out because it was handshaking for longer than 5000ms

Ok. So we are not setting adapter defaults when invoking storage_up and
storage_down. Everything else seems correct. I think the docs for
repo.config are a bit cryptic though.
José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

Ok. So we are not setting adapter defaults when invoking storage_up and
storage_down. Everything else seems correct. I think the docs for
repo.config are a bit cryptic though.

:+1:


cargo update -p SPEC can silently downgrade dependencies of other packages

This is kinda convoluted, but it bit me when I wasn't paying attention when updating rust's lock file.  Here's a relatively small repro.  Create a workspace with the following members and dependencies:
a → bitflags="0.9"
b → bitflags=">= 0.9, < 2.0"
c → bitflags="1.0"

cargo update will generate a lockfile that looks good (a→0.9, b→1.0, c→1.0).
cargo update -p c will downgrade b's copy of bitflags to 0.9!  I'd expect it to leave it as-is.
The real-world example of this is in rust where these chains exist:
rustbook → ... → html5ever → .. → rand 0.3
rls → rayon → rayon-core → rand >=0.3, < 0.5
cargo → ... → rand 0.4

Updating cargo caused rayon's version of rand to downgrade.  I didn't use rand in my example above because version 0.3 is a little odd in that it also depends on rand 0.4, but doesn't seem to be important and just complicates the example.

I believe this is sort of an instance of https://github.com/rust-lang/cargo/issues/2064, given multiple valid resolution graphs Cargo doesn't necessarily guarantee which one is generated. Otherwise Cargo doesn't currently have a heuristic to minimize the number of major versions resolved to

@ehuss Thank you for the cleare example, if it is easy for you do you have a zip file or a repo of this test case? If not I can stop being lazy and make one for myself.
I suspect we are trying things that are in self.try_to_use out of order, but I'd need to dig in to find out why.

Here you go: wsdown.zip

I can reproduce! Thanks! Now to investigate.

I added some prints after that sort
        print!("{}:{} => <", dep.name(), dep.version_req());
        for i in &ret {
            print!("{}, ", i.summary.version());
        }
        println!(">");

then in the unzipped folder:
issues5529> ..\cargo\target\release\cargo.exe  update -p c -Z no-index-update
bitflags:= 0.9.1 => <0.9.1, >
bitflags:^1.0 => <1.0.3, 1.0.2, 1.0.1, 1.0.0, >

So the issue is not that sort, it is where is the  =0.9.1 version_req coming from. It is not from any of the Cargo.toml's. So it must be inferred from the lock file, (@alexcrichton is that a thing that happens?) and it must inferred incorrectly as the lock file is supposed to keep c depending on 1.0.3.

@Eh2406 correct yeah, when Cargo reads a lock file it'll re-resolve with a lot of =0.9.1 dependencies and such, so if you cargo update -p foo it'll do a "conservative update" of foo but try to not tamper with the rest of the dependency graph.

Oh dear, that does sound like a problem! I'm not entirely sure where that'd come from...

@Eh2406 FWIW the locking pieces are all roughly around here. I'm not sure how much you've had a chance to explore core/registry.rs but that's where a good deal of the lockfile logic happens instead of the resolver itself

I tried running with set RUST_LOG=trace
Some hilites (or may be not. I may miss reading as I don't know core/registry.rs):
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: ignoring any lock pointing directly at c v0.1.0 (file:///.../issues5529/c)
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: ignoring any lock pointing directly at bitflags v1.0.3

^ That looks like it may be where we ignore the lock file.
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of a v0.1.0 (file:///.../issues5529/a)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      bitflags/^0.9/registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      first hit on bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::dependency: locking dep from `bitflags` with `^0.9` at registry `https://github.com/rust-lang/crates.io-index` to bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of b v0.1.0 (file:///.../issues5529/b)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      bitflags/>= 0.9, < 2.0/registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      second hit on bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::dependency: locking dep from `bitflags` with `>= 0.9, < 2.0` at registry `https://github.com/rust-lang/crates.io-index` to bitflags v0.9.1

^ That looks like it may be where lock the dep from b to the wrong thing.

issues5529>set RUST_LOG=trace
issues5529>..\cargo\target\debug\cargo.exe update -p c -Z no-index-update
TRACE 2018-07-11T18:48:11Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529
DEBUG 2018-07-11T18:48:11Z: cargo::core::workspace: find_root - is root C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml
DEBUG 2018-07-11T18:48:11Z: cargo::core::workspace: find_members - C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\a\Cargo.toml
TRACE 2018-07-11T18:48:11Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\a\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
DEBUG 2018-07-11T18:48:11Z: cargo::core::workspace: find_members - C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\b\Cargo.toml
TRACE 2018-07-11T18:48:11Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\b\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
DEBUG 2018-07-11T18:48:11Z: cargo::core::workspace: find_members - C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\c\Cargo.toml
TRACE 2018-07-11T18:48:11Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\c\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
DEBUG 2018-07-11T18:48:11Z: cargo::core::workspace: find_members - C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml
DEBUG 2018-07-11T18:48:11Z: cargo::core::workspace: find_root - trying C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - found a root checking exclusion
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - found!
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - trying C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - found a root checking exclusion
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - found!
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - trying C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - found a root checking exclusion
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - found!
DEBUG 2018-07-11T18:48:12Z: cargo::core::workspace: find_root - is root C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\Cargo.toml
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: load/missing  file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: loading source file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
DEBUG 2018-07-11T18:48:12Z: cargo::sources::config: loading: file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
TRACE 2018-07-11T18:48:12Z: cargo::core::source::source_id: loading SourceId; file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
TRACE 2018-07-11T18:48:12Z: cargo::ops::cargo_read_manifest: read_package; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\c\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
TRACE 2018-07-11T18:48:12Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\c\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
TRACE 2018-07-11T18:48:12Z: cargo::ops::resolve: previous: graph: Graph {
  - c v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c)
    - bitflags v1.0.3
  - bitflags v0.9.1
  - b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
    - bitflags v1.0.3
  - a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
    - bitflags v0.9.1
  - bitflags v1.0.3
}

features: {
}
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: ignoring any lock pointing directly at c v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c)
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: ignoring any lock pointing directly at bitflags v1.0.3
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: register_lock: bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: register_lock: b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: register_lock: a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      -> bitflags v0.9.1
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: attempting to prefer bitflags v0.9.1
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: attempting to prefer b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: attempting to prefer a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
DEBUG 2018-07-11T18:48:12Z: cargo::ops::resolve: attempting to prefer bitflags v1.0.3
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: load/missing  file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: loading source file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
DEBUG 2018-07-11T18:48:12Z: cargo::sources::config: loading: file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
TRACE 2018-07-11T18:48:12Z: cargo::core::source::source_id: loading SourceId; file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
TRACE 2018-07-11T18:48:12Z: cargo::ops::cargo_read_manifest: read_package; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\a\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
TRACE 2018-07-11T18:48:12Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\a\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: load/missing  file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: loading source file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
DEBUG 2018-07-11T18:48:12Z: cargo::sources::config: loading: file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
TRACE 2018-07-11T18:48:12Z: cargo::core::source::source_id: loading SourceId; file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
TRACE 2018-07-11T18:48:12Z: cargo::ops::cargo_read_manifest: read_package; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\b\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
TRACE 2018-07-11T18:48:12Z: cargo::util::toml: read_manifest; path=C:\Users\finkelman.SEMCOGDOM\Documents\MyProjects\cargo_speed_test\issues5529\b\Cargo.toml; source-id=file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: load/locked   file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      bitflags/^0.9/registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      first hit on bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::dependency: locking dep from `bitflags` with `^0.9` at registry `https://github.com/rust-lang/crates.io-index` to bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      bitflags/>= 0.9, < 2.0/registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      second hit on bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::dependency: locking dep from `bitflags` with `>= 0.9, < 2.0` at registry `https://github.com/rust-lang/crates.io-index` to bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of c v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c)
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      bitflags/^1.0/registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::registry:      nope, unlocked
DEBUG 2018-07-11T18:48:12Z: cargo::core::resolver: initial activation: a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: activating a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: load/missing  registry `https://github.com/rust-lang/crates.io-index`
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: loading source registry `https://github.com/rust-lang/crates.io-index`
DEBUG 2018-07-11T18:48:12Z: cargo::sources::config: loading: registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::source::source_id: loading SourceId; registry `https://github.com/rust-lang/crates.io-index`
DEBUG 2018-07-11T18:48:12Z: cargo::sources::registry: skipping update due to locked registry
DEBUG 2018-07-11T18:48:12Z: cargo::sources::registry: attempting query without update
TRACE 2018-07-11T18:48:12Z: cargo::sources::registry::remote: opened a repo without a lock
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of bitflags v0.9.1
DEBUG 2018-07-11T18:48:12Z: cargo::core::resolver: initial activation: b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: activating b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
DEBUG 2018-07-11T18:48:12Z: cargo::core::resolver: initial activation: c v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c)
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: activating c v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c)
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: load/mismatch registry `https://github.com/rust-lang/crates.io-index`
DEBUG 2018-07-11T18:48:12Z: cargo::core::registry: loading source registry `https://github.com/rust-lang/crates.io-index`
DEBUG 2018-07-11T18:48:12Z: cargo::sources::config: loading: registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::core::source::source_id: loading SourceId; registry `https://github.com/rust-lang/crates.io-index`
TRACE 2018-07-11T18:48:12Z: cargo::sources::registry::remote: opened a repo without a lock
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of bitflags v1.0.0
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of bitflags v1.0.1
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of bitflags v1.0.2
TRACE 2018-07-11T18:48:12Z: cargo::core::registry: locking summary of bitflags v1.0.3
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: a[0]>bitflags 1 candidates
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: a[0]>bitflags 0 prev activations
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: a[0]>bitflags trying 0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: activating bitflags v0.9.1
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: b[0]>bitflags 1 candidates
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: b[0]>bitflags 1 prev activations
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: b[0]>bitflags trying 0.9.1
DEBUG 2018-07-11T18:48:12Z: cargo::core::resolver::context: checking if bitflags v0.9.1 is already activated
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: c[0]>bitflags 4 candidates
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: c[0]>bitflags 1 prev activations
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: c[0]>bitflags trying 1.0.3
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: activating bitflags v1.0.3
TRACE 2018-07-11T18:48:12Z: cargo::core::resolver: resolved: graph: Graph {
  - bitflags v1.0.3
  - c v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c)
    - bitflags v1.0.3
  - b v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b)
    - bitflags v0.9.1
  - bitflags v0.9.1
  - a v0.1.0 (file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a)
    - bitflags v0.9.1
}

features: {
  bitflags v1.0.3: {"default"}
  bitflags v0.9.1: {"example_generated", "default"}
}
DEBUG 2018-07-11T18:48:12Z: cargo::ops::cargo_generate_lockfile: {
    (
        "a",
        SourceId {
            inner: SourceIdInner {
                url: "file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a",
                canonical_url: "file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/a",
                kind: Path,
                precise: None,
                name: None
            }
        }
    ): (
        [],
        []
    ),
    (
        "b",
        SourceId {
            inner: SourceIdInner {
                url: "file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b",
                canonical_url: "file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/b",
                kind: Path,
                precise: None,
                name: None
            }
        }
    ): (
        [],
        []
    ),
    (
        "bitflags",
        SourceId {
            inner: SourceIdInner {
                url: "https://github.com/rust-lang/crates.io-index",
                canonical_url: "https://github.com/rust-lang/crates.io-index",
                kind: Registry,
                precise: Some(
                    "locked"
                ),
                name: None
            }
        }
    ): (
        [],
        []
    ),
    (
        "c",
        SourceId {
            inner: SourceIdInner {
                url: "file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c",
                canonical_url: "file:///C:/Users/finkelman.SEMCOGDOM/Documents/MyProjects/cargo_speed_test/issues5529/c",
                kind: Path,
                precise: None,
                name: None
            }
        }
    ): (
        [],
        []
    )
}
 INFO 2018-07-11T18:48:12Z: cargo::util::job::imp: found 0 remaining processes

Dose that help track it down?

Oh yeah that'd do it! When you attempt to update something we remove locks in the graph that would otherwise possible cause a complete resolution failure, so in this case we're actually coalescing the number of bitflags deps from 2 to 1 which Cargo has a  heuristic for. (in that this looks like expected behavior)

That heuristic is at https://github.com/rust-lang/cargo/blob/cc11d50a27c55c349403bdfa97a2d30b29698d21/src/cargo/core/registry.rs#L564-L567
We don't do minimization when generating the lockfile, why do we do it for update?
Furthermore with the "conservative update" feature the resolver will try to continue using things that are in the lockfile. I think what I am asking is Is there a real case where we get a better answer with the heuristic then we get from the conservative update alone?

Oh we always try to minimize the lock file but it depends what you visit first. If you first see >= 0.9, < 2.0 you'll select 1.0. Only later when you see ^0.9 do you realize you're forced to use two versions. If you see them in the other order, however, you'll only use 0.9 series.
The heuristic for a minimal lockfile is in general just one added to help guide resolution but it's just affecting sorting I believe rather than the actual generated lockfile. I think it depends on the situation which crate graph is considered "more desirable"