v2: should get_password/get_credential use collection-level search?

I'm using spotifyd while storing my credentials in my KeePassXC database, which has a SecretService implementation. KeePassXC has been updated recently and now supports prompting the user to confirm access of an application to a stored secret. This prompting doesn't seem to supported by keyring-rs, as the call of keyring-rs to GetSecret now fails with an error:
method call time=1648045650.307442 sender=:1.248 -> destination=org.freedesktop.secrets serial=5 path=/org/freedesktop/secrets/collection/KeyDB; interface=org.freedesktop.Secret.Collection; member=SearchItems
   array [
      dict entry(
         string "service"
         string "spotifyd"
      )
      dict entry(
         string "username"
         string "***"
      )
   ]
method return time=1648045650.307636 sender=:1.65 -> destination=:1.248 serial=1674 reply_serial=5
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6"
   ]
method call time=1648045650.307687 sender=:1.248 -> destination=org.freedesktop.secrets serial=6 path=/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6; interface=org.freedesktop.Secret.Item; member=GetSecret
   object path "/org/freedesktop/secrets/session/7668f5ed92944dba9d4c9626a6e0f8ec"
error time=1648045650.307750 sender=:1.65 -> destination=:1.248 error_name=org.freedesktop.Secret.Error.IsLocked reply_serial=6

Here's an excerpt of a similar (but successful) message exchange by the Minecraft Launcher, which supports unlocking and prompting:
method call time=1648044309.545926 sender=:1.226 -> destination=:1.65 serial=9 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret
.Service; member=SearchItems
   array [
      dict entry(
         string "tokenkey"
         string "mojangClientToken"
      )
      dict entry(
         string "xdg:schema"
         string "com.mojang.tokenstore"
      )
   ]
method return time=1648044309.546214 sender=:1.65 -> destination=:1.226 serial=1414 reply_serial=9
   array [
   ]
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/c6d5c87eec6b467788481f4cd2ae8b2b"
   ]
method call time=1648044309.546400 sender=:1.226 -> destination=:1.65 serial=10 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=Unlock
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/c6d5c87eec6b467788481f4cd2ae8b2b"
   ]
method return time=1648044309.546534 sender=:1.65 -> destination=:1.226 serial=1415 reply_serial=10
   array [
   ]
   object path "/org/freedesktop/secrets/prompt/d9076c8584c34394aa60a72ab99ba1c2"
method call time=1648044309.547451 sender=:1.226 -> destination=:1.65 serial=17 path=/org/freedesktop/secrets/prompt/d9076c8584c34394aa60a72ab99ba1c2; interface=org.freedesktop.Secret.Prompt; member=Prompt
   string ""
method return time=1648044309.547541 sender=:1.65 -> destination=:1.226 serial=1416 reply_serial=17
signal time=1648044310.578814 sender=:1.65 -> destination=(null destination) serial=1417 path=/org/freedesktop/secrets/prompt/d9076c8584c34394aa60a72ab99ba1c2; interface=org.freedesktop.Secret.Prompt; member=Completed
   boolean false
   variant       array [
         object path "/org/freedesktop/secrets/collection/KeyDB/c6d5c87eec6b467788481f4cd2ae8b2b"
      ]
method call time=1648044310.579309 sender=:1.226 -> destination=:1.65 serial=20 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=GetSecrets
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/c6d5c87eec6b467788481f4cd2ae8b2b"
   ]
   object path "/org/freedesktop/secrets/session/c3a1ac6acba843b492fa157419b38f71"

It can be observed, that the Minecraft Launcher first calls Unlock on the objects returned in SearchItems. Then Prompt is called on the object returned by Unlock. Only after this GetSecrets is called.
keyring-rs on the other hand calls GetSecret immediately without calling Unlock and Prompt first, which is the reason for the failure.
I assume a call to unlock() and prompt() is missing here, before get_secret(): https://github.com/hwchen/keyring-rs/blob/4297618e0cf061eacedf6d7c3f164ee4074a3c5d/src/linux.rs#L50
Also it seems like prompt() isn't implemented for Item in secret-service-rs yet.
Relevant SecretService spec: https://specifications.freedesktop.org/secret-service/latest/ch08.html

Hi @jkhsjdhjs, platforms vary tremendously in the way they approach programmatic unlocking.  All three platforms support the notion of a user unlocking secure storage from a UI session before programmatic access is attempted, and the keyring approach---in order to avoid dealing with platform-specific UI---has been to require this general unlock be performed before keyring access is attempted.
If you would like to investigate the ways various platforms support programs invoking UI-based unlock, and submit a PR that incorporates it, we would be delighted to review it.  Starting with Linux only would be fine, but please try to avoid approaches that would change the API if possible.

Hi @jkhsjdhjs, platforms vary tremendously in the way they approach programmatic unlocking.  All three platforms support the notion of a user unlocking secure storage from a UI session before programmatic access is attempted, and the keyring approach---in order to avoid dealing with platform-specific UI---has been to require this general unlock be performed before keyring access is attempted.
If you would like to investigate the ways various platforms support programs invoking UI-based unlock, and submit a PR that incorporates it, we would be delighted to review it.  Starting with Linux only would be fine, but please try to avoid approaches that would change the API if possible.

Alright, I finally had some time to have a look at this. Sorry for the late reply @brotskydotcom.
The following patch would add the functionality to this library:
diff --git a/src/linux.rs b/src/linux.rs
index 7f349c6..c64f104 100644
--- a/src/linux.rs
+++ b/src/linux.rs
@@ -47,6 +47,9 @@ pub fn get_password(map: &mut PlatformCredential) -> Result<String> {
             .search_items(map.attributes())
             .map_err(decode_error)?;
         let item = search.get(0).ok_or(ErrorCode::NoEntry)?;
+        if item.is_locked().map_err(decode_error)? {
+            item.unlock().map_err(decode_error)?;
+        }
         let bytes = item.get_secret().map_err(decode_error)?;
         // Linux keyring allows non-UTF8 values, but this library only supports adding UTF8 items
         // to the keyring, so this should only fail if we are trying to retrieve a non-UTF8

It results in the following dbus communication when an item is not locked:
method call time=1653671076.733294 sender=:1.319 -> destination=org.freedesktop.secrets serial=5 path=/org/freedesktop/secrets/collection/KeyDB; interface=org.freedesktop.Secret.Collection; member=SearchItems
   array [
      dict entry(
         string "application"
         string "rust-keyring"
      )
      dict entry(
         string "username"
         string<EMAIL_ADDRESS>      )
      dict entry(
         string "service"
         string "spotifyd"
      )
   ]
method return time=1653671076.733535 sender=:1.69 -> destination=:1.319 serial=172 reply_serial=5
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6"
   ]
method call time=1653671076.733918 sender=:1.319 -> destination=org.freedesktop.secrets serial=6 path=/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6; interface=org.freedesktop.DBus.Properties; member=Get
   string "org.freedesktop.Secret.Item"
   string "Locked"
method return time=1653671076.734008 sender=:1.69 -> destination=:1.319 serial=173 reply_serial=6
   variant       boolean false
method call time=1653671076.734360 sender=:1.319 -> destination=org.freedesktop.secrets serial=7 path=/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6; interface=org.freedesktop.Secret.Item; member=GetSecret
   object path "/org/freedesktop/secrets/session/39a553b925aa4670b77f14807cc1e87e"

and in this one when an item is locked:
method call time=1653671021.542487 sender=:1.317 -> destination=org.freedesktop.secrets serial=5 path=/org/freedesktop/secrets/collection/KeyDB; interface=org.freedesktop.Secret.Collection; member=SearchItems
   array [
      dict entry(
         string "service"
         string "spotifyd"
      )
      dict entry(
         string "username"
         string<EMAIL_ADDRESS>      )
      dict entry(
         string "application"
         string "rust-keyring"
      )
   ]
method return time=1653671021.542760 sender=:1.69 -> destination=:1.317 serial=151 reply_serial=5
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6"
   ]
method call time=1653671021.543149 sender=:1.317 -> destination=org.freedesktop.secrets serial=6 path=/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6; interface=org.freedesktop.DBus.Properties; member=Get
   string "org.freedesktop.Secret.Item"
   string "Locked"
method return time=1653671021.543231 sender=:1.69 -> destination=:1.317 serial=152 reply_serial=6
   variant       boolean true
method call time=1653671021.543608 sender=:1.317 -> destination=org.freedesktop.secrets serial=7 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=Unlock
   array [
      object path "/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6"
   ]
method return time=1653671021.543731 sender=:1.69 -> destination=:1.317 serial=153 reply_serial=7
   array [
   ]
   object path "/org/freedesktop/secrets/prompt/84bbb993e0ee4815bdc016e474348cc2"
method call time=1653671021.544476 sender=:1.317 -> destination=org.freedesktop.secrets serial=9 path=/org/freedesktop/secrets/prompt/84bbb993e0ee4815bdc016e474348cc2; interface=org.freedesktop.Secret.Prompt; member=Prompt
   string ""
method return time=1653671021.544625 sender=:1.69 -> destination=:1.317 serial=154 reply_serial=9
signal time=1653671022.829063 sender=:1.69 -> destination=(null destination) serial=155 path=/org/freedesktop/secrets/prompt/84bbb993e0ee4815bdc016e474348cc2; interface=org.freedesktop.Secret.Prompt; member=Completed
   boolean false
   variant       array [
         object path "/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6"
      ]
method call time=1653671022.830018 sender=:1.317 -> destination=org.freedesktop.secrets serial=10 path=/org/freedesktop/secrets/collection/KeyDB/2bf27c5b9dc54eb78fcc8c97485425b6; interface=org.freedesktop.Secret.Item; member=GetSecret
   object path "/org/freedesktop/secrets/session/ac2c51fc57d641ca9243adfcb77e8336"

As can be seen, the Prompt function seems to be called implicitly after calling Unlock, this is probably handled somewhere in secret-service-rs.
However, this patch has the downside of an extra method call, because using is_locked() results in an extra Get call, requesting the Locked state.
That is unnecessary, because the response of the SearchItems method that is called previously to search the entries already indicates whether the items are locked or unlocked. As stated here, the first array contains unlocked items while the second one contains locked items: https://specifications.freedesktop.org/secret-service/latest/re01.html#org.freedesktop.Secret.Service.SearchItems
Thus my patch from above is far from ideal.
However, the search_items() method of secret-service-rs only provides a single vector of all returned items: https://github.com/hwchen/secret-service-rs/blob/d6aaa774f0ec504ff5f26662279e07175b8ef111/src/collection.rs#L117
Thus there's no way of determining whether the returned items are locked or unlocked, at least not without an extra method call. Because of this, I believe that the API of search_items() in secret-service-rs needs to be changed, so it indicates which items are locked and which aren't.

@jkhsjdhjs Just wanted to let you know that I still haven't had time to look at this, but I haven't forgotten about it.  I've been sort of hoping @hwchen would take it on, since he's our secret-service expert.

@brotskydotcom Thanks for letting me know! I investigated this a bit further and have to revise some previous statements:
While going through the SecretService specification I initially failed to notice that there are actually multiple interfaces:
The SearchItems method is specified for the Service interface and for the Collection interface as well.
Collection.SearchItems is actually specified to only return a single array of the search results, while only Service.SearchItems returns locked and unlocked items as separate arrays. Thus what I said here is wrong:

Because of this, I believe that the API of search_items() in secret-service-rs needs to be changed, so it indicates which items are locked and which aren't.

It is implemented correctly since it implements Collection.SearchItems, not Service.SearchItems.
In the dbus logs I posted in the issue description one can also see that the Minecraft Launcher uses Service.SearchItems while keyring-rs uses Collection.SearchItems. Since only the response of Service.SearchItems indicates which items are locked and which aren't I think it would be best to also use Service.SearchItems here.
For this, the search_items() function here would need to be changed, as in the current state it just collects locked and unlocked items in a single vector: https://github.com/hwchen/secret-service-rs/blob/d6aaa774f0ec504ff5f26662279e07175b8ef111/src/lib.rs#L282

@jkhsjdhjs I don't see an issue about this request to use Collection.SearchItems in the secret-service issues list.  I know they are close to a new release so this would seem to be the right time for them to consider this?
I'm going to mark this issue as waiting for the secret-service enhancements.

Hi @jkhsjdhjs I'm working on a new major release of keyring-rs that uses the (upcoming) 3.0 release of secret-service and I plan to take care of this issue in that release.  But I've noticed a discrepancy in API and I wanted to get your opinion on my plan.

There is a semantic difference between "secret-service-level search" and "collection-level search" in secret service; as can be seen in the spec: service-level search goes through all collections and returns separate locked and unlocked lists; collection-level search goes through just one collection and returns both locked and unlocked items together.
Keyring-rs currently restricts its search to a single collection (specified in the target used in entry creation), so using service-level search would change its semantics.

My current plan is to leave the collection-specific semantics of keyring intact and go with your first proposed fix above (checking if each item is locked before returning it).  I am willing to add a way of invoking service-level search in secret-service (because the new release uses traits, I can make credential-store-specific functionality available to clients), but for now I believe maintaining backward-compatibility of search semantics for older clients is worth the overhead of the extra is_locked call.
I would appreciate your take on this.

Sorry for the late reply, I didn't have much time in the past few days and also thought about this a bit.
First of all, I agree with you: semantics are important. Since the name of the collection is part of the SsCredential struct, it should be respected wherever possible.
Your current plan is to keep the current collection-specific semantics as is, but I argue that the current collection-specific semantics aren't correct, and since the next release will be a major release, that would be an opportunity to change these as well.

A credential isn't inherently bound to a collection. It may not be contained in any collection, and it may also be contained in several. With the current implementation, an SsCredential is only stored in a collection if set_password() is called.

Collection names are just aliases and not necessarily static. Thus, it doesn't really make sense to bind a credential to the name of a collection. SecretService allows any application to create aliases for collections, so even the name "default" may point to different collections each time [1].

The current semantically-correct thing to do is to only search the specified collection in get_password. However, the spec recommends to use the service-level search when searching for entries:

In order to search for items, use the SearchItems() method of the Service interface. [2]

I assume that most other implementations also do it that way, an example is given in the linked comment, where one can observe the minecraft launcher using the service-level search: https://github.com/hwchen/keyring-rs/issues/84#issue-1178278107.
As point 2 states, collection aliases aren't static, so a stored credential may be contained in a collection with a different alias the next time it is requested. This would break the collection-level search.
Also, the user may split their credentials into several collections, only one of which would be searched when using the collection-level search.

I propose to remove the collection attribute from the SsCredential struct and instead specify the collection alias when calling set_password and delete_password as function parameters.
Of course this would break the API, and clients would have to adjust a bit, but since you're currently preparing a new major release anyways, I think this would be the right time to consider this.
Keep in mind that I'm not a SecretService expert, this is just the way I interpret the spec and the semantic discrepancies I noticed between spec and implementation. I would appreciate your opinion on this, @brotskydotcom! Also, if anyone else is reading this, feel free to join the discussion!
[1] https://specifications.freedesktop.org/secret-service/latest/ch04.html
[2] https://specifications.freedesktop.org/secret-service/latest/ch05.html

Thanks so much @jkhsjdhjs for this thoughtful (and persuasive) analysis.  I have a number of thoughts, so bear with me while I use this response to think them through.  I think I'm likely to arrive at a place where we are both happy.

The only point you make that I disagree with is that "the spec recommends to use the service-level search when searching for entries".  While I agree that the spec makes that recommendation, the spec immediately follows that recommendation with this sentence "The SearchItems() method of the Collection interface is similar, except for it only searches a single collection", which is both an equally strong endorsement of collection-level search and a lie.  (As you and I both know, the SearchItems method of the Collection interface differs critically from service-level search in that it doesn't distinguish locked from unlocked items.)
The points you make about aliases being changeable are true but don't seem to me to really bear on this discussion.  Obviously if multiple clients use the same collection then they will need to agree about what to call that collection.  But I think it's reasonable for them to expect that if they use different collection names from each other to store an item then they can use the same attributes on that item without fear of ambiguity when they search.
The two points you make that influence me most strongly are these:

Collections are simply holders of items, and the same item can be in no collection or in many collections.  From the secret-service point of view, the collection is thus not a required "search key" for an item (in the way, for example, the required "domain" field is in the macOS/iOS keychain interface).
Major versions are the right times to make appropriate semantic changes in a crate's interface.  Thus if we are going to make an interface change to more closely mirror secret-service semantics around search, this is the time to make that change.

Where this all gets me is here:

The optional target field of an entry has intentionally vague semantics at the crate interface level: it's explicitly left to each of the credential stores to decide how to handle that field.  What the crate-level interface does imply, however, is that two entries with the same service and username values can use different target values to avoid collision in the credential store.
The v2 meaning of target for secret-service was the collection used both for creation and for search, a convention that was motivated by the macOS/iOS meaning of target.  But that meaning is arguably incorrect, as you pointed out.  While that meaning of target definitely makes sense in the creation scenario, and it gives clients a useful way of specifying a specific collection they already know exists, it doesn't make a lot of sense in the search scenario, because secret-service offers collection-independent search (and that search may in fact be more performant, depending on whether there is a global index or cache maintained by the service and whether the items being searched for are locked).
Given (1) and (2), the only issue I have with switching to service-level rather than collection-level search is the collision it could introduce for existing credentials that differ only in their target attribute.  (For new credentials I am happy to add a target attribute which can be used to disambiguate.) I can see at least a couple of ways of dealing with this, the second of which is the most backward compatible but introduces performance overhead in collision cases:

introduce a new error which indicates the existence of a collision and returns multiple entries;
in the presence of collision, use collection-level search to disambiguate.

Now that credential stores are full-fledged objects with constructors, I can make it easy for clients to construct a secret-service store with a specific ambiguity-resolution strategy (or even a different target-interpretation strategy).  So clients who really want the legacy semantics on search can just opt into it by using a parameter when they construct their store.  Alternatively, I could leave the default as v2 collection-level search (with unlocking of found items) and let new clients use a parameter to opt into service-level search.

I would very much appreciate thoughts on all this!

Changing the title and reopening this issue as it has migrated from a bug report to a new-version design question.

Thanks for the quick reply, and again sorry for the delay!
Also thanks for the explanation, I actually never had a look at the keyring-rs interface, I only viewed the SecretService specific files so far.
I can see the problem with switching to service-level search, and I also think that using a target attribute in the future is reasonable. For already-existing entries this could lead to collisions, as you correctly pointed out.

introduce a new error which indicates the existence of a collision and returns multiple entries;

I'm not in favor of this first alternative, since a new error type would be required for this behavior and application developers would thus have to adjust their code to handle this error correctly.

in the presence of collision, use collection-level search to disambiguate.

However, I like this alternative! It has the advantage that the applications using keyring-rs don't need to be changed in any way. The performance overhead wouldn't be a problem IMO, since dbus is quite fast and I'm pretty sure the fallback to collection-level search wouldn't be noticeable if the user is simply searching for single entries.
I don't quite understand your fourth point though. When falling back to collection-level search, this is the same behavior as currently implemented. So if there are still ambiguities when using collection-level search, these ambiguities would be present currently as well. New entries would be created with the new target attribute, which disambiguates them. So unless you plan to change the existing ambiguity behavior aside from this issue as well, I don't see the need for an ambiguity resolution strategy.
One question I'm currently asking myself regarding the collection-level search fallback however is:
If an entry is fetched via the collection-level search fallback and a new password for that entry is set, would that result in the creation of a new entry (because of the new target attribute that would be added) or would it update the existing entry?

Thanks again for a very useful reply; this conversation is really helping me sort out my thoughts.  A few clarifications:

The addition of the error on colliding entries is required regardless, both for the Mac keychain and the Linux secret-service, because in both services (as far as I know) attributes you don't specify as part of the search may be present in the entry.  Thus (for example), if someone were to use keychain-rs to add an entry with service="foo" and user="bar", and some 3rd party app added a credential with service="foo" and user="bar" and client="baz", the keychain-user would actually get back both those entries in a search.  (I haven't tested this on Linux, but I know it happens on Mac.)

Now let's talk about the "target" attribute:

If I add a "target" attribute to newly-created entries that are given explicit targets, then for backward compatibility I need to do one of the following:

search for entries without specifying the target, so that both new-style and old-style entries are found (per the behavior of #1).
search for entries with the target (which will only find new-style credentials), and then if that fails do a second search without the target (to find old-style credentials).

Regardless of which of these I do, I have to do two things in order to avoid creating both old-style and new-style credentials for the same entry:

whenever I find an old-style credential, I need to replace it with a new-style credential.
I have to do search-before-set, in case there's an old-style credential.

This is a lot of complexity and performance impact, none of which is needed if I don't add the target attribute.  If I don't add the target attribute, then I have to something to deal with with target ambiguity, such as:

Start with collection-level search.  This means each lookup incurs the additional cost of the "is it unlocked?" call, but guarantees the client always gets the target they searched for.
Start with service-level search, falling back to collection-level search in the case of ambiguity.  This is cheaper, but gives the client no guarantee that they aren't getting a credential that was created with a different target than used in the search.
A variant of (2) that puts the target into the description, so at least new-style credentials are guaranteed to have the right target.  (This variant depends on being able to update the description as part of updating the password in an existing credential.)

I'm planning to do (1) by default, since that's by far the simplest and the most backward-compatible.  But it's my belief that (1) and (2/3) can have very different performance impacts on users who don't care about target ambiguity.  That's why I talked about allowing users to choose their ambiguity strategy, so they could choose between 1 and 2/3.  Now that credential stores are represented by credential builders, it's easy to add options to the secret-service builder constructor to choose between these strategies, and for a user who wants a different strategy to make it his default.
As always, I would greatly value your feedback.

Thanks for the clarification! I'm still not sure if the new error type is really required for linux. AFAICT keyring-rs always stores the application and the service attribute, where application is stored as rust-keyring and service as the name of the application using keyring-rs, so for example spotifyd. So when searching, these attributes should be (and I believe currently are) included in the search.
But now that I think about it, I guess if a third party app creates these attributes as well, the application searching for an entry should me made aware of this. So yeah, I agree, the error is reasonable.
Hmm, the solutions you propose make sense. If keyring-rs handles the ambiguity it makes sense to use resolution strategies. But now I'm thinking, if the new error type is required anyways, it may be simpler to just append the ambiguous entries to the error and let the user decide which one they want to use.
What about the following:
Search on Service interface with target attribute
  Duplicates: Return Error containing all duplicate entries
  No results: Search on Collection interface without target attribute (using target as collection alias)
    Return response and mark entry as legacy internally
  Exactly 1 result: return

Entries marked as legacy internally would have to be extended by the target attribute once set_password() is called. On the next get_password() call it would then be found by the service-level search.

OK, sorry for the delay in replying, but I've been doing a lot of testing and a lot of thinking and I think I have a fairly elegant solution.  We introduce one option in the secret-service credential store builder: a boolean search_all which means to search for credentials in all collections (i.e., use service-level search).  When you turn on search_all in the builder, it causes all the credentials to include a target attribute (as well as using the target for the collection name in which the credential is created), and it always searches for credentials at service level including the target attribute.  This means:

if search_all is off (the default), then we are completely compatible with v1 credentials and we have to do the explicit check for a locked credential on get and delete.
if search_all is on, then we will never see any v1 or search_all=off credentials at all (because none have a target attribute).

Note that v1 and search_all=off will find credentials built with search_all=on (because they ignore the target attribute).  In addition, because of the way the secret service works, doing a v1 or search_all=off set-password call will remove the target attribute from an existing credential with the same service and user.
Thus, to write a v2 client that always uses service-level search but is compatible with non-service-level search clients, the service-level search client should always delete any existing non-target entry with the same user and service before setting a password.  This is very easy to do because you can use two credential stores side-by-side in the same v2 client.
Also note that, in order to release this version now, I had to revert back to using v2 of the secret service, because v3 has not yet been released.  This means that keyring v2 clients that do service-level search are going to pay the same "ensure-unlocked" penalty on every lookup that collection-level search clients do, because secret-service v2 doesn't have your enhancement to return the separate locked and unlocked collections.  But as soon as secret-service v3 gets released I will do a dot release of keyring v2 that will take advantage of it.
I'm putting out beta.1 of v2 very soon.  Please give it a try and let me know what you think!

What I like about this solution is that it's fully backwards compatible and that it allows for the credentials to be migrated.
But if I understood it correctly, the applications using this library would have to handle the migration themselves, so they would have to instatiate two separate credential stores, use one store to retrieve old credentials and the other to store credentials in the new fashion. While this gives the application full flexibility in what they want to do, I'm concerned whether the applications want that flexibility.
Since search_all is set to false by default, I fear that developers won't even notice a change and thus don't adjust anything when upgrading keyring-rs to v2. That might be good when caring about backwards-compatibility, but it also causes credentials to never be upgraded to the new style. And even worse, applications that are just starting to use this library will probably also use collection-level search, since it's the default.
So if we're doing it that way, I think this change should be the first mention in the changelog, it should be documented properly and maybe there should even be a deprecation warning when using search_all=false, because developers really should be aware of this.
Aside that, shouldn't a set-password call with search_all=false also add the target attribute? This way the credentials would be made compatible with search_all=true, and maybe search_all=false could eventually be removed in v3 or v4.
Again, this is all under the premise that I understood it correctly. Please let me know what you think!

So I have figured out a much, much simpler approach to all this:

We always use service-level search.  So no options are needed to turn it on or off.
We always add a target attribute when creating new items.
We always just search for the service and user.  So we find both v1-style entries (with no target attribute) and v2-style entries (with the target attribute).  We filter the found results so they are either v1-style entries (which are assumed to have a matching target) or v2-style entries with a matching target.
If we ever get multiple hits on a search, we return an ambiguous error.
set-password works by doing get-password and then, if it finds a unique item, setting the password on that item.  If there is no matching item, it creates one in a collection labeled by the target (creating that collection if necessary).  Note that the default target is the only collection found by alias; all other collections are found by label.

This seems to provide the best of all worlds: v1 and v2 are now completely compatible, and we can create collections if the client uses a non-default target.  (Note that v1 never created collections, and it always used the target name as an alias, so in effect it was completely restricted to using the default collection.)
If (due to 3rd party items) an ambiguity is found, there are platform-specific entries for getting all the passwords or deleting all the matching items.

That sounds like an excellent approach to me!

set-password works by doing get-password and then, if it finds a unique item, setting the password on that item.

Maybe it should also add the target attribute to that item, if it doesn't has one yet?

Maybe it should also add the target attribute to that item, if it doesn't has one yet?

I don't think there's any way to do that short of deleting and re-creating the item.  (Do you know of one?)  That would be two more calls to the Dbus and it might actually have the effect of changing the collection the item is in (if the original item was created in the default collection but the new item has a different target).  If a 3rd party is creating items I'd rather have keyring read and set them without altering them.


Endpoint can be used in assignment statements

Following works in the latest source
endpoint<Foo> fo {
}
fo = create Foo();
Foo aa = create Foo();
fo = aa;

fix this

This is no longer valid


Expose GeometryInstance3D.custom_aabb property

Follow up to https://github.com/godotengine/godot/pull/70087
As discussed in https://github.com/godotengine/godot/issues/57740
set_custom_aabb() was added here https://github.com/godotengine/godot/pull/25520 at that time reduz suggested exposing the property and Akien noted that we could add it in a follow up PR
Setting a custom_aabb allows the renderer to avoid the expensive mesh_get_aabb() function which recalculates the aabb from skeleton bones. To fully address usability needs we should add some editor functionality to create an appropriately sized AABB. But that is future work, I will need to create a proposal

Thanks!


fixed ARGOCD_SERVER environment variable

Testing on v2.1.7+a408e29 only ARGOCD_SERVER works, not ARGO_SERVER.
This is also shown as ARGOCD_SERVER here:
https://argo-cd.readthedocs.io/en/stable/user-guide/ci_automation/#synchronize-the-app-optional

looks like similar issues exist here, these environment variables don't work in my testing:
https://argoproj.github.io/argo-workflows/cli/argo/

Yes pls ignore.


Default to no eunit formatter if verbose specified

The previous default meant that verbose output would not be emitted, thanks to the custom formatter which doesn't seem to interact well with verbose.
I'm opening this now because I wanted to quickly fix this behavior, but I'm open to suggestions on how to improve the tests for this.

Thanks! Could you rebase this, I'll merge it after you do.

Should be good to go.  Let me know if there's anything else.


Move installer to the bazel/ subdir, but provide a toplevel alias.

Someone importing the project thus does not need that pull in that dependency directly.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.92%. Comparing base (66f5e76) to head (1e952f5).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2125   +/-   ##
=======================================
  Coverage   92.92%   92.92%
=======================================
  Files         359      359
  Lines       26666    26666
=======================================
  Hits        24780    24780
  Misses       1886     1886

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


Can't add new node with vSphere IPI installation

Describe the bug
When I try to add a new node by scaling a machine set, I see in vSphere console that a new virtual machine was created. But it seems that initial boot image doesn't get guestinfo properties

When I added a new nodes last time (about 7 months ago), it was working perfectly. From that time all that I know is that our version of vSphere was changed (from 7 to 8).
My assumption is that I have an old version of boot image with old version of FCOS on board.
P.S
I checked how guestinfo properties work on current FCOS version (38) and the OS gets them.
Version

IPI vSphere v8
Initial version, when cluster was installed - okd4.6
Current version - okd4.13
How reproducible

Log bundle

Resolved it my myself.
Right version FCOS can be found here  https://github.com/okd-project/okd/blob/master/FAQ.md#which-fedora-coreos-should-i-use
Then I downloaded ova file from here https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/38.20230414.3.0/x86_64/fedora-coreos-38.20230414.3.0-vmware.x86_64.ova and uploaded it to vSpehere
And it is possible to change template name in machineset as well.


Update for<EMAIL_ADDRESS>

🦆

Coverage remained the same at 100.0% when pulling fd676dd153634b36267bd5f79f591802b8643de6 on ch-ch-changes into d5e14d0b1179382139a2526e7186abc9fbdcf0f7 on master.

Coverage remained the same at 100.0% when pulling fd676dd153634b36267bd5f79f591802b8643de6 on ch-ch-changes into d5e14d0b1179382139a2526e7186abc9fbdcf0f7 on master.

Thanks, I've merged this as I need the module! 👍

:+1:


Remove unnecessary todo

These are already implemented as try_join*.

:frown: why doesn’t github have a way to rebase open PRs onto master automatically yet.


Bugs: checkbox & drawing etc.

Hi there,
I modified a theme from "theme_material" and tested with "lv_test_theme_1(th);", some bugs appeared as follows:
1. when setting style.body.radius=0; , drawing one dot more in every 90' angle as below:

I pointed out 2 for example. Both in "pc_simulator" & hardware board.
I tried to fix that but "xxx_design" is more complicated than what i thought to be.
Use an "if" condition before drawing may higher efficiency?
2.knob in slider: a square will be drawn when style.body.radius=0;
I modified these lines in "lv_slider_design()" : line 327-328
if(slider_w >= slider_h)
       {
            if(ext->knob_in == 0) {
                knob_area.x1 = area_indic.x2 - slider_h / **4**;
                knob_area.x2 = knob_area.x1 + slider_h **/2**;
            } else {
                knob_area.x1 = (int32_t) ((int32_t)(slider_w - slider_h) * (cur_value - min_value)) / (max_value - min_value);
                knob_area.x1 += slider->coords.x1;
                knob_area.x2 = knob_area.x1 + slider_h;
            }

            knob_area.y1 = slider->coords.y1;
            knob_area.y2 = slider->coords.y2;
        }

 3.when i try to merge to beta version, check box error in simulator: wrong size ,no caption and check

will crash and have no effects after reverting back (ver 5.1.0 is fine before that), acts normal in hardware
board(5.2.0 beta earlier version about 3-4 months ago)
 4. no effects on tab text font size:

lv_style_t tb;

    lv_theme_set_current(th);
    lv_obj_t *scr = lv_cont_create(NULL, NULL);
    lv_scr_load(scr);
    lv_cont_set_style(scr, th->bg);

   tv = lv_tabview_create(scr, NULL);
   lv_style_copy(&tb, th->tabview.bg);
   tb.text.font = &muli_latin_regular_40;
   lv_tabview_set_style(tv, LV_TABVIEW_STYLE_BG, &tb);

by the way, my font usage is it a problem?

i don't know why the page looks so messy ~_~

Hi,
please put your code section  between
 ```c
code block
```
tags

@kisvegabor
Hi, I found that ddlist & list & roller are much alike, commonly an downward arrow on the right by the ddlist, maybe more user friendly? What do you think?

Thank you for updating your comment!

radius: I fixed it in dev-5.2 branch. Can you verify if it works well?
square knob in slider: yes, the knob can be only square (or circle with LV_RADIUS_CIRCLE radius)
crash: your style declaration should be: static lv_style_t tb; because only the style pointers are saved.
To set the text size on tabs you should set the styles like this:

   /*The released button is transparent so it will inherit the background's style*/
   static lv_style_t tb_bg;
   lv_style_copy(&tb_bg, th->tabview.btn.bg);
   tb_bg.text.font = &muli_latin_regular_40;
   lv_tabview_set_style(tv, LV_TABVIEW_STYLE_BTN_BG, &tb_bg);

   /*The toggled released (active tab) is not transparent. Set it directly*/
   static lv_style_t tb_tgl_rel;
   lv_style_copy(&tb_tgl_rel, th->tabview.btn.tgl_rel);
   tb_tgl_rel.text.font = &muli_latin_regular_40;
   lv_tabview_set_style(tv, LV_TABVIEW_STYLE_BTN_TGL_REL, &tb_tgl_rel);

I pushed a minor fix to dev-5.2 related to tabview styling.

@kisvegabor
Thanks a lot for your advise.
First,
We have a major problem here: hardware board have a lot of glitches on the screen with 5.2.0 beta(new architecture on drawing) and is much slower than 5.2.0 beta earlier version. So, i am not sure which file should be replaced to solve the radius problem.
Second,
We have a new situation here:

Alignment of labels are not the same when using animation(the containers of labels using "lv_cont_set_layout(t_inf, LV_LAYOUT_ROW_M);" ) :
first one not using long mode.
second one using LV_LABEL_LONG_ROLL long mode.
I think the animation have bugs : perhaps layout param is not inherited?

Hi,
Please update to the dev-5.2 branch and test with that.

If it"s not working please provide an example code to test your code.

Thanks for your advise.
We will looking forward to testing the new beta.

@kisvegabor
Hi,
I update to the latest dev-5.2 branch and test with that, and make efforts to optimize for speed. Alignment of labels are not the same when using animation problem is still there.
mframe.zip
regards!

Hi,
I checked your code and modified one line to make it work:
lv_obj_set_width(t_inf_label, INFO_LANE_LABEL_W);

Originally you set the label and the conatainer height to the same value. The label objcet was really cenered vertically  due to the layout. However, the text always begins at the top of the label.
See the difference:
Your version:

My version:

So I just let the height to set automatically when setting the text with lv_label_set_text and later only modifed the width.

Hi,
Your code works fine.Thanks a lot.
Regards!


[duckx] file conflict

Installing package duckx[core]:arm64-windows...
The following files are already installed in D:/installed/arm64-windows and are in conflict with duckx:arm64-windows

Installed by libzip:arm64-windows
    include/zip.h

Installed by pugixml:arm64-windows
    include/pugiconfig.hpp
    include/pugixml.hpp

Elapsed time for package duckx:arm64-windows: 4.008 s

port probably not correctly setup

@Neumann-A ,Thanks for posting this issue, I can't reproduce your issue locally, are my steps wrong?
PS F:\test\vcpkg> ./vcpkg install duckx[core]:arm64-windows
Computing installation plan...
The following packages will be built and installed:
    duckx[core]:arm64-windows -> 1.0.0#1
Detecting compiler hash for triplet arm64-windows...
Restored 0 packages from C:\Users\vzhli17\AppData\Local\vcpkg\archives in 204.8 us. Use --debug to see more details.
Starting package 1/1: duckx:arm64-windows
Building package duckx[core]:arm64-windows...
-- Downloading https://github.com/amiremohamadi/DuckX/archive/v1.0.0.tar.gz -> amiremohamadi-DuckX-v1.0.0.tar.gz...
-- Extracting source F:/test/vcpkg/downloads/amiremohamadi-DuckX-v1.0.0.tar.gz
-- Using source at F:/test/vcpkg/buildtrees/duckx/src/v1.0.0-d9d30037d0.clean
-- Found external ninja('1.10.2').
-- Configuring arm64-windows
-- Building arm64-windows-dbg
-- Building arm64-windows-rel
-- Installing: F:/test/vcpkg/packages/duckx_arm64-windows/share/duckx/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\vzhli17\AppData\Local\vcpkg\archives\2b\2b56bd570a0465119c378c17bb93c9fce30a7bb54f81027aee729b463aee7a93.zip
Installing package duckx[core]:arm64-windows...
Elapsed time for package duckx:arm64-windows: 6.57 s

Total elapsed time: 11.9 s

The package duckx is header only and can be used from CMake via:

    find_path(DUCKX_INCLUDE_DIRS "duckx.hpp")
    target_include_directories(main PRIVATE ${DUCKX_INCLUDE_DIRS})

are my steps wrong?

install libzip and pugixml before you do the duckx installation.

Confirmed


v1.1.1

Hi,
I replaced the deprecated React.DOM with calls to React.createElement.
I also changed the behaviour slightly, as described in this issue: https://github.com/hzdg/react-imageloader/issues/3.
I hope you can merge this changes.

Hey @cell303, thanks for submitting this!
A couple of things:

I think we covered the React 0.12 issues with the last couple of releases; after updating, do you still see warnings?
We've already eclipsed the version you bumped to in this PR. It's usually best not to bump versions as part of a PR, since there might be other changes that get incorporated before the next release.

I think maybe you could reduce this PR to just this: https://github.com/cell303/react-imageloader/commit/cea35b729dc66227711cefde1bfc6c51ed022803
Thanks again, and sorry for the long delay!

Hi,

no, I have no warnings. I just read in the patch notes that React.createElement is the new way to do things and I just assumed that React.DOM is deprecated. However that doesn't seem to be the case.

I didn't know that, thanks for pointing it out.


snabb: fix build

Description of changes

Fixed the build for ZHF (https://github.com/NixOS/nixpkgs/issues/199919) at #ZurichZHF :)
Version bump from 2019.11 to 2022.10
Remove prePatch substitutions as these were causing build failure

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

The supportOpenstack arg now no longer does anything.

Hey nice work @seanrmurphy!
Hey in this post-OpenStack era I think that we could prune quite a few dependencies back. The parallel build failure workaround doesn't seem needed anymore either. Maybe something like this?
{ stdenv, lib, fetchFromGitHub }:

stdenv.mkDerivation rec {
  pname = "snabb";
  version = "2022.10";

  src = fetchFromGitHub {
    owner = "snabbco";
    repo = "snabb";
    rev = "v${version}";
    sha256 = "GIIW+2/1fuHTmYev/QvuO5Yb2ozbyw/45qQkym36US8=";
  };

  installPhase = ''
    mkdir -p $out/bin
    cp src/snabb $out/bin
  '';

  meta = <unchanged>;
}

Thanks for feedback @lukego @risicle - modified as suggested; tested build locally and everything seems in order.


feat: adds ubooquity deployment

Description of the change
Adds the ubooquity comic book
Benefits
Replace kavita so I can use comic app again.

🦙 MegaLinter status: ✅ SUCCESS

Descriptor
Linter
Files
Fixed
Errors
Elapsed time

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff
MegaLinter is graciously provided by


Update grpc sample

Fixes #2057
The sample now sends GRPC spans and stats. The GRPC OpenCensus instrumentation is in the package io.grpc:grpc-census (in grpc-java repo) which needed to be added.
Also updated the global trace sampler to Samplers.alwaysSample() so that the example will send GRPC instrumentation spans which are the parent in the example and were previously sampled away:

GRPC metrics like server_latency are now sent, and I updated the Stackdriver exporter to send at intervals of 5 seconds (the minimum allowed):

CI build fails due to some formatting issue.

Codecov Report

Merging #2058 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2058   +/-   ##
=========================================
  Coverage     83.05%   83.05%
  Complexity     2249     2249
=========================================
  Files           319      319
  Lines         10526    10526
  Branches       1048     1048
=========================================
  Hits           8742     8742
  Misses         1446     1446
  Partials        338      338

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 eab6382...89c4362. Read the comment docs.

CI fixed, merge if it looks good to you 🙂


TransformVectorMult node in VisualShader return a vec3 instead of a vec4, causing the w component of the vector to get dropped.

Godot version
4.1.3.stable (I also tried on 4.2 Beta4 and I believe QbieShay tried on the lastest Master)
System information
Godot v4.1.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; <IP_ADDRESS>01) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)
Issue description
Here at the request of QbieShay.
When using the TransformVectorMult node in VisualShader, the TransformVectorMult node outputs a vec3 instead of a vec4, causing the w component of the vector to get dropped.

