Re: OpenJDK 21
On Thu, 11 Jul 2024, Matthias Klose wrote:
> We will have to keep m68k as pointing to 17 for now.
What, other than the test dependencies, is missing for m68k?
I uploaded a t64-installable hacked 20 so we can bootstrap 21.
Maybe there are some patches that need updating?
Could you maybe do something like:
ifeq (,$(filter ${distrel},wheezy jessie stretch buster bullseye bookworm
precise trusty xenial bionic focal jammy mantic noble oracular))
# Debian testing/sid
ifneq (,$(filter ${DEB_HOST_ARCH},m68k sh4))
# xfwm4 B-D for testing not available
with_check = disabled running check on ${distrel}/${DEB_HOST_ARCH}
endif
nocheck_profile = ${NULL} [!m68k !sh4]
endif
The qemu-user buildds for these two architectures set nocheck
anyway currently still, so this won’t be a regression in practice.
xfwm4 has very heavy dependencies including cyclic. Are the tests
tied to it or would say twm or evilwm suffice? (I normally would
recommend icewm, but it’s got a good part of the same too-heavy
dependencies.)
bye,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
Re: Builds not reproducible on armhf
On Mon, 20 May 2024, Mechtilde Stehmann wrote:
> There are several with FTBR. I found that the day of the *.poms s a date from
> 1970.
I’ve had a look at this. The files have various, *differing*,
timestamps within the month of January 1970, which in itself
is not proper.
It’s not a t64-related JDK bug: I tested…
import java.io.*;
class T1 {
public static void main(String args[]) throws IOException {
File sf = new File("T1.java");
File df = new File("T1.out");
System.out.println(sf.lastModified());
InputStream is = new FileInputStream(sf);
OutputStream os = new FileOutputStream(df);
byte[] data = new byte[32768];
int nbytes = is.read(data);
os.write(data, 0, nbytes);
os.close();
is.close();
df.setLastModified(sf.lastModified());
}
}
… on armhf with OpenJDK 8, 17 and 21 (11 needs t64-transitioning).
Given the range of January 1970…
$ TZ=UTC date -d '1970-01-31T23:59:59Z' +%s
2678399
$ TZ=UTC date -d @2678399000
Sun Nov 15 23:43:20 UTC 2054
… it is entirely possible that someone confused time_t and
Java millis, so the timestamps are off by a factor of 1000.
-rw-r--r--···0·root·(0)·root·(0)·1415·1970-01-06·08:03:05.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
-rw-r--r--···0·root·(0)·root·(0)·1415·1970-01-03·13:27:14.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
-rw-r--r--···0·root·(0)·root·(0)·1416·1970-01-09·01:36:03.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/vinnie-debian.pom
-rw-r--r--···0·root·(0)·root·(0)·1416·1970-01-04·21:40:23.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/vinnie-debian.pom
$ for t in 1970-01-06T08:03:05 1970-01-03T13:27:14 \
1970-01-09T01:36:03 1970-01-04T21:40:23; do \
TZ=UTC date -d @$(TZ=UTC date -d "${t}Z" +%s)000; \
done
Fri Aug 10 11:23:20 UTC 1984
Tue Jan 4 13:53:20 UTC 1977
Sat Feb 1 16:50:00 UTC 1992
Mon Sep 8 01:03:20 UTC 1980
Okaaay… So, maybe not so much. I *was* guessing something with
DEB_SOURCE_EPOCH vs. project.build.outputTimestamp, but that’s
apparently not it either.
So I fear someone’ll have to dig through all the various Maven-
related source packages…
FWIW, the 517-day-old .deb currently in the repo has…
-rw-r--r-- root/root 1415 2022-12-17 18:36
./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
… which matches Sat, 17 Dec 2022 18:36:19 +0100 from d/changelog,
so something something reproducible-builds is still suspect.
Good luck with that,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
Re: Tomcat 9 removed from Debian 12
Hola Luis,
> I know that the remove tomcat9 packages was done on December of 2023 and that
> this was decided a long time ago. But I think that nobody has stopped to
> consider that you *cannot simply migrate from Tomcat 9 to 10 *(inserte here
I have. I currently maintain the tomcat9 package externally,
and I have users who use it for their customers so it’s used
in production, with sysvinit instead of systemd, even.
The packages are here:
http://www.mirbsd.org/~tg/Debs/dists/bookworm/wtf/Pkgs/tomcat9/
Don’t just install them from there, though, that would not
be secured. Ideally, you’d use the Debian package “extrepo”
to enable the “wtf-lts” repository, then pin it so that only
the packages tomcat9{,-admin,-common,-docs,-examples,-user}
and libtomcat9-{,embed-}java are considered from that repo.
Alternatively, http://www.mirbsd.org/~tg/Debs/debidx.htm
contains links to manual installation instructions, but you
might still want to consider pinning as the repo contains
other packages as well.
Full disclosure, while I’m a Debian Developer and team member,
Emmanuel has veto’d the changes to the tomcat9 package in the
past (mostly on the grounds of using adduser… *sigh*). I also
haven’t tested installing it together with tomcat10, and I
personally don’t test on bookworm (but others do), only on
bullseye and sometimes buster.
> because the javax.* to jakarta.* packages problem
Upstream Tomcat says they can convert that automatically,
but I wouldn’t rely on just that because from experience
I know that upgrading the Tomcat version is always a
breaking change that needs changes to all applications.
bye,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
Re: Removing freeplane 1.7.x from Debian?
On Sat, 6 Apr 2024, Emmanuel Bourg wrote: > since upstream already provides a package. That is not a justification appropriate for a Debian mailing list. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Wookey dixit: >And it worked beatifully. Thanks. Nice! >I'll try doing openjdk-20 next. You’ll want 21 as 20 has not got the t64 treatment. gl hf, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Wookey, >OK, got those. but that's just binaries. It was the source changes I >was looking for (or did I misunderstand and you didn't actually make >any of those?), Yes, I did not make any source changes. These were the last binaries from before the t64 transition (I downloaded the .deb files unchanged) with just control.tar.xz/control changed to allow installation given the relevant libraries were already rebuilt for t64. > but actually having an openjdk binaries is very useful >too to satisfy the self-dependency without more faff. Yes, that was their purpose. >I'm no java expert so if anything breaks or it gets more complicated >than 'get the right build-deps in (with care for t64-libs) somehow' I >will indeed be asking questions :-) Right. I’m no expert either, though :/ >> What was the actual problem with uploading the images you built? Just >> not having any corresponding source? Or something more complicated? > >Answering my own question: There have been a couple of new openjdk-17 >uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build >(17.0.10+7-1) is out of date. Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already moved to 17.0.11~7ea.orig.tar.* >So I now have all the pieces (on armhf, not checked armel yet but >hopefully it matches) Depends, but 'apt install /tmp/*.deb' will tell you ;-) >The build failed: > >An exception has occurred in the compiler (17.0.10). Please file a bug against >the Java compiler via the Java bug reporting page (https://bugreport.java.com) >after checking the Bug Database (https://bugs.java.com) for duplicates. >Include your program, the following diagnostic, and the parameters passed to >the Java compiler in your report. Thank you. >java.io.UncheckedIOException: java.nio.file.FileSystemException: .: Value too >large for defined data type > >Don't worry about this. It's a an issue to do with building for 32 bit >inside qemu on a 64-bit machine. I'll stop doing that and use real >hardware :-/ Ouch. I was just wondering which filesystem you used, but yes, there’s that known combined qemu/kernel/libc issue which cbmuser is also constantly running into. I think switching to… sgixfs I think? also makes it work, but I’m not sure. https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c73 sgixfs and btrfs, yeah, ext4 is problematic. But apparently, LFS should fix this but Java is again special in that it’s still problematic there. Were you using qemu-user? qemu-system has its own kernel and “should” be fine, modulo the usual qemu issues. Real hardware is better (for many architectures even necessary). Good luck, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Wed, 27 Mar 2024, Wookey wrote: >I looked at this last week, but got stuck because openjdk-17's >build-deps included graphviz Build-Depends-Indep: graphviz, pandoc You don’t need that. Use dpkg-checkbuilddeps -B, or manual inspection of the .dsc (packages.d.o does show the difference between adep and idep but not the profiles, unfortunately, and these can be key in ordering decisions). >another blocked chain with ghostscript,cups and libgtk2 conflicting >about their t64 status. You do need the t64 versions of all that, and the latest openjdk-17 fixed the issue with libcups2 (Ubuntu initially forgot to move that to t64 while Debian did that early, and openjdk-?? followed the former). > apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed You should get that rebuilt, yes. On the other hand, if everything else is falling into place, it’s not a problem for apt to uninstall itself just in that one build chroot ☻ > libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be > installed > libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed > libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be > installed These are fine. > libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed Force that away; nothing from this is actually used during the openjdk build in a way sufficient to impact the build. >But dose now says there is a solution, unlike last week. Oh, dose… right… here I was checking all of them manually ^^ (which did give me a better impression of where to break the cycles and what to upload earlier). >> openjdk-21 is in a similar situation, build-depending on itself, while >> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. >I presume the same, but don't actually know how old a java you can use >to bootstrap each newer java. Is it always just one version? AIUI it’s always just one version; I know it was so until 17, but I don’t think this has loosened (I asked in IRC, but got no answer until I went to sleep). >> Presumably once we have a single OpenJDK version that is installable, >> it would be possible to step through 18,19,20,21 building each version >> with the previous one. You’d have to patch them to both address the t64 issues and make it imply nocheck (or quinn-diff doesn’t pick it up as installable). It’s best to get at least 17 and 21 (which AIUI is the one we’ll want for trixie?) built this way. I think, unless users complain, we can these days go without 8 and probably even without 11. (You’d be surprised at the amount of users wanting 8, so I now provide those in a private repo of mine, but so far amd64/i386-only has sufficed for those. For the purposes for which 8 is still in sid, dropping armel and armhf will _most likely_ also suffice; ELTS still wants them, but rebuilt in jessie and stretch chroots so there is no re‐ bootstrapping to be done.)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, 26 Mar 2024, Jeffrey Walton wrote: >Nothing beats a native compile in your basement. Yes, definitely. >> Do they run stock Debian armhf? > >So the CubieTruck is embarrassingly down level: Oofff… >The Wandboard is doing better: Right, close enough anyway. >I don't mind shipping to Europe if you don't mind paying the VAT. I >think you will be the fourth or fifth Debian maintainer I've sent >hardware to. So sending from outside the eurozone, that can get tricky fast (depending on the value, they also want import duties on top), I think that might just be overkill for a oneshot helping out. Let’s see if I can get an account on a project box first, or work with someone who has. (I’m not intending to add going into ARM development on top of what I already try to balance… right now, I’m mostly helping m68k through t64, so Adrian does not burn out, he’s also got sh4 and powerpc to do, and the whole rest of d-ports with the mini-dak trouble of keeping old binary packages around.) But I do thank you for that offer. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Jeffrey, I’m answering back from the $dayjob address because Googlemail cannot communicate with normal mailservers. >I can send you two dev boards, if you want them. The first is >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I >don't use them much anymore. I've mostly moved on to Aarch64. That is certainly an option, if you don’t want them any more and want to ship them to .de, although it’ll likely take longer than just getting access on a suitable project machine. RAM is tight on them, but with swap the compiling should work. Both seem to have serial console, good. Do they run stock Debian armhf? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.
I did the observation that doko changed their source packages
to have the binaries Recommend instead of Depend on the libraries
in question. (Unfortunately neither before the transition started
nor coordinated with the openjdk-8 maintainer (me).)
I downloaded the latest binary packages of openjdk-{8,11,17,21},
changed all references to the libraries in question to refer to
their t64 counterparts, bumped the version number, repacked the
.deb files and updated the .changes files as if to do a binNMU.
After uploading, I used wanna-build to set the priority high so
they get rebuilt before someone considers using them.
mini-dak accepted these, but dak requires that the archive has
the corresponding source available, and since new versions (the
part before the Debian hyphen-minus) had already been uploaded,
it did not have them at hand any more either.
The rebuild process succeeded, as openjdk building itself does
indeed not use the libraries in question (or at least those
parts of their interface that are time_t-relevant).
I don’t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I’m not in the situation of throwing the
.debs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we’re using #debian-ports on OFTC for the
d-ports architectures and I couldn’t find out where to write to
for arm{el,hf}, so this mail of yours comes at a good time ;-)
The options for the armel/armhf porters are to either get the
.debs from me, install them in a chroot, and then the other B-D,
and rebuild the packages, or to use dpkg --force-depends to
install the dependencies (which makes it hard to use apt to
install the other ones unless you also edit /var/lib/dpkg/status
by hand first, something I was already used to from my reviving
m68k back in 2012–2015) into the chroot then rebuild there.
I will gladly help if it’s made possible for me to help. This
cannot be done on a porterbox because it’s still impossible to
either install arbitrary .debs into a chroot there or to obtain
root in the chroot to be able to force installation in the absence
of some Depends.
So if you have a fast armhf box or two, ideally with chroots
already made for sid, which you don’t mind temporarily giving
me root on, I’m in, otherwise I’ll answer questions from these
doing that work if needed.
I *think* 8/11/17/21 are the only versions we need to handle.
This does save us from having to rebootstrap this.
bye,
//mirabilos
- --
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８ ☕☂☄
iQIcBAEBCQAGBQJmA0vXAAoJEHa1NLLpkAfg0ZQQAI7P7qoVfADQrrsuNHAShvTB
lRvuK1br7bHRmqUx89dDwjOG1k0Xji3X3OURZldlhPCk99SJxQP3DLoCX5cmCzIA
IDyq+GoxREjJ/uyb4b6/qTAgSh7ZdRqxEfbVLsukL1i+wRs6dNw2Wg64i/R538jE
+yncg7zMyrWSA+3815i7BRfdMZBEk9E1qgW3hlnhueVfgANuyBLzzJchSstjunqE
0OcIukVQ30HaWaALmAfGcl7lcfM0sUFXL+EVpA8aBsVWNzZHtMIPnmI+yx8X4NOo
BOkfcYbPI928VZ/91meibSb9FXk8ShnO+zv+gU6dX74RlVoqOIeg6UQ/r2Cy+Up9
ssnksqTWTSkw1/n9bRNNiU8/O4kI5xV6FCUk2CaOsk+diQfXpoga50TR6DRM52tp
mjtBetkI1qK9vA0Y1VS+KoPp/FDYwFBKXiU3Jax9L7koaT5wGCurILqNTbDGVe19
2nmnphBUeIFniPByiItSEv7jH9GgxZyrwRvonYYpDXNeXFa0ymTNzKzrIG2ZqMrz
LcELgtIb6OD+WDYajUMOlTRBj2N9rFodruKyMcdUfc4so3OoFnS3cOdBvWBk/NdX
sFRgES39Ak5xgA3f4hP2ba03KZOFH2iIT3M8ZtZhH7eOIdhErKIUG0t6hxpWFdiV
ntE5WUlefRxovhbTOXKa
=KoS1
-END PGP SIGNATURE-
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: jtreg7: request to vendor the dependencies
On Wed, 18 Oct 2023, Vladimir Petko wrote: >jtreg7 depends on a number of test-related packages (junit4, junit5, >libhamcrest-java) that require transitive dependencies such as picocli >or opentest4j-reporting either introduced (that is not an issue) or >upgraded. Standard answer is that these must be packaged separately. >A new point release of the package in the stable release requires >careful testing and ensuring that there is no impact on reverse >dependencies. Right. Please talk to stable release maintainers and security people and ask them how they’d prefer to have this handled. Do also include Doko (as openjdk-?? maintainer). bye, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Re: Can someone tell me if this bug is in the proper state?
On Fri, 11 Aug 2023, Vladimir Petko wrote: >As far as I know, the bug was fixed in [1] which is safe to update to. 20230620~deb12u1 is in bookworm-p-u which you could enable to get that kind of fixes for stable earlier; it’ll otherwise be in the next point release. 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: 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: how to handle 'resources' best
On Thu, 6 Jul 2023, Andreas B. Mundt wrote: >The 'resources' are expected relative to /usr/share/java/filius.jar in >directories (i.e. config/filius.ini). How is it best to handle this >situation? Is it possible to tweak the path somehow (in the wrapper >script?) or do I need to patch the sources? Right now, I copy the >resources to /usr/share/filius/. If “filius” is an end program, not a library that others could use, I’d say place the JAR and resources both in /usr/share/filius/, skip putting the JAR into /usr/share/java/. But that’s just my opinion, others can put in something from best practices or so. 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: Re: jar missing in /usr/share/maven-repo/
On Wed, 5 Jul 2023, Andreas B. Mundt wrote: >after that. However, when I try to start it, I get: > > $ java -jar /usr/share/java/filius.jar > Error: Unable to initialize main class filius.Main > Caused by: java.lang.NoClassDefFoundError: > ch/qos/logback/core/joran/spi/JoranException I think you have to do: java -cp /usr/share/java/logback.jar:/usr/share/java/foodependency.jar:… -jar /usr/share/java/filius.jar It’s common to put that into a tiny shell script in /usr/bin. 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: 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!
(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-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
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!
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!
Re: packaging filius
On Sat, 13 May 2023, Andreas B. Mundt wrote:
>{htmlparser.version}
At the very least, there should be a $ before {
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: Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)
On Tue, 18 Apr 2023, Per Lundberg wrote: > A short update on this. This is a known regression in more recent versions of > Java: https://bugs.openjdk.org/browse/JDK-8226919 > > One of my colleagues (thanks, Sebastian!) managed to workaround this by > patching the JDK 17 sources to make it use plain /tmp in this case (when > ns_pid > == pid), and also added some better error handling in case this fails. > > We are currently working on getting this submitted upstream to OpenJDK, but I That’s a good path. > wanted to share it with you as well. One option would be to include this in > Debian's set of local JDK patches Shouldn’t this be added to 11 as well? Apparently, both are affected. > but I don't know how conservative the project is re. fixes like this? I'll > leave this up to the debian-java maintainers to decide. The OpenJDK (except for 8 which the ELTS people and I mostly work on) is not maintained by the debian-java people but by Doko. The usual way to hope for inclusion is to clone the bugreport, assign one to src:openjdk-11 and the other to src:openjdk-17, mail the patch with a description, add the tag patch and pray. 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: Packaging applications with JVM version restrictions
On Tue, 18 Apr 2023, Loïc Rouchon wrote: >targets the lowest installed JVM which version is greater or equals to I’m very much not fond of this approach, because who’s to say you want the lowest? I’d rather have the local admin or invoking user specify the version to use if the default version is not it, and if you have to run two incompatible ones from a script then you have to set an environment variablke at some point inside that script and so be it. Besides, what’s compatible? Some things may run with an older/newer JRE but others won’t. And how are you going to retrofit anything new to the old JDKs/JREs now? We cannot simply add new things now to old releases. 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: Packaging applications with JVM version restrictions
On Mon, 17 Apr 2023, Rob Browning wrote:
>Is there Is there a policy or preferred way to handle a package that
>needs a particular version or versions of java? e.g. say it doesn't
>work with < 9.
From a Depends standpoint, java9-runtime-headless or java9-runtime. But…
>I could imagine it might not want to just rely on /usr/bin/java because
>you might not want it to break if the system has 8 and 11 installed, and
>then the local admin changes the default to 8 via update-alternatives.
… this is, indeed, possible: the Depends simply means it’s present,
not the default. (And that is a good thing.)
>To avoid that, I imagine the application's /usr/bin/something could
>examine $(update-alternatives --list java) to find a suitable version,
>but is that reasonable, or is there a preferable approach?
I’m a bit wary of auto-selecting something. I’d instead check whether
${JAVA:-java} has the right version and complain when not. Possibly
check whether $JAVA_HOME is set (which it isn’t in a regular Debian
one-JRE installation) and use that if suitable instead of complaining.
(Where complaining means echo "E: some msg" >&2; exit 1)
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: Bug#1034059: marked as pending in zstd-jni-java
On Sun, 9 Apr 2023, Markus Koschany wrote: >maven-compiler-plugin. Usually this just works without changes to the version >number. I don't think a strict plugin dependency is the true solution but it >might help future contributors to remember the RC bug. Also not a real fix but more sustainable might be to just always do an indep build when also doing an archdep build, as that apparently does not have this bug? 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!
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: OpenJDK package - JTREG 7.1
On Thu, 16 Mar 2023, Vladimir Petko wrote: >Regarding using jtreg6 for tests of openjdk-8 it should be noted that >some tier1[1] tests fail with jtreg6. Lots of tests fail there anyway, also due to lack of asmtools. >For instance jtreg 6 fails: […] >and with jreg 5 those tests pass: […] >There are more instances like this and if it is of interest I can >provide a full comparison. Might be useful to pass that on to the 8u developers. I won’t be doing anything with it and the ELTS people are mostly interested in comparing test results against the previous upload’s, to see that nothing broke too badly. If upstream makes their tests jtreg6 compatible all the better. >Would it be possible to consider keeping jtreg 5 version around in No, we’re targetting jessie and stretch with openjdk-8 mostly, which lacks jtreg 5 and where the backported jtreg6 really helps, without, we had to disable the tests entirely. 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 package - JTREG 7.1
On Wed, 15 Mar 2023, Vladimir Petko wrote: >Since I can not upload I will file the ITP then. Depends on your sponsor, whether they insist on one. But, go ahead. >Would it be ok to >keep ownership with the Debian Java Team in line with jtreg6? Usual procedure is that for team-maintained packages, the Maintainer field is the team and the Uploaders field has at least one human who ideally is the primary maintainer for that package; this can be a nōn-Debian member. 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 package - JTREG 7.1
On Tue, 14 Mar 2023, Vladimir Petko wrote: >jtreg6 (in line with jtreg6 packaging which kept jtreg changelog). Was >it a correct thing to do, or should it be truncated? You can keep it; debhelper can now truncate it. >I could not find an ITP bug for jtreg6, does it mean that there is >some other process that I need to follow? ITPs are not necessary, only “nice” (e.g. to avoid duplicate work). If you consider it uploadable, upload it ignoring the lack of ITP. 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 package - JTREG 7.1
On Fri, 3 Mar 2023, Vladimir Petko wrote: >It is definitely an option to chase those errors and failures down and >ensure that basic tests pass with jtreg 7.1.1, but keeping around >jtreg6 for JDK 17 and jtreg7 for JDK 20 is probably an easier option >that will not require a lot of maintenance overhead. Thanks for investigating. Yes, you’ve got convincing arguments, as it’s not a drop-in compatible replacement ☺ 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 package - JTREG 7.1
On Thu, 2 Mar 2023, Vladimir Petko wrote: > Unfortunately jtreg6 is required. 6.1 is used by OpenJDK 17 and 6.1.1 I only see an “is used by” there, not a “requires this but cannot work with a newer version”. Upper bounds are often much more flexible, see openjdk-8 using jtreg6 now for example ☻ That’s why I ask to investigate 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: OpenJDK package - JTREG 7.1
On Thu, 2 Mar 2023, Vladimir Petko wrote: >OpenJDK 20. We still need jtreg6 and jtreg packages for older >versions of OpenJDK. openjdk-8 was switched to jtreg6 recently. See if doko will follow for 11. >I was wondering if it would be acceptable for me >to file an intent to package proposal for JTREG7 and package it? Sure, why not (unless someone else is already working on it). Is a new package needed anyway? Can’t this just be an upgrade to jtreg6 (sure that will then look weird as jtreg6 version 7.1-1 but we have lots of such situations)? Is it incompatible somehow? 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: ca-certificate-java/openjdk installation issues
On Fri, 24 Feb 2023, Vladimir Petko wrote: >The issue is the migration procedure - those packages have to be >published together to avoid any nasty surprises. Yeah, we’ll have to pick a time to do that, which is after the bookworm release anyway (it’s not okay to upload things to unstable right now that are not targetting the release, and only small targetted fixes, not big changes). >- call update-certificates-java trigger after update-alternatives in >every jre-headless postinstall script Is this REALLY necessary? AIUI triggers it shouldn’t, with the correct invocations. Please do talk to people who know about triggers well. >Potential problem: >- update-certificates-java trigger logs appearing multiple times when >different openjdk versions are installed at the same time dpkg should merge them, but even if not, triggers must be omnipotent anyway, so that’s not a problem. 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: ca-certificate-java/openjdk installation issues
On Fri, 24 Feb 2023, Vladimir Petko wrote: >This is possible to do if we update openjdk packaging and make it >trigger certificates-ca-java, so that it always runs after the openjdk We can do that easily. I maintain 8 and doko the rest (I hope). If that’s needed, i.e. if there’s no other way, that is. (And this should not break with older ca-certificates-java, like in jessie/stretch-ELTS.) >Please get well! Thank you. 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: ca-certificate-java/openjdk installation issues
On Thu, 23 Feb 2023, Vladimir Petko wrote: >Notice that ca-certificates-java attempts to process triggers before >default-jre is set up. This is exactly the condition we are trying to >avoid. It should run them again, and there’s got to be a way, but I’m not a triggers expert and currently ill, please get some input from people who know better about dpkg triggers. 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: reply: Bazel Removal from Debian
On Thu, 23 Feb 2023, sun min wrote: >It seems that the build system's local jdk overrides those jvm >parameters we defined in bazelrc or bashsrcript. How about asking Doko to locally add that parameter to 17 as a Debian-specific patch, just ignoring it? (And, ideally, warning.) 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: ca-certificate-java/openjdk installation issues
On Wed, 22 Feb 2023, Vladimir Petko wrote: >Alternative is to go with two packages: one for Java 11 and onwards >that does not use Java-based import, and the other - classic >ca-certificates-java with the trigger updated to watch Java 8? (this also confuses me, why would 8 be special?) 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: ca-certificate-java/openjdk installation issues
On Wed, 22 Feb 2023, Vladimir Petko wrote: >The existing trigger "interest /usr/lib/jvm" causes the import to run Unsure, I only used triggers once, a decade ago or so myself, but isn’t this what the interest-await trigger method is for? 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: ca-certificate-java/openjdk installation issues
On Wed, 22 Feb 2023, Vladimir Petko wrote: >in sync. A possible scenario is CA being revoked, which results in an That’s why I was suggesting to keep it down to manually vetted relevant ones. But if that’s unpalatable (do talk to the security people!), ship an empty JKS keystore by default. The JKS keystore will have no nōn-Java users, and soon as the JRE is there it’ll be regenerated. This all won’t make bookworm any more either, so no need to be hasty. 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: ca-certificate-java/openjdk installation issues
On Wed, 22 Feb 2023, Vladimir Petko wrote: >Just a small clarification, openssl itself allows importing a single >certificate and its chain and overwrites the store in the process, so >we need something like p11-kit. >Another grey area is ORACLE_TrustedKeyUsage attribute - at the moment Ugh. How about doing it the “low-tech” way: – ship a minimal JKS keystore with bin:ca-certificates-java, generated at build time, that contains a manually vetted list of roots, perhaps just what’s relevant for Debian – use a Recommends to get at a JRE – with trigger, generate a full keystore, once a JRE is there (The shipped one would need to be in /usr/share/!(doc) and copied so overwriting it with the generated one works and we’ll probably need to track hashes of shipped ones so we can honour admin choices to override the keystore if needed.) 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: Java 8 security patching
On Mon, 13 Feb 2023, James Kennard wrote: >Yes, it has been a long time now, but it's taken time for the alternatives >to gain traction. I was just trying to understand the current state of play >to help work out how and when to move away from openjdk-8. We’ve already moved, as a whole, to openjdk-11 and even 17 in 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!
Re: Java 8 security patching
On Mon, 13 Feb 2023, James Kennard wrote: >With the changes to Java licensing What changes? It’s been GPLv2 + Classpath exception for *ages* now. >, alternative distributions of Java have >become increasingly popular. They all have their pros and cons, Perhaps, but we’re still talking about the openjdk-8 package here, which, you know, ships OpenJDK 8… 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?
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?
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: Java 8 security patching
On Fri, 10 Feb 2023, James Kennard wrote: >Is there a particular reason why you are continuing to update it as opposed >to recommending people switch to an alternative distribution such as >Temurin? I don’t know what Temurin even is. While I do recommend that people switch to default-jdk, and in fact we have been needing to use at least 11 in development for a while because Maven plugins from Central didn’t work with 8 for some time even when intended to, some customers still run prod on 8, so we need it for testing. (Or, at least, used to; I’m currently not in a Java project at work.) I also have been supplying a customer with openjdk-8 as jessie backport before it was in backports itself, then ELTS. (The mentioned customer is also no longer in a situation to receive/need these, but this gives historical context.) I just did not cease updating 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: help with plugin versions and maven-debian-helper
On Fri, 10 Feb 2023, Emmanuel Bourg wrote: >>> - Drop the +ds suffix >> >> Why? Isn't that traditionally used to show a repack? > > I have a preference for clean version numbers. The suffix is useful > if a version was already packaged and needs to be modified afterward > because unwanted files were included by mistake. DevRef §6.7.8.2 indicates that using such a suffix for *all* repacked origtgz is better. 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: help with plugin versions and maven-debian-helper
On Fri, 10 Feb 2023, Vladimir Petko wrote: > Sorry for jumping into the discussion, but it looks like maven-helper >deploys > jar files slightly incorrectly. I think this is an open bug where it’s still under discussion whether to fix it there or change the java policy instead. (Your eMail lines are much too long.) 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: help with plugin versions and maven-debian-helper
On Thu, 9 Feb 2023, Emmanuel Bourg wrote: > The content of the binary package is perfect. Nice trick in debian/control > to reuse the same description, I didn't know that was possible. These tricka usually lead to *really* awfully useless .changes files though, unfortunately. 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: Java 8 security patching
On Wed, 8 Feb 2023, James Kennard wrote: >How long will Debian continue to provide a build of openjdk-8? And how long >will Debian continue to apply security patches to openjdk-8? The ELTS team is going to support openjdk-8 in jessie and stretch for as long as they get paid for (see the ELTS project’s pages for more information). Currently, they’re coordinating with me, I’m uploading new releases to unstable to take as base for the backported builds as time permits and sponsored by my employer (see below); however, openjdk-8 in sid is not officially supported in Debian and has not since 2019-07-06 if not earlier. For a given release, only default-jdk is supported; that is 11 for buster and bullseye, and 17 for bookworm; any other JDK that mey be available is either legacy compat or technology preview and completely unsupported (modulo individual volunteer effort as usual). If you need some level of support for openjdk-8, I suggest to contact Freexian (the ELTS coordinator). For uploads to unstable to continue, you might want to contract my employer so I can continue to do this, as it takes a couple of person-hours each quarter plus extra love for e.g. getting the tests to pass better. I also have an APT repository in which I publish builds of openjdk-8 for wheezy (EOL though), buster, bullseye and even bookworm (those not covered by ELTS), and a PPA at Launchpad in which I do the same for *buntu LTS releases; if you have interest in these I might also be made available via my employer. (The repositories are currently available to the public but unsupported. I also can only build for x86 at the moment.) 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: ca-certificate-java/openjdk installation issues
On Wed, 8 Feb 2023, Vladimir Petko wrote: >This functionality can be implemented using the following Python packages: […] Make that an “or” dependency then, so that people who already have the JVM installed don’t need to pull tons of Python3 packages. 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?
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 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?
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: Tomcat 10 packaging
On Mon, 12 Dec 2022, Emmanuel Bourg wrote: > There is another benefit of a versionless package: backport continuity. When > the tomcat package replaces tomcat in testing/unstable, it's no longer > possible to update the tomcat backport in stable (because the version must > exist in testing). With a unique tomcat package we can keep updating the > stable > backport even after upgrading to a more recent release in testing. Downside: no tomcat update for stable users any more, they will be forced to tomcat prematurely. It might be possible to get a backport exception and/or keep in testing until just before the release to ease 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: OpenJDK for Bookworm and beyond
On Fri, 11 Nov 2022, Emmanuel Bourg wrote: > once the system > is upgraded to bookworm, openjdk-11-jre will not be updated anymore and a > manual update to openjdk-17-jre will be necessary at some point. Yes, but if this is precisely the desired outcome… > Why worse? sid users will be the first to receive the updated openjdk package > with the versioned java-runtime dependency. That can be the problem. 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 for Bookworm and beyond
On Fri, 11 Nov 2022, Emmanuel Bourg wrote: > default-jre-headless | java11-runtime-headless > > Let's assume this is changed in bookworm to: > > default-jre-headless | java-runtime-headless (>= 11) > > Considering a tomcat9 user upgrading from bullseye to bookworm, there are two > cases: > > 1. the default JRE was used on bullseye, default-jre-headless and > openjdk-11-jre were already installed. During the upgrade, openjdk-17-jre is > pulled (required by default-jre), openjdk-11-jre remains (but could be removed > manually), and tomcat9 expects java-runtime-headless (>= 11) which is > satisfied by both default-jre-headless and openjdk-17-jre-headless. Tomcat > will run with OpenJDK 17 and all is fine. 3. openjdk-11-jre-headless was used in bullseye (most people I know do this to avoid the needless metapackage), the user will end up with both because the Provides on java-runtime-headless in bullseye was unversioned but maybe they don’t (worse if the package is backported). It’s worse for sid users, especially for rare cases. gn8, //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 for Bookworm and beyond
On Thu, 10 Nov 2022, Emmanuel Bourg wrote: > But openjdk-17-jre also provides java11-runtime. So even with: > > default-jre (>= 2:1.11) | java11-runtime > > there is no guarantee Java 11 will be used. That’s not the point. That much is true, but the point here is that the user *CAN* use Java 11, *if* they have installed it beforehand, i.e. that they are not _forced_ to upgrade. If they don’t have it installed, the default-jre will be installed anyway. This is about not forcing, possibly multiple, unnecessary JREs. 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 for Bookworm and beyond
On Thu, 10 Nov 2022, Emmanuel Bourg wrote: > better. But I don't see the need to wait a decade before using the versioned > java-runtime dependency in the packaged applications, what issue do you > foresee? The application defines default-jre (>= 2:1.11) | java-runtime (>= 11) but openjdk-11-jre does not yet Provides java-runtime, only java11-runtime. This will force the user to 17. (Same for any other version pairs, really. Also consider backports and partial upgrades.) 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 for Bookworm and beyond
On Tue, 8 Nov 2022, Moritz Mühlenhoff wrote: > Do we even have to keep 8 around in unstable at this point? If people > want to bootstrap kotlin or scala for a new arch, why can't this > happen on a buster system? AIUI this is not a :any issue, but an issue of bootstrapping one new enough to run with a newer JRE, from one that runs with an older one, i.e. 8. 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 for Bookworm and beyond
On Mon, 31 Oct 2022, Emmanuel Bourg wrote: > Also worth noting, default-jre now provides a versioned java-runtime > dependency. This means we can now replace the java-runtime dependencies > with java-runtime (>= n). No, we really should not: the various JDKs also only provide java-runtime and this dependency is specifically meant to also make it possible for software to use a JRE *other* than the default (the dependency reads like default-jre (>= x) | javaX-runtime by design/for a reason). Given how they stretch across versions and how many releases are supportable (ELTS from jessie on, *buntu from trusty on) I will argue that if and only if the openjdk-X source packages also start providing these _now_, that we can start switching to the versioned java-runtime provide in 2030, maybe later. 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: Status of antlr4 in Debian
Hi Pierre, >java.io.InvalidClassException: org.antlr.v4.runtime.atn.ATN; >Could not deserialize ATN with version 4 (expected 3) what exactly does it deserialise there? Is this maybe something that we should build from source in the Debian packaging instead? That would also solve your issue, probaby with less effort and additionally more DFSG-correctness ☺ 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 for Bookworm and beyond
On Thu, 29 Sep 2022, Emmanuel Bourg wrote: > > Who’s going to maintain that? > > I don't think the maintenance is a concern, we only have to ensure it > keeps building in sid. Yeah well, that’s maintenance, and that was missing for 8 as shown in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981811#5 > It's just to compile stuff in sid, not to run critical > production systems. If it’s used to base security updates for bullseye on, then no, it’ll be used to run critical production systems (indirectly: not the sid binaries, but the others). > > So I think we should keep 11 around *only* if someone (could be Doko, > > could be someone else) commits to maintaining it. If nobody does, Scala > > and Kotlin are SOL. > > I don't mind for Scala, but Kotlin can't be ignored unfortunately. Its > integration into Gradle makes it an essential part of the Java ecosystem. Then we should find something who takes on the maintenance burden. 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 for Bookworm and beyond
On Thu, 29 Sep 2022, Emmanuel Bourg wrote: > previous releases is kept. This scenario is likely to continue in the future > since the Debian and Java releases are now synchronized on the same 2 years > cycle. We could always delay Debian’s… (SCNR) or petition upstream to change theirs. > Assuming OpenJDK 17 users also have OpenJDK 11 installed that's about That is probably not a safe assumption. I have run into issues with more than one JRE installed, so I only ever install one. (But I doubt it matters much, for the larger picture, anyway.) > This is a significant share of users and it shows the extra effort > involved in maintaining an additional JDK is worth it. I think we have to distinguish between using the JDK/JRE as B-D/Depends of Debian packages, and using the JDK to develop and/or the JRE to run “other” software. For the former, we’re never going to get all software switched over to work with the newer one in time, especially considering we’ve apparently not switched the default to 17 over a year past the bullseye release. For the latter, I agree-ish. For bullseye and 17, we have https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#openjdk-17 which boils down to “11 is supported, 17 is not but we provide it as best-effort”. I think this suffices for the “other software” case. > Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping > of some packages that can't build directly with the latest JDK (more > specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK > 11 in unstable after the transition to OpenJDK 17. Who’s going to maintain that? For OpenJDK 8 I took over because, for quite some time (but not for a while) we had customers for whom I built this for older and newer Debian and *buntu releases. I’m now basically doing it because I started it, not because I have use myself any more. Doko dropped it, incidentally because of a bug he, with toolchain maintainer hat on, reported himself, and Tiago isn’t in a position to maintain things any more either AIUI. I am not going to take over 11 as well. (But if someone else wants to, I’d gladly share knowledge and experience. Or see my last paragraph.) History has shown that the (E)LTS contributors can and will do this on their own anyway so having 11 in sid to stage security support is not strictly necessary. If maintained, it is beneficial because then we’ll have a consistent state across releases. If unmaintained, however, not having it is better. So I think we should keep 11 around *only* if someone (could be Doko, could be someone else) commits to maintaining it. If nobody does, Scala and Kotlin are SOL. (There’s always the option of approaching my employer to make them make me maintain 11 as well as 8, for a fee, of course. I can barely justify continuing 8 right now. I’d do it but I’m not in a position to be able to do it through Freexian or freelancing.) 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
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
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: Gradle packaging status update
On Sat, 20 Aug 2022, Phil Morrell wrote: > Hi all, documenting my observations as of today because it's not looking > promising for bookworm. > > * kotlin FTBFS because of changes to support openjdk 17 #1012214 If gradle depends on kotlin, it’s not eligible for stable anyway because kotlin currently depends on two unsupported JDKs that are available in unstable for bootstrapping and (old…‑)stable support but nothing else. 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: your mail
On Wed, 18 May 2022, Carlo Stemberger wrote: > I'd like to do it myself, but: > 1) It's a very big project; > 2) I have 0 experience in packaging; > 3) I'm not a Java programmer > > Is there someone interested in helping me? This is then probably quite a bit more than just helping… > First step, I'd start by packaging bitcoinj[1]. I tried to build it[2] (`$ Personally, I’d rather not see more of this environmental pollution in Debian, but not speaking for a team. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Re: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out
On Fri, 29 Apr 2022, Evren Yurtesen wrote: > > What is the problem with logrotate? It happily rotates files owned > > by anyone in Debian. > > Because in Ubuntu rsyslog drops privileges to `syslog` user. > Therefore, the log files generated by rsyslog are owned by the > `syslog` user. But tomcat9 logrotate configuration forces logrotate to > become `tomcat` user, during rotation. Rsyslog fails to truncate the > catalina.out file which has read/write permissions only for `syslog` > user. The logfiles from tomcat aren’t normally generated by rsyslog though, they’re directly written by Java or via shell redirections. Anyway, this is chiefly a *buntu issue and the proposed fix would worsen the situation in Debian, so please try to get this solved on the *buntu side. 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#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)
Re: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out
On Thu, 14 Apr 2022, Utkarsh Gupta wrote: > The submitter has provided a debdiff, too: > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1008668;filename=tomcat9_9.0.58-1ubuntu1.debdiff;msg=5. This will break other syslog implementations, though. What is the problem with logrotate? It happily rotates files owned by anyone in Debian. 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: maven-*-helper JAR placement seems to contradict Java policy
On Wed, 23 Mar 2022, Emmanuel Bourg wrote: > I vaguely remember that replacing a symlink with a file during a package > update was causing some issues (i.e. the target is updated but the symlink Wasn’t that only for directories? 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: Bug#700610: bsh (BeanShell) security vulnerability (CVE-2016-2510)
On Tue, 22 Feb 2022, Thomas Uhle wrote: > What do you think, wouldn't it be time for an update in Debian? The comment > at https://github.com/beanshell/beanshell/issues/603 . reads for me more like a “maybe remove it instead…”. Honestly though, if it’s not available in Central, upstreams will not use it and stick to old beta versions. If Debian has a newer one, which may be incompatible, we’re inviting problems. 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: #975016 - OpenJDK 17 support state for Bullseye
Hi Holger, > and filed against src:debian-security-support, as openjdk-17 seems to be > supported and src:debian-security-support's purpose is to documented what's no, 11 is supported, 17 is just for users to run third-party stuff on (IIUC). 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-17 in Bullseye not up to date
Hi, > However, this version has not been updated since the Bullseye release > (whereas the up to date version is available in testing). right, someone has to do a stable or stable-security upload; probably the latter, from how this has been handed for other JDK versions before. Primary contact for this is Doko (Cc’d, though he probably also reads the list?); I assume from the release note snippet that this has been ok’d by release/security teams beforehand. > There is a bug report [2] for this problem, but it seems to have been > closed without any reason. No, its version tracking merely marks a version that’s not in stable as fixing this bug, but it’s still affecting stable/bullseye. The BTS can be confusing like that ;-) > version. You can find lots of tutorials on the Internet explaining how Yeah, well, those tutorials… *sigh* having taken over openjdk-8 for a while I ran into some counter-productive advice from them as well. But there’s not much one can do about them, except of course provide working things for the good case. > Is an upgrade of openjdk-17 still planned for Bullseye? I’d assume so, though you might have noticed the snippet did say not every update is guaranteed to be made available. 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: Packaging of openjdk-11-jre, ca-certificates-java (and possibly other)
On Mon, 25 Oct 2021, Nils Rennebarth wrote:
> Background is that I install the openjdk-11-jre in a chrooted
> environment where no /proc is available. This only produces the final
> system as a tarball though.
I’d argue that this is likely to be a problem in many more places,
though; making /proc, /sys, /dev{,/shm,/pts} etc. available for such
isn’t that much of a hardship.
This can only be changed in openjdk-17 for the next release anyway,
according to normal stable rules I think, so you might probably wish
to nevertheless invest in mounting procfs.
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: tomcat9 in buster-backports vs. security
On Tue, 10 Aug 2021, Markus Koschany wrote: > Obviously you should wait for Emmanuel's feedback before doing > anything. So… Emmanuel? 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: tomcat9 in buster-backports vs. security
On Tue, 10 Aug 2021, Markus Koschany wrote: > Currently I don't plan to update the bpo version of Tomcat 9 in Buster. If you > prefer the latest updates then I'd suggest to focus on bullseye-backports from I think you misunderstood the intention of this request. Packages in $version-backports have to be up-to-date wrt. their corresponding packages from $(version+1), except small, not very user-visible, etc. changes. In the case of security updates, this is even more important. The person who uploaded the first backport basically agreed to keep the tomcat9 backport up-to-date over the lifetime of buster-backports, that is, to approximately 14/15ᵗʰ August 2022(!). > now on. I am not sure yet if the regression which I have fixed in > 9.0.43-3 requires another security update for bullseye or buster at > the moment, since an easy workaround is available and probably not > many users are affected. I will monitor the situation though. Right. However, if you’re not intending to update the buster backport, please file a removal request and inform the users (via the bpo mailing list) about this and the extant security issues in the version they have installed. Thanks, //mirabilos ObPlug: http://www.mirbsd.org/~tg/Debs/dists/buster/lts/Pkgs/tomcat9/ is what I try to keep reasonably up to date. It also contains the sysvinit fixes. It’s built in a bullseye chroot though, and as such does NOT follow the bpo rules. It’s a works-for-me thing which one MAY use if they want, at their own risk. -- 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 *
tomcat9 in buster-backports vs. security
Hi, the tomcat9 backport is pretty much orphaned: newer tomcat9 versions don’t even build in buster any more¹, and both bullseye² and buster received security fixes recently. ① One built in bullseye works on buster but that is, of course, no option for bpo. (It works for my sysvinit-compatible local builds though.) ② Although waiting for -3 before acting would be best. Markus, Emmanuel, are you going to update the backport to the latest version (9.0.43-3 or 9.0.43-3~deb11u1 once migrated) fixing the compile time problem (some constants for Java™ 15 and newer are not defined yet) because the alternative is to request removal of the backport now and informing the users. 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: Bug#990534: arduino: Arduino-IDE not starting witch Cinnamon Desktop.
On Sat, 10 Jul 2021, Carsten Schoenert wrote: > ensure users have also installed openjdk-11-jre to get Arduino IDE working. Or 17? If you need to ensure a minimum version, do this (/bin/sh-safe): if test "$(java -XshowSettings:properties -version 2>&1 | \ sed -n '/^java.version = \([0-9]*\)\..*$/s//\1/p')" -lt 11; then echo >&2 "E: Either no JRE found or JRE too old (<11):" java -version exit 1 fi The command substitution evaluates to the first number before a period in the version, which is either 1 (from 1.8.x) or 8 for JRE 8, 11 for JRE 11, and obviously larger for later ones. If none, it evaluates to empty, which test … -lt interprets as zero which will also work. Please submit this to the Arduino IDE maintainer. 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: Bug#990534: arduino: Arduino-IDE not starting witch Cinnamon Desktop.
On Mon, 5 Jul 2021, Carsten Schoenert wrote:
> > $ ls -la /usr/bin/java
> > lrwxrwxrwx 1 root root 22 19. Jun 2017 /usr/bin/java ->
> > /etc/alternatives/java
> > $ ls -la /etc/alternatives/java
> > lrwxrwxrwx 1 root root 43 8. Nov 2018 /etc/alternatives/java ->
> > /usr/lib/jvm/java-11-openjdk-amd64/bin/java
You can also use 「readlink -f $(which java)」, which finds
the java binary from $PATH. Do also manually inspect the
output of 「which -a java」 which shows all java binaries
reachable from $PATH, and whether any of the environment
variables, like $JAVA_HOME, are set (they shouldn’t, in a
normal Debian installation with one JRE installed).
> I've recently discovered similar problems elsewhere and I needed to
> reinstall the openjdk packages. So it's possible that some symlinking
> isn't correct.
You should use update-java-alternatives for that.
> It's also possible that something is changing the variable JAVA_OPTIONS
> that is finally used in the wrapper.
>
> You can simply add a line like this right before the last line in the
> wrapper script.
>
> > JAVA_OPTIONS+=("-splash:$APPDIR/lib/splash.png")
> > fi
> >
> > +echo "Using JAVA_OPTIONS: $JAVA_OPTIONS"
This will show only the first array element. You’ll need:
echo "Using JAVA_OPTIONS: ${JAVA_OPTIONS[*]}"
> > "$JAVA" "${JAVA_OPTIONS[@]}" processing.app.Base "$@"
>
> Then please call arduino again from CLI.
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_8u292-b10-3_source.changes ACCEPTED into unstable
On Wed, 23 Jun 2021, Debian FTP Masters wrote: > openjdk-8 (8u292-b10-3) unstable; urgency=medium > . >* Re-upload with actually regenerated debian/control, oops Meh. This SHOULD have failed when building the source package. I fully blame git, unlike proper version control software (that is, CVS), failing to get mtimes right. (I know it is so for a fact, I blame -2 having the wrong debian/control on it.) bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Re: [feature request] provide a virtual package for jdk/jre
Hi Samuel, > I'd like to request this same feature for the java ecosystem on Debian. this thing exists: Package: openjdk-8-jre-headless Provides: java2-runtime-headless, java5-runtime-headless, java6-runtime-headless, java7-runtime-headless, java8-runtime-headless # and java-runtime-headless except I oops’d, will fix this RSN Package: openjdk-11-jre-headless Provides: java-runtime-headless, java10-runtime-headless, java11-runtime-headless, java2-runtime-headless, java5-runtime-headless, java6-runtime-headless, java7-runtime-headless, java8-runtime-headless, java9-runtime-headless Package: openjdk-17-jre-headless Provides: java-runtime-headless, java10-runtime-headless, java11-runtime-headless, java12-runtime-headless, java13-runtime-headless, java14-runtime-headless, java15-runtime-headless, java16-runtime-headless, java17-runtime-headless, java2-runtime-headless, java5-runtime-headless, java6-runtime-headless, java7-runtime-headless, java8-runtime-headless, java9-runtime-headless Package: openjdk-8-jre Provides: java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime # and java-runtime except I oops’d, will fix this RSN Package: openjdk-11-jre Provides: java-runtime, java10-runtime, java11-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime, java9-runtime Package: openjdk-17-jre Provides: java-runtime, java10-runtime, java11-runtime, java12-runtime, java13-runtime, java14-runtime, java15-runtime, java16-runtime, java17-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime, java9-runtime Package: openjdk-8-jdk Provides: java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk, java7-sdk, java8-sdk Package: openjdk-11-jdk Provides: java-compiler, java-sdk, java10-sdk, java11-sdk, java2-sdk, java5-sdk, java6-sdk, java7-sdk, java8-sdk, java9-sdk Package: openjdk-17-jdk Provides: java-compiler, java-sdk, java10-sdk, java11-sdk, java12-sdk, java13-sdk, java14-sdk, java15-sdk, java16-sdk, java17-sdk, java2-sdk, java5-sdk, java6-sdk, java7-sdk, java8-sdk, java9-sdk 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#920562: ca-certificates-java: postinst fails under qemu-aarch64-static ⇒ is a qemu issue
reassign 920562 qemu-user-static forcemerge 986022 920562 thanks This is pretty much the same issue, just for arm64 emulation. 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#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
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"
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
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!
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: May be its rather a "java.io.IOException: No such file or directory" issue (Was: Calling sbt inside d/rules)
On Thu, 27 May 2021, Andreas Tille wrote:
> > Shoot into the blue: $HOME?
>
> I had the same idea and tried this
>
>
> https://salsa.debian.org/r-pkg-team/r-cran-epitweetr/-/blob/master/debian/rules#L9
>
> but it does not help. :-(
I see…
> PS: In case someone might like to try pbuilder to reproduce the issue:
> all r-cran-* Build-Depends where several are in new are not needed
> until the error occures.
Good to know. I’ve got…
[pid 30364] stat("/.sbt/repositories", 0x7faae8e31bb0) = -1 ENOENT (No such
file or directory)
[pid 30364] stat("/.sbt/boot", 0x7faae8e32370) = -1 ENOENT (No such file or
directory)
[pid 30364] mkdir("/.sbt/boot", 0777) = -1 ENOENT (No such file or directory)
[…]
[pid 30364] openat(AT_FDCWD, "/.sbt/boot/sbt.boot.lock", O_RDWR|O_CREAT|O_EXCL,
0666) = -1 ENOENT (No such file or directory)
java.io.IOException: No such file or directory
… so there’s definitely something wrong with directories.
Looking at the /usr/bin/sbt script, I see there’s some /.sbt/ in
there but unused. Looking at the manpage shows…
pbuilder@tglase:~/b/r-cran-epitweetr/java$ sbt -no-share package
… is the key to success, at least until…
Getting org.scala-sbt sbt 0.13.13 ...
downloading
file:/usr/share/maven-repo/org/scala-sbt/sbt/0.13.13/sbt-0.13.13.jar ...
[SUCCESSFUL ] org.scala-sbt#sbt;0.13.13!sbt.jar (3ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/main/debian/main-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#main;debian!main.jar (8ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/actions/debian/actions-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#actions;debian!actions.jar (3ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/main-settings/debian/main-settings-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#main-settings;debian!main-settings.jar (3ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/interface/debian/interface-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#interface;debian!interface.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/io_2.11/debian/io_2.11-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#io_2.11;debian!io_2.11.jar (3ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/scala-sbt-ivy/debian/scala-sbt-ivy-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#scala-sbt-ivy;debian!scala-sbt-ivy.jar (7ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/logging/debian/logging-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#logging;debian!logging.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/logic/debian/logic-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#logic;debian!logic.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/process/debian/process-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#process;debian!process.jar (2ms)
downloading file:/usr/share/maven-repo/org/scala-sbt/run/debian/run-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#run;debian!run.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/command/debian/command-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#command;debian!command.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-lang/modules/scala-xml_2.11/debian/scala-xml_2.11-debian.jar
...
[SUCCESSFUL ]
org.scala-lang.modules#scala-xml_2.11;debian!scala-xml_2.11.jar(bundle) (4ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/launcher-interface/debian/launcher-interface-debian.jar
...
[SUCCESSFUL ]
org.scala-sbt#launcher-interface;debian!launcher-interface.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/classpath/debian/classpath-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#classpath;debian!classpath.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/completion_2.11/debian/completion_2.11-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#completion_2.11;debian!completion_2.11.jar
(2ms)
downloading file:/usr/share/maven-repo/org/scala-sbt/api/debian/api-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#api;debian!api.jar (3ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/compiler-integration/debian/compiler-integration-debian.jar
...
[SUCCESSFUL ]
org.scala-sbt#compiler-integration;debian!compiler-integration.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/compiler-ivy-integration/debian/compiler-ivy-integration-debian.jar
...
[SUCCESSFUL ]
org.scala-sbt#compiler-ivy-integration;debian!compiler-ivy-integration.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/relation/debian/relation-debian.jar ...
[SUCCESSFUL ] org.scala-sbt#relation;debian!relation.jar (1ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/task-system/debian/task-system-debian.jar
...
[SUCCESSFUL ] org.scala-sbt#task-system;debian!task-system.jar (2ms)
downloading
file:/usr/share/maven-repo/org/scala-sbt/tasks/debian/tasks-debian.jar ...
[SUCCESSFUL ]
Re: May be its rather a "java.io.IOException: No such file or directory" issue (Was: Calling sbt inside d/rules)
On Thu, 27 May 2021, Andreas Tille wrote: > I tried again without any clue - may be it is simply some missing > directory inside pbuilder - but I have no idea which one. :-( Shoot into the blue: $HOME? 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: Kotlin: looking for a DD to review/upload
On Fri, 7 May 2021, Phil Morrell wrote: > Are you planning to upload to stretch stretch is closed; backports only follow normal release cycles and desupport LTS. (This is a thing I’m hoping to change when I might be able to at some point in the future, but nothing’s decided yet.) bye, //mirabilos PS: You can build a .orig.tar.?z for bootstrapping without needing to go through uscan, if *that* is what keeps us from having a sane version number… -- 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 *
debhelper 13 (was Re: Kotlin: looking for a DD to review/upload)
On Fri, 7 May 2021, Matthias Klose wrote: > Is there any reason to use debhelper 13? Does it have anything that > is relevant for java packages? Just asking because that's usually > something which needs to be downgraded for backports. But I assume > there are enough dependency requiring debhelper v13 as well ... That’s Ubuntu you’re talking about. I’m still totally annoyed for my PPA builds that bionic and focal don’t have debhelper 13 available. Debian backports, at least for the last 3+ years, have had reasonably up-to-date debhelper, as downgrading the version just for backporting is really undesired as backports change and hindering things in sid. 13~bpo10+1 has a changelog date of 27 Apr 2020… 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: Kotlin: looking for a DD to review/upload
On Sat, 1 May 2021, Olek Wojnar wrote: > FWIW, help2man is often a really good starting point. REALLY not; that produces really bad-quality man(7)-format manpages. These days you want semantical markup via mdoc(7) instead (see, for example, the manpage I wrote for jamulus or others). 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: Kotlin: looking for a DD to review/upload
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 have NOT yet uploaded because ftpmasters must first ACCEPT 8u282-b08-2 (which is a rather hackish upload containing self-built binaries) so the B-D for future uploads will be available again. 8u292-b10-1 will be the first upload that’ll be built on the buildds again then. > However, the wait time can be used to do any final reviews. Yes, definitely. (Not something I see me helping with, though.) > - There are no lintian errors/warnings except for need of manpages. $ lintian -vIiE --pedantic --color=auto *.changes This often finds many more than one’s standard invocations do. Manpages are important (now’s the time to write some ☺) but not a conditio-sine-qua-nōn. I delivered the one for Jamulus later, too (lack of time to write one for the hurried upload to NEW). 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
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 *
