Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

Wookey <[email protected]> Wed, 27 Mar 2024 03:18:03 +0000

Newsgroups	gmane.linux.debian.ports.arm,gmane.linux.debian.devel.java
Organization	Wookware
Message-ID	<[email protected]>

On 2024-03-26 10:35 +0000, Simon McVittie wrote:
> It seems that some of the dependency chains for packages that are still
> waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
> default Java version for most architectures and Build-Depends on itself
> (with an alternative dependency on openjdk-16, but that no longer exists).
> evolution-data-server -> libphonenumber-dev is an example.
> 
> Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow?

I looked at this last week, but got stuck because openjdk-17's
build-deps included graphviz which was also uninstallable and led to
another blocked chain with ghostscript,cups and libgtk2 conflicting about their t64 status.

Checking again now, apt still complains:
The following packages have unmet dependencies:
 apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed
 libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be installed
 libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going 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

But dose now says there is a solution, unlike last week.

So it should be possible to get the dependencies in place (without
unreasonable jiggery-pokery) and bootstrap it. I'll have another go tomorrow.

> Or do maintainers of packages that build both a C/C++ library and Java
> bindings from a single source package need to disable its Java bindings
> on the affected architectures, either temporarily or permanently?

Some of that might still be expedient, but hopefully we can get a t64
java soon and it won't be necessary. We have to do that sooner or later anyway.

> openjdk-21 is in a similar situation, build-depending on itself, while
> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively.
> 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.

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?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

signature.asc (application/pgp-signature, 833 B)