From mine and QbieShay's understanding, TransformVectorMult should output a vec4. This can be seen in the generated GDShader code that the editor generates when enabling Proximity Fade in a Material
https://github.com/godotengine/godot/assets/17209617/136ace4a-7dae-4a0e-8ea0-2296571f1d4d
Steps to reproduce
In the visual shader editor, mulitply a vec4 by the INV_PROJECTION_MATRIX  using the TransformVectorMult node and you will see that a vec3 is the output instead of a vec4
Minimal reproduction project
Example Reproduction.zip

According to the documentation it is supposed to take a Vector3, not a Vector4

Right but then you lose the W component of a vector4, which you need in order to recreate proximity fade using visual shader.

As far as I know, there doesnt seem to be away to multiply the INV_PROJECTION_MATRIX and the Screen_UV to convert from screen space to world space. You lose the W component, which according to the generated GDShader code, is required to do the math correctly.

If TransformVectorMult is not the correct node that should be used, then what would be the alternative?

Please do not make multiple comments in a row, instead edit your comments, that way you won't cause notifications unnecessarily
To your question my answer is I don't know, but the documentation says that it is not this way, could be an error there, but this node is documented

Please do not make multiple comments in a row, instead edit your comments, that way you won't cause notifications unnecessarily
To your question my answer is I don't know, but the documentation says that it is not this way, could be an error there, but this node is documented
It is supposed to use a Vector3, see the code generating it:
	if (op == OP_AxB) {
		return "	" + p_output_vars[0] + " = (" + p_input_vars[0] + " * vec4(" + p_input_vars[1] + ", 1.0)).xyz;\n";
	} else if (op == OP_BxA) {
		return "	" + p_output_vars[0] + " = (vec4(" + p_input_vars[1] + ", 1.0) * " + p_input_vars[0] + ").xyz;\n";
	} else if (op == OP_3x3_AxB) {
		return "	" + p_output_vars[0] + " = (" + p_input_vars[0] + " * vec4(" + p_input_vars[1] + ", 0.0)).xyz;\n";
	} else {
		return "	" + p_output_vars[0] + " = (vec4(" + p_input_vars[1] + ", 0.0) * " + p_input_vars[0] + ").xyz;\n";
	}

