<div>                Thanks for the information.<br><br><br>            </div>            <div class="yahoo_quoted" style="margin:10px 0px 0px 0.8ex;border-left:1px solid #ccc;padding-left:1ex;">                        <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">                                <div>                    Le lundi 11 mars 2024 à 21:52:54 UTC+1, Thorsten Glaser <tg@mirbsd.de> a écrit :                </div>                <div><br></div>                <div><br></div>                <div><div dir="ltr">close 1066051<br clear="none">thanks<br clear="none"><br clear="none">Fab Stz dixit:<br clear="none"><br clear="none">>I usually install openjdk-8 from unstable on bookworm.<br clear="none"><br clear="none">This has never been officially supported. I’ve had an entire<br clear="none">discussion around that last month, which I will quote parts<br clear="none">from below, for context.<br clear="none"><br clear="none">>However this is not possible anymore because now it depends on t64 packages.<br clear="none"><br clear="none">Yes, this is to be expected.<br clear="none"><br clear="none">>Would it be possible to still install it on systems without t64 by<br clear="none">>updating the dependencies/build-depends?<br clear="none"><br clear="none">No.<br clear="none"><br clear="none">But (see the background information below) I’ll be making available<br clear="none">openjdk-8 packages built for bookworm in the “wtf-lts” extrepo soon<br clear="none">(with the next upload, which will be done once the t64 transition<br clear="none">has settled, i.e. in some days) if you don’t mind an inofficial repo<br clear="none">(though operated by the same person who uploads the package to Debian<br clear="none">proper so…), although for amd64 and i386 only at the moment, as I lack<br clear="none">hardware to build for other platforms (tell me if you need that).<br clear="none"><br clear="none">The RSS feed for the wtf extrepo will tell you when. You can obtain that<div class="yqt7515532443" id="yqtfd28483"><br clear="none">at </div><a shape="rect" href="http://www.mirbsd.org/~tg/Debs/NEWS.rss" target="_blank">http://www.mirbsd.org/~tg/Debs/NEWS.rss</a> (s/\.rss// for plaintext).<br clear="none"><br clear="none">Quotes, some paraphrased, follow. Cc’ing the relevant bug for archival<br clear="none">and public readability.<br clear="none"><br clear="none">────────────────────────────────────────────────────────────────────────<br clear="none"><br clear="none">OpenJDK 8 is included with Debian 9 (stretch) only, although it has<br clear="none">been retrofitted to Debian 8 (jessie) for ELTS as it still is actively<br clear="none">maintained, in contrast to jessie’s OpenJDK 7.<br clear="none"><br clear="none">Debian 10 and 11 shipped OpenJDK 11, due to misalignment between<br clear="none">Debian’s and OpenJDK-LTS’ release cycles.<br clear="none"><br clear="none">> (why does #989736 to keep OpenJDK out of testing and stable exist?)<br clear="none"><br clear="none">The reason behind it is that every Debian release contains exactly<br clear="none">one, and only one, supported OpenJDK version; the security team does<br clear="none">not have resources for more (unlike commercial distributions, nobody<br clear="none">is paid for their work).<br clear="none"><br clear="none">OpenJDK 8 had already been dropped from Debian, but I’ve resurrected<br clear="none">it and took over maintenance. We still use it in Debian proper for:<br clear="none"><br clear="none">• staging new releases for ELTS (ELTS is not part of Debian proper<br clear="none">  but an external offering, although basically done by the same people)<br clear="none"><br clear="none">• bootstrapping new environments (like Kotlin) that depend on JDK 8<br clear="none">  for their bootstrapping process<br clear="none"><br clear="none">This is all done in “unstable”; Kotlin was only able to enter “testing”<br clear="none">once it met the release goals for the “next-stable”, that is to build<br clear="none">with that then-future release’s default JDK.<br clear="none"><br clear="none">> There are a number of applications still depending on Java 8.<br clear="none"><br clear="none">Most of these should still run with 11 at least, even if they can<br clear="none">only be built on 8 or with special options (I wrote a Maven parent POM<br clear="none">that manages this).<br clear="none"><br clear="none">I know of exceptions that use undocumented/inofficial interfaces that<br clear="none">are not actually part of the JDK’s API. For these, it’s really SOL…<br clear="none"><br clear="none">I personally don’t have a problem with making OpenJDK 8 releases<br clear="none">available for other Debian releases; this is in fact how my involvement<br clear="none">in this started (I did it for a customer but also made the results<br clear="none">publicly available). If you don’t mind external repositories, you can<br clear="none">use the builds from there.<br clear="none"><br clear="none">I recently stopped making builds for Debian 7 (wheezy) even if that<br clear="none">is technically still feasible, because it is no longer supported by<br clear="none">even ELTS.<br clear="none"><br clear="none">Debian 8 and 9 are provided OpenJDK 8 by Freexian ELTS.<br clear="none"><br clear="none">I produce builds for Debian 10 and 11, amd64 and i386 only (I lack<br clear="none">the machines to do more currently).<br clear="none"><br clear="none">I don’t provide these packages for Debian 12 because I do not use<br clear="none">the latter and have no way to test them and can so save time.<br clear="none"><br clear="none">Given incentive (a nice offer) I might add more to this mix.<br clear="none"><br clear="none">I also provide OpenJDK 8 for all *buntu LTS releases that Canonical<br clear="none">allows Launchpad to build for, for all architectures the respective<br clear="none">releases have, via a PPA.<br clear="none"><br clear="none">> (would be convenient to add openjdk-8 to stable)<br clear="none"><br clear="none">Once a Debian stable is released, packages aren’t added to it any<br clear="none">more, barring special cases in LTS/ELTS releases like the aforementioned<br clear="none">switching jessie from OpenJDK 7 to 8, or they all getting newer kernels.<br clear="none"><br clear="none">> (does the bugreport mean it will forever be blocked from making it to stable?)<br clear="none"><br clear="none">Yes, it blocks OpenJDK 8 from ever reaching testing, and a new stable<br clear="none">is made by copying a frozen testing at the point in time where the<br clear="none">release gets made.<br clear="none"><br clear="none">This is, indeed, the purpose of that debbugs item. The “Outlook” and<br clear="none">the first message should have made that clear. (The latter also said<br clear="none">to contact me so all is fine.)<br clear="none"><br clear="none">This is the compromise that allowed OpenJDK 8 to be kept in Debian<br clear="none">at all, i.e. in Debian unstable; otherwise the security team would<br clear="none">have veto’d this. There is no way for OpenJDK 8 to be supported in<br clear="none">a stable Debian release any more.<br clear="none"><br clear="none">That doesn’t mean I desupport this in the package itself. While I<br clear="none">don’t build for or test on wheezy or precise any more, these two<br clear="none">and anything newer, up to the latest respective releases, should<br clear="none">work, and I occasionally do things to make it so. You just have to<br clear="none">obtain them from elsewhere than Debian itself… or, of course, do<br clear="none">the building yourself (there are a couple of files that do need<br clear="none">changing to match the target distribution and release; there is an<br clear="none">automated process for it which has to be manually triggered first<br clear="none">though, as it regenerates metadata; and then you need a proper<br clear="none">clean+minimal cowbuilder or sbuild/buildd environment to build the<br clear="none">actual binary packages).<br clear="none"><br clear="none">────────────────────────────────────────────────────────────────────────<br clear="none"><br clear="none">(There’s also the Debian package extrepo which can automate<br clear="none">the setup of the repository.)<br clear="none"><br clear="none">────────────────────────────────────────────────────────────────────────<br clear="none"><br clear="none">> (is it correct that this is your personal repo where you packaged this<br clear="none">> for a customer but also made it publicly available?)<br clear="none"><br clear="none">Yes and no, it’s a bit more complicated than that. I did the whole<br clear="none">backporting for a customer at $dayjob at first and used a different<br clear="none">repo for the deliverables using the same tools I had already made to<br clear="none">manage my personal repo already. At some point it was ok’d for me to<br clear="none">also provide these packages to the public. Since a few years, that<br clear="none">customer is no longer one due to changes imposed from elsewhere (they<br clear="none">had a specific project with us which they had to get rid of to switch<br clear="none">to Microsoft crap as mandated by another ministry), but I continue<br clear="none">the openjdk-8 builds, partially on company time, as my employer used<br clear="none">to be proud of doing FOSS things. And when openjdk-8 got dropped in<br clear="none">Debian, I took over maintainership and undid the dropping.<br clear="none"><br clear="none">> And possibly this is currently the only publicly<br clear="none">> available Debian repo that contains jdk-8 for Debian 11/12?<br clear="none"><br clear="none">To my knowledge, the only one continuously updated and using “proper”<br clear="none">Debian packaging mechanisms etc.<br clear="none"><br clear="none">> What I did as a final step was pin your repo like this:<br clear="none">><br clear="none">> /etc/apt/preferences.d/99my-custom-repository<br clear="none">> Package: *<br clear="none">> Pin: origin www.mirbsd.org<br clear="none">> Pin-Priority: 1<br clear="none">><br clear="none">> Package: openjdk-8-*<br clear="none">> Pin: origin www.mirbsd.org<br clear="none">> Pin-Priority: 500<br clear="none"><br clear="none">Right. The “lts” component already contains fewer packages than the<br clear="none">“wtf” component in the same repo, only the packages I would also<br clear="none">upload to Debian itself in the very same state (if that would be<br clear="none">acceptable), but if you want only the JDK, that’s fine and less<br clear="none">risky. The full list of packages included in the “lts” list is<br clear="none">semi-stable (changes announced on the RSS) and documented on<br clear="none"><a shape="rect" href="http://www.mirbsd.org/~tg/Debs/sources.txt/2-ltslst.txt" target="_blank">http://www.mirbsd.org/~tg/Debs/sources.txt/2-ltslst.txt</a> as well.<br clear="none">(On which I guess I’ll have to move bookworm to supported again,<br clear="none">although I’ll rely on user testing at least for more than the<br clear="none">tests I do during development.)<br clear="none"><br clear="none">> (the enquirer will help testing)<br clear="none"><br clear="none">Sounds great.<br clear="none"><br clear="none">I’m not currently in a Java project @ $dayjob, so my use (and testing<br clear="none">every time) is rather minimal (a bit of Maven build+test, a bit of<br clear="none">tomcat9 testing, and I use it to run a (oldish) Jenkins instance);<br clear="none">my Debian ELTS contact person also does his own testing, although with<br clear="none">the jessie/stretch builds of course (same source, built in different<br clear="none">environment).<div class="yqt7515532443" id="yqtfd03696"><br clear="none"></div></div></div>            </div>                </div>