card draft

Is your feature request related to a problem? Please describe.
A good feature in Trello and even some small task manager self-hosted solutions like Planka is that ability to draft cards if not added so that it does not get discarded if you click anywhere
Describe the solution you'd like
The solution will be just adding a card draft feature when adding a new card

I had thought about implementing this when I was working on the card composer but ended up liking that it just cancels the task name when clicking away.
I'll give this some thought - I might just switch it to work the way you described or maybe add it as an option?

After some thought - Im going to go ahead and implement this. The current plan is to include it in the next 0.3.0 release.

I think this is better as I think it is a very reliable feature. personally I moved to use taskcafe and sometimes I click by mistake on other parts and lose whatever I wrote.

I have marked this task as a good first issue.
I would personally implement the "draft" state in the Board component (frontend/src/Projects/Project/Board/index.tsx).
Relavent files

frontend/src/Projects/Project/Board/index.tsx
frontend/src/shared/components/Card/index.tsx
frontend/src/shared/components/Lists/index.tsx


Proposal: podcast:alteratefeed  for alternate versions of the same show (Video, Audio, Low-bitrate, etc...

Very similar to the podcast:alternateenclosure, but this new tag would be at the Channel level.  This could be used to specify an RSS feed instead of an enclosure for a Video, Audio, Low Bitrate, alternate language and other versions of the podacst but in a separate RSS feed.  This gives the option of doing a 2nd feed tied to the original feed for those who would rather do second feeds (or more) instead of by the episode using the podcast:alternateEnclosure tag.
I'm not a coder so I would need someone to provide the detailed code for this tag. I think it could be very simple.

I wouldn't classify alternate language, audio/video and alternate bitrate as the same feature. I think audio/video and bitrate present different encodings of the exact same recording with the same transcript and chapters and the same item titles and descriptions, while alternate language would constitute a new recording with different transcripts and chapters, and different item titles and descriptions.
So I would classify these as two separate features with their own requirements. For the alternate audio/video or bitrate, I personally think alternateEnclosure is enough. It would complicate crawlers and indexers to have different structural ways of achieving the same thing. For example, it would be undesirable to crawl and index 10 feed entries for 10 different combinations of bitrate and audio/video variations all with identical titles and descriptions, that would be wasteful, and so extra effort would be needed by those coding the crawlers and indexers to merge the alternates into one entry. It would also potentially be more work for the podcaster to maintain 10 feeds all with identical item titles and descriptions, and more wasteful to store 10 feeds that are 95% identical in titles, descriptions and chapter/transcript links except for the enclosures.
For the alternate languages, the proposed feature could be justified. However I think it could be a helpful part of the proposal to reuse the same item guids for alternate feeds. If a podcast app provides a feature to show a menu of available alternative languages and then switch between them, and the user is currently viewing a particular episode, it would make sense for it to be able to find the corresponding episode in the other feed.

I would push back quite hard on this proposal, Mike, sorry.
The ideal should be one RSS feed for one show, which alternateEnclosure offers.
If you do a search for The New Media Show, you should find one entry in your podcatcher. When you open that, it should offer all the available versions for shows.
Having multiple RSS feeds for one show puts strain on directories to keep them all up to date; splits the equivalent of Google juice for podcasts making them harder to recommend or promote; and is just plain bad.
What I would like though is some form of metadata within the alternateEnclosure as to whether it's the same audio as the primary enclosure. That would enable any podcast app to mimic YouTube Music's "AUDIO / VIDEO" switch, as seen below - a simple way to switch between the video and audio versions. Currently we don't have metadata helping the app know that this is identical audio, or a different edit. Perhaps this is something for @agates to look at.

I'd agree that different languages is worth linking to. However, it looks like there is already a standard within RSS for this, and looks like:
<link rel="alternate" hreflang="en" type="application/rss+xml" title="English" href="https://domain/rss/">
<link rel="alternate" hreflang="uk" type="application/rss+xml" title="Ukranian" href="https://domain/ua/rss/">
<link rel="alternate" hreflang="ru" type="application/rss+xml" title="Russian" href="https://domain/ru/rss/">

Does that fix the issue?

What I would like though is some form of metadata within the alternateEnclosure as to whether it's the same audio as the primary enclosure. That would enable any podcast app to mimic YouTube Music's "AUDIO / VIDEO" switch, as seen below - a simple way to switch between the video and audio versions. Currently we don't have metadata helping the app know that this is identical audio, or a different edit. Perhaps this is something for @agates to look at.

Seems to already be covered with 'rel'.

rel (optional) Provides a method of offering and/or grouping together different media elements. If not set, or set to "default", the media will be grouped with the enclosure and assumed to be an alternative to the enclosure's encoding/transport. This attribute can and should be the same for items with the same content encoded by different means. Should be limited to 32 characters for UX.

Seems to already be covered with 'rel'.

Oh yes! Thank you.

Blubrry for many historical reasons, will "never" adopt alternate enclosure; over 100k shows have been trained in 1 show = 1 feed we are not adding a dynamic that shows have to do twice as much work to be able to support Apple and other platforms.
But we would be able to support a RemoteItem as a podcast:alternatefeed versus what Mike described as a podcast:alternateenclosure
The idea is you point at the alternate feed, and each could have a reason code
Video
Lower Bandwidth
Alternate Language
ETC.
We will be pushing hard for this adoption.

James the reason we will never do Alternate Enclosures is simple. For podcasters with a Audio and Video podcast they still have to have two feeds no mater what. They have to have it for Apple etc  I am not making podcasters do double the work.
AKA Podcasts still have to have two feeds for non-podcast 2.0 platforms and they are still in the high majority. Asking a podcaster to add an  Audio file to his video feed as an alternate enclosure and add the video file to the audio feed is asking for trouble in screwing stuff up.
Again we will never adopt it. But we can support a RemoteItem; Podcast:Altternatefeed. because it does not break 18 years  of how podcasting agreed and was adopted as one feed one enclosure.

over 100k shows have been trained in 1 show = 1 feed

Yep. My thoughts exactly. Not "1 show but available in two feeds, one with video and one with audio..." which is what you're pushing for.
The good news is that I don't make the rules. But I don't like the idea of having many different RSS feeds for the same show. That way madness lies, in my honest opinion - notwithstanding the point you make about Apple Podcasts not supporting the alternateEnclosure tag (yet).

Apple will "never" support the alternate enclosure tag for a good reason. They want more listings, not less, in their directory. You will never hear them report a decline in the total number of podcasts in their directory. I'm not worried about Apple honestly I am more concerned about the 18 years of 1 show = 1 feed standard that was argued out long ago.
Not saying it was the correct argument but it was battled about long ago and is why things are the way there are now.

Apple will never do a lot of things.  Help those that will.  This is not their sandbox.

Right, but Apple does do video podcasts and Audio podcasts.  2 feeds.  Why not give people a choice on how they want to do the same thing?

They want more listings, not less, in their directory. You will never hear them report a decline in the total number of podcasts in their directory.

Apple almost never comment on the number of podcasts in their directory. I doubt they care.
However, Apple does do everything for the user. The recent change in download behaviour was entirely driven by less battery life and less storage use (and had nothing to do with any discussions with the industry, despite claims made elsewhere). It is absolutely Apple's "thing" to make it easy for one show = one feed (and to offer the user the option of selecting video/audio within that feed). That's the right thing for the user.
There's absolutely no reason why you can't have a "master" podcast of "The New Media Show" which is MP3 but also contains the video as an alternateEnclosure; and then to add a "The New Media Show Video Version" if you really want to still be backwards compatible with backwards podcast apps. No need to block a proposal about alternateEnclosure; nor to fill directories up with badly duplicated material.

@geeknews's point is that alternate enclosures cause double the work. But it's also possible that separate feeds (for video versus audio) cause double the work. It all depends on the publishing system. PowerPress, for example, makes it easy to manage multiple feeds from a single WordPress post. But other publishing systems, like Libsyn, don't let you make multiple feeds with the same post.
Here's my suggestion for how to reconcile all of this.

@jamescridland pointed out the existing standard for dealing with different languages. So that seems settled, especially since different media languages need different text languages.
alternateEnclosure would be best for the same format (audio or video) but different encoding (MP3 and AAC, high bitrate and low bitrate, HD and SD, etc.). That makes me wonder if we should rename the tag for clarity. Like alternateEncoding.
<link rel="alternate" media="video" … /> would be best for linking from the audio feed to the separate video feed (and vice versa with setting it to media="audio" on the video feed).


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter yamaha for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.yamaha
   -
ERRORS:

[ ] :heavy_exclamation_mark: [E162] js-controller 2.0.0 listed as dependency but 4.0.24 is required as minimum, 5.0.19 is recommended. Please update dependency at io-package.json.
[ ] :heavy_exclamation_mark: [E204] Version "0.4.1" listed at common.news at io-package.json does not exist at NPM. Please remove from news section.

WARNINGS:

[ ] :eyes: [W028] Minimum node.js version 18 recommended. Please adapt "{'engines' : { 'node' >= '16' } }" at package.json.
[ ] :eyes: [W044] dependency should not require a specific version. Use "~1.2.3" or "^1.2.3" syntax. Please update "peer-ssdp:0.0.5"
[ ] :eyes: [W105] Missing suggested translation into uk of "common.titleLang" in io-package.json.
[ ] :eyes: [W109] Missing suggested translation into uk of "common.desc" in io-package.json.
[ ] :eyes: [W145] Missing suggested translation into uk of some "common.news" in io-package.json.
[ ] :eyes: [W181] "common.license" in io-package.json is deprecated. Please define object "common.licenseInformation"
[ ] :eyes: [W184] "common.materialize" is deprecated for admin >= 5 at io-package.json. Please use property "adminUI".
[ ] :eyes: [W184] "common.title" is deprecated and replaced by "common.titleLang". Please remove from io-package.json.
[ ] :eyes: [W513] "gulpfile.js" found in repo! Think about migrating to @iobroker/adapter-dev package
[ ] :eyes: [W853] .npmignore found - consider using package.json object "files" instead.

SUGGESTIONS:

[ ] :pushpin: [S519] Consider adding plugin "@alcalzone/release-script-plugin-manual-review".
[ ] :pushpin: [S522] Please consider migrating to admin 5 UI (jsonConfig).

Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
Warnings reported by repository checker should be reviewed. While some warnings can be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
Suggestions reported by repository checker should be reviewed. Suggestions can be ignored due to a decision of the developer but they are reported as a hint to use a configuration which might get required in future or at least is used be most adapters. Suggestions are always optional to follow.
You may start a new check or force the creation of a new issue at any time by adding the following comment to this issue:
@iobroker-bot recheck
@iobroker-bot recreate
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence
Last update at Fri, 06 Sep 2024 11:51:47 GMT

Issue outdated due to RECREATE request. Follow up issue #476 has been created.
This issue will be closed.
your
ioBroker Check and Service Bot


[BUG] [Tooltips] Spawn Eggs - DAMAGE DISTRIBUTION - wrong value

Spawn Egg [visual / informational bug]

Show False Tool Tip Information "DAMAGE DISTRIBUTION" only [Mob Resistances works fine]

Should be: "minecraft:polar_bear;0.25;0;0.75"

But is: "100% b"

Note: All other Spawn Eggs have the same problem -> 100% B damage, other damage types are not shown

Notes:
-- The Console works fine, the damage is split by S,P,B like in the config - so its only a visual / informational bug
-- So Resistance works like they should
-- Damage calculation works (mobs with resistance take less damage - so the console informations are right)
-- B Immunity on slime works, it takes no B damage at all

The damage distribution is for the spawn egg itself, not for the mob spawned. Yeah that's a little misleading, but that's technically correct behaviour. Probably better if it showed mob damage instead...

Ohh then its a miss reading on my side... 😅
Sorry for that.
But is there a way to see the Damage the Mob is causing on the spawn egg or somewhere else? 🤔
Maybe it can be put into the Resistance section of the mob egg.


buildPythonApplication shouldn't add dependencies to PATH and PYTHONPATH

Issue description
For Python applications, Nix adds propagatedBuildInputs into PATH and PYTHONPATH. This makes sense for Python modules, but as far as I understand, I think this shouldn't be done for Python applications, which are run as executables. If I install some Python application foobar which uses jupyter, I don't want to get python and jupyter into my PATH. I just wanted foobar and I don't care that it happens to be written in Python. Also, I might want to install different versions of python and jupyter into the same environment so there would be conflicts just because foobar happens to depend on them too. In my opinion, the right way to install Python applications would be such that only the bin directory of the Python application is added to PATH but none of its dependencies. The dependencies should be made available only for the Python application with wrapping. Any comments or ideas?
EDIT: And even the Python application itself shouldn't be added to PYTHONPATH, only to PATH. Again, because it's just an application, it's not supposed to be used as a Python module.
Steps to reproduce
Let's try with nbstripout. Create a clean environment for it:
$ nix-shell -p nbstripout -p which --pure

Now, python and jupyter have been added to PATH:
$ which python
/nix/store/83xv5vjqs8qxzdsqs8dmni23wfkbx43a-python-2.7.13/bin/python
$ which jupyter
/nix/store/78iqhpa3k46ywjc5b9vm2gm5paarpf9p-python2.7-jupyter_core-4.3.0/bin/jupyter

Also, the Python dependencies are in PYTHONPATH:
$ python -c "import nbformat"; echo $?
0

Technical details

System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...)

