Bug#1036884: transition: time64_t

[Simon McVittie]

Control: block -1 by 1065787 1066049

One dependency chain that is blocking a lot of rebuilds right now is
this one:

... => curl -> stunnel4 -> python-cryptography => cargo => ...

key: => mandatory dependency
-> nocheck dependency

In the medium term, cargo needs re-bootstrapping on the affected
architectures (armel and armhf, plus a bunch of -ports architectures
where as far as I can see cargo was never available in the past) -
that's #1065787, and Steve already replied to that bug describing how
Ubuntu did this. Is there a porter who can take responsibility for that?

In the shorter term, I think it might be pragmatic to build either curl
or stunnel4 with tests disabled on the affected architectures, breaking
that dependency chain and allowing most C/C++ packages that are being held
up by curl to be rebuilt in parallel.

I think disabling tests in stunnel4 would have less impact on the rest
of Debian than disabling tests in curl if it results in an undetected
regression, so I'd suggest stunnel4 as the place to break that chain. I've
sent a proposed patch to #1066049.

On IRC, Michael Biebl suggested an alternative plan of configuring the
armel|armhf buildds to always build with the nocheck profile for the
duration of the transition (and presumably keep track of the affected
packages to be rebuilt with build-time tests afterwards), but as far as
I know that's not possible in our infrastructure?

Thanks,
smcv

[Emanuele Rocca]

[ debian-rust added to CC ]

Hi,

Post by Simon McVittie
In the medium term, cargo needs re-bootstrapping on the affected
architectures (armel and armhf, plus a bunch of -ports architectures
where as far as I can see cargo was never available in the past) -
that's #1065787, and Steve already replied to that bug describing how
Ubuntu did this.

I don't think Ubuntu actually fixed cargo yet, at least if the data in
UDD is reliable -- and if I'm looking in the right place. :-)

udd=> select source,version,date from ubuntu_upload_history where source='cargo' order by date desc limit 2;
source | version | date
--------+--------------------------------------------+------------------------
cargo | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
cargo | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
(2 rows)

Maybe when Steve mentioned the work done in Ubuntu on
https://bugs.debian.org/1065787#22 he meant other packages?

Post by Simon McVittie
Is there a porter who can take responsibility for that?

I did manage to get cargo to build in a armhf chroot by manually
installing the various deps, see the build artifacts at
https://people.debian.org/~ema/cargo/. I can work on armel next. The
tests are green but maybe there's some more meaningful validation we can
do before uploading? Anyone from debian-rust has ideas or comments?

[Steve Langasek]

Post by Emanuele Rocca

Post by Simon McVittie
In the medium term, cargo needs re-bootstrapping on the affected
architectures (armel and armhf, plus a bunch of -ports architectures
where as far as I can see cargo was never available in the past) -
that's #1065787, and Steve already replied to that bug describing how
Ubuntu did this.

I don't think Ubuntu actually fixed cargo yet, at least if the data in
UDD is reliable -- and if I'm looking in the right place. :-)
udd=> select source,version,date from ubuntu_upload_history where source='cargo' order by date desc limit 2;
source | version | date
--------+--------------------------------------------+------------------------
cargo | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
cargo | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
(2 rows)

cargo in Ubuntu is built from the rustc source package.

Post by Emanuele Rocca
Maybe when Steve mentioned the work done in Ubuntu on
https://bugs.debian.org/1065787#22 he meant other packages?

Post by Simon McVittie
Is there a porter who can take responsibility for that?

I did manage to get cargo to build in a armhf chroot by manually
installing the various deps, see the build artifacts at
https://people.debian.org/~ema/cargo/. I can work on armel next. The
tests are green but maybe there's some more meaningful validation we can
do before uploading? Anyone from debian-rust has ideas or comments?

[Emanuele Rocca]

Hi,

Post by Emanuele Rocca
I did manage to get cargo to build in a armhf chroot by manually
installing the various deps

When it comes to actually satisfying build-depends properly it seems
that as of right now the missing ones are libcurl4-gnutls-dev and
libgit2-dev. curl cannot be built on armhf due to stunnel4, and Simon
suggested a workaround for that in https://bugs.debian.org/1066049.

