Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Thorsten Glaser Newsgroups: linux.debian.bugs.dist,linux.debian.ports.arm,linux.debian.maint.java,linux.debian.devel.release Subject: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Date: Wed, 27 Mar 2024 23:50:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Wed Mar 27 22:45:10 2024 Old-Return-Path: X-Spam-Flag: NO Reply-To: Thorsten Glaser , 1036884@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Debian Release Team X-Debian-Pr-Message: followup 1036884 X-Debian-Pr-Package: release.debian.org X-X-Sender: tg@herc.mirbsd.org Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Debian-Message: from BTS X-Mailing-List: archive/latest/1830307 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 74 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Simon McVittie , 1036884@bugs.debian.org, debian-arm@lists.debian.org, debian-java@lists.debian.org X-Original-Date: Wed, 27 Mar 2024 22:30:04 +0000 (UTC) X-Original-Message-ID: X-Original-References: <20240327152702.GQ4300@mail.wookware.org> <20240327162149.GR4300@mail.wookware.org> <20240327215510.GE7545@mail.wookware.org> <20240327215510.GE7545@mail.wookware.org> Xref: csiph.com linux.debian.bugs.dist:1192075 linux.debian.ports.arm:13930 linux.debian.maint.java:12742 linux.debian.devel.release:123457 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 :/ >> 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 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 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=E2=80=A6 may I quote yo= u on that? sure, tho i doubt anyone will listen ;)