Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.java > #12739
| From | Thorsten Glaser <t.glaser@qvest-digital.com> |
|---|---|
| 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 | 2024-03-27 05:50 +0100 |
| Message-ID | <ImtoB-1Xrm-3@gated-at.bofh.it> (permalink) |
| References | <GArKF-c2RS-3@gated-at.bofh.it> <ImcnM-1N2D-1@gated-at.bofh.it> <ImrZv-1WJn-1@gated-at.bofh.it> <GArKF-c2RS-3@gated-at.bofh.it> <ImrZv-1WJn-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 4 groups.
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.)
Back to linux.debian.maint.java | Previous | Next — Previous in thread | Find similar
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Simon McVittie <smcv@debian.org> - 2024-03-26 11:40 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Thorsten Glaser <tg@debian.org> - 2024-03-26 23:40 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Jeffrey Walton <noloader@gmail.com> - 2024-03-26 23:50 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-03-27 00:50 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-03-27 03:30 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Jeffrey Walton <noloader@gmail.com> - 2024-03-27 03:30 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Wookey <wookey@wookware.org> - 2024-03-27 16:40 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Wookey <wookey@wookware.org> - 2024-03-27 17:30 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Thorsten Glaser <tg@debian.org> - 2024-03-27 23:50 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Wookey <wookey@wookware.org> - 2024-03-28 15:00 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Thorsten Glaser <tg@debian.org> - 2024-03-28 22:30 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Wookey <wookey@wookware.org> - 2024-03-27 04:30 +0100
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-03-27 05:50 +0100
csiph-web