The maven pattern for sbt plugins is invalid based on the spec

I've been in touch with the Bintray team because of https://github.com/sbt/sbt-bintray/pull/125.
It happens that the reason why sbt bintray does not accept the fix in the aforementioned PR is because sbt has been using an incorrect Maven pattern for sbt plugins. This is the reply I got from the Bintray team:

Going off of the Maven Design Documentation, Bintray expects the following Maven layout format:
[orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev])(-[classifier]).[ext]. Note the “module” field appears twice.

Our pattern is the following: https://github.com/sbt/librarymanagement/blob/53c80f076a5e9ab469037f352a4d68173140e216/core/src/main/scala/sbt/librarymanagement/ResolverExtra.scala#L357-L358, which is obviously wrong (there's a concept of module and a concept of artifact, where both should be the same).
The reason why this works for Sonatype is because they have a permissive layout for projects whose publishing rules do not abide by the spec. Bintray doesn't, and that's why no one has succeeded to publish sbt plugins to Bintray maven repositories.
This is a major issue that IMO should be sorted out as soon as possible. The only way I see to solve this problem is to add another pattern to sbt and make it use alongside the wrong pattern (we cannot remove it, too many projects depend on it).

This is the Maven Design Specification.

This is, to some degree an intentional design because Maven doesn't have the notion of extra attribute that we can use as resolution axis (as in same version, but different X, where X is scalaVersion etc). In practice it should not be a problem because the majority of the plugin ecosystem is on Ivy layout that we host.

In practice it should not be a problem because the majority of the plugin ecosystem is on Ivy layout that we host.

This is not true. Lots of plugins publish to Sonatype, and there's no reason why sbt should force its ecosystem to live in a platform (Bintray) where at the moment you use too many resources you have to pay, and that has given us several problems in the past (remember when people were not able to fetch sbt two months ago during one week?).

This is, to some degree an intentional design because Maven doesn't have the notion of extra attribute that we can use as resolution axis

To me, it seems this problem could have been solved if we had use the following pattern:
"[organisation]/[module](_[scalaVersion])(_[sbtVersion])/[revision]/[artifact](_[scalaVersion])(_[sbtVersion])-[revision](-[classifier]).[ext]".

Does that translate to correct ivy.xml?
What would the name say in https://oss.sonatype.org/content/repositories/public/com/lucidchart/sbt-scalafmt_2.12_1.0/1.10/sbt-scalafmt-1.10.pom?

What would the name say in https://oss.sonatype.org/content/repositories/public/com/lucidchart/sbt-scalafmt_2.12_1.0/1.10/sbt-scalafmt-1.10.pom?

Name would be still the same. My proposal is strictly compliant with the Maven design specification, so I expect it to be correct for pom files.

I don't think we can fix this till sbt 2.x because the layout is built into https://github.com/sbt/sbt/blob/1.x/launch/src/main/input_resources/sbt/sbt.boot.properties and
  def mavenStyleBasePattern =
    "[organisation]/[module](_[scalaVersion])(_[sbtVersion])/[revision]/[artifact]-[revision](-[classifier]).[ext]"

so all plugins will need to support the old layout forever, which Bintray is going to reject (?).
Just to support resolution from Bintray's maven repo we'd have to add a new resolver, which I don't think we should require all users to do since they already have Maven Central and sbt community repo.

which Bintray is going to reject (?).

I'm trying to convince them to be permissive, but this is sad. It'd be reasonable for them to dismiss it.

I don't think we can fix this till sbt 2.x because the layout is built into https://github.com/sbt/sbt/blob/1.x/launch/src/main/input_resources/sbt/sbt.boot.properties

We can add a maven style pattern that we use to resolve sbt plugins (in sbt-bintray, we will modify how plugins are published to maven repo by using the newly added pattern). The price to pay is that when something does not resolve with mavenStylePattern, it will need to try correctMavenStyleSbtPattern in case the plugin uses the new, correct pattern.

Just to support resolution from Bintray's maven repo we'd have to add a new resolver, which I don't think we should require all users to do since they already have Maven Central and sbt community repo.

FTR, I'm not saying we should add a new resolver. In fact, no new resolver is needed. The value of publishing sbt plugins to maven repos is that you can sync them to Central with Bintray.

FTR, I'm not saying we should add a new resolver. In fact, no new resolver is needed. The value of publishing sbt plugins to maven repos is that you can sync them to Central with Bintray.

That is such a corner case usage since most ppl either directly publish to Sonatype, or use Ivy layout if it's Bintray.

That is such a corner case usage since most ppl either directly publish to Sonatype, or use Ivy layout if it's Bintray.

If people do not want to publish to Central, they add their custom resolver.
If they do want to publish to Central, then there is no issue.
I don't agree this is a corner case usage. Lots of people have tried in the past, and the reason this hasn't worked was because of this bug. That's why they gave up and they now use sbt-sonatype, which has disadvantages (e.g. slow to publish, no custom user organization, etc). We've had instances of people failing to publish their plugins in the last few weeks. The fact that this doesn't work forces organizations to have a unique ivy repository only for sbt artifacts (which is the case for the Center and other organizations which only use Maven).

Let's summarize:

Central - no problem
Ivy layout on personal Bintray or sbt community repo - no problem
Companies using Sonatype or Artifactory internally - problem?
Maven layout on personal or corporate Bintray - add custom repo via sbt-bintray?

Companies using Sonatype or Artifactory internally - problem?

No, no problem.

Maven layout on personal or corporate Bintray - add custom repo via sbt-bintray?

Problem. My explanation for adding the custom repo via sbt-bintray only works when we publish sbt plugins under a valid maven pattern, which is currently not the case.

Right. So publishing should be customized also with sbt-bintray for plugins with a big warning sign saying that all users would also need sbt-bintray (and thus not recommended for OSS) due to #3410.

So publishing should be customized also with sbt-bintray for plugins with a big warning sign saying that all users would also need sbt-bintray (and thus not recommended for OSS) due to #3410.

I don't understand this solution. The solution I'm proposing is that we add a correct maven pattern. We use the newly added maven pattern for resolving sbt plugins, so that in case resolution fails the last option tries to resolve with the right pattern. These are the only two things that sbt needs to change.
In sbt-bintray land, just as sbt-sonatype and other publishing plugins, we make use of the recently added pattern for publishing plugins to Bintray Maven repositories. And then sbt should resolve them correctly.

If you're suggesting we add a second Maven Central resolver, I am against it.
For all other personal or corporate Bintray usage, it doesn't need change in sbt.

If you're suggesting we add a second Maven Central resolver, I am against it.

If you're against it, it would be good to know why. This is a bug in sbt.

For all other personal or corporate Bintray usage, it doesn't need change in sbt.

It does need change in sbt. The used maven pattern is invalid. It wouldn't be necessary if a good maven pattern had been used in the past. But this is not the case.

I agree it's an unfortunate behavior on sbt's part, but the true fix requires sbt 2.x, and as far as the majority of the users are concerned, it's been working ok for 9 years.
Each resolver that gets added by default adds performance overhead to all of the users, in conjunction with dynamic revisions like -SNAPSHOT, so I want to be cautious about it. The only users who are affected is those who want to first publish to Bintray in Maven layout, and then sync to Central. For that small % of users, I am ok to say that sbt won't support it out of the box, and let plugins workaround it.

it's been working ok for 9 years.

Yes, because people have worked around this issue for 9 years.

Each resolver that gets added by default adds performance overhead to all of the users, in conjunction with dynamic revisions like -SNAPSHOT, so I want to be cautious about it.

It's possible to add a resolver without affecting performance. Here's how I would do it:

Only add the resolver for sbt plugins or meta projects.
Only add the resolver at the end of the resolvers list, so that it's only tried out if the previous resolutions fail.

Re snapshot resolution, those are the semantics. Adding one more resolver to the process is not going to make it unbearably slow. It already is.

The only users who are affected is those who want to first publish to Bintray in Maven layout, and then sync to Central. For that small % of users, I am ok to say that sbt won't support it out of the box, and let plugins workaround it.

This is sad. Especially if we have a solution for this problem.

@jvican We in China ,the GFW sometime block the sbt repo,but not the maven center,so if sbt-plugins could publish to maven center,then wow,really help.
Some guys have to buy a vpn to use sbt:)

+1 for @jvican proposal to add an additional resolver since it solves a real problem and there's minimal to no impact for the user base if it would be the last one.

i have been trying to publish an sbt plugin inhouse, in my case to artifactory, with support for snapshots. it has been 2 days running around in circles.
so when i pick a maven style repository it doesn't work because of the invalid maven layout. artifactory rejects it. there is a workaround, which is to select "Suppress POM Consistency Checks" in artifactory, but this seems undesired. also i am afraid this will lead to issues when i synchronize from artifactory to bintray (using a distribution repository, a feature of artifactory), given that bintray will supposedly reject the invalid layout.
when i pick ivy style (or sbt style) repository just for sbt plugins it doesnt work because sbt publishes invalid snapshots according to the ivy spec (it should have a timestamp instead of -SNAPSHOT). artifactory is convinced a snapshot is a release and rejects it to the snapshot repository. i could select "Handle Releases" and also allow "Delete/Overwrite" for the snapshot ivy repository but that seems undesired and even then i doubt this will work since if artifactory doesn't recognize the artifact as a snapshot who knows if snapshot resolution will work correctly.
so being invalid for both maven and ivy style repositories gives me few good options. i could resort to a paid bintray just for my plugins to work around these issues but that seems a bit silly. also i would lose support for snapshots.
i don't understand why this is a corner case? i would have expected usage of inhouse repos like artifactory/nexus/archiva to be the most typical? to me bintray and sonatype sound kind of like corner cases.