In this code, you are mulipltying a vector4 by something adn returning a vec3. Why the truncation?

Because you are feeding a Vector4 to a method that takes Vector3? The problem here is not the truncation but the lack of an error or warning because you are giving it an incorrect argument

Because you are feeding a Vector4 to a method that takes Vector3? The problem here is not the truncation but the lack of an error or warning because you are giving it an incorrect argument

I understand what the current documentation says and I understand that what I am doing is "incorrect" according to the documentation. But then how are you supposed to do this calculation using the visual shader?
 vec4 world_pos = INV_PROJECTION_MATRIX * vec4(SCREEN_UV*2.0-1.0,depth_tex,1.0);

As I already answered, I don't know, all I know is that you are not using the method correctly as it currently exists

As I already answered, I don't know, all I know is that you are not using the method correctly as it currently exists

Ok well that why I was asked to create this issue. To bring up the fact that you cant do this using the TransformVectorMult node  as it currently exists and that the node might need changing, unless this is really the intended result and there is another more correct way to implement the calculation mentioned above

Then that's the area for a proposal as there's no bug here (except possibly for the lack of a warning/error)

Then that's the area for a proposal as there's no bug here (except possibly for the lack of a warning/error)

Ok. I was given incorrect instructions then. Can this be moved to proposal or do I have to recreate the post in proposal?

You need to fill out the details in the proposal as it is different
I am sorry you got the incorrect instructions, make sure you look at the instructions in the report form and the issue form to ensure the instructions you got were correct :)

Superseded by:

https://github.com/godotengine/godot-proposals/discussions/8375


Engine -> Framework rolls failing on "The status or check suite triage has failed."

Starting with https://github.com/flutter/flutter/pull/139518

This is failing on every PR:
https://github.com/flutter/flutter/actions/runs/7095454619/job/19312396481?pr=139531

Maybe related? https://github.com/flutter/flutter/pull/139533

Duplicate of https://github.com/flutter/flutter/issues/139511


Run content tests from raku/doc on templates

Now that content templates and web-specific pages exist in doc-website, we should run many of the content tests in raku/doc also on raku-doc-website.
We should do this in a way which avoids duplication of the tests and configs (e.g. list of allowed words).
Includes spelling, preferred phrasing, duplicated words, etc.

See https://github.com/Raku/doc/pull/4263

I don't see how to do this without some form of duplication of files
Is it possible to put the test utilities in a 'sub-repo'  so that both Raku/doc and Raku/doc-website can source the utilities from the same place? Then the utilities can be run in their own work flows.


⚠ Fox Sports has degraded performance

