Current documentation version is still either outdated or release variable is still incorrect

Continuation from Ticket #328
Currently, the docs have a release variable of 1.2.0beta. Are the docs out of date (and not in sync with the current release of pysaml2 (version 4.5.0)? Or are the docs up to date and the release variable is wrong?
The impact of this is that when searching for and viewing the docs they show as being for a very different version of the code than the user would be using. This version (1.2.0beta) shows up both in the docs and in search results pointing to the docs.
The end result is that when the users searches for docs for pysaml2 4.5.0, they only find docs for 1.2.0beta which is confusing.
The version number in the docs is 1.2.0beta. There haven't been any commits that would change the version number since @rohe set the version in October 2014. The intent of this value is to be "the major project version" of the software for which the documentation applies.
So assuming the documentation in the head of master applies to the current version 4.5.0 of pysaml2, then the "version" and "release" values should be 4.5.0
Fixes for this are either

Set the version and release variables in conf.py to the value in src/saml/__init__.py
Set the version and release variables in conf.py to ''

I made the relevant change and I am now closing this.
Thanks for the input 👍


Add ability to remember forum sort option

It was quite inconvenient that forums didn't remember the previously sort option, this was particularly an issue for the event forums which default to the "Event Time" sorting option.

@amytant Is this for Kraken or the web UI? I'm browsing in the web UI and it's remembering just fine.

I specifically mean that when you navigate away from a forum and then navigate back to it, the previously selected sorting option is no longer applied.

Ah ha. The breadcrumb link takes you to /forums which does not support sorting. So when you go into a forum category again it does not preserve. We'd need to store the sort information in the browser state/session.


IsHandTrackingEnabled called and crashes dedicated servers.

Dedicated servers crashes when a VR player joins.
Visual studio debugger shows that the bug is from FOculusHandTracking::IsHandTrackingEnabled function.
In another project, I've fixed the crash by returning false before any null errors can be made. Though this fix would probably result in handtracking not working.
To get the debugger to work, you need to go into project files and enable 'include debug files', and then build the dedicated server build of the game. You then attach the process of the built dedicated server after you've launched it.

Thanks for the report!
Could you clarify the context of the issue? Are you running the sample project or are you using OculusHandTools in a different project?
If you're trying to run the sample with networking, that's not currently supported.

Thanks for the report!
Could you clarify the context of the issue? Are you running the sample project or are you using OculusHandTools in a different project?
If you're trying to run the sample with networking, that's not currently supported.

I've tested this bug on both my project and on  this project. It's not the issue of the project not being multiplayer, it's that dedicated servers crash when a VR player joins.
If this would be best to put on another repo, please do redirect me.

This does seem to be an issue with the Oculus engine plugin.
That said, what code is calling IsHandTrackingEnabled? Are you using OculusHandTools or is the function being called from your code? Either way, the workaround (without modifying the function as you did) is to check for IsDedicatedServer before the call.

IsHandTrackingEnabled is called just from having the oculus plugin and joining a server. The solution I've found so far(while still annoying) is to just disable the plugin or return false while building the server. I imagine that removing the plugin would cause issues if the server has to execute any code from the plugin though.
I'll try using your solution and let you know if it works.
Thank you. :)


index.txt crosses export configs

TL;DR
When there are multiple export configs on a single instance, the index.txt file seems to cross the streams as it were.
For example, this is a sample from an export that should only contain "CH" region TEKs
exposureKeyExport-CH/1593446400-1593446700-00001.zip
exposureKeyExport-US/1592240400-00001.zip

Expected behavior
The different export configs have separate index.txt files
Observed behavior
They were merged

@gurayAlsac looked at the configs and it seems we are collecting all in regions right now, so this makes sense.
main=> select filename_root, output_region, input_regions from exportconfig ;
    filename_root     | output_region | input_regions
----------------------+---------------+---------------
 exposureKeyExport-US | US            |
 exposureKeyExport-CH | CH            | {}
(2 rows)

I propose we collect input US output US, input CH, output CH, and output ALL input {}

Clarification: if no input region specified it should be output region

When the filename root differs between export configurations, it seems that index.txt files still refer to files from other export configurations (and therefore in different filename roots).

originally, output region was just region
when I introduced the input region, the intent was that if that was an empty array, then the output region would be used.
I think an implicit "all" is potentially dangerous as it makes it really easy to over-export keys.

/assign


[release] org.jreleaser.sdk.commons.RestAPIException when releasing to gitlab.com

Task List

[x] Steps to reproduce provided
[x] Stacktrace (if present) provided
[x] Example that reproduces the problem (link to git repository is ideal)
[x] Full description of the issue provided (see below)

Context
I am in the process of trying to use JReleaser for a multi-module maven project dbnary. The configuration of the project is the following

dbnary (root project and parent pom)

many modules
dbnary-commands (the modules that define the command lines, generate the appassembly and the tar.gz + zip assemblies

The jreleaser configuration is defined in a profile in the root project and bound to deploy phase:
    <profile>
      <id>jreleaser</id>
      <!--properties>
        <jreleaser.git.root.search>true</jreleaser.git.root.search>
      </properties-->
      <build>
        <pluginManagement>
          <plugins>
            <plugin>
              <groupId>org.jreleaser</groupId>
              <artifactId>jreleaser-maven-plugin</artifactId>
              <version>1.0.0-M2</version>
              <configuration>
                <jreleaser>
                  <project>
                    <name>DBnary</name>
                    <java>
                      <mainClass>${app.main.class}</mainClass>
                    </java>
                  </project>
                  <release>
                    <gitlab>
                      <owner>gilles.serasset</owner>
                      <name>dbnary</name>
                      <host>gitlab.com</host>
                      <overwrite>true</overwrite>
                      <commitAuthor>
                        <name>gilles.serasset</name>
<EMAIL_ADDRESS>                      </commitAuthor>
                    </gitlab>
                  </release>
                  <distributions>
                    <dbnary>
                      <tags>
                        <tag>cli</tag>
                      </tags>
                      <artifacts>
                        <artifact>
                          <path>
                            ${app.distribution.directory}/${project.artifactId}-${project.version}.zip
                          </path>
                        </artifact>
                        <artifact>
                          <path>
                            ${app.distribution.directory}/${project.artifactId}-${project.version}.tar.gz
                          </path>
                        </artifact>
                      </artifacts>
                    </dbnary>
                  </distributions>
                </jreleaser>
              </configuration>
              <executions>
                <execution>
                  <id>make-distribution</id>
                  <phase>deploy</phase>
                  <goals>
                    <goal>release</goal>
                  </goals>
                </execution>
              </executions>
            </plugin>
          </plugins>
        </pluginManagement>
      </build>
    </profile>

the dbnary-commands module activates jreleaser in the same profile id:
    <profile>
      <id>jreleaser</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.jreleaser</groupId>
            <artifactId>jreleaser-maven-plugin</artifactId>
          </plugin>
        </plugins>
      </build>
    </profile>

Notes all these commands are launched locally (not in gitlab CICD):

mvn package runs fine (creates the appassembler and assemblies zip/tar.gz
JRELEASER_GITLAB_TOKEN=.... mvn -e -Djreleaser.dry.run=true -Pjreleaser deploy runs fine
JRELEASER_GITLAB_TOKEN=.... mvn -e -Pjreleaser deploy breaks

The specified token is a gitlab personal access token bound to my account (repo owner) with all scopes checked.
Expected Behaviour
I'm expecting the mvn deploy to send the assemblies as a gitlab release
Actual Behaviour
The command breaks with an error, while on the gitlab instance, the tag is created and the release attached to it contains the changelog + 4 source assets (zip, bz2, tar.gz and tar), but no other files.
Stack trace is :
[INFO] --- jreleaser-maven-plugin:1.0.0-M2:release (make-distribution) @ dbnary-commands ---
[INFO] JReleaser 1.0.0-M2
[INFO]   - basedir set to /Users/serasset/dev/dbnary/gitlab/dbnary
[INFO] Loading variables from /Users/serasset/.jreleaser/config.properties
[WARNING] Variables source /Users/serasset/.jreleaser/config.properties does not exist
[INFO] Validating configuration
[INFO] Project version set to 3.0.3-SNAPSHOT
[INFO] Release is snapshot
[INFO] Timestamp is 2022-02-16T12:59:55.334973+01:00
[INFO] HEAD is at 7b50a00
[INFO] Platform is osx-aarch_64
[INFO] dry-run set to false
[INFO] Generating changelog: dbnary-commands/target/jreleaser/release/CHANGELOG.md
[INFO] Calculating checksums
[INFO]   [checksum] dbnary-commands/target/distributions/dbnary/dbnary-commands-3.0.3-SNAPSHOT.zip.sha256
[INFO]   [checksum] dbnary-commands/target/distributions/dbnary/dbnary-commands-3.0.3-SNAPSHOT.tar.gz.sha256
[INFO] Signing files
[INFO]   [sign] Signing is not enabled. Skipping
[INFO] Uploading is not enabled. Skipping
[INFO] Releasing to https://gitlab.com/gilles.serasset/dbnary
[INFO]  - uploading dbnary-commands-3.0.3-SNAPSHOT.zip
[ERROR]  x failed to upload dbnary-commands-3.0.3-SNAPSHOT.zip
[INFO] Writing output properties to dbnary-commands/target/jreleaser/output.properties
[ERROR] JReleaser failed after 13.003 s
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:02 min
[INFO] Finished at: 2022-02-16T13:00:08+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.jreleaser:jreleaser-maven-plugin:1.0.0-M2:release (make-distribution) on project dbnary-commands: Execution make-distribution of goal org.jreleaser:jreleaser-maven-plugin:1.0.0-M2:release failed: Unexpected error when creating release: org.jreleaser.sdk.commons.RestAPIException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jreleaser:jreleaser-maven-plugin:1.0.0-M2:release (make-distribution) on project dbnary-commands: Execution make-distribution of goal org.jreleaser:jreleaser-maven-plugin:1.0.0-M2:release failed: Unexpected error when creating release
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution make-distribution of goal org.jreleaser:jreleaser-maven-plugin:1.0.0-M2:release failed: Unexpected error when creating release
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.jreleaser.util.JReleaserException: Unexpected error when creating release
    at org.jreleaser.workflow.ReleaseWorkflowItem.invoke (ReleaseWorkflowItem.java:36)
    at org.jreleaser.workflow.WorkflowImpl.execute (WorkflowImpl.java:66)
    at org.jreleaser.maven.plugin.JReleaserReleaseMojo.execute (JReleaserReleaseMojo.java:92)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.jreleaser.model.releaser.spi.ReleaseException: org.jreleaser.sdk.commons.RestAPIException
    at org.jreleaser.sdk.gitlab.GitlabReleaser.createRelease (GitlabReleaser.java:150)
    at org.jreleaser.model.releaser.spi.AbstractReleaser.release (AbstractReleaser.java:51)
    at org.jreleaser.engine.release.Releasers.release (Releasers.java:44)
    at org.jreleaser.workflow.ReleaseWorkflowItem.invoke (ReleaseWorkflowItem.java:34)
    at org.jreleaser.workflow.WorkflowImpl.execute (WorkflowImpl.java:66)
    at org.jreleaser.maven.plugin.JReleaserReleaseMojo.execute (JReleaserReleaseMojo.java:92)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.jreleaser.sdk.commons.RestAPIException
    at org.jreleaser.sdk.commons.ClientUtils.lambda$builder$1 (ClientUtils.java:99)
    at feign.AsyncResponseHandler.handleResponse (AsyncResponseHandler.java:96)
    at feign.SynchronousMethodHandler.executeAndDecode (SynchronousMethodHandler.java:138)
    at feign.SynchronousMethodHandler.invoke (SynchronousMethodHandler.java:89)
    at feign.ReflectiveFeign$FeignInvocationHandler.invoke (ReflectiveFeign.java:100)
    at com.sun.proxy.$Proxy33.uploadFile (Unknown Source)
    at org.jreleaser.sdk.gitlab.Gitlab.uploadAssets (Gitlab.java:251)
    at org.jreleaser.sdk.gitlab.GitlabReleaser.createRelease (GitlabReleaser.java:253)
    at org.jreleaser.sdk.gitlab.GitlabReleaser.createRelease (GitlabReleaser.java:145)
    at org.jreleaser.model.releaser.spi.AbstractReleaser.release (AbstractReleaser.java:51)
    at org.jreleaser.engine.release.Releasers.release (Releasers.java:44)
    at org.jreleaser.workflow.ReleaseWorkflowItem.invoke (ReleaseWorkflowItem.java:34)
    at org.jreleaser.workflow.WorkflowImpl.execute (WorkflowImpl.java:66)
    at org.jreleaser.maven.plugin.JReleaserReleaseMojo.execute (JReleaserReleaseMojo.java:92)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException

Environment Information

Operating System: mac os x
JReleaser Version: 1.0.0-M2 maven plugin
JDK Version: 11.0.10

...
[DEBUG] uploading assets to gilles.serasset/dbnary
[INFO]   - uploading dbnary-commands-3.0.3-SNAPSHOT.zip
[ERROR]  x failed to upload dbnary-commands-3.0.3-SNAPSHOT.zip
413 Request Entity Too Large
org.jreleaser.sdk.commons.RestAPIException
        at org.jreleaser.sdk.commons.ClientUtils.lambda$builder$1(ClientUtils.java:99)
        at feign.AsyncResponseHandler.handleResponse(AsyncResponseHandler.java:96)
        at feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:138)
        at feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:89)
        at feign.ReflectiveFeign$FeignInvocationHandler.invoke(ReflectiveFeign.java:100)
        at com.sun.proxy.$Proxy33.uploadFile(Unknown Source)
        at org.jreleaser.sdk.gitlab.Gitlab.uploadAssets(Gitlab.java:251)

After trying to figure out what happened, I noticed that I checked the trace.log from the root project that dated from another attempt...
I updated the trace.log and it gave me the reason :
413 Request Entity Too Large
My apps zip and tar.gz are around 50M and it appears that the attachement limit on gitlab.com is 10M.
AFAIK there is no way to change this limit on a repository basis... Will have to try another upload infra...

You can try using the uploadLinks feature. This requires uploading assets to an external location such as AWS S3 or a JFrog Artifactory instance. https://jreleaser.org/guide/latest/configuration/release/gitlab.html
Here's how the taxi-lang project does it as they faced the same problem https://gitlab.com/taxi-lang/taxi-lang/-/blob/develop/taxi-cli/jreleaser.yml

Well, I do not have access to s3 or artifactory instance, but could upload using ssh. Are there plans to allow wagon-ssh like uploads ?

Possibly. We also support custom HTTP/HTTPS of your choice as long as the service supports POST or PUT. Upload via ssh would have to wait after 1.0.0 is released.

@serasset just to have a clearer understanding for shaping the scp/sftp upload feature for later: the idea is to use scp/sftp to upload assets to a given server, said assets will be publicly available for download through other means such an https?
The reason for asking is that currently uploaders expose both upload and download urls. In the case of of scp/sftp JReleaser would still need a download url of some form, hopefully without requiring access credentials.

Related https://gitlab.com/gitlab-org/gitlab/-/issues/20061

Well, in fact, until then I had a scpexe:// url for my distributionManagement>repository in maven and maven deploy was simply deploying there (using wagon-ssh extension) and the artifacts where available at a public URL.
In maven, the upload URL was specified in delivery management and the download url in the repository section. They are only linked as they have the same id, but it is not necessary for maven.
As I tried to use JReleaser I wanted to use gitlab for releases as I switch to it for my repository (I was previously on bitbucket which does not offer such a releasing capacity). But the upload limit  on gitlab prevent me to do this.
I have no access to a S3 or artifactory instance and do not really want to setup my apache for uploading through http(s).
So I thought about :

using scp (or sftp), just like I did before for the artifacts distribution
using a repo for git pages (I have one at bitbucket, but could be github or gitlab)

While trying to setup this configuration, It was quite tedious to configure the scpexe credentials on CICD image, so I gave up and finally, I mirrored my repo on github and I release on github.
Now I'm not really sure scp is a good choice as managing the credentials in a CICD workflow is tedious and may be a too high security risk (you really need to configure a ssh key allowing only scp access and it is not an easy click and copy process). Maybe git pages would be better fitted for this as it looks like what is done for homebrew rule creation for instance.

Thanks. I did see the github mirror of your project (congrats on the release btw). Been working on download/upload capabilities using http/scp/sftp and happy to share it's almost there. the last stumbling block is setting up the SSH keys ate the right location which could be done like it is for PGP keys in the signing block.

2 people from GitLab have suggested using the generic packagers option. This requires a bit of work and constitutes a big change for the current state of the project (so close to v1.0.0) which means we'll punt it after v1.0.0.
Generic packages currently require a version number that follows semver. JReleaser supports 5 different versioning schemes which may or may not be compatible with semver depending on the chosen format. We already have two options in place (jpackage.applicationPackage.appVersion and chocolatey.packageVersion) that check if the chosen version number is valid (which happens to be something very close to semver).
The bigger change is making use of the REST API to upload binaries to a Generic package.
I know it's not exactly what you wanted to hear but the fact that there are "workarounds" (use any of the 3 uploaders currently supported || use GitHub or Gitea) does not block the next big release.

Closing in favor of #822
Alternative is to upload binaries to another location (JFrog Artifactory, AWS S3) or host binaries on GitHub/Codeberg


docs: create SECURITY.md

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


reopening PR to add consistency check for inputs passed to the ROM

Pull Request Description
What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)
This is addressing issue #1027. Right now, a more informative error will be raised. Another suggestion would be to make the method evaluate() smart enough to ignore additional inputs passed to the ROM if any.
What are the significant changes in functionality due to this change request?
The error message created if the inputs in a DataObject are different than the inputs expected by the ROM will be more informative.

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[ ] 1. Review all computer code.
[ ] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
[ ] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[ ] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
[ ] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in  XML block, the node <internalParallel> to True.
[ ] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
[ ] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
[ ] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
[ ] 9. If any test used as a basis for documentation examples (currently found in raven/tests/framework/user_guide and raven/docs/workshop) have been changed, the associated documentation must be reviewed and assured the text matches the example.

It looks like we previously have been operating more as you suggested as the "better option", where we've been filtering out only the variables we need, given the way tests are failing.
It may be profitable to reconsider this clarifying error and where it is raised.

It looks like that we have to rework this. Right?

I think so.


disable chrome BrowserWindow caching

opening issue at the request of @zcbenz
my issue is that when using win.loadUrl chrome aggressively caches page contents, and I cant get it to load newer versions without reloading with devtools open and the 'disable cache while devtools is open' checked
to reproduce, clone this repo: https://github.com/maxogden/atom-shell-cache-bug
and then run:
npm install
npm start