$ nixos-version
17.09.git.65477dc (Hummingbird)

Nix version: (run nix-env --version)

$ nix-env --version
nix-env (Nix) 1.11.9

Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion)

$ nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
"17.09.git.65477dcd34"

Sandboxing enabled: (run grep build-use-sandbox /etc/nix/nix.conf)

$ grep build-use-sandbox /etc/nix/nix.conf
build-use-sandbox = true

This is mostly a duplicate of https://github.com/NixOS/nixpkgs/issues/24128.

I'm closing this because

this is mostly about nix-shell where this is expected (#26151)
we do have an issue with the wrapper including too much (#24128)

See also the placeholder with Python-related issues https://github.com/NixOS/nixpkgs/issues/1819.


Elasticsearch instrumentation

This issue groups all the tasks that are required to allow proper usage of APM agent within Elasticsearch itself.

[x] fix log4j initialization within the agent: https://github.com/elastic/apm-agent-java/pull/2568
[x] fix class not found java.lang.Throwable when agent is loaded within ES, adding system module access to security policy fixed that.
[ ] Related but optional (would make debugging easier) #2539
[ ] internal spans within ES are created as transactions, whereas they are spans with OTel SDK.
[ ] HTTP attributes in transaction are not properly mapped (might be in apm-server mapping).

Relates to

https://github.com/elastic/elasticsearch/issues/84369

So far, the only change I've made to the agent is as follows:
diff --git a/apm-agent-plugin-sdk/src/main/java/co/elastic/apm/agent/sdk/logging/LoggerFactory.java b/apm-agent-plugin-sdk/src/main/java/co/elastic/apm/agent/sdk/logging/LoggerFactory.java
index c61257d21..4bcf2ee57 100644
--- a/apm-agent-plugin-sdk/src/main/java/co/elastic/apm/agent/sdk/logging/LoggerFactory.java
+++ b/apm-agent-plugin-sdk/src/main/java/co/elastic/apm/agent/sdk/logging/LoggerFactory.java
@@ -18,6 +18,9 @@
  */
 package co.elastic.apm.agent.sdk.logging;

+import java.security.AccessController;
+import java.security.PrivilegedAction;
+
 public class LoggerFactory {

     private static volatile ILoggerFactory iLoggerFactory;
@@ -32,11 +35,16 @@ public class LoggerFactory {
      * @param name The name of the logger.
      * @return logger
      */
-    public static Logger getLogger(String name) {
+    public static Logger getLogger(final String name) {
         if (iLoggerFactory == null) {
             return NoopLogger.INSTANCE;
         }
-        return iLoggerFactory.getLogger(name);
+        return AccessController.doPrivileged(new PrivilegedAction<Logger> () {
+            @Override
+            public Logger run() {
+                return iLoggerFactory.getLogger(name);
+            }
+        });
     }

     /**

This may not ultimately be what we want to do, but I got me further.
The problem with java.lang.Throwable not being found was (I believe) due to the ES code lacking the accessSystemModules permission.
CC @ChrisHegarty

I've noticed that the apm-agent module doesn't have all the sources of the agent, which makes debugging a challenge.
May not be entirely in scope of this issue but having the ability to pull in all sources to that the agent can be debugged within a project that it's integrated in seems like an important capability. That's not only in the context of Elasticsearch but arguably specifically important there.

I tried running a 3 node cluster in docker-compose, and noticed that the service map doesn't break down the cluster, which I think would be useful if one was in a degraded state. I set a different service_node_name on each, which is reflected in the "JVMs" tab.

Regarding the spans that are created as transactions: all the parent-child relationships are created through the context propagator, as a consequence even the spans that are on the same node are considered to be remote.
We should add a distinction between:

local parent span, stored as SpanContext or Context, probably within ES ThreadContext as a transient object.
remote parent span, which are created from the context propagator.

Given the parent/child relationship for inherited ThreadContext isn't really straightforward, it would be more efficient to discuss this with someone familiar with the ES codebase.
Also, with OTel (and also our internal agent API), the "currently active span" is the one that is picked as parent when another child span is created. Ideally, in the Tracer implementation, onTraceStarted would be able to retrieve the parent span from TraceContext and use it. Because the ThreadContext inherited fields are just plain strings, we have to find a way to store and inherit a reference (or alternatively an ID if it's not directly possible) in order to preserve the link to the parent span in place of using a remote parent.


Handle stream errors on all streams

Fix #17.
If any stream in the list emits an 'error' event, we should handle it,
even if we haven't started consuming that stream yet. Basically, we
will listen to 'error' immediately instead of at the time of use.
Previously, if any stream (other than the first, which we start
consuming right away) emitted an 'error', then it would be uncaught by
our code ("unhandled 'error' event")

Hey @mafintosh, what do you think of this?

I think we should use end-of-stream instead of handling errors/close ourselves. Other than that LGTM

I'll add end-of-stream in another PR.

@mafintosh Actually, I don't feel very confident about adding in end-of-stream -- it's pretty tricky to ensure all the event handlers continue to get cleaned up upon destroy, and I don't know what the current 'close' handler is meant to be doing. Could you take a stab at it when you have time? I want to see how you'd do it.


New UI to support meeting

Update UI to now hold meeting information for respective clients.
Recommended to follow FAid UI Mockup

Push back to v1.3

Split Panel UI is hooked up to the model now, just need to update colour scheme next.

All done


CDM on Windows reporting Tampered status

I have an Electron app for playing DRM assets. On Mac it is working well. On PC it plays back fine, but the license server is getting a response that says the platform status is PLATFORM_TAMPERED.
I read through the issue here: https://github.com/castlabs/electron-releases/issues/22, but my digests match and I'm getting no errors when running the vmp_resign.py script.
I'm using electron-builder to build and sign the application, then using the vmp_resign script afterwards. I have tried turning off the signAndEditExecutable option so it's not inserting icons and metadata, but I still am getting the tampered status. It sounds like running the resign script after electron-builder completes may not be enough, based on this: https://github.com/castlabs/electron-releases/issues/56#issuecomment-635600098
One thing I do notice that is odd, is that the CDM version reported in the response is one patch version off of what the manifest.json that accompanies the CDM says. The response has "4.10.1582.1", whereas the manifest.json has "4.10.1582.2". However, I feel that may be a red herring, as on Mac it is doing the same thing and receiving a VERIFIED status.
Here is the output from the resign verification:
vmp-resign/WARNING: -K/--key, -P/--password, -n/--no-prompt-password and -p/--prompt-password are ignored for verification
vmp-resign/INFO: Verifying package: build
vmp-resign/INFO: Reading signature from: build\My Player.exe.sig
vmp-resign/DEBUG: Decoding signature file with version: 0
vmp-resign/DEBUG: Decoding certificate entry
vmp-resign/DEBUG: Decoding signature entry
vmp-resign/DEBUG: Decoding flags entry
vmp-resign/DEBUG: Certificate:
vmp-resign/DEBUG:   Version: v3
vmp-resign/DEBUG:   Serial Number: <REDACTED>
vmp-resign/DEBUG:   Signature Hash Algorithm: sha256
vmp-resign/DEBUG:   Issuer: C=US, ST=Washington, L=Kirkland, O=Google, OU=Widevine, CN=widevine-codesign-root-ca
vmp-resign/DEBUG:   Subject: C=FR, L=Srasbourg, O=Movidone
vmp-resign/DEBUG:   Not Before: 2019-03-04 22:43:01
vmp-resign/DEBUG:   Not After: 2029-03-01 22:43:01
vmp-resign/DEBUG:   Extensions:
vmp-resign/DEBUG:     Subject Key Identifier:
vmp-resign/DEBUG:       Digest: c84c5b76507d9fcbe12195414e85b8727b330adc
vmp-resign/DEBUG:     Authority Key Identifier:
vmp-resign/DEBUG:       Key ID: ca3dd88e0f74577fd09ad9e121bf42fb23552986
vmp-resign/DEBUG:     Basic Constraints:
vmp-resign/DEBUG:       CA: False
vmp-resign/DEBUG:     Key Usage:
vmp-resign/DEBUG:       Digital Signature
vmp-resign/DEBUG:     Extended Key Usage:
vmp-resign/DEBUG:       Code Signing
vmp-resign/DEBUG:     <IP_ADDRESS>.4.1.11<IP_ADDRESS>:
vmp-resign/DEBUG:       ...
vmp-resign/DEBUG: Public Key: RSA 2048 bit
vmp-resign/INFO: Verifying file: build\My Player.exe
vmp-resign/DEBUG: File digest: c5f88e8f18dc1c5c62ab5905d8410ed90446f2be1249b3bb19403c1d8753514d61de0bd0ff3a08057925cd49fdaecda5dc790cf63642336d2d2eb6c39a0ae288
vmp-resign/DEBUG: Verifying data: c5f88e8f18dc1c5c62ab5905d8410ed90446f2be1249b3bb19403c1d8753514d61de0bd0ff3a08057925cd49fdaecda5dc790cf63642336d2d2eb6c39a0ae28801
vmp-resign/INFO: Verified package: build

Here is the status from the CDM with the tampered status:
{
   "status":"OK",
   "status_message":"",
   "license_metadata":{
      "content_id":"ewyxzy9KDEGb\/jG65VbVFA==",
      "license_type":"OFFLINE",
      "request_type":"NEW"
   },
   "supported_tracks":[
      {
         "type":"HD",
         "key_id":"TjRfOpWvU4erQnemQaeqgA==",
         "video_feature":""
      },
      {
         "type":"SD",
         "key_id":"RfIwY9PTUICi7o3daBn8cA==",
         "video_feature":""
      },
      {
         "type":"AUDIO",
         "key_id":"KRBtTL AVyKwylcrnLXI0A==",
         "video_feature":""
      }
   ],
   "make":"Google",
   "model":"ChromeCDM-Windows-2",
   "security_level":3,
   "internal_status":0,
   "session_state":{
      "license_id":{
         "request_id":"sNQeQDTN0PBnxn4WA3pW8g==",
         "session_id":"sNQeQDTN0PBnxn4WA3pW8g==",
         "purchase_id":"",
         "type":"OFFLINE",
         "version":0
      },
      "signing_key":"<REDACTED>",
      "keybox_system_id":13701,
      "license_counter":0
   },
   "drm_cert_serial_number":"<REDACTED>",
   "device_whitelist_state":"DEVICE_NOT_WHITELISTED",
   "platform":"chrome",
   "device_state":"RELEASED",
   "pssh_data":{
      "key_id":[
         "<REDACTED>"
      ],
      "content_id":"ewyxzy9KDEGb\/jG65VbVFA=="
   },
   "client_max_hdcp_version":"HDCP_V1",
   "client_info":[
      {
         "name":"architecture_name",
         "value":"x86-64"
      },
      {
         "name":"company_name",
         "value":"Google"
      },
      {
         "name":"model_name",
         "value":"ChromeCDM"
      },
      {
         "name":"platform_name",
         "value":"Windows"
      },
      {
         "name":"widevine_cdm_version",
         "value":"4.10.1582.1"
      }
   ],
   "platform_verification_status":"PLATFORM_TAMPERED",
   "content_owner":"movidone",
   "content_provider":"movidone",
   "system_id":13701,
   "oem_crypto_api_version":0,
   "resource_rating_tier":0,
   "client_ip":"<REDACTED>"
}

Any advice on how to change my signing process or configuration to resolve this tampered status?

This typically happens when the VMP signature has been broken, i.e. the electron executable has been changed somehow after you re-signed it. Not sure what can have caused it in this particular case though.
The verification output above, is that printed during build or is it something you have manually done after? If it is part of the build I would suggest trying it on the final package to see if it still passes the verification, i.e. unzipping the final package and using the same verification on the extracted version of the application. If it fails we'd know something happened to the executable in between the two verifications. Are you perhaps code-signing the application after the build process? This is another thing that changes the executable in a way that breaks VMP.
I would not worry too much about the version discrepancy you are seeing with manifest.json. Some previous releases have had this same issue where the version number was not updated correctly in all places.

The verification output is from after I was completely done with the build process. I'm building and signing the app using electron-builder, and then resigning Electron using the vmp-resign script after that process completes. For Mac, I was using vmp-resign on Electron before building and signing with electron-builder. It was my understanding that I had to do this in the opposite order for PC.
I'm not entirely certain of the order of operations performed by electron-builder. I would assume it first builds the app, then signs the exe. I suppose the vmp-resign running after that completes could break the signing, but I'm not sure where in the electron builder process I would need to try to run the vmp-resign to sign Electron.

Yes, you are right. On Windows you need to VMP-sign after anything that changes the executable, which can be electron-builder itself, code-signing or something else. On the Mac the situation is different since code-signing takes the entire app package into account, which means you need to do that after the VMP signature file has been added (and VMP can even account for some, non-code, Mach-O executable sections changing after then signing).
It sounds like you are doing everything right, but PLATFORM_TAMPERED indicates that VMP has found some issue in the VMP signature chain. Exactly what causes it is difficult to say without examining the entire process leading up to it.
I'm not sure what kind of advice I can currently give around electron-builder. It has been a long time since I last used it for anything and I know things have changed substantially since then. IIUC they now have some new hooks that should make integrations easier, so perhaps it is time I took a closer look at them :-)
Btw, what version of Electron are you using?

Thanks, @khwaaj. I am using 8.3.0.
I will ask the electron-builder folks if they have any leads. Info on a PLATFORM_TAMPERED status is scarce out there on the Web.

Ok, v8.3.0-wvvmp is working fine for me, so there appears to be nothing wrong with the release.
I put together a simple project where I tested electron-builder and I think I have a something that should work for cases such as yours, unless I have misunderstood what you are trying to do. I can't test it completely since I don't have code-sign certificates here, but aside from that it does what it should and produces correctly signed assets on macOS and Windows (that do not get PLATFORM_TAMPERED on any platform).
I can't share the whole project at this point since it is built on top of a private project but I can share the essentials of what I did:
package.json
{
  "name": "electron-builder-wvvmp",
  "version": "1.0.0",
  "description": "A minimal Electron application with Widevine support",
  "main": "main.js",
  "scripts": {
    "start": "electron .",
    "dist:mac": "electron-builder --mac",
    "dist:win": "electron-builder --win --x64 --ia32"
  },
  "author": "castLabs",
  "devDependencies": {
    "electron": "git+https://github.com/castlabs/electron-releases.git#v8.3.0-wvvmp",
    "electron-builder": "^22.7.0"
  },
  "build": {
    "appId": "electron.builder.wvvmp",
    "electronDownload": {
      "mirror": "https://github.com/castlabs/electron-releases/releases/download/v"
    },
    "mac": {
      "target": "zip"
    },
    "linux": {
      "target": "zip"
    },
    "win": {
      "target": "zip",
      "icon": "build/icon.ico"
    },
    "afterPack": "./after-pack.js",
    "afterSign": "./after-sign.js"
  },
  "dependencies": {}
}

after-pack.js
exports.default = async function(context) {
  // If we are not packaging for mac we don't sign here, just return
  if (context.packager.platform.name !== 'mac') {
    return;
  }

  // Sign the application package
  var spawnSync = require("child_process").spawnSync;
  var vmp = spawnSync('python', [
      'node_modules/electron/vmp-resign.py',
      '-vv',
      '-M', context.packager.appInfo.productFilename + '.app',
      '-C', 'path/to/cert.pem',
      '-K', 'path/to/key.pem',
      '-p', // Prompt for password (use -P to supply instead)
      context.appOutDir
    ],
    {
      stdio: 'inherit'
    });

  if (vmp.status != 0) {
    throw new Error('vmp-resign.py failed with code: ' + vmp.status);
  }

}

after-sign.js
exports.default = async function(context) {

  // If we are not packaging for windows we don't sign here, just return
  if (context.packager.platform.name !== 'windows') {
    return;
  }

  // Make sure we don't leave an outdated electron.exe.sig laying about
  if (context.packager.appInfo.productFilename !== 'electron') {
    var fs = require("fs");
    var path = context.appOutDir + '/electron.exe.sig'
    if (fs.existsSync(path)) {
      fs.unlinkSync(path)
    }
  }

  // Sign the application package
  var spawnSync = require("child_process").spawnSync;
  var vmp = spawnSync('python', [
      'node_modules/electron/vmp-resign.py',
      '-vv',
      '-W', context.packager.appInfo.productFilename + '.exe',
      '-C', 'path/to/cert.pem',
      '-K', 'path/to/key.pem',
      '-p', // Prompt for password (use -P to supply instead)
      context.appOutDir
    ],
    {
      stdio: 'inherit'
    });

  if (vmp.status != 0) {
    throw new Error('vmp-resign.py failed with code: ' + vmp.status);
  }

}

With this I can use npm run dist:mac && npm run dist:win to build Mac and Windows packages, and node_modules/electron/vmp-resign.py -vv -Y -M electron-builder-wvvmp.app -W electron-builder-wvvmp.exe dist/mac dist/win-unpacked dist/win-ia32-unpacked to verify them all in one go (on my Mac, on Windows I can only build Windows packages).
I hope this gives you some ideas on how to work around the issue you are seeing in your project!

On spotting this thread yesterday I took a look at our monitoring for tampered messages and found just over 500 reports in the previous 24 hours. These were tied to a recent release so, worrying about code signing (even though there's plenty of monitoring evidence the build works) I double checked the build on a Win 10  Pro v1903 18362.836 machine. It failed with a tampering message. Back on another Windows 10 machine the same build worked. So far the only noted difference is the OS build number - 18362.592
So, going back to #52, I altered the --widevine-base-dir=C://foo on the "tampered" machine and it worked. Looking at the app support folder it's reported as C:\Users\simongregory\AppData\Roaming\AppName which turns out to be an alias to C:\Users\simongregory\AppData\Local\AppName. I expect this is the cause of the trouble (as discussed back in #50) - and may well be one thing to rule out here. It's also looking like the scope of #50 extends beyond windows store installs.

Interesting, not really sure of what prompts the extra alias in AppData though. My test rig currently runs Win 10 Pro v1909 18363.836, and I've not seen any problems there, so far. Maybe it has something to do with the OS version that first created the AppData folders.
If this indeed just an alias, and not something like the overlay filesystem that the Desktop Bridge uses, it might be possible to simply determine the real path before registering the CDM. I'll try to set up some testing around this.

If thats the case then my first thought is that I manually created the alias/shortcut earlier in the year to test with and have forgotten about doing it! Let me investigate with a clean install.

I'm also on Win 10 Pro v1909 18363.836. This issue came up from a build made back in October 2019 on electron 5.0.0-beta. It's now upgraded to 8.3.0, and the issue persists. I've tried installing it on a completely clean machine that is up to date, and the issue still persists there, so my suspicion would not be the version of OS that made the AppData folder. I will see if I have the same sort of aliasing or if changing the widevine-base-dir helps. Thanks for the extra info guys!

I've been unable to recreate the alias through fresh installs and rolling back to earlier versions of the app and upgrading again. I think it was almost certainly me who created it in the first place. Apologies for the red-herring.
I'm still nowhere accounting for the tampering messages in monitoring though. For us it means a license isn't issued and users cant watch content - I have one user contact that appears to be getting this issue so will follow up with them and let you know if there's anything useful.

Ok, thanks @simongregory, the AppData aliasing seems more unlikely as a cause then. Still, this appearance of PLATFORM_TAMPERED in your logs has me worried this can become a widespread issue. The fact that some instances of the same version seem to work while others don't seems to point to something on the systems, or perhaps the service, rather than in the application package.
@turbidwater, did you see any indication that your package works on some machine but not others? Maybe you have some package exhibiting the problem that you can share with me, here or privately, so that I can see if I can reproduce the problem here?

@khwaaj It has not worked on the 4 PCs we have tested on. Two of those are Win 10 Pro v1903 18362.836.  So it has not seemed to change from PC to PC.
I will see if I can generate a generic app that exhibits the behavior, but the current project cannot be shared, unfortunately.

Oh, and I did verify that there is no aliasing happening on my AppData folders, so yes, that would appear to not be the cause.

I have filed an issue with electron-builder as well: https://github.com/electron-userland/electron-builder/issues/5038
I tried updating to the most recent version, but got the same results. So I'll cross post it here.

@turbidwater, after reading through this and #56 again I just need to clarify a few of things.
In #56 you mention signing ./node_modules/electron/dist with vmp-resign.py, which is fine, and even a requirement if you need to run the application directly from the repo with production VMP support (e.g. using npm run start or something similar).
In the config posted in https://github.com/electron-userland/electron-builder/issues/5038 you are passing electronDist to electron-builder to use the, possibly re-signed, version of electron in ./node_modules/electron/dist (as opposed to downloading/extracting a fresh package, which is the default). This is also fine, and should even work with electron-builder for the Mac version of your package, except in very special cases, as long as the signing is done before electron-builder does its thing. It's not likely work for a Windows though, unless you can configure electron-builder to leave the executable entirely untouched, which I'm not certain if it's even possible. And even then you'd need to manually rename electron.exe.sig to match the new application executable name before electron-builder creates the final packaged artifacts.
I'm not sure if this is representative of the signing you are currently doing, especially since you do mention that you actually re-sign after the application is built and code-signed, but you do not mention how you accomplish this. Re-signing after electron-builder has produced the final artifacts is unpractical since you'd have to extract/re-sign/re-package the artifacts themselves. A better approach would be to use the afterPack and afterSign hooks that I use in my example above, but I'm not sure if you are doing this, and your example posted in https://github.com/electron-userland/electron-builder/issues/5038 doesn't appear to do so as it's calling notarize.js in afterSign, so I'm not sure what to think here.
Also, since electron-builder copies electron, e.g. to dist/win-unpacked for win32-x64 by default, and then renames/processes the copy before packaging it into the final artifacts, that is the path you'd need to re-sign, not node_modules/electron/dist. The actual path used is available in the context passed to the afterPack/afterSign hooks (see context.appOutDir as used in my example scripts above), as are a few other useful values.
Since you are seeing the same error on all machines you have tried I'm still inclined to believe something is actually wrong with the VMP signature of the application, as opposed to the problems that @simongregory has been seeing in their logs lately. My suggestion would be to try and adopt something similar to the scripts I posted above for the afterPack and afterSign hooks, merging the latter with your notarize.js script so that it can both sign and notarize depending on the platform.

Thanks, @khwaaj. Those are solid suggestions.
For PC, I am re-signing the electron in the app, rather than the node_modules version.
./node_modules/electron/vmp-resign.py -C "VMP\Signed by widevine\prod-movideon.der" -P "MyPassword" -K  ./VMP/production-key.pem -W "MyPlayer.exe" -v build
But that's probably the problem. I think your idea of moving the signing step forward in the process to the afterPack and afterSign hooks seem like good ones. I will give those a try.

Quick update - Tamper message rate is down to around 300. Am unsure what conclusion to draw from that, its unlikely users are going to persist with the app if it's started failing so it could suggest something system specific with a limit.
User contact is on Win 7 and not technical. They claim it always worked before and don't know when it stopped exactly. They have a single user account, run Norton Antivirus, it's not a work PC (can have security restrictions and proxies), don't use Windows OneDrive/use cloud backup. I'm asking them to try setting a --widevine-base-dir to rule out folder aliasing. It's 50/50 as to wether they'll respond.
There are a lot of moving parts here, I was warned earlier in the year our licence supplier was upgrading (all went fine with QA), but the service is another thing I'm following up.

@simongregory, thanks for the update.
I agree it is hard to draw any conclusions currently. There are any number of things that could go wrong on both the client-side and server-side of things, so it would certainly have helped a lot with a technically inclined user to perform some tests locally on a failing setup. I hope you can get a response on the test you requested, at least.

@khwaaj , thank you again! Moving the re-sign into the afterSign step appears to have fixed the VMP. I'm no longer seeing the TAMPERED status. That script is now split into Mac and PC versions where for PC it runs vmp-resign and for Mac it runs notarizing.
Now the only puzzle is that the exe.sig file doesn't appear to get regenerated. It may just be that the actual app code hasn't changed since my last build. Electron-builder is doing the renaming of the sig file and electron.
I'm also getting a stern warning dialog when I install it where I have to, but I think that may have to do with the nature of the signing cert we're using. I'll have to dig into that.
But thanks so much (again) for your fantastic help and responsiveness!

Good to hear!
When you say the exe.sig-file doesn't get regenerated, are you talking about electron.exe.sig or your renamed MyApp.exe.sig? The latter should be there after your signing in afterSign but the former is redundant once the application has been renamed, which is why I remove it in my example script above. electron-builder has no knowledge of this and just leaves electron.exe.sig as is.
Not sure about the warning dialog you mention, but it sounds like it could have something to do with the code-signing, as you speculate. I hope it works out.

Yes, sorry. I meant the sig file for the app MyPlayer.exe.sig.

This seems to be fixed. Thanks a million, @khwaaj !

Ok, v8.3.0-wvvmp is working fine for me, so there appears to be nothing wrong with the release.
I put together a simple project where I tested electron-builder and I think I have a something that should work for cases such as yours, unless I have misunderstood what you are trying to do. I can't test it completely since I don't have code-sign certificates here, but aside from that it does what it should and produces correctly signed assets on macOS and Windows (that do not get PLATFORM_TAMPERED on any platform).
I can't share the whole project at this point since it is built on top of a private project but I can share the essentials of what I did:
package.json
{
  "name": "electron-builder-wvvmp",
  "version": "1.0.0",
  "description": "A minimal Electron application with Widevine support",
  "main": "main.js",
  "scripts": {
    "start": "electron .",
    "dist:mac": "electron-builder --mac",
    "dist:win": "electron-builder --win --x64 --ia32"
  },
  "author": "castLabs",
  "devDependencies": {
    "electron": "git+https://github.com/castlabs/electron-releases.git#v8.3.0-wvvmp",
    "electron-builder": "^22.7.0"
  },
  "build": {
    "appId": "electron.builder.wvvmp",
    "electronDownload": {
      "mirror": "https://github.com/castlabs/electron-releases/releases/download/v"
    },
    "mac": {
      "target": "zip"
    },
    "linux": {
      "target": "zip"
    },
    "win": {
      "target": "zip",
      "icon": "build/icon.ico"
    },
    "afterPack": "./after-pack.js",
    "afterSign": "./after-sign.js"
  },
  "dependencies": {}
}

after-pack.js
exports.default = async function(context) {
  // If we are not packaging for mac we don't sign here, just return
  if (context.packager.platform.name !== 'mac') {
    return;
  }

  // Sign the application package
  var spawnSync = require("child_process").spawnSync;
  var vmp = spawnSync('python', [
      'node_modules/electron/vmp-resign.py',
      '-vv',
      '-M', context.packager.appInfo.productFilename + '.app',
      '-C', 'path/to/cert.pem',
      '-K', 'path/to/key.pem',
      '-p', // Prompt for password (use -P to supply instead)
      context.appOutDir
    ],
    {
      stdio: 'inherit'
    });

  if (vmp.status != 0) {
    throw new Error('vmp-resign.py failed with code: ' + vmp.status);
  }

}

after-sign.js
exports.default = async function(context) {

  // If we are not packaging for windows we don't sign here, just return
  if (context.packager.platform.name !== 'windows') {
    return;
  }

  // Make sure we don't leave an outdated electron.exe.sig laying about
  if (context.packager.appInfo.productFilename !== 'electron') {
    var fs = require("fs");
    var path = context.appOutDir + '/electron.exe.sig'
    if (fs.existsSync(path)) {
      fs.unlinkSync(path)
    }
  }

  // Sign the application package
  var spawnSync = require("child_process").spawnSync;
  var vmp = spawnSync('python', [
      'node_modules/electron/vmp-resign.py',
      '-vv',
      '-W', context.packager.appInfo.productFilename + '.exe',
      '-C', 'path/to/cert.pem',
      '-K', 'path/to/key.pem',
      '-p', // Prompt for password (use -P to supply instead)
      context.appOutDir
    ],
    {
      stdio: 'inherit'
    });

  if (vmp.status != 0) {
    throw new Error('vmp-resign.py failed with code: ' + vmp.status);
  }

}

With this I can use npm run dist:mac && npm run dist:win to build Mac and Windows packages, and node_modules/electron/vmp-resign.py -vv -Y -M electron-builder-wvvmp.app -W electron-builder-wvvmp.exe dist/mac dist/win-unpacked dist/win-ia32-unpacked to verify them all in one go (on my Mac, on Windows I can only build Windows packages).
I hope this gives you some ideas on how to work around the issue you are seeing in your project!

This is the issue with building for Mac even with those changes you gave me and the command to build for Windows and Mac
npm run dist:mac && npm run dist:win                          ✔  11s 

><EMAIL_ADDRESS>dist:mac
> electron-builder --mac

  • electron-builder  version=22.14.5 os=5.10.93-1-MANJARO
  • loaded configuration  file=package.json ("build" field)
  • writing effective config  file=dist/builder-effective-config.yaml
  ⨯ Cannot find module 'dmg-license'
Require stack:
- /mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/out/dmgLicense.js
- /mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/out/dmg.js
- /mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/out/dmgUtil.js
- /mnt/Storage/Electron-applications/Binge/node_modules/app-builder-lib/out/macPackager.js
- /mnt/Storage/Electron-applications/Binge/node_modules/app-builder-lib/out/packager.js
- /mnt/Storage/Electron-applications/Binge/node_modules/app-builder-lib/out/index.js
- /mnt/Storage/Electron-applications/Binge/node_modules/electron-builder/out/builder.js
- /mnt/Storage/Electron-applications/Binge/node_modules/electron-builder/out/cli/cli.js
- /mnt/Storage/Electron-applications/Binge/node_modules/electron-builder/cli.js  failedTask=build stackTrace=Error: Cannot find module 'dmg-license'
Require stack:
- /mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/out/dmgLicense.js
- /mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/out/dmg.js
- /mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/out/dmgUtil.js
- /mnt/Storage/Electron-applications/Binge/node_modules/app-builder-lib/out/macPackager.js
- /mnt/Storage/Electron-applications/Binge/node_modules/app-builder-lib/out/packager.js
- /mnt/Storage/Electron-applications/Binge/node_modules/app-builder-lib/out/index.js
- /mnt/Storage/Electron-applications/Binge/node_modules/electron-builder/out/builder.js
- /mnt/Storage/Electron-applications/Binge/node_modules/electron-builder/out/cli/cli.js
- /mnt/Storage/Electron-applications/Binge/node_modules/electron-builder/cli.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/src/dmgLicense.ts:7:1)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/src/dmg.ts:13:1)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/mnt/Storage/Electron-applications/Binge/node_modules/dmg-builder/src/dmgUtil.ts:6:1)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)

If I try and install that missing module I run into this issue
npm i dmg-license                                               ✔
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin"} (current: {"os":"linux","arch":"x64"})
npm ERR! notsup Valid OS:    darwin
npm ERR! notsup Valid Arch:  undefined
npm ERR! notsup Actual OS:   linux
npm ERR! notsup Actual Arch: x64

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/corey/.npm/_logs/2022-01-31T09_53_25_352Z-debug-0.log

The first error is apparently a know issue in a recent version of electron-builder, you should be able to find a workaround here: https://github.com/electron-userland/electron-builder/issues/6520#issuecomment-1003515465
The second issue is just that a required python module is not installed, specifically macholib. You should be able to install the requirement using pip, the python package handler. There is however another issue here since the vmp-resign.py can only be used if you are in possession of your own VMP certificate, which I'm assuming you are not since Google stopped issuing these quite some time back. You'll probably need to adapt the hooks to use the EVS scripts instead to do the signing.

The first error is apparently a know issue in a recent version of electron-builder, you should be able to find a workaround here: electron-userland/electron-builder#6520 (comment)
The second issue is just that a required python module is not installed, specifically macholib. You should be able to install the requirement using pip, the python package handler. There is however another issue here since the vmp-resign.py can only be used if you are in possession of your own VMP certificate, which I'm assuming you are not since Google stopped issuing these quite some time back. You'll probably need to adapt the hooks to use the EVS scripts instead to do the signing.

Ahh ok I see so I need to revert to a older version of electron-packager as a workaround, okay thanks for letting me know!
Oh ok, well that is a little bit of a issue than isn't it haha. I also notice that you have to maintain the signs which is really a pain since it says every month.

I also notice that you have to maintain the signs which is really a pain since it says every month.

Yes, you need to update your authorization token periodically since it will expire otherwise. The tools automatically refresh this as long as possible (I don't remember the exact periods of the top of my head), but at some point you will need to re-authenticate using your credentials. In a CI scenario it is possible to provide these in the environment, or on the command line, as documented. If the tools are run in interactive mode (the default), you will be asked for credentials whenever required.

I also notice that you have to maintain the signs which is really a pain since it says every month.

Yes, you need to update your authorization token periodically since it will expire otherwise. The tools automatically refresh this as long as possible (I don't remember the exact periods of the top of my head), but at some point you will need to re-authenticate using your credentials. In a CI scenario it is possible to provide these in the environment, or on the command line, as documented. If the tools are run in interactive mode (the default), you will be asked for credentials whenever required.

Hmm ok I see, could I use one cert for all my packages needing it? it would make the whole process a lot easier as I maintain them all and they all come from me.

Yes, with EVS you will only register an account. You can use this same account to sign whatever application you build on top of ECS.


Convert LineSDKSwift to use resource_bundles for cocoapods

What did you do?
sp.resources     = ["LineSDK/LineSDK/Assets.xcassets", "LineSDK/LineSDK/Resource.bundle"] triggers https://github.com/CocoaPods/CocoaPods/issues/8431 which can cause apps to pull in excessive amounts of resources.
Please update to resource_bundles, which has numerous benefits aside from working around this issue.

@cltnschlosser Thanks for reporting this. I didn't know that issue and would have some investigation on it.
And yes, you are right, we should use resource_bundles instead and I'd also check whether it is compatible with our project.
Thank you.

Merged and will be released in the next minor version. @cltnschlosser Thank you for the suggestion!


Build pipeline

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

PR created by mistake


Fix typos and format

Fixing some typos and format.

Codecov Report

:exclamation: No coverage uploaded for pull request base (feature-governor@72d460a). Click here to learn what that means.
The diff coverage is n/a.

@@                 Coverage Diff                 @@
##             feature-governor     #191   +/-   ##
===================================================
  Coverage                    ?   43.70%
===================================================
  Files                       ?       10
  Lines                       ?     1167
  Branches                    ?        0
===================================================
  Hits                        ?      510
  Misses                      ?      624
  Partials                    ?       33

Flag
Coverage Δ

unittests
43.70% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add grd to boilerplate

Implement this: https://github.com/1000ch/grd

Sticking with Bootstrap 4 grid system for now.


matrix-synapse service fails to build on nixos-21.11

Steps To Reproduce
Steps to reproduce the behavior:

run nixos-rebuild on nixos-21.11 with matrix-synapse enabled

Build log
error: builder for '/nix/store/zq3pm50m3vlpwl6mf3fc253adasc5d03-python3.10-xmlschema-2.1.1.drv' failed with exit code 1;
       last 10 log lines:
adding 'xmlschema-2.1.1.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
Finished executing setuptoolsBuildPhase
installing
Executing pipInstallPhase
/build/source/dist /build/source
Processing ./xmlschema-2.1.1-py3-none-any.whl
ERROR: Could not find a version that satisfies the requirement elementpath<4.0.0,>=3.0.0 (from xmlschema) (from versions: none)
ERROR: No matching distribution found for elementpath<4.0.0,>=3.0.0

       For full logs, run 'nix log /nix/store/zq3pm50m3vlpwl6mf3fc253adasc5d03-python3.10-xmlschema-2.1.1.drv'.
error: 1 dependencies of derivation '/nix/store/fi57zlmyjiild62dg76lqyj6zrchck66-python3.10-pysaml2-7.2.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/kyrlp1i7isld0l0b6aiq54l0azmpw6ys-matrix-synapse-1.76.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/bcj8kb4r3vy4ih0fvyi2f3snb5hpbqiz-homeserver.yaml.drv' failed to build
error: 1 dependencies of derivation '/nix/store/ibhscbl9pc6xisnciv7dv5hbw8sn8abk-matrix-synapse-register_new_matrix_user.drv' failed to build
error: 1 dependencies of derivation '/nix/store/ii2pgqvpbrcj09nkrasfn9hcf0pkdgan-unit-matrix-synapse.service.drv' failed to build
error: 1 dependencies of derivation '/nix/store/kybqzd4i7d3wyg6k246bazyza9lj68zn-man-paths.drv' failed to build
error: 1 dependencies of derivation '/nix/store/msnwbrjqxq1zka4bzha2bkixc1sbja02-matrix-synapse-register_new_matrix_user_fish-completions.drv' failed to build
error: 1 dependencies of derivation '/nix/store/zx992z1kl8ymfjydfm2dvcf6lglhcg8h-system-path.drv' failed to build
error: 1 dependencies of derivation '/nix/store/qdrvzaj2iqr4k40fzrkfnv4s6zzp7rnk-system-units.drv' failed to build
error: 1 dependencies of derivation '/nix/store/ks78fkzhdchfg8npdrmsqa112ncfrj18-nixos-system-feronia-22.11.20230205.cff83d5.drv' failed to build

Additional context
Notify maintainers

@jonringer for python3.xmlschema
@Ma27 @fadenb @mguentner @Ekleog @Ralith @dali99 @sumnerevans for matrix-synapse
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
- system: `"x86_64-linux"`
 - host os: `Linux 5.15.91, NixOS, 22.11 (Raccoon), 22.11.20230204.8e82401`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.1`
 - nixpkgs: `/etc/nixpkgs`

Can confirm that it tries to build it with 4.0.1 on my machine

Oh sorry, you're absolutely correct, I didn't notice that I was still using the matrix-synapse package from nixos-unstable. So if #214693 fixes this, we can close the issue I think


Facebook requires valid response from domain/signin-facebook to move to production

The tutorial  on how to add an external login provider provides instructions that work while the app is in "development" through facebook dev. When you try to move to production, Facebook shows the following error:
URL(s) listed on your app dashboard settings could not be accessed for platform compliance review. Kindly make sure that the following field(s) on your app dashboard are working correctly:
Website: Site URL https://<domain.net>/signin-facebook
The corresponding URL(s) should return a successful HTTP status code. You can verify this using the Sharing Debugger.
Until you move your app to production in facebook dev, users will get an error message when trying to athenticate.

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

ID: f2c6faa2-8c65-073b-4988-672c1aa9690c
Version Independent ID: d22d616f-907e-ae62-1f43-88ad176a87d4
Content: Facebook external login setup in ASP.NET Core
Content Source: aspnetcore/security/authentication/social/facebook-logins.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Per the doc and error message you need to change the callback URL


fix DefaultTicketCatalog

When using the simple MFA + the Hazelcast tickets registry, I noticed it didn't work because there was an issue with the DefaultTicketCatalog.
Here is the fix.

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

Could you elaborate on how this issue manifests?

Sure.
The  find(Ticket ticket) relies on the find(String ticketId) where the first two lines:
        val index = ticketId.indexOf(UniqueTicketIdGenerator.SEPARATOR);
        val prefix = index != -1 ? ticketId.substring(0, index) : ticketId;

extracts the prefix from the ticket identifier.
So for example, from TST-1, TST would be extracted as the prefix and from CASMFA-2, CASMFA would be extracted as the prefix.
The code is very defensive so if you directly pass a prefix, it is taken as is.
So we should call the find(String ticketId) method with a ticketId and not with a prefix.
It has worked by luck so far as the prefix from the ticket is generally the prefix in the identifier. Which is not the case for the simple MFA where we have a ticketId like CASMFA-1 and a TST prefix because it's a transient session ticket.
Finally, it saves the token in one Hazelcast cache and tries to retrieve it from another one, which makes it not work.

Looks like we have quite a few test failures that seem related. Could you please review?

Sure. I will check that.

Yes, the tests failures were related because of the bad ticket identifiers used in tests: "TGT0" instead of "TGT-0" for example.
Waiting for the build to confirm all tests pass now.


Add basic JAX support

Unlike other modules, JAX array API support is fully in JAX itself in the jax.experimental.array_api submodule, so the only thing that is done here is to add JAX support to the helper functions. This also means that we do not run array-api-tests on JAX.
This also makes the various is_numpy_array, is_cupy_array, etc. functions public, as I noticed someone was using them on GitHub and they seem like they could be useful.

Oh we should also probably add a basic test for the device helpers at https://github.com/data-apis/array-api-compat/blob/main/tests/test_common.py

Apparently we've been supporting "cpu" as a special host device here (https://github.com/data-apis/array-api-compat/pull/40). This is still being discussed for the standard https://github.com/data-apis/array-api/issues/626.
I'm actually unsure if it's a good idea for us to be supporting that here given that we haven't really agreed about it in the standard. But if we did want to support it for JAX, how would we? I don't see how to actually access jax.CpuDevice.

jax.devices('cpu')[0] would return the first CPU device.

Removed the "cpu" device logic. It looks like that isn't going to be part of the standard. I opened https://github.com/data-apis/array-api-compat/issues/86 about removing it for cupy as well.


auto np

Preparation

[X] I read the Troubleshooting Guide
[X] My question isn't answered in any other issues (even the closed ones)

Your question
i remember there use to have auto np menu but i dont find it in any option in this new ui. i try to use command but it seems it doesny always work. all i want is using np when there are np available.

thanks


Account privileges

fixes #6
Added a resource for manager_account to be consistent with API Docs.
This class allows you to get and set privileges for accounts.

:+1:


Add parameters to query /get_expenses

Hello, I noticed that the /get_expenses query interface has no options for the query parameters described in the docs (ref here).
Leaving aside the usefulness of the parameters, I'm currently blocked in my integration because I don't have the ability to obtain the list of all expenses, as pagination is not supported.
May I ask a change to add these parameters? If it's okay to you, I can take care of it myself and open a PR.
Thank you in advance

Hi @jacopoRufini
Thanks, currently I don't have enough free time to implement it for the upcoming weeks and I would be grateful if you could contribute to this project.


Greedy repair operator

This PR:

[x] Closes #182.
[ ] Adds and passes relevant tests.
[ ] Has well-formatted code and documentation.

Notes:

It is essential that you add a test when making code changes.
This keeps the code coverage level up, and helps ensure the changes work as intended.
When fixing a bug, you must add a test that would produce the bug in the master branch, and then show that it is fixed with the new code.
New code additions must be well formatted. Changes should pass the pre-commit workflow, which you can set up locally using pre-commit.
Docstring additions must render correctly, including escapes and LaTeX.

I want to use some of pyvrp::search::Route's stuff here, because it's easy to use for full evaluation. But that needs a bit of refactoring before it's ready for use.

Refactoring is largely done now, so I think I can continue here using the newly improved pyvrp::search::Route!

Alright, this seems to work. Some tests and a benchmark, and we should be good to go.

I hope this is not much slower. It'll definitely be a little slower because greedy repair is expensive, but if it's a lot slower I'll investigate before we merge this.

There's a bug in here somewhere that causes the benchmarks to hang. I'll try to isolate that this afternoon. Shouldn't get in the way of a review, but obviously needs to be fixed before merging.

There's a bug in here somewhere that causes the benchmarks to hang. I'll try to isolate that this afternoon. Shouldn't get in the way of a review, but obviously needs to be fixed before merging.

Couldn't find it unfortunately!

There's a bug in here somewhere that causes the benchmarks to hang. I'll try to isolate that this afternoon. Shouldn't get in the way of a review, but obviously needs to be fixed before merging.

I benchmarked main overnight, but this did not run successfully. Something between https://github.com/PyVRP/PyVRP/commit/be47cfd640f60058dedfa0747a41d6b47f6ea7bf and main is merged that causes the benchmark hang.
RC1_10_1 with seed 5 and seed 10 are hanging for me.

That's good, because I couldn't find it in this PR. I'll have a look.

For me it's RC1_10_8.txt with seed 1, but only after a very long time (30min ish). This'll be annoying to debug.

I'm guessing it might be #302, because that's one of the few functional changes we've made. But we can bisect the thing and then we'll know for sure.

Well, let's hope that the current benchmark completes. Should be in in an hour!

Based on what completed (see above) I don't think this is fast enough. I'll have a look at how we can speed this up a bit later. There should be literature on this.

Based on what completed (see above) I don't think this is fast enough. I'll have a look at how we can speed this up a bit later. There should be literature on this.

The performance is also influenced by #344. I got a gap of 0.65% on https://github.com/PyVRP/PyVRP/commit/28f8aedd2d805d35c739b5f045445aa1d27df006, whereas it was 0.55% before that.

Alright, I'll run a new benchmark for this now that should complete fully. (🤞)

So the benchmark completed nicely (that's a relief), but I still think this is far too slow to use in SREX. I'll have a look at whether there's something we can do about that after dinner.

From the benchmark results, I mainly observe that the new greedy repair results in less overall iterations. This makes sense to me, since we no longer insert in the nearest route, and thus spend way more time in SREX greedy repair. Do you also see this with the profiler?
Although unlikely, the new greedy repair could also be generating worse solutions,  because it uses an exact evaluation instead of an approximate one. That may result in faster (and worse) convergence in local search. I'm just speculating here though.

OK, so just not doing greedy repair in SREX is fine. Considerably faster than using this greedy repair operator, and performance is on par with main from a few weeks ago. The question then is: are we OK with SREX returning incomplete solutions? I think that's fine because there never were any feasibility guarantees anyway.

The question then is: are we OK with SREX returning incomplete solutions?

This is the big part. The new code isn't that interesting.

Do you see a significant increase of time spent in SREX with the profiler?

Yes, it's mostly this. The issue in SREX is the greedy repair step, which is just really expensive. The benchmark above suggests we can do without, and I think that's a reasonable way to go about this.

OK, so just not doing greedy repair in SREX is fine. Considerably faster than using this greedy repair operator, and performance is on par with main from a few weeks ago. The question then is: are we OK with SREX returning incomplete solutions? I think that's fine because there never were any feasibility guarantees anyway.

I'm OK with SREX returning incomplete solutions, too. We can see this as another dimension of infeasibility (without penalty at the moment, but maybe with penalties in the future).
The conclusion that I draw here from repairing offspring is that it really doesn't matter too much; just don't spend too much time and let LS do its work. So I'm fine with the current SREX + LS combination. I think it's even better if we can implement the old "nearest route greedy repair," which I think will also be useful for an ILS-based approach later. But we can do that later, I'll add it to #307.


[nitro-docs] Index redirects to docs entry

home splash screen refactored into a separate file so it isn't lost forever
remove some dead wood

Preview https://5f030df374983ff19b9f4bc1--nitro-protocol.netlify.app/


Fix issue with traefik issueing certificates with letsencrypt acme

The core of the issue was that for entrypoints a default certResolver
was not being specified. Additionally had to read some docs within
traefik https://doc.traefik.io/traefik/routing/entrypoints/#tls that
state that is a tls = {} section is specified within the crd
ingressroute the tls configuration is overwritten.
If a TLS section (i.e. any of its fields) is user-defined, then the
default configuration does not apply at all.

Related to #1015
Changes:

changes related to traefik ingress

Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features to not work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing
Tested locally using minikube and using digitalocean
Requires testing

[X] Yes
[ ] No

In case you checked yes, did you write tests?

[ ] Yes
[X] No

Still need to test with custom secret for compatibility. So do not merge until this is tested.

Tested and this appears to be working great with all three methods of creating certificates. This also appears to fix the dask-gateway issue when visiting the link. With the exception that self signed certificates are not trusted. This is due to issue https://github.com/thomseddon/traefik-forward-auth/issues/122.


fix(postgrest): race condition when setting fetchOptions and execute method call

What kind of change does this PR introduce?
Fixes a bug which could lead to a race condition when executing the request on Postgrest.
What is the current behavior?
Lock was being acquired first for updating the fetchOptions and then inside the execute method for executing the request, this could lead to the execute method to use the wrong fetch options.
What is the new behavior?
Move assignment of fetchOptions inside execute method, on a single lock acquisition.

Lock was being acquired first for updating the fetchOptions and then inside the execute method for executing the request, this could lead to the execute method to use the wrong fetch options.

@grdsdev Q: Why are locks needed on the client? Can't it be stateless? (Since PostgREST requests are stateless)

@steve-chavez
Check the following test:
func testRaceCondition() async {
    let select = client.from("users").select()

    Task {
      print("Task 1")
      try await select.execute(options: FetchOptions(head: true))
    }

    Task {
      print("Task 2")
      try await select.execute(options: FetchOptions(head: false))
    }

    try? await Task.sleep(nanoseconds: NSEC_PER_SEC * 2)
  }

Task 1 and Task 2 can run on different threads, Task 2 can even start running before Task 1, that is all up to the Swift concurrency system.

@grdsdev Got it. Thanks for the explanation :+1:


good

[Enter feedback here]

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

ID: d1b9d373-2140-ead0-e1b2-de63f8e94125
Version Independent ID: 0bcd0103-042c-0ed8-2c8b-922ee27bff3c
Content: Tune Model Hyperparameters - Azure Machine Learning
Content Source: articles/machine-learning/component-reference/tune-model-hyperparameters.md
Service: machine-learning
Sub-service: core
GitHub Login: @likebupt
Microsoft Alias: keli19

@RESHVANTHKS can you please add more details to the issue? Thanks.


✅ Refactor YamlLoader for new data model

#656  👈 (View in Graphite)
main

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


revocation caching time & language review

Steering: Proposal Summary
Following technical review, the option to allow for revocation data to be older than 24 h under exceptional circumstances has been challenged.

Steering: Publication Summary
Used to present completed work to Steering for approval to publish.
Discuss the work that was completed in reference to the above proposal.  Include any differences from the proposal and why.
use [GitHub Preview](https://htmlpreview.github.io/) to show final state of documents along with pull requests (if needed).

Detailed Description:
orig ticket proposal:
The PR contains several typo and minor language edits. The main point, however, is the challenge of allowing revocation data to be older than 24 h under exceptional circumstances. It is proposed to be strict and limit to 24 h at all times.
See review comment
P&A call Aug 10:
What happens if revocation list not available due to exceptional/catastrophic circumstances? We could tighten up the wording, but should leave room for using older cache. Consider adding control method requirement to check when revocation list is back online.
Ties into issue https://github.com/orgs/Open-Credentialing-Initiative/projects/2?pane=issue&itemId=21168468

Triage:

[x] Is Issue appropriate for OCI Architecture
[x]  Assign Size
[x]  Assign Priority
[x]  Assign Label (if needed)
[x]  OCI affected Artifacts Identified
[ ]  Assign Triage - Artifact Version Target (v x.x.x Milestone)
[ ]  Assign Triage - Interop Profile Version Target (v x.x.x Milestone)
[ ]  Create sub-project (if needed)

Affected Parties (help determine Sunrise/Sunset):

[ ] Trading Partners
[ ]  Issuers
[x]  Wallet Solutions
[ ]  PI Verification Solutions

Affected OCI Artifact

[ ] Schema Document
[ ] Identity Schema
[ ] ATP Schema
[ ] Issuer Conformance Criteria
[x] Wallet Conformance Criteria
[ ] VRS Solution Conformance Criteria
[ ] Wallet API Specification
[ ] Governance Document
[ ] Conformance Program
[ ] OCI Website
[ ] Internal Process

Change Category (Guides Steering Review)
- Steering/Industry Review

[x] Business-Level (May affect business operations)
[ ] OCI Governance, Policy or website feature

- Steering/Industry Notification

[ ] Technical-Level (Does not affect business operations)
[ ] OCI Internal Process or Infrastructure

Communication

[ ] Website
[ ]  Newsletter
[ ]  email:
[ ]  Other:

NFR007 says, "Cached data SHALL be valid no longer than 48 hours." Would this be considered the max cap, even in catastrophic circumstances?

P&A mtg Sep 7: 24 h shall be overall max. caching time. new error code to be developed that says that revocation reg could not be accessed, suggest alt. verification method. if TP customer has instructed VRS that VC are optional, affected PIV interaction will pass; if VC are set to mandatory, the PIV interaction will fail.

2023-09-28: P&A approval to merge #75

Steering, Oct 9: remove "Credential revocation data SHALL not be older than 24 hours." - then publish


Support Binance order

Hi @hewigovens and team.
Thank you for updating docs for Dapp page.
I have tried to run freeze order according to new instruction which is updated on the docs. But unfortunately, ._sendCallRequest(request) is never going to return the request. After debugging, looks function is stacking on utf8ToBytes function forever.
I think method: 'trust_signTransaction', is not working properly since get_accounts order is working well.
This is my code to run freeze function. Kindly please check and advise.
(Please feel free to clone the repo and reproduce this issue!)
Code:
https://github.com/roy1210/beptool_fork/blob/feat/%40walletconnect/client/src/components/pages/Freezer.js#L161
Demo:
https://beptool-fork-git-feat-walletconnectclient.roy1210.vercel.app/
P.S.
The old library, @trustwallet/walletconnect will handle freeze order without any issue. Hence, kindly investigate how this issue happens. Maybe missing something in my code?? Much appreciate if you can add an example of Binance orders as well.  Thank you!
Code (Using @trustwallet/walletconnect): https://github.com/roy1210/beptool_fork/blob/feat/%40trustwallet/walletconnect/src/components/pages/Freezer.js#L150
Demo:
https://beptool-fork-git-feat-trustwalletwalletconnect.roy1210.vercel.app/
const request = connector._formatRequest({
    method: 'trust_signTransaction',
    params: [
        {
            network,
            transaction: JSON.stringify(tx),
        },
    ],
});

connector
 // Memo: Didn't return anything
  ._sendCallRequest(request)
  .then(result => {
    // Returns transaction signed in json or encoded format
    console.log(result);
  })
  .catch(error => {
    // Error returned when rejected
    console.error(error);
  });

where is utf8ToBytes function call? could you please try to create tx with wallet core proto? https://github.com/trustwallet/wallet-core/blob/master/typescript/tests/index.test.ts#L48
@trustwallet/walletconnect is old wallet connect version, maybe something breaks in latest walletconnect version

Hi @hewigovens !
What I am trying to say is both 2 branch I showed in above is 99% same code.
The only difference is using @trustwallet/walletconncet or @walletconnect/client(According to the latest docs).
The problem is @trustwallet/walletconncet works without any issue while @walletconnect/client is stacking on .-sendCallRequest(request) function. Both are the same tx object which followed WalletCore's proto message.
So do you think it doesn't make sense the new wallet connect doesn't work while the old wallet connect version works well ?

could you please try to create tx with wallet core proto? https://github.com/trustwallet/wallet-core/blob/master/typescript/tests/index.test.ts#L48

Do you mean make tx object by TW.Binance.Proto.SigingInput.create() ? then pass the tx to transaction: JSON.stringify(tx) in order to make connector._formatRequest?
Would you mind making an example for freeze order with TW.Binance.Proto.SigingInput.create() ? That would be much appreciated since there is no documentation and example code in wallet-core/typescript!
(btw, I think privateKey is not able to get from outside of the Trust wallet app.)

where is utf8ToBytes function call?

This function is called after .-sendCallRequest(request). I think maybe called by @walletconnect/client library.

ok, will try to debug it later this week, meanwhile https://github.com/thorchain/bepswap-web-ui might help you

Thank you very much for your support.
Yes, I checked this repo when I debugging before.  :D
Looks like they are using the old library @trustwallet/walletconnect: 0.0.12 too.
Looking forward to seeing your example code!
After trying the freeze order with the new @walletconnect/client, I’ll try to apply timelock order again!

Hi @hewigovens
I found the reason why .-sendCallRequest(request) didn't success.
It's my bad. I didn't set network property in here.
const request = connector._formatRequest({
    method: 'trust_signTransaction',
    params: [
        {
           // Should be `network: NETWORK_ID,` instead of `NETWORK_ID`
            NETWORK_ID,
            transaction: JSON.stringify(tx),
        },
    ],
});

After fixed network, the freeze order was running successfully!

@hewigovens

could you please try to create tx with wallet core proto? https://github.com/trustwallet/wallet-core/blob/master/typescript/tests/index.test.ts#L48

I have tried to create txInput by wallet-core but didn't success due to Error: TypeError: Cannot read property 'prototype' of null. Could you kindly advise where I missed in this code, please?
// Error: TypeError: Cannot read property 'prototype' of null
          const txInput = TW.Binance.Proto.SigningInput.create({
            chainId: "Binance-Chain-Tigris",
            accountNumber: account.account_number.toString(),
            sequence: account.sequence.toString(),
            freezeOrder: {
              from: addr,
              symbol: selectedCoin,
              amount: amount,
            }
          })

          console.log("txInput", txInput);
          const request = context.wallet.walletconnect._formatRequest({
            method: "trust_signTransaction",
            params: [
              {
                network: NETWORK_ID,
                transaction: txInput,
              },
            ],
          });

Ref: core_proto.d.ts
Values:

Not sure if this is the problem.

hey,  I can receive freeze/timeLock order after correcting the types: https://github.com/roy1210/beptool_fork/pull/3

@hewigovens Thank you very much!!! Let me study later!!

Hi @hewigovens
Looks like signed timeLock msg is invalided in your PR too. It's same error, Error: msg should not be nil.
Kindly check my reply.
Once again, thank you very much for your help!

@catenocrypt can you help confirm that timeLockOrder is working on mainnet (manually sign a tx with wallet core), or just some data not set correctly

@hewigovens
By the way, my wallet app version is 5.0. Do you think timelock order should work in this APP version?

Yes please always try latest build, we have pushed new release to App Store

@hewigovens
Should I download from App Store(ver5.2) or from TestFlight(ver5.0)?

@catenocrypt
Much appreciated if you can test timelock function with your TW app :D

Hi @hewigovens, @catenocrypt
(↓ Same as my comment in this PR)
I have found a way to achieve timelock with wallet-core. Basically I did following 2 approach to make it.

Use the client directly with a call to ‘client.tokens.timeLock’. (Which provide by Binance JS SDK)
Set a signing delegate on the client that calls into WalletConnect class instance.

However, time relock and time unlock are not working due to return Error: signature verification failed.
I guess wallet-core library has a problem to run time relock and time unlock.
Kindly please help to check it. Thanks!
(Maybe a problem with id in somewhere in the library? Because timelock_order is working well without id...)

Hey @roy1210 , I found the problem, it is caused by id, will push a fix to wallet core soon, Thanks for you detail and patience debugging!

Hi @hewigovens @catenocrypt
Thank you for your investigate!
There is one more thing wallet-core should aware about time relock.
When a user want to relock with same amount as original locked value, Binance chain assume null or [] (just empty array) in parameter of amount.
This issue might be helpful to explain.
https://github.com/binance-chain/node-binary/issues/254
And this is our fix in our fork of Binance JS SDK may help to explain this:
https://github.com/SwingbyProtocol/javascript-sdk/commit/898215c4d82dc167c4da4acd37b6b525095d5f37
I’m not seeing anything about the case where coins is omitted. Since it’s repeated in the PB message, it’s essentially an array. It should become null or [] in the json sign doc when empty for the purpose of relocking with the same amount.

relock test also added: https://github.com/trustwallet/wallet-core/pull/1143

Hi @hewigovens
Thank you for your update!
May I know estimated when I can try new version of wallet-core to try time relock and time unlock?

will let you know once we have new iOS build

Noted and thank you!

Hi @hewigovens
Sorry for asking again, when can I try the latest version of TW or wallet-core for "time relock" and "time unlock" ?

@hewigovens
The latest version of TW is supporting timelock, relockand unlock order.
Thank you for your great support!!


Test for Andrew

First make sure you read the test guidelines here: https://github.com/Wiredcraft/test-pm
This task will be followed up asynchronously over a few days and should not take more than two hours in total.
Project Introduction
You have been assigned as project manager for a project for the client Hodor Corp (your client stakeholder is Harry). The outcome of this project will be a website which allows a user to sign up, and log-in to a system that gives them stock market information. The system as a whole is expected in 5 weeks.
Project Details
The work has been divided into two parts:
• the backend and frontend for login and signup - This will be handled by Wiredcraft completely
• the backend and frontend for stock information which will be provided by a separate company Frodo Labs, you will need to interface with Frank, their project manager, to coordinate as they are building this system from scratch for Hodor Corp.
The specific requirements for the registration have been decided as Username, Password and Email address fields. The login will be based on username. And after sign up the stock market information system expects to receive the Username and Email so they can customise the information.
In your team you have:
• A designer who can make mockups and flow diagrams of the login and once confirmed, implement the frontend
• A developer who can implement the backend and help out integrating the login frontend
• A dev-ops engineer who can set up the servers and take care of deployment.
Your Task
The first step of this task is for you to provide the following:
• Clarify the requirements and provide your understanding of the final scope for Wiredcraft's work.
• An initial project plan including:

A work breakdown for Wiredcraft's integration with Frodo labs up to the final delivery
a rough timeline of what you think needs to happen in this project and deliverables. You can use the methodology of your choice for this plan,
Outline the project phases you would have and what should be delivered at each phase.
The plan can be a few paragraphs of text and the timeline can also be made using Github markdown by outlining what needs to be done during each week.
A rough outline of the process you would use for the day-to-day organisation of the development team and a short overview of how you would manage the communication flows internally and externally.

You can also kick off with any questions to multiple people in one GitHub comment, I will answer likewise and bring up more cases to test your communication skills as we go along:
(Assume you have already been introduced to the client (@hcharry111) and stock market service vendor (@flfrank222) ) and you can @myteam333 for questions to your development team)
e.g.
@flfrank222 - Hi there, can I confirm with you the requirements for ...
@hcharry111 - I heard from FLFrank222 that they need to have xxx, does that mean we need to change ....
@myteam333 - I'm not clear on how xxx could work, can you tell me more about it?
@mpathiuk - For the test, I don't understand what you mean by xxx ...

@myteam333 - hi guys,  do you need any additional resources for testing? Particularly integration testing with stock information from Frodo Corp?
@flfrank222 - Hi Frank, can I just confirm with you, username and email is the only user information you need passed on to you?
@myteam333 - I'm not quite clear on the infrastructure needed for system deployment and integration with Frodo Corp, please could you go through it with me.
WiredCraft Project Scope:
•	Wiredcraft will create a system sign up functionality. User sign-up fields: Username, Password, Email Address
•	Wiredcraft will build a system login functionality based on Username
•	Wiredcraft will integrate with Frodo Labs by passing on user sign up information (Username and Email)
Initial Project Plan:
Initiation
•	Introduce myself to project stakeholders Harry and Frank. Explain how they can contact me, and how they can track project progress and offer guidance using Github.
•	Send project scope document to Harry and Frank, ask for confirmation.
•	Draw up a standard list of non-functional requirements and send to Harry and Frank for confirmation.
•	Draw up a system integration testing plan and send to Frank for revision
•	Set out common rules regarding new change requirements and send to Harry for confirmation
Planning
•	Add items to product backlog as follows:
	Mock-up design of user UI and UX (this must be sent to client for confirmation at earliest date)
	Backend design and test for login and sign up
	Frontend design and test for login and signup
	Integration testing at our end
	Integration testing with Frodo Labs
•	Check calendar of team members over the next 5 weeks to ensure availability
•	Meet with team to clarify back log items, split up items into manageable tasks and help assign tasks to each of the team members.  Agree with them on a definition of done for each of the tasks. Ask team to provide time estimates for task items.
•	Based on time estimates, agree on project timeline and schedule team member’s times in calendar
•	Communicate ETC of deliverables to Frank. Based on this, confirm suitable date for integration testing with Frodo Labs.
•	Update Harry on timeline for completion of key deliverables
Execution
•	As the team work through the backlog, track project progress on Github. Ask team members to update task status in terms of Tasks to Do, Work in Progress, Ready to Be Tested and Done. Ask team members to update the ETC for their tasks after each day. Track planned vs current estimates on a burndown chart.
•	Host daily meetings for team members in order to understand task progress and any impediments for team members. Offer as much support as possible to reduce impediments.
•	After back log items have been completed (excluding final integration testing and release), ask team to present each of the items to product manager.
Release
•	Once reviewed, send Frodo Labs a release of our software for them to test integration, and also receive a release of their software for us to test integration.
•	After integration testing has been completed, ask dev-ops to release software to client.
Notes: I felt it was better not to use Scrum cycles because the team is small in number and not much opportunity for overlapping task completion

• From @myteam333 - Nothing more needed for testing from our side for the current acceptance criteria.
• From @flfrank222 - It shouldn't change after now as far as we can see.
Ok, so the plan is in progress and it is now the middle of week 2. The mockups were finished and approved by both stakeholders. Your developer has started on the integration already and spent 3 days on it. You get the following messages:
From @ flfrank222:
Hi @AndyGreene , our specification has changed a little due to incoming requirements on our side, for your integration you'll need to ask the user for address and you'll need to send that to us as well. It can be one plaintext field added to the registration form. Is that possible without changing the schedule? We've cleared this with Harry from HodorCorp already, this is an incoming requirement due to changing legislature that requires us to keep this information.
From @ hcharry111 :
Hi @AndyGreene - We just had a security audit on our side and when you deliver the system, we also need you to send us your internal IP addresses of all users, you don't need to store them, just pass them along to the FrodoLabs endpoints as part of every request. This shouldn't be a lot of work right? That's now a security requirement on our side.

I would proceed with the following actions:

Set up a group call with Frank and Harry to understand the new requirements, i.e. confirm with Harry that the user address is needed in the integration, confirm with Frank the requirement to send Internal IP addresses to FrodoLabs.
Draw up a spec for the new requirements
Explain to Frank and Harry, that I must get time estimates from the team and we may need to extend the timelines and charge for the extra hours.
Send the spec to the team and set up a meeting with them to clarify any questions on the new requirements and revised integration (go back to Harry and Frank if necessary). Work with the team to set up time estimates for it and any rework that must be done based on the new requirements
Check with senior staff if there are any legal implications for sending internal IP addresses of all users to FrodoLabs
Based on the time estimates, check the time availability of the team to complete the work, update the project timelines accordingly.
If the work is substantial (more than a half a day), explain to Harry that we must charge for the additional work (add it to the initial invoice), ask him for sign off of the new requirements
Contact Frank to confirm we will move on with the new requirements
Send the revised project timelines to all stakeholders and our team
Add all additional work to the Project Backlog

Thanks for this @AndyGreene ,we have what we need from the test to proceed. Closing the test as done and moving on the internal evaluation.


[ja] update Japanese translation docs/setup/_index

This is a Feature Request

What would you like to be added

Update Japanese translation https://kubernetes.io/ja/docs/setup/ sync to original English version c430d9a72c6a590baba140d728deea9d274f4bcd Wed Nov 23 15:06:08 2022 +0530.
Why is this needed
outdated doc
Comments

/language ja
/assign

/assign


proxy: Rename RequestMonitoring to RequestContext

Problem
It is called context/ctx everywhere and the Monitoring suffix needlessly confuses with proper monitoring code.
Summary of changes

Rename RequestMonitoring to RequestContext
Rename RequestMonitoringInner to RequestContextInner

Lol. I was told initially that the RequestContext name was confusing, so I renamed it :D https://github.com/neondatabase/neon/pull/6160/commits/2146bcfe416bc68f5577715d31d940fa7ec8a2bb

Lol. I was told initially that the RequestContext name was confusing, so I renamed it :D 2146bcf

Oh, interesting! I think RequestContext is just right and a very common name. I have never seen RequestMonitoring for something like this, but I see the point. Both RequestInfo or RequestMetadata still seem better, though. I'll think about this a bit more.


Add patch to test contrail service disable code

for the current default case

please test this

please test this

@bodepd isnt it duplicate to #628?

I wanted to validate them separately. One to make sure that the contrail changes work, then a second to reconfigure contrail.

please test this

please test this

this was just to test the associated patch on jiocloud-contrail, it has been merged:
https://github.com/JioCloud/jiocloud-contrail/pull/45


The server needs Apoli 1.0.0 Mod to run

Hello,
It states in the description of the mod that the mod has an already existing Apoli 1.0.0 mod within the code to run it however when i start up my server i get the error code that Apoli 1.0.0 mod is needed to access and run this server and therefore i cannot use the origins mod.

I am running into the same issue, but have not found a solution.

I assume you mean the server starts but connecting is impossible? This happens when you don't have Origins installed on your client. Both the server and all players need to install Origins! To check, you can try creating a singleplayer world to see whether Origins works there. If it doesn't, that means it isn't installed and you can't join Origins servers.