Getting an HTTP 409 from Artifactory 5.11.1 using default maven pattern, e.g publishTo := Some("artifactory" at "https://url"). Surprising.
Artifactory logs say:
2018-08-09 00:38:27,408 [http-nio-8081-exec-18455] [WARN ] (o.a.r.ArtifactoryResponseBase:107) - Sending HTTP error code 409: The target deployment path 'com/rallyhealth/rally-sbt-plugin_2.10_0.13/0.14.1-3-636791a-SNAPSHOT/rally-sbt-plugin-0.14.1-3-636791a-SNAPSHOT.pom' does not match the POM's expected path prefix 'com/rallyhealth/rally-sbt-plugin/0.14.1-3-636791a-SNAPSHOT'. Please verify your POM content for correctness and make sure the source path is a valid Maven repository root path.
<?xml version='1.0' encoding='UTF-8'?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.rallyhealth</groupId>
    <artifactId>rally-sbt-plugin</artifactId>
    <packaging>jar</packaging>
    <description>rally-sbt-plugin</description>
    <version>0.14.1-3-636791a-SNAPSHOT</version>
    <name>rally-sbt-plugin</name>
    <organization>
        <name>com.rallyhealth</name>
    </organization>
    <properties>
        <scalaVersion>2.12</scalaVersion>
        <sbtVersion>1.0</sbtVersion>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.scala-lang</groupId>
            <artifactId>scala-library</artifactId>
            <version>2.12.6</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.scala-sbt</groupId>
            <artifactId>sbt</artifactId>
            <version>1.2.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.scalatest</groupId>
            <artifactId>scalatest_2.12</artifactId>
            <version>3.0.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

FWIW Artifactory publishing using sbt 0.13 also required "Supress POM Consistency Checks."

Today, I had to publish an SBT plugin to our Artifactory server, which has POM Consistency Checks enabled.
The trick I used was to setup a custom resolver with a pattern that removes the scala & sbt binary suffixes.
That is, something like this:
val artifactoryResolver = Resolver.url(
  "Artifactory Realm",
  url("..."))(
  Patterns("[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]") )

resolvers += artifactoryResolver

publishTo := Some(artifactoryResolver)

@NicolasRouquette Your work around for Artifactory worked for me. Thank you!
The additional thing I needed to do when loading the plugin from plugin.sbt is to not use addSbtPlugin but instead just add a dependency like so
libraryDependencies += "com.someorg" % "somemodule" % "1.0.0"

when i pick ivy style (or sbt style) repository just for sbt plugins it doesnt work because sbt publishes invalid snapshots according to the ivy spec (it should have a timestamp instead of -SNAPSHOT). artifactory is convinced a snapshot is a release and rejects it to the snapshot repository.

This is a bug in itself I'd say and should be reported, I'm looking through issues and not seeing an existing one yet. Just checked that this is happening with sbt 1.3.9, sbtPlugin := true and publishMavenStyle := false.
I'm in the same boat with @koertkuipers: a few years running now with no non-broken way to publish sbt plugins in a corporate repository.

Companies using Sonatype or Artifactory internally - problem?

No, no problem.

This actually is a problem. At least for Artifactory, it requires "Suppress POM Consistency Checks", and here is at least one way that that is a real problem: virtual repositories. If you follow sbt's (great) guide for proxy repositories, the goal is to have one maven-releases repository, and one ivy-releases (or zero, as @jvican said of Scala Center, some of us would not need one save for sbt).
The natural way to do this in Artifactory is with virtual repositories: you aggregate your internal local publishing repos with remote proxied ones into a virtual, and expose that via ~/.sbt/repositories.
Virtual repositories cannot enable "Suppress POM Consistency Checks". It is not transitive either, at least not for remote repos in a virtual. Thus, because of people publishing sbt plugins to Sonatype with sbt-sonatype, we have to do things like this for our staff to be able to resolve them:
# Omitting Ivy for brevity

[repositories]
  local
  myorg-maven-releases: https://repo.myorg.com/maven-release/

  # To resolve sbt plugins, due to https://github.com/sbt/sbt/issues/3410
  myorg-proxy-sonatype-releases: https://repo.myorg.com/oss.sonatype.org-releases/

The remote proxy listed second is redundant, it's in the first virtual. But it's there so the suppression option can be enabled on it directly. This is whack-a-mole if someone wants an sbt plugin from another third-party Maven repo. I believe we've established on this thread that minimizing resolvers is desirable.
So that's one example of "people have worked around this issue for 9 [11] years".
It seems likely that #3879 would also be solved by fixing this, since regular Scala libraries published with sbt demonstrably get a maven-metadata.xml generated by Nexus on Central. I can confirm it works in Artifactory too.
The resistance to classifying this as a bug and indicating any resolve to address such an age-old problem as this after all the progress sbt has made in recent years is indeed, as Jorge characterized it, sad.
The issue is still open though, so I'll hold out hope that the priority could change someday.

@eed3si9n Do you have an objection to the proposal in https://github.com/sbt/sbt/issues/3410#issuecomment-321023555 for how to add a new resolver for plugins only with minimal impact? If a patch were submitted, do you still feel that it must wait for sbt 2.0?

@ches Now that we're using Coursier for metabuild resolution it might be a good time to try the idea.

Now that we're telling people to use Maven Central for sbt plugins, we should really fix this for sbt 2.x.

As a postscript to the notes above:
I think that I'm bumping into this at my work - I've been trying to seed some scala there. It's been a headscratcher figuring out that it was the plugins causing the build failures.
It's mandatory for us to go through artifactory, and I do not think I will convince devops to adopt "permissive" layouts, as scala isn't a "strategy" per se for the company - I have no influence there, I am simply required to use the infrastructure. So we can use scala - but for things that don't rely on sbt plugins - which will be a barrier to adoption.
Given how tough (for me as a "non expert") it was to figure out (I may even still be wrong about this issue being the underlying cause), I would not be surprised if there are people who quietly give up on the back of this... which is a shame! I've upvoted the "fix for sbt 2.x" comment :-).

@eed3si9n to confirm what is the situation with publishing plugins to Maven repositories?
Is this is all that is needed? https://stackoverflow.com/a/25193320/2789308
In particular, should we foresee any issues publishing SBT plug-ins to Maven Artifactory repositories or internal Nexus, in Maven style?

