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.

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,
<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 ;)

Reply via email to