Q&A: Analyzer fails to authenticate with Artifactory when downloading artifacts (http-401)

Hi there,
I'm having trouble to authenticate against Artifactory when running ort analyze.
Credendials for Artifactory (username / password) are provided via .netrc file and Maven settings.xml.
But download attempts always result in a http-401 unauthorized.
Downloading these artifacts via cURL works fine, when I provide username / password.
So it seems that the configuration on Artifactory side is fine.
Did I miss some configuration? What can I do to solve this issue?
I appreciate your help! :-)
08:31:50.127 [DefaultDispatcher-worker-3] DEBUG org.ossreviewtoolkit.analyzer.managers.utils.MavenSupport - Remote location for 'external.c:openssl:jar:sources:1.1.1n': external/c/openssl/1.1.1n/openssl-1.1.1n-sources.jar
08:31:50.127 [DefaultDispatcher-worker-3] DEBUG org.eclipse.aether.internal.impl.DefaultTransporterProvider - Using transporter HttpTransporter with priority 5.0 for https://artifactory.*****.com/artifactory/its-external
08:31:50.127 [DefaultDispatcher-worker-3] DEBUG org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider - Using connector BasicRepositoryConnector with priority 0.0 for https://artifactory.*****.com/artifactory/its-external
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.client.protocol.RequestAddCookies - CookieSpec selected: default
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection request: [route: {s}->https://artifactory.*****.com:443][total/ available: 2; route allocated: 1 of 50; total allocated: 2 of 100]
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection leased: [id: 1][route: {s}->https://artifactory.*****.com:443][total/ available: 1; route allocated: 1 of 50; total allocated: 2 of 100]
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-1: set socket timeout to 0
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-1: set socket timeout to 1800000
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing request HEAD /artifactory/its-external/external/c/openssl/1.1.1n/openssl-1.1.1n-sources.jar HTTP/1.1
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth state: UNCHALLENGED
08:31:50.128 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth state: UNCHALLENGED
08:31:50.154 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection can be kept alive indefinitely
08:31:50.154 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Authentication required
08:31:50.154 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.auth.HttpAuthenticator - artifactory.*****.com:443 requested authentication
08:31:50.154 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, CredSSP, Digest, Basic]
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for Negotiate authentication scheme not available
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for Kerberos authentication scheme not available
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for NTLM authentication scheme not available
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for CredSSP authentication scheme not available
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for Digest authentication scheme not available
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection [id: 1][route: {s}->https://artifactory.*****.com:[443](https://gitlab.*****.com/mocca/oss-review-toolkit/-/jobs/5359208#L443)] can be kept alive indefinitely
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-1: set socket timeout to 0
08:31:50.155 [DefaultDispatcher-worker-3] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection released: [id: 1][route: {s}->https://artifactory.*****.com:443]/[total available: 2; route allocated: 1 of 50; total allocated: 2 of 100]
08:31:50.155 [DefaultDispatcher-worker-3] WARN  org.apache.http.client.protocol.ResponseProcessCookies - Invalid cookie header: "Set-Cookie: AWSALBTG=wXE1osuo2pSAo+9NrSYXQ0EgQ2RySOklfj2QVhTXb2XX8HUxx5SaEIuyM0g+1x0pNOGyJRicNpJu9twEyDD33tSMSP9Y1ErNosFyl01UlYBi14GuJKNcVbUymYQIuzH67Osj5QbGasz4uEtYTYXYnLmrRmZgASaGHeoNH6JETQIxu72H***=; Expires=Wed, 06 Jul 2022 08:31:50 GMT; Path=/". Invalid 'expires' attribute: Wed, 06 Jul 2022 08:31:50 GMT
08:31:50.155 [DefaultDispatcher-worker-3] WARN  org.apache.http.client.protocol.ResponseProcessCookies - Invalid cookie header: "Set-Cookie: AWSALBTGCORS=wXE1osuo2pSAo+9NrSYXQ0EgQ2RySOklfj2QVhTXb2XX8HUxx5SaEIuyM0g+1x0pNOGyJRicNpJu9twEyDD33tSMSP9Y1ErNosFyl01UlYBi14GuJKNcVbUymYQIuzH67Osj5QbGasz4uEtYTYXYnLmrRmZgASaGHeoNH6JETQIxu72H***=; Expires=Wed, 06 Jul 2022 08:31:50 GMT; Path=/; SameSite=None; Secure". Invalid 'expires' attribute: Wed, 06 Jul 2022 08:31:50 GMT
08:31:50.156 [DefaultDispatcher-worker-3] WARN  org.apache.http.client.protocol.ResponseProcessCookies - Invalid cookie header: "Set-Cookie: AWSALB=Aj+xDryH81fx1LpTd/dzakMUkCUkt999yNNXJF8kysW7vCWHmFINz4B1EKXdDg+QDsp61KiKbnP3qvBQP21oJMEyTFPnDTQRNl/KXxIoojVo0DDjX7niHOIXhG4a; Expires=Wed, 06 Jul 2022 08:31:50 GMT; Path=/". Invalid 'expires' attribute: Wed, 06 Jul 2022 08:31:50 GMT
08:31:50.156 [DefaultDispatcher-worker-3] WARN  org.apache.http.client.protocol.ResponseProcessCookies - Invalid cookie header: "Set-Cookie: AWSALBCORS=Aj+xDryH81fx1LpTd/dzakMUkCUkt999yNNXJF8kysW7vCWHmFINz4B1EKXdDg+QDsp61KiKbnP3qvBQP21oJMEyTFPnDTQRNl/KXxIoojVo0DDjX7niHOIXh***; Expires=Wed, 06 Jul 2022 08:31:50 GMT; Path=/; SameSite=None; Secure". Invalid 'expires' attribute: Wed, 06 Jul 2022 08:31:50 GMT
08:31:50.156 [DefaultDispatcher-worker-3] DEBUG org.ossreviewtoolkit.analyzer.managers.utils.MavenSupport - Transfer failed: GET_EXISTENCE FAILED https://artifactory.*****.com/artifactory/its-external/external/c/openssl/1.1.1n/openssl-1.1.1n-sources.jar <> /root/.m2/repository/external/c/openssl/1.1.1n/openssl-1.1.1n-sources.jar
08:31:50.156 [DefaultDispatcher-worker-3] DEBUG org.ossreviewtoolkit.analyzer.managers.utils.MavenSupport - Could not find 'external.c:openssl:jar:sources:1.1.1n' in 'https://artifactory.*****.com/artifactory/its-external (https://artifactory.*****.com/artifactory/its-external, default, releases+snapshots)': ArtifactTransferException: Could not transfer artifact external.c:openssl:jar:sources:1.1.1n from/to https://artifactory.*****.com/artifactory/its-external (https://artifactory.*****.com/artifactory/its-external): status code: 401, reason phrase:  (401)
Caused by: HttpResponseException: status code: 401, reason phrase:  (401)
08:31:50.156 [DefaultDispatcher-worker-3] DEBUG org.ossreviewtoolkit.analyzer.managers.utils.MavenSupport - Unable to find 'external.c:openssl:jar:sources:1.1.1n' in any of [https://repo.maven.apache.org/maven2, https://artifactory.*****.com/artifactory/its-external].
08:31:50.156 [DefaultDispatcher-worker-3] DEBUG org.ossreviewtoolkit.analyzer.managers.utils.MavenSupport - Writing empty remote artifact for 'external.c:openssl:jar:sources:1.1.1n' to disk cache.

(i) Some information like URLs and header information have been obfuscated with ***

Downloading these artifacts via cURL works fine, when I provide username / password.

Are you using exactly the same URL as the ORT analyzer for this check? Because I recall there was a subtle difference in URLs that artifactory shows, which sometimes contain "api" as part of the path, and sometimes not. An IIRC in one of the cases the user's API key instead of e.g. an AD password needs to be used.
Maybe @MarcelBochtler remembers some more details.

Yes, the download link shown in Artifactory's native file browser matches the one used by ORT.
I tried both username / token and username / API key in the settings.xml.
Each time it resulted in a 401, wen ORT analyze was run.

I did some more investigation and found out, that the download requests performed by ORT do not reach Artifactory at all.
The access log of Artifactory does not show any download attempts at this time.
Could this be related to the invalid cookie messages? And the AWS application load balancer blocks all download requests because missing request attributes?

Could this be related to the invalid cookie messages?

Could be. Looks like this is more or less a know issue with the Apache HTTP client that the Maven resolver uses. The answer on SO has a solution on how to fix this for the Apache HTTP client directly, but we'd yet need to find out how to fix this for the Maven resolver / the client that the resolver uses.

Meanwhile we tried some configuration on the loadbalancer. But without effect.
The credentials used for these type of downloads (executed by MavenSupport class) are taken either from .netrc or ENV variables (ORT_HTTP_USERNAME and ORT_HTTP_PASSWORD), right?
Is there any way to add a custom request header to these requests? Might be worth a try.
I'm using Artifactory as httpStorageBackend for the scanner, with an Authorization header that holds a bearer token.
This works fine.

Might our issues be related to this?
https://github.com/oss-review-toolkit/ort/blob/main/analyzer/src/main/kotlin/managers/Gradle.kt#L225
Because we are only having authentication errors with Gradle builds.
And Artifactory says non_authenticated_user is requesting files.

@sschuberth: Same issue here. As you can see, username and password is shown in the log:
7:14:27.367 [DefaultDispatcher-worker-3] DEBUG org.eclipse.aether.internal.impl.DefaultTransporterProvider - Using transporter HttpTransporter with priority 5.0 for https://repo.acme.de/artifactory/repo
07:14:27.367 [DefaultDispatcher-worker-3] DEBUG org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider - Using connector BasicRepositoryConnector with priority 0.0 for https://repo.acme.de/artifactory/repo with username=SomeUser01, password=***
07:14:27.374 [DefaultDispatcher-worker-3] DEBUG org.eclipse.aether.internal.impl.DefaultTransporterProvider - Using transporter HttpTransporter with priority 5.0 for https://repo.maven.apache.org/maven2
07:14:27.375 [DefaultDispatcher-worker-3] DEBUG org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider - Using connector BasicRepositoryConnector with priority 0.0 for https://repo.maven.apache.org/maven2
07:14:27.379 [DefaultDispatcher-worker-3] WARN  org.ossreviewtoolkit.analyzer.managers.utils.MavenSupport - There have been issues building the Maven project models, this could lead to errors during dependency analysis: ProjectBuildingException: Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.acme.pom:acme-java-pom:7.2.0: Could not transfer artifact com.acme.pom:acme-root-pom:pom:4.0.4 from/to artifactory (https://repo.acme.de/artifactory/repo): /home/ort/.m2/repository/com/acme/pom/acme-root-pom/4.0.4/acme-root-pom-4.0.4.pom.part.lock (No such file or directory) and 'parent.relativePath' points at wrong local POM @ line 14, column 10

I suspect maven has no permissions to create files under /home/ort/.m2/repository - but has read permissions on the settings.xml file.

Might our issues be related to this? https://github.com/oss-review-toolkit/ort/blob/main/analyzer/src/main/kotlin/managers/Gradle.kt#L225

@software-testing-professional Unfortunately, you didn't use a permalink, and by now that line points to if (!initScriptFile.delete()) {, which I believe is unrelated. Would you mind repeating which line you had in mind?

I suspect maven has no permissions to create files under /home/ort/.m2/repository - but has read permissions on the settings.xml file.

@mawl you mentioned that you're using your own "custom Dockerfile". So, can you confirm that there is nothing to fix in any of our two Dockerfiles? Otherwise, feel free to create a PR.

@sschuberth Sorry for that.
I found a code comment here:
https://github.com/oss-review-toolkit/ort/blob/aa942fa62dd7f055e2f27f51831dc66cf77e55c8/analyzer/src/main/kotlin/managers/Gradle.kt#L230
 // TODO: Also handle authentication and snapshot policy.
This led me to the assumption that something related to authentication might still be missing.

Sorry for that.

No worries. Thanks for being quick in posting an update!

This led me to the assumption that something related to authentication might still be missing.

I'm currently unsure whether this old comment of @mnonnenmacher from 2017 is still valid.
@software-testing-professional looks like you're running ORT from a Docker image. Could you also try running ORT natively with the same configuration to rule out any Docker-related issues?

@sschuberth Sorry, I'm a bit late with my answer. ;-)
I also tried to use ORT natively. With same results.
Normally I use the ORT Docker image and mount all the configuration (settings.xml, .netrc, etc.) into the container.
The repository configuration is done via Gradle.
And the Artifactory repositories are configured as
maven {
          credentials {
              username lUsr
              password lPwd
          }
          url lUrl

Although everything was configured, Artifactory only got requests from an "unauthenticated" user.
Because the requested resource was part of the Gradle project, these requests definitely came from ORT.
But:
I did some more testing, and could solve the authentication issue by adding this to gradle.properties and mounting it into the container:
systemProp.http.proxyUser=<user>
systemProp.http.proxyPassword=<pw>

So currently the Gradle authentication still does not work. But solved via proxy authentication.

@software-testing-professional would you mind checking whether the current version of ORT that includes https://github.com/oss-review-toolkit/ort/pull/6498 fixes the issue for you?

@sschuberth Yes, I'll be able to try that next week from Wednesday on. :+1:

I can confirm that the scanner does not freeze anymore, if ClearlyDefined is defined as storageReader (together with artifactoryStorage).
    storageReaders: [
      "clearlyDefined",
      "artifactoryStorage"
    ]

...
08:30:57.397 [main] INFO  org.ossreviewtoolkit.scanner.ScanResultsStorage - Read 0 scan result(s) for 'Maven:io.swagger.core.v3:swagger-core:2.2.7' from ClearlyDefinedStorage in 694.389us.
08:30:57.979 [main] INFO  org.ossreviewtoolkit.scanner.ScanResultsStorage - Read 1 scan result(s) for 'Maven:org.apache.tomcat.embed:tomcat-embed-el:10.1.4' from ClearlyDefinedStorage in 582.341739ms.
08:30:57.981 [main] INFO  org.ossreviewtoolkit.scanner.ScanResultsStorage - Read 0 scan result(s) for 'Maven:net.logstash.logback:logstash-logback-encoder:7.2' from ClearlyDefinedStorage in 1.274609ms.
08:30:57.982 [main] INFO  org.ossreviewtoolkit.scanner.ScanResultsStorage - Read 0 scan result(s) for 'Maven:org.springframework:spring-test:6.0.3' from ClearlyDefinedStorage in 890.483us.
...

Tested with Docker-based ORT, built from commit 19c89ff9a.
Thank you for fixing it!!! :smiley:

I can confirm that the scanner does not freeze anymore, if ClearlyDefined is defined as storageReader

Hmm, this sounds a bit as if you're confusing this issue with https://github.com/oss-review-toolkit/ort/issues/4540 😉
But what about this:

I'm having trouble to authenticate against Artifactory when running ort analyze.

Ah right - that happens if you have too many open tabs. :laughing:
I'll move that answer over to the other issue.
Regarding authentication, this also works with the Docker-based ORT built from commit https://github.com/oss-review-toolkit/ort/commit/19c89ff9a0a7aa2a52d85c82fd477531da1ecf3d.

Regarding authentication, this also works with the Docker-based ORT built from commit 19c89ff.

Great, thanks for confirming, so I'll be closing this!


feat(core-data): Add message bus subscription log

If your build fails  due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[x] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[x] I am not introducing a new dependency (add notes below if you are)
[ ] I have added unit tests for the new feature or bug fix (if not, why?)
[x] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
[ ] I have opened a PR for the related docs change (if not, why?)

Note
Please refer the discussion: Subscribe/Publish Message bus topic - Need understanding on service communications #292
Conclusion: no logging for core-data subscription.
Testing Instructions
Please note that I'm using a custom Makefile from edgex-native-build (My custom configurations)

I have gone through Working in a Hybrid Environment and at this time this setup is not working for me.
So I have created a custom Makefile with configurations that help me in bringing up edgex with few commands.
Forked & cloned the code from edgex-go & build and test it with my custom configurations.

Owners/maintainers can suggest me any other method of testing if it needs to be done.
And here is the result from my current configurations:
level=INFO ts=2024-07-28T06:27:08.812725069Z app=core-data source=subscriber.go:53 msg="core-data subscribing to topics: [{edgex/events/device/# 0xc0005e0180}]"

according to the guide line, you need to create an issue first to describe why you want to add the feature.
the commit message prefix should be feat(core-data): , no refactor because it's an enhancement not refactoring
feat(core-data): Add msg bus subscription log

@cloudxxx8 , Need some time to make the changes. Sorry for not understanding a few terms.
Thanks

I have created and updated the Issue #4843

according to the guide line, you need to create an issue first to describe why you want to add the feature. the commit message prefix should be feat(core-data): , no refactor because it's an enhancement not refactoring feat(core-data): Add msg bus subscription log

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 40.63%. Comparing base (992710d) to head (a6f6ea5).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4840   +/-   ##
=======================================
  Coverage   40.63%   40.63%
=======================================
  Files         109      109
  Lines       10427    10427
=======================================
  Hits         4237     4237
  Misses       5828     5828
  Partials      362      362

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

@M0hanrajp sorry, that's my bad, I realezed your original commit message is correct
refactor prefix is the right way to go, because there is no behavior change here

it's fine to keep it as is since it has been merged

@M0hanrajp sorry, that's my bad, I realezed your original commit message is correct refactor prefix is the right way to go, because there is no behavior change here

OK Thanks for letting me know.


Require PHP 5.4

The CronBundle uses short-array syntax a lot, which isn't compatible with PHP 5.3

Changes were applied in scope of other commit, closing this PR.


Bug: Changing the font size when inputting does not take effect

Lexical version: latest
Steps To Reproduce

open https://playground.lexical.dev/
Change font size when inputting

https://github.com/facebook/lexical/assets/84793349/5d13a4a3-f4f7-44fa-833a-3416708fa2db

Link to code example:

The current behavior
Changing the font size when inputting does not take effect
The expected behavior
Input can change font size

Hi @StyleT , I want to try this. This is the first time I am contributing to open-source. How can I assign this to myself?

Hi @zhuba-Ahhh @StyleT, I somewhat got the solution. It is taking effect but we have to press enter as it is been stated in onKeyDown that you have to press enter to change the state of the font size.

Yes, I have found that pressing Enter is effective, but simply typing to change the value in the input box is not effective. You can try

As like we are handling the onChange and onKeyDown event, we have to handle, onBlur event. My suggestion is to remove onKeyDown handler and just use the onBlur event to handle the change of the font.

Hi @zhuba-Ahhh As like we are handling the onChange and onKeyDown event, we have to handle, onBlur event. My suggestion is to remove onKeyDown handler and just use the onBlur event to handle the change of the font.

Yes, you can try it like this?

You might be right, who will be the right person to comment on this? You or someone else? I am new to this so I don't know.

According to me

Either to remove the onKeyDown event and add the onBlur event
We can include both the event

What do you think?

Hi @StyleT , I want to try this. This is the first time I am contributing to open-source. How can I assign this to myself?

Just comment here that you'll work on it and submit a PR ;) Even if 2+ people submit concurrent PRs (never happens, almost) - it's ok.

Hey @StyleT , I am working on it, i have submitted my code for review. So hope so that it will be assign to me.


What is Wrist Twist Detection？

How can i touch off Wrist Twist Detection by moving screen？

Hi @maoqis, you can checkout this video on yourtube to see how to do a wrist twist gesture
https://www.youtube.com/watch?v=P95eCwkPS4w

thanks!

Closing as I am assuming this works for you 😄


⚠ Bofrost.si has degraded performance

In 15197a8, Bofrost.si (https://www.bofrost.si) experienced degraded performance:

HTTP code: 200
Response time: 4966 ms

Resolved: Bofrost.si performance has improved in cf271b4 after 12 minutes.


Review for "asdf1_d" where "asdf_1d" should be used.

Seriously considering mooting this by switching back to Java style method/field mangling (e.g. only occasionally adding "r#" prefixes, or "_" postfixes, and adding type info to disambiguate overloads.)


Updated the developers guide, the user guide, and used assert.

Codecov Report

Merging #88 (4e0cd25) into master (142c801) will decrease coverage by 0.08%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master      #88      +/-   ##
============================================
- Coverage     72.65%   72.57%   -0.09%
- Complexity      529      530       +1
============================================
  Files            87       87
  Lines          1686     1688       +2
  Branches        183      183
============================================
  Hits           1225     1225
  Misses          406      406
- Partials         55       57       +2

Impacted Files
Coverage Δ
Complexity Δ

...late/logic/parser/DeliveryStatusCommandParser.java
80.00% <0.00%> (-20.00%)
3.00 <1.00> (+1.00)
:arrow_down:

Continue to review full report at Codecov.

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


Case study: Ticketed lock

Successfully prove the ticketed lock, as described by the Starling script:
constraint emp                       => ticket >= serving;
constraint holdTick(t)               => ticket > t;
constraint holdLock()                => ticket > serving;
constraint holdLock()  * holdTick(t) => serving != t;

// These combinations cannot hold:
constraint holdTick(t) * holdTick(t) => false;
constraint holdLock()  * holdLock()  => false;

/*
 * Locks the ticket lock.
 */
method lock() {
  {| emp |}
    <t = ticket++>;
  {| holdTick(t) |}
    do {
      {| holdTick(t) |}
        <s = serving>;
      {| if s == t then holdLock else holdTick(t) |}
    } while (s == t)
  {| holdLock |}
}

/*
 * Unlocks the ticket lock.
 */
method unlock() {
  {| holdLock() |}
    <serving++>;
  {| emp |}
}

This is a fairly simple application of Starling, and is at time of writing the main case study driving tool development.

This is now possible with recent starling builds; closing.


vEOS requires it's ma1 interface to be the first interface in the bus

Attempting to fix #160.
I've tested my code against 2 lots of vEOS versions and also a CSR to ensure that still works

So without this patch, which interface is first on the bus? Do you have a full output from ps or something? I thought mgmt was the first one already.

I also had some issues with very new vEOS images: I was able to telnet but could not SSH although the management interface looked correctly configured.
I will try to spawn them again soon and come back with more details if needed.

I can confirm that SSH does not work without this patch, and that it works with it.
+1 for merging.

I have finally tested these changes, and I also confirm that it doesn't work without them. Thanks @grahamneville.

Thanks @grahamneville! I've also confirmed that on 4.20.1F it works.
@plajjan Can we have this patch merged?

@emjemj Since you have the merge/push keys. Pretty please.

If you say so, I'm not able to test myself unfortunately.

Thank you.


Backslash parsing problem in argument.

Describe the bug
Read string option with backslash \ and " results in reading " in the string.
To Reproduce
public class Options
{
    [Option('P', "path", Required = true, HelpText = "Set working directory path.")]
    public string Path { get; set; }
}

static void Main(string[] args)
{
    string path = "";

    var result = Parser.Default.ParseArguments<Options>(args)
           .WithParsed(o =>
           {
               path = o.Path;
           });

    if (result.Tag == ParserResultType.Parsed)
    {
        Console.WriteLine($"Path: {path}");
    }
}

Passing in argument -P "C:\path\to\read\"
Console output is Path: C:\path\to\read"

Expected behavior
Read backslash as it is. In the above example, output should be Path: C:\path\to\read\
Additional context
Am i missing some options?
Ref issues/226 reports the same problem, still not fixed?

This particular behavior is not a bug in the library.

Ref https://github.com/commandlineparser/commandline/issues/226 reports the same problem, still not fixed?

It's not caused by the library, nor can it be solved by the library. If you would have bothered to read the response in the issue you linked, you would know what is going on... :-(
Inspect the args array you are passing, and you might be surprised by what you see.
(Basically, what you observe is the typical behavior by the program start-up which is creating the args array for the Main method from the commandline string provided to the program. This behavior is equivalent to the WinAPI function GetCommandlineArgs. Plus, the syntax rules of the shell to type in the commandline arguments also has an effect on what the commandline string passed to the program will look like.)


AAP-21128: Admin Dashboard: [staging] Segment/Amplitude integration

See https://issues.redhat.com/browse/AAP-21128
This sets the Segment API Write Key for the staging environments.
Segment configuration completed by: https://issues.redhat.com/browse/PRODAY-77

/ok-to-test


python3Packages.lc7001: init at 1.0.3

Motivation for this change
Python module for interacting with Legrand LC7001
https://github.com/rtyle/lc7001
This could become a Home Assistant dependency.
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

2 packages built:

python38Packages.lc7001
python39Packages.lc7001

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

2 packages built:

python38Packages.lc7001
python39Packages.lc7001


Sublime Snippets for new files

Love the guide, and love the snippets.
However, while using them I noticed that they are limited to only being used on JavaScript files. This means that it wont work on a new, unsaved file, until the proper syntax is selected, or until it is saved as a JavaScript file.
I've got a working solution and will submit a PR shortly.

PR ?

closing, but feel free to PR

PR has already been implemented at #446

awesome!


Fix cpplint failure, causing travis CI to be red

E.g. https://travis-ci.org/marvinroger/homie-esp8266/jobs/199213998
Ran the following command successfully:
cpplint --repository=. --recursive
--filter=-whitespace/line_length,-legal/copyright,-runtime/printf,-build/include,-build/namespace,-runtime/int
./src

Thanks! 👍


AppBundle -> Upload to GPC -> Install -> Run -> Crash(only on master branch)

I'm on master flutter branch.
I've created an app and successfully tested release version.
flutter build apk
All works on emulator and physical device.
Then, I've created appbundle.
flutter build appbundle
Uploaded aab file to Google Play Console.
And on internal testing/alpha/beta/prod (same for pre-launch report) next behaviour:
Successfulling install app -> Starting app -> crash.
After that, I checked stable flutter branch and repeat all the previous steps -> All works.
So, something wrong on master branch when we creating app bundle.

App size statistic from GPC:

0.23 version - bundle created on master branch
0.24.4 version -bundle created on stable branch

I just saw this too and had to roll back the release and go back to using APKs for GPC.
Here are the logs in ADB. The contents of the AAB are below. This was from a clean build.
06-02 23:59:58.769 10423 10423 E flutter : [ERROR:flutter/runtime/dart_vm_data.cc(19)] VM snapshot invalid and could not be inferred from settings.
06-02 23:59:58.769 10423 10423 E flutter : [ERROR:flutter/runtime/dart_vm.cc(241)] Could not setup VM data to bootstrap the VM from.
06-02 23:59:58.769 10423 10423 E flutter : [ERROR:flutter/runtime/dart_vm_lifecycle.cc(89)] Could not create Dart VM instance.
06-02 23:59:58.770 10423 10423 F flutter : [FATAL:flutter/shell/common/shell.cc(218)] Check failed: vm.

I think this is the same issue as https://github.com/flutter/flutter/issues/33424, which is related to https://github.com/flutter/flutter/issues/31922 and will apparently be fixed in the forthcoming v1.7.0 dev channel release.

Dup of #31922.


Fix typo in server_jpa/configuration.md

Seems like there is no interest in my contribution. Will close it so it doesn't clutter my list of PRs


Fix es-console port to be 8080 so it works on openshift

part of https://github.com/lightbend/es-backend/issues/331

Going to include this in https://github.com/lightbend/helm-charts/pull/90 since I need it there to make the build pass.


Unable to install Ruby 2.6.x on Alpine Linux

Consider the following Dockerfile:
FROM alpine:latest

RUN apk --no-cache add \
    make \
    build-base \
    linux-headers \
    readline-dev \
    openssl-dev \
    yaml-dev \
    zlib-dev \
    curl \
    bash \
    git

# Set up Ruby
ENV HOME /root
ENV PATH $HOME/.rbenv/shims:$HOME/.rbenv/bin:$HOME/.rbenv/plugins/ruby-build/bin:$PATH
RUN curl -fsSL https://github.com/rbenv/rbenv-installer/raw/main/bin/rbenv-installer | bash
RUN rbenv install 2.6.6

Which yields the following failure:
rbenv/rbenv#7 [4/9] RUN rbenv install 2.6.6
rbenv/rbenv#7 sha256:7364b1ef28f24f37b459a6c21729ed4d88b725286f8090342d1c19f2c8981c77
rbenv/rbenv#7 0.364 Downloading ruby-2.6.6.tar.bz2...
rbenv/rbenv#7 0.365 -> https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.6.tar.bz2
rbenv/rbenv#7 14.45 Installing ruby-2.6.6...
rbenv/rbenv#7 234.0
rbenv/rbenv#7 234.0 BUILD FAILED (Alpine Linux 3.14.2 using ruby-build 20211019)
rbenv/rbenv#7 234.1
rbenv/rbenv#7 234.1 Inspect or clean up the working tree at /tmp/ruby-build.20211101115736.16.aoAbJF
rbenv/rbenv#7 234.1 Results logged to /tmp/ruby-build.20211101115736.16.log
rbenv/rbenv#7 234.1
rbenv/rbenv#7 234.1 Last 10 log lines:
rbenv/rbenv#7 234.1                                     net-telnet 0.2.0
rbenv/rbenv#7 234.1 installing rdoc:                    /root/.rbenv/versions/2.6.6/share/ri/2.6.0/system
rbenv/rbenv#7 234.1 installing html-docs:               /root/.rbenv/versions/2.6.6/share/doc/ruby
rbenv/rbenv#7 234.1 installing capi-docs:               /root/.rbenv/versions/2.6.6/share/doc/ruby
rbenv/rbenv#7 234.1 /root/.rbenv/versions/2.6.6/lib/ruby/2.6.0/yaml.rb:12:in `<top (required)>': uninitialized constant Psych (NameError)
rbenv/rbenv#7 234.1 	from /root/.rbenv/versions/2.6.6/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
rbenv/rbenv#7 234.1 	from /root/.rbenv/versions/2.6.6/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
rbenv/rbenv#7 234.1 	from -e:15:in `block in <main>'
rbenv/rbenv#7 234.1 	from -e:13:in `reject'
rbenv/rbenv#7 234.1 	from -e:13:in `<main>'
rbenv/rbenv#7 ERROR: executor failed running [/bin/sh -c rbenv install 2.6.6]: exit code: 1
------
 > [4/9] RUN rbenv install 2.6.6:
------
executor failed running [/bin/sh -c rbenv install 2.6.6]: exit code: 1

I have tested Ruby versions 2.6.6 to 2.6.8 and got the failure above. For version 2.7.0 to 2.7.4 I see a different failure:
.rbenv/versions/2.7.4/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:12:in `<module:Kernel>': uninitialized constant Kernel::Monitor (NameError)
        from /home/jenkins/.rbenv/versions/2.7.4/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:10:in `<top (required)>'
        from /home/jenkins/.rbenv/versions/2.7.4/lib/ruby/2.7.0/rubygems.rb:1444:in `require'
        from /home/jenkins/.rbenv/versions/2.7.4/lib/ruby/2.7.0/rubygems.rb:1444:in `<top (required)>'
        from <internal:gem_prelude>:1:in `require'
        from <internal:gem_prelude>:1:in `<internal:gem_prelude>'


⚠ Bofrost.fr has degraded performance

In c5d344e, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1067 ms

Resolved: Bofrost.fr performance has improved in 8704bfb.


Thief / UE3 Engine

Games status:

Thief--> Not working

Details:
Here's Thief Log: (no output error message)
=== GRVK 0.3.0 ===
I/grInitAndEnumerateGpus: app "Thief" (00000000), engine "Unreal3" (00000000), api 00015000
W/grGetExtensionSupport: STUB
W/grGetExtensionSupport: STUB
W/grGetExtensionSupport: STUB
I/grCreateDevice: 10DE:2204 "GeForce RTX 3090" (Vulkan 1.2.155, driver 461.81.0)
W/grCreateQueryPool: STUB

@xatornet which DLLs did you use, and where did you place them to get the game to recognize Mantle?

@xatornet which DLLs did you use, and where did you place them to get the game to recognize Mantle?

Just grvk's mantle64.dll and AMD's mantleaxl64.dll inside Binaries2/Win64. Then you'll be able to select it inside setup. Seems the game's implementation only allows mantle on 64bit

@xatornet it's not working for me. can you try this stubbed out mantleaxl64.dll and report back? mantleaxl64.zip

@xatornet it's not working for me. can you try this stubbed out mantleaxl64.dll and report back? make sure you delete the old logs before starting the game.
mantleaxl64.zip
Here's the new log. Same behaviour though:

=== GRVK 0.3.0 ===
I/grInitAndEnumerateGpus: app "Thief" (00000000), engine "Unreal3" (00000000), api 00015000
W/grGetExtensionSupport: STUB
W/grGetExtensionSupport: STUB
W/grGetExtensionSupport: STUB
I/grCreateDevice: 10DE:2204 "GeForce RTX 3090" (Vulkan 1.2.155, driver 461.81.0)
W/grCreateQueryPool: STUB

looks like the stub library gets loaded fine then. that's good.

Turns out the launcher requires mantle32.dll/mantleaxl32.dll present in Binaries/Win32 in order to detect Mantle. However the game crashes as soon as I launch it without any logs created.

Moving to https://github.com/libcg/grvk/issues/42


Inability to Edit Weekly Cron for Every Day of the Week in react-js-cron

Description:
I am utilizing the react-js-cron to create weekly cron expressions. However, when attempting to edit a cron expression for all days of the week, the editor automatically switches to a daily mode. Specifically, when I input a weekly cron expression for every day of the week, such as '10 10 * * *,' the editor incorrectly converts it to a daily cron format.
Here are the steps to reproduce the issue, broken down point by point:

Select the "Weekly" cron option.
Leave the "Day of the Week" setting as "Every Day."
Choose specific "Hour" and "Minute" values.
The resulting cron expression will be "10 10 * * *."
After saving this cron expression, when you attempt to edit it,
The editor incorrectly converts the default "Weekly" dropdown option to "Daily."
The "Hour" and "Minute" values are retained from the previous input.

Versions (please complete the following information):

react-js-cron version - 4.1.0
React version: 18.2.0

Hi,
If I understood your use case, it's normal.
10 10 * * * means every day of the week at 10:10, right?
But it also means every day at 10:10, right?
It's the same thing. This cron component is designed to make you read the most easy format.
Every day at 10:10 = Every week on every day of the week at 10:10 = Every month on every day of the month n every day of the week at 10:10, ect...
Let me know if I understood what you meant?

Hi @xrutayisire, thank you for your quick response.
Yes, you've understood the issue correctly. However, when we set the defaultPeriod to "Weekly" and then set the cron value as "10 10 * * *" [using default value for cron], it should persist the period as "Weekly." But it appears to be changing the period in the dropdown to "Daily."
Could you please look into this? Your assistance is greatly appreciated.

Hi,
It's true that the default value for period should be persisted.
Also, the same problem happens when we set to only allow "Weekly" period, daily will be selected when it should keep the only allowed one.
It's necessary to rework the period management and the fallback system.
I currently don't have time to fix that, if you want to open a PR I would review it.
If not, I will do it, but I'm not really sure when. Could be something in November.
Thank you for the bug report 🙏

Thanks @xrutayisire for response. I am also little bit busy with work. But I will try to look into this. Meanwhile if you get the time then kindly fix it.
Thanks in advance.

Hi,
It's true that the default value for period should be persisted. Also, the same problem happens when we set to only allow "Weekly" period, daily will be selected when it should keep the only allowed one.
It's necessary to rework the period management and the fallback system. I currently don't have time to fix that, if you want to open a PR I would review it.
If not, I will do it, but I'm not really sure when. Could be something in November.
Thank you for the bug report 🙏

Hi @xrutayisire ,
Is there any update on this?

Hi,
No sorry I really have no time since quite some time now. I'm not sure when I could take care of that in a near future. 😕


The code for the doc is wrong, functions V2 code can't be used

[Enter feedback here]
You would need to use the V1 compatible code to use OpenApi definition, so the correct code is:
using System.Net;
const double revenuePerkW = 0.12;
const double technicianCost = 250;
const double turbineCost = 100;
public static async Task Run(HttpRequestMessage req, TraceWriter log)
{
dynamic data = await req.Content.ReadAsAsync();
int hours = data.hours;
int capacity = data.capacity;
//Formulas to calculate revenue and cost
double revenueOpportunity = capacity * revenuePerkW * 24;
double costToFix = (hours * technicianCost) +  turbineCost;
string repairTurbine;

if (revenueOpportunity > costToFix)
{
    repairTurbine = "Yes";
}
else
{
    repairTurbine = "No";
}
return req.CreateResponse(HttpStatusCode.OK, new{message = repairTurbine,
        revenueOpportunity = "$"+ revenueOpportunity,
        costToFix = "$"+ costToFix
     });

}
It would be good to add the steps to select Azure Functions V1 in the beginning of the documentation, "Before creating the function, please go to 'Function App Settings' and select V1 as runtime platform".

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

ID: f713e2b2-710e-8036-c4d7-8910927525e3
Version Independent ID: bee3baa6-df72-aea1-9b0b-42f574b4745e
Content: Create an OpenAPI definition for a function
Content Source: articles/azure-functions/functions-openapi-definition.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

Hi @Jiihaa, thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@Jiihaa thanks for catching this. I will make those updates as you suggest.

This is now being tracked internally by 1394919.

Why to close an issue if it not resolved? Would be nice to see this kind of things in the "open issues" in docs before starting to work with anything which is impossible to work with.

@Jiihaa The issue has been automatically closed due to a PR merge and the updated docs would reflect in a few hours.


Add taker_fee into the swap events

also update the tokens_in and tokens_out fields so they will have the original values without the taker_fee.


add logs to bobsled output

should probably also add some sort of secret masking

env vars will now be published to the Run entries in dynamodb
should be possible to build a filter that strips them out of logs now


Documentation links are not working when viewed from GitHub

I'm submitting a...

Documentation

Current behavior
Links from https://github.com/nventive/Uno/blob/master/doc/index.md are not working when viewed on GitHub.
Expected behavior
Should work for both the docs generated site, and GitHub.

It does not seem to generate a proper link, the ~ works, but the link needs to be a .md not an .html. Is there a way for docfx to detect that in a link ?

I changed the links markup to MD syntax, which is converted to html markup on docfx build. Seems to do the trick.


Unable to compare some timestamp types

Describe the bug
A clear and concise description of what the bug is.

assertj core version: 3.25.3
java version: 21.0.1-open
test framework version: JUnit 5.10.2
os (if relevant):  Linux 6.5.0-15-generic # 15-Ubuntu SMP PREEMPT_DYNAMIC Tue Jan  9 17:03:36 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 23.10)

Test case reproducing the bug
Some timestamp types, for example, java.sql.Timestamp, are not specifically handled when comparing with other temporal types, and as a result, though there are no compile-time errors caused by types, they are not effectively compared as temporals.
public class Demo {
    @Test
    void compareSqlTimestampWithInstant() {
        final long now = System.currentTimeMillis();
        final Timestamp ts = new Timestamp(now);
        final Instant instant = Instant.ofEpochMilli(now);
        assertEquals(ts.getNanos(), instant.getNano()); // this succeeds
        assertThat(ts).isEqualTo(instant); // this fails.
        assertThat(ts).isAfterOrEqualTo(instant); // even if I want to relax the check, this still fails
    }
}

I can see there are javadocs mentioning that comparisons are done by converting these timestamp types to java.util.Date, but is there a way to make this less surprising, otherwise make it a compilation error, so the user can take care of nanoseconds?
Updated: I thought it was caused by nano-second precision being dropped along the assertion classes, but it turns out that there is no special handling of such types, and they end up calling Object.equals().

Thanks for reporting it, @IUSR.
The root cause is the usage of Date.from(Instant) internally, which doesn't behave correctly when actual is a Timestamp.
As a workaround, you can rely on Timestamp.from(Instant):
assertThat(ts).isEqualTo(Timestamp.from(instant));
assertThat(ts).isAfterOrEqualTo(Timestamp.from(instant));

Thanks for confirming, Stefano! Yes, I am currently converting the timestamp/temporal objects into the same type and comparing them as a workaround. It'd be good when things "just work", as my experience with assertj has been :)

I'm afraid we didn't fully solve the issue.
Although the original example now works, the following fails:
Instant instant = Instant.ofEpochSecond(0, 1); // 1970-01-01T00:00:00.000000001Z
Timestamp timestamp = Timestamp.from(instant);
assertThat(timestamp).isEqualTo(instant); // fails

I'll reopen it and have a look.


WSS Connection Error on captcha

Describe the bug
As you can see below here using locally and apache port forwarded to 1337 and custom setted port in config on 1337 itll just display this all the time
Screenshots or Logs

Configuration (please complete the following information):

Edge, Chrome, Firefox
Apache on Ubuntu

Did you configure Apache to support websockets? See: https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy#apache

well. F on me i guess.


pricingPhaseList property on android is not typed as a list

Description
The pricingPhaseList property is typed as an object but returns a list.
Expected Behavior
Should be typed as a list
Environment:

react-native-iap: 9.0.0-rc.1

Opened up #1827 to fix this

Merged


How to customize scaffold title

The default scaffold title when no widgets selected is Storybook, how do I customize this text to something I want.

Hey, it's not possible in the current version.
Also, keep in mind that the next version will have no default scaffold at all. You can try the current pre-release version to check how it looks like (although, it has some breaking changes).

The new version is released without scaffold.


Documentation for helm charts

Add a README for each helm chart. For now this should focus on documenting the values.
Example for inspiration https://github.com/aws/karpenter-provider-aws/tree/main/charts/karpenter

I can work on this @niallthomson

Thanks @dshamanthreddy the helm charts can be found here https://github.com/aws-containers/retail-store-sample-app/tree/main/deploy/kubernetes/charts
You can ignore the opentelemetry one as it will likely be removed soon.


Asynchronous signature verification on validator registration

Abstract
This proposal removes immediate signature verification of new validator registrations, making the verification asynchronous. The information about verification status shouldn’t be returned from the registration endpoint any more, and instead queried from data API.
This change removes a CPU bottleneck in the relay, along with possible DOS attack vectors, and allows registration process to be resilient to high loads.
With the current process, relays don’t have an even load and relay operators need to use expensive infrastructure to cover the load spikes. As the signature verification failure status is not used in the flow, relaxing the spikes should greatly reduce relay’s maintenance costs, increasing the number of people who can afford running relays.
Motivation
This change addresses a number of problems and threats to the relay ecosystem that are the effect of verifying registration signatures on register validator submission.
The mainnet right now has more than 400k validators and we expect this number to grow with Ethereum adoption. There are existing mechanisms that on every epoch re-register existing validators, resending hundreds of thousands of validator registrations in the few first seconds of an epoch.
Verifying signatures is not a computationally trivial operation - to carry the CPU load a singular relay instance needs to be run on an oversized server that is not utilizing its computing power for the rest of an epoch.
The current implementation of [mev-boost](https://github.com/flashbots/mev-boost/blob/main/server/service.go#L276-L284) does not return error contents back to the validator on failed registration.
The verification of registration signatures is also not immediately used as the registrations are only used to be returned later by the api endpoint ([link](https://github.com/flashbots/mev-boost-relay/blob/174a4a66280aa0289551f61dbabbb17ec202c18d/services/api/service.go#L1420)).
Current network traffic characteristics are similar to a DDOS attack, as the current mechanism creates an attack vector where a bad actor sends its own registration slightly ahead of time and then floods the server with incorrect registrations. It’s also possible to completely clog the relay with just the number of new registrations.
Prior Art
The recurrent registration problem was reported a few times before, but the core of the problem was never satisfactorily resolved.
https://github.com/ethereum/builder-specs/issues/24

Relays need to be designed in a way that can handle the load. Some variance might be nice but couldn't be relied upon anyway.

This change is meant to eliminate the CPU-bound performance problems, without changing the entire network’s behavior.
Detailed Description
Current Validator registration process:

Receive http request
Decodes request’s body into json array of validator registration objects
For every element of the array check series of parameters (e.g. submission time, is known validator)
Additionally to the checks, the signature verification are performed to verify payload authenticity
For every successful verification, registration is persisted in the storage.

This proposal aims to make the signature verification (step 4) asynchronous.
The only reason a good, lawful and honest validator may be concerned about its signature state is at the time of its initial or consecutive deployments, i.e. when configuration can change. There is no benefit to knowing it is still correct on every deployment.
Therefore, the information about the state of verification may be offloaded into a separate endpoint and removed from (POST) /relay/v1/builder/validators . It can be achieved by extending  /relay/v1/data/validator_registration  with additional enum field - status.
Go (possible implementation)
type Status int64

const (
	Unverified Status = iota
	Verified
	Invalid
)

// SignedValidatorRegistration https://github.com/ethereum/beacon-APIs/blob/master/types/registration.yaml#L18
type SignedValidatorRegistration struct {
	Message   *RegisterValidatorRequestMessage `json:"message"`
	Signature Signature                        `json:"signature" ssz-size:"96"`
  Status    Status                           `json:"status"`
}

https://github.com/flashbots/go-boost-utils/blob/main/types/builder.go#L200-L204

The endpoint would then return:
{
  "message": {
    "fee_recipient": "0xabcf8e0d4e9587369b2301d0790347320302cc09",
    "gas_limit": "1",
    "timestamp": "1",
    "pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a"
  },
	"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
  "status": 1 // or possibly in a string form "verified"
}

The new process would assume that after successful initial verification (e.g. submission time, is known validator) every registration would be persisted with the default unverified state.
It should be left for the relay development team to decide on implementation details, however, the goal for the verification itself is to become “eventually verified”.  This new flow would allow various improvements not limited to verifying signatures in the background process, throttling the number of parallel calculations, or calculating signatures only upon request.
For existing relay implementations it would still be possible to preserve verification calculations on submission and save as already verified.
Backward Compatibility
This change introduces a weak inconsistency for people who were expecting to find an error on incorrect signature - that should no longer be returned.
Change to the /relay/v1/data/validator_registration endpoint is additive - meaning there are no protocol-breaking changes.
In existing codebases, the value can still be calculated in the same place as it was before and saved as already verified. So no big immediate changes should be needed.
Dependencies
This proposal doesn’t depend on any other work.
Risks and Security Considerations
There is no standard of the multi-validator registration process - it is unclear how relays should behave upon a failure of one validator. From the user perspective, it’s undesirable to fail all validators in the payload if one has a broken signature. This change allows all validators that passed pre-check to be registered and discarded only when needed.
Rationale and Alternatives
As described above this change targets performance improvements for good, lawful and honest validators, as signatures may only change during the deployment of a new configuration, followed by a process restart. There is no benefit to verifying that one’s signature is still correct for every request. Furthermore, current implementations of processes like mev-boost would not return this information back to the validator either.
This simple change can allow relays to use smaller servers, utilizing more of the cpu idle time - as we no longer have 3s window for verifying >400k signatures - allowing more people to afford running relays.

My main concern with this approach is that it changes guarantees of when a registration would be available for a block builder, something the validator wants ASAP presumably. But the spec currently doesn't have a notion for that:
Validators should submit valid registrations well ahead of any potential beacon chain proposal duties to ensure their building preferences are widely available in the external builder network.

Following such a change, consensus clients would need to change their behavior so that they wait something like RELAY_REGISTRATION_VERIFICATION_EPOCHS before verifying successful registrations. Which would benefit from a multi registration endpoint check. The tradeoff is a little more complexity on the validators behalf for substantial reduction of requirements on relays.

More significantly, any interaction between the beacon node and builder network should be governed by this repository (builder-specs) only, and be part of the /eth/v1/builder URL namespace.
Furthermore, the data API is an optional, read-only API that just provides information, which I think is how it should stay.

Hello @metachris  :)
So this proposal addresses a general performance problem that comes from the uneven load to the relays, caused by all validator registrations are being requested in a very small time window.  I totally understand that the mitigation of this would be problematic or even impossible. As we know, right now we have 480k validators and we can expect this number to grow overtime as the Ethereum ecosystem adoptability would increase.
So getting some numbers - using a benchmark similar to this (https://go.dev/play/p/qIkX32P72xU)
running locally on my laptop (cpu: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz)
and tweaked CGO call to be called just two times per goroutine.
For only 100k verifications running in "pseudo" parallel, I'm starting getting >2s times at the end of the test. And thats less than 1/4 of total validators in the network.
...
37.935837ms 37.728061ms 37.523928ms 2.9077741s 2.905973879s 39.033587ms 2.94450452s 253.90337ms 2.786395929s 2.807140238s 3.04535983s 309.566367ms 279.77344ms 312.924829ms 2.820837326s 2.750283127s 3.166437639s 3.339986995s 2.835711676s 2.723569409s 3.038397519s 2.576335097s 3.013019202s 38.933431ms 2.720233617s 2.362865309s 2.776145867s 3.681909227s 2.895910462s 2.915738048s 2.995064506s 3.113350071s 2.834942554s 2.728928558s 292.017123ms 2.780016954s 2.728749649s 2.727139215s 2.726702378s 42.569885ms 2.718879444s 2.696528209s 2.752178562s 2.699053796s 2.670845901s 2.765461856s 2.750473287s 2.602536422s 2.75083412s 3.633679448s 2.50511517s 2.415705863s 2.749493338s 2.660235112s 240.622069ms 3.043937598s 2.914697023s 2.751057663s 2.625962425s 2.751828603s 2.492199364s 2.504997482s 43.800332ms 2.330705368s 2.94870707s 2.601791192s 2.593560958s 2.749524767s 53.447823ms 4.264518309s 2.38180683s 2.377050874s 2.329720002s 41.080284ms 37.103973ms 39.119569ms 2.367715328s 2.345738463s 36.873379ms 2.624762982s 2.634
473542s 38.450864ms 2.584475202s 3.050292374s 38.447486ms 2.641822882s 61.061044ms 3.508749847s 43.896506ms 2.602160536s 42.757587ms 3.025659504s 2.818663048s 2.412669092s 2.661324843s 51.716491ms 3.0502516s 2.632646561s 3.051142488s 255.869857ms 60.742465ms 2.754216055s 2.624122268s 2.613799906s 56.339688ms 2.339848668s 2.472792414s 2.700297608s 2.698910354s 54.795769ms 61.692674ms 53.813275ms 2.754934288s 2.624789041s 2.4788049s 2.442373473s 2.360090553s 2.748827285s 2.196213833s 2.595349887s 2.475422718s 2.608756717s 52.989874ms 2.428796966s 2.605602633s

This comes from the fact that there is a finite number of cores that ultimately just gets flooded by number of calculations you need to do. So purely from the performance problem - that's pretty heavy bottleneck.
Answering your last concern first - The description of getValidatorRegistration endpoint in the only documentation (https://flashbots.github.io/relay-specs/#/Data/getValidatorRegistration) quite clearly states that this endpoint to "Check that a validator is registered with the relay" and that it is "Useful to check whether your own registration was successful."
So it's exactly for this particular purpose.
So noone is suggesting any changes to the API other than:

Adding status to field to the getValidatorRegistration response, so that people can actually know that their registration was unsuccessful, as this information it's currently not returned by mev-boost back to the validator.
Only optionally fail on validator registrations that are incorrectly submitted - as there is no benefit of retuning that information to the users on every call.

If you desire - this does not require literally any changes in your implementation - other than adding a static status: "verified" into validator registration endpoint - as flashbots relay would always verify it right away,  and that's all.
However as signature verification is no longer necessary to be done upon registration this would open up many different approaches to solving the bottleneck.
Writing a document above, I did my best to create a change that would requite almost zero engagement from relay authors - and that would really solve and not just mitigate the CPU bottleneck. I understand that some ways of mitigating this performance problems but it should be in the hands of relay authors to decide wether they should use cache it or solve it the other way.
For the cache itself as currently the validator endpoint is publicly opened, if I'm not mistaken - any person can easily create an attack script that would submit a random payloads bypassing the cache "guards". And by doing this constantly you can make relay unresponsive with fairly small number of payloads using a cheap instance. And if you don't do this on submission process - as suggested above - it's impossible to make relay unresponsive because of this bottleneck.

I think that there may be a case for asynchronous verification of validator registrations, but before this the synchronous path should be optimized to see if it is really necessary as it does add a level of complexity for validators beyond the current "if I receive a successful registration message then I know the registration was good".
There is a lot that can be done with validator registrations beyond what exists in either dreamboat or the flashbots MEV relay today.  Some notes on this:

creating signatures and public keys from byte arrays is a relatively expensive operation, so should be avoided if possible, and certainly not carried out in advance of its use.  For where it is required, maintaining a map[[48]byte]*Pubkey for public keys and a similar map for signatures avoids unnecessary recomputation
keeping track of prior successful registrations with a map[[48]byte]*SignedValidatorRegistration, where the [48]byte is the validator's public key, allows simple checks to be made against new validator registrations (e.g. if the fee recipient address and timestamp are the same then it can be flagged as valid without further checks; if the fee recipient address is the same but the timestamp later then it can be flagged as valid and the signature checked out of the critical path to decide whether or not to update the map)
to avoid cold start issues the maps above can be stored on disk periodically, and read back on start.  However, the process should not rely on a disk-based database to read in this data as it will be significantly slower than an in-memory map (even with appropriate mutexes to protect it)

And of course concurrency should be used as much as possible to parallelize operations where large numbers of registrations are received at the same time.
It is also worth exploring the issue where there is a large spike of registrations around the epoch.  There is, as far as I am aware, no technical reason why the registrations all need to arrive at this particular point in time (and indeed Vouch sends them roughly half way through the previous epoch).  Making a change to spread the submission of validator registrations out could provide a solution in itself, and I have kicked off a discussion around this.


Factor out CI for dataset repos

Currently there is only one dataset with CI scripts stored directly inside. We need to factor this out so that the scripts can be shared between repos.

Done. The workflows are here: https://github.com/RiverBench/ci-workflows


more specific siege dialogue

is it possible to restore more specific siege dialogue when the co says we're taking the capital
i know it exists cause rikke says it when taking winterhold and riften
example:

instead she says were taking markarth

Regrettably no. Since these sieges were never triggered in Vanilla, Bethesda never recorded the lines. :(


Support for uploading directly to IA

FOS is a bottleneck at the moment, and it looks like we can actually get away with simply uploading the files to the collection, one item per pipeline per calendar date with many WARCs, and have essentially the same result we have now.  This patch adds a new mode of operation for the uploader; do not set RSYNC_URL, but do set S3_URL, IA_COLLECTION, IA_ITEM_TITLE, IA_AUTH, and IA_ITEM_PREFIX, and the items will go directly to IA.
Current functionality is undisturbed.

I haven't looked over this in great depth, but it seems to be doing pretty well in production.  If nobody has any objections in the next day or two, I'll merge it.


Rendering issues for generated API docs

We run gen-crd-api-reference-docs in "markdown" mode, where it will process doc comments as markdown, but it's buggy and incorrect for some links.
An example is this line which is converted to:

Server is the connection address for the Vault server, e.g: “https://vault.example.com:8200”.

That invalid link ends up getting parsed a second time (when we render the file using next.js) and we end up creating a second  inside the first  which is even more invalid. That then confuses React which expects only valid HTML, and it prints lots of errors (but renders OK, I think).
A possible solution would be to parse all of the docs comments as HTML, but that's not possible because some of them are invalid HTML and in any case a lot of them use Markdown so it'd be tedious to change it for all CRDs on all branches.

I created an example using just blackfriday which illustrates the error:
package main

import (
	"fmt"

	"github.com/russross/blackfriday/v2"
)

func main() {
	fmt.Println(string(blackfriday.Run([]byte(`for example: "https://example.com"`))))
}

This produces this output:

for example: “https://example.com”

On both the version of blackfriday used by gen-crd-api-reference-docs and on the latest version

Note: In #1170 we add trust-manager API doc generation with crdoc (https://github.com/fybrik/crdoc/) which doesn't seem to have the same problems with invalid HTML generation. It might not be a universal solution for everything but it might be better to use that for cert-manager, too.


⚠ Minecraft has degraded performance

In 7385a56, Minecraft (https://www.minecraft.net) experienced degraded performance:

HTTP code: 200
Response time: 1185 ms

Resolved: Minecraft performance has improved in f696f50.


notification can't send mails if the displayname has a comma

Describe the bug
If the display name of a user has a comma, the notification service can't send a mail, because the sender is not in commas which has to be with a comma in the string.
Steps to reproduce

Change the display name to "Tux, Eberhard"
Send a Mail via the notification

Expected behavior
Mails should be send from this user.
Actual behavior
Mails are not send and have a error in the notifications logs
{"level":"error","service":"notifications","error":"Mail Error: mail: missing '@' or angle-addr; Header: [From] Address: [Tux, Eberhard via owncloud@mymail.com]","e
vent":"SendEmail","time":"2024-06-14T16:06:31Z","line":"github.com/owncloud/ocis/v2/services/notifications/pkg/service/service.go:129","message":"failed to send a message"}
Setup
OCIS 5.0.5 with helm charts deployed
Additional context

@b1schumacher Thank you for your report. I'll take a look ASAP.

@2403905 There is already a merge request which fixes this #9403


[rabbitmq] remove CommonName from tls cert

The CommonName has a max length of 64 bytes. Since the CommonName value is already in the DnsNames of the certificate it is not required.

manually tested in a fips enabled env that rabbitmq properly starts and services connect.

seems to be fine for FIPS so it should be OK.

/cherry-pick 18.0.0-proposed


Environment Error

When I was setting the environment and installing the packages mentioned in the requirements.txt, I met an ERROR as follows:
ERROR: Command errored out with exit status 1:
command: /home/yifan/anaconda3/envs/ringnet/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-Ad2D66/pyrender/setup.py'"'"'; file='"'"'/tmp/pip-install-Ad2D66/pyrender/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-exZ7Iq
cwd: /tmp/pip-install-Ad2D66/pyrender/
Complete output (29 lines):
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
ERROR: Package 'imageio' requires a different Python: 2.7.18 not in '>=3.5'
Traceback (most recent call last):
File "", line 1, in
File "/tmp/pip-install-Ad2D66/pyrender/setup.py", line 70, in
include_package_data=True
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/setuptools/init.py", line 161, in setup
_install_setup_requires(attrs)
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/setuptools/init.py", line 156, in _install_setup_requires
dist.fetch_build_eggs(dist.setup_requires)
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/setuptools/dist.py", line 721, in fetch_build_eggs
replace_conflicting=True,
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/pkg_resources/init.py", line 782, in resolve
replace_conflicting=replace_conflicting
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/pkg_resources/init.py", line 1065, in best_match
return self.obtain(req, installer)
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/pkg_resources/init.py", line 1077, in obtain
return installer(requirement)
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/setuptools/dist.py", line 777, in fetch_build_egg
return fetch_build_egg(self, req)
File "/home/yifan/anaconda3/envs/ringnet/lib/python2.7/site-packages/setuptools/installer.py", line 130, in fetch_build_egg
raise DistutilsError(str(e))
distutils.errors.DistutilsError: Command '['/home/yifan/anaconda3/envs/ringnet/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp4D3zxq', '--quiet', 'imageio']' returned non-zero exit status 1
----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

Could you please give me a favor?

same error QAQ

It's a bit late but can be fixed by installing an older version of Imageio
pip install imageio==2.6.1


Cannot save OGG files

Self-explanatory title is self-explanatory.
Here's the steps how to reproduce it:

Open an OGG file.
Fill up values in the application. It shouldn't matter but edit the release year just to be safe since it seems to be where the error came from glancing at the traceback (which is attached later in this issue).
Save the file.

What is expected? Should save the file successfully.
What happened? An error popped up.

This is installed with Flatpak, version 0.2.0.
Running it in the command line to see the output, it printed the following traceback:
Traceback (most recent call last):
  File "/app/share/eartag/eartag/file.py", line 163, in save
    file.save()
  File "/app/share/eartag/eartag/backends/file_mutagen_vorbis.py", line 74, in save
    self.mg_file.save()
  File "/app/lib/python3.9/site-packages/mutagen/_util.py", line 156, in wrapper
    return func(self, h, *args, **kwargs)
  File "/app/lib/python3.9/site-packages/mutagen/ogg.py", line 587, in save
    self.tags._inject(filething.fileobj, padding)
  File "/app/lib/python3.9/site-packages/mutagen/oggvorbis.py", line 137, in _inject
    vcomment_data = b"\x03vorbis" + self.write()
  File "/app/lib/python3.9/site-packages/mutagen/_vorbis.py", line 178, in write
    self.validate()
  File "/app/lib/python3.9/site-packages/mutagen/_vorbis.py", line 158, in validate
    raise ValueError(err)
ValueError: 1995 needs to be str for key 'date'

I also built and tested the application with Nix and it gave the same error.

That was quick. I can confirm it's been fixed. Thank you! (And doubly thanks for creating this app. It goes nicely with Amberol, too.)