@ScalaWilliam Back in the days I had lots of issues to publish binaries (not sbt-plugins, altough) created by SBT build to an in-house Sonatype Nexus OSS repository.
SBT itself (i.e. directive `publishMavenStyle := true') was just not enough to publish  -SNAPSHOT versions consistently.
Luckily I found out this excellent plugin: https://github.com/arktekk/sbt-aether-deploy created by a @hamnis.
Short plugins description says it all:

Deploys sbt-artifacts using Maven Artifact Provider.
The same behavior as Maven should be expected.

Would it be possible to integrate these plugins features into SBT 2.x ?
Or am I just daydreaming :innocent: @hamnis @eed3si9n ?

@ScalaWilliam Back in the days I had lots of issues to publish binaries (not sbt-plugins, altough) created by SBT build to an in-house Sonatype Nexus OSS repository.
SBT itself (i.e. directive publishMavenStyle := true) was just not enough to publish -SNAPSHOT versions consistently.
Luckily I found out this excellent plugin: https://github.com/arktekk/sbt-aether-deploy created by a @hamnis.
Short plugins description says it all:

Deploys sbt-artifacts using Maven Artifact Provider.
The same behavior as Maven should be expected.

Would it be possible to integrate these plugins features into SBT 2.x ?
Or am I just daydreaming 😇 @hamnis @eed3si9n ?

Thanks for sharing this Dejan!!
I have not had a deep look, but I want to check, to consume SBT plugins produced by this sbt-aether-deploy, do you need any special settings, in particular, the POM consistency check on Artifactory, and also anything on the consuming side?
I tried it on a corporate Artifactory Maven just now, did not work. Got a 409, it looks like this:
lazy val `sample-plugin` = project.enablePlugins(SbtPlugin).enablePlugins(AetherPlugin)
.settings(
version := ..,
useCoursier := false,
scalaVersion := "2.12.11",
pluginCrossBuild / sbtVersion := "1.5.0",
publishTo := ...,,
overridePublishSettings
)

I cannot copy paste the message as confidential; but basically it says org.eclipse.aether.deployment.DeploymentException: Failed to deploy artifacts: Could not transfer artifact ... from/to <realm> (url): status code: 409, reason phrase: Conflict (409)
Might it be due to POM consistency checks?

@eed3si9n does Sonatype OSS not do the POM consistency checks, is that the reason why people are able to publish SBT plugins to Maven Central? My original thinking was it was just a different target, but the more I dig into this the more I find ;-)

@ScalaWilliam thats right. Sonatype OSS does not match coordinates to POM. It probably should, but doesn't

@ScalaWilliam thats right. Sonatype OSS does not match coordinates to POM. It probably should, but doesn't

So, luck of the draw for SBT!
Is there a way to do 'publish' + 'addSbtPlugin' while avoiding consistency checks, even (if not recommended) at the expense of not following the SBT conventions, ie an escape hatch?

The main motivation behind this was to use Ivy's concept of extra attribute, which allows multiple sbt versions to exist under some Scala version. The idea of using Ivy layout repository never took off, so we should think about a Maven-equivalent encoding for this notion.
We could draw hint from Scala.JS since it uses suffix like _sjs1_3 - https://repo1.maven.org/maven2/com/eed3si9n/verify/verify_sjs1_3/1.0.0/
So for sbt 2.x, we could do something like _sbt2_2.13.
Similarly, those trying to use sbt plugins from an in-house Maven repositories could probably re-publish the plugins as a library with _2.12 suffix, and use libraryDependencies += ... to add them into project/plugins.sbt.
The last (and only?) time multiple releases of sbt were released under the same Scala version ABI was sbt 0.5, which used Scala 2.7.2, the same used by sbt 0.4. If Scala _3 era or _4 era significantly reduces the binary incompatibility as promised, or if we're in _2.13 for a long time due to macros etc, it's possible that this could happen again in the future.

Thanks for the information @eed3si9n. So to clarify, libraryDependencies += ... is all that is needed to replace addSbtPlugin, and nothing else? How do you "re-publish" the library with the _2.12 suffix? Is it artifactName := ...?

just wrote a blog post to explain my idea - https://eed3si9n.com/pom-consistency-for-sbt-plugins

I've spent some time today republishing plugins, it is ... gruelling... but it this workaround has been successful - which is wonderful. Thankyou for taking the time to document it! I will grovel at the feet of any plugin author who adopts it!
I am struggling, with the ScalaJS plugin though. It appears to have a transitive dependancy on another plugin (platform deps).
https://github.com/scala-js/scala-js/blob/3c58b2cb130dd1b1153ec4a772cb6cbdf3214652/project/Build.scala#L1094
I'm took a punt that that when republishing scala JS sbtPlugin (I cried when I saw the build definition!)...  changing the line to
addPomConsisntentSbtPlugin2021Draft("org.portable-scala" % "sbt-platform-deps" % "1.0.1")
And republishing that plugin too would help... but I have not been successful. Somehow, I can't get it to look for the right thing :-(. Even after the change above, error message is always
not found:
corp.com/artifactory/sbt/org/portable-scala/sbt-platform-deps_2.12_1.0/1.0.0/sbt-platform-deps-1.0.0.pom

Which we already know it won't find.
Would that be expected to work, or are there any hints on managing a transitive dependancy with this workaround?

@eed3si9n I think we should add this issue in the 2.0.0 milestone

Mill is using same pattern as Scala.js and it works reasonable well.
For:

Mill Binary platform 0.10.x
Scala Binary version 2.13.x

We add the suffix: _mill0.10_2.13 to the artifact name.
A bit inconvenient in search, but a predictable and consistent pattern.

We published the following plug-in that automatically enables publishing valid artifacts alongside invalid artifacts (reusing the same artifact ID to reduce complication). It has been tested with Sonatype/Maven Central and works just fine.
Any plug-in authors who try this out please let me know! This will enable access of your plug-in to enterprise environments with minimal changes to your release process.
You just need to add this to your project/plugins.sbt:
addSbtPlugin("com.scalawilliam.esbeetee" % "sbt-vspp" % "0.4.11")

All the detail is in the README -- https://github.com/esbeetee/sbt-vspp/ -- including explanations of the choices made.

@ScalaWilliam Your approach breaks with the assumption of almost any user/tool, that a scala artifacts ID end in the Scala target platform. IMHO, additional marker should be added as infix and also contain some prefix denoting their purpose, e.g. Scala.js used _sjs as marker infix-prefix, and Mill uses _mill as infix-prefix.

@ScalaWilliam Your approach breaks with the assumption of almost any user/tool, that a scala artifacts ID end in the Scala target platform, as it adds the sbt suffix after the Scala version (e.g. my-plugin_2.12_1.0). Also, there is no hint about the purpose.

Hi @lefou , thank you for your input! It's reusing the existing approach of SBT but includes a valid POM to the distribution of an artifactId (there are no changes to that).
I must challenge the above as it is really important to state that this does not break anything, and in fact would enable SBT artifacts to get listed on e.g. mvnrepository.com at last. We must distinguish separately consistent POM versus long term infix naming (which is currently not being done).

IMHO, additional marker should be added as infix and also contain some prefix denoting their purpose, e.g. Scala.js uses _sjs as marker infix-prefix, and Mill uses _mill as infix-prefix. That way, a sbt plugin artifact ID could look like my-plugin_sbt1.0_2.12.

Publishing an additional artifactId might add additional complications for users publishing multiple different libraries in their publishing process (have to mess around with multiple artifactId and updating the build+publish process, potentially introducing an additional uncertainty and burden on plugin authors as I want them to just plug-and-play with this -- questions like 'does this compose with publishSigned?' arise). It would mean every publish action publishes 2 libraries than just a single one (with an originally incorrect POM and a correct one). This is really a least resistance interim solution before the proper SBT 2.0 solution is implemented (as thousands of developers currently end up having to fall back on Maven or Gradle in enterprise environments and unfortunately they don't have the time to raise, let alone investigate and resolve such issues - this is from experience)
If you would be willing to work with us to validate the process for publishing any SBT plugins in this way, we can implement the code changes to accommodate for that, as ultimately we just need a working POM file (in fact we tried that approach and quickly realised it is a little more tricky, although if we can work with somebody to challenge this line of thought then that would be just as fine)
More than happy to set up a Discord audio session to discuss the topic so we could get a consensus on a fix.

@ScalaWilliam I probably mixed up the status quo artifact ID of sbt plugin and what your plugin does. I think your plug-in makes sense, as it helps now. Thanks for clarifying.
I still wonder, why this can't be implemented in sbt itself.

https://eed3si9n.com/pom-consistency-for-sbt-plugins outlines a solution that adds suffix similar to Scala.JS.
See for example, https://repo1.maven.org/maven2/com/eed3si9n/sbt-assembly_sbt1_2.12/1.2.0/.
The blog also includes implementation of addPomConsisntentSbtPlugin2021Draft that you can copy-paste to use today.

@lefou yes, it should be implemented in SBT. It just needs to be carefully tested as e.g. how to resolve and specify plugin-on-plugin dependencies.
@eed3si9n yes, this is referenced in the README of sbt-vspp. How can we get many plug-in authors to integrate the full set of changes into their CI/CD pipelines? - is the question. (e.g. composition of a dedicated env var with the sbt-release plug-in or any of the other sbt-to-sonatype release approaches) among others.

We discussed this topic at the Scala Center and would like to propose the following solution to the problem, which could already be implemented in sbt 1.x.
First, thank you @ScalaWilliam for your work on sbt-vspp and your efforts in moving the ecosystem toward a more compliant solution for publishing sbt plugins.
In short, the solution we propose consists of

publishing both valid poms and invalid poms (like what sbt-vspp does), and
changing the resolution logic to resolve the valid poms first, and fallback to the old poms in case of error.

Assuming that would be completely implemented for sbt 1.8, this means that a plugin that uses sbt 1.8 would now be published with a valid Maven pattern, fixing the problems discussed here. Also, the users of that plugin would not be required to move to sbt 1.8 because the plugin would still be published to the old coordinates as well (so, older versions of sbt would still be able to resolve the plugin artifacts).
Now, consider the case where a plugin foo depends on the plugins bar and baz, and bar also depends on baz. And, in particular, foo and bar use different versions of sbt, 1.8 and 1.7, respectively:
graph BT;
  bar --> baz;
  foo --> bar;
  foo --> baz;

In this example, assuming bar uses sbt 1.7, in its pom.xml the dependency to baz would not include the “sbt plugin suffix” to the artifact id: it would be just baz. However, if foo uses sbt 1.8, it would try to resolve baz_2.12_1.0 as a direct dependency, and also baz as a transitive dependency of bar. So, the dependency resolution logic will have to handle this and figure out that both artifacts are the same.
Now, consider the case where foo uses sbt 1.7, and bar uses sbt 1.8. In that case, the project foo would use the old resolution mechanism, so the only way for foo to figure out that both dependencies to baz are the same is to declare the dependency to baz, in the old-style pom.xml of bar using the old-name (ie, baz instead of baz_2.12_1.0).
Here is a more detailed plan on how to implement this:

publish both valid and invalid poms

the valid pom name would add the _2.12_1.0 suffix to the artifact name (e.g. sbt-scalajs_2.12_10-1.12.0), like sbt-vspp does
the invalid pom would be named like the poms we publish today, and their dependencies would contain artifacts named without the _2.12_1.0 suffix (so, the content of the invalid and valid pom files would be different)

change the resolution logic

in Coursier, change the logic for resolving sbt plugins to look for valid pom files, and to fallback to the old scheme in case of failure
also in Coursier, treat the dependencies to sbt plugins xxx_2.12_1.0 and xxx to be the same dependency (xxx_2.12_1.0)
update sbt to use that new version of Coursier

Do you see any issues with this approach?

Do you see any issues with this approach?

I think this is a missed chance of establishing a scheme which is more robust against misinterpretations. E.g. _sbt1.0_2.12 instead of _2.12_1.0. As you already plan to support some fall-back scheme why not add two fallback schemes, but use a new primary scheme which mentions sbt as platform and is consistent with e.g. Scala.js, Mill, and probably others.

The only reason is to change as few things as possible.

@lefou I think this is a missed chance of establishing a scheme which is more robust against misinterpretations.
True, but we will have another chance when simplifying things for sbt 2.0.
With the solution proposed by @julienrf, we would only publish one "package" (a Maven path), but this package would contain two pom files. This seems more robust to me because it would be easier to avoid having twice the same dependency under the same class path: the one with the old scheme and the one with the new scheme. Also, but this is a minor concern, it would be easier for tools like Scaladex to handle that two different artifacts are actually the same.
When going to sbt 2.0, we will probably want to clean this unnecessary complexity and publish only one artifact, with a better scheme.

That is absolutely wonderful to hear @julienrf, @adpi2 - definitely if fallback resolution is supported in Coursier that would make things much more smooth. This is a great interim solution before SBT 2.x solves it strategically. Super excited, and can't wait for @sjrd's Scala.js plugin to be available in enterprises.

changing the resolution logic to resolve the valid poms first, and fallback to the old poms in case of error.

Traditionally sbt has avoided dynamic resolution since it can make the build non-repeatable. See  for example snapshot dependencies and version ranges. While well intentioned, dynamic version effectively captures time into build because later on the state of The Internet can change, and thus cannot be cached stably. While "resolvers" mechanism can introduce such inconsistency, Coursier would consider it a bug if you get different artifacts from 2 different resolvers.

That is a good point. I agree that builds should be reproducible. I don't think it is effectively an issue in this case. For any given plugin version, it will either have only the old scheme, forever, or have the two schemes from the first time it is published.
If someone doesn't play by those rules and publishes the new scheme after the fact, it should still be reasonably fine because the .jar would (should) be exactly the same.
If someone really is a bad actor and intentionally publishes a different jar under the new scheme for a previously published sbt plugin, then we have a problem. But that requires intentional sabotage.

Hi @julienrf, was just wondering if there's a schedule or similar for making the necessary changes for 1.8? Eagerly awaiting especially for Scala.js to be usable :-)

Hello! We will be able to start working on it in October. Hopefully, a release will follow before the end of the year.

@julienrf fantastic to see some progress on this. As I'm not overly familiar with sbt-librarymanagement, how is it looking? LMK if need any help testing!

We indeed started working on that issue and made some significant progress.
As described in @julienrf 's comment, we want to to transition smoothly to a valid Maven pattern in sbt 1.x, by keeping the bi-directional compatibility:

In short, the solution we propose consists of

publishing both valid poms and invalid poms (like what sbt-vspp does), and
changing the resolution logic to resolve the valid poms first, and fallback to the old poms in case of error.

The Maven path would still be the same, but the artifact directory would contain two pom files, a "valid" one and a "deprecated" one:
Example:
org/scala-js/sbt-scalajs_2.12_1.0/1.13.0
├── sbt-scala-js-1.13.0.pom                     // old pom file for backward compatibility
└── sbt-scala-js_2.12_1.0-1.13.0.pom            // new valid pom file
└── sbt-scala-js_2.12_1.0-1.13.0.jar

I locally have an implementation of point 2 in Coursier: it is able to resolve valid poms and fallback to the old poms in case of errors, and it handles conflict resolution correctly.
This is what I still need to work on:

implement the same in the Ivy mode of librarymanagement
implement the Maven publication of two pom files
check that the old versions of Coursier and librarymanagement can resolve newly published artifacts
check that there are no impact on publishing to Ivy.

LMK if need any help testing!

If all goes according to plan I should have a few things ready for testing and reviewing by the end of next week.

Here are the 3 pull requests that should solve this issue:

https://github.com/sbt/sbt/pull/7096
https://github.com/coursier/coursier/pull/2633
https://github.com/sbt/librarymanagement/pull/409

Feedback is welcome.

I'm wondering why this includes a change in coursier? I can see that there are potential two different ways to resolve an plugin artifact (with the potential for inconsistencies), but I think handling this mapping in the resolver isn't correct. The resolver should follow general resolution strategies that we also expect from Maven or Ivy. In this case, we work around some dedicated use case for sbt plugins, which should also be handled in sbt and its library management (on the client-side of the coursier API). If there is a potential performance penalty, it could even help to motivate the migration to the new layout.
Also, supporting a sbt specific scheme in coursier, might make it even harder to ever get rid of it.

@lefou I'd imagine this is because of the possibility of a valid plugin depending on an invalid plugin, or similar. The old scheme will need to be removed at some point, might even be worth a community initiative to list out plugins that are not yet moved to 1.9 for publishing, and speak to their authors.

👋🏻 I'd like to chime in with a word of encouragement. The PRs submitted by @adpi2 would be a major boon for those attempting to publish/retrieve sbt plugins to/from GitHub Packages.
As part of a research project (currently private, unfortunately), I have successfully published sbt plugins to the GitHub Packages Maven repository; even SNAPSHOTs work through some mvn hackery (sbt-github-packages doesn't support SNAPSHOTs natively based on my experiments). Retrieving the sbt plugins from GitHub Packages currently requires a bit more mvn hackery due to the artifact naming scheme & mechanics of addSbtPlugin. I suspect that the proposed pom resolution changes may simplify the retrieval of sbt plugins from GitHub Packages dramatically. I'm joining the conversation so I can confirm upon release of sbt 1.9.x.
Thanks for addressing this! 🙏🏻

@andrew-selvia thank you for sharing this, I was only vaguely aware GitHub provided some artifact management support, but your use case is completely new. Scala to the 🌚 🚀 once it all starts working fully seamlessly with the Maven ecosystem !

The fix for this issue has been shipped to sbt 1.9.0-M1 and I started testing it thoroughly to check that:

sbt can publish new plugins using a valid Maven pattern
sbt can resolve old and new plugins and resolve conflicts (using Coursier or Ivy)
Maven can resolve the new plugins

For this purpose, I created all sorts of graph of dependencies in "ch.epfl.scala" % "sbt-plugin-example-diamond" between versions 0.6.0 and 0.10.0. It's a diamond graph of sbt-plugins:
               sbt-plugin-example-diamond
                       /    \
sbt-plugin-example-left    sbt-plugin-example-right
                       \    /
               sbt-plugin-example-bottom

@ScalaWilliam and others, I encourage you to try sbt 1.9.0-M1 out before we cut the final release. Only "ch.epfl.scala" % "sbt-plugin-example-diamond" % "0.10.0" has been fully migrated and you should be able to resolve it behind your security scanning system. If you can try the other versions (0.6.0, 0.7.0, 0.8.0 and 0.9.0) I would be curious to see the error reports.
This is how you should try resolving the sbt plugins:
addSbtPlugin("ch.epfl.scala" % "sbt-plugin-example-diamond" % "0.10.0")

Using libraryDependency += "ch.epfl.scala" % "sbt-plugin-example-diamond" % "0.6.0" is not correct, it will fail if the dependency has not yet been migrated.
I also tested the interaction between sbt 1.9.0-M1 and sbt-vspp and it worked surprisingly well. There are a few positive side-effects that I did not exect:

sbt 1.9.0-M1 tries to resolve the artifacts published earlier with sbt-vspp. So if I declare addSbtPlugin(""com.scalawilliam.esbeetee" % "sample-plugin" % "0.0.2"), it will download sample-plugin_2.12_1.0-0.0.2.jar.
Publishing a plugin using sbt-vspp on sbt 1.9.0-M1 (which is not recommended) still works. And sbt 1.9.0-M1 is even able to resolve the transitive dependencies and resolve the conflicts. The only glitch is that Maven will not be able to resolve the transitive dependencies. That's why people should stop using sbt-vspp. But it they don't, there won't be any bad consequences.

For testing, I published "ch.epfl.scala" % "sbt-plugin-example-diamond" % "0.11.0-SNAPSHOT"(and all its dependencies) using sbt-vspp and sbt-1.9.0-M1. You should be able to resolve it like this:
resolvers ++= Resolver.sonatypeOssRepos("snapshots")
addSbtPlugin("ch.epfl.scala" % "sbt-plugin-example-diamond" % "0.11.0-SNAPSHOT")

@sjrd when can we get Scala.js, please? :-) That will be the litmus test.

When sbt 1.9.0 is out, and around the next date for a Scala.js release. One should be coming up in about 2 weeks. We release every 2 months. A Scala.js release is 1 full day of work spread over 2-3 days, so we don't "just" do another one.

@adpi2 when would you think SBT 1.9.0 can be out? So far had been using SBT 1.9.0-M1, and no issues.
@sjrd I think we last caught up just under 3 weeks back - given the backwards/forwards compatibility of this solution @adpi2 implemented, would it not be reasonable to decouple it from the SBT 1.9.0 release? I would argue at least a Milestone release would make sense to validate that the entire Scala.js SBT stack works, before rolling out a full release anyway?

We don't publish milestones or RCs of minor or patch versions of Scala.js. And we're too conscious about compatibility to depend ourselves on a milestone version. Especially since there are at least two plugins in the chain (there's sbt-platform-deps), or 3 if we count sbt-crossproject.
Therefore, no, I'm afraid we won't publish Scala.js based on sbt 1.9.0-M1. We will wait for the final version.
We did validate that our CI passes with 1.9.0-M1, though.

@adpi2 when would you think SBT 1.9.0 can be out?

As far as I am concerned, for this issue, it can go out now. But it's for @eed3si9n to decide. It seems there are some bugs in Zinc that we may want to fix in 1.9.0.

@adpi2 I found something interesting, and this is not a regression by any means; I tried publishing to an Artifactory but it failed because of the old artifact style as Artifactory has a feature that rejects anything that does not come with a consistent POM structure. Is it possible to have an option to only publish only the consistent style artifacts, and not both? As otherwise Artifactory rejects the latter (old style artifacts), thus failing the publish action. Then I believe it will work fully for publishing. I managed to apply a filter on publishedArtifacts and it worked successfully.

@ScalaWilliam https://github.com/sbt/sbt/pull/7201 should solves the issue.
I encourage you to contribute if you find other ways to improve all of this.

@adpi2 thank you so much!!! To confirm this option worked.

This does not seem to work for me. Using 1.9.0-RC3 and publishMavenStyle := true, in a private Artifactory repo.

This does not seem to work for me. Using 1.9.0-RC3 and publishMavenStyle := true, in a private Artifactory repo.

I understand you need to add:
sbtPluginPublishLegacyMavenStyle := false

Why is that the case? I’m trying to publish to a maven repo. Isn’t that the point mentioned here?

Why is that the case? I’m trying to publish to a maven repo. Isn’t that the point mentioned here?

Since sbt 1.9, it tries to publish any plugin with the new and legacy Maven style (for backward compatibility). But the legacy Maven style is incompatible with your Artifactory configuration. So you need to disable it with:
sbtPluginPublishLegacyMavenStyle := false

Notice that you won't be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in [sbt-vspp]'https://github.com/esbeetee/sbt-vspp)).

For those who were desperately waiting for Scala.js to be released with this model, Scala.js 1.13.2 is out.

@sjrd confirmed working.
any chance for this one as well? for cross compilation.
https://github.com/portable-scala/sbt-crossproject

We now published sbt-crossproject v1.3.2 with sbt 1.9.x.
It might or might not work. The problem with sbt-crossproject is that it declares a dependency on sbt-scalajs 0.6.x, for maximum compatibility. The binary API it uses was carefully designed so that it can link with sbt-scalajs 1.x.
Depending on whether library resolution tries to actually resolve the POM of sbt-scalajs 0.6.x before noticing that it needs to be overridden by sbt-scalajs 1.x anyway, corporate artifactories may still reject or accept the scheme.
Worst case, if it doesn't work out of the box, it might be possible to explicit exclude the transitive dependency of sbt-scalajs-crossproject on sbt-scalajs.


Replace inline export default fix #51

Codecov Report

Merging #55 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #55   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          14     25   +11
  Lines          35     46   +11
=====================================
+ Hits           35     46   +11

Impacted Files
Coverage Δ

src/array/push.js
100% <100%> (ø)

src/util/using.js
100% <100%> (ø)
:arrow_up:

src/array/unshift.js
100% <100%> (ø)

src/object/set.js
100% <100%> (ø)

src/object/assign.js
100% <100%> (ø)

src/math/add.js
100% <100%> (ø)

src/object/update.js
100% <100%> (ø)
:arrow_up:

src/object/pickBy.js
100% <100%> (ø)

src/lang/toggle.js
100% <100%> (ø)
:arrow_up:

src/array/xor.js
100% <100%> (ø)

... and 16 more

Continue to review full report at Codecov.

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


Point-in-time-restore is not recreating firewall rules

Yesterday we performed a PITR on one of our Azure PostgreSQL databases. However we experienced, that the firewall rules were missing on the restored server. Please update the documentation "new server is created with the same configurations as the server it is based on" and also evaluate if this could be fixed in one of the upcoming releases.

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

ID: 61a86489-2b1d-1b42-687a-5d4323ad7306
Version Independent ID: 48c0caea-6b9a-add5-9fb5-ef995c737064
Content: Limitations in Azure Database for PostgreSQL
Content Source: articles/postgresql/concepts-limits.md
Service: postgresql
GitHub Login: @rachel-msft
Microsoft Alias: raagyema

Thank you for the feedback. The limits document (as well as the restore how-to docs) will be updated shortly (ETA: 11am PST, 7/20) with this information.
We have been reviewing this topic and evaluating the next steps. There isn't currently an ETA, however. We encourage you to add your request to our uservoice page: https://feedback.azure.com/forums/597976-azure-database-for-postgresql

#please-close


Support For New Semantic Release Version and Node 18

Hi @pmowrer
I created a new pull request.
This plugin doesn't work in last semantic release for node 18.
also i have changes on "semantic-release-monorepo" for support last version.
Please i need merge theses changes..
https://github.com/pmowrer/semantic-release-plugin-decorators/pull/31

+1 It would be great if this package moves to es modules. thank you for your work @w4rlock

I hope this gets gets noticed. This will also allow me to use semantic-release/gitlab v10

+1 I've been trying to use semantic-release in my NX workspace through TheUnderScorer/nx-semantic-release but the lack os ESM support from the plugin decorators is a blocker. I'd love to see this through and I am willing to provide help if necessary.

Not sure if this helps, but this is how we worked around the issue. I have tested with node >= 18 as well as older versions.
https://github.com/tjg184/semantic-release-plugin-decorators/tree/fix/dynamic_import


Synthface

Thank you for sharing your study, Where can we find the Synthface dataset?

Hi! Unfortunately the synthface dataset is not publicly available at the moment.

Thank you,no problem, can you at least give an example of json files to show how you give your labels/parameters of synthetic images?

You can see an example json file with metadata here.

Thank you, I have one more question, How could we calculate bone rotations using openface? Are the given gaze directions in the csv file  related to the bone rotation parameters in the json file?

Unfortunately, I have never used OpenFace's eye gaze estimation, so it's hard for me to comment on this. If OpenFace returns the gaze as angles, then it should be possible to use it to drive ConfigNet's eye gaze, however a conversion might be required, for example if the axes are oriented differently in OpenFace.

Would you clarify ConfigNet's eye gaze estimation, so I can convert it. Since Syntface is private, and not enough information about the required supervision for  the additional loss term in the first stage training, I am struggling to generate labels. Thank you.

Not sure if I understand your question. Are you asking about what format the gaze is specified in?
The gaze is specified as euler angles where:

first angle corresponds to looking up and down
second angle would correspond to the eye rolling around an axis going through the iris - it does nothing
third angle corresponds to looking left and right

You can see an example of eye gaze control in the demo. The way the angles are generated is specified in lines 96-114 in basic_ui.py.
Let me know if that helps.
Marek


Undo Last Commit

My workflow often involves committing changes to feature or bugfix branches, and it's easy to accidentally commit to the wrong branch.
It'd be nice if there was an easy command to perform the task of undoing a recent commit and unstaging those changes, all in one go.
Undo Last Commit: git reset HEAD~1

+1

For now you can use the Run command to do this.

I've just published a new version with a feature that allows users to define their own commonly used commands locally. It's an experimental feature right now and I would love if you gave it a try and provided feedback.
You can read about it here

I will be trying it, thanks a lot!

That works fantastically! Thanks again.
I updated the undo command to be safe to call multiple times (now it undoes and redoes itself infinitely):
atom.packages.onDidActivateInitialPackages (p) ->
  if gitPlus = atom.packages.getActivePackage('git-plus')?.mainModule.provideService()
    # Undo Last Commit
    # This reset targets the previous line in the git reflog, so it can be called again to undo itself.
    gitPlus.registerCommand 'atom-text-editor', 'akonwi:undo-last-commit', ->
      gitPlus.getRepo() # If there are multiple repos in the project, you will be prompted to select which to use
      .then (repo) -> gitPlus.run repo, 'reset HEAD@{1}'

Curious, why do commands require the akonwi: prefix when being registered?

The prefix can be whatever you want. It's just an identifier to keep commands unique from another package that might use the same name.

Sweet, thanks again.


usbc: add support for controlling VBUS by TCPC

This PR adds support for enabling the sinking and sourcing by TCPC functions. The example code uses the callback that must be provided by user application to enable the sourcing of VBUS, where if the project uses the TCPC, the VBUS should be controlled by it without requirement for user to provide callback where the TCPC driver is responsible for enabling the paths.

@jfischer-no @sambhurst can you take a look please?

Rebased the commits to the current main


Setup Travis CI for auto-build AppImage (portable binary packages for Linux)

Propose setup master branch to produce auto-builds using Travis CI as *.AppImage package -- universal portable package format for most of Linux distributions.

http://github.com/AppImage/AppImageKit

https://github.com/probonopd/linuxdeployqt
https://github.com/probonopd/uploadtool

Firstly, you need setup .travis.yml script in the root of master branch, for example:

https://github.com/probonopd/linuxdeployqt/blob/master/.travis.yml
https://github.com/leozide/leocad/blob/master/.travis.yml
https://github.com/Symbian9/azpainter/blob/master/.travis.yml

@probonopd, please, help @vslavik to solve this task! ;-)
P.S.: Known apps that already provide AppImage's listed on AppImageHub

https://appimage.github.io/apps

NOTE
As Poedit is very important tool for translators and program development providing latest version of it as AppImage portable package could solve "slow repository updating" issue.

https://repology.org/metapackage/poedit/versions

@probonopd, please, help @vslavik to solve this task! ;-)

Happy to help; please let me know if you are running into any issues given the description above.

Basically
https://github.com/vslavik/poedit/blob/0fe9e0d867fe532bd31e9a47b0dd179373574f91/.travis.yml#L48
would need to be replaced by something along the lines from
https://github.com/probonopd/audacity/blob/AppImage/.travis.yml, like
  - time ./configure --prefix=/usr
  - time make -j$(nproc)
  - make install DESTDIR=$(readlink -f appdir) ; find appdir/
  - wget -c -q "https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage"
  - chmod a+x linuxdeployqt*.AppImage
  - unset QTDIR; unset QT_PLUGIN_PATH ; unset LD_LIBRARY_PATH
  - export VERSION=$(git rev-parse --short HEAD) # linuxdeployqt uses this for naming the file
  - ./linuxdeployqt*.AppImage ./appdir/usr/share/applications/*.desktop -bundle-non-qt-libs

Now, due to
https://github.com/vslavik/poedit/blob/0fe9e0d867fe532bd31e9a47b0dd179373574f91/.travis.yml#L16
we need to do some extra shenanigans in order to make the AppImage compatible with somewhat more mature systems like Ubuntu 14.04.
  - # Workaround to increase compatibility with older systems; see https://github.com/darealshinji/AppImageKit-checkrt for details
  - mkdir -p appdir/usr/optional/ ; wget -c https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/exec-x86_64.so -O ./appdir/usr/optional/exec.so
  - mkdir -p appdir/usr/optional/libstdc++/ ; cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./appdir/usr/optional/libstdc++/
  - ( cd appdir ; rm AppRun ; wget -c https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/AppRun-patched-x86_64 -O AppRun ; chmod a+x AppRun)
  - ./linuxdeployqt*.AppImage --appimage-extract
  - export PATH=$(readlink -f ./squashfs-root/usr/bin):$PATH
  - ./squashfs-root/usr/bin/appimagetool -g ./appdir/ $NAME-$VERSION-x86_64.AppImage

as pull requests to .travis.yml

As I said, I don't consider Travis-dependent way of building them useful.

I can say -- AppImage is fully must-have option

Let's agree to disagree on that.


Chainlink Local and @chainlink/contracts-ccip v1.4 Bump

This PR updates the @chainlink/contracts-ccip dependency to v1.4 (affects import paths).
It also adds tests for the Example Scripts.
The tests rely on the Chainlink Local CCIP local simulator tool as a test double "fake" for live test/mainnet CCIP.

have run tests and all working.


Disable UnauthenticatedHTTP2DOSMitigation feature gate

Release note:
None because we never released a version of Pinniped which had this feature gate enabled.
NONE

I disabled this feature gate because it was causing a problem with parallel anonymous requests to the aggregated APIs. Running this reproduce.sh script shown bellow would reliably reproduce the problem with the Concierge on a kind cluster. Some requests would get 503 responses from the Kube API server with the body error trying to reach service: http2: Transport: cannot retry err [http2: Transport received Server's graceful shutdown GOAWAY] after Request.Body was written; define Request.GetBody to avoid this error. Disabling the feature gate for the Concierge server process prevents this problem.
#!/usr/bin/env bash

set -euo pipefail

# The requests only seem to error when there are parallel requests.
# When invoked with no args, this script calls itself multiple times in parallel,
# and passes a different integer argument to each invocation.
# This creates sufficient parallel requests to always see some errors.
# To only run some sequential requests, use "reproduce.sh /tmp 1" and see the output in /tmp/1.out.
if [[ $# == 0 ]]; then
  trap 'rm -rf "$temp_dir"' EXIT
  temp_dir=$(mktemp -d) || exit 1

  self=$(realpath "$0")
  set +e
  seq 1 8 | xargs -n 1 -P 0 "$self" "$temp_dir"
  if [[ $? != 0 ]]; then
    # Some invocation(s) failed, so summarize the results.
    cat "$temp_dir"/*
    exit 1
  fi
  echo "Done! No requests failed."
  exit
fi

# Get the API server"s CA bundle.
trap 'rm -f $ca_file' EXIT
ca_file=$(mktemp)
kubectl config view \
  --minify --raw \
  --output jsonpath="{.clusters[*].cluster.certificate-authority-data}" |
  base64 -d >"$ca_file"

# Get the API server's endpoint.
endpoint=$(kubectl config view --minify --output jsonpath="{.clusters[*].cluster.server}")

# Choose an output file to store all output, to avoid interleaving output with other parallel invocations.
out_file="$1/$2.out"

# Run lots of requests sequentially, until one of them returns an error.
for n in $(seq 1 200); do

  echo "Parallel process $2: Sending request $n ..." >>"$out_file"

  # Make an anonymous request (no auth header) to an aggregated API endpoint.
  # Note that --no-progress-meter requires curl 7.67 and --fail-with-body requires curl v7.76.
  # Note that this would also fail using "kubectl create --as system:anonymous --raw ..." except kubectl will
  # not show the full response from the server, so we are using curl instead. Using curl also proves
  # that the errors shown are not coming from the kubectl client code, but are indeed from the server.
  set +e
  result=$(curl --cacert /tmp/cluster-ca-cert.pem \
    --no-progress-meter --fail-with-body \
    -XPOST \
    -H 'Accept: application/json, */*' \
    -H 'Content-Type: application/json' \
    "$endpoint/apis/identity.concierge.pinniped.dev/v1alpha1/whoamirequests" \
    -d '{}' 2>>"$out_file")
  if [[ $? != 0 ]]; then
    echo "Parallel process $2: Request $n failed with response body: $result" >>"$out_file"
    exit 255
  fi
  set -e

done

echo "Parallel process $2: Made all requests without any errors." >>"$out_file"

Also note that the kind cluster that I was using was running the Kubernetes v1.27.3 node image, in case that matters.

Update: We created an issue in k/k and they are looking at possible ways to solve it already. https://github.com/kubernetes/kubernetes/issues/122308


Empty resources column when viewing a dataset through the "info" modal in the project-list page,

I browse to the Projects page, where I see a list of projects.
I click on "info" for a given project.
I see a list of datasets, in the modal that appears.
The "metadata" and "resources" columns are empty, even if I know that they have some values in the DB. The DB content looks like

"dataset_list": [
    {
      "name": "input-ds-zenodo_new4",
      "type": "image",
      "meta": {},
      "read_only": true,
      "id": 5,
      "resource_list": [
        {
          "path": "/home/tommaso/Fractal/fractal-demos/examples/01_cardio_tiny_dataset/../images/10.5281_zenodo.7059515/",
          "id": 5,
          "dataset_id": 5
        }
      ],
      "project_id": 4
    },
    {
      "name": "output-ds-zenodo_new4",
      "type": "zarr",
      "meta": {},
      "read_only": false,
      "id": 6,
      "resource_list": [
        {
          "path": "/home/tommaso/Fractal/fractal-demos/examples/01_cardio_tiny_dataset/tmp_zenodo_new4/output",
          "id": 6,
          "dataset_id": 6
        }
      ],
      "project_id": 4
    }

NOTE: I don't think there's enough space to show either of these columns in such a small view, but I was not expecting to see them empty. I propose we:

Understand what is going wrong.
Remove the "Metadata" column (that one will have a lot of information, which cannot fit in this view).
Replace the "Resources" column with something shorter than a full list of long absolute paths, e.g. we replace it with a new "Number of resources" column.

Additional info: maybe these fields look empty because they were empty when the dataset was created (which is always the case), but at some point they need to be updated with an additional API call.


[CELEBORN-1521] Introduce celeborn-spi module for authentication extensions

What changes were proposed in this pull request?
Introduce celeborn-spi module for authentication extensions.
Why are the changes needed?
Address comments: https://github.com/apache/celeborn/pull/2632#issuecomment-2247132115
Does this PR introduce any user-facing change?
No, this interface has not been released.
How was this patch tested?
UT.

cc @pan3793 @waitinfuture

one more question: should we make all SPI to be Java interfaces?

ok, rewritten with java

SBT build pass:
 build/sbt "clean;celeborn-spi/package"; ls spi/target

Using /Users/fwang12/.sdkman/candidates/java/current as default JAVA_HOME.
Note, this will be overridden by -java-home if it is set.
[info] welcome to sbt 1.9.4 (Azul Systems, Inc. Java 1.8.0_392)
[info] loading settings for project celeborn-build from plugins.sbt ...
[info] loading project definition from /Users/fwang12/todo/celeborn/project
[info] loading settings for project celeborn from version.sbt ...
[info] resolving key references (12502 settings) ...
[info] set current project to celeborn (in build file:/Users/fwang12/todo/celeborn/)
[success] Total time: 0 s, completed Jul 24, 2024 11:55:23 PM
[info] generate META-INF/LICENSE for project celeborn-spi
[info] generate META-INF/NOTICE for project celeborn-spi
[info] compiling 5 Java sources to /Users/fwang12/todo/celeborn/spi/target/classes ...
[success] Total time: 1 s, completed Jul 24, 2024 11:55:24 PM
celeborn-spi-0.6.0-SNAPSHOT.jar resource_managed                sync                            zinc
classes                         streams                         update

thanks, merged to main/0.6.0


Add contributing docs and clean up Makefile

Overview
While working on #262, I noticed some opportunities to clean up the Makefile. I see these same Makefile constructs across various repos, so I think it's a case of the same thing getting copy-pasted across multiple projects.
This PR resolves those issues and starts a Contributing section in the README because I was confused about what to do the first time I dropped into this library.
Review requests

Do these changes make sense? I'm new to this codebase and surely lacking some context
I added reviewers by git blame, please add anyone else who should look at this

@Otterverse  is better at Makefile's than I am so I'm swapping to him :) Sorry James!

Go modules changed and I would not expect them to. Setting PR to a draft while I investigate

generally looks good to me, removing myself from reviewers since I'm not much good at Makefiles either


parameters used in pretraining

Hi AGILE team,
According to the manual you provided, we have cloned the MolCLR model into the .ckpt folder using the command git clone https://github.com/yuyangw/MolCLR.git, and its contents are shown in the figure below. Would any further operations be required for the cloned files? Additionally, in the pre-training config file, should load_model be set to MolCLR, such as load_model: MolCLR # resume training ?

Appreciate your help,
ycpei
<EMAIL_ADDRESS>

Hi @yuchanpei,
Sorry for the late reply! For the pre-training, you should only download the MolCLR checkpoints in the .ckpt folder, instead of clone the whole MolCLR repo. Let me know if you still have problems starting the pre-training!


exploitdb: 2023-04-22 -> 2023-04-24

Diff: https://gitlab.com/exploit-database/exploitdb/-/compare/refs/tags/2023-04-22...2023-04-24
Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.


Fixes an issue with a completion callback not being called in PacketTunnelProvider.

Task/Issue URL: https://app.asana.com/0/0/1205410509758168/f
BSK PR: https://github.com/duckduckgo/BrowserServicesKit/pull/488
macOS PR: https://github.com/duckduckgo/macos-browser/pull/1579
Description
Fixes an issue with a completion callback not being called in PacketTunnelProvider.
Steps to test this PR
Just check that NetP works fine.

Internal references:
Software Engineering Expectations
Technical Design Template

Look at the BSK PR for an explanation on why this was closed.


Sheet and CSS changes

Updated sheet and css to support optional 1E classes, cleaned up
formatting and changed displayed text.

Instead of replacing the old file with a new one, could you make these changes to the original file so that I can see the changes that are being made. Even if you copy the code from your new file over the old one, I will still be able to see the changes that are happening.


Migrate to SLAlpha4 & add display annotations

Purpose

Current Azure Service Bus connector implementation is in SLAlpha 2. This PR migrate the current implementation to SLAlpha 4 with display annotation support. It is necessary to add display names for client, remote operations, parameters and return values in the connector side which will be used in Choreo UI.
Resolves https://github.com/wso2-enterprise/choreo/issues/2964
Resolves https://github.com/wso2-enterprise/choreo/issues/3398

Goals

Migrate the connector to SLAlpha4 and add display annotations

Approach
Necessary changes in the code level have been done so that it is compatible with Swan Lake Alpha 4 release. Samples and Documentation are updated to support the changes. Github workflow is updated. Display names were added using @display annotation.

Add display name for client
Add display name for listener
Add display names for remote operations
Add display name for parameters in the remote operations
Add display name for the return value of the remote operations

User stories

N/A

Release note

Necessary changes in the code level have been done so that it is compatible with Swan Lake Alpha 4 release.
Display names were added using @display annotation.

Add display name for client
Add display name for listener
Add display names for remote operations
Add display name for parameters in the remote operations
Add display name for the return value of the remote operations

Documentation

https://github.com/RolandHewage/module-ballerinax-azure-service-bus/tree/alpha4#readme

Training

N/A

Certification

N/A

Marketing

N/A

Automation tests

Unit tests

Done

Integration tests

Done

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes
Ran FindSecurityBugs plugin and verified report? no
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes

Samples

https://github.com/RolandHewage/module-ballerinax-azure-service-bus/tree/alpha4/asb-ballerina/samples

Related PRs

N/A

Migrations (if applicable)

Migrate to SLAlpha 4 in Ubuntu 20.04 OS

Test environment

SLAlpha 4
JDK 11
Ubuntu 20.04
Service Bus Connector Version 0.1.2
Learning

N/A

This PR is outdated and addressed by a separate PR. Hence closing.


fastlane fails when doing sigh action

I am unable to finish my Fastlane lane as it exits with error while starting a sigh action:
[11:46:25]: fastlane finished with errors
/Library/Ruby/Gems/2.0.0/gems/spaceship-0.10.2/lib/spaceship/client.rb:244:in `parse_response': {"creationTimestamp"=>"2015-10-01T09:46:24Z", "resultCode"=>0, "userLocale"=>"en_US", "protocolVersion"=>"QH65B2", "requestId"=>nil, "requestUrl"=>"https://developer.apple.com:443//services-account/QH65B2/account/listTeams.action", "responseId"=>"248f52ed-c370-44e7-85d8-19f7be7755d8", "isAdmin"=>nil, "isMember"=>nil, "isAgent"=>nil, "pageNumber"=>nil, "pageSize"=>nil, "totalRecords"=>nil, "httpResponseHeaders"=>nil} (Spaceship::Client::UnexpectedResponse)
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.10.2/lib/spaceship/portal/portal_client.rb:52:in `teams'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.10.2/lib/spaceship/portal/ui/select_team.rb:35:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.10.2/lib/spaceship/portal/portal_client.rb:68:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.10.2/lib/spaceship/portal/spaceship.rb:37:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.10.2/lib/spaceship/portal/spaceship.rb:81:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-0.10.8/lib/sigh/runner.rb:12:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-0.10.8/lib/sigh/manager.rb:7:in `start'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/actions/sigh.rb:22:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:142:in `block (2 levels) in execute_action'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/actions/actions_helper.rb:37:in `execute_action'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:128:in `block in execute_action'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:127:in `chdir'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:127:in `execute_action'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/fast_file.rb:137:in `method_missing'
	from (eval):37:in `block (3 levels) in parse'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/lane.rb:36:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/lane.rb:36:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:109:in `try_switch_to_lane'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/fast_file.rb:129:in `rescue in method_missing'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/fast_file.rb:124:in `method_missing'
	from (eval):63:in `block (3 levels) in parse'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/lane.rb:36:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/lane.rb:36:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:51:in `block in execute'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:46:in `chdir'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/runner.rb:46:in `execute'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/lane_manager.rb:43:in `cruise_lane'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/lib/fastlane/command_line_handler.rb:31:in `handle'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/bin/fastlane:36:in `block (2 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:153:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/runner.rb:428:in `run_active_command'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/runner.rb:68:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/delegates.rb:15:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/bin/fastlane:127:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.30.2/bin/fastlane:133:in `<top (required)>'
	from /usr/bin/fastlane:23:in `load'
	from /usr/bin/fastlane:23:in `<main>'

Find out the account I configured had an iTunesConnect account but NOT a Developer Program account.

:+1:


[CLEANUP] - adding keyboard shortcut to copy the URL when in a trans …

…browser

Build Completed
:white_check_mark: This pull request has passed all validations.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  ui/src/org/pentaho/di/ui/spoon/ExpandedContentManager.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.ui.spoon.ExpandedContentManager

Instruction Change: -.54%:small_red_triangle_down:
Line Change: -.30%:small_red_triangle_down:


[HotFix] Fix create parent directory will cause FileAlreadyExistsException

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Codecov Report
Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (69676b4) 38.53% compared to head (d3c2801) 38.52%.

:exclamation: Current head d3c2801 differs from pull request most recent head 7d65e0e. Consider uploading reports for the commit 7d65e0e to get more accurate results

Files
Patch %
Lines

...pache/dolphinscheduler/common/utils/FileUtils.java
60.00%
2 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##                dev   #15576      +/-   ##
============================================
- Coverage     38.53%   38.52%   -0.01%
  Complexity     4766     4766
============================================
  Files          1305     1305
  Lines         44838    44805      -33
  Branches       4806     4783      -23
============================================
- Hits          17278    17263      -15
+ Misses        25684    25667      -17
+ Partials       1876     1875       -1

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


Detecting When NerdTree is Opening

Hello, sorry if this is an obvious question. But I cannot seem to find the answer to this (maybe I am just bad at looking for it).
I am trying to detect when NerdTree is opening a buffer. I need this because my winwidth, and winminwidth settings are effecting Nerdtree when set globally. Also, I resize splits to maximize the current split (and I don't want to maximize NerdTree ever).
My first attempt at this was to detect if I was entering a non-NerdTree buffer, and set local settings. But I guess these variables are not defined at the time the auto comands are running.
autocmd BufEnter * if (!exists("b:NERDTree") | setlocal winheight=5 | setlocal winminheight=5 | setlocal winwidth=85 | setlocal winminwidth=70 | :res | :vertical res | endif

My logic was that this should run in all buffers except the NerdTree buffer. But unfortunately, it runs all buffers.
Any advice would be greatly appreciated. Thanks!

I think the way resize works requires something a little more complicated. This .vimrc snippet works with vertical splits, but you can take it from here to handle the horizontal splits.
set winminwidth=5
autocmd WinEnter * resize |
                 \ vertical resize |
                 \ let current_win = winnr() |
                 \ let NT_win = bufwinnr('NERD_tree_*') |
                 \ if NT_win ==# current_win |
                 \   execute 'noautocmd setlocal winwidth='.g:NERDTreeWinSize |
                 \ elseif NT_win !=# -1 |
                 \   execute 'noautocmd '.NT_win.'wincmd w' |
                 \   execute 'noautocmd setlocal winwidth='.g:NERDTreeWinSize |
                 \   noautocmd wincmd p |
                 \ endif

Thanks @PhilRunninger! I tweaked this a little but I got it to work. Also, my understanding of winminwidth was wrong. Setting it sets it for all windows. So that was messing me up too. This solves my issue. You can close the issue if you want. And thanks for making such an amazing plugin!

You're welcome, but I can't take credit for NERDTree. It's @scrooloose 's brainchild; I'm just helping it along. If you don't mind, can you share your final autocmd for others who might be interested?

Oh sorry, I saw you on a bunch of the issues, so I assumed you must be the maintainer. But still, I thank you for the help!
I changed what you wrote to the following
set winheight=5
set winminheight=5
set winwidth=60
set winminwidth=40

autocmd WinEnter * let current_win = winnr() |
                 \ let NT_win = bufwinnr('NERD_tree_*') |
                 \ if NT_win ==# current_win |
                 \   execute 'noautocmd setlocal winwidth='.g:NERDTreeWinSize |
                 \ elseif NT_win !=# -1 |
                 \   execute 'noautocmd '.NT_win.'wincmd w' |
                 \   noautocmd wincmd p |
                 \   resize |
                 \   vertical resize |
                 \ endif

I moved the resize and vertical resize inside the elseif because I didn't want it doing it inside of nerdtree windows. I also removed the winwidth inside the elseif because the resize and vertical resize would just make the non-nerdtree window as big as it could be based on the global winminwidth, and winminheight.
But I learned a lot from this. I honestly didn't even know about noautocmd or that you could move to a window with wincmd w.

No worries. I'm just happy to keep it going.
It looks like you have a couple of lines that don't do anything. wincmd w followed by wincmd p just switches to NERDTree and back to the previous window. You can maybe take them out.
Yes, there is a lot to learn about Vim script buried deep in the help pages. I'm learning all the time myself.


can provide ppc64le paltform binary?

i want to npm i sharp ,but no ppc64le libvips binary,so i can not install sucessfully,can you provide one?thanks

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


ERROR: unknown message type '59' (also 50, 53, and 56)

I'm seeing frequent logs reporting unknown message types 50, 53, 56, and 59, which don't have entries in LXProtocolTypes.h. I only have original LIFX bulbs on the network (no LIFX White 800 lights) so it must be something else that the bulbs are sending out that's new. Hopefully we'll get a LIFXKit update soon? It doesn't crash my app (at least in this case) but at times it really fills up the logs.
ERROR: unknown message type '50'. The appropriate class may need to be registered in +[LFXMessage messageWithMessageData:]

I have seen these messages on my builds too. I suspect they are from the new firmware's cloud support messages since the SDK doesn't support/include the cloud service code (yet)

I am getting this errors right now.
I've tried to integrate the lifx framework into a swift osx application. I did exactly the steps from "Xcode Sub-Project Installation" and created a bridging header file.
Is there something else to do? What does this error mean?


Some original function not found

Is your feature request related to a problem? Please describe.
Why do some original functions not be found?
such as: https://ffmpeg4d.dpldocs.info/ffmpeg.libavutil.samplefmt.av_samples_get_buffer_size.html#meta
etc...
Describe the solution you'd like
I think we need these functions
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Or we could do the same thing by other method in goav project? Thanks~

@stephenwithav Hi, how do you think about this issue~I think we really need them.Would you plan to do that?

#82 I added some new functions

excellent~


Refactor 303 quarkus vertx sql module

I'm planning to implement more scenarios in regards of Route validation:

Add a custom validator
Validate responses

Beforehand, this PR aims to make some cleanup with:

Rename test classes in order to avoid having duplicate class names in different packages
Remove unnecessary @Valid and validator annotations
Fix some warnings that my IDE was complaining about

@pjgg I've replied all your comments and removed the leftover dependency, thanks for spotting!


Attempt to fix /economystats + add an alias for a command

Here goes nothing...
Keep in mind that I'm currently on an iPad so I can't test anything atm >_>

Failed Testing >_>

I'll fix it tomorrow, I know how to do so.

Perfect! @Mystifi can you also add the economy alias like I did?

Yeah, definitely.


Create PowerShell Standard 6.0 reference assembly

Tests are included to ensure that the assembly can be used to create a very simple cmdlet. I'll use this a the template to create the PowerShell Standard 5.1 assembly.
There is no actual implementation here, just the scaffolding of the classes, but this can be used to create assemblies (like cmdlet assemblies) which would then run against the actual code assembly. The expectation is that this source will be used to create the nupkg for distribution.
This also includes the source which was used for the PowerShell Standard 3.0 nuget package. The PowerShell Standard 3.0 assembly was initially created by jason, I'm including it in this PR to ensure that we keep track of it, since the compiled assembly is already available here: https://www.nuget.org/packages/PowerShellStandard.Library/3.0.0-preview-01

The decision was to create a repo for the PowerShellStandard rather than add it to this repo, so I'm closing this


resolve topic: Limit unread flag on automated notifications.

Previously, users found it annoying that the automated "Resolve topic"
notifications triggered an unread for everyone in the stream; this
discouraged some users from using the feature on older threads for
fear of being annoying. We change this to a better default, of only
users who participated in the topic (via either messages or reactions)
being eligible for the new message being unread.
We will likely want to create global and stream-level notifications
settings to control this behavior as a follow-up -- some users, like
me, might prefer the simpler "Always unread" behavior in some streams.
Note that the automated notifications that a topic was resolved will
still result in the topic being moved to the top of the left sidebar.
This would be somewhat difficult to change, since the left sidebar
algorithm just looks at the highest message ID in the topic.
Fixes #19709.
Only tested manually.  @amanagr do you have time to add tests for this?  It'd be a huge help.

Added test!

Merged, thanks @amanagr!


Will this work with a backend service?

Does this cache adapter work for a NodeJS server? Or is it intended to be used only for front-end usage?

It does, I actually just did this last week to cache requests executed in an Express API :)

Yes it works, and if you multi instance service you can use it with Redis

@ktalebian could just read the.... readme instead of polluting the issue board :)

This has been addressed, thanks for the useful information everyone.


Investigate webhook service

Rio currently uses webhooks in several areas to automate various aspects of the Gitops flows.
It may be worthwhile to investigate a standalone webhook server (non-k8s) that can be used to perform webhook automation against.

related issue https://github.com/rancher/rio/issues/676.


Add support for type definition in Form fields custom properties panel

Problem you would like to solve
I would like to be able to define typed (boolean, number) custom properties for Form fields. At the moment, every custom props is rendered in the relevant JSON file as String.
Proposed solution
In addition to "key" and "value" fields, add the "type" field to specify the JSON supported type of the variable.
Alternatives considered
At the moment we implemented a solution based on a prefix added to the value key, for example boolean.myproperty and we convert the value from string to the required type before rendering the Form and we strip the type prefix from the name of the variable.
Additional context
No response

Hi @davismol, thanks for sharing!
Can you maybe share a bit more about your use case? This will help us to understand why this is beneficial to add, especially because there are workarounds, as you described.

Hi, sorry for the late reply...
The idea is to have a way to define the JSON supported types for the custom properties of forms component.
I mean, if  I define something like this, in the relevatn JSON I get all the props as strings

I would like to be able to define the type (boolean, number, ecc..) in the modeler and get the property valued accordingly in the JSON and not as strings:
      "properties": {         "section": "anagraph-data",         "format": "myFormat",         "key3": true,         "key4": 10       },


Booking slot of activity that has started does nothing

Step to reproduce

Create an activity that should happen within a certain time interval, i.e. set a start and an end time.
Wait until the start time has past.
Click on the empty slot.
Click "Yes, of course!" in the pop-up.

What happens
Nothing happens; The slot stays empty, even after refreshing the page.
In the developers tools, the request's response is a 403 (Forbidden): {"detail":"The activity is in the past.","error_code":"permission_denied"}
What should happen
The slot shows your picture to confirm it is booked by you, or an error message is shown.
Personally, I do not have a clear preference as I could think of arguments against and for allowing booking slots of activities that have already started, so I suggest to show an error pop-up for the moment.

Yes, I think there are both cases, when it makes sense to be able to join after it started and when it does not. I myself have wanted to join a pickup that had a set time but was actually quite flexible within a time period, so it's always unclear when people join in late to save the pickup/activity from being missed. For that reason I'd prefer to leave it open for the user to choose, after receiving a warning.

This bug still needs to be fixed. :)

I implemented this backend part to allow to join started activities. It would resolve the issue if we just merge that as it is.
An optional extra would be the warning on the frontend, do you think we should do that before deploying it?

A warning would be nice indeed! :)

