New index schema and registry API for extended feature syntax.

This introduces a new features2 field in the index to segregate the new feature syntax for namespaced features and weak dependency features. The intent here is to prevent versions of Cargo older than 1.19 from breaking, since they will fail to run even with a Cargo.lock file.
To prevent publishing from breaking when talking to a registry that does not understand this new field, this switches the publish API to a new URL (api/v2/crates/new).
This also introduces a new schema field to the index and publish API, so that in the future changes can be made, and versions of cargo after this is introduced will silently ignore entries it doesn't understand.
This is split into a number of different commits, with more information in each commit.

r? @alexcrichton
(rust-highfive has picked a reviewer for you, use r? to override)

r? @alexcrichton
(rust-highfive has picked a reviewer for you, use r? to override)

I'm not too happy with this. So...which seems worse?

Method A: Leave the new features in the features field, and let 1.18 and older break completely (even if they have a Cargo.lock) if they use a package that starts using the new syntax.  1.19 and newer will ignore any package published with the new features.

The workaround for this is to use a local index with a snapshot in time before the new features are introduced.

Method B: Add the new features2 field, which allows all versions with a pre-existing Cargo.lock to work correctly.  However, updating the lock file in versions 1.50 and older may potentially select entries with the new features, which will probably result in something that won't build correctly (because they ignore the features2 field).

The workaround for this is to use the --precise flag of cargo update to force it to select older versions before features2 was introduced if you need to generate a Cargo.lock with a package that starts using features2 in a newer version.

I'm not too happy with this. So...which seems worse?

Method A: Leave the new features in the features field, and let 1.18 and older break completely (even if they have a Cargo.lock) if they use a package that starts using the new syntax.  1.19 and newer will ignore any package published with the new features.

The workaround for this is to use a local index with a snapshot in time before the new features are introduced.

Method B: Add the new features2 field, which allows all versions with a pre-existing Cargo.lock to work correctly.  However, updating the lock file in versions 1.50 and older may potentially select entries with the new features, which will probably result in something that won't build correctly (because they ignore the features2 field).

The workaround for this is to use the --precise flag of cargo update to force it to select older versions before features2 was introduced if you need to generate a Cargo.lock with a package that starts using features2 in a newer version.

This includes a test which is ignored by default which can test the behavior of every toolchain. Here's what its output looks like:

Version
Unlocked
Locked

1.0.0-x86_64-unknown-linux-gnu
failed
failed

1.1.0-x86_64-unknown-linux-gnu
failed
failed

1.2.0-x86_64-unknown-linux-gnu
failed
failed

1.3.0-x86_64-unknown-linux-gnu
failed
failed

1.4.0-x86_64-unknown-linux-gnu
failed
failed

1.5.0-x86_64-unknown-linux-gnu
failed
failed

1.6.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.7.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.8.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.9.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.10.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.11.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.12.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.13.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.14.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.15.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.16.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.17.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.18.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.19.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.20.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.21.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.22.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.23.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.24.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.25.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.26.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.27.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.28.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.29.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.30.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.31.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.32.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.33.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.34.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.35.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.36.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.37.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.38.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.39.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.40.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.41.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.42.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.43.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.44.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.45.2-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.46.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.47.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.48.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

stable-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

beta-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

nightly-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

This shows that without a Cargo.lock, every version will select a dependency with the new feature syntax (and will essentially build them as-if the features aren't activated). With a Cargo.lock, they will stick to whichever version they are locked to.
I'm unable to get test results for 1.0 through 1.5. For some reason they are unable to extract the tar files from the testsuite. I suspect it is something related to #2327, but my energy for investigating has run low.

This includes a test which is ignored by default which can test the behavior of every toolchain. Here's what its output looks like:

Version
Unlocked
Locked

1.0.0-x86_64-unknown-linux-gnu
failed
failed

1.1.0-x86_64-unknown-linux-gnu
failed
failed

1.2.0-x86_64-unknown-linux-gnu
failed
failed

1.3.0-x86_64-unknown-linux-gnu
failed
failed

1.4.0-x86_64-unknown-linux-gnu
failed
failed

1.5.0-x86_64-unknown-linux-gnu
failed
failed

1.6.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.7.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.8.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.9.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.10.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.11.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.12.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.13.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.14.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.15.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.16.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.17.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.18.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.19.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.20.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.21.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.22.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.23.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.24.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.25.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.26.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.27.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.28.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.29.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.30.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.31.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.32.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.33.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.34.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.35.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.36.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.37.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.38.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.39.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.40.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.41.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.42.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.43.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.44.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.45.2-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.46.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.47.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

1.48.0-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

stable-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

beta-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

nightly-x86_64-unknown-linux-gnu
success bar=1.0.2
success bar=1.0.1

This shows that without a Cargo.lock, every version will select a dependency with the new feature syntax (and will essentially build them as-if the features aren't activated). With a Cargo.lock, they will stick to whichever version they are locked to.
I'm unable to get test results for 1.0 through 1.5. For some reason they are unable to extract the tar files from the testsuite. I suspect it is something related to #2327, but my energy for investigating has run low.

Thanks for putting this all together! I think this all seems pretty reasonable for "let's keep 1.18 and prior building with a lockfile", but I've still got a few questions.

How come the publish API path is being altered here? Presumably you'd get a worse error if you publish the new features to a registry that doesn't support it, but nothing fundamental is changing, right?
Do you know if crates.io is ready to receive some updates for this PR, primarily in writing new index entries?
Thinking for a moment, perhaps a better publish API would be for Cargo to send the index entry to crates.io itself? Registries then wouldn't have to synthesize a new entry and we wouldn't have to update all registries every time our index format updates (which while presumably rare would be nice to not have to worry about too).

I personally continue to not really be all that interested in worrying about older Cargo's picking up newer versions of crates. I feel like misinterpreting Cargo features is the least of our worries in that respect. I suspect almost no crates published in the last year even compile with Rust 1.0 due to feature usage of libstd or the language. Basically what I mean to say is that we never really designed Cargo in mind with cargo update on Rust 1.0 continuing to work years into the future. So much of that is broken I don't think it's really worth worrying about.
I do think that it seems reasonable to have a version field in the index entry though. It's not harming anyone and it could help tooling later on down the road too.

Thanks for putting this all together! I think this all seems pretty reasonable for "let's keep 1.18 and prior building with a lockfile", but I've still got a few questions.

How come the publish API path is being altered here? Presumably you'd get a worse error if you publish the new features to a registry that doesn't support it, but nothing fundamental is changing, right?
Do you know if crates.io is ready to receive some updates for this PR, primarily in writing new index entries?
Thinking for a moment, perhaps a better publish API would be for Cargo to send the index entry to crates.io itself? Registries then wouldn't have to synthesize a new entry and we wouldn't have to update all registries every time our index format updates (which while presumably rare would be nice to not have to worry about too).

I personally continue to not really be all that interested in worrying about older Cargo's picking up newer versions of crates. I feel like misinterpreting Cargo features is the least of our worries in that respect. I suspect almost no crates published in the last year even compile with Rust 1.0 due to feature usage of libstd or the language. Basically what I mean to say is that we never really designed Cargo in mind with cargo update on Rust 1.0 continuing to work years into the future. So much of that is broken I don't think it's really worth worrying about.
I do think that it seems reasonable to have a version field in the index entry though. It's not harming anyone and it could help tooling later on down the road too.

How come the publish API path is being altered here? Presumably you'd get a worse error if you publish the new features to a registry that doesn't support it, but nothing fundamental is changing, right?

If you publish the new features2 field to the api/v1 path, the new field is ignored (at least by crates.io, I haven't checked other registry implementations).  The registry would end up creating an entry in the index with incorrect features (all of the features2 entries would be missing).  This would then result in broken behavior when you actually try to use the newly published package.  I wanted to be more cautious here because there are increasingly more registry implementations, and we can't guarantee they will all be updated before this PR is merged (in fact, can pretty much guarantee none of them will).

Do you know if crates.io is ready to receive some updates for this PR, primarily in writing new index entries?

It is not.  I have not started that work, I wanted to see how this goes first.  I'm hoping it is not too difficult.  I'm also uncertain when we should do that, since that is permanently committing to the new format, and I'm not sure how to decide when that's ready.

Thinking for a moment, perhaps a better publish API would be for Cargo to send the index entry to crates.io itself? Registries then wouldn't have to synthesize a new entry and we wouldn't have to update all registries every time our index format updates (which while presumably rare would be nice to not have to worry about too).

That sounds reasonable.  I'll need to take a look at the crates.io code to see how well that will fit in.

older Cargo's picking up newer versions of crates

Yea, that seems like a reasonable stance.  However, I was thinking that for a stabilization timeline, I'd like to see this PR in at least 3 versions back before stabilizing, to avoid too much frustration for people.  That is, if this goes in 1.51, then the earliest it should be stabilized is 1.54.  That allows people using stable-1 to continue to safely run cargo update.    (Considering our speed at stabilizing things, I'm not too worried. 😄 )
I'm uncertain how quickly projects will jump on using this new syntax.  Since it is an MSRV bump, I assume most will delay for a while, but I'd like to be a little cautious.

How come the publish API path is being altered here? Presumably you'd get a worse error if you publish the new features to a registry that doesn't support it, but nothing fundamental is changing, right?

If you publish the new features2 field to the api/v1 path, the new field is ignored (at least by crates.io, I haven't checked other registry implementations).  The registry would end up creating an entry in the index with incorrect features (all of the features2 entries would be missing).  This would then result in broken behavior when you actually try to use the newly published package.  I wanted to be more cautious here because there are increasingly more registry implementations, and we can't guarantee they will all be updated before this PR is merged (in fact, can pretty much guarantee none of them will).

Do you know if crates.io is ready to receive some updates for this PR, primarily in writing new index entries?

It is not.  I have not started that work, I wanted to see how this goes first.  I'm hoping it is not too difficult.  I'm also uncertain when we should do that, since that is permanently committing to the new format, and I'm not sure how to decide when that's ready.

Thinking for a moment, perhaps a better publish API would be for Cargo to send the index entry to crates.io itself? Registries then wouldn't have to synthesize a new entry and we wouldn't have to update all registries every time our index format updates (which while presumably rare would be nice to not have to worry about too).

That sounds reasonable.  I'll need to take a look at the crates.io code to see how well that will fit in.

older Cargo's picking up newer versions of crates

Yea, that seems like a reasonable stance.  However, I was thinking that for a stabilization timeline, I'd like to see this PR in at least 3 versions back before stabilizing, to avoid too much frustration for people.  That is, if this goes in 1.51, then the earliest it should be stabilized is 1.54.  That allows people using stable-1 to continue to safely run cargo update.    (Considering our speed at stabilizing things, I'm not too worried. 😄 )
I'm uncertain how quickly projects will jump on using this new syntax.  Since it is an MSRV bump, I assume most will delay for a while, but I'd like to be a little cautious.

Oh I was imagining that if we don't change the publish path that we wouldn't send features2, we'd send everything in features. That means registries would either reject it due to being malformed (e.g. what I think crates.io would do) or pass it through to the index un-blemished. If we do add a features2 on publish to the registry I agree we need a new path, I just wasn't sure if we needed to do that.

Thinking for a moment, perhaps a better publish API would be for Cargo to send the index entry to crates.io itself? Registries then wouldn't have to synthesize a new entry and we wouldn't have to update all registries every time our index format updates (which while presumably rare would be nice to not have to worry about too).

That sounds reasonable. I'll need to take a look at the crates.io code to see how well that will fit in.

Actually on second though this may not be a great idea. I wouldn't want a malicious actor being able to place whatever they want into the index, so crates.io I think will want to maintain tight control over what goes into the index. That does mean, though, that if we bump the version and change the syntax we'll need to always update crates.io as well.

That is, if this goes in 1.51, then the earliest it should be stabilized is 1.54.

While I don't mind being conservative this does seem overly conservative to me. I don't feel this is really all that much different than a new language feature being stabilized. If a crate wants to work with stable-1 then everything it depends on has to have the same policy and no one would use this feature until it hits stable-1 anyway.
In any case though if you'd prefer to be more conservative I don't mind!

Oh I was imagining that if we don't change the publish path that we wouldn't send features2, we'd send everything in features. That means registries would either reject it due to being malformed (e.g. what I think crates.io would do) or pass it through to the index un-blemished. If we do add a features2 on publish to the registry I agree we need a new path, I just wasn't sure if we needed to do that.

Thinking for a moment, perhaps a better publish API would be for Cargo to send the index entry to crates.io itself? Registries then wouldn't have to synthesize a new entry and we wouldn't have to update all registries every time our index format updates (which while presumably rare would be nice to not have to worry about too).

That sounds reasonable. I'll need to take a look at the crates.io code to see how well that will fit in.

Actually on second though this may not be a great idea. I wouldn't want a malicious actor being able to place whatever they want into the index, so crates.io I think will want to maintain tight control over what goes into the index. That does mean, though, that if we bump the version and change the syntax we'll need to always update crates.io as well.

That is, if this goes in 1.51, then the earliest it should be stabilized is 1.54.

While I don't mind being conservative this does seem overly conservative to me. I don't feel this is really all that much different than a new language feature being stabilized. If a crate wants to work with stable-1 then everything it depends on has to have the same policy and no one would use this feature until it hits stable-1 anyway.
In any case though if you'd prefer to be more conservative I don't mind!

Actually on second though this may not be a great idea.

Oh, good point!
Let me know if you have any other questions.  This does seem like a semi-major change, but I'm uncertain of what else to consider.

Here's a few more possible suggestions:

Perhaps a config.json field in the index could indicate whether the registry supports the v2 endpoint or not? That way if you publish to a custom registry (or crates.io, really) without it supporting it we'd have a first-class error rather than handling the 404.
For the v2 endpoint I'd probably drop the features2 field, and have the registry split it into the v2 format index entry since registries are writing the index entry anyway.

Other than that though I don't have much else on this either, so while I agree it's somewhat major it seems fine to go ahead and start rolling this out. This is unfortunately more work than I thought it would be to handle 1.19....
One option is to add the index entry versioning and we could add that ASAP to Cargo and even backport it to ensure at least that part hits stable as soon as it can?

I dunno I'm also a little wishy-washy on the versioning in the index entry. I'm not really sure it buys us anything unless we actually have a plan to drop Rust versions at some point. If we don't ever drop Rust versions then we're always stuck with 1.18 and prior.  Similarly we're always stuck with Cargo versions that don't look for an index entry version field. Given our current trajectory it seems like we'll never make use of this version field since we'll always be handling those older versions?

A version field lets us change the meaning of fields that are newer then when the version field was added.
Let's say we add a new sintaxe to features2 in cargo 1.99 but cargo 1.55 will crash or misunderstand that sintaxe. Then by bumping the version field we can tell that version to not try.
It is limited. It can't change the presence of existing fields (while we support 1.19). It can't change the meaning of existing fields (while we support version before it was added). But even the little slice of flexibility seems useful.

That's a good point yeah! While I'm not too sure how useful the ability will be in the future that I think convinces me that we may as well go ahead and implement it.

:umbrella: The latest upstream changes (presumably #9125) made this pull request unmergeable. Please resolve the merge conflicts.

This has been split into several other PRs: #9125, #9126, #9161


Create student.txt

@trcong120299 The registrant of this domain is "UB VIETNAM INVESTMENT AND DEVELOPMENT JOINT STOCK COMPANY". This domain does not belong to a university, nor to a college. I have to close the request without merging. Please ensure that you are familiar with this repository rules located at the bottom of this page before submitting a new request.


Allow downloading DASH streams in any order

In response to the discussion in #5575. Please note that the 'format' and 'format_id' fields in the info_json are normalised back to video+audio order; this may or may not be desirable.
I still think downloading audio first should be the default.

Any particular reasons for not merging this or is it just general overload?

i don't think that normalizing it is good idea, the options you point at here https://github.com/rg3/youtube-dl/pull/5575#issuecomment-98386403 are better.

I don't understand your comment. This patch actually implements one of them.

to have -f bestaudio+bestvideo download audio first

here you said you want this to download audio before the video.

are normalised back to video+audio order

as i understand this mean if i put -f bestaudio+bestvideo it will change to look like -f bestvideo+bestaudio.


Fix rsync behaviour with callable environment vars

I run into bit of trouble with rsync when depending on server, rsync is weirdly different. Consider this code:
server('production', 'prod.server', 22)
        ->user('Product')
        ->stage('production')
        ->forwardAgent()
        ->env('deploy_path', '/var/www/vhosts/product')
        ->env('rsync_src', function() {
          $local_src = env('local_release_path');
          if (is_callable($local_src)) {
            $local_src = $local_src();
          }
          return $local_src;
        });
server('dev', 'devel.preview', 22)
        ->user('preview')
        ->stage('dev')
        ->forwardAgent()
        ->env('deploy_path', '/var/www/vhosts/preview.host/product')
        ->env('rsync_src', __DIR__)
        ->env('rsync_dest', '{{current}}');

Using rsync without this PR, I got error:

PHP Catchable fatal error:  Object of class Closure could not be converted to string

on rsync task for production (but not for dev).
This PR fixes rsync behaviour to force it to actually run all calables before using env variable as string in command.

tagged as 3.0.3

:+1:
2015-06-19 18:18 GMT+02:00 Samuel Gordalina<EMAIL_ADDRESS>
tagged as 3.0.3
—
Reply to this email directly or view it on GitHub
https://github.com/deployphp/recipes/pull/18#issuecomment-113562535.

--
Pozdrawiam,
Hubert Kowalski

Well, it like a bug in Deployer. env must be able to set as callable.

Funny thing is - if I add code for setting rsync_src outside of server
call chain, everything works nice, but acts //globally//. If I set it
inside call chain as in opening example - I see error. I did not have time
to dig in deployer, it was quicker for me to fix recipe :)
2015-06-20 19:00 GMT+02:00 Anton Medvedev<EMAIL_ADDRESS>
Well, it like a bug in Deployer. env must be able to set as callable.
—
Reply to this email directly or view it on GitHub
https://github.com/deployphp/recipes/pull/18#issuecomment-113789875.

--
Pozdrawiam,
Hubert Kowalski


Testing with Jest

Has anyone been able to do this successfully? It isn't entirely clear to me whether Marty should be auto-mocked as much as possible, or if in general it works better to not mock it. Any pointers would be appreciated, and I would be happy to contribute some documentation after I get it working.

We've found you don't need to mock much of Marty for unit testing.
For stores fetches we normally stub the specific method with sinon and return whatever fetch

We've found you don't need to mock much of Marty for unit testing.
For stores fetches we normally stub the specific method with sinon and return a fetch
var fetch = require("marty/fetch");

sinon.stub(UserStore, "getUser").returns(fetch.done({ username: "foo", ... }))

For action creators, we tend to just mock at the state source level.
sinon.stub(UserAPI, "createUser").returns(new Promise(user))

var UserActionCreators = Marty.createActionCreators({
  createUser: function (user) {
    UserAPI.createUser(user).then(onUserCreated)

    function onUserCreated(res) {
      ...
    }
  }
});

I'm going to be writing up some more notes about testing in the next week or two

Thanks James. I ended up getting things working by telling Jest not to mock underscore, util, and marty in package.json. Otherwise, there would be some cryptic error about toString() for a line in the uuid module.
Another error I saw in the process was Marty appearing to be undefined after Jest's automocking --- it turns out the reason here is because in index.js, Marty is assigned via _.extend, hence not mocking underscore. This issue on the jest github page provided the key insight: https://github.com/facebook/jest/issues/201
I definitely look forward some higher-level testing docs, though. Thanks for the good work on marty!

Hey @mohanzhang, would you have some sample code around this? Say, package.json and some code being tested? Thanks :)

+1 to seeing this as well if you've got some time to write it up @mohanzhang

@dariocravero @Rodeoclash Hey guys, sorry it's taken me a while to get back to you. Unfortunately, I can't easily share code examples since this was for my work, but I think this bit of package.json should be helpful:
{
  [...],
  "jest": {
    "rootDir": "./app/assets/javascripts",
    "scriptPreprocessor": "<rootDir>/__tests__/preprocessor.js",
    "moduleFileExtensions": [
      "js",
      "coffee",
      "cjsx"
    ],
    "unmockedModulePathPatterns": [
      "react",
      "react/addons",
      "lodash",
      "jquery",
      "moment",
      "underscore",
      "util",
      "marty"
    ],
    "testFileExtensions": [
      "js",
      "coffee",
      "cjsx"
    ],
    "testPathIgnorePatterns": [
      "preprocessor.js"
    ]
  }
  [...],
}

And once you have Jest set up in this way (preprocessor.js is based on http://facebook.github.io/jest/docs/tutorial-react.html), your tests can be pretty straightforward. Here is an example testing a fictitious Store:
describe 'MyStore', ->
  # imports
  jest.dontMock('../my_store')
  MyStore = require('../my_store')

  React = require('react/addons')
  TestUtils = React.addons.TestUtils

  beforeEach () ->
    MyStore.setState(MyStore.getInitialState())

  describe '#foo', () ->
    it "bars real good", ->
      MyStore.bar(5)  # suppose for this example that this just sets the state, and .foo retrieves the same state
      expect(MyStore.foo()).toEqual(5)

If you set up package.json right, then all the marty stuff inside MyStore should "just work" when you run npm test.

This is awesome, I will add a testing guide to the website based on this
Thanks
James

On 18 Feb 2015, at 7:16 pm, Mohan Zhang<EMAIL_ADDRESS>wrote:
@dariocravero @Rodeoclash Hey guys, sorry it's taken me a while to get back to you. Unfortunately, I can't easily share code examples since this was for my work, but I think this bit of package.json should be helpful:
{
[...],
"jest": {
"rootDir": "./app/assets/javascripts",
"scriptPreprocessor": "/tests/preprocessor.js",
"moduleFileExtensions": [
"js",
"coffee",
"cjsx"
],
"unmockedModulePathPatterns": [
"react",
"react/addons",
"lodash",
"jquery",
"moment",
"underscore",
"util",
"marty"
],
"testFileExtensions": [
"js",
"coffee",
"cjsx"
],
"testPathIgnorePatterns": [
"preprocessor.js"
]
}
[...],
}
And once you have Jest set up in this way (preprocessor.js is based on http://facebook.github.io/jest/docs/tutorial-react.html), your tests can be pretty straightforward. Here is an example testing a fictitious Store:
describe 'MyStore', ->
imports
jest.dontMock('../my_store')
MyStore = require('../my_store')
React = require('react/addons')
TestUtils = React.addons.TestUtils
beforeEach () ->
MyStore.setState(MyStore.getInitialState())
describe '#foo', () ->
it "bars real good", ->
MyStore.bar(5)  # suppose for this example that this just sets the state, and .foo retrieves the same state
expect(MyStore.foo()).toEqual(5)
If you set up package.json right, then all the marty stuff inside MyStore should "just work" when you run npm test.
—
Reply to this email directly or view it on GitHub.

Thanks @mohanzhang :) Looking forward to seeing this on the guides and contributing to it too

This looks great. We're figuring out the Jest tests as well. Has anyone figured out how to test that the remotely part of a get request returns the right data? We would like to call Store.getSomeData() and have a mocked API response be returned. So it's got to go through locally, then remotely, then back in remotely. Any ideas?

@songawee The pattern we adopted involves following the facebook flux diagram pretty closely: https://github.com/facebook/flux
See that Web API offshoot from Action Creators? That's where we're doing all our API work. So in your Store.getSomeData() example, we actually have it so that the component requesting the update fires off an action ActionCreator.requestData(), which might look something like
requestData: () ->
  @dispatch() # in case the store needs to react to an async request having started
  MyAPI.getData()

And inside MyAPI.getData:
getData: () ->
  $.get('/endpoint.json', (result) ->
    SourceActionCreator.receiveData(result)
  )

What is SourceActionCreator? It's just another Action Creator, but it's limited to only those actions that are fired as a result of an API succeeding. The store can then listen to this "receiveData" action and do the appropriate thing.
I know this deviates a little bit from the marty docs, but we have found that marty does not really hinder this pattern in any way, and that it makes for easier testing. We just check that the request and receive actions have the right effects, and test the API portion separately (which we place under sources/ using MyAPI = Marty.createStateSource(...))
This effectively lets us decouple all our external data actions from the rest of our flux app, and we can trust that if the API source is well tested and that the rest of the app is well tested, given that marty is well tested, we can trust that it will all work as advertised. Otherwise, you end up testing bits of marty as well and who wants to test more than they have to, right? ;)

This is pretty much where I wound up as well. I had some trouble testing stores that relied on sources though. A sample test:
it('should create', function () {
    RegistrationsSource.create.mockImplementation(function (details) {
      return {
        'then': function (cb) {
          cb(serverDetails);
          return {
            'catch': function () {}
          }
        }
      }
    });
    store.create(createDetails);
    expect(RegistrationsSource.create).toBeCalledWith(createDetails);
  });

The is testing a create method on a store which calls a source which returns a promise. I wound up mocking the returned promise. I'm quite new to testing with Jest / Flux so in no way is this a suggestion for other people to use!
I think it would be good to start collaborating on a testing page for the documentation, some things I think that would be good in it:

Setting up Jest with Marty, including examples of package.json etc.
Examples of testing stores, in particular the interface between stores / sources and how they should be stubbed out.
Perhaps testing views that use MartyJS components (although so far it looks like standard React view testing, the MartJS components are not imparting any specific behaviour on them aside from the state mixin)

Awesome, thanks @Rodeoclash and @mohanzhang for your responses. We're still looking into how to integrate the state source. Here is what we ended up with:
pit('returns data after an Api fetch', () => {
      return new Promise((resolve, reject) => {

        Api.query.mockImpl(() => Promise.resolve(Response));

        var listener = Store.addChangeListener(function() {
          var value = Store.getData();
          if (value.done) {
            expect(value.result).toBe('data');
            resolve();
            listener.dispose();
          }
        });

        Store.getData();
       });
    });

Initially our store is empty. We call Store.getData() to get the fetch started. The store actually emits two changes (one as the result of an API fetch that returns a promise and one that we call explicitly). We check the value of the fetch in the change listener and only do the expectations when the fetch is done.

Question:
How do you test individual react components that depend on Marty stores, when they have no reference to this.app?
Additionally, I am using require.context to register my Marty stores. Has anyone found a way to test this with jest?

@chapinkapa You need to set up the wrapper/container yourself. You'll need to use Webpack if you want require.context to work.


Add support for multi-tenancy season

Duck season

Flaky Test
Failure Summary
Logs

[chromium] should login with credentials correctly correctly.
The login request to the server failed with a 404 Not Found error.
Logs ↗

[chromium] should show the privacy policy correctly.
The test timed out waiting for the privacy policy to be displayed correctly.
Logs ↗

[chromium] should display error message for invalid login correctly.
The expected HTTP status code 401 was not received, instead a function was returned.
Logs ↗

[chromium] should navigate to the dashboard after login correctly.
The test timed out waiting for the dashboard to be displayed after login.
Logs ↗

... and 1 more

View Full Report ↗ ⋅ Docs


Connection doesn't time out when using SSL

there isn't any error messages. My config.php looks like this (nothing special)
<?php
use Phergie\Irc\Connection;

return [
  'plugins' => [
    new \Phergie\Irc\Plugin\React\Pong\Plugin,
    new \Phergie\Irc\Plugin\React\AutoJoin\Plugin([
      'channels' => '#mybot'
    ]),
  ],

  'connections' => [
    new Connection([
      'serverHostname' => 'wilhelm.freenode.net',
      'username' => 'mybot',
      'realname' => 'irc bot',
      'nickname' => 'mybot',
      'serverport' => 6697,
      'options' => [
        'transport' => 'ssl'
      ]
    ]),
  ]
];

with composer.json
{
    "require": {
        "phergie/phergie-irc-bot-react": "^1.3",
        "phergie/phergie-irc-plugin-react-autojoin": "^1.1",
        "phergie/phergie-irc-plugin-react-feedticker": "^1.0",
        "phergie/phergie-irc-plugin-react-nickserv": "^1.3",
        "phergie/phergie-irc-plugin-react-pong": "^1.1",
        "pschwisow/phergie-irc-plugin-react-altnick": "^1.0"
    }
}

so far i tracked the issue down to https://github.com/reactphp/socket-client/blob/v0.4.4/src/Connector.php#L58 it waits for a write event that never comes. There is already a write event before that so i wonder if the asynchronous nature of things causes some timing problems here.

Closing this as not a Phergie issue since it's react not throwing errors when you use the wrong port numbers for the specified transport

@svpernova09 did you liked to close this issue because you felt you are personally responsible for debugging it? Imo it's ok to leave the issue open, especially since an issue has been filed with the dependency. However it is a phergie issue which seems caused by one of the dependencies. Normally the "parent" issue stays open until a fix in the dependency library and the version has been bumped https://github.com/phergie/phergie-irc-client-react/blob/master/composer.json#L19 By the way, for me it has not entirely be proven yet whether it is indeed a react issue. Also, suppose that react can do a few things without given messages about it phergie could just print to the console a list of possible causes (which would already help the user). Anyway ultimately the decision is yours, but it just strike odd to me as user of the library i experience this issue with phergie

@flip111
The root cause of this issue  is that you were using the incorrect port number for an SSL transport.
I agree 100% that there should be something that gives you some feedback.
For your reported problem of "Connection doesn't time out when using SSL" the solution was "use the correct port number for SSL on Freenode servers".
Feel free to open a new issue with suggestions on how we could improve this and we can have that discussion.
Some suggestions I could offer (Ordered by estimated level of effort):

Add documentation language that instructs the user to double check their connection info including SSL ports
Do some kind of configuration check (think compiler sanity checks) however we would need to do this for more than just Freenode, and that could get out of hand pretty quickly.
Add some kind of timer functionality in the client that tries to detect timeouts. This is probably quite tricky and could be problematic for slower servers.

An aside:
I'm sorry if I'm coming across as difficult. I'm genuinely trying to make sure we're aware of root causes and fixes. I'm not a fan of leaving issues open ended. If we're waiting on an upstream fix from a dependency or even a compiler I think we're better served putting that issue in documentation where it makes sense and not letting an open issue rot for months/years.

I'm hoping to get some response on the react issue i opened, i was planning to come up with a way how to improve this after i actually understand what's going on. So hopefully someone from react can help me understand the code and so can improve this library


Any updates ?

Just discovered Hydra, thank you for creating this, Netty scared me and I didn't wanted to use it as is.
Last update was made 2 months ago, and i'm pretty sad if this project has been abandonned.
Are you planning to continue on maintaining this project ?
Thank you.

Hello @aroooo, I'm quite happy that Hydra is being helpful for you. It's nice to hear that the actual intent for the project seems to have worked! Unfortunately the project has been quite abandoned the past months. But your question actually did motivate me to again start working with the project.
I fixed some of the examples and enhanced them. There still is issue #2 that needs to be implemented, as UDP support is something quite crucial actually. I'm going to try to work on that matter and keep this project alive ^.^

Thank you for your reply! Looking forward to see the improvements 😄


WIP: Fix wallet initialization

7fb42e1 changes the order of how the wallet is loaded. Before it would load the network, load the disk wallet, and then catch up on the blockchain (if any steps failed, the subsequent steps would not be performed) . If loading the network failed, the wallet would never be loaded (we can still query the wallet for balance, and transactions even if not connected to the network).
Now we load the disk wallet first, load the network, and than catch up on the blockchain so that the wallet is always loaded regardless of if the network loaded.
dafb8f1 fixes cmd_runner so that it would always get loaded upon call. This patch is also needed for lbryum password entry for encryption.

LGTM.  Since this is a fork, can you make sure that tests / linting pass.

This will need to be redone since https://github.com/lbryio/lbry/pull/331 changes a lot of the wallet code

Closing as replaced by new pull request


Switch to using boringssl rather than system OpenSSL. [phab:D1196]

Created by shahms at 2016-12-27 20:59:16:
This removes the un-used gRPC dependency and switches to using base64.h rather than the BIO routines (as those aren't linked in).

zarko wrote at 2016-12-27 22:11:34:
Checked the C++ tests on OSX as well.

zarko accepted this revision at 2016-12-27 22:11:34

shahms closed via commit d01c952068eb4586ec9a60d2b570d83afc4bb403 at 2016-12-27 22:49:34


[Bug] share link mask haven't prompts

When share link mask with 4 prompts like user or assistant is not possible reuse with share link public because that 4 prompts not there
Copy and paste share link mask and try to view if prompts is there ...
Share link have original prompts
VERCEL DEPLOY

That is not possible, because we dont have a database to store prompts, you have to add the mask to the code base, so that you can share it as a link.


OSSL_DECODER_CTX_new_by_EVP_PKEY OSSL_ENCODED_CTX_new_by_EVP_PKEY

These API names aren't following the consistent pattern.
Using _new_by is not the right approach. We have _new_from when constructing something.
e.g. EVP_PKEY_CTX_new_from_pkey
The APIs should be renamed to following that pattern.
And yes there is another use of new_by in EC_KEY_new_by_curve_name but that isn't the same sort of thing.
In English usage terms all the new_by should be new_from IMHO - but certainly the newly added APIs should be following the main naming convention already in use.

For starters, I agree that "by" wasn't the best choice.
Function like EVP_PKEY_CTX_new_from_pkey have "from" in them because they do something (create something new) from existing data (some input parameter, like a pkey), and while one could arguably have OSSL_ENCODER_CTX_new_from_pkey, the same kind of thinking doesn't quite fit for decoder variant, since it doesn't create the DECODER_CTX from existing pkey data.
The name choices for these two functions was made to strongly associate with the type of the intended input / output.

Should the names be OSSL_DECODER_CTX_new_for_pkey and OSSL_ENCODER_CTX_new_from_pkey then?

OTC: If we keep combined function then use for; but prefer to move into two functions then use setup_for for the new function.


#2266 Custom port images

Fixes: #2266
Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

I fixed the Network diagram problem -- thanks for trying that I had missed it. The code now sets default width and height for port images or guide images if they are missing from the application's node layout fields.


a bug in the method ChassisExist

Expected Behavior
when the chassis not exist, the method ChassisExist return false
Actual Behavior
the method ChassisExist return true
Steps to Reproduce the Problem
if the output is a empty str, the method will return true, because len(strings.Split(output, "\n")) is 1, not 0.

Additional Info

Kubernetes version:
Output of kubectl version:
(paste your output here)

kube-ovn version:

v1.11.3

- operation-system/kernel version:

**Output of `awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release`:**
**Output of `uname -r`:**

(paste your output here)

<!-- Any other additional information -->

Could you please commit a PR to fix it?


Schema limits HTTP Compress bufferSize to smaller max than permitted on BIG-IP

Environment

Application Services Version: 3.18.0
BIG-IP Version: <IP_ADDRESS>

Summary
AS3 Schema doesn't permit what's allowed in BIG-IP. HTTP Compression buffer size in BIG-IP permits buffer size 0 -<PHONE_NUMBER> ... AS3 Schema limits at 32768. Prohibits migrating large value buffersizes to AS3 model.
AS3 HTTP_Compress Schema Link:
https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/3.19/refguide/schema-reference.html#http-compress
...
bufferSize (integer) 	4096 	[256, 32768] 	Maximum number of response octets to buffer before deciding whether to apply compression (default 4096)
...
Steps To Reproduce
Steps to reproduce the behavior:

Submit the following declaration:

    {
        "class": "AS3",
        "action": "deploy",
        "declaration": {
            "class": "ADC",
            "schemaVersion": "3.18.0",
            "target": {
                "address": "<IP_ADDRESS> "
            },
            "app_1": {
                "class": "Tenant",
                "app_1": {
                    "class": "Application",

                    "template": "http",
                    "serviceMain": {
                        "virtualPort": 80,

                        "virtualAddresses": [
                            "<IP_ADDRESS>"
                        ],
                        "pool": "Pool",
                        "enable": true,

                        "iRules": [],
                        "class": "Service_HTTP",
                        "profileHTTPCompression":{
                            "use": "compress_profile"
                        }

                    },

                    "Pool": {
                        "members": [
                            {
                                "servicePort": 80,
                                "adminState": "enable",
                                "serverAddresses": [
                                    "<IP_ADDRESS>"
                                ]
                            }
                        ],
                        "monitors": [
                            "http"
                        ],
                        "class": "Pool"
                    },

                    "compress_profile":{
                        "bufferSize": 128000,
                        "class": "HTTP_Compress"
                    }
                }
            }
        }
    }

Observe the following error response. Check Task Status ... Fails, constrains to Schema. Schema should adapt to BIG-IP:

{
    "id": "7f952f89-552e-45a0-8e2f-389eb8c337f2",
    "results": [
        {
            "code": 422,
            "errors": [
                "/app_1/app_1/compress_profile/bufferSize: should be <= 32768"
            ],
            "declarationFullId": "",
            "message": "declaration is invalid"
        }
    ],
    "declaration": {}
}

Expected Behavior
Permit values in AS3 permitted by BIG-IP.
Actual Behavior
Schema enforces a lower max value than accepted on BIG-IP.

Thank you for reporting this. It is being tracked in our internal product backlog as AUTOTOOL-1626

This has been resolved as part of the 3.21.0 release.


content types the second

A ContentType/MediaType/Accept of / should always succeed and pick the first type offered in the list (if not otherwise prioritized).
Example:

% In the header
{'Accept',<<"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8">>}

%Trying to match and failing:
{{<<"*">>,<<"*">>,[]},800,[]} =/= {{<<"application">>,<<"json">>,[]},to_json}

Thought I did, but probably forgot a clause.

So fixed I guess.


File middleware should set endpoint if it hits a file

I've now changed this, to only report FileMiddleware as the source. I was told FileMiddleware should probably not use the file name as a span name, it has a high cardinality problem and exposes too much information.
I have also added setting the endpoint path as you enter a RouterGroup, so if a middleware throws an error you have some router info


Unsatisfied dependency while using sleuth otel

I want to implement distributed tracing using sleuth-otel
Our apps are hosted in GKE, Currently we implemented that using spring-cloud-sleuth-core-2.2.7.RELEASE and spring-cloud-gcp-starter-trace -1.2.7.RELEASE It is working fine and we are getting traceId exported to GCP Trace API. But we want to upgrade this feature using sleuth-otel.
My question is, is it possible to export traceId to GCP trace API using sleuth-otel ?
If yes, can you tell me what did i miss. These are my changes,
            <dependency>             <groupId>org.springframework.cloud</groupId>             <artifactId>spring-cloud-starter-sleuth</artifactId>             <exclusions>                 <exclusion>                     <groupId>org.springframework.cloud</groupId>                     <artifactId>spring-cloud-sleuth-brave</artifactId>                 </exclusion>             </exclusions>         </dependency>         <dependency>             <groupId>org.springframework.cloud</groupId>             <artifactId>spring-cloud-sleuth-otel-autoconfigure</artifactId>             <version>1.0.0-M7</version>      </dependency>      <dependencyManagement>         <dependencies>             <dependency>                 <groupId>org.springframework.cloud</groupId>                 <artifactId>spring-cloud-dependencies</artifactId>                 <version>2020.0.0</version>                 <type>pom</type>                 <scope>import</scope>             </dependency>             <dependency>                 <groupId>org.springframework.cloud</groupId>                 <artifactId>spring-cloud-sleuth-otel-dependencies</artifactId>                 <version>1.0.0-M7</version>                 <type>pom</type>             </dependency>         </dependencies>     </dependencyManagement>
also i added the below in application.properties
spring.application.name=app-name spring.sleuth.otel.log.exporter.enabled=true spring.sleuth.otel.log.slf4j.enabled=true
Build gets succeed but while running the app i got error like this,

APPLICATION FAILED TO START

Description:
The bean 'httpClientBeanPostProcessor', defined in class path resource [org/springframework/cloud/sleuth/instrument/web/client/TraceWebClientAutoConfiguration$NettyConfiguration.class], could not be registered.
A bean with that name has already been defined in class path resource [org/springframework/cloud/sleuth/autoconfig/instrument/web/client/TraceWebClientAutoConfiguration$NettyConfiguration.class] and overriding is disabled.
Action:
Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true
And this is my mvn dependency:tree
[INFO] +- org.springframework.cloud:spring-cloud-starter-sleuth:jar:2.2.7.RELEASE:compile
[INFO] |  +- org.springframework.cloud:spring-cloud-starter:jar:2.2.7.RELEASE:compile
[INFO] |  |  +- org.springframework.cloud:spring-cloud-context:jar:2.2.7.RELEASE:compile
[INFO] |  |  |  - org.springframework.security:spring-security-crypto:jar:5.3.6.RELEASE:compile
[INFO] |  |  +- org.springframework.cloud:spring-cloud-commons:jar:2.2.7.RELEASE:compile
[INFO] |  |  - org.springframework.security:spring-security-rsa:jar:1.0.9.RELEASE:compile
[INFO] |  |     - org.bouncycastle:bcpkix-jdk15on:jar:1.64:compile
[INFO] |  |        - org.bouncycastle:bcprov-jdk15on:jar:1.64:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter-aop:jar:2.3.7.RELEASE:compile
[INFO] |  |  - org.aspectj:aspectjweaver:jar:1.9.6:compile
[INFO] |  - org.springframework.cloud:spring-cloud-sleuth-core:jar:2.2.7.RELEASE:compile
[INFO] |     +- org.aspectj:aspectjrt:jar:1.9.6:compile
[INFO] |     +- io.zipkin.brave:brave:jar:5.12.7:compile
[INFO] |     |  - io.zipkin.reporter2:zipkin-reporter-brave:jar:2.15.2:compile
[INFO] |     +- io.zipkin.brave:brave-context-slf4j:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-messaging:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-rpc:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-spring-web:jar:5.12.7:compile
[INFO] |     |  - io.zipkin.brave:brave-instrumentation-http:jar:5.12.7:compile	----
[INFO] |     +- io.zipkin.brave:brave-instrumentation-spring-rabbit:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-kafka-clients:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-kafka-streams:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-httpclient:jar:5.12.7:compile		----
[INFO] |     +- io.zipkin.brave:brave-instrumentation-httpasyncclient:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-spring-webmvc:jar:5.12.7:compile
[INFO] |     |  - io.zipkin.brave:brave-instrumentation-servlet:jar:5.12.7:compile
[INFO] |     +- io.zipkin.brave:brave-instrumentation-jms:jar:5.12.7:compile
[INFO] |     - io.zipkin.reporter2:zipkin-reporter-metrics-micrometer:jar:2.15.2:compile
[INFO] |        +- io.zipkin.reporter2:zipkin-reporter:jar:2.15.2:compile
[INFO] |        - io.zipkin.zipkin2:zipkin:jar:2.21.7:compile
[INFO] |  +- org.springframework.cloud:spring-cloud-sleuth-otel-autoconfigure:jar:1.0.0-M7:compile
[INFO] |  +- org.springframework.cloud:spring-cloud-sleuth-autoconfigure:jar:3.0.3-SNAPSHOT:compile
[INFO] |  +- org.springframework.cloud:spring-cloud-sleuth-instrumentation:jar:3.0.3-SNAPSHOT:compile
[INFO] |  |  - org.springframework.cloud:spring-cloud-sleuth-api:jar:3.0.3-SNAPSHOT:compile
[INFO] |  +- org.springframework.cloud:spring-cloud-sleuth-otel:jar:1.0.0-M7:compile
[INFO] |  |  - io.opentelemetry:opentelemetry-extension-aws:jar:1.0.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-api:jar:1.0.0:compile
[INFO] |  |  - io.opentelemetry:opentelemetry-context:jar:1.0.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-semconv:jar:1.0.1-alpha:compile
[INFO] |  +- io.opentelemetry:opentelemetry-sdk-common:jar:1.0.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.0.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-sdk:jar:1.0.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.0.1-alpha:compile
[INFO] |  +- io.opentelemetry.instrumentation:opentelemetry-instrumentation-api:jar:1.0.1-alpha:compile
[INFO] |  - io.opentelemetry:opentelemetry-extension-trace-propagators:jar:1.0.0:compile
[INFO] +- org.springframework.boot:spring-boot:jar:2.3.7.RELEASE:compile
I observed one thing, spring-cloud-starter-sleuth also uses spring-cloud-sleuth-core internally. Do we really need this ?
If i exclude the 'spring-cloud-sleuth-core`
that error has gone and i got the traceID in logs as follows
INFO[app-name,608ff343d205770232bd9a6e50779e6c,608fbb6aeca362ce3120ba18f3b874a3]
which doesn't have exporter flag.
Also in this case that traceId gets propogated along the apps and i saw same same traceID in the entire flow same as above(without exporter flag).
So that traces are not getting exported to GCP. Can you tell me did i miss anything in the above scenario or do i need to add any other dependencies along with the above one to make it export to GCP. Otherwise, do i need to create any beans for exporting.
Thanks in Advance :)

I don't believe it's compatible with sleuth 2.x and gcp 1.x.

Yes, it's not compatible

Oh is it. Then cannot we export traces to GCP using sleuth otel ? or Which versions of otel supports GCP


Fix metric values of pagefile total and pagefile free

This pull request fixes incorrect calculations for memory statistics on Windows. We shouldn't divide pagefile values in bytes.

I'm sorry, I didn't understand what value it have to return in first implementation.
https://github.com/mackerelio/mackerel-agent/commit/1d98e61ffe5a14f3eb45ceb65d5352174b5863d2#diff-969afae1d4334413594ec5c79885e910R32


Automated cherry pick of #5225: Upgrade OVS to 2.17.7

Cherry pick of #5225 on release-1.10.
#5225: Upgrade OVS to 2.17.7
For details on the cherry pick process, see the cherry pick requests page.

/skip-all

Closing this. There is a Kind test failure because of a known issue, and I don't think we are maintaining 1.10 any more.


Remove Dependent Question section from Page Layout[BUG]

Describe the bug
Remove Dependent question section from Page Layout before newest release as feature is not built out.

Go to create a new Custom Questions
Scroll down to the section labeled Dependent Question section

@dwhitig THis is being removed from the page layout and has help text and descripting with the following note: NOTE: Functionality doesn't currently exist and is on the roadmap.


Make cargo metadata --no-deps print all path deps (including other workspaces)

Yet another solution to #7483. (See also #8988, #8994.)
This solution avoids users to get all the information they need with a single cargo invocation, rather than having to recursively call cargo themselves.
The first commit implements the functionality, and the second speeds it up to the point of feasibility, at the cost of some code complexity.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks for the PR!  We discussed this in the team meeting, and decided to move forward with #8994 for now, and to put this on hold.  There are some concerns noted in https://github.com/rust-lang/cargo/pull/8994#issuecomment-754155562 that this may not be so straightforward.  @alyssais will #8994 address what you are interested in? I'm fine with leaving this PR open for now if you'd like, until we have more experience with #8994 to see how the performance is.

Thanks for the PR!  We discussed this in the team meeting, and decided to move forward with #8994 for now, and to put this on hold.  There are some concerns noted in https://github.com/rust-lang/cargo/pull/8994#issuecomment-754155562 that this may not be so straightforward.  @alyssais will #8994 address what you are interested in? I'm fine with leaving this PR open for now if you'd like, until we have more experience with #8994 to see how the performance is.

@alyssais will #8994 address what you are interested in? I'm fine with
leaving this PR open for now if you'd like, until we have more
experience with #8994 to see how the performance is.

Let me share a little about my use case:
I'm working on tooling to provide better packaging of Cargo projects in
Nixpkgs.  Part of this is that given a git checkout that I know contains
the crate I'm interested in, find the Cargo.toml for that crate.  I
figure "look up the Cargo.toml for a local crate given its name and
version" is probably something that would be useful for lots of tooling
built on Cargo -- I don't think it matters to users what workspace it's
in, as long as it's a local (path-only) dependency somewhere in the
dependency graph, and this seems to mirror what the rustfmt people in
#8994 say is their use case too.
#8994 certainly makes it possible for me to find this information, but
in a very roundabout way.  First, I'm going to now need to call Cargo
once per workspace to hunt for my crate until I find it, which doesn't
sound so bad, except that there's no way to actually get a list of local
workspaces, so now I have to construct that.  And constructing that is
very complicated, because I have to iterate over the dependencies, and
run cargo metadata on those to discover their dependencies, recursively.
And to do this at all efficiently, I have to keep a cache of which
workspaces I've visited, so when I visit them again I don't iterate
through all of their dependencies over and over again.
And now what was a simple cargo | jq shell pipeline becomes a custom
program that I have to write and maintain, and I have to think about
recursion and caching and get that all right.  And rustfmt, seperately,
also has to do all those things.  And the next tool that wants to
operate on an entire local project also has to do all these things.
And lots of neat things probably just can't happen, because if I want to
write a quick shell script or something to loop through all my local
crates, there's just no way to do that.  This is something I've wanted
to do before and given up on because the complexity of having to write
that code myself for a one-off is just too high.
So #8994 makes it possible to do this, but it doesn't make it
accessible.  It'll be fine for me, since the problem I want to solve is
very important for us and I can spend a great deal of time implementing
all the fiddly logic correctly.  I didn't have to implement this in
Cargo -- my reasons for doing so were partially that Cargo already has
types and stuff for this, but mostly because there's a clear need from
other people for the same functionality and I wanted it to be easily
accessible to them as well.  And so even though it sounds like I will
have to go and write that program, I would still like to see Cargo offer
a way to do this to prevent different people having to figure out the
same complicated tree-walking code over and over again.
Other things Cargo could do to enable this:

Provide a way to print all local workspaces.  That turns a tree
traversal into a simple iteration.  But I don't know where it would
fit into the Cargo CLI, whereas the approach in this PR felt very
natural.

Create a new mode for cargo metadata, maybe cargo metadata
--local-workspaces or something.  I'll admit it's a bit strange to
include local dependencies when a flag called --no-deps is given, and
I actually thought about proposing to rename it to --no-remote-deps or
something.

@alyssais will #8994 address what you are interested in? I'm fine with
leaving this PR open for now if you'd like, until we have more
experience with #8994 to see how the performance is.

Let me share a little about my use case:
I'm working on tooling to provide better packaging of Cargo projects in
Nixpkgs.  Part of this is that given a git checkout that I know contains
the crate I'm interested in, find the Cargo.toml for that crate.  I
figure "look up the Cargo.toml for a local crate given its name and
version" is probably something that would be useful for lots of tooling
built on Cargo -- I don't think it matters to users what workspace it's
in, as long as it's a local (path-only) dependency somewhere in the
dependency graph, and this seems to mirror what the rustfmt people in
#8994 say is their use case too.
#8994 certainly makes it possible for me to find this information, but
in a very roundabout way.  First, I'm going to now need to call Cargo
once per workspace to hunt for my crate until I find it, which doesn't
sound so bad, except that there's no way to actually get a list of local
workspaces, so now I have to construct that.  And constructing that is
very complicated, because I have to iterate over the dependencies, and
run cargo metadata on those to discover their dependencies, recursively.
And to do this at all efficiently, I have to keep a cache of which
workspaces I've visited, so when I visit them again I don't iterate
through all of their dependencies over and over again.
And now what was a simple cargo | jq shell pipeline becomes a custom
program that I have to write and maintain, and I have to think about
recursion and caching and get that all right.  And rustfmt, seperately,
also has to do all those things.  And the next tool that wants to
operate on an entire local project also has to do all these things.
And lots of neat things probably just can't happen, because if I want to
write a quick shell script or something to loop through all my local
crates, there's just no way to do that.  This is something I've wanted
to do before and given up on because the complexity of having to write
that code myself for a one-off is just too high.
So #8994 makes it possible to do this, but it doesn't make it
accessible.  It'll be fine for me, since the problem I want to solve is
very important for us and I can spend a great deal of time implementing
all the fiddly logic correctly.  I didn't have to implement this in
Cargo -- my reasons for doing so were partially that Cargo already has
types and stuff for this, but mostly because there's a clear need from
other people for the same functionality and I wanted it to be easily
accessible to them as well.  And so even though it sounds like I will
have to go and write that program, I would still like to see Cargo offer
a way to do this to prevent different people having to figure out the
same complicated tree-walking code over and over again.
Other things Cargo could do to enable this:

Provide a way to print all local workspaces.  That turns a tree
traversal into a simple iteration.  But I don't know where it would
fit into the Cargo CLI, whereas the approach in this PR felt very
natural.

Create a new mode for cargo metadata, maybe cargo metadata
--local-workspaces or something.  I'll admit it's a bit strange to
include local dependencies when a flag called --no-deps is given, and
I actually thought about proposing to rename it to --no-remote-deps or
something.

I've just run into a problem that is very similar to what @alyssais solved with this PR. Do you have any thoughts regarding rethinking the decision you took here?
I also want to known the path of a given workspace member within a hermetic build.

:umbrella: The latest upstream changes (presumably #10269) made this pull request unmergeable. Please resolve the merge conflicts.

Since https://github.com/rust-lang/cargo/pull/8994 has landed, I think this PR can be closed.

Since #8994 has landed, I think this PR can be closed.

As I've already explained at great length, #8994 does not fully solve the problem.


Remove units from (translated) labels

To my understanding, units (A, W, km) should not be part of the entity label, but are configured by the entity itself and displayed next to the actual value (250 km).
So, for example polestar_estimate_distance_to_empty_miles and polestar_estimate_distance_to_empty_km should have a label of "Distance remaining" (or "Range"), because the actual unit (km or Miles) is displayed next to the value.

To my understanding, units (A, W, km) should not be part of the entity label, but are configured by the entity itself and displayed next to the actual value (250 km).
So, for example polestar_estimate_distance_to_empty_miles and polestar_estimate_distance_to_empty_km should have a label of "Distance remaining" (or "Range"), because the actual unit (km or Miles) is displayed next to the value.

but the entity name should be unique otherwise it can show only the first entity

Well the distance should be the same, so we should be able to use just one of the attributes and leave the conversion to home assistant

I also considered this. Currently the entities are 1:1 mapped from the Polestar API response, but it makes sense to provide an additional entity (like polestar_estimate_distance_to_empty) that is automatically mapped to  polestar_estimate_distance_to_empty_miles or polestar_estimate_distance_to_empty_km depending on the configured unit system.

Some entities became unknown?
e.g. _estimate_distance_to_empty_km, _estimate_full_charge_range (in KM). My HA runs in metric

whic version are you using?

just updated to 1.2.9

@ScooterisT5 did you see something in the log?

No, since the update nothing in the log.
Before it was like this, but i am sorry, i do not know which version it was before.
Logger: homeassistant.components.sensor.recorder
Source: components/sensor/recorder.py:204
Integration: Sensor (documentation, issues)
First occurred: 15:25:10 (3 occurrences)
Last logged: 15:25:10
The unit of sensor.polestar_XXXX_estimate_distance_to_empty_miles is changing, got multiple {'mi', 'miles'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (miles). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
The unit of sensor.polestar_XXXX_average_energy_consumption_kwh_per_100_km is changing, got multiple {'Kwh/100km', 'kWh/100km'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (Kwh/100km). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
The unit of sensor.polestar_XXXX_estimate_full_charge_range_miles is changing, got multiple {'mi', 'miles'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (miles). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this

Am 01.01.2024 um 19:48 schrieb Tuen Lee @.***>:
@ScooterisT5 https://github.com/ScooterisT5 did you see something in the log?
—
Reply to this email directly, view it on GitHub https://github.com/leeyuentuen/polestar_api/issues/49#issuecomment-1873436161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBPG27YVNRDT5B2BOHTYMMAHBAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQZTMMJWGE.
You are receiving this because you were mentioned.

No, since the update nothing in the log. Before it was like this, but i am sorry, i do not know which version it was before. Logger: homeassistant.components.sensor.recorder Source: components/sensor/recorder.py:204 Integration: Sensor (documentation, issues) First occurred: 15:25:10 (3 occurrences) Last logged: 15:25:10 The unit of sensor.polestar_XXXX_estimate_distance_to_empty_miles is changing, got multiple {'mi', 'miles'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (miles). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this The unit of sensor.polestar_XXXX_average_energy_consumption_kwh_per_100_km is changing, got multiple {'Kwh/100km', 'kWh/100km'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (Kwh/100km). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this The unit of sensor.polestar_XXXX_estimate_full_charge_range_miles is changing, got multiple {'mi', 'miles'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (miles). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
…
Am 01.01.2024 um 19:48 schrieb Tuen Lee @.***>: @ScooterisT5 https://github.com/ScooterisT5 did you see something in the log? — Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBPG27YVNRDT5B2BOHTYMMAHBAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQZTMMJWGE. You are receiving this because you were mentioned.

this is just on developer settings -> statistics -> search for polestar entity and fix the miles and km issue

All fine in statistics, still „unknown“ after reboot

Am 01.01.2024 um 19:58 schrieb Tuen Lee @.***>:
No, since the update nothing in the log. Before it was like this, but i am sorry, i do not know which version it was before. Logger: homeassistant.components.sensor.recorder Source: components/sensor/recorder.py:204 Integration: Sensor (documentation, issues) First occurred: 15:25:10 (3 occurrences) Last logged: 15:25:10 The unit of sensor.polestar_XXXX_estimate_distance_to_empty_miles is changing, got multiple {'mi', 'miles'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (miles). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this The unit of sensor.polestar_XXXX_average_energy_consumption_kwh_per_100_km is changing, got multiple {'Kwh/100km', 'kWh/100km'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (Kwh/100km). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this The unit of sensor.polestar_XXXX_estimate_full_charge_range_miles is changing, got multiple {'mi', 'miles'}, generation of long term statistics will be suppressed unless the unit is stable and matches the unit of already compiled statistics (miles). Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
… x-msg://2/#
Am 01.01.2024 um 19:48 schrieb Tuen Lee @.***>: @ScooterisT5 https://github.com/ScooterisT5 https://github.com/ScooterisT5 did you see something in the log? — Reply to this email directly, view it on GitHub <#49 (comment) https://github.com/leeyuentuen/polestar_api/issues/49#issuecomment-1873436161>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBPG27YVNRDT5B2BOHTYMMAHBAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQZTMMJWGE. You are receiving this because you were mentioned.
this is just on developer settings -> statistics -> search for polestar entity and fix the miles and km issue
—
Reply to this email directly, view it on GitHub https://github.com/leeyuentuen/polestar_api/issues/49#issuecomment-1873439360, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBPZX4CADOMAXIPEKS3YMMBMDAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQZTSMZWGA.
You are receiving this because you were mentioned.

ok, could you start debugging mode (1min) in the polestar_api, and send me the debug log?

I see the same in version 1.2.9. I have a long range and you may be right about the 600km. If I look at the polestar site it is reporting 1018km remaining:

i'll update them to 660km instead of 600 because the WLTP is around 655,
I think this is more a bug on polestar side, so I'm not planning to fix this I think. I put a maximum on it, to prevent issue that you see on the screenshot where it spike to 2000km:

ok, could you start debugging mode (1min) in the polestar_api, and send me the debug log?
ah wait the value _estimate_full_charge_range, could it be that you have a long range version? i've put something that the value could not be more then 600km or 400miles. could be that issue maybe

Ah, sorry just went back to 1.2.1, which is fine.
And yes it is a  LRDM
Ha, but very lovely in 1.2.1 it shows a range in KM by a soc of 51% a remaining range of 1018KM - a dream came true ;-)

Is it a coincidence? both having 1018km? seems a bug on polestar

Defently a Polestar bug.

I agree, this also happens sometimes in former versions of the app.
Just now i opened the app to check what it is showing, and now it is also corrected in the polestar_api.
But now VIN, and License plate got unknown, weird

Am 01.01.2024 um 20:25 schrieb Tuen Lee @.***>:
Is it a coincidence? both having 1018km? seems a bug on polestar
—
Reply to this email directly, view it on GitHub https://github.com/leeyuentuen/polestar_api/issues/49#issuecomment-1873448384, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBNDYL3WF6ZYU2JOCZDYMMESXAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQ2DQMZYGQ.
You are receiving this because you were mentioned.

I agree, this also happens sometimes in former versions of the app. Just now i opened the app to check what it is showing, and now it is also corrected in the polestar_api. But now VIN, and License plate got unknown, weird
…
Am 01.01.2024 um 20:25 schrieb Tuen Lee @.***>: Is it a coincidence? both having 1018km? seems a bug on polestar — Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBNDYL3WF6ZYU2JOCZDYMMESXAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQ2DQMZYGQ. You are receiving this because you were mentioned.

if you are on the old version, that vin license issue is known, should fix in the latest version

OK, done - now it shows correctly in 1.2.9
Sorry for the alert
So, if the range is not shown as expected, maybe just open the polestar app to trigger update from car, instead of CD reset.

Am 01.01.2024 um 20:31 schrieb Tuen Lee @.***>:
I agree, this also happens sometimes in former versions of the app. Just now i opened the app to check what it is showing, and now it is also corrected in the polestar_api. But now VIN, and License plate got unknown, weird
… x-msg://4/#
Am 01.01.2024 um 20:25 schrieb Tuen Lee @.***>: Is it a coincidence? both having 1018km? seems a bug on polestar — Reply to this email directly, view it on GitHub <#49 (comment) https://github.com/leeyuentuen/polestar_api/issues/49#issuecomment-1873448384>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBNDYL3WF6ZYU2JOCZDYMMESXAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQ2DQMZYGQ. You are receiving this because you were mentioned.
if you are on the old version, that vin license issue is known, should fix in the latest version
—
Reply to this email directly, view it on GitHub https://github.com/leeyuentuen/polestar_api/issues/49#issuecomment-1873450311, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK47FBJUFSHT7MU6V27MZBTYMMFJFAVCNFSM6AAAAABBGW5OX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQ2TAMZRGE.
You are receiving this because you were mentioned.

I updated to 1.2.9. The good news is that the model, registration, and VIN now consistently show. The bad news is that all other values disappear after some time and then only re-appear after a reload of the integration.

@m0wlheld  i think something like this: where all the miles are gone

I updated to 1.2.9. The good news is that the model, registration, and VIN now consistently show. The bad news is that all other values disappear after some time and then only re-appear after a reload of the integration.

did you saw something in the log? there is a version 1.3.1. maybe take a look there? it could something with polestar server issue.

Two related message in the log:
Read Timeout on update data
19:58:57 – (WARNING) Polestar API (custom integration) - message first occurred at 02:29:19 and shows up 3 times
and
522: undefined
17:13:22 – (ERROR) Polestar API (custom integration)
The timing of that first entry 02:29:19 and 19:58:57 is when the values go 'Unknown'. At 17:13:22 all seemed ok.
I will update to 1.3.1. now.

same issue here: https://github.com/leeyuentuen/polestar_api/issues/43#issuecomment-1874027435
should be the issue of one of the ip that give issue.

The PR went to far and removed units from entity names, where they need to stay, like polestar_6291_average_energy_consumption_kwh_per_100_km changed to polestar_6291_average_energy_consumption_kwh_per_100 . It should to my understanding stay at polestar_6291_average_energy_consumption_kwh_per_100_km or be polestar_6291_average_energy_consumption with a unit of kWh/100km
The Polestar API does AFAIK not report a kWh/100mil equivalent.

i'm using all of them KM and just convert them to miles.
so for the average consuming in miles will it be /100mil. not sure if they want this or not.

i'm using all of them KM and just convert them to miles. so for the average consuming in miles will it be /100mil. not sure if they want this or not.

unterstood. So kwh_per_100 makes sense.
Any change to remove _watts and _amps from charging_power_watts and charging_current_amps? Btw: I did not see any values from these sensors when my car was charging at my AC-wallbox. Are they for DC charging only?

The watt and amp I'll change later,
but this sensor:

I've put them as not supported yet, but maybe the feature will contain value.

take a look at this beta: https://github.com/leeyuentuen/polestar_api/releases/tag/1.3.9

@m0wlheld  can you check if it is now correct before I release?


not able configure pypy3 in vscode

Environment data
Version: 1.55.2 (user setup)
Commit: 3c4e3df9e89829dce27b7b5c24508306b151f30d
Date: 2021-04-13T09:35:57.887Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19042

Extension version (available under the Extensions sidebar): v2021.4.765268190
Python version (& distribution if applicable, e.g. Anaconda): latest pypy3
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pypy3
Value of the python.languageServer setting: Pylance

[NOTE: If you suspect that your issue is related to the Microsoft Python Language Server (python.languageServer: 'Microsoft'), please download our new language server Pylance from the VS Code marketplace to see if that fixes your issue]
Expected behaviour

add pypy3 env in new terminal command prompt

Actual behaviour

Nothing happens

Steps to reproduce:

open vscode.
try adding pypy3.exe as interpreter from filesystem path.
Nothing happens

[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

XXX

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

@gokulyc Can you try with python.useIsolation: false in your VS Code settings for container? See if that helps.

I am suspecting this is caused by https://github.com/microsoft/vscode-python/issues/15960 which is an issue with pypy itself. We have added a mitigation which will be available in the next release or if you needed it sooner try the insider version of the python extension. You can always download and install latest insiders build form here https://pvsc.blob.core.windows.net/extension-builds/ms-python-insiders.vsix .

Should be fixed with https://github.com/microsoft/vscode-python/pull/15968

Excuse-me for the question: is it already in published VSCode & vscode-python  ?

@stonebig This is in the latest release of the extension v2021.5.842923320

hum, in extension of today, if I have parametrized "settings.json" like this
{
"python.interpreterPath": "${env:WINPYDIR}\\\\pypy3.exe",
"jupyter.widgetScriptSources": [
"jsdelivr.com",
"unpkg.com"
],
}

.... pypy3.exe is not said "found"

so, to summarize:

the patch https://github.com/microsoft/vscode-python/pull/15968 may have solve a running compatibility issue
but the auto-detection (of pypy3.exe, the executable name on windows), is not working well.

we don't detect pypy3.exe automatically. We handle it if user provides it via entering the path. This would be a feature request to automatically detect pypy distributions. Please file a feature request for this.


Update policies.rst

@KLuuKer  please review

Shouldn't that be
#if NET451
        public static readonly Task CompletedTask = Task.FromResult(0);
#else
        public static readonly Task CompletedTask = Task.CompletedTask;
#endif

I'm don't work at the death star company but that aside
:shipit:

@spboyer  please review.


DateRangePicker do not display result in inputs for luxon adapter

Environment

Tech
Version

@material-ui/pickers
4.0.0-alpha5

material-ui

TypeScript

React

Browser

Peer library
<EMAIL_ADDRESS>

Steps to reproduce
Open live example & try to change luxon date range
Result is applied but not displayed in inputs
Expected behavior
Display selected range in inputs
Actual behavior
No visible result for luxon only n
Live example
https://codesandbox.io/s/determined-star-yb0hq?file=/index.js

Exact same issue for dayjs adapter


Schema is not up-to-date

With update to
'@autorest/modelerfour' (4.2.75->4.2.75) & @autorest\core\dist' (3.0.6162) we are getting tabDelimited style in http parameter.
        protocol: !<!Protocols>
          http: !<!HttpParameter>
            in: query
            style: tabDelimited

It's not represented in schema:
https://github.com/Azure/perks/blob/master/codemodel/.resources/all-in-one/json/code-model.json#L2016

fixed
https://github.com/Azure/perks/blob/master/codemodel/.resources/all-in-one/yaml/code-model.yaml#L1849


Stop running hooks on pr merge

Alternative fix for #6946
This just removes the final SSH_ORIGINAL_COMMAND preventing the hooks from being run whilst I figure out how to fix the issues in #6961

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7dd9837). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #6963   +/-   ##
=========================================
  Coverage          ?   41.46%
=========================================
  Files             ?      441
  Lines             ?    59665
  Branches          ?        0
=========================================
  Hits              ?    24738
  Misses            ?    31705
  Partials          ?     3222

Impacted Files
Coverage Δ

models/pull.go
49.8% <100%> (ø)

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 7dd9837...9a6658f. Read the comment docs.

Hmm... the new unit test failure is very interesting. It doesn't appear to have anything to do with my changes.

In particular the failure is at:
panic: Failed to execute 'git config --global core.quotepath false': error: could not lock config file /root/.gitconfig: File exists
29

Has there been a change of the docker environment?

OK I've just removed the SSH_ORIGINAL_COMMAND from the pushing environment as I suspect that it's not working correctly in any case.

But repo.OwnerName should still be repo.MustOwnerName()?

Yeah, any comprehensive fix will need that - could add it now if preferred.


Let purges run in parallel.

Allow purges to bypass the lock to on modifications.

Verified that things are fast again on my end. Thanks!


Fails to SAT solve, but why?

I have two verilog files. They should have the same result, but the SAT solver fails. Unclear to me why
Steps to reproduce the issue
option1.v
module regfile2r1w_alt
  (input                   clk
  ,input [4-1:0]          waddr0
  ,input                  we0
  ,input [7-1:0]          din0
  ,input [4-1:0]          raddr0
  ,output [7-1:0]         q0
  ,output [7-1:0]         q1
  );

  reg [7-1:0] rf[2-1:0];

  reg [7-1:0] q0_next;
  always_comb begin
    if (we0 && raddr0 == waddr0)
      q0_next = din0;
    else
      q0_next = rf[raddr0];
  end

  always @(posedge clk) begin
    q0 <= q0_next;
  end

  always @(posedge clk) begin
    q1 <= q0_next;
  end

  always @(posedge clk) begin
    if (we0) begin
      rf[waddr0] <= din0;
    end
  end

endmodule

option2.v
module regfile2r1w_alt
  (input                   clk
  ,input [4-1:0]          waddr0
  ,input                  we0
  ,input [7-1:0]          din0
  ,input [4-1:0]          raddr0
  ,output [7-1:0]         q0
  ,output [7-1:0]         q1
  );

  reg [7-1:0] rf[2-1:0];

  reg [7-1:0] q0_next;
  always_comb begin
    if (we0 && raddr0 == waddr0)
      q0_next = din0;
    else
      q0_next = rf[raddr0];
  end
  always @(posedge clk) begin
    q0 <= q0_next;
  end

  reg [7-1:0] q1_next;
  always_comb begin
    if (we0 && raddr0 == waddr0)
      q1_next = din0;
    else
      q1_next = rf[raddr0];
  end
  always @(posedge clk) begin
    q1 <= q1_next;
  end

  always @(posedge clk) begin
    if (we0) begin
      rf[waddr0] <= din0;
    end
  end

endmodule

The script to check:
read_verilog -sv ./option1.v ; opt; prep; memory ; rename -top gold; design -stash gold;
read_verilog -sv ./option2.v ; opt; prep; memory ; rename -top gate; design -stash gate;
design -copy-from gold -as gold gold
design -copy-from gate -as gate gate

miter -equiv -make_assert -flatten gold gate equiv
hierarchy -top equiv
sat -prove-asserts -show-inputs -max 2 -verify -set-init-undef -ignore_unknown_cells equiv

Looking over your code, I found many fascinating details:

No initial value was given to either memory.  This could easily cause a mismatch between the two.

No initial values were given to either of the q0 or q1 registers.  This could also cause a mismatch.

Neither q0 nor q1 was declared as a register.  This generates a verific error, although none under non-verific

The addresses passed to the memory were too wide.  The memory should only see a single bit address.  This doesn't change a passing proof, but neither is it likely what the designer intended.

After fixing the above issues, I was able to prove that the two designs were equivalent using abc pdr from SymbiYosys, yet not with yosys' SAT solver.  (I seem to recall hearing something about SAT solvers not being able to handle memories property, although I can't remember the details.)  Indeed, I would recommend moving to SymbiYosys in general for any formal verification needs.
Dan

I understand that the code is not clean, but was created on purpose for testing.
The way that we found it is because doing this:
read_verilog -sv option1.v ; proc ; opt -fast ; pmuxtree ; memory_dff ; memory_share ; memory_collect
write_verilog option2.v

and then run the SAT solver it says that it is not equivalent.
Clearly something peculiar that yosys reads the original verilog, creates verilog but it is not able to check that they are equivalent.

You should read the warning messages:
Setting up SAT problem:
Final constraint equation: { } = { }
Warning: Failed to import cell $techmap\gate.$memory\rf[0]$85 (type $dff) to SAT database.
Warning: Failed to import cell $techmap\gate.$memory\rf[1]$87 (type $dff) to SAT database.
Warning: Failed to import cell $techmap\gate.$procdff$77 (type $dff) to SAT database.
Warning: Failed to import cell $techmap\gold.$memory\rf[0]$30 (type $dff) to SAT database.
Warning: Failed to import cell $techmap\gold.$memory\rf[1]$32 (type $dff) to SAT database.
Warning: Failed to import cell $techmap\gold.$procdff$22 (type $dff) to SAT database.

Your sat command sets up a combinatorial sat problem, not a sequential one. Use for example -seq N to run a BMC with length N.
For example, the following passes fine:
read_verilog -sv ./option1.v ; opt; prep; memory ; rename -top gold; design -stash gold;
read_verilog -sv ./option2.v ; opt; prep; memory ; rename -top gate; design -stash gate;
design -copy-from gold -as gold gold
design -copy-from gate -as gate gate

miter -equiv -make_assert -make_outcmp -flatten gold gate equiv
hierarchy -top equiv
sat -prove-asserts -seq 10 -show-public -verify -set-init-undef -ignore_unknown_cells equiv


Emergency Room Admission casing normalization

Addresses the changes requested in #323

updates the casing of 'Emergency room admission' -> 'Emergency Room Admission' throughout

Thanks for the contribution, but I think we should use the official code display value, which according to the SNOMED browser is: "Emergency room admission (procedure)"
https://browser.ihtsdotools.org/?perspective=full&conceptId1=50849002&edition=en-edition&release=v20180731&server=https://browser.ihtsdotools.org/api/v1/snomed&langRefset=900000000000509007
If you're interested in updating this pull request with the official string, we'll gladly accept it.
Thanks!

No problem, I'll get an update going shortly

Thank you!


ci: Fix rdkafka tests

Per this comment from @mensfeld

found this: https://github.com/open-telemetry/opentelemetry-ruby-contrib/blob/main/instrumentation/rdkafka/test/opentelemetry/instrumentation/rdkafka/patches/consumer_test.rb
It clearly lacks some finalization of work. consumers are not being closed and they leak out of those specs.
https://github.com/appsignal/rdkafka-ruby/issues/216#issuecomment-1662279215

cc: @andyfleming
Fixes https://github.com/open-telemetry/opentelemetry-ruby-contrib/issues/119

I'm not saying this is the only cause but this is definitely one of them. If it continues to crash, I will look more.

We will keep you informed of any other issues we run into.

Anytime :)

Now that I have your attention... It would be great to get your feedback on the code and if there may be better ways for us to integrate with rdkafka instead of using a monkey patching strategy.

That really depends on what you aim to instrument. rdkafka and underlying librdkafka are hard to instrument due to their async nature. I spent months on building reliable instrumentation pipelines for WaterDrop and Karafka to make sure that all errors are propagated and that appropriate metrics are being published.
The general stance on rdkafka-ruby from the maintainers is that it aims to be a base building block for more complex software (like Karafka) and it is suppose to be a binding to librdkafka to expose its APIs. What that means is that your patches should be ok and should be stable because those APIs should not change.
I do don't think that in near future we will come up with any instrumentation framework because of what I said. It would be outside of scope of this library because with instrumentation, some assumptions need to be made.

Please let me know if you or anyone at app-signal would be available to help us with maintaining this instrumentation.

You can count me in.

🎉

Great work guys! FYI if you ever encounter Ruby VM crashes please ping me immediately. Those bindings are subtle and I do my best to handle all the things gracefully but you know ;) people make mistakes


gzip vs websocket: response does not implement http.Hijacker

Hi! My caddy version is 0.8.1.
When both websocket and gzip directives are applied to the same API point - errors are raised on handshake:
# 25/Feb/2016:00:25:17 +0700 [ERROR 400 /echo] websocket: response does not implement http.Hijacker

Here Caddyfile example:
localhost:2020
errors stdout

gzip {
    # Uncomment next line to fix error
    # not /echo
}

websocket /echo cat

And here tiny sample page to check error
<title>Issue</title>

Send to socket:

        <input id="src" type="text" />
        <button id="perform" onclick="perform()" disabled="disabled">Send</button>

Received:

        <input id="dst" type="text" disabled="disabled" />

By the way, it's similar to #133 and #146 issues.

Oops, gzip's response recorder does not implement the Hijacker interface.

Thanks for providing details about the issue and an easy way to reproduce -- I was able to fix this in a jiffy!

Thank you! :+1:


No mcsema-disass command found

After I successfully build the tool, there is no mcsema-disass command generated as showed in the README. It is weird.

Hi,
Try following this README: https://github.com/trailofbits/mcsema/blob/fix_prefix_and_run_tests/README.md and see if you have better results. There is a pull request to make it the README in master already.

Thanks! This helps. BTW, do I have to use IDA-pro for disassembling? It needs to pay for using it. Are there any other options?

Right now; yes. We are working on Binary Ninja support, which is also paid but more affordable. We will also gladly accept pull requests that do CFG recovery via other frontends.