you should see HELLOOOO in the app
now, quit the atom shell app, edit client/index.html in that repo to say something other than HELLOOOO and then run npm start again
it should still show  HELLOOOO
also, @zcbenz and I looked briefly through http://peter.sh/experiments/chromium-command-line-switches/ but did not find one that seemed to do the trick. i also tried this but it doesn't fix the issue:
    win.loadUrl("http://localhost:8765")
    win.webContents.on('did-finish-load', function() {
      console.log('reloading')
      win.reloadIgnoringCache()
    })

Hi zcbenz!
What is the location (on windows) that atom-shell uses for caching?
I need to solve the cache problem badly! Is there plans to support the chromium command line switches for disaling cache completely?
Thanks!

The cache is stored at require('remote').require('app').getDataPath(), and unfortunately there is no command line switch in Chromium to disable cache.

From next release you can use --disable-http-cache switch command line switch to disable disk cache.

hi @zcbenz, it still caches the webview content. I have added the --disable-http-cache  switch in app, but still it caches the webview..


How create global notify function with md-snackbar

I would like to create a global function or method that would take one parameter - the text. And shows a snackbar with this text

You'll need to create this logic in the root instance of your Vue Application. And you should trigger some action (in vuex for example) to change the text and toggle the visibility of your snackbar


Getting 'Missing region in config' when running gulp

Hi, I'm getting 'Missing region in config' when running gulp. The region is properly configured in my ~/.aws/config file but it seems that is not being picked up.
I had to explicitly set the region before creating any AWS resource to make it work.

This is actually a problem with the AWS SDK and not this repo itself.
You'll have to add this to your shell's init script (~/.bash_profile, ~/.zshrc):
For example: export AWS_REGION="us-east-1"
Keep in mind that this is only necessary locally and in the Lambda environment, it will get the region from process.env.AWS_REGION


How do you compile the tex file?

Hey, I like the template and would like to use it but I have no idea how to compile it.

The most straight foward way is using the template on Overleaf: https://www.overleaf.com/latex/templates/jakes-resume/syzfjbzwjncs
This removes the headache of installing the compiler and packages.

Haha, that is most definitely true.


[Feature] Add Nvcomp python bindings to kvikio.

This PR adds the basic bindings for Cascaded and Lz4, and a broken Snappy binding. I need to figure out how to import nvcomp properly before this will work with kvikio.

Thanks @thomcom !  As part of this PR will you also include example notebooks and the benchmark plots you built earlier. The plots don't need to be committed in the PR but uploaded in the PR comments

Thanks @quasiben I've added the files, I'll move them around later.

This is basically ready for review. Tomorrow I will add the notebook, benchmarks, and get the style updated correctly.

Do we need to do something to make sure nvCOMP is available on CI?

I don't believe so as nvcomp tooling is tested as part of cuDF/libcuDF
@thomcom looks like there are some style check failures

I don't believe so as nvcomp tooling is tested as part of cuDF/libcuDF

How is the nvCOMP binding code here tested?

Thanks. Was more asking are we running those on gpuCI here? Relatedly are there any gpuCI changes we need to include here to run the tests.

Oh of course, I'll be looking into that today if I can affect it.

These CI failures are mysterious to me.

Maybe try merging in branch-22.04 or pushing another commit? Seems like CI failed to checkout the PR. So would just give it another try. If it still fails, we can ask for help :)

Think this CI error is capturing the issue that I'm wondering about
      building 'kvikio._lib.nvcomp' extension
      /usr/local/gcc9/bin/gcc -Wsign-compare -DNDEBUG -fwrapv -O3 -Wall -fPIC -O3 -I/workspace/.conda-bld/kvikio_1647375755170/work/cpp/include -I/workspace/.conda-bld/kvikio_1647375755170/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/include -I/usr/local/cuda/include -I/workspace/.conda-bld/kvikio_1647375755170/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/include/python3.8 -c kvikio/_lib/nvcomp.cpp -o build/temp.linux-x86_64-3.8/kvikio/_lib/nvcomp.o -std=c++17
      kvikio/_lib/nvcomp.cpp:776:10: fatal error: nvcomp.h: No such file or directory
        776 | #include "nvcomp.h"
            |          ^~~~~~~~~~
      compilation terminated.

Do we need to be cloning or downloading nvCOMP somewhere on CI first?

Thinking we need to add this code and then call it somewhere like this.

I think we're already depending on cudf in this, are we not? There's a piece in setup.py about loading the headers from NVCOMP_HOME if they aren't installed. I will look again.

I don't think so. This is lower level than cuDF.
Thanks Thomson! 😄

Glad to hear you discussed this.
Yeah was wondering about this. RMM recently added support for scikit-build ( https://github.com/rapidsai/rmm/pull/976 ), which might be one approach to this problem.
Another might be an (lib)nvcomp package, which we depend on.

I think Github is lying. I definitely beat @jakirkham to posting that :upside_down_face:

Interesting what are the main challenges to implementing a scikit-build based process?
Yeah think I agree that a Conda package would be more medium term. So makes sense to table that for now.
Also curious how either of these compare to what you (Thomson) and Mads discussed earlier

@jakirkham my biggest concerns with scikit-build are the unknowns. It is still very much a beta project, and I found a number of issues while implementing it for RMM. While I would be hopeful that we have ironed out enough of them, RMM is header-only so the need to (statically) link to an additional project could potentially uncover additional complications or limitations that we would need to address. I am happy to give this a shot, and if it turns out to "just work" then that would be fantastic. I just don't want that adoption to become a blocker for this release since we're so close.

Sure and to be clear I'm not pushing that or any of the other approaches. Am just trying to determine, which of these is most viable in the near term so we can proceed on next steps here.

I took a stab at trying to answer that question in #32. I can't seem to get builds of kvikio (C++ or Python) to run correctly (on my machine or a DGX), so I'm going to let CI tell us how viable scikit-build is going to be in the short term.

So... I guess it just worked :smiley: :tada: I guess we handled enough issues with the RMM conversion to make this relatively painless. So maybe we just roll with scikit-build (assuming everyone involved is on board).

What is the current status on you work @vyasr ? Do you have ideas for resolving the building of nvcomp, making its header available, and adding it to the Cython static library? Thanks!

To my great despair I found out that Nvcomp released v2.2 on Feb 7. They modified the API that is used in the nvcomp bindings thoroughly and a major refactor is required. I'm planning on scrambling to push this refactor as fast and hard as I can.
Should we drop the idea of having this ready for 22.04 (since we're in burndown) or should we release with v2.1?

Should we drop the idea of having this ready for 22.04 (since we're in burndown) or should we release with v2.1?

Do you know what version of nvComp cuDF is using for 22.04 and 22.06 ?  My guess is that we should follow cuDF

What is the current status on your work @vyasr ? Do you have ideas for resolving the building of nvcomp, making its header available, and adding it to the Cython static library? Thanks!

I have ideas, yes. I think we would basically do what @jakirkham suggested here:

Thinking we need to add this code and then call it somewhere like this.

but now that we're using scikit-build we could restrict that line of code to just the Python kvikio package rather than the libkvikio build. I'll test that out once #32 is completed (I'll ping you before I push any changes to this branch though).

When you have a moment, can you please fix the merge conflicts here @thomcom? 🙂

:+1: Today I'm updating the notebook once more and moving it to where it belongs, then producing benchmarks and sharing them here, then hoping this can fly like a phoenix.

This is done unless there are more changes via review! Thanks!

@madsbk I added the docs that I forgot this morning. Thanks! I also dropped BatchedSnappy which has some issues I won't be working on presently.

@thomcom my last request here would be to move pynvcomp.pxd to something like libnvcomp.pxd, then cimport it explicitly in pynvcomp.pyx. In Cython pxd and pyx files with the same name are interpreted in a very specific way, and in this case that relationship isn't accurate. In particular, there's no pure Cython in pynvcomp.pyx that you are trying to make cimportable in other Cython files, you're exclusively creating objects that are visible in pure Python. pynvcomp.pxd is not defining an interface for pynvcomp.pyx, it's importing the "symbols" from the C++ library. As such, it's misleading to have the names aligned.

Hey @vyasr, your comment is interesting to me. My approach with .pxd and .pyx naming has always been that the .pxd file defines the interface to the existing C/C++ code, and the pyx implements the python bindings for that interface. In this case, the pure cython in pynvcomp.pyx is only the typecastings that convert between python objects and c pointers. It's not intended for cimport into other cython files, only to expose the C++ interface to python. Would you put the C++ interface and the python visible bindings into the .pyx file and not have a pxd file at all? I see that in _lib here there's a kvikio_cxx_api.pxd and a libkvikio.pyx, how about I rename into that pattern?

You might be interested in looking at the first section on this page. Specifically, it's valuable to distinguish between use-cases 1 and 3. Use-case 1 is really what the pxd file in this PR is doing (exposing C++ code). In RAPIDS we rarely write pure Cython, it's almost always just a wrapper around C++, so we don't run into use-case 3 as much, but there are some good examples in cudf like column.pxd and copying.pxd.
Regarding the naming, I suggested the libFoo.pxd for C++ bindings and pyFoo.pyx or just Foo.pyx for the Cython since I think that's the common convention that I have observed across most other Cython packages that I've worked with. I'm fine with your proposal too since it maintains internal consistency in kvikio. Feel free to check with other devs too in case they express different preferences from mine.

I see that in _lib here there's a kvikio_cxx_api.pxd and a libkvikio.pyx, how about I rename into that pattern?

I think this is a good idea. Then, if we want to change to another naming scheme like @vyasr suggest, we can change the name of both libraries at the same time.

All requests have been answered.

Thanks @thomcom, it is merged.


Problem when using subliminal in api mode

When using subliminal in api mode (without an 'install' of subliminal) I have problems with the providers.
I can register the providers as entry point myself, but they are always empty because the import of subliminal in my application always triggers the following code from 'api.py' before I can register them myself:
provider_manager = ExtensionManager('subliminal.providers')

The provider manager uses a cache, so they remain empty.
As workaround, I now pop the 'subliminal.providers' from the ExtensionManager CACHE so it will be read again.
What's the proper way to re-initialize the provider_manager?

See https://github.com/Diaoul/subliminal/tree/no_setup
I accept PRs to maintain this patch and extend the logic to the ProviderPool manager.

Thanks for your modification, but I would rather not have a separate branch ;)
I just succeeded in reloading the provider_manager by:

register the 'subliminal.providers' entry point myself at runtime
re-initializing the provider.manager in subliminal.api

    distribution = pkg_resources.Distribution(location=os.path.dirname(current_path),
                                              project_name='fake_entry_points', version='1.0.0')
    # Add entry points here if needed
    # Add subliminal entry points (since subliminal 1.0)
    entry_points = {
        'subliminal.providers': [
            'addic7ed = subliminal.providers.addic7ed:Addic7edProvider',
            'opensubtitles = subliminal.providers.opensubtitles:OpenSubtitlesProvider',
            'podnapisi = subliminal.providers.podnapisi:PodnapisiProvider',
            'thesubdb = subliminal.providers.thesubdb:TheSubDBProvider',
            'tvsubtitles = subliminal.providers.tvsubtitles:TVsubtitlesProvider'
        ],
        'babelfish.language_converters': [
            'addic7ed = subliminal.converters.addic7ed:Addic7edConverter',
            'tvsubtitles = subliminal.converters.tvsubtitles:TVsubtitlesConverter'
        ]
    }
    distribution._ep_map = pkg_resources.EntryPoint.parse_map(entry_points, distribution)
    pkg_resources.working_set.add(distribution)

    # Clear subliminal providers from provider manager entry point cache because they were empty at startup
    # Entry point is set by our own fake_entry_points, so they need to be reloaded
    provider_manager.ENTRY_POINT_CACHE.pop('subliminal.providers')
    provider_manager.__init__('subliminal.providers')

Perhaps you can provide a helper method in the api to re-initialize the provider_manager in a similar way?

I believe if you do all that before importing subliminal you shouldn't need any hack.

You're right. I played a bit with my imports and now I manage to create the entry points at runtime before the provider_manager is loaded!
The clearing is not longer needed. :+1:

Glad you found a proper way to make it work :)

PS: I just saw that the readme.rst for the save_subtitles method is not up to date ;)
save them to disk, next to the video
save_subtitles(subtitles)