How about this? You need to then check the checkbox to join.

Looks good to me! Annoying having to check the box and then confirm, but that's the point!


Text Wrapping would help

So because messages can be any size but usually have words, regardless of language, if a word at the edge of the window wrapped around so it stayed whole, that would be best. Like Okayu became "Okay-u" because of not fitting entirely on the line.

It used to wrap word, and yes most of the time messages have word with spaces. Edge case is the "AAAHHHHHHHHHH" or other messages like that which broke the layout of the extension, so I added word break. I wanted to have hyphenation which is what you are suggesting, but somehow the CSS option doesn't work at all for me. I don't know if it's a problem of the browser, as hyphenation is a bit more complex, as according to documentation, it's based on a dictionnary. I will have to do some more research... There is also PR #83 which is reimplementing word wrap.


gnupg: remove systemd user config

This was removed upstream in:
https://github.com/gpg/gnupg/commit/eae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed
Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

#231108 fixes the systemd user config.

I just rebased this PR on staging after the all the merges to make it way smaller and easier to review.


macOS: Crash when closing any window

Crash on macOS with cibuild5911 when closing any window. mat1jaczyyy/apollo-studio
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
   at Avalonia.Native.WindowBaseImpl.get_Scaling()
   at Avalonia.Controls.TopLevel.Avalonia.Layout.ILayoutRoot.get_LayoutScaling()
   at Avalonia.Layout.Layoutable.GetLayoutScale()
   at Avalonia.Layout.Layoutable.MeasureCore(Size availableSize)
   at Avalonia.Layout.Layoutable.Measure(Size availableSize)
   at Avalonia.Layout.LayoutManager.Measure(ILayoutable control)
   at Avalonia.Layout.LayoutManager.ExecuteMeasurePass()
   at Avalonia.Layout.LayoutManager.ExecuteLayoutPass()
   at Avalonia.Controls.WindowBase.HandleResized(Size clientSize)
   at Avalonia.Controls.Window.HandleResized(Size clientSize)
   at Avalonia.Native.WindowBaseImpl.WindowBaseEvents.Avalonia.Native.Interop.IAvnWindowBaseEvents.Resized(AvnSize size)
   at Avalonia.Native.Interop.IAvnWindowBaseEventsShadow.IAvnWindowBaseEventsVtbl.Resized(IntPtr thisObject, Void* param0)
