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