Can you make a PR with the appropriate change?


fix: add and remove color button not aligned

Fixes Issue
**My PR closes #469 **
👨💻 Changes proposed(What did you do ?)
added align-items: center in style.css on line 424.
✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title and description of the PR are clear and explain the approach.

Note to reviewers

📷 Screenshots

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


Small bug in TensorBoard: Visualizing Learning tutorial [FIXED, pending website pushes]

There is a small bug in the code on the site: https://www.tensorflow.org/versions/r0.7/how_tos/summaries_and_tensorboard/index.html
b = tf.Variable(tf.zeros([10], name='bias'))
should be:
b = tf.Variable(tf.zeros([10]), name='bias')
The consequence is that when you view the graph, the 'bias' variable has no useful label and is simply Variable.

This was fixed earlier today in: https://github.com/tensorflow/tensorflow/commit/5df9ff89a58a17e6efca7f186b57f22430130768
We'll probably amend our docs to fix this eventually.  Going to leave this open until then.

Are the docs fixed? I can take this one to begin with.

This is fixed for docs versions later than 0.7. Do we have a policy on backporting documentation fixes to older versions?
@martinwicke want to chime in?

FWIW I would be fine just closing this because I don't think many people will find the 0.7 docs.

@robwell (or anyone else), if you are motivated enough to send a fixing PR against 0.7 we'll happily accept it. But I will close this issue, it's not enough of a problem since it's fixed in 0.8 and master.


List all Data Packages by User

We need to list all data packages of user. The data packages can be from the publisher of which the user is member or owner.
Api: /api/package/<name>?type=user
Request body:
{
   "page": 1,
   "page_size": 10
}

Response body
{
   "page": 1,
   "page_size": 10,
   "total_data": 55,
   "data": []
}

Closing will be handled by https://github.com/frictionlessdata/dpr-api/issues/200


Add attribute to show who last un/set alarm (SPC)

Description:
Adds a changed_by attribute to the SPC alarm control panel component. This allows showing the name of the SPC alarm system user who last issued an arm/disarm command and also allows for automations to depend on this value. Similar to the attribute with the same name in the Verisure alarm component.
Please note that this PR also includes removal of processing for the 'OQ' message which is not needed.
Pull request in home-assistant.github.io: home-assistant/home-assistant.github.io#3650
Checklist:
If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/spc.py#L166-L191
Please remove ensure_feature and use loop.create_task(). All the function need not be coroutine, you can return a coroutine without yield. Add also the async_ präfix. Maybe you can export that into a own library and hold the part on Home-Assistant smart.

Yes, extracting the API related parts to a separate library and possibly also reworking the async bits is on the to-do list but perhaps that should be a separate PR? This one is a rather small improvement of functionality that has existed in HA for a few releases already.

Tests are failing.

Yes, I suspect there might be a race condition somewhere. Will look into it.

Coverage decreased (-0.2%) to 93.898%

Well I think test coverage for these components is quite OK as it is... of course more tests could be added but I don't think it would add so much value.

Test coverage drop was related to other changes. this is fine. Thanks!


road-map-date

updated the updated date.

@stack72 should approve this very minor change just in case it conflicts with his update


godot 4.0 using alpha branch hello world

Client worked with changes made to alpha thanks!

im using alpha 10.3 and i have same error


Build an extra static boringssl for NuRaft

This will help with building NuRaft with boringssl.
For asio I used --with-openssl=/home/feid/dev/ats_h3_tools/boringssl
For NuRaft I used
-DASIO_INCLUDE_DIR=/home/feid/dev/asio-1.29/include
-DOPENSSL_LIBRARY_PATH=/home/feid/dev/ats_h3_tools/boringssl/lib64
-DOPENSSL_INCLUDE_PATH=/home/feid/dev/ats_h3_tools/boringssl/include
Then ats can be built with StekShare plugin enabled without issues.

@bneradt This fixes one of the quiche autests.
This needs to be apply to our CI images so we get this working now.
Thanks.

Cherry-picked to v10.0.x
This was needed to cleanly pick #11270


Elcomsoft.PhoneBreaker version 10.12.38835.6971

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Automatic Validation failed with:
Manifest: The manifest file path must match PackageIdentifier and PackageVersion properties from manifest. actual
'manifests\e\ElcomsoftCo\ElcomsoftPhoneBreaker\10.12.38835.6971', expected
'manifests\e\ElcomsoftCo\PhoneBreaker\10.12.38835.6971'

The path has an extra Elcomsoft before PhoneBreaker.

Anyone using a git client that supports moving multiple items, or renaming a folder

Hello @upintheairsheep,
I am sorry to report that the Sha256 Hash does not match the installer. This may be caused by using a vanity URL rather than a URL directly to the binary.
Please check the HASH and submit again. Sorry for the inconvenience.
Template: msftbot/validationError/installers/hashMismatch

It most likely updated while it was “gone”

This package has the wrong EXE in the shortcut. It has EPB.exe but running this does nothing, even directly. But EPBMain.exe runs the program.

This package has the wrong EXE in the shortcut. It has EPB.exe but running this does nothing, even directly. But EPBMain.exe runs the program.

Editing the shortcut fixes the issue, allowing the shortcut to launch the application. I'm not sure how to fix this, as I believe it's part of the installer.

This package has the wrong EXE in the shortcut. It has EPB.exe but running this does nothing, even directly. But EPBMain.exe runs the program.

Editing the shortcut fixes the issue, allowing the shortcut to launch the application. I'm not sure how to resolve this, as I believe it's part of the installer.

It’s most likely an elcomsoft problem

Is there another version of this package where the shortcut has been fixed? It's a poor user experience to have a shortcut that doesn't do anything after installing software, and no way to run it.

Contact elcomsoft
On Friday, May 19, 2023, Stephen Gillie @.***> wrote:

Is there another version of this package where the shortcut has been
fixed? It's a poor user experience to have a shortcut that doesn't do
anything after installing software, and no way to run it.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/winget-pkgs/pull/102152#issuecomment-1555023860,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKNKRXGF7KN56F7OKWTAQILXG6WTFANCNFSM6AAAAAAWZUAT3Y
.
You are receiving this because you were mentioned.Message ID:
@.***>

Is there another version of this package where the shortcut has been fixed? It's a poor user experience to have a shortcut that doesn't do anything after installing software, and no way to run it.

This is an Elcomsoft problem, contact them to report the bug, merge this into there, and this is a dynamicly updating link.

Is there another version of this package where the shortcut has been fixed? It's a poor user experience to have a shortcut that doesn't do anything after installing software, and no way to run it.

This is an Elcomsoft problem, contact them to report the bug, merge this into there, and this is a dynamicly updating link.

Follow up.

This appears to be the expected behavior for this package.


Unable to locate phpcs

VSCode Version: 1.17.2
OS Version: Window 10

Steps to Reproduce:

when I write a php tag and copy and php code into php file

Reproduces without extensions: Yes/No  Yes

Duplicate of ikappas/vscode-phpcs/issues/8. You have the vscode-phpcs extension installed which requires to have phpcs globally installed on your system. (Set the executable to the PATH variable). So he can't find the executable and throws this error.


Add download functionality

Initial commit for adding in-app download functionality. @joelekstrom there's a few settings that should be user-configurable (selecting download-directory and auto-opening extensions). Could you take a look at how to integrate those in the settings window? I've added a FIXME statement in places to check.

@joelekstrom got it to work - see changes in the PR. Can you help check and also take a look at ideas for integrating this in the settings. Or do we not need to make any of this configurable (download location, auto-open)?

@mdbraber I think as a first step it's good enough without settings - of course a setting would be nice but that could be another PR 👍

LGTM

@joelekstrom I've created a final update to include download related settings and to use a FileDownloadManager to detect already running downloaded processes. Should be the last update before we can hopefully finish this. I might have don't some illogical things as I'm still rather inexperienced coding in Obj-C :-) Thanks for your feedback so far.

@mdbraber Great job! I've looked through the code and will come back with some suggestions, but all in all this seems like a real nice solution to me.
But one confusion - when I'm trying this locally I can clearly see the .fmdownload file, but I can't see any progress indicator on it in finder/dock or on my downloads folder. Do you see the actual progress locally?

Hmm, no that still doesn't help for me. I will investigate a bit more when I get the time. I also think we can use the NSURLSessionDownloadTask to slim it down a bit, still just creating a tempt file at target location. I will experiment a bit and see if I can get it to work!

I've considered using NSURLSessionDownloadTask as it would be the likely designated class for this. My consideration is that a temporary file is created in a cache location and the progress of the download (e.g. byte size of the file) can't be seen if we create an empty .fmdownload file. I opted for streaming of the output, rather than 0-byte temp file.

@joelekstrom here's a small POC I've created to test the progress indicator:
#import <Foundation/Foundation.h>

int main(int argc, char** argv) {
	NSString *_downloadingPath = @"/Users/mdbraber/Downloads/test.pdf";
	NSDictionary *info = [NSDictionary dictionaryWithObjectsAndKeys:
		@"NSProgressFileOperationKindDownloading", @"NSProgressFileOperationKindKey",
		[NSURL fileURLWithPath:_downloadingPath], @"NSProgressFileURLKey",
		nil];
	NSProgress *progress = [[NSProgress alloc] initWithParent:nil userInfo:info];
	self.progress = progress;
	[self.progress setKind:@"NSProgressKindFile"];
	[self.progress setPausable:NO];
	[self.progress setCancellable:YES];
    [self.progress setTotalUnitCount:10];
	int self.count = 0;
	double delayInSeconds = 2.0;
	NSLog(@"Starting timer");
	[self performSelector:@selector(updateCount:) afterDelay:2.0];
}

void updateCount(count) {
	[self.progress setCurrentCount:self.count];
}

Interesting that I don't see it, must be something with my setup 🤔 will try a bit more. You can get progress from URLSessionDownloadTask using URLSessionDownloadDelegate: https://developer.apple.com/documentation/foundation/urlsessiondownloaddelegate/1409408-urlsession
I was thinking there's still a tmp .fmdownload file created where we post the progress, but then you don't need to handle the download buffering etc

Sorry @joelekstrom I accidentally posted the wrong POC - I've edited the comment above with the right POC and instructions (copied from https://gist.github.com/torarnv/0a4b6b4509bad7682b2dc0c561ec4437). Wondering if this POC would work for you. Main things I found that prevent the progress bar from showing are (1) fileURL paths with symlinked locations (2) forgetting to use publish
Regarding NSURLSessionDownloadTask I agree it means not having to handle download buffering, but the file size wouldn't be reflected in the Finder. I've take a cue from Safari to see how they do it, and there the file is streamed directly to a download location (actually it's a bit different, the Safari .download file is actually a package file which holds the temporary file) Of course I think it's fine if you would prefer to switch to NSURLSessionDownloadTask but I think personally I prefer this approach.

All right, sounds good let's keep this approach! 👍 I'll try to test the POC if I get some time layer today

Interestingly, I do see the progress bar when running the POC, but not in Fastmate. Gonna have to try a bit more 🤔

So strange, I got it to work once in Fastmate but then it stopped. I think something is acting up. Will debug a bit more tomorrow.
Btw, you can set up the progress object a bit more nicely this way:
    self.progress = [NSProgress progressWithTotalUnitCount:_totalBytes];
    self.progress.fileOperationKind = NSProgressFileOperationKindDownloading;
    self.progress.fileURL = [[NSURL fileURLWithPath:self.downloadingPath] URLByResolvingSymlinksInPath];
    self.progress.kind = NSProgressKindFile;
    self.progress.pausable = NO;
    self.progress.cancellable = YES;

Thanks for the update @joelekstrom, update the initialization. Any update on getting the progress bar to work on your side?

Been a bit busy lately so haven't spent much time on it! However, if we can't get this to work perfectly that's fine. We could also ship it as a preference disabled by default to allow people to beta test it. Let people opt in to this new download experience and see how it goes. It might just be my computer acting up 😄

We could make the whole download  functionality optional, I would than suggest switching it on by default qn making it possible to revert to the current behavior

Yep, that sounds good to me! Would you like to add a preference for it? (Sorry for being so slow btw)

@joelekstrom yes, I'll add a preference for the download behavior in general, so people can toggle it on/off. No problem about the response time, I can relate :-) Would be nice to ship a version in the coming days / weeks, especially to get some feedback from people what can be improved.

I agree! Would also be nice to ship the other patches you’ve made

Hi @mdbraber! I feel like it's time we get this out. I rebased the branch added some minor changes including a setting to fall back to legacy downloads. Any thoughts on those? Otherwise I'll merge it and ship a new update soon. Thanks again for all the work on this!

@joelekstrom sorry for the delayed reply I was away for a bit. Thanks for merging this and adding a setting to revert to the legacy behavior. I think only one small detail to check now with users is if we can get the progress bar to show. It still shows on my install, but I've heard from at least one other user it (also, like with you) doesn't show up. Any ideas how we could get some user feedback on that?

@mdbraber no problem! It does show on my new computer so it may have been something with my setup on the previous one


Improving Camera Conversion

Issue/Motivation
I noticed that in certain situations, even though my camera was setup as pitchRange = .free, it kept switching to .freeWithinRange(0, 59.9999999). When back converting the MLNMapView camera we were missing determining the pitch range based on our enum: the camera would always be set to .freeWithinRange instead of trying to go for .free or .fixed too if applicable.
Tasklist

[N/A] Include tests (if applicable) and examples (new or edits)
[N/A] If there are any visual changes as a result, include before/after screenshots and/or videos
[N/A] Add #fixes with the issue number that this PR addresses
[N/A] Update any documentation for affected APIs
[N/A] Update the CHANGELOG

/Users/runner/work/swiftui-dsl/swiftui-dsl/Sources/MapLibreSwiftUI/MapViewCoordinator.swift:336:1: error: (andOperator) Prefer comma over && in if, guard or while conditions.
Really, thats a thing now? 😅 Not a fan, && is clearly readable for me, "," is not 🤷♂.

Really, thats a thing now? 😅 Not a fan, && is clearly readable for me, "," is not 🤷♂.

wat... Ok, I think I'd use this style specifically if I have a multi-condition if statement that also includes let bindings, because that's how the syntax works for those. But otherwise yeah this is less clear for me too. I'll disable that check.


Couple Tweaks Needed

Just downloaded this for the first time today, so my b if its just an issue on my end/using an unsupported diffusers version.
In Models/Attention.py & Unet.py...
from diffusers.modeling_utils should now be:
from diffusers.models.modeling_utils
In c_vid2vid's sd.py, to mirror the referenced sd.py file (at least in the latest comfyui):
Lines 2&3 should be:
from comfy import model_management, model_patcher
from comfy.sd import load_model_weights, VAE, CLIP, load_lora_for_models
–
Might be wrong about the latter tweak, but I received an error if I went a sub-ref below to get "ModelPatcher, model_lora_keys_unet, model_lora_keys_clip" from sd.py

Also needed to fix models/attention.py, line 14 to:
diffusers.models.attention import Attention as CrossAttention, FeedForward, AdaLayerNorm


Rebase isUpdated on equality check?

Overview
Currently, all the metadata editors relies on an additional isUpdated flag also it might be replaced by shallow descriptions comparison (?)

DONE in #162


Fix DependencyRegistrationException

I have moved this fix into this PR: https://github.com/Sage/sinject/pull/5


Debugger crash runtime when model consists of a big List String

What was first experienced as a problem with decoding a list of many string items with Json.Decode turned out to be isolated to elm-reactor running in debug mode. The problem is triggered when the model contains a List String with about 15000 elements.
@unsoundscapes in the Elm Slack suggested this was related to the debugger wanting to traverse the model in order to display it.
You can find code that reproduces this error here:
https://github.com/johannesl/elm-issue1521
Google Chrome on macOS (55.0.2883.95) is effected, and throws a "Maximum call stack size exceeded" error. The problem triggers in neither Safari nor Firefox on macOS.

I suspect this is a duplicate of #80.

Tracking in #98. Thanks for the report!


support multi-queues ?

now only one queue to save tasks, if multi-queue to save tasks, will more efficient ?

https://github.com/lix19937/multithreaded_programming/blob/main/26_threadpool/src/thread_pool.hpp


Pydantic models dumped to dict with deprecated method dict with pydantic v2

This was fixed in #49 but one call to dict was missed

Nice catch, thanks!


Cannot verify verge-blockchain.com's certificate when downloading

When compiling, there is option to download blockchain. Need to supply the certificate chain to correct this (minor) error, please see:
Do you wish to download the complete VERGE Blockchain (y/n)?y
rm: cannot remove 'go.sh-Verge-Blockchain.zip': No such file or directory
--2018-01-03 19:25:53--  https://verge-blockchain.com/blockchain/go.sh-Verge-Blockchain.zip
Resolving verge-blockchain.com (verge-blockchain.com)... <IP_ADDRESS>, 2a01:4f8:10b:406a::2
Connecting to verge-blockchain.com (verge-blockchain.com)|<IP_ADDRESS>|:443... connected.
WARNING: cannot verify verge-blockchain.com's certificate, issued by ‘CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US’:
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length:<PHONE_NUMBER> (1,3G) [application/zip]
Not sure if this belongs here. Host lacks proper certificate chain, adding it should do the trick when using wget. If added wget can be executed without --no-check-certificate flag.
https://www.ssllabs.com/ssltest/analyze.html?d=verge-blockchain.com&s=<IP_ADDRESS>&hideResults=on
steps

add proper chain https://verge-blockchain.com/
this will make --no-certificate flag obsolete

have relayed relevant information over to the admin of verge-blockchain.info and verge-blockchain.com to look into issue.
doing some house cleaning and will close this issue here since it's not exactly QT related.


Refresh Token missing

When I request my "access token", by passing my "auth token", I was expecting to also receive a "refresh token", however it's missing.
Can someone explain why it's missing, and how I get hold of a refresh token?
This is what's returned...
access_token:
"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiIwMWZkNWVkMi1mNzI0LTRhNzMtODUyNC01OWJhMDZiZjRlNTgiLCJzdWIiOjEsImV4cCI6MTUyMDAxMTA2NiwiaWF0IjoxNTIwMDA3NDY2fQ.2Yk9qz5smUWqNMlSwCvPXjHZzknun9wcP62fytVR1lof4tEjuYYKeEP_zb_A1dDYLpKhnBLFoW5Ama9pOrJkz77fJ_gVnemdR9LrrKof9xIAF9JemuYMroCjIawDWHIbiv9tmu4lAO-DIsA6EQnCYNXZX89ViZkuiMWEN1ER_6SPGofS-Ze07zDEFzQgBLrE5s3v-EGaz6CBczHPyCuFchZ7xnoZ_J3YnuP00PyDYwY5vv9xgPIsz_k0V9Hz3VVlcZu-2YjGxiLrRFgx2lhZP5jlKEI_Qs0_xMtyOE6972ck72CFEnqIxpiPUFRlN9s8f7jRBAnLkkFYh_e4H8FNeA"
expires_in:3600
token_type:"Bearer"

What type of grant are you using?


pkg/asset: kube-{flannel,proxy}, calico-node: Tolerate all taints

kube-{flannel,proxy} need to run on every node, no matter what
the taints is. Without kube-{flannel,proxy} the node is never
ready.
I'm not sure if the node will work without calico-node, but it should
run on every node anyway.
Fix #699

coreosbot test this please

I just pushed this to production and it is working as expected.

Does this need to be added to the calico daemonset too?

Does this need to be added to the calico daemonset too?

Definitely..
Done and rebased.

Are we waiting on anything, or can we merge this?

You could also add a toleration for your custom taint to the flannel or calico DaemonSet in the usual way. It feels a tad presumptuous to tolerate all possible taints, we've been wrong about broad assertions like that in the past. On the other hand I don't have a case in mind, since a NotReady node isn't so useful (maybe in debugging an issue, but its a stretch).

To be fair these are system level networking nodes. Is there a reason they shouldn't be running on a node?

Like I said, I don't have a concrete one in mind for flannel and calico. Some folks do run without kube-proxy for whatever reason (I'm not one of them).
The question we need to answer is not "is there a reason not to run them", its "is it ok to always run them" (onus lies on the broader assertion) because if it turns out there is some case, a user has to go find all the taints in use and edit components to re-add the explicit tolerations.

