Re: 64-bit time_t transition: cargo needs manual intervention
On 2024-03-16 04:21, Emanuele Rocca wrote: > With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf And on armel too. Fixed armhf/armel packages uploaded. > Fabian: it seems that cargo's build-depend on git can be dropped? The > package builds fine without, tests included. I haven't touched build-depends and git is still currently uninstallable. For this reason cargo would not cleanly build from source on armhf/armel in case of sourceful upload, but as I said without git it does build fine. Leaving this one up to Fabian!
Re: 64-bit time_t transition: cargo needs manual intervention
On Sat, 16 Mar 2024 at 14:29, Simon McVittie wrote: > On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > > For example curl isn't building on armel/armhf now and numerous packages > > that > > depend of curl are not building on armel/armhf. > > I believe a maintainer upload or NMU of #1066981 and #1066982 would > now be enough to unblock curl, which would hopefully unblock a lot of > the C/C++ ecosystem (in particular fixing the unsatisfiable dependency > libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow > gdb to be installed), while also making life easier for the people trying > to re-bootstrap cargo. I've uploaded curl 8.6.0-4 with the patches from #1066981 and #1066982, thank you for those, Simon! Cheers, -- Samuel Henrique
Re: 64-bit time_t transition: cargo needs manual intervention
On Sat, 16 Mar 2024 at 15:37:20 +0100, Matthias Klose wrote: > build gdb without libdebuginfo on the bootstrap archs for a while. That's likely also good advice, but the cycle involving gdb isn't the only one involving curl. smcv
Re: 64-bit time_t transition: cargo needs manual intervention
Hi! On 2024-03-16 02:29, Simon McVittie wrote: > On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > > For example curl isn't building on armel/armhf now and numerous packages > > that > > depend of curl are not building on armel/armhf. > > I believe a maintainer upload or NMU of #1066981 and #1066982 would > now be enough to unblock curl, which would hopefully unblock a lot of > the C/C++ ecosystem (in particular fixing the unsatisfiable dependency > libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow > gdb to be installed), while also making life easier for the people trying > to re-bootstrap cargo. Thanks Simon. I can confirm that curl does indeed build properly on armhf with DEB_BUILD_PROFILES='pkg.curl.noldap nocheck'. With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf (haven't tried armel yet). See https://people.debian.org/~ema/cargo/ for the debs. I've included installable curl packages there too in case someone else wants to give it a go. Fabian: it seems that cargo's build-depend on git can be dropped? The package builds fine without, tests included.
Re: 64-bit time_t transition: cargo needs manual intervention
On 16.03.24 15:29, Simon McVittie wrote: On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: For example curl isn't building on armel/armhf now and numerous packages that depend of curl are not building on armel/armhf. I believe a maintainer upload or NMU of #1066981 and #1066982 would now be enough to unblock curl, which would hopefully unblock a lot of the C/C++ ecosystem (in particular fixing the unsatisfiable dependency libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow gdb to be installed), while also making life easier for the people trying to re-bootstrap cargo. build gdb without libdebuginfo on the bootstrap archs for a while.
Re: 64-bit time_t transition: cargo needs manual intervention
On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > For example curl isn't building on armel/armhf now and numerous packages that > depend of curl are not building on armel/armhf. I believe a maintainer upload or NMU of #1066981 and #1066982 would now be enough to unblock curl, which would hopefully unblock a lot of the C/C++ ecosystem (in particular fixing the unsatisfiable dependency libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow gdb to be installed), while also making life easier for the people trying to re-bootstrap cargo. As a non-user of the affected architectures, I'm not comfortable with being responsible for NMU'ing those changes (certainly not without giving the curl maintainers a chance to comment!), but I've provided patches so that either a curl maintainer or a porter could do so. Thanks, smcv
Re: 64-bit time_t transition: cargo needs manual intervention
On Fri, Mar 15, 2024 at 08:16:40AM -0700, Otto Kekäläinen wrote: > Hi! > > pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler > kirjoitti: > > > On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote: > > > Hi! > > > > > > Is anyone perhaps planning to fix cargo? > > > > > > For example curl isn't building on armel/armhf now and numerous packages > > > that depend of curl are not building on armel/armhf. > > > > > > Thanks in advance to the person who steps up. > > > > see the (linked) t64 transition bug: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197 > > > That link doesn't answer my question. The link is to bug report summarizing > that cargo is broken and suggesting it needs to be re-bootstrapped. > > Currently we haven't seen anybody step up to do it. I would be very > grateful if somebody with enough expertise would be available to do it and > thus help resolve the whole chain of broken builds. it does (the replies afterwards are about people stepping up, the coordination then shifted to IRC where it is still ongoing..). it will take a bit though, there are very large and intertwined dep chains to analyze and unwind (and/or temporarily break), as well as lots of manual rebootstrapping along the way..
Re: 64-bit time_t transition: cargo needs manual intervention
On 2024-03-14 22:03 -0700, Otto Kekäläinen wrote: > Hi! > > Is anyone perhaps planning to fix cargo? Yes. We have been working on it this week (e.g. ema built cargo for armhf), but that is not sufficient to unbung the curl->stunnel4->python->crypography->cargo loop. I tried building the patched stunnel4 last night but got stuck on other missing dependencies, and just about everything being uninstallable (and then my wife made me do something else for the rest of the evening). > For example curl isn't building on armel/armhf now and numerous packages > that depend of curl are not building on armel/armhf. We are well aware that this is broken and blocking lots of things. Co-ordinate efforts on the #debian-arm channel. There are plenty of other loops to unbung too. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: 64-bit time_t transition: cargo needs manual intervention
Hi! pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler kirjoitti: > On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote: > > Hi! > > > > Is anyone perhaps planning to fix cargo? > > > > For example curl isn't building on armel/armhf now and numerous packages > > that depend of curl are not building on armel/armhf. > > > > Thanks in advance to the person who steps up. > > see the (linked) t64 transition bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197 That link doesn't answer my question. The link is to bug report summarizing that cargo is broken and suggesting it needs to be re-bootstrapped. Currently we haven't seen anybody step up to do it. I would be very grateful if somebody with enough expertise would be available to do it and thus help resolve the whole chain of broken builds. > >
Re: 64-bit time_t transition: cargo needs manual intervention
On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote: > Hi! > > Is anyone perhaps planning to fix cargo? > > For example curl isn't building on armel/armhf now and numerous packages > that depend of curl are not building on armel/armhf. > > Thanks in advance to the person who steps up. see the (linked) t64 transition bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197
Re: 64-bit time_t transition: cargo needs manual intervention
Hi! Is anyone perhaps planning to fix cargo? For example curl isn't building on armel/armhf now and numerous packages that depend of curl are not building on armel/armhf. Thanks in advance to the person who steps up.
Re: 64-bit time_t transition: cargo needs manual intervention
Andrea Bolognani, le mer. 13 mars 2024 18:03:40 +0100, a ecrit: > On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote: > > Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit: > > > 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition > > >because its major purpose this decade is running legacy 32-bit > > > binaries, > > >a purpose that would no longer be possible if it broke ABI > > >- non-release architectures in the same category: hurd-i386 (I think) > > > > We asked hurd-i386 to be there indeed, because we plan to have > > hurd-amd64 replace hurd-i386 way before 2038 :) > > Wouldn't it make sense to migrate hurd-i386 to 64-bit time_t > regardless of the plans for hurd-amd64? When seeing the pain that arm* suffer, I believe we made the right choice. > Contrary to linux-i386, it's not like there is a wealth of (possibly > proprietary/binary-only) hurd-i386 software out there that we would > benefit from remaining compatible with. Sure, but the migration itself takes manpower, for no real benefit. Samuel
Re: 64-bit time_t transition: cargo needs manual intervention
On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote: > Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit: > > 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition > >because its major purpose this decade is running legacy 32-bit binaries, > >a purpose that would no longer be possible if it broke ABI > >- non-release architectures in the same category: hurd-i386 (I think) > > We asked hurd-i386 to be there indeed, because we plan to have > hurd-amd64 replace hurd-i386 way before 2038 :) Wouldn't it make sense to migrate hurd-i386 to 64-bit time_t regardless of the plans for hurd-amd64? Contrary to linux-i386, it's not like there is a wealth of (possibly proprietary/binary-only) hurd-i386 software out there that we would benefit from remaining compatible with. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: 64-bit time_t transition: cargo needs manual intervention
Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit: > 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition >because its major purpose this decade is running legacy 32-bit binaries, >a purpose that would no longer be possible if it broke ABI >- non-release architectures in the same category: hurd-i386 (I think) We asked hurd-i386 to be there indeed, because we plan to have hurd-amd64 replace hurd-i386 way before 2038 :) Samuel
Re: 64-bit time_t transition: cargo needs manual intervention
On Tue, 12 Mar 2024 at 23:13:30 -0500, Steven Robbins wrote: > I checked the build logs for cargo and noticed that most architectures have > been built on the buildds. All release arches except armel & armhf. How is > it that these two have build dep installability problems but others do not? Those two are the only release architectures where the 64-bit time_t transition has caused an ABI break: 1. amd64, arm64, mips64el, ppc64el, riscv64, s390x are all 64-bit, so they already had 64-bit time_t - non-release architectures in the same category: alpha hurd-amd64 ia64 loong64 ppc64 sparc64 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition because its major purpose this decade is running legacy 32-bit binaries, a purpose that would no longer be possible if it broke ABI - non-release architectures in the same category: hurd-i386 (I think) 3. There is currently no release architecture that is 32-bit but already had a 64-bit time_t prior to 2024 - non-release architectures in this category: x32 4. armel, armhf are the two remaining 32-bit release architectures after excluding all of the above - non-release architectures in the same category: hppa m68k powerpc sh4 I hope that helps to categorise the architectures that do/don't have a problem here. For architectures in categories 1, 2 and 3 above, libfoo0 is still renamed to libfoo0t64, but libfoo0t64 Provides: libfoo0, making it significantly easier to satisfy build-dependencies. The last category is the only one where there has genuinely been a compatibility break and therefore this Provides would be wrong, so it is also the category where some packages need re-bootstrapping. smcv
Re: 64-bit time_t transition: cargo needs manual intervention
On Tuesday, March 12, 2024 1:24:25 A.M. CDT Steve Langasek wrote: > The quickest fix for this based on what we've done in Ubuntu is: > > - unpack cargo and libstd-rust debs to the root via dpkg-deb -x > - use equivs to mock up packages by these names with no dependencies and > install those > - bootstrap > - enjoy Thanks! I checked the build logs for cargo and noticed that most architectures have been built on the buildds. All release arches except armel & armhf. How is it that these two have build dep installability problems but others do not? -Steve signature.asc Description: This is a digitally signed message part.
Re: 64-bit time_t transition: cargo needs manual intervention
On Mon, Mar 11, 2024 at 09:07:17PM -0500, Steven Robbins wrote: > Peter convincingly argues (details in bug) that manual intervention is needed > for package "cargo": > On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green > wrote: > > This will require manual intervention to resolve, either through > > cross-building or through building manually in a hacked-up build > > environment. > > I've certainly seen mention of rustc on #debian-devel recently, > > so I think the people handling the time_t transition are already > > aware of this. > I'm wondering if the time_t people or the rust people could comment on this? > This build failure has a surprisingly (to me) long chain of casualties. Is > this an easy thing to fix or is going to take weeks? The quickest fix for this based on what we've done in Ubuntu is: - unpack cargo and libstd-rust debs to the root via dpkg-deb -x - use equivs to mock up packages by these names with no dependencies and install those - bootstrap - enjoy -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
