Complete new linuxNew based packaging

Initial List before we split into an Epic etc.

[x] Update README.md on how to run it and how it works
[x] Add Java 8, 11, and 16 support for Temurin Builds Debian, Red Hat, and SUSE support
[x] Fix RH Build failing due to GPG signing bug
[x] Test for version string correctness
[x] Add Java 8 JRE Temurin packages
[x] ~Parameterize the scripts so that version numbers aren't hard-coded~ - See discussion below.
[x] Bring in cacerts logic from Andreas repo - Andreas has kindly given permission. ~Eclipse Tracking Bug and CQ~ - code was Pull Requested in.
[x] For the ca-certs figure out a way to have adoptium-ca-certificates as an optional package and deal with that gracefully.
[ ] Test the adoptium ca-certs package as a dependency of the main package
[x] Hook the the new build into a Jenkins pipeline? job
[x] Enable GPG signing for RPMs
[x] Implement uploading to Artifactory
[x] Integrate into Jenkins pipelines

From the original author:
If I remember correctly, the necessary infra for 11 and 16 is present. Doing packages for 8 is copy & paste and a little bit on top. Jenkins is able to build the packages. The only steps left to do: Pull them from Jenkins, manually sign the RPMs (create a new GPG key beforehand), and upload everything onto a server.

Initial metadata update: https://github.com/adoptium/installer/pull/331
Is there an email alias that can be used for RPMs/Debs? I suppose<EMAIL_ADDRESS>is wrong?

https://github.com/adoptium/installer/pull/332 for Updated README and an early attempt at adding a Java 8 temurin Debian package

Initial metadata update: #331
Is there an email alias that can be used for RPMs/Debs? I suppose<EMAIL_ADDRESS>is wrong?

Good question.  I suspect we aren't allowed to use the AdoptOpenJDK.net email addresses. Perhaps an EF-based mailing list?

Parameterize the scripts so that version numbers aren't hard-coded?

I've learnt the hard way over the past years that it's tough to reconcile OpenJDK's version numbering and Adopt's version numbering with the requirements of Debian and RPM packages. Remember the drama of <IP_ADDRESS>. If you get it wrong, the packages won't show up on the user's computers (been there, done that). If you get it very wrong, you have to increment the epoch (been there, done that). Computing the version number correctly requires access to correct metadata (for example, because the .1 rebuilds aren't included in java -version). In the past, metadata was sometimes incomplete or wrong. Furthermore, extensive automated testing would be needed to ensure that every edge case is covered. You also have to consider that the packages are a separate "product" with their own version. If you fix a bug in the package, you have to bump the version. And you have to set it back once the next PSU comes out. Therefore, the lack of parameterization is a feature.

Fix RH Build failing due to GPG signing

I'm not sure what it means. If it means that you intend to sign the RPMs during the build, I'd reconsider. Signing RPMs during build requires sensitive key material on the build machines. Building takes time, so you need multiple machines. That was a problem in the past. So it's a deliberate choice not to sign the RPMs. I'd rather sign the RPMs just before uploading or even on the machine that distributes them (private GPG key is required on there anyway because the package indexes have to be signed).
I'd also strongly consider creating a keyring package for Debian (see https://wiki.debian.org/DebianRepository/UseThirdParty, Brave did this well in the past). This allows to rollover keys.

Fix RH Build failing due to GPG signing

I'm not sure what it means. If it means that you intend to sign the RPMs during the build, I'd reconsider. Signing RPMs during build requires sensitive key material on the build machines. The building takes time, so you need multiple machines. That was a problem in the past. So it's a deliberate choice not to sign the RPMs. I'd rather sign the RPMs just before uploading or even on the machine that distributes them (a private GPG key is required on there anyway because the package indexes have to be signed).

Something in the default Gradle tasks caused a GPG sign to be executed.  I think I'd rather have that as a separate explicit step.  Still digging into the code to see why it triggers (Suse and Debian don't).

I'd also strongly consider creating a keyring package for Debian (see https://wiki.debian.org/DebianRepository/UseThirdParty, Brave did this well in the past). This allows to roll over keys.

Will check with EF if they have something.

Additional piece that we didn't pull into the linuxNew story before (back when the work from adoptium-packages-linux was pulled in, is the cacert piece, which can be found here: https://github.com/aahlenst/adoptium-packages-linux/tree/cacerts - so add a step in the description of this issue to bring that in.

Initial metadata update: #331
Is there an email alias that can be used for RPMs/Debs? I suppose<EMAIL_ADDRESS>is wrong?

Good question. I suspect we aren't allowed to use the AdoptOpenJDK.net email addresses. Perhaps an EF-based mailing list?

@tellison suggested<EMAIL_ADDRESS>which seems fine. It's just an email address for users to report bugs/issues.

<EMAIL_ADDRESS>
I've globally replaced that in my PR

Dockerfiles for RPM-based distros need an update across the board because the old sks-keyservers.net pool was shut down.
RUN gpg --batch --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7

needs to be replaced with
RUN  gpg --batch --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7

Does anybody have any logs that shed some light on Fix RH Build failing due to GPG signing?? I just ran an RPM build and it worked fine.

Would be very helpful if someone could hook it up with GitHub Actions. A workflow exists but wasn't copied over. Although it's x64 only, that alone catches some issues and helps verifying PRs.

RUN  gpg --batch --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7

I swapped this out but get the error:
#9 [ 6/19] RUN gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu
#9 sha256:3ca4c0b2d52e7d651b6e73a9d43b94d10b5f37545dfc6f2cbb752ccc2ac64eea
#9 0.232 gpg: Signature made Thu Apr 16 06:40:32 2020 UTC
#9 0.232 gpg:                using RSA key B42F6819007F00F88E364FD4036A9C25BF357DD4
#9 0.232 gpg: Can't check signature: No public key
#9 ERROR: executor failed running [/bin/sh -c gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu]: exit code: 2
------
 > [ 6/19] RUN gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu:
------
executor failed running [/bin/sh -c gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu]: exit code: 2

