Control: tags -1 + moreinfo On Thu, 21 Mar 2024 at 15:00:52 +0100, Christian Marillat wrote: > I noticed this bug with the libopenshot-audio source and with > armel, armh and powerpc architectures from buildd logs and my rebuild. > > I didn't pay attention for others sources, but I noticed that only > after a second rebuild... > > ,---- > | pkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: > substitution variable ${t64:Provides} used, but is not defined > | dpkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: > substitution variable ${t64:Provides} used, but is not defined > `----
This appears to be working as designed (cc'ing the instigator of this transition for confirmation). It is correct that no ${t64:Provides} is generated on armel, armhf and powerpc (and other 32-bit non-i386 architectures, like hppa). There are four categories of architectures for this transition (text adapted from https://wiki.debian.org/ReleaseGoals/64bit-time, which was itself adapted from a recent message from me to -devel): 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. On these architectures, libopenshot-audio9t64 can safely have Provides: libopenshot-audio9, because the ABI has not actually changed. 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. On i386, libopenshot-audio9t64 can have the Provides, as above. 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. On x32, libopenshot-audio9t64 should ideally have the Provides, as above (I'm not sure whether it actually does, but given the status of x32, I don't think this is actually harming anyone.) 4. armel, armhf are the two 32-bit release architectures which are not in any of the previous categories, so they are genuinely changing their ABIs. Non-release architectures in the same category: hppa m68k powerpc sh4. On these architectures, libopenshot-audio9t64 must not have a Provides on libopenshot-audio9, because its ABI has changed, so the new library does not provide an interface that is compatible with the old library. (This is the reason why we're doing all this renaming!) So I think this is not a bug, and certainly not a RC bug. The warnings are a bit annoying, but do not indicate a genuine problem. smcv