The problem with libgit2 seems to be cmake, which can be built on armhf
with DEB_BUILD_PROFILES=pkg.cmake.bootstrap. Do we plan on performing
binary uploads of packages built with bootstrap profiles, or what is the
general idea forward?

[Emanuele Rocca]

Post by Emanuele Rocca
When it comes to actually satisfying build-depends properly it seems
that as of right now the missing ones are libcurl4-gnutls-dev and
libgit2-dev.

Cargo is now done. With libcurl4-gnutls-dev and libgit2-dev available I
could bootstrap it on armhf/armel, and Fabian later took care of a
source-only upload. We had to drop git from build-depends, not yet
installable on 32bit arm. Without git a (small) minority of tests are
not being run, but that seemed acceptable.

Next up for the rust world is rustc, which is currently blocked on
llvm-16-dev, itself stuck on a cycle between php and postgres.

[Simon McVittie]

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?

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?

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.

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.

smcv

[Thorsten Glaser]

Hi,

Post by Simon McVittie
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
=2Edeb 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=E2=80=99t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I=E2=80=99m not in the situation of throwing the
=2Edebs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we=E2=80=99re using #debian-ports on OFTC for the
d-ports architectures and I couldn=E2=80=99t 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
=2Edebs 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=E2=80=932015) into the chroot then rebuild there.

I will gladly help if it=E2=80=99s made possible for me to help. This
cannot be done on a porterbox because it=E2=80=99s 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=E2=80=99t mind temporarily giving
me root on, I=E2=80=99m in, otherwise I=E2=80=99ll answer questions from th=
ese
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
- --=20
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

[Jeffrey Walton]

Post by Thorsten Glaser
[...]
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 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.

Provide your postal mailing address, if you want them.

Jeff

[Thorsten Glaser]

Hi Jeffrey,

I=E2=80=99m answering back from the $dayjob address because Googlemail
cannot communicate with normal mailservers.

Post by Jeffrey Walton
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=E2=80=99t want them any more and wa=
nt
to ship them to .de, although it=E2=80=99ll likely take longer than just ge=
tting
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
--=20
15:41=E2=8E=9C<Lo-lan-do:#fusionforge> Somebody write a testsuite for hello=
world :-)

[Thorsten Glaser]

Nothing beats a native compile in your basement.

Yes, definitely.

Post by Thorsten Glaser
Do they run stock Debian armhf?

Oofff=E2=80=A6
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=E2=80=99s see if I can get an account on a project box first, or
work with someone who has. (I=E2=80=99m not intending to add going into
ARM development on top of what I already try to balance=E2=80=A6 right
now, I=E2=80=99m mostly helping m68k through t64, so Adrian does not
burn out, he=E2=80=99s 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
--=20
15:41=E2=8E=9C<Lo-lan-do:#fusionforge> Somebody write a testsuite for hello=
world :-)

[Jeffrey Walton]

On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser

I’m answering back from the $dayjob address because Googlemail
cannot communicate with normal mailservers.

Post by Jeffrey Walton
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.

Nothing beats a native compile in your basement. It sure beats the
snot out of a cross-compile, or an emulator like a Debian QEMU/Chroot.
I switched to the dev boards after getting frustrated with
cross-compiles. (So many makefiles are poorly written, and can't
handle a simple cross-compile).

And I run a first class swap file on all of my dev boards. SDcards are
easy to replace. A SDcard lasts 6 to 9 months before you start seeing
unexplained file system errors. That's around the time you know it's
time to replace the SDcard.

Do they run stock Debian armhf?

So the CubieTruck is embarrassingly down level:

cubietruck:~$ lsb_release -a
Distributor ID: Linaro
Description: Linaro 14.04
Release: 14.04
Codename: trusty

The Wandboard is doing better:

wandboard:~$ lsb_release -a
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

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.

Jeff

[Wookey]

Post by Thorsten Glaser
I hacked that, and I tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.

What was the actual problem with uploading the images you built? Just
not having any corresponding source? Or something more complicated?

It seems to me you've done all the hard work - we just need to work
out how to get those packages into the archive. Maybe that needs a
rebuild with corresponding source? Although if we already have the
source just making a new changes file with all the right piece in
should be enough, should it not?

