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.)