Bug#1125014: dies on unknown architecture in .dsc

[Stuart Prescott]

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/ stuart at nanonanonano.net
Debian Developer  http://www.debian.org/       stuart at debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7