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 :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-27 22:30 +, Thorsten Glaser wrote: > >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. > > 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 -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
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 ;)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-27 15:27 +, Wookey wrote: > On 2024-03-26 22:28 +, Thorsten Glaser wrote: > > > 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 -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 22:28 +, Thorsten Glaser wrote: > 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 -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
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.)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 10:35 +, 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 Description: PGP signature
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 :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser wrote: > > 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. 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
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 :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser wrote: > > [...] > > 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
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-
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
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
