Re: 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
-- 
<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… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)