@aahlenst - Extra question.  I understand you completed the ca-certs work in your repo (https://github.com/aahlenst/adoptium-packages-linux/tree/cacerts).  Should I just be looking to bring across all of https://github.com/aahlenst/adoptium-packages-linux/tree/cacerts/ca-certificates and patch the scripts to refer to those as what I think you've done in your repo?

RUN  gpg --batch --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7

I swapped this out but get the error:
#9 [ 6/19] RUN gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu
#9 sha256:3ca4c0b2d52e7d651b6e73a9d43b94d10b5f37545dfc6f2cbb752ccc2ac64eea
#9 0.232 gpg: Signature made Thu Apr 16 06:40:32 2020 UTC
#9 0.232 gpg:                using RSA key B42F6819007F00F88E364FD4036A9C25BF357DD4
#9 0.232 gpg: Can't check signature: No public key
#9 ERROR: executor failed running [/bin/sh -c gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu]: exit code: 2
------
 > [ 6/19] RUN gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu:
------
executor failed running [/bin/sh -c gpg --batch --verify /tmp/gosu.asc /usr/bin/gosu]: exit code: 2

On a side note, should I also swap the key server for the Suse script?

I've resolved this, gosu and tini needed separate keys.

@aahlenst - Extra question. I understand you completed the ca-certs work in your repo (https://github.com/aahlenst/adoptium-packages-linux/tree/cacerts). Should I just be looking to bring across all of https://github.com/aahlenst/adoptium-packages-linux/tree/cacerts/ca-certificates and patch the scripts to refer to those as what I think you've done in your repo?

@aahlenst - Stewart and I were a little confused over this.  I think the current build bundles the cacerts with the JDK itself, so is having a separate adoptium-ca-cacerts linux package actually needed?

I hope you have some time 😁
Having the keystore as part of the JDK (= included in the package) is a subpar experience.

Adding certificates to the keystore requires to change the keystore. However, because the keystore is bundled with the package, it gets updated with every package update. So you have to re-add the certificate to the keystore after each package update. Good luck with getting that right. One possible way out would be to mark the keystore as config file in the package's metadata. Henceforth, you'd be asked whether you want to replace the keystore or not. That's an all or nothing operation. Most people won't see the prompt anyway, because few people update their systems interactively. Because the default option is to keep the modified keystore, they wouldn't ever get new CA certificates.
The OS keystore and the Temurin keystore are different. So some tools can connect to a website while Temurin cannot and vice versa. This is very confusing (we had many reports in the past). This was somewhat mitigated by shipping Mozilla's list of CA certificates. You can configure this integration yourself, but why bother when you can just apt-get or yum install whatever is included with your distribution?

So, integrating with the tooling of the OS to centrally manage the keystore and have a consistent list of certificates in the OS and JDK is the right thing to do.
On RPM based distributions, this can be achieved rather easily. The ca-certificates packages of RHEL and friends automatically generate a suitable keystore for the JDK. You just have to symlink it.
On Debian derivatives, this is more complicated. There exists a package that can generate a keystore for the JDK. Unfortunately, it has a cyclic dependency on the JDK because the program to generate the keystore is written in Java. Some script in that package acts as a tie breaker, but it can only do that for JDK it knows. And it knows only JDKs shipped as part of Debian. We tried it in the past and failed. So, I decided to roll our own without the cyclic dependency. To be clear, it does not contain a cacerts file. But it generates one and integrates with Debian's facilities to manage CA certificates. You add a CA certificate to Debian and the cacerts will automatically be regenerated. Same happens if you remove one. As a result, the package is very small and even architecture-independent. In can be used by any JDK (not only Temurin). It just needs to be installed once.
I think that provides enough value for a little price and brings Temurin's packages on equal footing as the JDKs shipped by the distros themselves. But Temurin even has the AQA/TCK stamps of approval.

Thinking out loud.  I'm not 100% convinced this is what users will expect.  Up until now Java users have kept the O/S keystore and Java keystore separate and I'd hypothesize for many users that's a good thing (they may not want their O/S to have all of the allowable certs by Java and vice versa).
By making this change now, we'd be changing some pretty fundamental default behaviour.
Perhaps offering to do this as an optional step would be OK (if I can figure out how to do that).

For Eclipse Signing: see https://wiki.eclipse.org/IT_Infrastructure_Doc#What_about_GPG_signing.3F
looks like they have a maven target mvn gpg:sign-and-deploy-file we’ll need to find out what the cbi url is to send artefacts
e.g https://cbi.eclipse.org/jarsigner/sign but for gpg
George is asking the EF on the details here.

We got requests to integrate with the OS facilities. And now would be a good time to fix all the weirdness. We'd also follow every (?) distro JDK package out there. RHEL, SUSE, Debian, Alpine, all do this. It was inaptness that we didn't have it from the beginning.
If you want to make this opt-in (Debian, don't know about RHEL from the top of my head):

Rename cacerts to bundled_cacerts or something similar.
Claim a directory/file in /etc/default. Define a variable like BUNDLED_CACERTS=Yes.
Include tooling in the package to symlink cacerts to either bundled_cacerts or the file in the cacerts package depending on the value of BUNDLED_CACERTS.
Invoke that tooling during postinst.

This would have to be part of the Temurin JDK package. If you included it in the cacerts package, the cacerts package would have to know about all versions. Doable, but maybe not desirable.

Should I just be looking to bring across all of https://github.com/aahlenst/adoptium-packages-linux/tree/cacerts/ca-certificates and patch the scripts to refer to those as what I think you've done in your repo?

You might succeed in cherry-picking the commit or use git patch apply to bring it over.

For Eclipse Signing: see https://wiki.eclipse.org/IT_Infrastructure_Doc#What_about_GPG_signing.3F
looks like they have a maven target mvn gpg:sign-and-deploy-file we’ll need to find out what the cbi url is to send artefacts
e.g https://cbi.eclipse.org/jarsigner/sign but for gpg
George is asking the EF on the details here.

That's what you have to do: https://access.redhat.com/articles/3359321. RPMs only. Debian packages should not be signed, but the package index instead.

We got requests to integrate with the OS facilities.

@aahlenst Makes sense but any idea why we wanted to have our own CA package instead of using the CA package supplied with each distro? e.g. ca-certificates on RHEL (Provides /etc/pki/ca-trust/extracted/java/cacerts) or ca-certificates-java (Provides /etc/ssl/certs/java/cacerts) on Ubuntu

OK, John and I were looking at this locally and I see what Debian does now (basically loops through the O/S certs and adds them via keytool for Java, thereby keeping them in sync - there's an update command as well).  So I think it makes sense as @aahlenst suggests.  Now to figure out the coding to make that a reality :-).

It looks like Debian already solves this with the ca-certificates-java package.  I'll try setting that as a dependency.
Now, the ca-certificates-java may not have the richness of the Adopt set that we pull from Mozilla, in which case I'll go back to the fuller solution that @aahlenst proposed.  Sorry for the slowness here folks, I'm learning as I go :-)

@karianna I know it's hard to keep track of everything I wrote. But https://github.com/adoptium/installer/issues/330#issuecomment-896308438 explains everything. Why ca-certificates-java doesn't work and that our cacerts package is supposed to be Debian only because RHEL has solved this differently (and better). Please re-read. I also welcome suggestions to improve my writing.
Also note that most Linux distributions effectively use Mozilla's list of certificates.

Thanks, and apologies that I hadn't read through that comment previously

Likewise - thanks for the detail - I'll give this a go tomorrow and update the PR as appropriate.  This is the last step before signing to solve.  Both RPM and Deb 8/11 packages have been manually tested and compared against the previous AdoptOpenJDK packages and are the same - so that's good.

@aahlenst - I think I'd like to fork and clone your repo into Adoptium that creates the adoptium-ca-certificates.deb file.  Would that be OK?

@karianna Understood. I'm happy to arrange a full transfer. Or you can create a new repo and just push the old contents into it.

Something to keep an eye on while evaluating repository hosting options: The software responsible for generating the Debian repository needs to be capable to sign the Release and InRelease files with multiple GPG keys. Otherwise, it is impossible to securely roll over the keys. Artifactory cannot do it (at least when I checked the last time, heck it cannot even generate those files correctly). reprepro can since 4.3.

@karianna Any more progress on this recently? Is this blocked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=575312 btw, or is there anywhere else these packages could be hosted in the meanwhile?

I just need to find time - and sadly my main work machine has pretty much died on me so I'm going to lose potentially another week.  Super sorry about this I know the community has been waiting for a long time.

 Let us know if we can be of any help. :+1:

Is there any ETA when the deb packages will be available?

Hoping to complete this by end of Sept, the Java 17 release is giving us extra impetus :-)

Hello, it's me again! 😛
While we wait for the official packages, here's some unofficial 'installer' packages for Debian and Ubuntu.
https://github.com/rpardini/adoptium-deb-installer
I had a working package generator back from AOJ days, and adapted it today to use GitHub Actions and the v3  Adoptium API.
It produces tiny packages that just download the tarball from official sources, check SHA256,  and sets it up the way Debian and Ubuntu expects it (update-alternatives, etc).
They're multi-arch, and packages for JDK 8, 11, 16 and 17 are available, both in a simple Debian APT repo and via Ubuntu PPA.
Remember: unofficial, don't go using those in production.

It ssems it never will be finished. We just switched to Zulu, as they are reliable. Adoptium/Temurin for Linux is a no-go.

@persicsb FYI we did the same :-(

the tarball is ok for jlinking an embedded jre, which you don't even need to be running linux to do, but yeah; for our systems that need to have it installed at system are either still stuck on adoptopenjdk 16.0.1 or are moving to ubuntu's own packaging (but they're slow too)

It ssems it never will be finished.

I can assure you that is not the case. We're going to get this fixed, and I fully agree that the delay here in getting these out at Adoptium has not been great. Believe me, we're very much aware of it and have taken steps in the last week or so to get this driven to completion and are working out some versioning issues with the packaging. Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

The problem is Github Actions uses adoptium, so no JDK17 until this issue
is done.
On Wed, Nov 10, 2021, 12:22 Rachel Greenham @.***>
wrote:

the tarball is ok for jlinking an embedded jre, which you don't even need
to be running linux to do, but yeah; for our systems that need to have it
installed at system are either still stuck on adoptopenjdk 16.0.1 or are
moving to ubuntu's own packaging (but they're slow too)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/adoptium/installer/issues/330#issuecomment-965036205,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEQWKUK722H4C4KUKAHWCLULJIXXANCNFSM5BVTOWSA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

standalone deb/rpms were expected at some point and are useful to help with testing (there was an ask for that earlier), but ultimately a repo is strongly preferred as it lets it become part of a routine software update process.

It ssems it never will be finished.

I can assure you that is not the case. We're going to get this fixed, and I fully agree that the delay here in getting these out at Adoptium has not been great. Believe me, we're very much aware of it and have taken steps in the last week or so to get this driven to completion and are working out some versioning issues with the packaging. Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

yum/apt repository is better, but it seems to take you guys more time to prepare. so it would be nice if rpm/deb files could be pushed onto github first for everyone to use.

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

Repositories are the nicest (as many security regulations does not enable direct GitHub fetching) , but around 3 weeks ago the community here seemed to agree on providing rpms/debs as GitHub releases are enough as the absolute minimum.

I am looking for alternatives as well after reading that JREs are not supported anymore (adoptium/adoptium#64) but jlink would be the way to go. We run hundreds of Apps in Kubernetes based on the same JRE base images. Switching to jlink would just increase the build time without the benefit of saving diskspace at all. And now even packages for JDK 8 an d 11 are outdated.

Agreed with previous comments.
RPM/DEB on github releases is a good workaround but apt/dnf/yum repos are ideal eventually. At least for our use-case.

I can assure you that is not the case. We're going to get this fixed, and I fully agree that the delay here in getting these out at Adoptium has not been great. Believe me, we're very much aware of it and have taken steps in the last week or so to get this driven to completion and are working out some versioning issues with the packaging.

Thanks for the update. It seems like AdoptOpenJDK should have kept producing releases until the Adoptium transition is done. And I understand that issues and delays happen, but the lack of communication has been an issue for me. Whenever I get asked when we'll be ready to push the next patch release of Java 11 my answer is "I don't know, the state of our upstream provider is in transition since August with no ETA" and have to refer to this issue. Not great. Is there another place I should be looking for updates? Can we get more frequent updates on the status, some kind of ETA, what issues are being worked through, how people can potentially help? What workarounds have been explored so people can stop offering the same suggestions?

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

My org is primarily based on CentOS 7, x64 and ARM. yum repositories we can mirror internally would be ideal. Straight RPMs would be enough to unblock us, which echos the discussion already had on this issue.

Agreed with all the above. RPM would be a decent workaround, but it should be published to a yum repo.

Thanks for the update [...] the lack of communication has been an issue for me.

Understood and I agree 100% on the sentiments.

Is there another place I should be looking for updates? Can we get more frequent updates on the status, some kind of ETA, what issues are being worked through, how people can potentially help?

We've got multiple people on this just now. The overall strategy is as per this issue. We've got a job in our CI to create Temurin packages at https://ci.adoptopenjdk.net/view/work-in-progress/job/adoptium-packages-linux-pipeline/ but there are some failures occurring in some parts of the process so they're not quite ready for release yet and some of the names may change. I'm working with the people doing the work to make the issues more public and some are now in this repository but there are a few others that are not yet logged in there.

Unfortunately, it has a cyclic dependency on the JDK because the program to generate the keystore is written in Java. Some script in that package acts as a tie breaker, but it can only do that for JDK it knows. And it knows only JDKs shipped as part of Debian. We tried it in the past and failed.

@StrangeNoises has been digging around today and thinks that we might be able to avoid that by setting our temurin packages as providing the virtual javaXX-runtime-headless ones which act as a suitable dependency for ca-certificates-java. If we can legitimately do that it could well be a valid way of avoiding the extra package.

Hi @byF - I was under the impression that setup-java already supports Temurin via tarballs - what is it that's blocked on the native install packages?

You're right, if you're using setup-java action, then yes. However, virtual environment contains Java LTS versions directly as well: https://github.com/actions/virtual-environments/issues/4085#issuecomment-930956468 (and that's what we want to keep using)

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

Just to call out a different opinion from others, but the same conclusion...
The expectation of being able to pull from an upstream Apt/Yum repository is convenient for one-off users, but it is probably a bad idea for anybody with long-term commitments.
For the upstream project, it is a bad idea, because it has a significant expense related to hosting costs. It is possible that the costs can be directed towards an organization already willing to pay for such things, such as Github.com, but the cost exists nonetheless.
For users, and particularly for large groups of users, such as a company, it is generally a bad idea to have an open dependency on a public web site for business critical functions. Upstream URL change, and upstream organizations change (AdoptOpenJDK -> Adoptium in this very threat). Content appears and disappears at the whim of somebody else. "Appears" means that a "yum upgrade" may pick up a package which has never been tested, and this could be automated and happen across hundreds or thousands of machines.
As a result of the above, I think it is important to warn people that any serious users of downstream packages should be taken their own local copies, and serving it from their own repositories to their user bases. And, this means that the .rpm and .deb are the most important artifacts. Whether they are published to "Github Releases" pages, or to a "Yum Repository", my first action will be to download it and test it, and my next action will be to publish it in our own Yum repositories for local consumption.

Just my 2 cents: if YUM/APT repositories are not provided at all, that is a serious regression compared to AdoptOpenJDK, however, this was not communicated when it was announced, that AdoptOpenJDK joins the Eclipse Foundation.
Users expected improvements (Eclipse-provided runtime, additional quality checks), but this is a drawback. It would certainly make some feel that Eclipse Foundation is just a cemetery for open-source projects.

I agree with the sentiment that it's a significant regression from what we had before to not have hosted repositories that could deliver the minor version upgrades in a routine fashion.
It is normal in the Linux world for packages to be distributed this way, assuming competent hosting and packaging (with cryptographic signing in place, we would expect to add adoptium's public key to our systems' keychain, which allows for automatic verification of packages by the package manager). Not supporting it makes adoptium weird and less useful, and people will rather find alternatives. I understand as well as Azul, Microsoft offers deb/rpm repos for their openjdk builds now... which for those of us who have been around a while, is superbly ironic, but nevertheless a fact.
Sites that don't want to be a part of that can then choose to opt out and download and install the packages manually, or make use of the various version "pinning" facilities offered by their respective distros for precisely this purpose. (eg: as an administrator you can "pin" production machines to a specific version, allow upgrades to a test instance, and when satisfied "pin" the production systems to that version instead. No need then for a local repo.)

^--- "No need then for a local repo"... This depends upon "small mom/pop shop" vs "big user base". In the former case, it can seem easier to let somebody else manage this for you. But, this then subjects you to the other person.
The idea of one central repository that is the center of the Universe, and machines in the world pull for it, is a recipe for global failure.
That said... I'm not saying it isn't an expectation and requirement for one-off users who don't know how to, or haven't yet recognized the need to keep local copies, and distribute from local copies.

providing the repos in the normal linux fashion does not prevent people using their own local repo or being as paranoid as they want. but being weird and not fitting into normal package management will make adoptium far less useful to everyone else.

Just my 2 cents: if YUM/APT repositories are not provided at all, that is a serious regression compared to AdoptOpenJDK, however, this was not communicated when it was announced, that AdoptOpenJDK joins the Eclipse Foundation.

One this topic I will reiterate that it was NEVER our intention to stop having such repositories, which is why it was not communicated :-) We just haven't done a great job of getting the new setup ready :'(

On the topic of whether to have a local repo, that's obviously entirely up to each organisation. One of the nice things about Adoptium is that we place absolutely no restrictions on redistribution, so you're welcome to do so if it's beneficial for your business (The only disadvantage from our perspective is that it wouldn't show up in any of our download metrics :-) )

One this topic I will reiterate that it was NEVER our intention to stop having such repositories, which is why it was not communicated :-) We just haven't done a great job of getting the new setup ready :'(

I know, but the person before me argued against YUM/APT repositories. And from what I see, and what was communicated, the current target is to push RPMs/DEBs to Github releases.
For example, some comments ago you asked, if we really need repositories:

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

This wording suggested, that if no one on this thread needs a repo, it won't be done.

... whereas earlier than that there was talk of producing deb/rpms for direct download first, as a stopgap and to allow wider testing that the packages themselves were ok, but... it was always expressed as being that, with proper repos later.
what's the opposite of feature-creep? 😀

This wording suggested, that if no one on this thread needs a repo, it won't be done.

Gotcha - that absolutely wasn't my intention with the question - I was attempting to guage "Is it a waste of our time if we put that interim solution in place before we have the apt/yum repos ready"

@sxa, first of all, thanks for your efforts so far.

Putting an interim solution by e.g. publishing packages via GitHub releases is definitely not a waste a time from my point of view.
As others said, referring to this issue every time when our security department asks me for fixes for JDK 8 or 11 or development teams ask me when they may get JDK 17 is unfortunate. And it does not strengthen the trust in the decision a couple of years back for AdoptOpenJDK which I endorsed heavily against Zulu or the JDK packages provided by Debian itself.
One of my colleagues now went forward, ran the packaging scripts on their workstation and published them to our own Artifactory instance to be picked up.
It was not a real big effort but some.
And we like to automate things, which is not as straightforward as all our build machines are behind firewalls and so we would need to copy firstly all involved Docker images, the Git repository and tar-balls to do that.
I know that someone already published packages on GitHub and please, this is great for some people, but I think corporate users really like if there are more "official" packages.
We consume quite some software via GitHub releases, so we trust these anyways, checking them against SHA256 is easy and I can imagine that this is the same for other consumers as well.

We've managed to get a repository set up that should be possible to make Temurin live in apt/yum purposes early next week, so it's likely that we'll now skip the publishing direclty to github and go straight to that assuming no other blockers show up. We're also hard at work making sure the packages are signed (a prereq for putting them in those repos) and ensuring we have them available for all the platforms we support. We're very close now, finally :-)

Thank you very much!
Is there any problem with the signing key?
I installed the key:
pub   rsa2048 2021-11-16 [SC]
      3B04 D753 C905 0D9A 5D34  3F39 843C 48A5 65F8 F04B
uid           [ unknown] Adoptium GPG Key (DEB/RPM Signing Key<EMAIL_ADDRESS>sub   rsa2048 2021-11-16 [E]

But i get this:
E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.

I used debian bullseye.

Good progress has been made, but there are a couple of draft PRs still being worked for deb files including what you have noted in https://github.com/adoptium/installer/issues/330#issuecomment-979320890. (See draft PRs at: https://github.com/adoptium/installer/pull/382 and https://github.com/adoptium/installer/pull/386).
Also good progress on the rpms (https://github.com/adoptium/installer/pull/388 and others in the merged PRs list that add support for several archs).
Current view of artifacts being pushed to adoptium.jfrog.io

Thanks to everyone (@sophia-guo @gdams @sxa @karianna @jerboaa @aahlenst and others I am likely forgetting) who has helped progress on this work, hopefully only a few tasks left.
Automated testing for the non-x86 archs also still needs to be added (https://github.com/adoptium/installer/issues/375).  Meantime, we'll reach out for manual testing help for aarch64 (that will be pushed shortly, related: https://github.com/adoptium/installer/pull/389 and https://github.com/adoptium/installer/pull/391).

example:
deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main

Thank you very much! Is there any problem with the signing key? I installed the key:
pub   rsa2048 2021-11-16 [SC]
      3B04 D753 C905 0D9A 5D34  3F39 843C 48A5 65F8 F04B
uid           [ unknown] Adoptium GPG Key (DEB/RPM Signing Key<EMAIL_ADDRESS>sub   rsa2048 2021-11-16 [E]

But i get this:
E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.

I used debian bullseye.

an example:
deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main

@SekiBetu The issue here seems to be that the repository itself doesn't have a Release.gpg, not that the public key isn't found.

To be precise:
For those lazy like me:
# wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
# echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye Release" > /etc/apt/sources.list.d/adoptium.list
# apt-get update
E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

To be precise – this fails for me:
# wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
# echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye Release" > /etc/apt/sources.list.d/adoptium.list
# apt-get update
E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

just want you to know apt-key is no longer used, try gpg instead, example:
curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | sudo gpg --dearmor -o /usr/share/keyrings/adoptopenjdk-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/adoptopenjdk.list
sudo apt update && sudo apt install -y adoptopenjdk-11-hotspot

This leads to:
curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | gpg --dearmor -o /usr/share/keyrings/adoptopenjdk-archive-keyring.gpg \
     && echo "deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/adoptopenjdk.list \
     && apt update && apt install --no-install-recommends -qy adoptopenjdk-11-hotspot

E: Malformed entry 1 in list file /etc/apt/sources.list.d/adoptopenjdk.list (Component)
E: The list of sources could not be read.

# cat /etc/apt/sources.list.d/adoptopenjdk.list
deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb  main

Would it be possible to generate RHEL 6 RPMs too?
It's still supported especially on ELS.
Thanks

This leads to:
curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | gpg --dearmor -o /usr/share/keyrings/adoptopenjdk-archive-keyring.gpg \
     && echo "deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/adoptopenjdk.list \
     && apt update && apt install --no-install-recommends -qy adoptopenjdk-11-hotspot

E: Malformed entry 1 in list file /etc/apt/sources.list.d/adoptopenjdk.list (Component)
E: The list of sources could not be read.

# cat /etc/apt/sources.list.d/adoptopenjdk.list
deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb  main

the new repo is not out yet, i'm just showing the old one as an example, your error is caused by lsb_release not installed, you need to replace $(lsb_release -cs) with bullseye manually

just want you to know apt-key is no longer used, try gpg instead, example:

'apt-key' should still work. I think the actual issue is that the new repository does not yet have any "Release.gpg" files.

the new repo is not out yet

Some of us are just impatient ;) This should be the new repo: https://adoptium.jfrog.io/ui/packages

@knyttl @SekiBetu Please don't mix examples with the old adoptopenjdk repo. The adoptium temurin repo has problems and is not usable yet and @knyttl s example should work (with the component main). Also with buster and stretch. The "signed-by" syntax is optional but the apt-key way and storing the gpg store in /etc/apt/trusted.gpg.d should work as well.

Thank you for correctly signing the debian repository!
But please fix these two property problems that makes the debian reposity unusable:
https://github.com/adoptium/installer/issues/400
https://github.com/adoptium/installer/issues/401

Thanks you @gdams . I can now install Temurin 8,11 and 17 on Debian 9,10 and 11.

@nudgegoonies so what is your complete script for installation?

Manually i tested with Debian 9,10 and 11 Docker Images with these interactive commands (example for debian:bullseye image):
apt update
apt install wget gpg
wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye main" > /etc/apt/sources.list.d/adoptium.list
apt update
apt install temurin-8-jdk temurin-11-jdk temurin-17-jdk

For our inhouse temurin docker images based on debian i use the gpg file in /etc/apt/trusted.gpg.d rather than apt-key.

This fails for me:
E: Failed to fetch https://jfrog-prod-usw2-shared-oregon-main.s3.amazonaws.com/aol-adoptium/filestore/18/18e4eba26b7de862ace87b1e0a53e98c80d22a92?X-Artifactory-repositoryKey=deb&X-Artifactory-projectKey=temurin&x-jf-traceId=163ef43197e5d8bb&response-content-type=application/x-debian-package&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20211216T095738Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIASG3IHPL6RZALTNGC/20211216/us-west-2/s3/aws4_request&X-Amz-Signature=c072600fa00f4e1f2d96e3632618b2bb705db237ec7d7645a876cba5dcb46bda  File has unexpected size (163938604 != 163938492). Mirror sync in progress? [IP: <IP_ADDRESS> 443]

Seems promising. Can you please make RPMs available for Fedora 34 and 35? It may be just a simple symbolic link from the current Fedora 33 RPM. Fedora 33 is EOL now, Fedora 35 is the current production release.
Oftentimes, people use $releasever in the repository path, to make updates seamless, however, since the repository only contains Fedora 33 packages, it may not be suitable for most users.

. Can you please make RPMs available for Fedora 34 and 35? It may be just a simple symbolic link from the current Fedora 33 RPM. Fedora 33 is EOL now

@sophia-guo could you please remove the Fedora 33 release and add support to push 34 and 35?

Manually i tested with Debian 9,10 and 11 Docker Images with these interactive commands (example for debian:bullseye image):
apt update
apt install wget gpg
wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye main" > /etc/apt/sources.list.d/adoptium.list
apt update
apt install temurin-8-jdk temurin-11-jdk temurin-17-jdk

For our inhouse temurin docker images based on debian i use the pepared gpg file in /etc/apt/trusted.gpg.d rather than apt-key. So this should work too:
wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  |  gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/temurin.gpg

Err:5 https://adoptium.jfrog.io/artifactory/deb bullseye/main amd64 temurin-17-jdk amd64 <IP_ADDRESS>.0+12-1
  File has unexpected size (163938604 != 163938492). Mirror sync in progress? [IP: <IP_ADDRESS> 443]
  Hashes of expected file:
   - SHA256:c58199f37de694227cb6d2288a838a520a590a0587f74dadc8cbc2e464872197
   - SHA1:4053b7d65ec2a417d31ecee3aa75e6bc6987b391 [weak]
   - Filesize:163938492 [weak]
Fetched 2,602 kB in 1s (5,147 kB/s)
E: Failed to fetch https://jfrog-prod-usw2-shared-oregon-main.s3.amazonaws.com/aol-adoptium/filestore/18/18e4eba26b7de862ace87b1e0a53e98c80d22a92?X-Artifactory-repositoryKey=deb&X-Artifactory-projectKey=temurin&x-jf-traceId=7c9953e1337c3fc6&response-content-type=application%2Fx-debian-package&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20211216T112033Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIASG3IHPL6RZALTNGC%2F20211216%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Signature=bebdf1777f77dd685bc82c8d3e6e44aa6cd6a03e60ff81c59e723d4a5f8f3164  File has unexpected size (163938604 != 163938492). Mirror sync in progress? [IP: <IP_ADDRESS> 443]
   Hashes of expected file:
    - SHA256:c58199f37de694227cb6d2288a838a520a590a0587f74dadc8cbc2e464872197
    - SHA1:4053b7d65ec2a417d31ecee3aa75e6bc6987b391 [weak]
    - Filesize:163938492 [weak]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

same error here

nvm, it's working now.

another question: will openj9 version be added in the future?

another question: will openj9 version be added in the future? i didn't see any information about openj9 here adoptium/adoptium#68

No.
There are RPM downloads here (the semeru open edition is the successor of openj9 builds from adoptopenjdk):
https://developer.ibm.com/languages/java/semeru-runtimes/downloads/

Fedora 33 removed. Fedora 34, 35 added.

Hi! is it possible to get Java 17 as RPM for CentOS 7?

@evgenkisel it looks like the CentOS 8 repo also works for CentOS 7 based on a quick docker smoke test, though IDK if there are any potential issues doing that. It looked like there was a CentOS 7 repo last week, not sure what happened to it. Also unsure where the repository key is for importing. This is the repo I was using for testing: https://adoptium.jfrog.io/artifactory/rpm/centos/8/x86_64/. Unsure if it's actually ready to be used but:
$ docker run -it --rm centos:7
[root@91dd8f25fe3d /]# yum-config-manager --add-repo https://adoptium.jfrog.io/artifactory/rpm/centos/8/x86_64/
Loaded plugins: fastestmirror, ovl
adding repo from: https://adoptium.jfrog.io/artifactory/rpm/centos/8/x86_64/

[adoptium.jfrog.io_artifactory_rpm_centos_8_x86_64_]
name=added from: https://adoptium.jfrog.io/artifactory/rpm/centos/8/x86_64/
baseurl=https://adoptium.jfrog.io/artifactory/rpm/centos/8/x86_64/
enabled=1

[root@91dd8f25fe3d yum.repos.d]# yum --nogpgcheck install temurin-11-jdk
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: centos.s.uw.edu
 * extras: or-mirror.iwebfusion.net
 * updates: ftp.osuosl.org
Resolving Dependencies
--> Running transaction check
---> Package temurin-11-jdk.x86_64 0:<IP_ADDRESS>.0.8-1 will be installed
--> Processing Dependency: libXtst(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: libXrender(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: libXi(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: libXext(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: libX11(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: freetype(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: fontconfig(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: dejavu-sans-fonts for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Processing Dependency: alsa-lib(x86-64) for package: temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64
--> Running transaction check
---> Package alsa-lib.x86_64 0:1.1.8-1.el7 will be installed
---> Package dejavu-sans-fonts.noarch 0:2.33-6.el7 will be installed
--> Processing Dependency: dejavu-fonts-common = 2.33-6.el7 for package: dejavu-sans-fonts-2.33-6.el7.noarch
---> Package fontconfig.x86_64 0:2.13.0-4.3.el7 will be installed
--> Processing Dependency: fontpackages-filesystem for package: fontconfig-2.13.0-4.3.el7.x86_64
---> Package freetype.x86_64 0:2.8-14.el7_9.1 will be installed
--> Processing Dependency: libpng15.so.15(PNG15_0)(64bit) for package: freetype-2.8-14.el7_9.1.x86_64
--> Processing Dependency: libpng15.so.15()(64bit) for package: freetype-2.8-14.el7_9.1.x86_64
---> Package libX11.x86_64 0:1.6.7-4.el7_9 will be installed
--> Processing Dependency: libX11-common >= 1.6.7-4.el7_9 for package: libX11-1.6.7-4.el7_9.x86_64
--> Processing Dependency: libxcb.so.1()(64bit) for package: libX11-1.6.7-4.el7_9.x86_64
---> Package libXext.x86_64 0:1.3.3-3.el7 will be installed
---> Package libXi.x86_64 0:1.7.9-1.el7 will be installed
---> Package libXrender.x86_64 0:0.9.10-1.el7 will be installed
---> Package libXtst.x86_64 0:1.2.3-1.el7 will be installed
--> Running transaction check
---> Package dejavu-fonts-common.noarch 0:2.33-6.el7 will be installed
---> Package fontpackages-filesystem.noarch 0:1.44-8.el7 will be installed
---> Package libX11-common.noarch 0:1.6.7-4.el7_9 will be installed
---> Package libpng.x86_64 2:1.5.13-8.el7 will be installed
---> Package libxcb.x86_64 0:1.13-1.el7 will be installed
--> Processing Dependency: libXau.so.6()(64bit) for package: libxcb-1.13-1.el7.x86_64
--> Running transaction check
---> Package libXau.x86_64 0:1.0.8-2.1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================================
 Package                                  Arch                    Version                           Repository                                                           Size
==============================================================================================================================================================================
Installing:
 temurin-11-jdk                           x86_64                  <IP_ADDRESS>.0.8-1                   adoptium.jfrog.io_artifactory_rpm_centos_8_x86_64_                  157 M
Installing for dependencies:
 alsa-lib                                 x86_64                  1.1.8-1.el7                       base                                                                425 k
 dejavu-fonts-common                      noarch                  2.33-6.el7                        base                                                                 64 k
 dejavu-sans-fonts                        noarch                  2.33-6.el7                        base                                                                1.4 M
 fontconfig                               x86_64                  2.13.0-4.3.el7                    base                                                                254 k
 fontpackages-filesystem                  noarch                  1.44-8.el7                        base                                                                9.9 k
 freetype                                 x86_64                  2.8-14.el7_9.1                    updates                                                             380 k
 libX11                                   x86_64                  1.6.7-4.el7_9                     updates                                                             607 k
 libX11-common                            noarch                  1.6.7-4.el7_9                     updates                                                             164 k
 libXau                                   x86_64                  1.0.8-2.1.el7                     base                                                                 29 k
 libXext                                  x86_64                  1.3.3-3.el7                       base                                                                 39 k
 libXi                                    x86_64                  1.7.9-1.el7                       base                                                                 40 k
 libXrender                               x86_64                  0.9.10-1.el7                      base                                                                 26 k
 libXtst                                  x86_64                  1.2.3-1.el7                       base                                                                 20 k
 libpng                                   x86_64                  2:1.5.13-8.el7                    base                                                                213 k
 libxcb                                   x86_64                  1.13-1.el7                        base                                                                214 k

Transaction Summary
==============================================================================================================================================================================
Install  1 Package (+15 Dependent packages)

Total download size: 161 M
Installed size: 319 M
Is this ok [y/d/N]: y
Downloading packages:
(1/16): dejavu-fonts-common-2.33-6.el7.noarch.rpm                                                                                |  64 kB  00:00:05
(2/16): alsa-lib-1.1.8-1.el7.x86_64.rpm                                                                                | 425 kB  00:00:05
(3/16): fontconfig-2.13.0-4.3.el7.x86_64.rpm                                                                                | 254 kB  00:00:00
(4/16): fontpackages-filesystem-1.44-8.el7.noarch.rpm                                                                                | 9.9 kB  00:00:00
(5/16): dejavu-sans-fonts-2.33-6.el7.noarch.rpm                                                                                | 1.4 MB  00:00:00
(6/16): freetype-2.8-14.el7_9.1.x86_64.rpm                                                                                | 380 kB  00:00:05
(7/16): libX11-1.6.7-4.el7_9.x86_64.rpm                                                                                | 607 kB  00:00:05
(8/16): libX11-common-1.6.7-4.el7_9.noarch.rpm                                                                                | 164 kB  00:00:00
(9/16): libXau-1.0.8-2.1.el7.x86_64.rpm                                                                                |  29 kB  00:00:00
(10/16): libXi-1.7.9-1.el7.x86_64.rpm                                                                                |  40 kB  00:00:00
(11/16): libXrender-0.9.10-1.el7.x86_64.rpm                                                                                |  26 kB  00:00:00
(12/16): libXtst-1.2.3-1.el7.x86_64.rpm                                                                                |  20 kB  00:00:00
(13/16): libpng-1.5.13-8.el7.x86_64.rpm                                                                                | 213 kB  00:00:00
(14/16): libxcb-1.13-1.el7.x86_64.rpm                                                                                | 214 kB  00:00:00
(15/16): libXext-1.3.3-3.el7.x86_64.rpm                                                                                |  39 kB  00:00:05
(16/16): temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64.rpm                                                                                | 157 MB  00:00:15
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                5.9 MB/s | 161 MB  00:00:27
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : fontpackages-filesystem-1.44-8.el7.noarch                                                                                1/16
  Installing : dejavu-fonts-common-2.33-6.el7.noarch                                                                                2/16
  Installing : dejavu-sans-fonts-2.33-6.el7.noarch                                                                                3/16
  Installing : libX11-common-1.6.7-4.el7_9.noarch                                                                                4/16
  Installing : 2:libpng-1.5.13-8.el7.x86_64                                                                                5/16
  Installing : freetype-2.8-14.el7_9.1.x86_64                                                                                6/16
  Installing : fontconfig-2.13.0-4.3.el7.x86_64                                                                                7/16
  Installing : libXau-1.0.8-2.1.el7.x86_64                                                                                8/16
  Installing : libxcb-1.13-1.el7.x86_64                                                                                9/16
  Installing : libX11-1.6.7-4.el7_9.x86_64                                                                                10/16
  Installing : libXext-1.3.3-3.el7.x86_64                                                                                11/16
  Installing : libXi-1.7.9-1.el7.x86_64                                                                                12/16
  Installing : libXtst-1.2.3-1.el7.x86_64                                                                                13/16
  Installing : libXrender-0.9.10-1.el7.x86_64                                                                                14/16
  Installing : alsa-lib-1.1.8-1.el7.x86_64                                                                                15/16
  Installing : temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64                                                                                16/16
  Verifying  : libXext-1.3.3-3.el7.x86_64                                                                                1/16
  Verifying  : alsa-lib-1.1.8-1.el7.x86_64                                                                                2/16
  Verifying  : libXi-1.7.9-1.el7.x86_64                                                                                3/16
  Verifying  : fontconfig-2.13.0-4.3.el7.x86_64                                                                                4/16
  Verifying  : libXau-1.0.8-2.1.el7.x86_64                                                                                5/16
  Verifying  : temurin-11-jdk-<IP_ADDRESS>.0.8-1.x86_64                                                                                6/16
  Verifying  : libXrender-0.9.10-1.el7.x86_64                                                                                7/16
  Verifying  : libX11-1.6.7-4.el7_9.x86_64                                                                                8/16
  Verifying  : dejavu-fonts-common-2.33-6.el7.noarch                                                                                9/16
  Verifying  : dejavu-sans-fonts-2.33-6.el7.noarch                                                                                10/16
  Verifying  : libXtst-1.2.3-1.el7.x86_64                                                                                11/16
  Verifying  : 2:libpng-1.5.13-8.el7.x86_64                                                                                12/16
  Verifying  : libxcb-1.13-1.el7.x86_64                                                                                13/16
  Verifying  : freetype-2.8-14.el7_9.1.x86_64                                                                                14/16
  Verifying  : fontpackages-filesystem-1.44-8.el7.noarch                                                                                15/16
  Verifying  : libX11-common-1.6.7-4.el7_9.noarch                                                                                16/16

Installed:
  temurin-11-jdk.x86_64 0:<IP_ADDRESS>.0.8-1

Dependency Installed:
  alsa-lib.x86_64 0:1.1.8-1.el7                  dejavu-fonts-common.noarch 0:2.33-6.el7    dejavu-sans-fonts.noarch 0:2.33-6.el7    fontconfig.x86_64 0:2.13.0-4.3.el7
  fontpackages-filesystem.noarch 0:1.44-8.el7    freetype.x86_64 0:2.8-14.el7_9.1           libX11.x86_64 0:1.6.7-4.el7_9            libX11-common.noarch 0:1.6.7-4.el7_9
  libXau.x86_64 0:1.0.8-2.1.el7                  libXext.x86_64 0:1.3.3-3.el7               libXi.x86_64 0:1.7.9-1.el7               libXrender.x86_64 0:0.9.10-1.el7
  libXtst.x86_64 0:1.2.3-1.el7                   libpng.x86_64 2:1.5.13-8.el7               libxcb.x86_64 0:1.13-1.el7

Complete!
[root@91dd8f25fe3d yum.repos.d]# java -version
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment Temurin-11.0.13+8 (build 11.0.13+8)
OpenJDK 64-Bit Server VM Temurin-11.0.13+8 (build 11.0.13+8, mixed mode)
[root@91dd8f25fe3d yum.repos.d]#

@evgenkisel
This worked for me on RHEL 8 for example:
cat <<'EOF' > /etc/yum.repos.d/adoptium.repo
[Adoptium]
name=Adoptium
baseurl=https://adoptium.jfrog.io/artifactory/rpm/centos/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public
EOF

yum install temurin-17-jdk

(and yeah, the CentOS 7 repository has recently disappeared 😮)

are there plans on adding jre only packages to this repo? or will it always be the full jdk only

When will the APT installation instructions be added to https://adoptium.net/installation.html#packages?  I can already see it on the blog at https://blog.adoptium.net/2021/12/eclipse-temurin-linux-installers-available/.

@wwuck i’ll be adding the instructions to the website shortly

Ubuntu 21.10 deb version is missing. As @Pokegamer129 has a problem setting up a repository on his system, I found out that by troubleshouting his process as described in comments of Moresteck/BetaCraft-Launcher-Java#114 and I'm not sure if package for 21.04 might be compatible.

can confirm the above. Following the instructions to the letter from the blogpost on 21.10 (impish indri) fails because there is no release for that version. Changing the source file to use hirsute does work. There are some minor (non-showstopper) issues with using update-java-alternatives but at this point we probably should be raising new issues for them if we think they're important enough.

well, matching which distro versions are actually supported by their own vendors seems a good start. 😀 21.04 is going to EOL very shortly; 21.10 is the current non-LTS release, although I don't think it was when JDK 17.0.1 came out 😜
But honestly assuming it's the same actual binary build being installed in each case - as opposed to, say, compiled against the extant library versions in that exact distro version - then it could probably be simplified by not making the distro version a part of the repo url.
Or in Ubuntu's sake (and its own downstream derivatives), basing it off the upstream debian version instead, as there are fewer of those and they last longer. via /etc/debian_version.
I imagine you might have similar issues with Fedora, where releases are also frequent and short-lived, vs. RHEL and what's stepped into CentOS's shoes.

well, matching which distro versions are actually supported by their own vendors seems a good start.

Absolutely and I will be attempting to ensure we have that as a minimum ;-)

Now that there are JRE builds back (yay!), are there plans to provide them as Debian packages via the repository, too? Right now, only JDK packages are available there.

I have also a question about crypto-policies: Is it planned to autoconfigure the installed Eclipse Temurin JDK to use the system-wide configured crypto-policies?

The blog post mentions linux package support for SLES 12, but I cannot find any folder with sles packages in the jfrog repository. Is support for SLES still planned? And will the installation documantion be put on the adoptium.net page?

The blog post mentions linux package support for SLES 12, but I cannot find any folder with sles packages in the jfrog repository. Is support for SLES still planned? And will the installation documantion be put on the adoptium.net page?

https://blog.adoptium.net/2021/12/eclipse-temurin-linux-installers-available/

I have also a question about crypto-policies: Is it planned to autoconfigure the installed Eclipse Temurin JDK to use the system-wide configured crypto-policies?

We do not have that in the plan at the moment.

I have also a question about crypto-policies: Is it planned to autoconfigure the installed Eclipse Temurin JDK to use the system-wide configured crypto-policies?

We do not have that in the plan at the moment.

The Red Hat distribution of OpenJDK (java-11-openjdk package) on RHEL is automatically using the system-wide crypto-policies as far as I know. Probably they configure this behavior in a similar way like you configure the usage of the system certificate store here.
If it's currently not on the plan - how can I request a feature request for this?

The blog post mentions linux package support for SLES 12, but I cannot find any folder with sles packages in the jfrog repository. Is support for SLES still planned? And will the installation documantion be put on the adoptium.net page?

https://blog.adoptium.net/2021/12/eclipse-temurin-linux-installers-available/

Yes, that's the blog post I was referring to. It mentions SLES:

openSUSE/SLES Instructions

Import the RPM repo making sure to change the openSUSE version if you are not using OpenSUSE 15.2. RPM’s are also available for SLES 12 and 15. To check the full list of versions supported take a look at https://packages.adoptium.net/ui/repos/tree/General/rpm.

But there is no folder for SLES in the jfrog repo:

Am I missing something obvious?

See #426

@karianna Great, thanks!

@karianna The jfrog-repo lists sles 12 and 15 now, which is great! Thanks 👍 Currently, there is only temurin 17.0.2 available - will packages for jdk 11 be provided as well?

Yes they should be arriving AFAIK

Thanks everyone.


Confused about language for how to set-up a local batch process with the pre-trained Megadetector_v3

Hi!
I am confused about how to initiate the batch processing functionality of the megadetector. I've now successfully called the single image detection script, but am not completely understanding what phrasing to use when designating a multiple images to be sifted through the run_tf_detector_batch.py
I'm new to all of this, I've learned what a json file is and see that designating one is necessary for the batch process. Would someone be able to point me in the right direction for how to phrase the command to designate multiple images to the batch process script?
Thanks for your time!
edit: Correction, I now understand the purpose of the json file and it's role with using the visualization tool. My main confusion is how do you communicate to the script that an entire directory of images is to be classified as opposed to just one.

Oh geez, major user error on my end. Will try to keep future questions less dumb and more infrequent. Issue closed.

Glad you were able to figure this out @Jonathan-Gore! Yes, the image_file argument can be path to a directory as explained in its help text, but yes, it is a confusing argument name!


fix cve-2022-29810 in 2.3 branch

The related issue: https://github.com/stolostron/backlog/issues/22260
Signed-off-by: Yang Le<EMAIL_ADDRESS>

/lgtm


DEV: minimize image size with multistage builds

I feel like this is the direction minimizing docker images should go towards, rather than attempt to squash layers within image.
We should keep package installs as minimial as possible (EG, only installing -dev packages when absolutely necessary) by building ruby (and in the discourse one with imagemagick + nginx builds, install non-dev packages for running things requiring other linked libs)
Build in a separate image, and copy over the compiled ruby binaries
don't include build dependencies listed on ruby-build page in the final image.
before: 318MB
after: 250MB

turns out this was missing shared libs and it did need a bunch of libraries to run ruby, which was most of the space identified here. I'm sad ruby is such a hog, but we're on par with official ruby debian slim images of ~76mb compressd.


Strange issue with SPRITE parameter

Hi again,
I'm struggling to understand why the following code not works (sprite is not moving) when I use a variable in the SPRITE instruction (s or THIS.spr instead of 0).
If you decomment the 2 lines commented below (and comment the next one), it works. Why?
Tested on latest version 3.1, no error or warning during compilation:
xcbasic3.exe src\test.bas output\test.prg
Complete. (0)
+---------------+-------+-------+
|    Segment    | Start |  End  |
+---------------+-------+-------+
|BASIC Loader   | $0801 | $080C |
|Program code   | $080D | $09EB |
|Library        | $09EC | $09FF |
|Variables*     | $0A00 | $0A0E |
+---------------+-------+-------+
(*) Uninitialized segment.

' This code doesn't work. If you decomment the 2 lines and comment the following one, it works. Why?

TYPE TSPRITE
    spr AS BYTE
    x   AS INT
    y   AS BYTE

    SUB setPosition() STATIC
        'SPRITE 0 AT THIS.x, THIS.y
        SPRITE THIS.spr AT THIS.x, THIS.y
    END SUB

    SUB move() STATIC
        THIS.x = THIS.x + 1
        CALL THIS.setPosition()
    END SUB

    SUB init(s as BYTE, px AS INT, py AS BYTE, c AS BYTE) STATIC
        'SPRITE 0 ON COLOR 7
        SPRITE s ON COLOR c

        THIS.spr = s
        THIS.x = px
        THIS.y = py

        CALL THIS.setPosition()
    END SUB
END TYPE

DIM spr AS TSPRITE
CALL spr.init(0, 24, 100, 7)

FOR k as INT = 0 TO 320
    CALL spr.move()
    DO WHILE PEEK($D012) <> 240: LOOP
NEXT

Notice that if I put the variable s between parathesis, the compiler crash (not sure if it's related):
SPRITE (s) ON COLOR c
object.Exception@source\language\factor.d(118): Add case for XCBASIC.Factor
----------------
0x00007FF713015A37
0x00007FF712EDAEB1
0x00007FF712F16096
0x00007FF712ED8BEE
3
0x00007FF712ED8BF8
0x00007FF712EDA1B8
4
0x00007FF712ED8BF8
0x00007FF712F5F083
0x00007FF712EC2DFD
0x00007FF712EC3724
2
0x00007FF712EC376B
0x00007FF712D62E06
0x00007FF71302DFE3
0x00007FF71302DE3F
0x00007FF71302DF3F
0x00007FF71302DE3F
0x00007FF71302DD4A
0x00007FF713017F29
0x00007FF712D68422
0x00007FF71308A53C
0x00007FFE54F17614 in BaseThreadInitThunk
0x00007FFE551226F1 in RtlUserThreadStart

Looking at it I'd say it's a bug in the compiler. I'll check.

Fixed in https://github.com/neilsf/xc-basic3/releases/tag/v3.1.6
Thanks for the bug report!


[WIP] add instance normalization

Accessing #5229
This implements Instance Normalization, but this is a draft atm (20180910).
TODO

[ ] Backprop
[ ] Test
[ ] Document

Any comments are welcome!

Hi,
To use cuDNN BatchNormalization, gamma and beta have to be 1-dimensional.
Is this correct?

Since this is a bit old and I changed the design, close this and submit a new PR.


Can you tell me the parameters of the vessel segmentation，thank you very much!!

Can i obtain the parameters of the Drive dataset training？include “BatchSize”, “epochs”. I'll appreciate for you!!!!

1/4 annotated images (5 labeled images and 15 unlabeled images)， batch size is 16

1/4 annotated images (5 labeled images and 15 unlabeled images)， batch size is 16

thank you very much!!!


⚠ Bofrost.si has degraded performance

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

HTTP code: 200
Response time: 2570 ms

Resolved: Bofrost.si performance has improved in 68e65b9.


Make code more configurable and add documentation how to run locally

I have run the code locally on my macOS Sonoma, 14.0 (23A344)) and go version 1.20.9 from Visual Studio Code to get sense about code base and be able to test local changes before contributing into upstream.
This changes are not breaking changes and just simplify a local setup for a project

Already in https://github.com/Threagile/threagile/pull/57


Unable to run/test configuration

Expected Behavior
Testing the feed should populate the result in the "result" tab.
Current Behavior
I tried running the xkcd example given in the readme file, but it doesn't seem to work. I get no output in the "testing" tab, and no helpful message in the System logs.
Steps to Reproduce
Please provide detailed steps for reproducing the issue.

Installed & enabled feediron. Getting the "Feediron" tab in user interface.
Selected "xkcd_com" from predefined rules & clicked on Add: Nothing happens.
Gave the following configuration to add a rule in the configuration text area:

{
    "xkcd.com": {
        "type": "xpath",
        "xpath": [
             "div[contains(@id,'comic')]",
             "div[contains(@id, 'comic')]\/img\/@title"
        ],
        "join_element": "
"
    },
    "debug": "true"
}

Clicked on Add, nothing happens. Expected: A page load or some message. Actual: Nothing. No error in system log as well.

Tried testing the example config in the testing section. using the following config:

{
    "type": "xpath",
    "xpath": [
         "div[contains(@id,'comic')]",
         "div[contains(@id, 'comic')]\/img\/@title"
    ],
    "join_element": "
"
}

No progress on the screen. Expected: the xkcd comic should load. Actual: Stack trace (?) in system logs.

Failure Information (for bugs)

Context
Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

Operating System: Debian 9
TTRSS version/git version: Tiny Tiny RSS v18.12 (734af33)
PHP version: PHP 7.0.33-0
Feediron Configuration: NA
Feediron branch/commit: master/407168c628880b5ced572cc549db6d50e866d3c8

Yes the add function dosn't give any notification feedback. This is defiantly a bad fist user experience issue.

select feed example, press add
Press save (Don't think it's necessary but always a good idea)

Next time TT-RSS updates the XKCD feed it will use that rule to process.
As for the testing area The log looks like it ran successfully so it's hard to say.
Do feed load normally?
If you right click and in Inspect element is there anything in the Result tab of the Testing Tab?
Example:

    Neal Stephenson thinks it's cute to name his labels 'dengo'

I'm running  v18.8 (642677d) at the moment I'll update sometime the week after next if you keep having issues.

I inspected the results pane, and it shows the following html:

So the img element is missing from results.
One thing that I'm trying to understand is the concept of "predefined
rules". If I add these, are these added some backend configuration and
used behind the scenes?
If I select any rule, and click on add, and let's say the rule is
added. Will it merge with the Configuration that I give in the text
area?
I'm asking this because I used an existing rule, and added its feed in
order to test, but it's not working. I'm still getting just a one-line
blurb in the feed and have to go to the website to read the actual article.
dugite-code writes:

Yes the add function dosn't give any notification feedback. This is defiantly a bad fist user experience issue.

select feed example, press add
Press save (Don't think it's necessary but always a good idea)

Next time TT-RSS updates the XKCD feed it will use that rule to process.
As for the testing area The log looks like it ran successfully so it's hard to say.
Do feed load normally?
If you right click and in Inspect element is there anything in the Result tab of the Testing Tab?
Example:

    Neal Stephenson thinks it's cute to name his labels 'dengo'

I'm running  v18.8 (642677d) at the moment I'll update sometime the week after next if you keep having issues.

--
With best regards,
Tushar Tyagi

@dugite-code While I've not been able to test the code, the functionality is working if I write the configuration for individual websites.
I just have to wait for the feed to load again the next time background job runs.
Perhaps we can close the ticket?


Wesee Block with parallax styling

Implement main content area, ideally content can be in a column block with extra block option to get the styling specific for this section. Extra section meta data might be needed here.

This is currently hard coded in a clientlib. To be discussed if we keep it that way aka hard coded as well.

As discussed in todays call we will keep this as a static fragment in the projects GitRepo as well. @amlan18041996 will provide a static HTML snippet we can re-use.


Python's package for "+pyvenv" should be "pyvenv" instead of "pyvenv-mode"

Installing pyvenv-mode   FATAL ERROR: (error Package ‘pyvenv-mode-’ is unavailable)   Run again with the -d flag for details
The actual package is here

My bad! This is now fixed. Thanks for letting me know!


[Bug] [worker-server] Obviously, when I wait in series, I will wait all the time, and I can't stop waiting

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened

Obviously, when I wait in series, I will wait all the time, and I can't stop waiting
What you expected to happen
no
How to reproduce
no
Anything else
No response
Version
3.0.0-alpha
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

hi，I checked the latest dev branch and the problem I've been waiting for has been solved, but enumerating classes is risky.


Install script fails to detect distro on Debian

Hi,
The script fails on Debian
./setup.py
Traceback (most recent call last):
  File "./setup.py", line 964, in <module>
    main()
  File "./setup.py", line 957, in main
    install_plugin()
  File "./setup.py", line 869, in install_plugin
    install_packages(SYSTEM_DEPENDENCIES)
  File "./setup.py", line 261, in install_packages
    command = DISTRIBUTION_TO_INSTALLER[detect_linux_distribution()] + " ".join(packages)
KeyError: 'Debian GNU'

Because Debian is not in the DISTRIBUTION_TO_INSTALLER
root@stretch:~# cat /etc/*-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Go to line 63 and add Debian GNU
DISTRIBUTION_TO_INSTALLER = {
"Ubuntu": APT_INSTALL_COMMAND,
"Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
"Amazon Linux AMI": YUM_INSTALL_COMMAND,
"CentOS Linux": YUM_INSTALL_COMMAND,
"Debian GNU": APT_INSTALL_COMMAND,
}

FYI with the new Amazon Linux ami, you have to do this too, you'll get the same error except it will so "Amazon Linux" so just change "Amazon Linux AMI" to "Amazon Linux"

@dgouldin thanks
Does it make a new pull-request to fix this issue?


[Refactor][core]Data inflation when using postgres

What and why to refactor
As a software engineer, I am using devlake to collect developer data since long time ago. Recently we find that the _devlake_subtasks table occurs a data inflation. It used 750MB after a week from we upgrading devlake v1.0, but there were only 1000 records in the table.
Describe the solution you'd like
Solutions from @klesh

Reduce the update rate to _devlake_subtasks  table when collect data.
Store progress info in memory firstly and write it to db in a fixed rate.

Related issues
No
Additional context

The issue was introduced in v1.0.
We are using postgres.

After reading some code,I organizaed a table to show when we updading the progress of sub tasks.

Trigger timing
Times
Code

Sub task started
Once a sub task
https://github.com/apache/incubator-devlake/blob/98bc98bc9b62108834cfa10b554d708b64c1e932/backend/core/runner/run_task.go#L308-L314

Mannually called by sub task context
Unknown(decide by plugin implement)
https://github.com/apache/incubator-devlake/blob/98bc98bc9b62108834cfa10b554d708b64c1e932/backend/impls/context/default_exec_context.go#L68-L97https://github.com/apache/incubator-devlake/blob/98bc98bc9b62108834cfa10b554d708b64c1e932/backend/impls/context/default_subtask_context.go#L37-L53

Mannually called by task context
Unknown
https://github.com/apache/incubator-devlake/blob/98bc98bc9b62108834cfa10b554d708b64c1e932/backend/impls/context/default_task_context.go#L40-L49

Seems that the progress updating calling is not always under controller, so we need to descrise db operation automatically.


C++ Program to Left/Right rotate an array

Assigned Issue Number?
#40
Language Opted?
C++
Number of files added or updated?
1
Name of these files?
Data_Structures/Array/array_rotate.cpp
Checklist

[x] I was assigned for this otherwise my PR will be rejected.
[x] I've read the contribution guidelines.
[x] I've referred the correct issue number.
[x] I've filled up this entire template correctly.

:star2: this repository and support.

@falguni-k 👍🏼


Week days short in SQ language

These are short days for SQ language
closes #442

@antoniandre

Thank you for the PR, merged and release in version 3.10.2.


Update swagger-ui-dist to 4.5.1

Updates org.webjars.npm:swagger-ui-dist from 4.5.0 to 4.5.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.webjars.npm", artifactId = "swagger-ui-dist" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #736.


A few more style bugs

Changed code snippet styles.
Updated tip styles - added text to content before.
Changed footer text color.
Search styles changes.

Hello @richbachman,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


Logging support

This isn't optimal yet - there is some duplication since each sub-class now has its own logger, so there's no need to prefix each message manually with the class name - but it's certainly functional and tested.

Thank goodness for the m_log never failing to return a pointer, so we can do away with the if (m_log).

I'm going to add pull requests for the nVidia and AMD submodules and then I plan to look them over and merge them.  We can continue cleanup/refactoring as needed once they are in.


inline comments not working

We're dropping inline comments for now after some recommendations from the UX team.


Fix dependency paths after re-organizing configs

I forgot to update the dependency paths in the Sceptre config files, so I ran into errors during deployment.
https://github.com/Sage-Bionetworks-Workflows/nextflow-infra/runs/5236025506?check_suite_focus=true

@tthyer: Thanks for the prompt! The contribution guidelines definitely needed to be spruced up a little.


Can't install with without access to /usr/local/share

This seems to be a problem with install_nbextension not our code.  Is it possible that nb extensions aren't as compatible with  virt_env as they should be?  Or is it just that IPython don't want notebook extensions to be part of the virtual env?

Ping @takluyver IIRC. Virtualenv is python specific, so we have no knowlege of it. There is a userflag for that if you want to explicitely install elsewhere.

We've gone back and forth on where to install things by default - for now, the default is systemwide, and you can pass user=True if you want to do a per-user installation. We don't want to encode knowledge of a particular Python-specific environment tool into these functions (nbextensions and kernelspecs are not part of the Python environment), but we will look for them in e.g. share/jupyter/nbextensions relative to sys.prefix, so if you know you're in an environment, you can install there.

Thanks for the clarification @takluyver.  @Carreau, can you add one more option that allow us to specify an alternate install directory, so that user's can manually specify the path sharee/jupyter/nbextensions relative to sys.prefix

There's already a prefix option. But once you know where you want to install to, the installation process is really just copying files.

(i.e. there's no reason to go through an IPython API if you know where you're installing to - just use standard shutil functions to copy a file or folder)

Thanks @takluyver, since we already call the IPython API, we have just added the prefix option.
Closed by #77

I stumbled on
OSError: [Errno 13] Permission denied: '/usr/local/share/jupyter'

error as well, from @takluyver 's comment I'd think that the --user option in init would do the trick and install files in ~/.ipython but it's not working, here's the output with and without the --user flag
	(colaboratory)me@bibook ~/D/Python> python -m jupyterdrive drive
	Traceback (most recent call last):
	  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
	    "__main__", fname, loader, pkg_name)
	  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
	    exec code in run_globals
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/jupyterdrive/__main__.py", line 2, in <module>
	    jupyterdrive.main()
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/jupyterdrive/__init__.py", line 96, in main
	    verbose=args.verbose
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/jupyterdrive/__init__.py", line 31, in install
	    nbextensions_dir=path)
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/IPython/html/nbextensions.py", line 176, in install_nbextension
	    ensure_dir_exists(nbext)
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/IPython/utils/path.py", line 588, in ensure_dir_exists
	    os.makedirs(path, mode=mode)
	  File "/Users/me/Development/Python/environments/colaboratory/bin/../lib/python2.7/os.py", line 150, in makedirs
	    makedirs(head, mode)
	  File "/Users/me/Development/Python/environments/colaboratory/bin/../lib/python2.7/os.py", line 157, in makedirs
	    mkdir(name, mode)
	OSError: [Errno 13] Permission denied: '/usr/local/share/jupyter'
	(colaboratory)me@bibook ~/D/Python> python -m jupyterdrive --user drive
	Traceback (most recent call last):
	  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
	    "__main__", fname, loader, pkg_name)
	  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
	    exec code in run_globals
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/jupyterdrive/__main__.py", line 2, in <module>
	    jupyterdrive.main()
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/jupyterdrive/__init__.py", line 96, in main
	    verbose=args.verbose
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/jupyterdrive/__init__.py", line 31, in install
	    nbextensions_dir=path)
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/IPython/html/nbextensions.py", line 176, in install_nbextension
	    ensure_dir_exists(nbext)
	  File "/Users/me/Development/Python/environments/colaboratory/lib/python2.7/site-packages/IPython/utils/path.py", line 588, in ensure_dir_exists
	    os.makedirs(path, mode=mode)
	  File "/Users/me/Development/Python/environments/colaboratory/bin/../lib/python2.7/os.py", line 150, in makedirs
	    makedirs(head, mode)
	  File "/Users/me/Development/Python/environments/colaboratory/bin/../lib/python2.7/os.py", line 157, in makedirs
	    mkdir(name, mode)
	OSError: [Errno 13] Permission denied: '/usr/local/share/jupyter'

In both cases I get a permision denied error for '/usr/local/share/jupyter'.
Did I misunderstood the "pass user=True part that @takluyver suggested?
What's the proper way for an user to install into his home directory?

@KesterTong @Carreau - there's a --user option, but it looks like you don't actually use it when calling install().

I can't remember if I ever used --user.  I may have used --path all along.  Or maybe I just started installing using sudo.  Sorry for the confusion @anddam, it looks like your final command line is close to what I was using at one point.  @takluyver I will investigate the --user option, maybe it once did something and stopped working

I think all the machinery for it is there, you're just missing a user=args.user here: https://github.com/jupyter/jupyter-drive/blob/master/jupyterdrive/init.py#L97

@takluyver you are right.  I created #99 so we remember to fix this.


App adjustments

I want to merge this change because it adds the following:

fixes a bug where undefined would be passed in as domain to iFrame
passes the correct domain to extensions
makes shop.domain.host read only for cloud instances (based on IS_CLOUD_INSTANCE env variable)

PR intended to be tested with API branch: master
Screenshots

Pull Request Checklist

[ ] This code contains UI changes
[x] All visible strings are translated with proper context including data-formatting
[ ] Attributes [data-test-id] are added for new elements
[ ] Changes are mentioned in the changelog
[x] The changes are tested in different browsers and in light/dark mode

Test environment config

API_URI=https://master.staging.saleor.cloud/graphql/

Task linked: SALEOR-4333 Dashboard passes wrong backendHost to iframe App

Task linked: SALEOR-1273 Drop domain configuration from Dashboard


Catch multipart not found

Description
Catching 20403 and continuing when RETS gives us an object not found when going through a multipart object request
GitHub Issues

#148

Coverage increased (+0.2%) to 92.201% when pulling b125dbb7dc095b5de38380c659c4508e41cd0233 on mcrowson:catch_multipart_not_found into 7ae8bafb102852ddbee46683a437cc342ea0d716 on refindlyllc:development.


Don't emit optimization remarks if we don't have a debug location

@swift-ci Please smoke test and merge


inference.exe ERROR

  File "inference.py", line 86, in <module>
  File "utils.py", line 194, in get_hparams_from_file
FileNotFoundError: [Errno 2] No such file or directory: './finetune_speaker.json'
[18808] Failed to execute script 'inference' due to unhandled exception!

先读读README吧，你不放config文件当然打不开

I'm getting a similar issue trying to run a 4.0 voice. The voice run perfectly on SO-VITS-SVC-FORK, but I'm getting a symbols error:
Traceback (most recent call last): File "inference.py", line 90, in AttributeError: 'HParams' object has no attribute 'symbols' [7748] Failed to execute script 'inference' due to unhandled exception!

me too


Add support for project subdirectories

Right now this extension only works if I open the elixir directory as the root directory of the vscode workspace.
It will be helpful to have a configuration setting that allows me to define in which subdirectory the elixir root folder is.
The problem arises when I have to work both at the frontend and backend at the same time.

So, you have a multi-folder workspace? That's weird then, because for me it works, and I added support for this a while ago.
What does your setup look like and what error messages or warnings do you get?

@Pavinati Any updates on this?

I actually stopped to use this extension and now i just launch mix credo from the terminal.
My setup was the following:

A root folder with project files like the CHANGELOG.md, license and similar files
2 sub directories, one for the backend (elixir) one for the frontend (Typescript)
Everything elixir related is in the backed dir, for example the mix file would be in backend/mix.exs
I work on the project by opening the root dir from VS Code (Ctrl + K, Crtl + O by default)

On this setup i was able to get all the warning by running the following commands on the terminal
cd backend
mix credo

But no warnings and no error messages where shown in the VS Code project

Thanks for the info!
I see. I initially thought you'd have two workspace folders instead of only one with two subdirectories.
I belive the issue would also occur in monorepos.
So it would be sufficient to go recursively up to the project root (depending on the openend document) and see if there is any mix.exs that would identify that directory as a mix project.
Will be working on that immediately and let you know as soon as it's fixed if you're interested.

Thank you very much!

@Pavinati I deployed a version 0.8.1 to the VS Code extension store where this bug should be fixed.
Let me know if it works!

So i did update the plugin, but it still doesn't work. The only difference is that now it displays a warning

I didn't expect the credo config to be required so i generated one anyway with the command
mix credo gen.config

but the warning remains

Huh, that's weird. Could you enable the debug mode of the extension?
Either by using the UI or by adding "elixir.credo.enableDebug": true to your settings json.
And then can you have a look at the VS Code Output Panel of the extension and send me a screenshot after opening an elixir file?
Then, I can properly debug and fix the issue.

Enabling the Debug flag doesn't show anything in the Output Panel (nor in other Panels)

You have to select the output channel to view on the right hand side of the panel (where the dropdown Tasks) is displayed. There you need to select Credo (Elixir Linter)

You're right, i actually never changed it. here you go
> .credo.exs file does not exist. Ignoring...

> Retreiving credo information: Executing credo command `/home/pavij/.asdf/shims/mix credo info --format json --verbose` for /home/pavij/seco/clea/backend/lib/clea/apps.ex in directory /home/pavij/seco/clea/backend

> Credo (Elixir Linter) initiated successfully.

> Setting linter issues for document /home/pavij/seco/clea/backend/lib/clea/apps.ex.

i tried to manually launch said command from the terminal and it appears working as intended
pavij@pavij-desktop-pc:~/seco/clea/backend$ /home/pavij/.asdf/shims/mix credo info --format json --verbose /home/pavij/seco/clea/backend/lib/clea/apps.ex
{
  "config": {
    "checks": [
      {
        "name": "Elixir.Credo.Check.Consistency.ExceptionNames",
        "params": {}
      },
...

Thanks for the output! I believe I did not strip the project folder when comparing whether a file should be linted. I assume that everything would work if the configuration option Lint Everything is enabled.

Okay, I published a new version 0.8.2 which (hoppefully 😅) fixes everything.
Can you please confirm?

Ok, installed the 0.8.2 version, now i can see a new command launched
> Retreiving credo information: Executing credo command `/home/pavij/.asdf/shims/mix credo info --format json --verbose` for /home/pavij/seco/clea/backend/lib/clea/apps.ex in directory /home/pavij/seco/clea/backend

> Executing credo command `/home/pavij/.asdf/shims/mix credo --format json --read-from-stdin --config-file .credo.exs` for /home/pavij/seco/clea/backend/lib/clea/apps.ex in directory /home/pavij/seco/clea/backend

> Setting linter issues for document /home/pavij/seco/clea/backend/lib/clea/apps.ex.

That second command never ends thoguh. I guess it's due to the --read-from-stdin flag.
It works with the following command:
/home/pavij/.asdf/shims/mix credo --format json --config-file .credo.exs /home/pavij/seco/clea/backend/lib/clea/apps.ex

or by piping the file into the stdin with bash
cat /home/pavij/seco/clea/backend/lib/clea/apps.ex | /home/pavij/.asdf/shims/mix credo --format json --read-from-stdin --config-file .credo.exs

Are you sure the second command never ends? Because the third line of your output is only shown if the second terminates.
Could you send me your setting for the credo extension (either JSON or Settings UI screenshot would be helpful)?

Could you maybe also test for VS Code  by adding three consecutive blank lines in your apps.ex or somewhere and then save the file?


[event request] Page 398 “Sales Credit Memo Statistics” new event publisher in trigger "OnAfterGetRecord"

Dear ALAppExtensions Team:
we would need a new event publisher in Page 398 “Sales Credit Memo Statistics”, trigger "OnAftergetRecord":
NEW PUBLISHER:
[IntegrationEvent(false, false)]
local procedure OnAfterCalculateAdjProfitLCY(var AdjProfitLCY: Decimal; Rec: Record "Sales Cr.Memo Header")
begin
end;
The parameter AdjProfitLCY is referenced as VAR
The code in trigger "onaftergetrecord " in Page Page 398 “Sales Credit Memo Statistics” would be modified as follows:
OLD CODE:
....
.
.
.
CustLedgEntry.SetCurrentKey("Document No.");
CustLedgEntry.SetRange("Document No.", "No.");
CustLedgEntry.SetRange("Document Type", CustLedgEntry."Document Type"::"Credit Memo");
CustLedgEntry.SetRange("Customer No.", "Bill-to Customer No.");
if CustLedgEntry.FindFirst then
AmountLCY := -CustLedgEntry."Sales (LCY)";
    if AmountLCY <> 0 then
        ProfitPct := Round(100 * ProfitLCY / AmountLCY, 0.1);

    AdjProfitLCY := AmountLCY - TotalAdjCostLCY;
    if AmountLCY <> 0 then
        AdjProfitPct := Round(100 * AdjProfitLCY / AmountLCY, 0.1);

    if Cust.Get("Bill-to Customer No.") then
        Cust.CalcFields("Balance (LCY)")
    else
        Clear(Cust);

.
.
.
.....
NEW CODE:
....
.
.
.
   CustLedgEntry.SetCurrentKey("Document No.");
    CustLedgEntry.SetRange("Document No.", "No.");
    CustLedgEntry.SetRange("Document Type", CustLedgEntry."Document Type"::"Credit Memo");
    CustLedgEntry.SetRange("Customer No.", "Bill-to Customer No.");
    if CustLedgEntry.FindFirst then
        AmountLCY := -CustLedgEntry."Sales (LCY)";

    if AmountLCY <> 0 then
        ProfitPct := Round(100 * ProfitLCY / AmountLCY, 0.1);

    AdjProfitLCY := AmountLCY - TotalAdjCostLCY;

    //start new code
    OnAfterCalculateAdjProfitLCY(AdjProfitLCY, Rec);
//end new code

    if AmountLCY <> 0 then
        AdjProfitPct := Round(100 * AdjProfitLCY / AmountLCY, 0.1);

    if Cust.Get("Bill-to Customer No.") then
        Cust.CalcFields("Balance (LCY)")
    else
        Clear(Cust);

.
.
.
......
Thanks!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Update sidebar - age group

Add the possibility to age an age group filter on the sidebar

Done in f4ad628


Simplify Merge type

Merge type could be simplified. This is the definition of TypeScript's built-in Extract type:
type Extract<T, U> = T extends U ? T : never;

That's why these types are equal
type Test = Extract<'id' | 'name' | 'age', 'id' | 'name'>; // Equals to 'id' | 'name'
type Test2 = 'id' | 'name' // Equals 'id' | 'name'

I have a very vague memory that I wanted to propose this last year, and finally found a counterexample. I'll take a detailed look tomorrow and see if I can recreate it or if I'm mistaken after all :)

@all-contributors please add @kubk for code

Thanks @kubk! Released as 📦<EMAIL_ADDRESS>