--- End of stack trace from previous location where exception was thrown ---
   at Avalonia.Native.PlatformThreadingInterface.RunLoop(CancellationToken cancellationToken)
   at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
   at Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime.Start(String[] args)
   at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime[T](T builder, String[] args, ShutdownMode shutdownMode)
   at Apollo.Core.Program.Main(String[] args) in /Users/mat1jaczyyy/Code/apollo-studio/Apollo/Core/Program.cs:line 125
Abort trap: 6
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

@danwalmsley it looks like that we are trying to handle resize on a window that's considered to be closed by Acalonia. Osx probably triggers that event on performClose or something


feat(whale-api): add GET api for on-chain governance

What this PR does / why we need it:

Add /proposals, /proposals/:id and /proposals/:id/votes endpoints on whale
To allow straightforward paginated listing implementation for downstream, e.g. scan and wallet

Which issue(s) does this PR fixes?:

Fixes #
Additional comments?:

Intermittent codecov issue when running CI, seems to be related to https://github.com/codecov/codecov-action/issues/598

Changing to draft while tests are being added into packages/whale-api-client/__tests__

Changing to draft while tests are being added into packages/whale-api-client/tests

@kyleleow Alternatively if we don't want to manually keep it in sync with ain and there are no foreseeable problems passing any arbitrary string to defid, then we can skip the validation