You could also add a toleration for your custom taint to the flannel or calico DaemonSet in the usual way.

because if it turns out there is some case, a user has to go find all the taints in use and edit components to re-add the explicit tolerations.

I think that most people, still want to run kube-{flannel,proxy}, calico-node after adding a taint. Not running kube-{flannel,proxy}, calico-node seems a bit like a corner case, and if people do that they is probably smart enough to tweak the tolerations them-self.

Any update on this?

Hmm.. Could someone decide if this is go or no-go? :)

I'm not opposed, but I'd feel better if upstream Calico manifests switched or indicated this was pending. They're ultimately the main upstream for these manifests.

coreosbot run e2e

Rebased..

Upstream PR: https://github.com/projectcalico/calico/pull/1443


Does function throw? Ability to tell if a function could throw by looking at its signature.

🔍 Search Terms
Throw
Function signature
✅ Viability Checklist

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion
When looking at functions in typescript. We can see what arguments it takes and their types as well as the type it will return. But what we don't know is if anywhere down the line of this function is if it uses the throw keyword. If it does and we don't know about it then this can very much change the behaviour of our resumed predictable code.
My suggestion is that when looking at the function signature, it indicates in some method where it could throw or not. This flag would bubble up to any function that uses the function that could throw unless wrapped inside a try catch block.
This should also apply to functions like fetch, which doesn't actually have the throw keyword in it, but can still throw.
📃 Motivating Example
This feature can help developers know and plan where and when to wrap stuff in try catch blocks to catch this undefined behaviour that somewhere further down the code breaks for an unexpected reason. The throw keyword is not a mistake of JavaScript. It is a feature and we should have better features to know when it has been used.
💻 Use Cases

What do you want to use this for?
To know if a function may break and stop it from breaking the rest of my code, without adding unnecessary try catch blocks.
What shortcomings exist with current approaches?
We currently have no way to know if a function may throw, with the exception of documentation or looking at source code.
What workarounds are you using in the meantime?
Assuming these are fine until they break with a new unknown error.

Duplicate of https://github.com/microsoft/TypeScript/issues/23060 / https://github.com/microsoft/TypeScript/issues/13219 and others.


Labels migration

Update plugin to handle only osc labels
To remove all aws related API
UT + E2E TEST

Few notes:

Typo in last commit message
go.mod update can be put in a separate commit
conflict in go.sum to fix

Except that, LGTM


Iphone 6s: A Problem Occurred with this Webpage so it was Reloaded

Hi ,
Using this library for cropping and zoom the image with ionic and angularJS(1.4).  Facing issue in iphone6 plus .Showing the captured image ionic modal. When i rotgate device landScape and protrate continioulsy application getting reloaded in WEB. Can you please help on this.

Same problem form me on iphone7 plus on safari, have found a way to fix?

Hi Aleolly,
We haven't found any fix yet.

@kamakshi417 and @Aleolly have try with v1.2.1 and let us know it it's resolves the problem with ionic


Don't attempt to re-import broken files if they didn't change

Fixes #62271
_reimport_file() had code that was able to handle invalid imports (it even explicitly writes valid=false to file), but that code was unused, because the method failed early in case of error. This PR moves the fail line to the bottom of the method, so user is notified about failed import, but the .import file and modified times are written normally.
Moreover, I removed code that attempts to re-import when .import file is invalid. This is no longer necessary after #84974. Reimport will be automatically attempted if .import file has changed, so no reason to force it when the file will stay invalid anyway (see above case).

Thanks!

Does this also fix #90980?

Does this also fix #90980?

Tested, seems so.


AdaLNSelfAttn.forward 请问下这句目的是什么

表示下面的b.__call__会调用AdaLNSelfAttn.forward，不写作注释应该是为了方便跳转

hi @yanghu819 that is a useless code only for IDE's usage-finding as said by @inmny


Color contrast function [NDS-20]

Our books currently use Bootstrap's color-yiq function to set automatic text color on background-color bleeds, but we cannot currently support that in the design system. Let's do some research on this and implement something that can be used to accomplish it.
References

Here's how Bootstrap is handling this now: https://github.com/twbs/bootstrap/blob/2cbb0a941c0a33fc11518061cfd6fad5c0d1c3c0/scss/_functions.scss#L95-L145.
Could we implement the newer APCA algorithm, which is forthcoming in WCAG 3.0? If we can, what would be the risk of using this now?

NDS-20

This will probably be helpful in #154 and #153.

Issue linked to JIRA Story: [NDS-20]

Hi  @sh0ji
Just wanted to mention that if there are concerns regarding backwards compatibility to WCAG 2 contrast, we've released Bridge-PCA, which is backwards compatible to WCAG 2, but using APCA technology. There's a simple demonstrator and how-to at https://www.myndex.com/BPCA/
And both BridgePCA and APCA W3 are available on NPM.
 npm i bridge-pca

 npm i apca-w3

Questions and comments welcome in the discussion forum: https://github.com/Myndex/SAPC-APCA/discussions

Very cool, thanks for sharing, @Myndex! And thanks for everything you're doing to improve the way we evaluate color. We'll look into using these libraries.


DFD1

You will need to model and analyze your use cases and requirements properly using the appropriate models with the appropriate level of granularity.  For the projects, at a minimum,  you will need to ensure that you have the appropriate sequence diagrams (supporting your use cases), as well as DFDs (you will need to have at least a level 0 and level 1).

