On Tue, Jan 13, 2026 at 10:14:02AM +0100, Guillem Jover wrote:
This has been prompted by seeing maintainers (in many cases) try to cover all architectures supported by dpkg, when listing them in package metadata or programmatically in code for example, which seems counter productive (and a waste of their time).
A bit OT from why I'm on CC, but FWIW, I agree here. I often see long-dead arches listed in B-D or D lines, and I tend to believe it's copy-paste, not actually done with the intention of dealing with a real problem for a real port (official or otherwise).
In the past I've tried to file reports for obsolete arch usage, but I think for the latest batch, I'd like to let lintian sip in, and then do a bug filing once most maintainers have had a go at removing those dead arches.
Ditto, back when I helped with NEW, I would often see this same thing. I would rarely REJECT or even PROD over it.
While discussing the removal of this last batch, concerns were brought up about dak potentially refusing uploads (even for older releases) when it starts using the dpkg arch tables [C]. Where I talked with Paul Tagliamonte about improving dak to use the dpkg arch table for the target release, so that we could do these cleanups safely (I should perhaps file a report to make this more visible though!). Although as I mentioned in the dpkg list discussion, if this is going to cause unintended fallout for the next stable release, I'm prepared to revert those removals before the Debian release.
Yeah, this is on my TODO. I fully intend to give this a whirl, but i've been set back by a few $LIFE things. I think it's a great idea, and I've recently dealt with dpkg arch tuples, so some of it is even still swapped into cache.
Hopefully dak isn't a factor here. If it becomes one, definitely hit me up directly.
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.
I am not up on autopkgtest; I'm also suprised to be seeing breakage here.
I did look at the source (since I am technically a parseltongue), and we can do a bad thing with the internals to dupe:
```
import debian._arch_table
table = debian._arch_table.DpkgArchTable.load_arch_table()
table._dpkg_wildcard_to_tuple("kfreebsd-amd64")
```
On sid this gives me:
```
Traceback (most recent call last):
File "<python-input-14>", line 1, in <module>
table._dpkg_wildcard_to_tuple("kfreebsd-amd64")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 143, in
_dpkg_wildcard_to_tuple
result = self._dpkg_arch_to_tuple(arch)
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 152, in
_dpkg_arch_to_tuple
return self._arch2table[dpkg_arch]
~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'kfreebsd-amd64'
```
Which looks the same.
fondly,
paultag
--
⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte <paultag>
⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/
⢿⡄⠘⠷⠚⠋ Debian, the universal operating system.
⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
signature.asc
Description: PGP signature
