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