Broken down into smaller issues:
-find processes within the system
-find information flows within the system
-find the system boundary
-find data store accesses during data flows


A128CBC-HS256

Hi,
in the draft in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-14 i can read this:

Replaced "A128CBC+HS256" and "A256CBC+HS512" with "A128CBC-HS256" and "A256CBC-HS512".  The new algorithms perform the same cryptographic computations as [I-D.mcgrew-aead-aes-cbc-hmac-sha2], but with the Initialization Vector and Authentication Tag values remaining separate from the Ciphertext value in the output representation.  Also deleted the header parameters "epu"(encryption PartyUInfo) and "epv" (encryption PartyVInfo), since they are no longer used.

Will you update the gem to work properly with this change in the draft? If you know what changes should be made in JSON::JWE perhaps i'll be able to code them.
An example of the problem i have. Trying to decode with A128CBC+HS256 i have this error when calling JSON::JWE#decrypt! method:
OpenSSL::Cipher::CipherError Exception: wrong final block length
Thanks.

@bensw I believe I'm running into the same thing with a MSFT JWE.
Been trying to decrypt but not having success.
Should I still try and use older version of this gem and decompress as mentioned above?

I was facing a similar problem, using version 0.5.6 of the gem, my code is:
def inflate_jwe(jwe_string)
  zstream = Zlib::Inflate.new(-15)
  buf = zstream.inflate(jwe_string)
  zstream.finish
  zstream.close

  buf
end

def decrypt!(data)
  jwe = JSON::JWT.decode(data, default_private_key).to_s
  inflate_jwe(jwe)
end

output = UrlSafeBase64.decode64(decrypt!(data))

The part that I was missing was to decode64 the data after it was inflated.


Spring Cloud Common Warn on lbRestClientPostProcessor

