Re: jtreg for openjdk-8 in ELTS
Hi! On 02/11/2023 21:24, Thorsten Glaser wrote: Hi ELTS people (mostly pochu, I guess), for openjdk-8 tests, Vladimir tells me we “really” want jtreg5. If it is possible to add a jtreg5 package to jessie and stretch even if it exists nowhere else, perhaps with vendored dependencies where applicable like it is done for jtreg7 in stable now, we can use that. I had started to look at backporting jtreg6, without vendored dependencies. That was a bit painful due to the need of upgrading other packages, which had rdeps. Using vendored deps in this case sounds like a good solution. Not sure whether it will be easier for jtreg5. Vladimir would be able to tell you which dependencies would need to be included, and at which versions, or maybe even help with the package. Any help would be appreciated! libasmtools-java is also needed for fuller coverage but can probably be easily backported. Yeah, since it's is a new package there shouldn't be many issues with introducing that, as it's got no rdeps. Cheers, Emilio
jtreg for openjdk-8 in ELTS
Hi ELTS people (mostly pochu, I guess), for openjdk-8 tests, Vladimir tells me we “really” want jtreg5. If it is possible to add a jtreg5 package to jessie and stretch even if it exists nowhere else, perhaps with vendored dependencies where applicable like it is done for jtreg7 in stable now, we can use that. Vladimir would be able to tell you which dependencies would need to be included, and at which versions, or maybe even help with the package. libasmtools-java is also needed for fuller coverage but can probably be easily backported. bye, //mirabilos -- 18:47⎜ well channels… you see, I see everything in the same window anyway 18:48⎜ i know, you have some kind of telnet with automatic pong 18:48⎜ haha, yes :D 18:49⎜ though that's more tinyirc – sirc is more comfy
Re: Maintainer field of openjdk-8
On 07/07/2023 19:29, Thorsten Glaser wrote: Alioth is no longer maintained, but the old lists.alioth.debian.org addresses have been preserved and should still be used. But not for new things, I understood? Not for new teams, but new packages in existing teams can keep using the same address. Emmanuel Bourg
Re: Maintainer field of openjdk-8
On Fri, 7 Jul 2023, Emmanuel Bourg wrote: > Alioth is no longer maintained, but the old lists.alioth.debian.org addresses > have been preserved and should still be used. But not for new things, I understood? bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: openjdk-8 still needed for bootstrapping?
On 26/06/2023 20:53, Thorsten Glaser wrote: Last time I asked the answer was a vague yes; is this still the case? Nothing has changed, so yes. We just need openjdk-8 in unstable. Emmanuel Bourg
Re: Maintainer field of openjdk-8
On 04/07/2023 20:42, Thorsten Glaser wrote: This is how I understood team-maintained packages to be handled. Especially how else are people supposed to get the bug traffic. debian-java@lists.debian.org is a discussion list, notifications should go to pkg-java-maintain...@lists.alioth.debian.org wnpp bugs are also welcome on debian-java@lists.debian.org I remember that a few years ago, I had put the list as the Maintainer of one of my packages and I was asked to set it to pkg-java-maintain...@lists.alioth.debian.org instead. AIUI Alioth lists are no longer maintained, deprecated and should especially not be used in new places. Alioth is no longer maintained, but the old lists.alioth.debian.org addresses have been preserved and should still be used. Emmanuel Bourg
Re: Maintainer field of openjdk-8
On Tue, 4 Jul 2023, Vincent Prat wrote: > Lately, we have been receiving a significant number of automatic emails > concerning openjdk-8. > This is because this diffusion list is in the Maintainer field of the package. This is how I understoof team-maintained packages to be handled. Especially how else are people supposed to get the bug traffic. > I remember that a few years ago, I had put the list as the Maintainer of one > of > my packages and I was asked to set it to > pkg-java-maintain...@lists.alioth.debian.org instead. AIUI Alioth lists are no longer maintained, deprecated and should especially not be used in new places. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Maintainer field of openjdk-8
Hi, Lately, we have been receiving a significant number of automatic emails concerning openjdk-8. This is because this diffusion list is in the Maintainer field of the package. I remember that a few years ago, I had put the list as the Maintainer of one of my packages and I was asked to set it to pkg-java-maintain...@lists.alioth.debian.org instead. What is the current consensus on the matter? Regards, Vincent Le 03/07/2023 à 00:33, Debian FTP Masters a écrit : openjdk-8_8u382~b04-2_source.changes uploaded successfully to localhost along with the files: openjdk-8_8u382~b04-2.dsc openjdk-8_8u382~b04-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1040181: marked as done (openjdk-8: Please disable tests on zero architectures)
Your message dated Sun, 02 Jul 2023 22:39:05 + with message-id and subject line Bug#1040181: fixed in openjdk-8 8u382~b04-2 has caused the Debian Bug report #1040181, regarding openjdk-8: Please disable tests on zero architectures to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1040181: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040181 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: openjdk-8 Version: 8u382~b04-1 Severity: important Tags: patch X-Debbugs-Cc: Thorsten Glaser Zero is slow, OpenJDK has many tests, and on slower ports architectures the build can literally take a month: https://buildd.debian.org/status/logs.php?pkg=openjdk-8&arch=alpha Please fix this with something like: --- debian/rules.old2023-07-02 21:46:21.815210161 + +++ debian/rules2023-07-02 21:48:21.783102835 + @@ -137,7 +137,7 @@ endif with_check = $(if $(findstring nocheck, $(DEB_BUILD_OPTIONS)),,yes) -ifneq (,$(filter $(DEB_HOST_ARCH), armel)) +ifeq (,$(filter $(DEB_HOST_ARCH), $(hotspot_archs))) with_check = disabled running check on $(DEB_HOST_ARCH) endif ifneq (,$(filter $(distrel),precise)) --- End Message --- --- Begin Message --- Source: openjdk-8 Source-Version: 8u382~b04-2 Done: Thorsten Glaser We believe that the bug you reported is fixed in the latest version of openjdk-8, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1040...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Thorsten Glaser (supplier of updated openjdk-8 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Format: 1.8 Date: Mon, 03 Jul 2023 00:17:03 +0200 Source: openjdk-8 Architecture: source Version: 8u382~b04-2 Distribution: unstable Urgency: medium Maintainer: Java Maintenance Changed-By: Thorsten Glaser Closes: 1040167 1040181 Changes: openjdk-8 (8u382~b04-2) unstable; urgency=medium . * Rewrite codename-based if(n)eqs, so they fail safer (Closes: #1040167) * Maybe fix sparc64 Linux build failure * Do not run check for nōn-Hotspot architectures (Closes: #1040181) Checksums-Sha1: 3d77a63a49d70acb0619bcb01cdcdafdbd0fb159 4562 openjdk-8_8u382~b04-2.dsc 5113855e6b61388404d92ebd29ed8f77430b7428 183088 openjdk-8_8u382~b04-2.debian.tar.xz Checksums-Sha256: 6df5be61263e00296d4f0a0b7a5de4616ed1e1d068e0ebe9069c032cd312190a 4562 openjdk-8_8u382~b04-2.dsc 1619ca90373140fb4eb6daaf93e6037b6d9dbe52e2eb633b62005ae4356b1486 183088 openjdk-8_8u382~b04-2.debian.tar.xz Files: 7284308dc663033b384f4380a998020d 4562 java optional openjdk-8_8u382~b04-2.dsc 972d37000c6179da49b317da0a713f67 183088 java optional openjdk-8_8u382~b04-2.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) iQIcBAEBCQAGBQJkofg5AAoJEHa1NLLpkAfgqsQP/2M+GS9P8f9KPLZYHNrNewKE 0zfejocsvX1PMtqNL2agrfnEifjCfeBGHOrsrNYJB96sHCK9FB7dm5JCsjSFrcrR JaK9oWzzKANHWlxPqD9ETWWJ2z1sFdqbuNcA43/3SnKARYHwAO8a58OpOMOfa6lD Y9QO7KuLwY4V1e+NIMgGoSgZrriod0ekET60mid6d7yDonIE41TgpztG7BYn5giO 4rtUTn2tpsdVFXy7uUV3Ba4Mn9t28+rk52Dab8w+zRCjL5ZoRCK4Nod3vb61wVlO KAaiIUFuV/CtIJ2LjNIJYSBRb7c0uNjDuskDrjHIUFlwKe7E2BSQnBfI8R6PdbOO LvPa8YmjNyCItle+RC26p9h6CoLNYgjg7ejr2QN6yuOp6aNmrVr/PxZEQdwj8kYB gBUMdtmIUPS+5WFScvEzacAJp1X2xEZ3R3GIGKO2yBT/72t2Frw7s4i0uh0rQt0P RnljRiVjLpXBockVzCPuYobtb6ATXgAX3FMjjsXaKeIgspnOFVGEvFdsf4m3vPrF i5+4I4bN95FBvd090rwa5ElDxwGhIE4KpNvKR5b+9fwDQCXvVW7EYi6JckguIXFv 1dCsOpoVF2g0powm5bHpXVXvScgDoVOSrPt2PX9Uae407zjAnce7uj+zlv/oReDK cvdOJLtx9ToF0Oht+u9B =QvgM -END PGP SIGNATURE End Message ---
Bug#1040167: marked as done (openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian)
Your message dated Sun, 02 Jul 2023 22:39:05 + with message-id and subject line Bug#1040167: fixed in openjdk-8 8u382~b04-2 has caused the Debian Bug report #1040167, regarding openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1040167: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040167 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openjdk-8-jre-headless Version: 8u382~b04-1 Severity: important Dear Maintainer, Updating from 8u372-ga-1 which was the previous version in unstable is not possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8 However libjpeg8 is not to be found in Debian Expected behaviour: correct dependencies or adding the missing libjpeg8 to Debian? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (991, 'stable-security'), (991, 'stable'), (990, 'proposed- updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable- updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20230103 ii java-common 0.74 ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libfontconfig12.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s1 12.2.0-14 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-22.14-2 ii libnss3 2:3.87.1-1 ii libpcsclite1 1.9.9-2 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxi62:1.8-1+b1 ii libxrender1 1:0.9.10-1.1 ii libxtst6 2:1.2.3-1.1 ii util-linux2.38.1-5+b1 ii zlib1g1:1.2.13.dfsg-1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-6 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.15.1-3 -- no debconf information --- End Message --- --- Begin Message --- Source: openjdk-8 Source-Version: 8u382~b04-2 Done: Thorsten Glaser We believe that the bug you reported is fixed in the latest version of openjdk-8, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1040...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Thorsten Glaser (supplier of updated openjdk-8 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Format: 1.8 Date: Mon, 03 Jul 2023 00:17:03 +0200 Source: openjdk-8 Architecture: source Version: 8u382~b04-2 Distribution: unstable Urgency: medium Maintainer: Java Maintenance Changed-By: Thorsten Glaser Closes: 1040167 1040181 Changes: openjdk-8 (8u382~b04-2) unstable; urgency=medium . * Rewrite codename-based if(n)eqs, so they fail safer (Closes: #1040167) * Maybe fix sparc64 Linux build failure * Do not run check for nōn-Hotspot architectures (Closes: #1040181) Checksums-Sha1: 3d77a63a49d70acb0619bcb01cdcdafdbd0fb159 4562 openjdk-8_8u382~b04-2.dsc 5113855e6b61388404d92ebd29ed8f77430b7428 183088 openjdk-8_8u382~b04-2.debian.tar.xz Checksums-Sha256: 6df5be61263e00296d4f0a0b7a5de4616ed1e1d068e0ebe9069c032cd312190a 4562 openjdk-8_8u382~b04-2.dsc 1619ca90373140fb4eb6daaf93e6037b6d9dbe52e2eb633b62005ae4356b1486 183088 openjdk-8_8u382~b04-2.debian.tar.xz Files: 7284308dc663033b384f4380a998020d 45
Bug#1040181: openjdk-8: Please disable tests on zero architectures
Source: openjdk-8 Version: 8u382~b04-1 Severity: important Tags: patch X-Debbugs-Cc: Thorsten Glaser Zero is slow, OpenJDK has many tests, and on slower ports architectures the build can literally take a month: https://buildd.debian.org/status/logs.php?pkg=openjdk-8&arch=alpha Please fix this with something like: --- debian/rules.old2023-07-02 21:46:21.815210161 + +++ debian/rules2023-07-02 21:48:21.783102835 + @@ -137,7 +137,7 @@ endif with_check = $(if $(findstring nocheck, $(DEB_BUILD_OPTIONS)),,yes) -ifneq (,$(filter $(DEB_HOST_ARCH), armel)) +ifeq (,$(filter $(DEB_HOST_ARCH), $(hotspot_archs))) with_check = disabled running check on $(DEB_HOST_ARCH) endif ifneq (,$(filter $(distrel),precise))
Bug#1040167: marked as done (openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian)
Your message dated Sun, 02 Jul 2023 21:49:53 + with message-id and subject line Bug#1040167: fixed in openjdk-8 8u382~b04-2~binfix1 has caused the Debian Bug report #1040167, regarding openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1040167: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040167 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openjdk-8-jre-headless Version: 8u382~b04-1 Severity: important Dear Maintainer, Updating from 8u372-ga-1 which was the previous version in unstable is not possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8 However libjpeg8 is not to be found in Debian Expected behaviour: correct dependencies or adding the missing libjpeg8 to Debian? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (991, 'stable-security'), (991, 'stable'), (990, 'proposed- updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable- updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20230103 ii java-common 0.74 ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libfontconfig12.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s1 12.2.0-14 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-22.14-2 ii libnss3 2:3.87.1-1 ii libpcsclite1 1.9.9-2 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxi62:1.8-1+b1 ii libxrender1 1:0.9.10-1.1 ii libxtst6 2:1.2.3-1.1 ii util-linux2.38.1-5+b1 ii zlib1g1:1.2.13.dfsg-1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-6 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.15.1-3 -- no debconf information --- End Message --- --- Begin Message --- Source: openjdk-8 Source-Version: 8u382~b04-2~binfix1 Done: Thorsten Glaser We believe that the bug you reported is fixed in the latest version of openjdk-8, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1040...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Thorsten Glaser (supplier of updated openjdk-8 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Format: 1.8 Date: Sun, 02 Jul 2023 21:41:14 +0200 Source: openjdk-8 Binary: openjdk-8-dbg openjdk-8-demo openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless openjdk-8-jre-zero Architecture: source amd64 arm64 armel armhf i386 ppc64el s390x Version: 8u382~b04-2~binfix1 Distribution: unstable Urgency: medium Maintainer: Thorsten Glaser Changed-By: Thorsten Glaser Closes: 1040167 Description: openjdk-8-dbg - Java runtime based on OpenJDK (debugging symbols) openjdk-8-demo - Java runtime based on OpenJDK (demos and examples) openjdk-8-jdk - OpenJDK Development Kit (JDK) openjdk-8-jdk-headless - OpenJDK Development Kit (JDK) (headless) openjdk-8-jre - OpenJDK Java runtime, using openjdk-8-jre-headless - OpenJDK Java runtime, using (headless) openjdk-8-jre-zero - Alternative JVM for OpenJDK, using Zero Changes: openjdk-8 (8u382~b04-2~binfix1) unstable; urgency=medium . *
[aure...@debian.org: Re: Fwd: (buildd chroot bug) Re: Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian]
I realized that message has been forwarded to *all* buildd maintainers, and I answered there. So let me forward the answer to the bug report. - Message transféré de Aurelien Jarno - From: Aurelien Jarno To: Thorsten Glaser Cc: buildd-maintain...@buildd.debian.org User-Agent: Mutt/2.2.9 (2022-11-12) Date: Sun, 2 Jul 2023 23:02:38 +0200 Subject: Re: Fwd: (buildd chroot bug) Re: Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian Message-ID: [ tl;dr for buildd-maintainers: nothing to do. ] Hi, On 2023-07-02 21:44, Thorsten Glaser wrote: > Hi, > > please check the footnote below. Thanks! > > -- Forwarded message -- > Message-ID: <2d85d8b1-45e2-d6a8-5088-7fd838b7...@tarent.de> > Date: Sun, 2 Jul 2023 20:20:16 +0200 (CEST) > > Dixi quod… > > >Indeed. Weird. > > > >Thanks for reporting, I’ll have two or three looks at it… fixing that > >is going to be… fun. Not. > > OK so first analysis is showing the cause of the problem: > > • the buildd chroots for sid/unstable do not identify themselves as > sid/unstable but instead as trixie/testing, which is a bug onto > itself¹ No the chroots do not identify themselves. I guess you check the output of "lsb_release -a". If you believe the output is not correct, please report the bug to the lsb-release package. > however if the buildd chroot bug could be fixed, I’d be glad. There is nothing to fix on the buildd chroot side, please fix your debian/rules script instead. > ① sid buildd chroots should save the following content… > PRETTY_NAME="Debian GNU/Linux sid" > NAME="Debian GNU/Linux" > ID=debian > HOME_URL="https://www.debian.org/"; > SUPPORT_URL="https://www.debian.org/support"; > BUG_REPORT_URL="https://bugs.debian.org/"; > VERSION_ID=unstable > VERSION_CODENAME=sid > … as /usr/lib/os-release.sid (in the chroot) and run… > # dpkg-divert --rename --divert /usr/lib/os-release.dpkg-dist \ > --add /usr/lib/os-release > # ln -sfT os-release.sid /usr/lib/os-release > … in the chroot, so the reported lsb_release is correct. They used > to have this in /etc/lsb-release, but the lsb-release program no > longer uses that. That's plainly wrong, that's not the job of a buildd to configure that. The chroots are just created using debootstrap --variant=buildd, which is basically a minimal chroot with build-essential. There shouldn't be any further visible configuration to the chroot, as your package is supposed to build the same way on a normal installation outside of a chroot. The functionality you describe should just come by installing additional packages. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net - Fin du message transféré - -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: URGENT: please abort openjdk-8 builds
Hi, On 2023-07-02 20:04, Thorsten Glaser wrote: > Hi, > > we have a situation; could you please abort the openjdk-8 builds > that are not yet finished? I have just killed the build on mipsel and mips64el. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
(buildd chroot bug) Re: Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian
Dixi quod… >Indeed. Weird. > >Thanks for reporting, I’ll have two or three looks at it… fixing that >is going to be… fun. Not. OK so first analysis is showing the cause of the problem: • the buildd chroots for sid/unstable do not identify themselves as sid/unstable but instead as trixie/testing, which is a bug onto itself¹ • the source package checks the buildd release codename and does things based on that; normally, the tests are written in a manner that they fall through to the latest (i.e. they test for known names of older releases for the old behaviour, and use the new behaviour if none of the old release names is used); the code to handle the long ago libjpeg62→libjpeg8→libjpeg62-turbo transition however was written the other way round, which causes trouble if the new release is unknown I’ll fix that in the source, but first I need to get the situation fixed as openjdk-8 build-depends on itself, which will be bad if it’s not installable. I’m going to change all uses of the distro codename to fall safely, however if the buildd chroot bug could be fixed, I’d be glad. bye, //mirabilos ① sid buildd chroots should save the following content… PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; VERSION_ID=unstable VERSION_CODENAME=sid … as /usr/lib/os-release.sid (in the chroot) and run… # dpkg-divert --rename --divert /usr/lib/os-release.dpkg-dist \ --add /usr/lib/os-release # ln -sfT os-release.sid /usr/lib/os-release … in the chroot, so the reported lsb_release is correct. They used to have this in /etc/lsb-release, but the lsb-release program no longer uses that. -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
URGENT: please abort openjdk-8 builds
Hi, we have a situation; could you please abort the openjdk-8 builds that are not yet finished? Thanks! -- Forwarded message -- From: Fab Stz Message-ID: <22218593.EfDdHjke4D@debian> Resent-From: Fab Stz To: Debian Bug Tracking System Resent-To: debian-bugs-d...@lists.debian.org Resent-cc: Java Maintenance Date: Sun, 02 Jul 2023 19:23:35 +0200 Resent-Date: Sun, 02 Jul 2023 17:27:02 + Subject: Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian X-Spam-Status: No, score=2.2 required=4.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FOURLA,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,FVGT_m_MULTI_ODD,HEADER_FROM_DIFFERENT_DOMAINS, NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,SHIP_ID_INT,SPOOFED_FREEMAIL, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 Package: openjdk-8-jre-headless Version: 8u382~b04-1 Severity: important Dear Maintainer, Updating from 8u372-ga-1 which was the previous version in unstable is not possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8 However libjpeg8 is not to be found in Debian Expected behaviour: correct dependencies or adding the missing libjpeg8 to Debian? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (991, 'stable-security'), (991, 'stable'), (990, 'proposed- updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable- updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20230103 ii java-common 0.74 ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libfontconfig12.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s1 12.2.0-14 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-22.14-2 ii libnss3 2:3.87.1-1 ii libpcsclite1 1.9.9-2 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxi62:1.8-1+b1 ii libxrender1 1:0.9.10-1.1 ii libxtst6 2:1.2.3-1.1 ii util-linux 2.38.1-5+b1 ii zlib1g1:1.2.13.dfsg-1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-6 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.15.1-3 -- no debconf information
Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian
On Sun, 2 Jul 2023, Fab Stz wrote: >Updating from 8u372-ga-1 which was the previous version in unstable is not >possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8 WTF‽ *checks* Indeed. Weird. Thanks for reporting, I’ll have two or three looks at it… fixing that is going to be… fun. Not. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian
Package: openjdk-8-jre-headless Version: 8u382~b04-1 Severity: important Dear Maintainer, Updating from 8u372-ga-1 which was the previous version in unstable is not possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8 However libjpeg8 is not to be found in Debian Expected behaviour: correct dependencies or adding the missing libjpeg8 to Debian? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (991, 'stable-security'), (991, 'stable'), (990, 'proposed- updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable- updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20230103 ii java-common 0.74 ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libfontconfig12.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s1 12.2.0-14 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-22.14-2 ii libnss3 2:3.87.1-1 ii libpcsclite1 1.9.9-2 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxi62:1.8-1+b1 ii libxrender1 1:0.9.10-1.1 ii libxtst6 2:1.2.3-1.1 ii util-linux2.38.1-5+b1 ii zlib1g1:1.2.13.dfsg-1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-6 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.15.1-3 -- no debconf information
openjdk-8 still needed for bootstrapping?
Hi, apparently there’s again the question whether we still need openjdk-8 in sid for bootstrapping JVM-based languages and/or utilities. This is independent of the question whehter it should be there to ease backports or because people might otherwise turn to Canonical’s commercial offer or whether it can be supported in sid with not too high effort (given it’s maintained with an active upstream, I’d say yes). Last time I asked the answer was a vague yes; is this still the case? Thanks in advance, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Processed: Re: Bug#1035340: latest openjdk-8-jdk version 8u372-b07 is not available
Processing commands for cont...@bugs.debian.org: > close 1035340 Bug #1035340 [openjdk-8-jdk] latest openjdk-8-jdk version 8u372-b07 is not available Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1035340: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035340 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1035340: latest openjdk-8-jdk version 8u372-b07 is not available
package: openjdk-8-jdk version: latest When I invoke `apt-get update && apt-get install openjdk-8-jdk` it is installing an older version of jdk-8 which is 8u362-b09. Jdk version 8u372-b07 is not getting installed while running the `apt-get install openjdk-8-jdk` even after running the `apt-get update` command. It should always fetch the latest package available. I an using ubuntu 22.04 Thanks, Pawan
jtreg 7 vs. jtreg6 vs. testng vs. openjdk-8 (was Re: OpenJDK package - JTREG 7.1)
Hi Vladimir, >Sorry for the late reply, but I have realized that there might be an >issue with adopting jtreg6 for Java 8 testing. > >Jtreg 6 requires testng 7.3[1] and Jtreg 5 uses 6.9.5[2]. The current >jtreg6 package uses 6.9.5 making it suitable for Java 8 testing but >not so much for 11 and up. If testng is upgraded to 7.5 it will be >still binary compatible, but there will be new regressions due to API OK, good to know. However, let’s translate this, thinking in upstream versions/dependencies, to Debian now. Debian has testng 6.9.12 in “all” releases (jessie-backports and up). src:openjdk-8 testing works with that, so we can use this for the jessie and stretch ELTS uploads. As long as pochu doesn’t update testng in either, we’re fine, jtreg6 or not. When testng 7.3 will be uploaded to Debian (not before the release of bookworm), then openjdk-8 in sid should either use jtreg 5 (which doesn’t mix with Emmanuel’s plans to update jtreg to 7) or will have extra test failures in trixie/sid. The jtreg update hasn’t happened yet, and also will not occur before the bookworm release, so there’s ample time to consider this. Honestly, openjdk-8 isn’t officially part of trixie (although people may very well build it for it) and the sid one is not “officially supported”, the jessie/stretch ELTS builds are our primary deliverables, so I can live with the extra test failures in sid (as long as they still run at all). As for *buntu, they seem to be hiding the openjdk-8 updates in paid-for subscriptions so I can ignore what they do, anyway. stretch-ELTS is EOL on 2027-06-30 so we need to somehow be able to keep openjdk-8 around and supported-ish until then, but if it doesn’t become possible in sid any more, it’ll end up being an ELTS-only problem. I don’t know whether there are any more bootstrapping things that could benefit from openjdk-8 in sid currently or planned. However once it’s gone it’s very unlikelt it’s possible to bring it back again any more, especially should the target class version be bumped. I’m not sure for how long -target/-release 8 will be state of the art in either Debian or otherwhere (Maven Central), but it seems to be very long-lived. (We have customers still using it as JRE so I check whether things work on it, except I’m not currently in a Java project at work.) bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: Kotlin and OpenJDK 8 in Bookworm?
Emmanuel Bourg: Le 2023-02-13 16:38, Hans-Christoph Steiner a écrit : android-framework-23 is in bullseye. So I doublechecked, it is actually just a conflict with JDK17, due to the removal of com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that though. I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567 Another solution, maybe simpler: package the com.sun.javadoc API in a standalone package, independent from openjdk-8 Sounds totally reasonable. But I have no idea how to start on that. Would it be something like just copying some .java files into the doclava source package? .hc
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-02-13 16:38, Hans-Christoph Steiner a écrit : android-framework-23 is in bullseye. So I doublechecked, it is actually just a conflict with JDK17, due to the removal of com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that though. I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567 Another solution, maybe simpler: package the com.sun.javadoc API in a standalone package, independent from openjdk-8 Emmanuel Bourg
Re: Kotlin and OpenJDK 8 in Bookworm?
Hans-Christoph Steiner: Thorsten Glaser: On Mon, 13 Feb 2023, Hans-Christoph Steiner wrote: Great work there! I would still love to see openjdk-8 in bookworm. That ship has sailed yesterday. No new entries into testing are now possible any more. Damn, that might mean a lot of Android packages are not going to be in bookworm. We're in a very similar boat as Kotlin/Gradle, with upstream still building things with JDK8. We have piles of time-consuming hacks to keep things going. We're going to loose a bunch of Android things because doclava cannot run newer JDKs. Upstream still uses JDK8 to build it in the current Android code. You mean you lost these after stretch when openjdk-8 was not shipped with buster any more, of course. android-framework-23 is in bullseye. So I doublechecked, it is actually just a conflict with JDK17, due to the removal of com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that though. I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567 .hc I dug a bit more: yes, some Android packages will not be in bookworm, but looks like the most important ones will not be affected by android-framework-23 being removed. I think some of the other team members reduced the reliance on that package recently, which I wasn't aware of. .hc
Re: Kotlin and OpenJDK 8 in Bookworm?
Thorsten Glaser: On Mon, 13 Feb 2023, Hans-Christoph Steiner wrote: Great work there! I would still love to see openjdk-8 in bookworm. That ship has sailed yesterday. No new entries into testing are now possible any more. Damn, that might mean a lot of Android packages are not going to be in bookworm. We're in a very similar boat as Kotlin/Gradle, with upstream still building things with JDK8. We have piles of time-consuming hacks to keep things going. We're going to loose a bunch of Android things because doclava cannot run newer JDKs. Upstream still uses JDK8 to build it in the current Android code. You mean you lost these after stretch when openjdk-8 was not shipped with buster any more, of course. android-framework-23 is in bullseye. So I doublechecked, it is actually just a conflict with JDK17, due to the removal of com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that though. I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567 .hc
Re: Kotlin and OpenJDK 8 in Bookworm?
On Mon, 13 Feb 2023, Hans-Christoph Steiner wrote: > Great work there! I would still love to see openjdk-8 in bookworm. That ship has sailed yesterday. No new entries into testing are now possible any more. > We're > going to loose a bunch of Android things because doclava cannot run newer > JDKs. > Upstream still uses JDK8 to build it in the current Android code. You mean you lost these after stretch when openjdk-8 was not shipped with buster any more, of course. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: Kotlin and OpenJDK 8 in Bookworm?
Markus Koschany: Am Mittwoch, dem 01.02.2023 um 12:24 +0100 schrieb Emmanuel Bourg: Le 2023-01-26 17:17, Emmanuel Bourg a écrit : I've been working on Kotlin lately, trying to make it build with OpenJDK 17 only, and hopefully have it included in Bookworm. Long story short, after days banging my head on this issue, I don't think it's possible. I take that back, kotlin now builds with OpenJDK 17 and is on track to migrate to testing. This comes at a price though, besides my sanity I had the sacrifice the Android support (the Android dependencies still build with OpenJDK 8) and the -Xuse-javac option which hasn't been updated for OpenJDK 17 yet [1]. That sounds awesome. Well done! Great work there! I would still love to see openjdk-8 in bookworm. We're going to loose a bunch of Android things because doclava cannot run newer JDKs. Upstream still uses JDK8 to build it in the current Android code. I think we have a clear case for the security team, since not only has upstream pledged support for the entire time window we need, but multiple distros as well. The solution I think is to upgrade Gradle to the first version with the Kotlin DSL source code merged, which is Gradle 5.3. I leave that to someone else. Gradle 6.x works with the old Kotlin version and also builds gradle-kotlin-dsl just fine. Let me tie up the loose ends together next week and then let's see how it goes. Thanks for keeping this moving, it is the best news I've heard in a while. I'm not sure how I can best support this effort, but please ping me if you need me to jump in anywhere. .hc
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-02-10 18:07, Thorsten Glaser a écrit : The MIPS buildds are at it currently and expected to finish soon, in case you still want to go forward. It’s close to soft freeze. It's still building but that's fine, we won't need openjdk-8 for kotlin, the beast has been tamed. Emmanuel Bourg
Re: Kotlin and OpenJDK 8 in Bookworm?
Dixi quod… >On Mon, 30 Jan 2023, Emmanuel Bourg wrote: >> I suggest that we let openjdk-8 transition to testing now before the >> beginning of the soft freeze, just to keep our options open. […] >then, if we indeed can keep the options open. The MIPS buildds are at it currently and expected to finish soon, in case you still want to go forward. It’s close to soft freeze. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: Kotlin and OpenJDK 8 in Bookworm?
Am Mittwoch, dem 01.02.2023 um 12:24 +0100 schrieb Emmanuel Bourg: > Le 2023-01-26 17:17, Emmanuel Bourg a écrit : > > > I've been working on Kotlin lately, trying to make it build with > > OpenJDK 17 > > only, and hopefully have it included in Bookworm. > > > > Long story short, after days banging my head on this issue, I don't > > think > > it's possible. > > I take that back, kotlin now builds with OpenJDK 17 and is on track to > migrate to testing. > > This comes at a price though, besides my sanity I had the sacrifice the > Android support (the Android dependencies still build with OpenJDK 8) > and > the -Xuse-javac option which hasn't been updated for OpenJDK 17 yet [1]. That sounds awesome. Well done! > The solution I think is to upgrade Gradle to the first version with the > Kotlin DSL source code merged, which is Gradle 5.3. I leave that to > someone > else. Gradle 6.x works with the old Kotlin version and also builds gradle-kotlin-dsl just fine. Let me tie up the loose ends together next week and then let's see how it goes. Markus signature.asc Description: This is a digitally signed message part
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-01-26 17:17, Emmanuel Bourg a écrit : I've been working on Kotlin lately, trying to make it build with OpenJDK 17 only, and hopefully have it included in Bookworm. Long story short, after days banging my head on this issue, I don't think it's possible. I take that back, kotlin now builds with OpenJDK 17 and is on track to migrate to testing. This comes at a price though, besides my sanity I had the sacrifice the Android support (the Android dependencies still build with OpenJDK 8) and the -Xuse-javac option which hasn't been updated for OpenJDK 17 yet [1]. It isn't extensively tested yet but the resulting package is good enough to rebuild itself. The next hurdle is to enable the Kotlin DSL in Gradle. I've packaged the version of gradle-kotlin-dsl that came with Gradle 4.4 but it doesn't work. When Gradle encounters a .kts file an obscure error is thrown (NoDescriptorForDeclarationException: Descriptor wasn't found for declaration SCRIPT). I have no idea how to fix this, and I now think this is a dead end anyway. gradle-kotlin-dsl uses internal Gradle APIs that changed in Gradle 5, so if we use the Kotlin syntax to upgrade Gradle, it'll break immediately and we'll be unable to rebuild Gradle. The solution I think is to upgrade Gradle to the first version with the Kotlin DSL source code merged, which is Gradle 5.3. I leave that to someone else. Emmanuel Bourg [1] https://youtrack.jetbrains.com/issue/KT-56235
Re: Kotlin and OpenJDK 8 in Bookworm?
On Mon, 30 Jan 2023, Emmanuel Bourg wrote: > Le 2023-01-26 19:39, Thorsten Glaser a écrit : > >>> ineluctable truth: we need OpenJDK 8 back into the stable distribution. >> >> Not going to happen, sorry. This has been vetoed by the security >> team and was the condition for keeping it in unstable at all. > > Are you opposed to this idea, or just pessimistic it could be accepted? Pessimistic. It is currently manageable to upgrade in sid and the jessie and stretch updates in ELTS are trivial. I personally also build it for wheezy and (on user request) buster, bullseye, and on a PPA for trusty/xenial/bionic/focal/jammy, so it works. I can only mildly test it, though. > I think it's important to highlight that the situation has evolved. We > thought openjdk-8 was good enough in unstable only to bootstrap Kotlin > and then move to a more recent JDK, but this isn't going to happen. Any proposal to keep openjdk-8 will want to know for how long this isn’t going to happen, i.e. at what point Kotlin &c. are expected to work with default-jdk. > Also there was an uncertainty on the lifetime of OpenJDK 8, but it's > clear now that it'll be maintained for at least two more Debian > releases. Oh, indeed? I haven’t seen the plan, but if that is so, this may be a good data point. On the other hand, the security team will not be liking having more than one implementation of something to support. Yes, documenting its unsupportedness is one thing, but if it exists… > We have invested an insane amount of time in these Kotlin/Gradle OK, I understand the frustration. > maintaining openjdk-8 in stable would require only a fraction of that. (Not to mention that it is currently I who’s maintaining that, and the ELTS people do the actual work of writing the DSA/DLAs and uploading to -security. But I’m okay with this as long as I’m not expected to upload a new version on basically the same day as its release; I took a bit longer for the 2023Q1 update due to other work-relared things having priority, but I normally do it within the week or so. On the other hand, I’m currently in the position of being able to do most of that on company time, and I’m not sure how much I want to continue this when that will no longer be true.) > The longer we wait, the more likely we are going to paint ourself in a > corner, with a completely broken and unmaintainable Gradle for What’s the status of Gradle then? I thought it required Kotlin, and we have Kotlin now, so isn’t it already using that? > example, or other elements in our tool chain that will no longer work > with OpenJDK 8 and break even more the kotlin build. To be honest, I expected that point to happen within the preceding two years already. I know I could not build Maven projects with < 11 (but targetting 8 from 11 works well now, and some of the bugs were building accidents on the Maven plugin developers’ side). > We still have some time to discuss this before the Bookworm release. Do we? We’re in the first part of the freeze already. > I suggest that we let openjdk-8 transition to testing now before the > beginning of the soft freeze, just to keep our options open. I’d like to have at least one person from the stable release managers “sign off” on that beforehand, also because it is the package maintainer who is going to be blamed. Not necessarily as a for-the-team decision, just so that at least someone is informed; the team can decide later then, if we indeed can keep the options open. > We won't expand the usage of kotlin during that time (no Gradle > upgrade for example) such that the situation remains reversible before > the release. Sounds like a plan. I’d appreciate if you could distill from this thread what has been said and contact the SRM. Once we have at least one nōn-veto response you can close #989736 so it will migrate so we have options open. It was freshly uploaded today anyway, so it’ll take some time. As a caveat, one of the MIPS platforms FTBFS’d with the previous release (they all are currently still in Needs-Build for this one). https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015730.html is where I informed upstream about this, but I don’t know if someone has even looked at that. We’ll want to have this running on at least all release architectures if we go forward with this. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-01-26 19:39, Thorsten Glaser a écrit : ineluctable truth: we need OpenJDK 8 back into the stable distribution. Not going to happen, sorry. This has been vetoed by the security team and was the condition for keeping it in unstable at all. Are you opposed to this idea, or just pessimistic it could be accepted? I think it's important to highlight that the situation has evolved. We thought openjdk-8 was good enough in unstable only to bootstrap Kotlin and then move to a more recent JDK, but this isn't going to happen. Also there was an uncertainty on the lifetime of OpenJDK 8, but it's clear now that it'll be maintained for at least two more Debian releases. We have invested an insane amount of time in these Kotlin/Gradle issues, maintaining openjdk-8 in stable would require only a fraction of that. The longer we wait, the more likely we are going to paint ourself in a corner, with a completely broken and unmaintainable Gradle for example, or other elements in our tool chain that will no longer work with OpenJDK 8 and break even more the kotlin build. We still have some time to discuss this before the Bookworm release. I suggest that we let openjdk-8 transition to testing now before the beginning of the soft freeze, just to keep our options open. We won't expand the usage of kotlin during that time (no Gradle upgrade for example) such that the situation remains reversible before the release. Emmanuel Bourg
Re: Kotlin and OpenJDK 8 in Bookworm?
On Thu, 26 Jan 2023, Emmanuel Bourg wrote: > ineluctable truth: we need OpenJDK 8 back into the stable distribution. Not going to happen, sorry. This has been vetoed by the security team and was the condition for keeping it in unstable at all. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: Kotlin and OpenJDK 8 in Bookworm?
Hi Emmanuel, Am Donnerstag, dem 26.01.2023 um 17:17 +0100 schrieb Emmanuel Bourg: > Hi all, > > I've been working on Kotlin lately, trying to make it build with OpenJDK > 17 > only, and hopefully have it included in Bookworm. > > Long story short, after days banging my head on this issue, I don't > think > it's possible. [...] I have come to the same conclusion. Your recent commitment to make this all work with OpenJDK 17 gave me hope but it shouldn't be I guess. > > How do you feel about allowing openjdk-8 in testing/bookworm with a > clear > mention in the release notes that it's only there for technical reasons > and > we make no commitment about its support? I think this is the only possible solution at the moment. We make it clear that openjdk-8 is not supported in any way and will not receive any security updates. We probably need to update the package description and should mention this clearly in the release notes too. In that case I don't see any objections from neither the release or security team. Regards, Markus signature.asc Description: This is a digitally signed message part
Kotlin and OpenJDK 8 in Bookworm?
Hi all, I've been working on Kotlin lately, trying to make it build with OpenJDK 17 only, and hopefully have it included in Bookworm. Long story short, after days banging my head on this issue, I don't think it's possible. The latest upstream version, Kotlin 1.8.0, released last month, still expects OpenJDK 6 and 7 to build! It doesn't look like Kotlin is anywhere near being buildable with a modern JDK. For example, the Kotlin compiler imports classes from the com.sun.tools package which is no longer exported since OpenJDK 9, and it doesn't seem possible to set the --add-exports options to let the Kotlin compiler access them. Kotlin has become, for the better or worse, a central piece of the Java ecosystem, mostly due to its adoption by Gradle and Android. We see an increasing number of project using Gradle with the Kotlin DSL and they are difficult to maintain. We basically have to rewrite the build system, either translating the Kotlin build files into Groovy (as was done for bootstrapping Kotlin, and for the Gradle 6 packaging attempts) or replacing them with something different (the junit5 package now uses Maven). This is extremely tedious and error prone. We can continue struggling like this for a few more years (the Kotlin packaging effort started 3 years ago already), or we can accept the ineluctable truth: we need OpenJDK 8 back into the stable distribution. Looking around, Ubuntu kept shipping the openjdk-8 package in its latest 22.04 LTS [1], Red Hat still includes it and even pushed back the EOL date by 6 months, from May 2026 to November 2026 [2]. Temurin is also aligned on November 2026 [3]. Azul [4] and Oracle [5] will support OpenJDK until 2030. So should Debian include OpenJDK 8 back, we can expect it to be supported by the Java community for the lifetime of Bookworm. How do you feel about allowing openjdk-8 in testing/bookworm with a clear mention in the release notes that it's only there for technical reasons and we make no commitment about its support? Emmanuel Bourg [1] https://packages.ubuntu.com/source/kinetic/openjdk-8 [2] https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions [3] https://adoptium.net/support/ [4] https://www.azul.com/products/azul-support-roadmap/ [5] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Re: OpenJDK 8
Hi Thomas, > since Java 8 Update 341 is the default on java.com I think it should be in the > Debian repo. there’s 8u342-b07-1 (which corresponds to 8u345-ga) in Debian, but *only* for jessie and stretch ELTS, and (totally unsupported) in unstable. java.*com* has no bearing on Debian. Debian has released with OpenJDK 11 since 2019 (buster, bullseye), and the next release will instead come with OpenJDK 17 as Debian tracks the LTS releases. It is not feasible to officially support more than one Java release per Debian release, considering the effort (including testing, QA, etc.) and manpower (volunteered) needed. Note it is possible to install multiple JDKs/JREs on Debian, but having more than one at the same time w̲i̲l̲l̲ eventually cause problems (speaking from experience here…). Similarily, while you *can* install a nōn-default JDK/JRE on Debian (e.g. 17 on bullseye, or my wtf-lts 8 packages on wheezy, buster or bullseye) those releases’ Debian packages of Java software will not be ready for it because they’re built with the target release’s supported environment in mind and likely won’t cleanly work with older JREs (e.g. newer class versions) and break from newer JREs’ incompatible changes. So these options are mostly for users running their own software. To be honest here, if you still use JDK 8 in this day and age, you probably might want to look into t̲h̲a̲t̲ instead ☺ bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: OpenJDK 8
On Wed, Sep 28, 2022 at 01:30:02PM +, Thomas Vatter wrote: > Am 28.09.22 um 10:22 schrieb Phil Morrell: > > On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote: > > > a complete OpenJDK 8 is missing in the repo. There is only a server VM. > > > > Hi Thomas, > > > Hi Phil, Hello Mailinglist, > > OpenJDK 8 LTS has not been included in Debian since stretch which as of > > June 30th is no longer supported by LTS team. Please update to v11 LTS > > from Debian buster or bullseye and be ready to use v17 LTS going > > forward. Alternatively, if absolutely necessary, you can reach outside > > Debian with `extrepo enable wtf-lts` to get unofficial packages by the > > same maintainer. > > > since Java 8 Update 341 is the default on java.com I think it should be in > the Debian repo. Bend those "I think ... should ..." into "What is needed"-questions. Groeten Geert Stappers P.S. Some failed self censoring, a.k.a. old fashion F.U.D. Fear Uncertainty and Doubt: What is a recent example of Oracle understanding there is libre software? -- Silence is hard to parse
Re: OpenJDK 8
Hi Phil, since Java 8 Update 341 is the default on java.com I think it should be in the Debian repo. Thomas Am 28.09.22 um 10:22 schrieb Phil Morrell: On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote: a complete OpenJDK 8 is missing in the repo. There is only a server VM. Hi Thomas, OpenJDK 8 LTS has not been included in Debian since stretch which as of June 30th is no longer supported by LTS team. Please update to v11 LTS from Debian buster or bullseye and be ready to use v17 LTS going forward. Alternatively, if absolutely necessary, you can reach outside Debian with `extrepo enable wtf-lts` to get unofficial packages by the same maintainer. -- emorrp1
Re: OpenJDK 8
Hi Phil, > On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote: > > a complete OpenJDK 8 is missing in the repo. There is only a server VM. > OpenJDK 8 LTS has not been included in Debian since stretch which as of it’s in sid, though… mostly to help boostrap Kotlin and things, and to prepare jessie and stretch updates. I think what he meant is that the client VM is not included, which is true, except on armhf, which only has the client VM but not the server VM (not ported). As far as I can tell, this has always been the case since 2008, with the exception of arm64 having both for a while. Tiago or Doko might know more. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: OpenJDK 8
On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote: > a complete OpenJDK 8 is missing in the repo. There is only a server VM. Hi Thomas, OpenJDK 8 LTS has not been included in Debian since stretch which as of June 30th is no longer supported by LTS team. Please update to v11 LTS from Debian buster or bullseye and be ready to use v17 LTS going forward. Alternatively, if absolutely necessary, you can reach outside Debian with `extrepo enable wtf-lts` to get unofficial packages by the same maintainer. -- emorrp1 signature.asc Description: PGP signature
OpenJDK 8
Hello, a complete OpenJDK 8 is missing in the repo. There is only a server VM. best regards Thomas Vatter Self-Employed Software-Developer Network-Inventory Software Tel. 030-79782510 Fax 030-79782512
Processed: openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies
Processing commands for cont...@bugs.debian.org: > close 896907 Bug #896907 [openjdk-8-jre-headless] openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 896907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896907 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#896907: openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies
close 896907 thanks Hi, closing as the requested moreinfo was not provided in the last ~year and we’re moving toward 17 as supported JDK/JRE. bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#896907: marked as done (openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies)
Your message dated Mon, 28 Mar 2022 15:42:28 +0100 with message-id and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #896907, regarding openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 896907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896907 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openjdk-8-jre-headless Version: 8u162-b12-1~deb9u1 Severity: normal Dear Maintainer, The openjdk-8-jre-headless package intentionally excludes user interface related components, but the package mistakenly enables Java assistive technologies which require user interface components. Java assistive technologies should be disabled in the *-headless package so that components do not mistakenly believe assistive technologies might work. The Jenkins jenkins/jenkins:slim image is based on the openjdk:slim image. The OpenJDK slim image packages openjdk-8-jre-headless. The Docker image description says: openjdk:slim This image installs the -headless package of OpenJDK and so is missing many of the UI-related Java libraries and some common packages contained in the default tag. It only contains the minimal packages needed to run Java. Unless you are working in an environment where only the openjdk image will be deployed and you have space constraints, we highly recommend using the default image of this repository. While using Jenkins based on the jenkins/jenkins:slim image, charts and graphs are not drawn because JFreeChart fails to initialize. JFreeChart fails to initialize because Java assistive technologies are enabled, but not installed. Disabling Java assistive technologies allows Jenkins to show charts and graphs when hosted on the jenkins/jenkins:slim image. Refer to https://github.com/jenkinsci/docker/pull/657 for the pull request to the Jenkins Docker image which resolves the problem by disabling Java assistive technologies. Refer to https://github.com/docker-library/openjdk/pull/189 for the openjdk pull request which resolves the problem by disabling Java assistive technologies. Those two pull requests should be removed once the upstream packaging is corrected to not enable Java assistive technologies when running openjdk-8-jre-headless. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20170531+nmu1 ii java-common 0.58 ii libc6 2.24-11+deb9u3 ii libcups2 2.2.1-8+deb9u1 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libjpeg62-turbo 1:1.5.1-2 ii liblcms2-22.8-4 ii libnss3 2:3.26.2-1.1+deb9u1 ii libpcsclite1 1.8.20-1 ii libstdc++66.3.0-18+deb9u1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.9-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii util-linux2.29.2-1+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-1 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.10-8 -- no debconf information --- End Message --- --- Begin Message --- *Avez-vous besoin de financement? Avez-vous besoin d'un prêt pour des besoins professionnels ou personnels? Nous proposons tous les types de prêts aux particuliers ou aux entreprises, quel que soit votre pointage de crédit actuel. Pour plus d'informations, n'hésitez pas à nous contacter par e-mail : guarantycreditlo...@aol.com pour plus d'informations.* *Merci pour votre temps, nous nous réjouissons d'accorder votre crédit en ligne.* *COPYRIGHT 2022 (R).* --- End Message ---
Bug#760982: marked as done (openjdk-8 needs time zone data)
Your message dated Mon, 28 Mar 2022 15:42:20 +0100 with message-id and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #760982, regarding openjdk-8 needs time zone data to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 760982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760982 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:openjdk-8 Version: 8u40~b04-2 Severity: serious Tags: sid jessie https://lists.debian.org/debian-java/2014/08/msg00017.html 5. Implement a java.time.zone.ZoneRulesProvider [3] that reads the TZif2 files installed by the tzdata package in /usr/share/zoneinfo. This would render the tzdata-java package obsolete in the long term. GNU ClassPath has a TZif2 parser [4] that could be used as a starting point. [4] https://github.com/jatovm/classpath/blob/master/gnu/java/util/ZoneInfo.java --- End Message --- --- Begin Message --- *Avez-vous besoin de financement? Avez-vous besoin d'un prêt pour des besoins professionnels ou personnels? Nous proposons tous les types de prêts aux particuliers ou aux entreprises, quel que soit votre pointage de crédit actuel. Pour plus d'informations, n'hésitez pas à nous contacter par e-mail : guarantycreditlo...@aol.com pour plus d'informations.* *Merci pour votre temps, nous nous réjouissons d'accorder votre crédit en ligne.* *COPYRIGHT 2022 (R).* --- End Message ---
Bug#819785: marked as done (openjdk-8-jre-headless: Debug information missing in JRE jars)
Your message dated Mon, 28 Mar 2022 15:42:28 +0100 with message-id and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #819785, regarding openjdk-8-jre-headless: Debug information missing in JRE jars to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 819785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819785 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openjdk-8-jre-headless Version: 8u77-b03-3 Severity: important Dear Maintainer, I have just discovered that stepping into JRE classes with a debugger does not allow inspecting variable states, the debugger complains that classes are built without "-g" option. I cannot confirm when this started - I only debug into system classes occasionally. However, for me, absense of this information strongly limits the ability to seriously develop java code with this package. javap -l shows some information but it does not show the variable tables. My best guess is, that classes were compiled with "-g:lines" instead of "-g" or -g:lines,vars" I'm using Netbeans 8.1 debugger. TIA. Chris. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20160321 ii java-common 0.57 ii libc6 2.22-5 ii libcups2 2.1.3-5 ii libfontconfig12.11.0-6.4 ii libfreetype6 2.6.3-3 ii libgcc1 1:5.3.1-13 ii libjpeg62-turbo 1:1.4.2-2 ii liblcms2-22.6-3+b3 ii libnss3 2:3.23-1 ii libpcsclite1 1.8.16-1 ii libstdc++65.3.1-13 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxi62:1.7.6-1 ii libxrender1 1:0.9.9-2 ii libxtst6 2:1.2.2-1+b1 ii multiarch-support 2.22-5 ii util-linux 2.27.1-6 ii zlib1g1:1.2.8.dfsg-2+b1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra 2.35-1 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho ii libnss-mdns0.10-7 pn openjdk-8-jre-jamvm pn ttf-wqy-microhei | ttf-wqy-zenhei -- Configuration Files: /etc/java-8-openjdk/accessibility.properties changed: -- no debconf information --- End Message --- --- Begin Message --- *Avez-vous besoin de financement? Avez-vous besoin d'un prêt pour des besoins professionnels ou personnels? Nous proposons tous les types de prêts aux particuliers ou aux entreprises, quel que soit votre pointage de crédit actuel. Pour plus d'informations, n'hésitez pas à nous contacter par e-mail : guarantycreditlo...@aol.com pour plus d'informations.* *Merci pour votre temps, nous nous réjouissons d'accorder votre crédit en ligne.* *COPYRIGHT 2022 (R).* --- End Message ---
Bug#896907: marked as done (openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies)
Your message dated Fri, 11 Mar 2022 13:53:06 -0800 with message-id and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #896907, regarding openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 896907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896907 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openjdk-8-jre-headless Version: 8u162-b12-1~deb9u1 Severity: normal Dear Maintainer, The openjdk-8-jre-headless package intentionally excludes user interface related components, but the package mistakenly enables Java assistive technologies which require user interface components. Java assistive technologies should be disabled in the *-headless package so that components do not mistakenly believe assistive technologies might work. The Jenkins jenkins/jenkins:slim image is based on the openjdk:slim image. The OpenJDK slim image packages openjdk-8-jre-headless. The Docker image description says: openjdk:slim This image installs the -headless package of OpenJDK and so is missing many of the UI-related Java libraries and some common packages contained in the default tag. It only contains the minimal packages needed to run Java. Unless you are working in an environment where only the openjdk image will be deployed and you have space constraints, we highly recommend using the default image of this repository. While using Jenkins based on the jenkins/jenkins:slim image, charts and graphs are not drawn because JFreeChart fails to initialize. JFreeChart fails to initialize because Java assistive technologies are enabled, but not installed. Disabling Java assistive technologies allows Jenkins to show charts and graphs when hosted on the jenkins/jenkins:slim image. Refer to https://github.com/jenkinsci/docker/pull/657 for the pull request to the Jenkins Docker image which resolves the problem by disabling Java assistive technologies. Refer to https://github.com/docker-library/openjdk/pull/189 for the openjdk pull request which resolves the problem by disabling Java assistive technologies. Those two pull requests should be removed once the upstream packaging is corrected to not enable Java assistive technologies when running openjdk-8-jre-headless. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20170531+nmu1 ii java-common 0.58 ii libc6 2.24-11+deb9u3 ii libcups2 2.2.1-8+deb9u1 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libjpeg62-turbo 1:1.5.1-2 ii liblcms2-22.8-4 ii libnss3 2:3.26.2-1.1+deb9u1 ii libpcsclite1 1.8.20-1 ii libstdc++66.3.0-18+deb9u1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.9-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii util-linux2.29.2-1+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-1 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.10-8 -- no debconf information --- End Message --- --- Begin Message --- *Vous avez besoin d'un prêt pour votre entreprise, besoin d'un prêt rapide pour régler vos factures, pour un usage personnel ? Notre offre propose des prêts avec un faible taux d'intérêt de 3%. Avez-vous pensé à contracter un prêt ? Vous avez probablement été rejeté par votre banque locale ? Veuillez répondre pour plus d'informations: guarantycreditloanun...@aol.com * --- End Message ---
Bug#819785: marked as done (openjdk-8-jre-headless: Debug information missing in JRE jars)
Your message dated Fri, 11 Mar 2022 13:53:06 -0800 with message-id and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #819785, regarding openjdk-8-jre-headless: Debug information missing in JRE jars to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 819785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819785 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openjdk-8-jre-headless Version: 8u77-b03-3 Severity: important Dear Maintainer, I have just discovered that stepping into JRE classes with a debugger does not allow inspecting variable states, the debugger complains that classes are built without "-g" option. I cannot confirm when this started - I only debug into system classes occasionally. However, for me, absense of this information strongly limits the ability to seriously develop java code with this package. javap -l shows some information but it does not show the variable tables. My best guess is, that classes were compiled with "-g:lines" instead of "-g" or -g:lines,vars" I'm using Netbeans 8.1 debugger. TIA. Chris. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20160321 ii java-common 0.57 ii libc6 2.22-5 ii libcups2 2.1.3-5 ii libfontconfig12.11.0-6.4 ii libfreetype6 2.6.3-3 ii libgcc1 1:5.3.1-13 ii libjpeg62-turbo 1:1.4.2-2 ii liblcms2-22.6-3+b3 ii libnss3 2:3.23-1 ii libpcsclite1 1.8.16-1 ii libstdc++65.3.1-13 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxi62:1.7.6-1 ii libxrender1 1:0.9.9-2 ii libxtst6 2:1.2.2-1+b1 ii multiarch-support 2.22-5 ii util-linux 2.27.1-6 ii zlib1g1:1.2.8.dfsg-2+b1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra 2.35-1 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho ii libnss-mdns0.10-7 pn openjdk-8-jre-jamvm pn ttf-wqy-microhei | ttf-wqy-zenhei -- Configuration Files: /etc/java-8-openjdk/accessibility.properties changed: -- no debconf information --- End Message --- --- Begin Message --- *Vous avez besoin d'un prêt pour votre entreprise, besoin d'un prêt rapide pour régler vos factures, pour un usage personnel ? Notre offre propose des prêts avec un faible taux d'intérêt de 3%. Avez-vous pensé à contracter un prêt ? Vous avez probablement été rejeté par votre banque locale ? Veuillez répondre pour plus d'informations: guarantycreditloanun...@aol.com * --- End Message ---
Bug#760982: marked as done (openjdk-8 needs time zone data)
Your message dated Fri, 11 Mar 2022 13:53:01 -0800 with message-id and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #760982, regarding openjdk-8 needs time zone data to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 760982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760982 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:openjdk-8 Version: 8u40~b04-2 Severity: serious Tags: sid jessie https://lists.debian.org/debian-java/2014/08/msg00017.html 5. Implement a java.time.zone.ZoneRulesProvider [3] that reads the TZif2 files installed by the tzdata package in /usr/share/zoneinfo. This would render the tzdata-java package obsolete in the long term. GNU ClassPath has a TZif2 parser [4] that could be used as a starting point. [4] https://github.com/jatovm/classpath/blob/master/gnu/java/util/ZoneInfo.java --- End Message --- --- Begin Message --- *Vous avez besoin d'un prêt pour votre entreprise, besoin d'un prêt rapide pour régler vos factures, pour un usage personnel ? Notre offre propose des prêts avec un faible taux d'intérêt de 3%. Avez-vous pensé à contracter un prêt ? Vous avez probablement été rejeté par votre banque locale ? Veuillez répondre pour plus d'informations: guarantycreditloanun...@aol.com * --- End Message ---
Bug#760982: marked as done (openjdk-8 needs time zone data)
Your message dated Tue, 22 Feb 2022 01:20:47 +0100 with message-id <0d8026bf.avyaaes-buqaacotjggatgaaabtbywbif...@mailjet.com> and subject line Avez-vous besoin d'un prêt? has caused the Debian Bug report #760982, regarding openjdk-8 needs time zone data to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 760982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760982 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:openjdk-8 Version: 8u40~b04-2 Severity: serious Tags: sid jessie https://lists.debian.org/debian-java/2014/08/msg00017.html 5. Implement a java.time.zone.ZoneRulesProvider [3] that reads the TZif2 files installed by the tzdata package in /usr/share/zoneinfo. This would render the tzdata-java package obsolete in the long term. GNU ClassPath has a TZif2 parser [4] that could be used as a starting point. [4] https://github.com/jatovm/classpath/blob/master/gnu/java/util/ZoneInfo.java --- End Message --- --- Begin Message --- Vous avez des factures impayées ou vous avez besoin d'un prêt urgent ? Ne vous inquiétez plus, nous offrons toutes sortes de prêts à un taux d'intérêt de 3 %. si vous êtes intéressé, répondez-nous maintenant pour plus de détails...guarantycreditloanun...@aol.com--- End Message ---
Bug#906111: marked as done (openjdk-8-jre: Package should Provide: java-runtime)
Your message dated Tue, 15 Jun 2021 20:48:33 +
with message-id
and subject line Bug#906111: fixed in openjdk-8 8u292-b10-2
has caused the Debian Bug report #906111,
regarding openjdk-8-jre: Package should Provide: java-runtime
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
906111: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906111
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openjdk-8-jre
Version: 8u181-b13-1
Severity: normal
Dear Maintainer,
Package openjdk-8-jre has Provides:
java2-runtime, java5-runtime, java6-runtime, java7-runtime,
java8-runtime
It is missing "java-runtime". As result, some other packages that
depend on java-runtime will force installation of JRE 7 (too old)
or JRE 10 (too new, some tools still do not support it) and having JRE
8 will not satisfy their dependencies.
Other JRE versions in debian have "java-runtime" in their Provides:.
Package openjdk-7-jre Provides:
java-runtime, java2-runtime, java5-runtime, java6-runtime,
java7-runtime
Package openjdk-10-jre Provides:
java-runtime, java10-runtime, java2-runtime, java5-runtime,
java6-runtime, java7-runtime, java8-runtime, java9-runtime
Please add java-runtime to "Provides" section in the control file.
Equivalent ..-jdk packages do not suffer from this problem (JDK 7,8 and
10 provide "java-jdk")
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openjdk-8-jre depends on:
ii libasound2 1.1.6-1
ii libatk-wrapper-java-jni 0.33.3-21
ii libc62.27-5
ii libgif7 5.1.4-3
ii libgl1 1.0.0+git20180308-4
ii libgl1-mesa-glx 18.1.5-1
ii libglib2.0-0 2.56.1-2
ii libgtk-3-0 3.22.30-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libpng16-16 1.6.34-2
ii libpulse012.0-1
ii libx11-6 2:1.6.5-1
ii libxext6 2:1.3.3-1+b2
ii libxinerama1 2:1.1.3-1+b3
ii libxrandr2 2:1.5.1-1
ii openjdk-8-jre-headless 8u181-b13-1
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages openjdk-8-jre recommends:
pn fonts-dejavu-extra
Versions of packages openjdk-8-jre suggests:
pn icedtea-8-plugin
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: openjdk-8
Source-Version: 8u292-b10-2
Done: Thorsten Glaser
We believe that the bug you reported is fixed in the latest version of
openjdk-8, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 906...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Thorsten Glaser (supplier of updated openjdk-8 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Format: 1.8
Date: Tue, 15 Jun 2021 22:23:01 +0200
Source: openjdk-8
Architecture: source
Version: 8u292-b10-2
Distribution: unstable
Urgency: low
Maintainer: Java Maintenance
Changed-By: Thorsten Glaser
Closes: 822348 863199 906111
Changes:
openjdk-8 (8u292-b10-2) unstable; urgency=low
.
* Fix regression in /etc/java-8-openjdk/accessibility.properties
* Drop Suggests nōnexistent icedtea-8-plugin
* Fix binfmts error with patch from bug (Closes: #822348)
* Create /usr/share/man/man1 if it doesn’t exist, for crippled
container images (Closes: #863199)
* Provide java-runtime{,-headless} (Closes: #906111)
* Mark openjdk-8-doc as M-A:foreign
* Update “It was downloaded from” in d/copyright (cf. #970517)
Checksums-Sha1:
59fe4d38d084fa4c74f45a420e80c5e425b4e850 4778 openjdk-8_8u292-b10-2.dsc
105eddac95a638fa091f0a9b227cb9e057051665 216612
openjdk-8_8u292-b10-2.debian.tar.xz
Checksums-Sha256:
b75342dff79d49e113d4baf303
Bug#822348: marked as done (openjdk-8-jre-headless: prerm checks for wrong file before deregistering binfmt)
Your message dated Tue, 15 Jun 2021 20:48:33 +
with message-id
and subject line Bug#822348: fixed in openjdk-8 8u292-b10-2
has caused the Debian Bug report #822348,
regarding openjdk-8-jre-headless: prerm checks for wrong file before
deregistering binfmt
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
822348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822348
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openjdk-8-jre-headless
Version: 8u91-b14-2
Severity: normal
Tags: patch
The prerm is looking for /var/lib/binfmts/@basename@ (e.g., openjdk-8) but the
files under /var/lib/binfmts are named after the binfmt being registered, not
the package.
This means that users which have upgraded from openjdk-7 to openjdk-8 will
always see a warning message about openjdk-7 already having registered the
binfmt when a new openjdk-8 update is installed.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openjdk-8-jre-headless depends on:
ii ca-certificates-java 20160321
ii java-common 0.57
ii libc6 2.22-7
ii libcups2 2.1.3-5
ii libfontconfig12.11.0-6.4
ii libfreetype6 2.6.3-3+b1
ii libgcc1 1:5.3.1-15
ii libjpeg62-turbo 1:1.4.2-2
ii liblcms2-22.7-1
ii libnss3 2:3.23-2
ii libpcsclite1 1.8.16-1
ii libstdc++65.3.1-15
ii libx11-6 2:1.6.3-1
ii libxext6 2:1.3.3-1
ii libxi62:1.7.6-1
ii libxrender1 1:0.9.9-2
ii libxtst6 2:1.2.2-1+b1
ii multiarch-support 2.22-7
ii util-linux2.28-1
ii zlib1g 1:1.2.8.dfsg-2+b1
openjdk-8-jre-headless recommends no packages.
Versions of packages openjdk-8-jre-headless suggests:
ii fonts-dejavu-extra 2.35-1
pn fonts-indic
pn fonts-ipafont-gothic
pn fonts-ipafont-mincho
ii libnss-mdns 0.10-7
pn openjdk-8-jre-jamvm
pn ttf-wqy-microhei | ttf-wqy-zenhei
-- no debconf information
=== modified file 'debian/JB-jre-headless.prerm.in'
--- debian/JB-jre-headless.prerm.in 2014-05-29 08:50:43 +
+++ debian/JB-jre-headless.prerm.in 2016-04-23 17:39:15 +
@@ -15,7 +15,7 @@
if which update-binfmts >/dev/null; then
# try to remove and ignore the error
- if [ -e /var/lib/binfmts/@basename@ ]; then
+ if [ -e /var/lib/binfmts/jar ]; then
update-binfmts --package @basename@ \
--remove jar /usr/bin/jexec || true
fi
--- End Message ---
--- Begin Message ---
Source: openjdk-8
Source-Version: 8u292-b10-2
Done: Thorsten Glaser
We believe that the bug you reported is fixed in the latest version of
openjdk-8, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 822...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Thorsten Glaser (supplier of updated openjdk-8 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Format: 1.8
Date: Tue, 15 Jun 2021 22:23:01 +0200
Source: openjdk-8
Architecture: source
Version: 8u292-b10-2
Distribution: unstable
Urgency: low
Maintainer: Java Maintenance
Changed-By: Thorsten Glaser
Closes: 822348 863199 906111
Changes:
openjdk-8 (8u292-b10-2) unstable; urgency=low
.
* Fix regression in /etc/java-8-openjdk/accessibility.properties
* Drop Suggests nōnexistent icedtea-8-plugin
* Fix binfmts error with patch from bug (Closes: #822348)
* Create /usr/share/man/man1 if it doesn’t exist, for crippled
container images (Closes: #863199)
* Provide java-runtime{,-headless} (Closes: #906111)
* Mark openjdk-8-doc as M-A:foreign
* Update
Processed: more openjdk-8 bug maintenance
Processing commands for cont...@bugs.debian.org: > # this is here for keeps > tags 989736 moreinfo Bug #989736 [src:openjdk-8] openjdk-8: keep out of testing and stable Added tag(s) moreinfo. > outlook 989736 This package is required for JVM language bootstrapping in > unstable, and used to prepare security updates for stretch LTS and jessie > ELTS. Furher use is not officially supported by Debian, but provided as a > convenience for end users by the maintainer. Outlook recorded from message bug 989736 message > # 11 seems to contain the requested debugging info > severity 819785 normal Bug #819785 [openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information missing in JRE jars Severity set to 'normal' from 'important' > tags 819785 + help Bug #819785 [openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information missing in JRE jars Added tag(s) help. > # this is only a workaround for crazily broken systems > severity 863199 normal Bug #863199 [openjdk-8-jre-headless] error creating symbolic link '/usr/share/man/man1/rmid.1.gz.dpkg-tmp Severity set to 'normal' from 'important' > tags 863199 = pending Bug #863199 [openjdk-8-jre-headless] error creating symbolic link '/usr/share/man/man1/rmid.1.gz.dpkg-tmp Added tag(s) pending. > # applied > tags 822348 + pending Bug #822348 [openjdk-8-jre-headless] openjdk-8-jre-headless: prerm checks for wrong file before deregistering binfmt Added tag(s) pending. > # this is something I'd like to have but must be fixed in 11 first > reassign 834053 openjdk-11 Bug #834053 [src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size Bug reassigned from package 'src:openjdk-8' to 'openjdk-11'. No longer marked as found in versions openjdk-8/8u292-b10-1 and openjdk-11/11.0.12+4-1. Ignoring request to alter fixed versions of bug #834053 to the same values previously set > affects 834053 openjdk-8 Bug #834053 [openjdk-11] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size Added indication that 834053 affects openjdk-8 > # fix this in 11 first if possible at all or close there > reassign 907541 openjdk-11 Bug #907541 [openjdk-8] [openjdk-8] Bind to a multicast address fails Bug reassigned from package 'openjdk-8' to 'openjdk-11'. No longer marked as found in versions 8u181-b13-1, openjdk-11/11.0.12+4-1, and openjdk-8/8u292-b10-1. Ignoring request to alter fixed versions of bug #907541 to the same values previously set > # need reproducer, assistive things work fine for me > tags 896907 = moreinfo unreproducible Bug #896907 [openjdk-8-jre-headless] openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies Added tag(s) unreproducible and moreinfo. > # applied > tags 906111 + pending Bug #906111 [openjdk-8-jre] openjdk-8-jre: Package should Provide: java-runtime Added tag(s) pending. > # still relevant? seems to work fine... > tags 760982 = moreinfo Bug #760982 [src:openjdk-8] openjdk-8 needs time zone data Added tag(s) moreinfo; removed tag(s) bullseye, buster, stretch, jessie, and sid. > thanks Stopping processing here. Please contact me if you need assistance. -- 760982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760982 819785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819785 822348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822348 834053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834053 863199: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199 896907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896907 906111: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906111 907541: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907541 989736: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989736 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#907541: [openjdk-8] Bind to a multicast address fails
Hi Andre, > This was supposed to be fixed upstream in Java 12: > https://bugs.openjdk.java.net/browse/JDK-8210493 > > However it was taken back again (see last comment in that issue) and is now > supposedly fixed in java 13: > https://bugs.openjdk.java.net/browse/JDK-8215294 > https://bugs.openjdk.java.net/browse/JDK-8216417 thanks for this information bundle, it helps tremendously. > As far as I am aware, it works with current Java versions in Debian (>= 13). > > I am not sure if Debian actually wants to carry this for the versions <13, as > the patch somehow introduced other issues (see the upstream bug-reports). As far as I understand, the original patch indeed introduced issues, so it’s probably not something we want to have in 8 and 11. The fix in 13+ is not backportable because they basically rewrote the entire socket classes’ implementations. I guess this won’t be fixed in 8 and, more importantly, 11 currently. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#907541: [openjdk-8] Bind to a multicast address fails
Am 15.06.21 um 00:54 schrieb Thorsten Glaser: tags 907541 + confirmed upstream found 907541 openjdk-8/8u292-b10-1 found 907541 openjdk-11/11.0.12+4-1 thanks On Wed, 29 Aug 2018, Andre Naujoks wrote: This bugs affects all currently available Java versions in Debian (7, 8, 10 and 11). I don't know how to mark this here. Normally, cloning the bug against all affected packages, but I’m Cc’ing Doko on this hoping he’ll DTRT ☺ The contents of the patch should be usable for all versions with very little change. […] The attached patch fixes/adds this in the jvm. This is another of these things where it’d be preferable to fix this upstream first then apply the patch in Debian packages. However it’s small and easily applied ahead of time. It’d be no good if I’d fix this in openjdk-8 but 11 (and 17, possibly) are unfixed; Doko? Andre, can you report this upstream? Hi Thorsten. This was supposed to be fixed upstream in Java 12: https://bugs.openjdk.java.net/browse/JDK-8210493 However it was taken back again (see last comment in that issue) and is now supposedly fixed in java 13: https://bugs.openjdk.java.net/browse/JDK-8215294 https://bugs.openjdk.java.net/browse/JDK-8216417 As far as I am aware, it works with current Java versions in Debian (>= 13). I am not sure if Debian actually wants to carry this for the versions <13, as the patch somehow introduced other issues (see the upstream bug-reports). It would be nice to have, but I'd understand if you'd decided against taking the patch after the back and forth that happened upstream. Regards Andre Thanks, //mirabilos
Processed: Re: [openjdk-8] Bind to a multicast address fails
Processing commands for cont...@bugs.debian.org: > tags 907541 + confirmed upstream Bug #907541 [openjdk-8] [openjdk-8] Bind to a multicast address fails Added tag(s) upstream and confirmed. > found 907541 openjdk-8/8u292-b10-1 Bug #907541 [openjdk-8] [openjdk-8] Bind to a multicast address fails Marked as found in versions openjdk-8/8u292-b10-1. > found 907541 openjdk-11/11.0.12+4-1 Bug #907541 [openjdk-8] [openjdk-8] Bind to a multicast address fails Marked as found in versions openjdk-11/11.0.12+4-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 907541: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907541 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#907541: [openjdk-8] Bind to a multicast address fails
tags 907541 + confirmed upstream found 907541 openjdk-8/8u292-b10-1 found 907541 openjdk-11/11.0.12+4-1 thanks On Wed, 29 Aug 2018, Andre Naujoks wrote: > This bugs affects all currently available Java versions in Debian (7, 8, 10 > and 11). > I don't know how to mark this here. Normally, cloning the bug against all affected packages, but I’m Cc’ing Doko on this hoping he’ll DTRT ☺ > The contents of the patch should > be usable for all versions with very little change. […] > The attached patch fixes/adds this in the jvm. This is another of these things where it’d be preferable to fix this upstream first then apply the patch in Debian packages. However it’s small and easily applied ahead of time. It’d be no good if I’d fix this in openjdk-8 but 11 (and 17, possibly) are unfixed; Doko? Andre, can you report this upstream? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#896907: openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies
On Wed, 25 Apr 2018, Mark Waite wrote: > Java assistive > technologies should be disabled in the *-headless package so that > components do not mistakenly believe assistive technologies might work. I’m not sure this is technically possible; this is a conffile, so we cannot, from a packaging PoV, have different configurations depending on which packages are installed. > The openjdk-8-jre-headless package intentionally excludes user interface > related components, but the package mistakenly enables Java assistive > technologies which require user interface components. On the other hand, these components probably fall under “need the nōn-headless JRE” anyway. Here, “headless” does not mean “doesn’t have a display attached locally” but “omits stuff for graphics”. If your library uses graphics, chances are it needs the full JRE, including its dependencies. That being said, openjdk-11 currently doesn’t enable assistive technologies at all (because they don’t work — not because of things like this; expect them to be enabled once they work). > The Docker > image description says: > > openjdk:slim > > This image installs the -headless package of OpenJDK and so is missing > many of the UI-related Java libraries and some common packages contained There you have it. You’ll need to add the full JRE. > While using Jenkins based on the jenkins/jenkins:slim image, charts and > graphs are not drawn because JFreeChart fails to initialize. JFreeChart > fails to initialize because Java assistive technologies are enabled, > but not installed. This sounds like something fixable in JFreeChart. Is this the same I see packaged as libjfreechart-java in Debian? Do you have some small reproducer for the “JFreeChart fails to initialise” problem I can run to test this? Thanks in advance, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Processed: Re: openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size
Processing commands for cont...@bugs.debian.org: > tags 834053 + confirmed upstream Bug #834053 [src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size Added tag(s) upstream and confirmed. > found 834053 openjdk-8/8u292-b10-1 Bug #834053 [src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size Marked as found in versions openjdk-8/8u292-b10-1. > found 834053 openjdk-11/11.0.12+4-1 Bug #834053 [src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size Marked as found in versions openjdk-11/11.0.12+4-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 834053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834053 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#834053: openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size
tags 834053 + confirmed upstream found 834053 openjdk-8/8u292-b10-1 found 834053 openjdk-11/11.0.12+4-1 thanks On Mon, 18 Feb 2019, Nobuhiro Ban wrote: > Or, should I send this report to upstream? This would be appreciated. While we can fix that in the Debian copies of openjdk-8, and probably Doko can fix it in 11 and 17 as well, there’d still be differing behaviour. Once fixed upstream applying it to all versions is easier. @Doko: or what do you think? The diff is a one-liner bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Processed: Re: openjdk-8-jre-headless: Debug information missing in JRE jars
Processing commands for cont...@bugs.debian.org: > found 819785 8u292-b10-1 Bug #819785 [openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information missing in JRE jars Marked as found in versions openjdk-8/8u292-b10-1. > tags 819785 + upstream Bug #819785 [openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information missing in JRE jars Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 819785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819785 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#819785: openjdk-8-jre-headless: Debug information missing in JRE jars
found 819785 8u292-b10-1 tags 819785 + upstream thanks On Sat, 2 Apr 2016, Christian Haul wrote: > I have just discovered that stepping into JRE classes with a debugger does not > allow inspecting variable states, the debugger complains that classes are > built > without "-g" option. They are built without any -g option. Some (jaxp, for example) use -g but not all. Looking at jdk/make/Setup.gmk, from jdk.tar.xz, the calls of the SetupJavaCompiler macro are all missing -g from FLAGS. The CORBA stuff is also built without it. There’s no single variable used by all of them where we could just add -g so this… is going to be tricky. Ideally, you’d ask upstream to change this for the next 8u? Is this possible? Thanks, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Processed: reopening bugs from reintroducing openjdk-8
Processing commands for cont...@bugs.debian.org:
> unarchive 819785
Bug #819785 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information missing in
JRE jars
Unarchived Bug 819785
> unarchive 822348
Bug #822348 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] openjdk-8-jre-headless: prerm checks for wrong file
before deregistering binfmt
Unarchived Bug 822348
> unarchive 834053
Bug #834053 {Done: Debian FTP Masters }
[src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font
size
Unarchived Bug 834053
> unarchive 859138
Bug #859138 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] java.lang.UnsupportedOperationException: The BROWSE
action is not supported on the current platform!
Unarchived Bug 859138
> unarchive 896907
Bug #896907 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] openjdk-8-jre-headless: Headless JRE package should
not configure assistive technologies
Unarchived Bug 896907
> unarchive 907541
Bug #907541 {Done: Debian FTP Masters }
[openjdk-8] [openjdk-8] Bind to a multicast address fails
Unarchived Bug 907541
> unarchive 863199
Bug #863199 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] error creating symbolic link
'/usr/share/man/man1/rmid.1.gz.dpkg-tmp
Unarchived Bug 863199
> unarchive 906111
Bug #906111 {Done: Debian FTP Masters }
[openjdk-8-jre] openjdk-8-jre: Package should Provide: java-runtime
Unarchived Bug 906111
> reopen 819785
Bug #819785 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information missing in
JRE jars
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 822348
Bug #822348 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] openjdk-8-jre-headless: prerm checks for wrong file
before deregistering binfmt
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 834053
Bug #834053 {Done: Debian FTP Masters }
[src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style) corrupts font
size
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 859138
Bug #859138 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] java.lang.UnsupportedOperationException: The BROWSE
action is not supported on the current platform!
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 896907
Bug #896907 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] openjdk-8-jre-headless: Headless JRE package should
not configure assistive technologies
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 907541
Bug #907541 {Done: Debian FTP Masters }
[openjdk-8] [openjdk-8] Bind to a multicast address fails
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 863199
Bug #863199 {Done: Debian FTP Masters }
[openjdk-8-jre-headless] error creating symbolic link
'/usr/share/man/man1/rmid.1.gz.dpkg-tmp
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> reopen 906111
Bug #906111 {Done: Debian FTP Masters }
[openjdk-8-jre] openjdk-8-jre: Package should Provide: java-runtime
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 8u212-b01-1+rm.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
819785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819785
822348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822348
834053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834053
859138: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859138
863199: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199
896907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896907
906111: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906111
907541: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907541
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
openjdk-8 vs. time zone data
Hi, can anyone comment on the status of: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760982 Is there anything that still needs to be done? AFAICT it works fine on jessie. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
openjdk-8 back in sid (was Re: Kotlin: looking for a DD to review/upload)
Dixi quod… > On Thu, 29 Apr 2021, Sunil Mohan Adapa wrote: > > > Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into > > Debian. We need a DD willing to upload it. > > > > The actual upload needs to wait for openjdk-8, which is currently in the > > NEW queue, to be accepted first. > > Again, please only do the actual uploading *after* openjdk-8 8u292-b10-1 > (or higher) has been built for all architectures. This is a version I This has happened now. Enjoy! Architecture VersionStatus For Buildd StateSection [12]Logs Actions [13]Buildd exposure stats [14]all 8u292-b10-1 [15]Installed 2d 16h 48m [16]x86-grnet-02 misc[17]old | [18]all (1) [19]giveback [20]Buildd exposure stats [21]amd64 8u292-b10-1 [22]Installed 2d 16h 39m [23]x86-ubc-01misc[24]old | [25]all (1) [26]giveback [27]Buildd exposure stats [28]arm64 8u292-b10-1 [29]Installed 2d 14h 9m [30]arm-conova-01 misc[31]old | [32]all (1) [33]giveback [34]Buildd exposure stats [35]armel 8u292-b10-1 [36]Installed 21h 39m[37]hoiby misc[38]old | [39]all (2) [40]giveback [41]Buildd exposure stats [42]armhf 8u292-b10-1 [43]Installed 2d 14h 29m [44]arm-arm-01misc[45]old | [46]all (1) [47]giveback [48]Buildd exposure stats [49]i386 8u292-b10-1 [50]Installed 2d 15h 49m [51]x86-conova-01 misc[52]old | [53]all (1) [54]giveback [55]Buildd exposure stats [56]mips64el 8u292-b10-1 [57]Installed 2d 2h 14m [58]mipsel-manda-04 misc[59]old | [60]all (1) [61]giveback [62]Buildd exposure stats [63]mipsel8u292-b10-1 [64]Installed 1d 12h 10m [65]mipsel-aql-02 misc[66]old | [67]all (1) [68]giveback [69]Buildd exposure stats [70]ppc64el 8u292-b10-1 [71]Installed 2d 17h 29m [72]ppc64el-unicamp-01misc[73]old | [74]all (1) [75]giveback [76]Buildd exposure stats [77]s390x 8u292-b10-1 [78]Installed 2d 13h 9m [79]zandonai misc[80]old | [81]all (1) [82]giveback It’s not available for any of the debian-ports architectures, unfortunately. This should not be a problem for your use case. If needed, porters can probably make the old packages available for a rebuild so it can be built on ports architectures again, though not all build (the m68k patch for example needs updating as it no longer applies and was disabled). bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Re: OpenJDK 8 archive re-entry
On Mon, 26 Apr 2021, Thorsten Glaser wrote: >I assume the normal > process of looking at it and eventually getting back to us will run > now. So far, nothing happened, and repeated inquiries got no response at all. Just keeping the list informed. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Re: OpenJDK 8 archive re-entry
Hi again, I’ve asked over time again, but other than the “can we keep it out of bookworm?”, which, of course, is a yes, I’ve not got any feedback yet. > In the meantime I also prepared an 8u292-b10-1… found lots of issues > even… but will wait uploading it until it was ACCEPTED into unstable > because then the buildds can do their job, instead of me needing to > do builds for each architecture… I’m building it for testing locally > right now. I’ve uploaded corresponding builds to the “lts” (and “wtf”) component of http://www.mirbsd.org/~tg/Debs/debidx.htm (wheezy/jessie/stretch/buster/ bullseye), and to https://launchpad.net/~mirabilos/+archive/ubuntu/jdk (precise/trusty/xenial/bionic/focal), for amd64 and except trusty+ i386, so if anyone wants to have a look or use it already… feel free to ☺ bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Re: OpenJDK 8 archive re-entry
Hi again, > > Emmanuel, will you or should I? > > Please do. sorry for taking a bit, but I did today. I talked a bit with elbrus, explaining the reasoning, and that, of course, this won’t end up in bookworm or have any sort of official support — I assume the normal process of looking at it and eventually getting back to us will run now. In the meantime I also prepared an 8u292-b10-1… found lots of issues even… but will wait uploading it until it was ACCEPTED into unstable because then the buildds can do their job, instead of me needing to do builds for each architecture… I’m building it for testing locally right now. > That said, we may also upload kotlin now even if openjdk-8 is still in > the queue. As long as they enter sid in the right order, that's fine. In I’d really prefer not. The first upload of openjdk-8 was done in a hackish way. Please wait with uploading kotlin until 8u292 is both uploaded *and* built by the buildds *and* in status Installed, so it’s ready as B-D for further builds. > the worst case kotlin will be accepted before openjdk-8 and simply > prevented from transitioning to testing until openjdk-8 arrives. If kotlin runtime-Depends on openjdk-8 there’s no chance it’ll ever end up in testing anyway ☺ and even if not, it’d only do so after the bullseye release of course. > > I’m not exactly sure this method is the preferred one, especially > > given ebourg’s alternative bootstrapping path from source is > > progressing admirably. (Not to throw away that work though, it’ll > > become useful nearer to that bootstrapping processes end.) > > To be honest, I still have a very long way to go and I'm not even sure > to succeed (I spent a full day dealing with 2 months worth of commits, > and I'm only at the Q2 2015 code). Right. > They've done a great work, I don't think my approach replaces theirs, at > best I may reconnect with them to provide the bootstrap compiler, or > certify later that both approaches produce the same binaries. That’s certainly one way to do it, if things build reproducibly. We probably should look at rebootstrapping openjdk-8 at some point in time as well… the fetch-orig target used http, not https, for downloading the sources… one of the things I’m fixing in 8u292-b10-1 (except for icedtea-sound because of unavailability of https for it but I downloaded it manually, verified-ish it with PGP and added a SHA256 check to d/rules for it so it’s at least consistent). bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Re: OpenJDK 8 archive re-entry
Le 22/04/2021 à 02:51, Thorsten Glaser a écrit : > unfortunately not yet. They’re probably depriorising sid in times of > freeze, but the grace period for not bothering them is probably over > by now so if ebourg doesn’t want to prod them now, I can do this but > nobody else should so they don’t get annoyed. > > Emmanuel, will you or should I? Please do. That said, we may also upload kotlin now even if openjdk-8 is still in the queue. As long as they enter sid in the right order, that's fine. In the worst case kotlin will be accepted before openjdk-8 and simply prevented from transitioning to testing until openjdk-8 arrives. > I’m not exactly sure this method is the preferred one, especially > given ebourg’s alternative bootstrapping path from source is > progressing admirably. (Not to throw away that work though, it’ll > become useful nearer to that bootstrapping processes end.) To be honest, I still have a very long way to go and I'm not even sure to succeed (I spent a full day dealing with 2 months worth of commits, and I'm only at the Q2 2015 code). They've done a great work, I don't think my approach replaces theirs, at best I may reconnect with them to provide the bootstrap compiler, or certify later that both approaches produce the same binaries. Emmanuel Bourg
Re: OpenJDK 8 archive re-entry
Hi Phil, > I'm sure it's just a matter of time, but have you had any feedback from > ftp-masters about openjdk-8? unfortunately not yet. They’re probably depriorising sid in times of freeze, but the grace period for not bothering them is probably over by now so if ebourg doesn’t want to prod them now, I can do this but nobody else should so they don’t get annoyed. Emmanuel, will you or should I? > Thanks to Sunil for the major breakthrough, > we are now ready to [upload] kotlin which is now [blocked] on this. I’m not exactly sure this method is the preferred one, especially given ebourg’s alternative bootstrapping path from source is progressing admirably. (Not to throw away that work though, it’ll become useful nearer to that bootstrapping processes end.) bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
OpenJDK 8 archive re-entry
On Wed, Mar 24, 2021 at 11:03:44PM +0100, Thorsten Glaser wrote: > On Wed, 24 Mar 2021, Emmanuel Bourg wrote: > > Le 24/03/2021 à 22:13, Thorsten Glaser a écrit : > > > I can certainly bring it back to unstable, built with > > > gcc 10, if there are no major issues involved in making > > > it build with GCC 10, if there is interest. > > > > We are certainly doomed without openjdk-8 in unstable, we really need it > > back. > > Okay. So, unless doko vetos (it was he who was the maintainer > and he who requested the removal (to be able to remove GCC 9, > which he is also maintainer of) but I would enter the d-java > list as team maintainer, with myself as uploader for now) I’ll > try to get it building with GCC 10 and upload that to unstable. Hello mirabilos, I'm sure it's just a matter of time, but have you had any feedback from ftp-masters about openjdk-8? Thanks to Sunil for the major breakthrough, we are now ready to [upload] kotlin which is now [blocked] on this. [upload]: https://salsa.debian.org/java-team/kotlin/-/issues/11 [blocked]: https://salsa.debian.org/java-team/kotlin/-/issues/12 signature.asc Description: PGP signature
Re: openjdk-8 8u275-b01-1
On Tue, 22 Dec 2020, Emilio Pozuelo Monfort wrote: > I have released this to stretch and jessie (after some testing on the latter). Thanks! bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *
Re: openjdk-8 8u275-b01-1
Hi Thorsten, On 02/12/2020 20:39, Thorsten Glaser wrote: On Wed, 2 Dec 2020, Emilio Pozuelo Monfort wrote: Let me know how those tests go and we can proceed from there. It builds, with the usual “most tests pass”, and the test program I threw at it also works. I have released this to stretch and jessie (after some testing on the latter). Cheers, Emilio
Re: openjdk-8 8u275-b01-1
On Wed, 2 Dec 2020, Emilio Pozuelo Monfort wrote: > Let me know how those tests go and we can proceed from there. It builds, with the usual “most tests pass”, and the test program I threw at it also works. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *
Re: openjdk-8 8u275-b01-1
On 02/12/2020 11:21, Thorsten Glaser wrote: Hi Emilio, If you can send a debdiff I'd be happy to take a look. the debdiff between sid and stretch would be trivial, just changelog and the regenerated debian/control file (attached). I’m building it at the moment so I can test it first. Do you also need a debdiff against the version currently in stretch? I can do that as well, but it’s going to be somewhat larger. No need for that. Let me know how those tests go and we can proceed from there. Thanks, Emilio
Re: openjdk-8 8u275-b01-1
Hi Emilio, > If you can send a debdiff I'd be happy to take a look. the debdiff between sid and stretch would be trivial, just changelog and the regenerated debian/control file (attached). I’m building it at the moment so I can test it first. Do you also need a debdiff against the version currently in stretch? I can do that as well, but it’s going to be somewhat larger. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *diff -Nru openjdk-8-8u275-b01/debian/changelog openjdk-8-8u275-b01/debian/changelog --- openjdk-8-8u275-b01/debian/changelog2020-12-02 09:51:35.0 +0100 +++ openjdk-8-8u275-b01/debian/changelog2020-12-02 11:15:53.0 +0100 @@ -1,3 +1,10 @@ +openjdk-8 (8u275-b01-1~deb9u1) stretch-security; urgency=medium + + * Team upload. + * Provide 8u275-b01 (GA) regression fixes + + -- Thorsten Glaser Wed, 02 Dec 2020 11:15:53 +0100 + openjdk-8 (8u275-b01-1) unstable; urgency=medium * Team upload. diff -Nru openjdk-8-8u275-b01/debian/control openjdk-8-8u275-b01/debian/control --- openjdk-8-8u275-b01/debian/control 2020-12-02 09:51:35.0 +0100 +++ openjdk-8-8u275-b01/debian/control 2020-12-02 11:14:49.0 +0100 @@ -9,7 +9,7 @@ jtreg, testng, default-jre-headless (>= 2:1.8), time, fastjar (>= 2:0.96-0ubuntu2), autoconf (>= 2.69), automake, autotools-dev, ant, ant-optional, - g++-9, + g++-6, libffi-dev, openjdk-8-jdk | openjdk-7-jdk, libxtst-dev, libxi-dev, libxt-dev, libxaw7-dev, libxrender-dev, libcups2-dev, libasound2-dev, liblcms2-dev, libfreetype6-dev (>= 2.2.1), libxinerama-dev, libkrb5-dev, xsltproc, libpcsclite-dev, libgtk2.0-dev, zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev, libpulse-dev (>= 0.9.12) [!alpha], systemtap-sdt-dev [!sh4],
Re: openjdk-8 8u275-b01-1
Hi Thorsten, On 02/12/2020 10:06, Thorsten Glaser wrote: Hi (E)LTS-people, I’ve just uploaded an OpenJDK 8 regression update to sid, sponsored by my employer (as below). (I’m also building locally for buster, wheezy and various *buntu releases, so all possible systems I may encounter are covered, which is why I’m invested.) Would it help if I also prepared uploads to stretch-security and jessie-something, or do you prefer to continue doing so on your own? If you can send a debdiff I'd be happy to take a look. Thanks, Emilio
openjdk-8 8u275-b01-1
Hi (E)LTS-people, I’ve just uploaded an OpenJDK 8 regression update to sid, sponsored by my employer (as below). (I’m also building locally for buster, wheezy and various *buntu releases, so all possible systems I may encounter are covered, which is why I’m invested.) Would it help if I also prepared uploads to stretch-security and jessie-something, or do you prefer to continue doing so on your own? Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Will openjdk-8 go into buster?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Dixi quod… > some stuff in my personal APT repository on my own server, > and packages coming from a DD are usually better than .deb > format files, produced Goddess knows how, from elseplace. Here we are: http://www.mirbsd.org/~tg/Debs/debidx.htm Run “REPOKEY” (sha256 below) for SecureAPT: bfa75b572be43fcec9038d661fd497f5c08f8e2bb1e0340a044521b98895c95d gl hf, //mirabilos - -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) Comment: ☃ ЦΤℱ—８ ☕☂☄ iQIcBAEBCQAGBQJdeBvQAAoJEHa1NLLpkAfgWv4P/ijoWsRsmT3hzcttphtQ0VKV hcDC/8GmK2Pf7aqU24uD4pcfIrekjnOK7Vu84WdozCEPCwaSj3UDJbxKEhYntkpH f8BrbeGkLslWUYIFhBkPBNkg2G16WBNZzPqVc96ro4iN0ds8pCdzocjSR2BKjHPw DmgxQ56lwbHng0HUPtuu/QHGJ4zYiW/KG07loubCbo++/QXERGd0nwymoTFTCeWQ sXBXC5XMs7jcGkaK875m6+9kRhEIewwngIPI8NLqhSCxudKJ7RW8QjTxhk1yAmrE WtV3ZAg5WepybrluoBX+RCd1gUDuPpMPrxUrJ5OJ2zl7al9rBCyasxT1l5VFHIen 48cEmaJ00lr+IsWF452rC2UiZ1KyrDQUIC2thTW5/oVtErg9UBopJVbSbOrIGoch 61161KRXL1Jv2H8F9iKmwLKfeFbrXNZd0PJqJrB8t4QVkuBe14A5OA+A3HtnvQWI soP41+EB5y/tjmaYuIgmXdYrQRAiS7EHRD0T0JLWYHl01dk0D2+Mzo7QQ3iWeDOw Tv6YoTFZYaafpL3MwP8Edjw+5K/3ciWMjUxwpzKELwG0gkyi8nkSCtgi564VnBdz pG16PGT9JifjBKUic5gJlzFe+EDTB6FtLquR+Wor4bAZ3W4mH+mim7rHyJN+3v7W fm8Xcs/D5mDmm44I1TjK =G96p -END PGP SIGNATURE-
Re: Will openjdk-8 go into buster?
On Thu, 5 Sep 2019, Fredrik Jonson wrote: > I was under the impression that a RC-bug for bullseye on the package, > would inhibit automatic transition from testing to bullseye. Currently, testing == bullseye, so this sentence makes no sense. > Anyway, I just noticed that adoptopenjdk has begun offering their openjdk 8 > builds as debian packages in a package repository of their own. Which is > great, and completely meets my nice-to-have request without wasting the > precious time of the Debian Java Team. It’s not about time, it’s about Debian’s security guarantee. If something ships in a stable release (e.g. buster), there will be security support for it for multiple years, even if upstream won’t support it any more — which makes us, hope‐ fully understandably, wary of shipping too much old software in new stable releases (Debian is not a software museum). That being said, I’d prefer a “Nachnutzung” (post-market?) repository, in which I could build official-enough packages of stuff not going to shipped later, for those needing it, without the implied security warranties and all that, where the packages are then built in the target distribution (can be jessie, stretch and bullseye, in my case, since this kind of porting goes back and forth) on all architectures, so the shlib:Depends match. But there isn’t such a thing in Debian currently; I provide some stuff in my personal APT repository on my own server, and packages coming from a DD are usually better than .deb format files, produced Goddess knows how, from elseplace. (Incidentally, for $orkplace (see the signature), I’ll need to provide openjdk-8 builds for precise, trusty, xenial¹, wheezy, jessie anyway, and was considering putting² those into my repository already, so I’m likely to add buster, as there appears to be interest³ from users.)⁴ ① Doko provides official builds for xenial sometimes, and the current openjdk-8 is already provided, so no need, it’s on my list though. ② The disc space and network traffic might become an issue though, as those packages are *huge*. Even if I’m only building for i386, amd64 and (for sid, occasionally) m68k and/or x32… although… not OpenJDK. ③ https://www.mirbsd.org/~tg/Debs/debidx.htm although the precise/trusty/xenial builds are in a Launchpad PPA of mine. ④ Thanks Doko for keeping the package so easily buildable on so many so old releases ☻ bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Will openjdk-8 go into buster?
On 2019-08-28 at 11:56, t.gla...@tarent.de wrote: > On Wed, 28 Aug 2019, Fredrik Jonson wrote: > > > In the beginning of the summer there were discussions of backporting > > openjdk-8 to buster/stable once the release dust had settled. > > That would mean shipping bullseye with OpenJDK 8 as well, > which is kinda defeated by the justification to not ship > it with buster. I was under the impression that a RC-bug for bullseye on the package, would inhibit automatic transition from testing to bullseye. Anyway, I just noticed that adoptopenjdk has begun offering their openjdk 8 builds as debian packages in a package repository of their own. Which is great, and completely meets my nice-to-have request without wasting the precious time of the Debian Java Team. So this followup is mostly a hint to others who might find this thread in search of openjdk-8 packages for buster. Repo usage instructions are here: https://adoptopenjdk.net/installation.html#linux-pkg And, while I'm posting, a big thank you to everyone involved in Debian, you're awesome! :) -- Fredrik Jonson
Re: Will openjdk-8 go into buster?
On Wed, 28 Aug 2019, Fredrik Jonson wrote: > In the beginning of the summer there were discussions of backporting > openjdk-8 to buster/stable once the release dust had settled. That would mean shipping bullseye with OpenJDK 8 as well, which is kinda defeated by the justification to not ship it with buster. > Of course I can use adoptopenjdk binaries, but it is a great convenience > to be able to update via apt. You can most likely use the binaries from sid (at least for a while until library dependencies go up) or from stretch-security (with stretch’s libraries for those that aren’t in buster). Recompiling it is also easy enough. But there’s no place in Debian to host those. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Re: Will openjdk-8 go into buster?
Hi all, In the beginning of the summer there were discussions of backporting openjdk-8 to buster/stable once the release dust had settled. Are there any update on those intentions? Is there anything I and other users/non-maintainers can do to help? Of course I can use adoptopenjdk binaries, but it is a great convenience to be able to update via apt. -- Fredrik Jonson
Re: Will openjdk-8 go into buster or not?
On Sun, 16 Jun 2019 18:01:05 +0200 Emmanuel Bourg wrote: > No openjdk-8 won't go into Buster. I'll try to upload it as a backport > though because it's still fairly popular. I plan to update the release > notes this week. Okay, thanks for clarify. -- Hideki Yamane
Re: Will openjdk-8 go into buster or not?
Le 16/06/2019 à 15:21, Hideki Yamane a écrit : > I'm checking buster release note and find that it says both OpenJDK8 > and 11 exists in buster. > > https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#newdistro > > But as https://tracker.debian.org/pkg/openjdk-8 , it doesn't exist in > testing (buster). Will openjdk-8 go into buster or not? No openjdk-8 won't go into Buster. I'll try to upload it as a backport though because it's still fairly popular. I plan to update the release notes this week. Emmanuel Bourg
Will openjdk-8 go into buster or not?
Hi, I'm checking buster release note and find that it says both OpenJDK8 and 11 exists in buster. https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#newdistro But as https://tracker.debian.org/pkg/openjdk-8 , it doesn't exist in testing (buster). Will openjdk-8 go into buster or not? -- Hideki Yamane
Re: OpenJDK 8 watch file
Hi Martijn, I somehow missed this email, sorry about that and for the late reply. On Wed, May 29, 2019 at 7:14 AM Martijn Verburg wrote: > > Hi All, > > Starting a new thread here. I know the Red Hat folks well (AdoptOpenJDK > hosts their OpenJDK binaries for them from the source tarballs as previously > mentioned). > > So it sounds like getting the arm sources merged in (or at least kept in > sync) would help? Merging the code would help greatly if the aim is to eventually use the upstream tarballs. As for keeping in sync, aarch64 has been doing quite a good work recently, releasing very closely with upstream. > As an FYI - the 'Official' AArch64 port for OpenjDK 8 (jdk8u) is actually > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah > > I'm not sure if this is where Debian was building from for that platform? Yes, that's the repository we have been using. > I'll try to chase down arm32/aarch32 - I don't think we're even building that > at Adopt yet ourselves. It would be great if they could get their releases out faster, similar to what aarch64 has done - moving from weeks to a couple days or less. Usually most openjdk-8 packages have been released with an aarch32 hotspot that was 1 or 2 releases behind, with only hotspot security updates on top (if there's any), thus forsaking any hotspot fixes from newer releases. Keep in mind that OpenJDK updates in stable Debian/Ubuntu releases are usually considered security updates, so this approach is just fine just not optimal. It also allowed us to provide a faster hotspot for the armhf users, speed up our build, and being able to run the whole testsuites which was not possible with the ZeroVM builds. Regards, Tiago > > - > > OpenJDK 8 is another beast and the openjdk-8 package has to track a > lot more repositories: the "root" openjdk repository, corba, 3 hotspot > repositories (1 for the oracle supported archs, 1 for armhf, another > one for arm64), jaxp, jaxws, jdk, langtools, hotspot, nashorn. And the > arm related hotspot repositories usually lag behind the official one > from a few days to a few months (specially aarch32 used for armhf), so > that can delay the release or require hotspot security patches to be > applied on top of the arm hotspot. That makes having a watch file for > it much harder since the OpenJDK 8 tarballs don't include the code for > the arm hotspots. Hopefully the arm repositories will be eventually > merged upstream now that RedHat is leading OpenJDK 8. > > That said, sorry to side track the discussion, if anyone wants to > discuss openjdk-8 further I recommend doing that in a separated > thread. ;-) > > -- > > > Cheers, > Martijn -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
OpenJDK 8 watch file
Hi All, Starting a new thread here. I know the Red Hat folks well (AdoptOpenJDK hosts their OpenJDK binaries for them from the source tarballs as previously mentioned). So it sounds like getting the arm sources merged in (or at least kept in sync) would help? As an FYI - the 'Official' AArch64 port for OpenjDK 8 (jdk8u) is actually https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah I'm not sure if this is where Debian was building from for that platform? I'll try to chase down arm32/aarch32 - I don't think we're even building that at Adopt yet ourselves. - OpenJDK 8 is another beast and the openjdk-8 package has to track a lot more repositories: the "root" openjdk repository, corba, 3 hotspot repositories (1 for the oracle supported archs, 1 for armhf, another one for arm64), jaxp, jaxws, jdk, langtools, hotspot, nashorn. And the arm related hotspot repositories usually lag behind the official one from a few days to a few months (specially aarch32 used for armhf), so that can delay the release or require hotspot security patches to be applied on top of the arm hotspot. That makes having a watch file for it much harder since the OpenJDK 8 tarballs don't include the code for the arm hotspots. Hopefully the arm repositories will be eventually merged upstream now that RedHat is leading OpenJDK 8. That said, sorry to side track the discussion, if anyone wants to discuss openjdk-8 further I recommend doing that in a separated thread. ;-) -- Cheers, Martijn
Re: openjdk-8 re-uploaded to unstable (currently in NEW)
Kotlin needs jdk 8 to build. On Tue, 28 May 2019, 3:13 pm John Paul Adrian Glaubitz, < glaub...@physik.fu-berlin.de> wrote: > Hi! > > On 5/27/19 11:04 PM, Matthias Klose wrote: > > The packages are now accepted and the 8u212-b03 upstream version is now > uploaded > > as well. > > > > The changes and buildinfo files didn't exist anymore for the powerpc, > ppc64, > > sparc64 and x32 binaries, so if a porter wants to restore those, please > rebuild > > them with manually installed openjdk-8 packages from snapshot.debian.org > . > > Yes, I can do that. So, if I understand correctly, Kotlin requires > OpenJDK-8 > to work? > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: openjdk-8 re-uploaded to unstable (currently in NEW)
Hi! On 5/27/19 11:04 PM, Matthias Klose wrote: > The packages are now accepted and the 8u212-b03 upstream version is now > uploaded > as well. > > The changes and buildinfo files didn't exist anymore for the powerpc, ppc64, > sparc64 and x32 binaries, so if a porter wants to restore those, please > rebuild > them with manually installed openjdk-8 packages from snapshot.debian.org. Yes, I can do that. So, if I understand correctly, Kotlin requires OpenJDK-8 to work? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: openjdk-8 re-uploaded to unstable (currently in NEW)
On Mon, 27 May 2019, Matthias Klose wrote: > The changes and buildinfo files didn't exist anymore for the powerpc, ppc64, > sparc64 and x32 binaries, so if a porter wants to restore those, please > rebuild > them with manually installed openjdk-8 packages from snapshot.debian.org. Will do for x32. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Re: openjdk-8 re-uploaded to unstable (currently in NEW)
On 26.05.19 21:13, Matthias Klose wrote: > The openjdk-8 packages which were unfortunately removed from unstable > (although > the issue #915620 only asked for the removal of some binaries), are now again > in > NEW, targeting unstable. One of the FTP assistants is objecting to the upload > to unstable, apparently because somebody (security team, Moritz?) asked to > restore these packages in experimental instead of unstable. Otoh, we still > need > these packages in unstable to bootstrap kotlin (yes we can bootstrap in > experimental, but then it's not assured how to build kotlin for unstable with > an > experimental build). > > I honestly don't understand why FTP master would have such an objection, so > please clarify what prohibits the acceptance to unstable with an RC issue to > not > propagate these packages to testing. The packages are now accepted and the 8u212-b03 upstream version is now uploaded as well. The changes and buildinfo files didn't exist anymore for the powerpc, ppc64, sparc64 and x32 binaries, so if a porter wants to restore those, please rebuild them with manually installed openjdk-8 packages from snapshot.debian.org. Matthias
Re: openjdk-8 re-uploaded to unstable (currently in NEW)
On Sun, May 26, 2019 at 09:13:38PM +0200, Matthias Klose wrote: > The openjdk-8 packages which were unfortunately removed from unstable > (although > the issue #915620 only asked for the removal of some binaries), are now again > in > NEW, targeting unstable. One of the FTP assistants is objecting to the upload > to unstable, apparently because somebody (security team, Moritz?) asked to > restore these packages in experimental instead of unstable. Otoh, we still > need > these packages in unstable to bootstrap kotlin (yes we can bootstrap in > experimental, but then it's not assured how to build kotlin for unstable with > an > experimental build). > > I honestly don't understand why FTP master would have such an objection, so > please clarify what prohibits the acceptance to unstable with an RC issue to > not > propagate these packages to testing. I don't see any issue with these re-entering unstable. For openjdk-7 we only kept it in experimental as they were exclusively used to stage the -security uploads, but if there are other use cases like kotlin it seems perfectly fine to keep it in unstable as well. Cheers, Moritz
Re: openjdk-8 re-uploaded to unstable (currently in NEW)
Le 26/05/2019 à 21:13, Matthias Klose a écrit : > The openjdk-8 packages which were unfortunately removed from unstable > (although > the issue #915620 only asked for the removal of some binaries), are now again > in > NEW, targeting unstable. Thank you for the upload Matthias. > I honestly don't understand why FTP master would have such an objection, so > please clarify what prohibits the acceptance to unstable with an RC issue to > not > propagate these packages to testing. +1 Building Kotlin is going to become critical to keep the Java ecosystem in Debian up to date. The situation is already quite complicated and it would be nice not to add more hurdles with and experimental only openjdk-8 package. Thank you, Emmanuel Bourg
openjdk-8 re-uploaded to unstable (currently in NEW)
The openjdk-8 packages which were unfortunately removed from unstable (although the issue #915620 only asked for the removal of some binaries), are now again in NEW, targeting unstable. One of the FTP assistants is objecting to the upload to unstable, apparently because somebody (security team, Moritz?) asked to restore these packages in experimental instead of unstable. Otoh, we still need these packages in unstable to bootstrap kotlin (yes we can bootstrap in experimental, but then it's not assured how to build kotlin for unstable with an experimental build). I honestly don't understand why FTP master would have such an objection, so please clarify what prohibits the acceptance to unstable with an RC issue to not propagate these packages to testing. Matthias
Re: openjdk-8 removed from Buster?
On 30/04/2019 15.21, Hans-Christoph Steiner wrote: > It is also not possible to run upstream Gradle binaries older than 4.8 > or 4.7. It is a stupid bug on Gradle's part, but nonetheless, those > versions work with OpenJDK 8. I guess the Debian package of gradle > fixed the issue, since it is gradle 4.4. Yes, the Debian/Ubuntu version of Gradle 4.4.1 was fixed to also work with OpenJDK 11 besides OpenJDK 8. > Android Studio ships with its own (really old) embedded copy of > OpenJDK8, so Android developers on Debian will need to do: > > export JAVA_HOME=/path/to/android-studio/jre Note this is not an option for headless machines (build servers). And also not for about half of Android devs who use Eclipse or IntelliJ (as those don't come bundled with a JDK). Yesterday I heard Ubuntu 19.10 will ship with OpenJDK 8, 11 and 13. I think it makes sense to have a (limited) amount of versions to pick from, just like with Python 2, 3 and 3.7 or GCC 8/9.
Re: openjdk-8 removed from Buster?
Andreas Schildbach: > On 24/04/2019 10.56, Emmanuel Bourg wrote: > >> Yes, we've worked hard on the transition to Java 11, fixing more than >> 500 issues over a year. Incompatible packages have been either upgraded, >> fixed or removed. The notable exception right now is netbeans (#925509). > > The other notable exception is building apps for Android, since the > versions of Android Gradle plugin you can use due to Gradle 4.4 are > quite old (and the version included in Debian is ancient). > > I'm happy for now that at least Ubuntu decided to keep OpenJDK 8 in its > repository. (I'm responding mostly as an FYI, I think it is OK for Debian to drop OpenJDK 8.) It is also not possible to run upstream Gradle binaries older than 4.8 or 4.7. It is a stupid bug on Gradle's part, but nonetheless, those versions work with OpenJDK 8. I guess the Debian package of gradle fixed the issue, since it is gradle 4.4. Android Studio ships with its own (really old) embedded copy of OpenJDK8, so Android developers on Debian will need to do: export JAVA_HOME=/path/to/android-studio/jre .hc
Re: openjdk-8 removed from Buster?
Hello, Am 29.04.19 um 17:29 schrieb Thomas L: > It seems that openjdk-8 was also removed from jessie-backports. > Why? Is it a mistake? jessie-backports is obsolete and no longer supported. Regards, Markus signature.asc Description: OpenPGP digital signature