or am I missing something?

Wookey

[Wookey]

Post by Wookey

Post by Thorsten Glaser
I hacked that, and I tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.

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.

But it does a great job of filling the self-dependency so I can build the current version.
So I now have all the pieces (on armhf, not checked armel yet but hopefully it matches)

Building now...


Wookey

[Thorsten Glaser]

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=E2=80=99m no expert either, though :/

Post by Wookey
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 ;-)

An exception has occurred in the compiler (17.0.10). Please file a bug aga=

inst the Java compiler via the Java bug reporting page (https://bugreport.j=
ava.com) after checking the Bug Database (https://bugs.java.com) for duplic=
ates. Include your program, the following diagnostic, and the parameters pa=
ssed 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=E2=80=99s that known combined qemu/kernel/libc issue which cbmuser
is also constantly running into. I think switching to=E2=80=A6 sgixfs I
think? also makes it work, but I=E2=80=99m not sure.

https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960#c73
sgixfs and btrfs, yeah, ext4 is problematic. But apparently,
LFS should fix this but Java is again special in that it=E2=80=99s
still problematic there.

Were you using qemu-user? qemu-system has its own kernel and
=E2=80=9Cshould=E2=80=9D be fine, modulo the usual qemu issues. Real hardwa=
re
is better (for many architectures even necessary).

Good luck,
//mirabilos
--=20
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too=E2=80=A6 may I quote yo=
u on that?
<igli> sure, tho i doubt anyone will listen ;)

[Wookey]

Post by Thorsten Glaser

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.

OK. I get it now.

Post by Thorsten Glaser

but actually having an openjdk binaries is very useful
too to satisfy the self-dependency without more faff.

Yes, that was their purpose.

And it worked beatifully. Thanks.

armhf and armel uploaded and accepted half an hour ago (armel built by Andrey Rakhmatullin)

I'll try doing openjdk-20 next.


Wookey

[Thorsten Glaser]

Post by Wookey
And it worked beatifully. Thanks.

Nice!

Post by Wookey
I'll try doing openjdk-20 next.

You=E2=80=99ll want 21 as 20 has not got the t64 treatment.

gl hf,
//mirabilos
--=20
15:41=E2=8E=9C<Lo-lan-do:#fusionforge> Somebody write a testsuite for hello=
world :-)

[Wookey]

Post by Simon McVittie
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.

Post by Simon McVittie
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.

Post by Simon McVittie
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

[Thorsten Glaser]

Post by Wookey
I looked at this last week, but got stuck because openjdk-17's
build-deps included graphviz

Build-Depends-Indep: graphviz, pandoc

You don=E2=80=99t 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).

Post by Wookey
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).

Post by Wookey
apt : Depends: libgnutls30 (>=3D 3.8.1) but it is not going to be install=

ed

You should get that rebuilt, yes.
On the other hand, if everything else is falling into place, it=E2=80=99s
not a problem for apt to uninstall itself just in that one build
chroot =E2=98=BB

Post by Wookey
libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be ins=

talled

Post by Wookey
libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be inst=

alled

Post by Wookey
libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be ins=

talled

These are fine.

Post by Wookey
libcups2 : Depends: libgnutls30 (>=3D 3.8.1) but it is not going to be in=

stalled

Force that away; nothing from this is actually used during the
openjdk build in a way sufficient to impact the build.

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

Oh, dose=E2=80=A6 right=E2=80=A6 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).

Post by Wookey

Post by Simon McVittie
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=E2=80=99s always just one version; I know it was so until 17,
but I don=E2=80=99t think this has loosened (I asked in IRC, but got
no answer until I went to sleep).

Post by Wookey

Post by Simon McVittie
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=E2=80=99d have to patch them to both address the t64 issues and
make it imply nocheck (or quinn-diff doesn=E2=80=99t pick it up as
installable).

It=E2=80=99s best to get at least 17 and 21 (which AIUI is the one
we=E2=80=99ll want for trixie?) built this way. I think, unless
users complain, we can these days go without 8 and probably
even without 11.

(You=E2=80=99d 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=E2=80=90
bootstrapping to be done.)