In d926381, Fox Sports (https://foxsports.com) experienced degraded performance:

HTTP code: 200
Response time: 1678 ms

Resolved: Fox Sports performance has improved in 6f74b91.


Cortina Activation - Doc Updates

Making updates to our docs according to the Cortina Activation, which will take place soon. Decided to put all those updates in one PR here.
list of changes:

add info about batched delegator rewards (fa0cabe6808ad18ab7a8175a02b57573525c80fe)
update the X-CHAIN index API endpoint (fb078c5fa8e4bcc0649c67397fead690f45874ae)
add X-chain avm.getBlock, avm.getBlockByHeight, and avm.getHeight endpoints (40bdec788b700c1284f9a89a9f76a7ced54badf5 , 843422163ffec78bd3500ede88abba0bab98f930 , abab97358cf9163826a2a151f3ae0e3e983deb49)
update the block gas limit from 8m to 15m as per update (8ccfc45c7c1cf3cd3088a7e875c9601c3edf5e91)
add a little FAQ to migration guide (6dca833450f2ef7c78f3e7d376c653cdf8ed9c05)

LGTM, will wait for Cortina release.


Module parameter support

Adds support for the module=example.com/foo flag described here.
This flag "strips" of the provided prefix from the output path. In effect it makes it possible to output the generated files in any sub folder, but the import paths, module and packages "line up".
Fixes #342

@akonradi @rmichela I'm not sure what the contribution guidelines for this project are, but I see that you two are the most active contributors so I thought I'll ask you.
I made this fix to support the module= flag described in the official protobuf documentation because my own usage of this plugin relies on it. I know this is alpha state, so I can live with using my own fork for now, but it would be nice to have it in the main repo as well

@akonradi @rmichela I'm not sure what the contribution guidelines for this project are, but I see that you two are the most active contributors so I thought I'll ask you.
I made this fix to support the module= flag described in the official protobuf documentation because my own usage of this plugin relies on it. I know this is alpha state, so I can live with using my own fork for now, but it would be nice to have it in the main repo as well

Is there anything holding this PR back?

Yes, and it's kind of clunky for me to keep my local fork (which I use in production) up to date with main

Not sure how to reach the maintainers though @sgtsquiggs. Seems like @akonradi is the most active

Sorry for dropping the ball on this. Code changes seem good; is there a way to add a test case for this?

I can give it a shot

Thanks! It doesn't have to be super complex, just something that will prevent CI succeeding if we accidentally break the module behavior somehow.

@akonradi I made this simple harness additions https://github.com/envoyproxy/protoc-gen-validate/pull/415/commits/1bb0581981ad41dfa00f2ba13eb736b7f9ad5bfb, but it didn't trigger the Circle build for some reason. Does Circle trigger on every push to a PR?

It definitely should be. Can you try pushing an empty commit to trigger it? If that doesn't work we can debug further.

That worked, but now the build task is failing with a cryptic error message

The make harness command is successful locally though. Both directly in the terminal and in a docker container.

The Bazel build is failing because the new proto wasn't listed as a dependency of a build rule. bazel build //tests/... should reproduce the error locally. Let me know if you need help fixing.

I'll take a crack at this today

I'm nearly finished - IMO it would be easier to remove the new inmodule and just apply the module param to other_package instead - two birds with one stone sort of situation. Otherwise I'm kind of adding inmodule to the test harness similarly to other_package but it isn't really testing anything new.

Ok, great @sgtsquiggs. I don't have any opinions on this, so just do whatever you feel is the best

I think I've got it working here: https://github.com/sgtsquiggs/protoc-gen-validate/tree/module-param

I'll create a new PR so I can get CI running. I had a few problems with java/python failures with make bazel-tests but I can't see how these changes affect that

@torbjornvatn if you reset your branch to mine and force-push, this should pass and we can celebrate :tada:

Time to 🍾 It worked!
Thanks for the help on this @sgtsquiggs

Thanks!


Add clang-tidy-16 support

This is limited by the base image we use. When we bump that, it will change the min/max versions of clang-tidy we have access to.
Unfortunately, I don't think it's possible to parameterise the base image so that users can choose themselves


Make changes in #322

I have made changes under the heading Our Organization brings together Professionals in Allied Health.

This has issues with it. You deleted  And


Feature/histogram ci plot

Just added one integration test

Not sure why pyproject.toml and poetry.lock were pushed together with the test file..... Hope it does not ruin the dev-backup branch....

@voremargot I think the conflict is resolved. You can feel free to merge it, if it looks good to you.


VFNET device error when run inference_detector

Hi everyone,
When a run the inference_detector to VFNET algorithm, I got this error message (only for VFNET, for ATSS ... no problems):
/usr/local/lib/python3.6/dist-packages/mmcv/parallel/_functions.py in forward(target_gpus, input)
71             # Perform CPU to GPU copies in a background stream
72             streams = [_get_stream(device) for device in target_gpus]
---> 73
74         outputs = scatter(input, target_gpus, streams)
75         # Synchronize with the copy stream
/usr/local/lib/python3.6/dist-packages/torch/nn/parallel/_functions.py in _get_stream(device)
117     if _streams is None:
118         _streams = [None] * torch.cuda.device_count()
--> 119     if _streams[device] is None:
120         _streams[device] = torch.cuda.Stream(device)
121     return _streams[device]
TypeError: list indices must be integers or slices, not torch.device
The device paramenter of init_detector is default ('cuda:0') and distributed=False. Can you help me?

I had the same problem with VFNet. I think it's a fundamental bug in the code of mmcv and nothing to do with the method. More specifically here:
https://github.com/open-mmlab/mmcv/blob/91a7fee03a3973a56cb5f687a6859ef0aaacf15e/mmcv/parallel/_functions.py#L72
However torch _get_stream formulates a list, therefore device should be integer and not torch.device  https://github.com/pytorch/pytorch/blob/18ae12a841bdc99c6cce65ac5c77cc1149dc8564/torch/nn/parallel/_functions.py#L111-L120
The fix is to pass device.index rather than device while calling _get_stream

I have the same issue when i run vfnet demo. how to solve it?

@JonathanAndradeSilva @ggalan87 I have found the reason.
in vfnet_r50_fpn_1x_coco.py test_pipline, change dict(type='DefaultFormatBundle') to dict(type='ImageToTensor', keys=['img'])
test_pipeline = [
    dict(type='LoadImageFromFile'),
    dict(
        type='MultiScaleFlipAug',
        img_scale=(1333, 800),
        flip=False,
        transforms=[
            dict(type='Resize', keep_ratio=True),
            dict(type='RandomFlip'),
            dict(type='Normalize', **img_norm_cfg),
            dict(type='Pad', size_divisor=32),
            # dict(type='DefaultFormatBundle'),
            dict(type='ImageToTensor', keys=['img']),
            dict(type='Collect', keys=['img']),
        ])


Various laws conversion

Army
Based on EU4 professionalism. If less than 60%, use law_peasant_levies; else, use law_professional_army
Bureaucracy

law_elected_bureaucrats: Universal Suffrage, Parliamentarism
law_appointed_bureaucrats: Centralized Bureaucracy, Sidhi Recruitment, Appointment by Committee, Subservient Bureaucrats, Zealous Administrators
law_hereditary_bureaucrats is the fallback

Child labor
At start, law_child_labor_allowed should be given to all countries
Church and State
law_state_religion should be given to all countries
Cultural acceptance

law_multicultural should be given to Empire Ranks with more than 8 accepted cultures
law_racial_segregation and law_national_supremacy should be considered the default (difference is whether slavery is still allowed or not)

Colonialism
Based on native policies:

law_colonial_exploitation if Native Repression Policy
law_colonial_resettlementif Native Trading Policy or Native Coexistence Policy
law_no_colonial_affairs if there is no policy (and thus no colonialism)

Separation of powers

law_oligarchy: Oligarchy (Republic), Plutocracy (Republic), Noble Elite (Republic), Revolutionary Republic, Free City, Trading City, Veche Republic, American Republic, Colonial Government, Dutch Republic, Kongsi Federation, Aristocratic Court, Legislative Sejm
law_elder_council: Tribal government
law_landed_voting: Autonomous Swiss Cantons, Landholders, Military Electorate, Parliamentarism, General Estates, States General, The Feuillant System
law_wealth_voting: Federal Republic, Citizenry
law_census_voting: Three Social Classes, The Two-Chamber System
law_anarchy: Pirate Republic, Peasants Republic, Self-Governing Colony, Sich Rada
law_universal_suffrage: Equal Electorate
law_autocracy: fallback

Economic system
Until sound mappings are found, fallback on law_traditionalism
Schooling
law_religious_schools to be given to all Protestant countries and to all countries who are tech tier 1 or 2.
Any other country will have law_no_schools
Free speech
Default to law_censorship. Use law_outlawed_dissent for countries at negative stability.
Governments

law_chiefdom: Tribal government
law_monarchy: Monarchy government
law_parliamentary_republic: Republic government with any of the following: Protectorate Parliament, Venetian Government, Noble Elite, Free City, Veche Republic, Colonial Government, Dutch Republic, Kongsi Federation, Autonomous Swiss Cantons
law_presidential_republic: Any other Republic government
law_theocracy: Theocracy government

Health system
law_no_health_system for all countries
Internal security
law_no_home_affairs for all countries
Slavery and serfdom
law_serfdom for countries that still have slavery accepted in EU4, law_serfdom_banned and law_slavery_banned for all remaining ones
Countries accepting slavery will also have:

law_debt_slavery if they lack colonists
law_slave_trade if they have colonists

Migration
law_no_migration_controls for all countries
Police
law_local_police for all countries with law_professional_army; law_no_police otherwise
Women rights
law_no_womens_rights for all countries
Taxation
law_land_based_taxation for all countries
Trade

law_mercantilism to all countries with more than 20% mercantilism
law_free_trade to Pirate Republics and Tribal governments, as well as all decentralized tags
law_protectionism to all remaining Western and Eastern countries
law_isolationism to all remaining centralized tags

Welfare
law_no_social_security for all countries

Update from the perspective of valid laws at the beginning of the game. All laws listed here are used by at least one country at the start of the game unless denoted. Completely omitted are laws that reqiure techs beyond what the most advanced country starts out with.
Power Sctructure
Governance Principles

law_chiefdom* Decentralized Only
law_monarchy
law_presidential_republic
law_parliamentary_republic
law_theocracy* Mutually exclusive with Total Separation

Note: All Decentralzied nations should get a preset of laws instead of the mapping process.
Distribution of Power

law_autocracy* Mutually exclusive with Elected Bureaucrats
law_oligarchy* Mutually exclusive with Elected Bureaucrats
law_landed_voting
law_wealth_voting
law_census_voting
law_universal_suffrage* No Vanilla country starts with this

Citizenship

law_national_supremacy
law_racial_segregation
law_cultural_exclusion* Mutually exclusive with Slave Trade & Legacy
law_multicultural* Mutually exclusive with all Slavery

Church and State

law_state_religion
law_freedom_of_conscience
law_total_separation* Mutually exclusive with Theocracy

Bureaucracy

law_hereditary_bureaucrats
law_appointed_bureaucrats
law_elected_bureaucrats* No Vanilla country starts with this, mutually exclusive with Oligarchy & Autocracy

Army Model

law_peasant_levies
law_professional_army
law_national_militia

Internal Security

law_no_home_affairs
law_national_guard
law_secret_police* No Vanilla country starts with this
law_guaranteed_liberties* No Vanilla country starts with this

Economy
Economic System

law_traditionalism* Mutually exclusive with Per Capita and Proportional Tax
law_interventionism* Mutually exclusive with Serfdom
law_agrarianism
law_laissez_faire* Mutually exclusive with Isolationism & Serfdom

Trade Policy

law_mercantilism
law_protectionism
law_free_trade
law_isolationism* Mutually exclusive with Lazzez-Faire

Taxation

law_consumption_based_taxation
law_land_based_taxation
law_per_capita_based_taxation* Mutually exclusive with Traditionalism
law_proportional_taxation* No Vanilla country starts with this, Mutually exclusive with Traditionalism

Colonzation

law_no_colonial_affairs
law_colonial_resettlement
law_colonial_exploitation

Policing

law_no_police
law_local_police
law_dedicated_police

Education System

law_no_schools
law_religious_schools
law_private_schools
law_public_schools

Health System

law_no_health_system
law_charitable_health_system

Human Rights
Free Speech

law_censorship
law_right_of_assembly

Labor Rights

law_serfdom_banned
law_serfdom * Mutually exclusive with Interventionism and Laissez-Faire

Children's Rights

law_child_labor_allowed

Rights of Women

law_no_womens_rights
law_women_own_property

Welfare

law_no_social_security
law_poor_laws

Migration

law_no_migration_controls
law_migration_controls
law_closed_borders

Slavery

law_slavery_banned
law_debt_slavery* Mutually exclusive with Multiculturalism
law_slave_trade* Mutually exclusive with Multiculturalism & Cultural Exclusion
law_legacy_slavery* Mutually exclusive with Multiculturalism & Cultural Exclusion


Code from article won't compile

The code in this article won't compile.
I get the error
Class 'ExtendedRepositoryImpl' must either be declared abstract or implement abstract method 'deleteAllById(Iterable<? Extends ID>)' in 'CrudRepository'

The // ... in the article implies that more code is required, such as all methods needed by the interface

Hey, @peterbayerle.
deleteAllById() is already implemented by SimpleJpaRepository, so the snippet in section 3 should compile just fine without implementing it yourself.
Make sure you are extending SimpleJpaRepository and your imports are correct, like in the file you mentioned.


Question about the docs wording

The docs say:

The init.py file for the namespace package needs to contain only the following:
Every distribution that uses the namespace package must include an identical init.py

I wonder:

does "only" mean "a semantically equivalent set of instructions that appear first in the file"?
does "identical" mean "semantically equivalent" or "character-by-character identical"?

To give an example, consider the two following __init__.py modules. Are they valid paired-modules for a non-native namespace package?
# arbitrary comments like:
# pylint: disable=missing-module-docstring
__path__ = __import__("pkgutil").extend_path(__path__, __name__) # type: ignore
# note the type ignore comment as well

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

Note how neither the textual contents nor the AST is the same, but how they actually do the same thing.
Does it still work if there are other statements after extending __path__?
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
print("done extending __path__")

Don't hesitate to redirect me to the code responsible for this :slightly_smiling_face:

Thanks!
I'd gladly open a PR, but I'm still not sure about the exact requirements for the __init__.py file contents. Should I open the exact same issue on https://github.com/pypa/packaging.python.org? I see that you're

looking into an overhaul of the guide

so that might not be necessary? Maybe easier for you to track if it's over there. Let me know!
In the meantime I'll run some experiments.

OK, interesting.
Given the following file tree:
.
├── sp1
│   └── np
│       ├── __init__.py
│       └── moda.py
└── sp2
    └── np
        ├── __init__.py
        └── modb.py

(sp stands for search path, np stands for namespace package)
sp1/np/__init__.py
print("from sp1")
# arbitrary comments like:
# pylint: disable=missing-module-docstring
__path__ = __import__("pkgutil").extend_path(__path__, __name__) # type: ignore
# note the type ignore comment as well
varx = 1
vary = True

sp2/np/__init__.py
print("from sp2")
varx = 2
varz = True

Here is the behavior:
% PYTHONPATH=sp1:sp2 python
Python 3.11.5 (main, Aug 26 2023, 14:36:58) [GCC 13.2.1 20230801] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import np
from sp1

Here we see that only sp1/np/__init__.py was executed.
It make sense as it appeared first in the search paths.

>>> np.__path__
['/home/pawamoy/t/sp1/np', '/home/pawamoy/t/sp2/np']

Still, Python correctly finds np to be a namespace package,
with sp2/np a part of it. It's probably thanks to the extend_path call
in sp1/np/__init__.py. Interestingly, though the docs say we need
to put the same contents in all __init__.py modules,
it's actually not strictly necessary.
Obviously, to make it work for any given search path order,
all of them must call extend_path indeed.

>>> from np import moda, modb
>>> moda.__file__
'/home/pawamoy/t/sp1/np/moda.py'
>>> modb.__file__
'/home/pawamoy/t/sp2/np/modb.py'

Here we confirm that we can find both modules,
coming from both namespace packages.

>>> np.varx
1
>>> np.vary
True
>>> np.varz
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'np' has no attribute 'varz'. Did you mean: 'varx'?

Here we confirm again that only the first __init__.py module was executed.

With this I believe I'll be able to send a PR :slightly_smiling_face:


fix: bug 2026 endsession edit lose tags and create extra train dialog

:tada: This PR is included in version 0.352.22 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Proposed change to JCDP standard: Allow the inclusion of ancillary species sightings data which are recorded but not currently submitted

Introduced during WGJCDP meeting on April 2023.
Allow the inclusion of ancillary species sightings data which are recorded but not currently submitted; seals, shark and fish (e.g. basking shark and blue fin tuna), seabirds, etc.

There needs to be consistent within the database, if this change was to be made existing datasets may need to be updated to include these data which has a resourcing implication.

Final list of ancillary species is now available on the WG SharePoint
https://community.ices.dk/ExpertGroups/WGJCDP/2023%20Meeting%20Documents/04.%20Working%20documents/Vocabulary_Sightings_Species%20list_v2.xlsx
What are the next steps needed to add these to the species vocabulary?

[ ] Update the JCDP species vocabulary list
[ ] Update the data template
[ ] Update the data standard document

@cmspinto @pcrjoana @neil-ices-dk @NikkiTaylorJNCC

@neil-ices-dk @cmspinto @pcrjoana @NikkiTaylorJNCC
Hi all. I wanted to check on progress of adding the additional species to the JCDP? Is there anything else needed for this to be implemented?

@pcrjoana

Has been implemented into the portal and template.
Need to update the standard and promote the change

To do: check the standard is updated


Migration1706272837UpdateProductExportForeignKey fails because of incorrect SQL-Syntax

PHP Version
8.2
Shopware Version
<IP_ADDRESS>
Expected behaviour
php bin/console database:migrate --all
to complete without any errors.
Actual behaviour
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version
  for the right syntax to use near 'CONSTRAINT `fk.product_export.sales_channel_domain_id`' at line 1

How to reproduce
php bin/console database:migrate --all
the issue can be fixed by changing the update method to this:
$connection->executeStatement('ALTER TABLE `product_export` DROP FOREIGN KEY `fk.product_export.sales_channel_domain_id`;');

$connection->executeStatement(
    <<<'SQL'
    ALTER TABLE `product_export`
        ADD CONSTRAINT `fk.product_export.sales_channel_domain_id`
            FOREIGN KEY (`sales_channel_domain_id`) REFERENCES `sales_channel_domain` (`id`) ON DELETE RESTRICT ON UPDATE CASCADE;
SQL
);

Do you maybe use MySQL 5.7?

@philipschikora DROP CONSTRAINT syntax should be supprted since MySQL 8.0.19.
But because we support MySQL 8.0 and up we will change it to DROP FOREIGN KEY. Thanks for raising this.

Fixed
https://github.com/shopware/shopware/commit/5356a5aefda744b6ae2c73f094d4f6e91fb2d455


Android clicking input type=file brings up system file browser, not camera options

Bug Report
Problem
When clicking on an html type="file" input a system file picker appears instead of camera options.

What is expected to happen?
If I perform the same action in the system browser I get the expected dialog:

Version information
"cordova-android": "^8.0.0",
"cordova-plugin-camera": "^4.1.0",
"cordova-plugin-file": "^6.0.2",
"cordova-plugin-file-transfer": "^1.7.1",

cordova-cli 9.0.0
Full package.json and config.xml here
Checklist

[x] I searched for existing GitHub issues
[x] I updated all Cordova tooling to most recent version
[x] I included all the necessary information above

this is not a bug in this plugin, input file is handled by cordova-android. You already reported it there https://github.com/apache/cordova-android/issues/816

@jcesarmobile @alexcroox do you know / found a way to fix it ?


environment variable to enable logging

I am trying to use this language server outside of VS Code. I have an initial JSON-RPC message in a text file and I am using < to feed it to Microsoft.Python.LanguageServer, but the executable just hangs. It would be great if I could use an environment variable to enable logging and get some idea of what is going on.

Language servers can make requests back to the client. This language server does in order to fetch configuration, so long as the client has declared support for the call (rather than waiting for a config change notification).
Are you declaring that the client supports that call in your initialize call? The LS will likely block waiting, though should time out.

I am running Microsoft.Python.LanguageServer < initialize.json with the following as the contents of my initialize.json file, so I was hoping/expecting that a request from more data from the client would be written to stdout (or an error to stderr):
Content-Length: 5713

{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "initializationOptions": {
      "interpreter": {
        "properties": {
          "InterpreterPath": "/usr/local/bin/python3"
        }
      }
    },
    "rootPath": null,
    "rootUri": "file:///tmp",
    "capabilities": {
      "workspace": {
        "applyEdit": true,
        "workspaceEdit": {
          "documentChanges": true,
          "resourceOperations": [
            "create",
            "rename",
            "delete"
          ],
          "failureHandling": "textOnlyTransactional"
        },
        "didChangeConfiguration": {
          "dynamicRegistration": true
        },
        "didChangeWatchedFiles": {
          "dynamicRegistration": true
        },
        "symbol": {
          "dynamicRegistration": true,
          "symbolKind": {
            "valueSet": [
              1,
              2,
              3,
              4,
              5,
              6,
              7,
              8,
              9,
              10,
              11,
              12,
              13,
              14,
              15,
              16,
              17,
              18,
              19,
              20,
              21,
              22,
              23,
              24,
              25,
              26
            ]
          }
        },
        "executeCommand": {
          "dynamicRegistration": true
        },
        "configuration": false,
        "workspaceFolders": true
      },
      "textDocument": {
        "publishDiagnostics": {
          "relatedInformation": true,
          "tagSupport": true
        },
        "synchronization": {
          "dynamicRegistration": true,
          "willSave": true,
          "willSaveWaitUntil": true,
          "didSave": true
        },
        "completion": {
          "dynamicRegistration": true,
          "contextSupport": true,
          "completionItem": {
            "snippetSupport": true,
            "commitCharactersSupport": true,
            "documentationFormat": [
              "markdown",
              "plaintext"
            ],
            "deprecatedSupport": true,
            "preselectSupport": true
          },
          "completionItemKind": {
            "valueSet": [
              1,
              2,
              3,
              4,
              5,
              6,
              7,
              8,
              9,
              10,
              11,
              12,
              13,
              14,
              15,
              16,
              17,
              18,
              19,
              20,
              21,
              22,
              23,
              24,
              25
            ]
          }
        },
        "hover": {
          "dynamicRegistration": true,
          "contentFormat": [
            "markdown",
            "plaintext"
          ]
        },
        "signatureHelp": {
          "dynamicRegistration": true,
          "signatureInformation": {
            "documentationFormat": [
              "markdown",
              "plaintext"
            ],
            "parameterInformation": {
              "labelOffsetSupport": true
            }
          }
        },
        "definition": {
          "dynamicRegistration": true,
          "linkSupport": true
        },
        "references": {
          "dynamicRegistration": true
        },
        "documentHighlight": {
          "dynamicRegistration": true
        },
        "documentSymbol": {
          "dynamicRegistration": true,
          "symbolKind": {
            "valueSet": [
              1,
              2,
              3,
              4,
              5,
              6,
              7,
              8,
              9,
              10,
              11,
              12,
              13,
              14,
              15,
              16,
              17,
              18,
              19,
              20,
              21,
              22,
              23,
              24,
              25,
              26
            ]
          },
          "hierarchicalDocumentSymbolSupport": true
        },
        "codeAction": {
          "dynamicRegistration": true,
          "codeActionLiteralSupport": {
            "codeActionKind": {
              "valueSet": [
                "",
                "quickfix",
                "refactor",
                "refactor.extract",
                "refactor.inline",
                "refactor.rewrite",
                "source",
                "source.organizeImports"
              ]
            }
          }
        },
        "codeLens": {
          "dynamicRegistration": true
        },
        "formatting": {
          "dynamicRegistration": true
        },
        "rangeFormatting": {
          "dynamicRegistration": true
        },
        "onTypeFormatting": {
          "dynamicRegistration": true
        },
        "rename": {
          "dynamicRegistration": true,
          "prepareSupport": true
        },
        "documentLink": {
          "dynamicRegistration": true
        },
        "typeDefinition": {
          "dynamicRegistration": true,
          "linkSupport": true
        },
        "implementation": {
          "dynamicRegistration": true,
          "linkSupport": true
        },
        "colorProvider": {
          "dynamicRegistration": true
        },
        "foldingRange": {
          "dynamicRegistration": true,
          "rangeLimit": 5000,
          "lineFoldingOnly": true
        },
        "declaration": {
          "dynamicRegistration": true,
          "linkSupport": true
        }
      }
    },
    "trace": "off",
    "workspaceFolders": null
  }
}

I just tried changing it to "trace": "verbose" (and Content-Length: 5717), but it still just hangs with no output.

Are you certain your JSON-RPC is correct? That header needs to be terminated with \r\n. Best to use a real JSON-RPC client instead of a hand-rolled one or piping. I'm not even certain a < is going to work if it's adding extra newlines at the end, for example. JSON-RPC is not conducive to this sort of thing.
As for adding environment variables to enable logging, maybe, but I'm not certain how that'd work given our logging is via JSON-RPC as well, so if the input is wrong and our JSON-RPC library is hanging then it may not be able to print anything either...

Ah, thanks, I forgot about the \r\n requirement, so this is almost definitely well-formatted...

To clarify, this isn't JSON-RPC per-se (JSON-RPC is really just the message format), but LSP uses a specific HTTP-style encoding with its own requirements. I'd expect us to hang; we had bugs a long time ago when our JSON-RPC library in an update started to expect a BOM (which is very wrong for UTF-8 encoded text...) which led to similar hangs and was "fun" to debug.

Here is a simple repro: https://gist.github.com/bolinfest/2474367e6f923fdb98df1c409616c8ac
When I pipe that to a simple LSP based off the code sample from https://code.visualstudio.com/api/language-extensions/language-server-extension-guide#explaining-the-language-server, I see a response written to stdout. When I try the same thing with Microsoft.Python.LanguageServer, I get no response.

I also just tried this my local copy of pyls and it worked:
$ python3 -m pyls -vvvv --log-file /tmp/pyls.log < /Users/mbolin/src/test-lsp/initialize.rpc
Content-Length: 641
Content-Type: application/vscode-jsonrpc; charset=utf8

{"jsonrpc": "2.0", "id": 0, "result": {"capabilities": {"codeActionProvider": true, "completionProvider": {"resolveProvider": false, "triggerCharacters": ["."]}, "documentFormattingProvider": true, "documentHighlightProvider": false, "documentRangeFormattingProvider": true, "documentSymbolProvider": true, "definitionProvider": true, "executeCommandProvider": {"commands": []}, "hoverProvider": true, "referencesProvider": true, "signatureHelpProvider": {"triggerCharacters": ["(", ","]}, "textDocumentSync": {"openClose": true, "willSave": true, "change": 2, "willSaveWaitUntil": true, "save": {"includeText": true}}, "experimental": {}}}}/Users/mbolin/fbsource/xplat/vscode/vscode-extensions/pyls/VendorLib

Oh, hm, I just realized that processId is unspecified, is that the issue?

No, that's an optional setting which language servers can use to watch their parent process and exit if it goes away.


Add spec for Transducers

Hi! We've been talking about Transduce and Transducers in the Sanctuary Gitter channel and there are mixed thoughts. There's definitely curiosity and value in them since there's general interest expressed around the internet and on a variety of other mediums, so I'm placing this issue to ponder around the concept, and perhaps eventually find a suitable solution together.
Some links follow.

For a working implementation of Transduce, we can look at Ramda's: http://ramdajs.com/docs/#transduce which has it's type signature as: (c → c) → (a,b → a) → a → [b] → a.
For a guided trip to Transducers in JavaScript: https://github.com/getify/Functional-Light-JS/blob/master/apA.md
For Clojure docs on Transducers: https://clojure.org/reference/transducers
For a journey into their type definition through Haskeller's eyes: http://hypirion.com/musings/haskell-transducers
For a great talk about Transducers at Strange Loop, by Rick Hickey: https://www.youtube.com/watch?v=6mTbuzafcII

This issue has not gained traction. Are you interested in pursuing this, @sadasant?


Add config bootstrapper

This PR adds config-bootstrapper to prombench. this bootstraps configmaps used in various areas in prombench.
upgrading of prow with the updateconfig will be done in a follwing pr. this will allow updating of configmaps directly when prs are merged.
closes #206
closes #223  ( base image with go binary still needs to be added )
also adds GOOGLE_APPLICATION_CREDENTIALS to the readme for #222

seems like many files are just renamed. Can you try to use git mv so that it shows the diff only as a file rename
is this still required? github does show the files that are only renamed like this:

manifests/cluster-infra/1_gcloud_rolebinding.yaml → manifests/cluster-infra/1a_gcloud_rolebinding.yaml

image example:

cc @krasi-georgiev

will this allow us to use just the config updater without the other prow components?
If not which are the minimal components we need to have this working?

These are the only config files needed to run config-bootstrapper , the configmap prow-config added in plugins.yaml is not even required but I added it because we'll need it anyway when adding the updateconfig plugin for prow
/prombench/config/prow/config.yaml
prowjob_namespace: default
pod_namespace: default
log_level: debug

/prombench/config/prow/plugins.yaml
config_updater:
  maps:
    config/prow/config.yaml:
      name: prow-config
    config/prow/plugins.yaml:
      name: prow-config
    config/prometheus-meta/prometheus.yaml:
      name: prometheus-meta
    config/grafana/prometheus-datasource.yaml:
      name: grafana-datasources
    config/grafana/prometheus-dashboard.yaml:
      name: grafana-dashboard-provision
    config/grafana/dashboards/*.json:
      name: grafana-dashboards

no other prow components is needed. That's why config-bootstrapper is added in the manifest/cluster-infra directory before any prow component is even added.

The prow configmaps added here are not used by prow. that might be a confusion,  I'll add a comment in the new pr.

My question was more if we would still need to run a full prow installation even after we migrate to GH actions? If that is the case maybe there is some other standalone tool that can do the same job with far less maintenance overhead.

Can you also explain in more details the problem we are trying to solve.
IIRC one problem was that the configs when deploying a test are in the image itself.
https://github.com/prometheus/prombench/issues/117
This probably doesn't even need solving as when we build the images as part of the CI the tests will always use the latest image which will include the most recent configs.
The second problem is probably when we have changes to existing config maps. This can probably be solved by something like https://github.com/WanderaOrg/git2kube

no we won't need to run a full prow installation to run config-bootstrapper we don't need any other prow component. config-bootstrapper is not a core prow component itself.

IIRC one problem was that the configs when deploying a test are in the image itself.

This PR does not attempt to solve this, the statefulset prombench tests pr(will be sending soon) attempts to solve that by cloning and mounting that volume for prombench to use. On the other hand, when using github actions, we should be able to clone the latest prombench and use the manifests/prombench and Makefile from it.

Can you also explain in more details the problem we are trying to solve.
Since we're adding more components to prombench, having a way to store configurations in their native form helps. for eg. now we can directly update grafana dashboard json without having to add any extra escape sequence for golang templates.

secondly after we migrate to GitHub actions we'll only need to have the hook prow component if we want to have the update-config plugin (which will update configmaps directly from github merges) . config-bootstrapper is a k8s job does not need any prow component and only updates the configmaps during initial start.

just realized that in the case where we use the prombench image with github actions it would have no way to access the manifests/ files as the command runs within the github action env and NOT in the Google cloud cluster.

to solve this @nikita-mk 	need to create another action "clonePrombenchRepo" that will clone the prombench repo and save it in /github/workspace/prombench
this way the prombenchDeploy action would be able to access the manifest files.
So the makefile can be changed to something like:
MANIFESTS               ?= manifests/prombench
# Set the env only if not set.
# This allows it to set it from github actions to "/github/workspace/prombench/manifests/prombench",
# but still use the makefile without a docker image locally.

nodepool_create:
	$(PROMBENCH_CMD) gke nodepool create -a ${AUTH_FILE} \
		-v ZONE:${ZONE} -v PROJECT_ID:${PROJECT_ID} -v CLUSTER_NAME:${CLUSTER_NAME} -v PR_NUMBER:${PR_NUMBER} \
		-f ${MANIFESTS}/nodepools.yaml


Time Incorrect - Fix in Progress

Bug Report (Issue #1) :
Time Incorrect - Fix in Progress
Upon a user selecting a time and creating a meetup, the TIME and DATE are stored, then meetups are fetched from backend.
Currently working on the refactor front-end branch, API is temporarily set to localhost:3000/api instead of Heroku deployed API. I'm in the process of adding features and refactoring the backend as well, on the current back-end branch: refactor.
Bug Description:
Time is not rendered correctly on Meetups show page
Noticed this bug while I was refactoring (refactor branch) both the frontend and the backend and adding additional features locally.
I'm currently in the process of debugging and fixing it.
Information found upon debugging:

Upon submission, TIME and DATE are sent to the backend (localhost:3000/api/meetups/new).
TIME and DATE is then stored in the PostgreSQL meetups table
TIME is stored as a TIME PostgreSQL data-type correctly (verified by checking SQL table)
Since TIME is stored correctly, it must be an issue in React upon parsing of data
Moment module (react-moment) must be parsing This.props.time incorrectly

Fixed Issue (Issue Closed)

Moment was parsing time incorrectly, there was a 5 hour offset no matter what timezone I set it to


Update obs4MIPs names to ESGF's in Schlunder20esd recipe

Description

Following discussion here https://github.com/ESMValGroup/ESMValTool/issues/2974
CERES-EBAF Ed2-7 is not available on ESGF anymore.
CERES-EBAF Ed2-8 is available for variable rlut, rlutcs, rsdt, rsut, rsutcs.
This PR removes the version facet for CERES-EBAF which fix automatic download from ESGF.
AIRS RetStd-v5 ['hus'] >> AIRS-2-1
AIRS-2-0 v2 ['hur'] >> AIRS-2-0
CERES-EBAF Ed2-7  >> CERES-EBAF
GPCP-SG v2.2 ['pr'] >> GPCP-V2.2

Before you get started

[x] ☝ Create an issue to discuss what you are going to do

Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

[x] 🛠 This pull request has a descriptive title
[ ] 🛠 Code is written according to the code quality guidelines
[x] 🛠 Documentation is available
[ ] 🛠 Tests run successfully
[ ] 🛠 The list of authors is up to date
[x] 🛠 Any changed dependencies have been added or removed correctly
[ ] 🛠 All checks below this pull request were successful

New or updated recipe/diagnostic

[ ] 🧪 Recipe runs successfully
[x] 🧪 Recipe is well documented
[x] 🧪 Figure(s) and data look as expected from literature
[x] 🛠 Provenance information has been added

New or updated data reformatting script

[ ] 🛠 Documentation is available
[ ] 🛠 The dataset has been added to the CMOR check recipe
[ ] 🧪 Numbers and units of the data look physically meaningful

To help with the number of pull requests:

🙏 We kindly ask you to review two other open pull requests in this repository

Thanks for pointing this out!

Thanks for the updates! Could you please merge the main branch from this GitHub git repository into your branch? That should solve the failing tests. For example, if you have added this repository under the name upstream, you can do this by running the command git pull upstream main.


Add "Release of Azure Cloud Upload feature" entry

 P2: Blog about new azure upload feature

Deploy preview for openbuildservice ready!
Built with commit 4359d4217293676fea8f4f85462546cf0d936cf2
https://deploy-preview-184--openbuildservice.netlify.com

@hennevogel, @dmarcoux, your suggestions were applied. Please re-review.