Spring Cloud Version: 2023.0.1
Spring Boot Version: 3.2.4
Log
2024-03-31 13:02:07.127 [main] WARN org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker.postProcessAfterInitialization - Bean 'org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig' of type [org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [lbRestClientPostProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.
2024-03-31 13:02:07.131 [main] WARN  org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker.postProcessAfterInitialization - Bean 'deferringLoadBalancerInterceptor' of type [org.springframework.cloud.client.loadbalancer.DeferringLoadBalancerInterceptor] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [lbRestClientPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.

+1 I am also getting this warning

It's by design. Boot informs DeferringLoadBalancerInterceptor will not be eligible for auto-proxying, and we don't want it to be.


Off-Canvas variables are not customizable

We're currently working on our first site with Foundation 6 and we've found a quite serious bug. None of the scss variables used by off-canvas are marked as "!default", so none of them are overridable with  custom settings.
best regards,
Andreas

I can't use scss off-canvas settings neither.

Fixed! We'll have a patch out today to address it.


fix: added missing trailing slash for edu redirects

Fix AEXG-3024
Test URLs:

Before:

https://main--express-website--adobe.hlx.page/express/
https://main--express-website--adobe.hlx.page/ca_fr/express/
https://main--express-website--adobe.hlx.page/eg_ar/express/
https://main--express-website--adobe.hlx.page/express/edu/?locale=ja-JP
https://main--express-website--adobe.hlx.page/express/edu/?locale=blah

After:

https://fix-client-redirect--express-website--adobe.hlx.page/express/
https://fix-client-redirect--express-website--adobe.hlx.page/ca_fr/express/
https://fix-client-redirect--express-website--adobe.hlx.page/eg_ar/express/
https://fix-client-redirect--express-website--adobe.hlx.page/edu/?locale=ja-JP
https://fix-client-redirect--express-website--adobe.hlx.page/edu/?locale=blah

@sirgil2009 after more tests, we still observe some inconsistencies:
https://fix-client-redirect--express-website--adobe.hlx.page/edu/?locale=it-IT
should redirect to
https://www.adobe.com/it/education/express/
but redirects to
https://www.adobe.com/tw/education/express/?locale=it-IT
Also, http://localhost:3000/404.html turns into an endless loop, because the code sets userLocale to 404.html at line 64.

Looks good overall.
There are a few opportunities to improve the maintainability and optimize the code:
* maybe combining the 2 first `if`/`else if` clauses since they share a lot of code

* aligning variable names so they are more verbose and descriptive

* suffix takes 2 `f`

@ramboz  Ok, Awesome!  I'll refactor and make these improvements including extracting the js code into
a separate file, so I can write unit test for it.  I am creating a new ticket for that.

Hello @sirgil2009 @ramboz
I think we're getting close! I did some further tests that still don't pass:

https://fix-client-redirect--express-website--adobe.hlx.live/testing/edu?locale=jcy-GB
https://fix-client-redirect--express-website--adobe.hlx.live/testing/edu?locale=es-ES
https://fix-client-redirect--express-website--adobe.hlx.live/testing/edu?locale=da-DK
https://fix-client-redirect--express-website--adobe.hlx.live/testing/edu?locale=pt-BR
https://fix-client-redirect--express-website--adobe.hlx.live/testing/edu?locale=pt-BR

This is not working - there's a typo in euducation.

https://fix-client-redirect--express-website--adobe.hlx.live/edu?locale=pt-BR

This special cases where express is not in the URL are not working. Here it redirects to https://www.adobe.com/education/express/?locale=jcy-GB and should redirect to https://www.adobe.com/br/education/.

LGTM now @sirgil2009 !


Enable gitlab ci for release-5.29

Summary

Ticket Link

Hi @metanerd, may I ask if you are also going to release 5.31 within the next days?

Hi @metanerd, may I ask if you are also going to release 5.31 within the next days?

Hi @sbley! I am planning to, but I cannot promise anything.

Hi @sbley! I am planning to, but I cannot promise anything.

@sbley I released 5.31.

@sbley I released 5.31.

Thank was quick. Thank you!

Thank was quick. Thank you!

HI @metanerd I noticed the 5.31 release does not contain type definitions and js files but only the src folder itself. Is that on purpose or was there a problem with publishing? Should I file an issue for that?

HI @metanerd I noticed the 5.31 release does not contain type definitions and js files but only the src folder itself. Is that on purpose or was there a problem with publishing? Should I file an issue for that?

I am going to investigate. Thank you for your report!

I am going to investigate. Thank you for your report!

Hi @metanerd, additionally it seems release 5.31.0 does not contain the fix for issue #1290 or did I just missed something?

Hi @metanerd, additionally it seems release 5.31.0 does not contain the fix for issue #1290 or did I just missed something?


Briefing note for OIPC

Description:
This was requested  during April 20 meeting in order to brief the OIPC Commissionaire
DOD

[ ] Draft briefing note about this initiative for OIPC (deadline: mid-May so they have it before Fees review starts in June)
[ ] Review by ED
[ ] Review by ADM?

Update Apr 28:  Matt met with Rihanna. Standing down for a moment, we may pivot to sending a letter to the commissioner instead


OptimizeHuffmanForRle

When compiling zopfli for Win64 using MINGW-W64, I got a warning about invalid typecasting and a malloc value being out of potential range.  I fixed this issue with a patch I'm proving.  Please feel free to use it.  The thing is that in Win64, malloc takes an 8-byte unsigned value while in Win32, it takes a 4-byte value
.  Int is always 4 bytes even in  Win64.  That effects OptimizeHuffmanForRle mostly.
win32-fixes.patch.txt

I don't think so.   When I compiled for Win32 using GCC, I got this:
42%] Building C object CMakeFiles/zopflilib_obj.dir/src/zopfli/lz77.c.obj
D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.c: In function 'OptimizeHuffmanForRle':
D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.c:452:16: warning: argument 1 value '4294967292' exceeds maximum object size<PHONE_NUMBER> [-Walloc-size-larger-than=]
good_for_rle = (int*)malloc((unsigned)length * sizeof(int));
In file included from D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/lz77.h:28:0,
              from D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.h:28,
              from D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.c:20:
D:/msys64/mingw32/i686-w64-mingw32/include/stdlib.h:503:17: note: in a call to allocation function 'malloc' declared here
void *__cdecl malloc(size_t _Size);
              ^~~~~~
[ 47%] Building C object CMakeFiles/zopflilib_obj.dir/src/zopfli/util.c.obj
[ 52%] Building C object CMakeFiles/zopflilib_obj.dir/src/zopfli/zlib_container.c.obj
[ 57%] Building C object CMakeFiles/zopflilib_obj.dir/src/zopfli/zopfli_lib.c.obj
[ 57%] Built target zopflilib_obj

I'm rather surprised by this considering I was compiling a version for the 32-bit version of Windows.  My build process builds for both using two separate toolchains.  The thing you have to keep in mind is that in Windows 64 bit, the pointer is 8-bytes wide as well as size_t and ptrdiff_t but the "int" is always 4-bytes wide.

Isn't the problem rather that in the loop right above length is counted down until it reaches -1. The compiler cannot see if the loop will always break early, so it warns that multiplying -1 with sizeof(int) is unlikely to be meaningful?

I still have to run a test, but I have to ask this question, why does the procedure have this declaration?
void OptimizeHuffmanForRle(int length, size_t* counts)
The problem in Windows 64-bit is that an int can only accommodate 2GB's of data (2 to 31's power).  If you use a size_t for the length parameter, you could get up 2 to the 63rd power as a maximum data size.

I would think the correct type might be a ssize_t (signed size_t).

Well, anyway, I did test your proposed loop with the compiler and it doesn't give warnings.  But I still don't like that procedure because of that concern I mentioned.   I'm going to look at something else.

Please forgive any confusion on my part since I don't know the algorithm.  But the reason I was thinking some things needed to be 8 bytes was that I know  that an "int" is 8-bytes wide on many 64-bit systems (not 4-bytes like Windows).

8 bytes are definitely not needed in this algorithm, a cast to fix the warning is good here.
Does changing
good_for_rle = (int*)malloc((unsigned)length * sizeof(int));
into
good_for_rle = (int*)malloc((unsigned)(length * sizeof(int)));
or
good_for_rle = (int*)malloc((size_t)(length * sizeof(int)));
fix the warning in both win64 and win32 for you?
Thanks

good_for_rle = (int*)malloc((unsigned)(length * sizeof(int)));
Gives warning for Win32 but not Win64.
D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.c: In function 'OptimizeHuffmanForRle':
D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.c:452:16: warning: argument 1 value '4294967292' exceeds maximum object size<PHONE_NUMBER> [-Walloc-size-larger-than=]
good_for_rle = (int*)malloc((unsigned)(length * sizeof(int)));
In file included from D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/lz77.h:28:0,
              from D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.h:28,
              from D:/msys64/home/jpmugaas/exp/mingw-w64-zopfli/src/zopfli-zopfli-1.0.2/src/zopfli/deflate.c:20:
D:/msys64/mingw32/i686-w64-mingw32/include/stdlib.h:503:17: note: in a call to allocation function 'malloc' declared here
void *__cdecl malloc(size_t _Size);
              ^~~~~~
===
good_for_rle = (int*)malloc((size_t)(length * sizeof(int)));

Gives warning in Win64 and Win32:

zopfli/src/zopfli/deflate.c:452:24: warning: argument 1 range [18446744065119617024,<PHONE_NUMBER>3709551612] exceeds maximum object size<PHONE_NUMBER>854775807 [-Walloc-size-larger-than=]
good_for_rle = (int*)malloc((size_t)(length * sizeof(int)));
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from zopfli/src/zopfli/lz77.h:28,
              from zopfli/src/zopfli/deflate.h:28,
              from zopfli/src/zopfli/deflate.c:20:
D:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:503:17: note: in a call to allocation function 'malloc' declared here
void *__cdecl malloc(size_t _Size);
              ^~~~~~

Win32 warning:
zopfli/src/zopfli/deflate.c: In function 'OptimizeHuffmanForRle':
zopfli/src/zopfli/deflate.c:452:16: warning: argument 1 value '4294967292' exceeds maximum object size<PHONE_NUMBER> [-Walloc-size-larger-than=]
good_for_rle = (int*)malloc((size_t)(length * sizeof(int)));
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from zopfli/src/zopfli/lz77.h:28:0,
              from zopfli/src/zopfli/deflate.h:28,
              from zopfli/src/zopfli/deflate.c:20:
D:/msys64/mingw32/i686-w64-mingw32/include/stdlib.h:503:17: note: in a call to allocation function 'malloc' declared here
void *__cdecl malloc(size_t _Size);

At this point, I'm thinking that maybe the problem isn't with the unsigned parameter to malloc but what malloc may be returning which is a pointer.

Here's the definition for Microsoft's website:

void *malloc(
size_t size
);

I got a ping from a comment on the related commit, which made me take another look at this. I realized OptimizeHuffmanForRle is only ever called with fixed values as length of either ZOPFLI_NUM_LL (288) or ZOPFLI_NUM_D (32). So we could use a fixed size array like in TryOptimizeHuffmanForRle to avoid the malloc in the first place.
I have a branch with the change here. Happy to make a PR if there is any interest, but it's only 3 lines changed.


Added fix for adding annotations that are not strings in ontodoc

Furthermore, reenabled test for ontodoc. This is still aminimal test, but I think can be gradually expanded.
Lastly - because a new altLabel was added in the testontology, it was reveiled that the same entity is returned twice in get_by_label_all in test_prefix. Issue #511 was made bacause of this.
Description:

Type of change:

[x] Bug fix.
[ ] New feature.
[ ] Documentation update.

Checklist:

This checklist can be used as a help for the reviewer.

[ ] Is the code easy to read and understand?
[ ] Are comments for humans to read, not computers to disregard?
[ ] Does a new feature has an accompanying new test (in the CI or unit testing schemes)?
[ ] Has the documentation been updated as necessary?
[ ] Does this close the issue?
[ ] Is the change limited to the issue?
[ ] Are errors handled for all outcomes?
[ ] Does the new feature provide new restrictions on dependencies, and if so is this documented?

Comments:

Codecov Report

Merging #512 (09eafd3) into master (10b6c2d) will increase coverage by 2.38%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #512      +/-   ##
==========================================
+ Coverage   63.08%   65.46%   +2.38%
==========================================
  Files          16       16
  Lines        3080     3081       +1
==========================================
+ Hits         1943     2017      +74
+ Misses       1137     1064      -73

Impacted Files
Coverage Δ

ontopy/ontodoc.py
66.33% <100.00%> (+14.63%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Feature request: Gentoo ebuild

I am building a gentoo based htpc and this is just what I was looking for, simple and powerfull.
Could you add a gentoo ebuild to it?
Many thanks

I have no experience with Gentoo. Can you explain what ebuild is and what would be required to support it?

Thank you for the reply.
A ebuild is to gentoo what a PKGBUILD is to arch (maybe a bit more complex).... perhaps if you can post flex-launcher PKGBUILD I might be able to (with my limited skills) to write a ebuild from it and post it here.

The PKGBUILD is available here. This is actually a configuration file for a PKGBUILD and CMake will fill in the appropriate variables at compile time (e.g. @VARIABLE@).
This should be able to get you started for how a build script for Flex Launcher needs to work.

I don't plan to support ebuilds within this repository. However, if another user has created an ebuild elsewhere, I may link to it in the installation section. Create a PR in that case.


Issue after initial sync

I tried this out and so far I've loved it. Yesterday it seemed to be doing fine. However today I noticed when I created a new repo, it synced the initial repo but stopped syncing after that point. I have the delay variable set to 1800 seconds,
DELAY=1800

However, after the initial commit, it hasn't pushed anymore updates to the repo from Github to Gitea.
I've attempted to restart the docker container, and even shut it off and re-launch it after verifying the docker-compose.yml was alright.
Any ideas of where to look? Hopefully it's just a small thing, because I love the idea of this app, and it's vital to the setup I have. Am I losing my mind or is it supposed to keep mirroring each time the delay expires? I swear I saw it doing multiple commits.
Edit: Something I noticed. If I go into the repo settings, I noticed that each one of the repos that were mirrored ended up having the mirror settings set. However, for the timer, it's set to 8h0m0s. Whereas my pull time in the docker yml is set to 30 minutes.
Is the pull time for docker only how often it looks for new repos? And then 8 hours to sync for each one? Or is this a bug?

Hey 👋
First of all sorry for the late response. I am pretty busy with private manners right now.
This tool is only a small script to automatically create repositories on a specific Gitea instance which are mirrored from GitHub.
It’s literally just a replacement to the click through procedure to setup that manually on Gitea.
The synchronization method is completely implemented and handled by Gitea, you may have a look at their docs:
https://docs.gitea.com/usage/repo-mirror
The script will run with a fixed delay, i.e. 8 hours. After 8 hours it may create new repository mirrors for added repositories on your GitHub user or organization.
The synchronization between Gitea and GitHub is completely handled by Gitea and will absolutely work without the script running.
If you have an error on your mirror refresh I would recommend to analyse the logs of your Gitea instance and probably open an issue on the Gitea repo.
Sorry again for the late response. I hope my answer was helpful to you.
Best,
Dennis

In order to change the default mirror time (8 hours), it could be possible to introduce a configuration for a pull interval which could be overwritten according to your needs.
How soon do you need the mirror update?

Hey,
It's ok, I sort of figured Gitea was the one handling the duration when I saw that they were all set to 8 hours.
It would be a cool feature, but the time-frame is really up to you. I just went in and adjusted the time down on a few repos because I update them so frequently. But there's really no rush on it, whenever you have time it would be a nice addition.


Enhance positions table to deal with closed / settled positions and markets

Blocked by https://github.com/vegaprotocol/frontend-monorepo/issues/3114
Story
As a trader on console
I want to have my now dead positions on closed markets made less prevelant - or gone entirely - from the positions view
So that I dont take a few seconds each time i load the positions tab to identify those dead positions and either filter them out or sort them to the bottom
Acceptance Criteria

[ ] I can easily identify my open positions
[ ] I can easily identify my closed positions on live markets
[ ] I can avoid being distracted or annoyed by settled positions on settled markets which have very little value to me now
[ ] I can probably see the realised P&L on those settled positions SOMEWHERE (but not necessarily here)

Tasks

[ ] UX (if needed)
[ ] Design (if needed)
[ ] Team and stakeholder review
[ ] Specs reviewed and created or adjusted
[ ] Implementation
[ ] Testing (unit and/or e2e)
[ ] Code review
[ ] QA review

Sketch
Current view ... seems to be alphabetical so settled positions are scattered among open ones ... which is suboptimal.

Additional details / background info
I could imagine various solutions to this of increasing difficulty

Just get rid of settled positions ... potentially not ideal at the moment as not sure we have anywhere else to view this P&L?
Just sort by last updated to the top, by definition the closed ones will sink to the bottom if you're still actively trading
Sort by market status first and then alphabetical so settled ones are at the bottom but alphabetical ordering is maintained
Create some other place for reviewing historic P&L

@JonRay15 We are proposing using the pane context menu to allow you to show/hide closed positions.

Ok that probably works