path not working

I have problems to get it to work. When  specify a "path", then it doesnt ask for authentication. I believe that the "path" I provide does not match. When I omit the "path"-Option, everything works as expected.
Maybe there is an issue with my .htaccess configuration?
I tried to use it together with slim-jwt-auth. The JwtAuthentication is working as expected.
The root of my Slim-App is under example.com/api. Therefore I use a .htacces to rewrite the URL:
RewriteEngine On
RewriteBase /api

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]

RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

My Slim-Code looks like this:
$app = new \Slim\App();
$app->add(new \Slim\Middleware\JwtAuthentication([
    "path" => "/jwttest", // or ["/api", "/admin"]
    "secret" => "supersecretkeyyoushouldnotcommittogithub"
]));

$app->add(new \Slim\Middleware\HttpBasicAuthentication([
    "path" => "/admin", //does not ask for authentication when i visit example.com/api/admin
    "users" => [
        "root" => "t00r",
        "user" => "passw0rd"
    ]
]));

$app->get("/", function() {
    echo "No password needed.";
});

$app->get("/admin", function() {
    echo "API protected by password";
});

//the following is working as expected:
$app->get("/jwttest", function() {
    echo "API protected by JWT";
});

Is there a difference, how the path is retrieved from the Slim-App between JwtAuthentication and HttpBasicAuthentication?

