Bug#1125014: dies on unknown architecture in .dsc

[Paul Tagliamonte]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-python-debian-maint/attachments/20260113/12c5334b/attachment.sig>