Control: tags -1 + moreinfo
Hello!
(Guillem - this is about architecture tuple names; see
bugs.debian.org/1125014 for additional context if needed)
The data source that python3-debian uses for valid architectures is
dpkg, and kfreebsd seems to have been dropped from
/usr/share/dpkg/ostable and /usr/share/dpkg/tupletable between trixie
and forky:
trixie:
$ grep freebsd /usr/share/dpkg/*table
/usr/share/dpkg/ostable:eabihf-gnu-kfreebsd kfreebsd-gnueabihf
kfreebsd[^-]*-gnueabihf
/usr/share/dpkg/ostable:base-gnu-kfreebsd kfreebsd-gnu
kfreebsd[^-]*(-gnu.*)?
/usr/share/dpkg/ostable:base-bsd-freebsd freebsd
freebsd[^-]*
/usr/share/dpkg/tupletable:base-gnu-kfreebsd-amd64
kfreebsd-amd64
/usr/share/dpkg/tupletable:base-gnu-kfreebsd-i386
kfreebsd-i386
/usr/share/dpkg/tupletable:base-bsd-freebsd-amd64
freebsd-amd64
/usr/share/dpkg/tupletable:base-bsd-freebsd-arm freebsd-arm
/usr/share/dpkg/tupletable:base-bsd-freebsd-arm64
freebsd-arm64
/usr/share/dpkg/tupletable:base-bsd-freebsd-i386 freebsd-i386
/usr/share/dpkg/tupletable:base-bsd-freebsd-powerpc freebsd-powerpc
/usr/share/dpkg/tupletable:base-bsd-freebsd-ppc64
freebsd-ppc64
/usr/share/dpkg/tupletable:base-bsd-freebsd-riscv
freebsd-riscv
sid
$ grep freebsd /usr/share/dpkg/*table
/usr/share/dpkg/ostable:base-bsd-freebsd freebsd
freebsd[^-]*
/usr/share/dpkg/tupletable:base-bsd-freebsd-amd64
freebsd-amd64
/usr/share/dpkg/tupletable:base-bsd-freebsd-arm freebsd-arm
/usr/share/dpkg/tupletable:base-bsd-freebsd-arm64
freebsd-arm64
/usr/share/dpkg/tupletable:base-bsd-freebsd-i386 freebsd-i386
/usr/share/dpkg/tupletable:base-bsd-freebsd-powerpc freebsd-powerpc
/usr/share/dpkg/tupletable:base-bsd-freebsd-ppc64
freebsd-ppc64
/usr/share/dpkg/tupletable:base-bsd-freebsd-riscv
freebsd-riscv
The data source was changed in dpkg
5d17f447257a7ea5fa60e3496e365c29a2b63cc5 where all kfreebsd references
were dropped. I see some old Debian architectures (official and
unofficial) are still present in these files while others are missing,
and there's also some architectures from d-ports there, so I'm not sure
of the intention of these data; my feeling is that historical names
probably should be retained in these tables. I'm including Guillem in thi
I'm not sure whether the problematic behaviour should *also* be changed
in python-debian to not raise exceptions on unknown architectures - I
doubt that python-debian should blindly ignore invalid architectures in
this code either.
Christoph, I'm not sure how to actually provoke the failure you're
seeing - my attempts to make a very minimal reproducer have failed. What
versions of dpkg and python3-debian are involved? Perhaps Paul can add
some autopkgtest knowledge to this to help too, to know how
architecture_is_concerned is being called in this situation.
thanks
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ [email protected]
Debian Developer http://www.debian.org/ [email protected]
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