Slim 2 or Slim 3?

I'm using Slim 3. My composer.json looks like this:
{
"require": {
"slim/slim": "3.*",
"vrana/notorm": "dev-master",
"tuupola/slim-jwt-auth": "^2.0",
"monolog/monolog": "^1.17",
"lcobucci/jwt": "3.1.0",
"tuupola/slim-basic-auth": "2.x-dev"
}
}
2016-01-31 2:52 GMT+01:00 Mika Tuupola<EMAIL_ADDRESS>
Slim 2 or Slim 3?
—
Reply to this email directly or view it on GitHub
https://github.com/tuupola/slim-basic-auth/issues/19#issuecomment-177357017
.

Fixed in 2.0.1. As a sidenote you should use "tuupola/slim-basic-auth": "^2.0" instead. It is safer than using development version.

I found out, that it is working when I omit the leading slash of the path:
$app->add(new \Slim\Middleware\HttpBasicAuthentication([     "path" => "admin",     "users" => [         "root" => "t00r",         "user" => "passw0rd"     ] ]));

You can use ``` for codeblocks.

Thanks, it's working now.

Great. Thanks for the heads up!


GEOMESA-1027 README updates

Signed-off-by: Andrew Hulbert<EMAIL_ADDRESS>

nice, going to merge this too

b303e56ca68c3edef945500aa4df93e6f7125996


GVRCubeSceneObject is not visible by default

If you create a GVRCubeSceneObject with the following code, it will not be visible
            GVRCubeSceneObject cube_obj = new GVRCubeSceneObject(gvrContext);
            cube_obj.getRenderData().getMaterial().setColor(1, 0, 0);
            cube_obj.getTransform().setPosition(0, -1, -2);
            gvrContext.getMainScene().addSceneObject(cube_obj);

Ideally, you should be able to see a red cube with above code.
Here is the sample project that can reproduce this issue.
https://github.com/nitosan/GearVRf-bugs/blob/master/create_cube/app/src/main/java/com/example/org/gvrfapplication/MainActivity.java#L38

The default shader if none is specified is the Texture shader. If you don't supply a texture when you are using this shader, it will not render the object. If you use the Phong shader with only a color, that will work. This is fixed in the upcoming 4.0 release.

@nitosan
This will do what you want:
            GVRCubeSceneObject cube_obj = new GVRCubeSceneObject(gvrContext);
            cube_obj.getRenderData().getMaterial().setVec4("diffuse_color", 1, 0, 0, 1);
            cube_obj.getRenderData().setShaderTemplate(GVRPhongShader.class);
            cube_obj.getTransform().setPosition(0, -1, -2);
            gvrContext.getMainScene().addSceneObject(cube_obj);

setColor sets the u_color uniform for the texture and other legacy shaders.

@liaxim Thanks for the sample code, although this code sample works, I kinda feel that a developer should be able to set the color w/o digging into the inner works of material.

@nitosan No question about that. There needs to be a specific method for something as common as this.

@nitosan Your snippet works in 4.0. Can we close the issue? Do you have any specific suggestion how to improve the code in 4.0?

Verified working with 4.0.0


Edit to duct tape makes you unable to reload misc repair kit

Probably w/ all other reloadable things using duct tape too

Frankly, I'm shocked that this mod still receives any attention: it's been dead and buried for over 3 years now, with the most recent update simply saying "Other mods are being worked on".
Initially I was skeptical that this mod, of all things, would be causing any issues with duct tape, given that all it does is add gunmod functionality to it. Because it's a copy-from definition in Gunsmith, every other property comes from the base game. If there would be any issues with the item, it would be because of the base game, not the mod.
But, my ADHD loves distractions, so I went ahead and tested anyway.
The short answer is: no, it's not Gunsmith. The latest experimental I could get from DDA's Github (this one, cdda-experimental-2024-03-24-0121) has the exact same issue with duct tape rolls and misc. repair kits as it had for, well, a very long time now. This was true with or without Gunsmith on the same build of the game. You could reload the repair kit with loose duct tape, but not with the tape hidden "inside" a cardboard roll, in both cases.
For what it's worth, there is a possible fix coming to the base game at some point. However, given that your game version seems to be lagging behind by almost 11 months – the time when the cardboard roll change for duct tape was introduce – you might not see this fix for a very long time still.
That said, thank you for reminding me about the state of this repo. It really ought to be archived. A mod that has last been tested on a release three-and-a-half years ago is not much of a mod anymore.