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.)
Reply to: