Bug#1125014: dies on unknown architecture in .dsc

[Guillem Jover]

Hi!

[ Paul Tagliamonte CCed, related to our earlier dak vs dpkg arch data
  discussion. ]

On Sun, 2026-01-11 at 15:54:01 +1100, Stuart Prescott wrote:
> Control: tags -1 + moreinfo

> (Guillem - this is about architecture tuple names; see
> bugs.debian.org/1125014 for additional context if needed)

(Thanks for looping me in!)

> 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:

> 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

(Sentence seems to be cut off.)

So the intention with the architecture cleanups that I've been doing
in the past (now recently when removing kopensolaris-any, kfreebsd-any
and powerpcspe; and previously by restricting valid subsets of
wildcards for hurd, freebsd, dragonflybsd, darwin, solaris, aix,
and removal of knetbsd-any, uclinux, arm64ilp32, avr32, m32r and
tilegx; and even earlier the removal of lpia, which I think was the
first removal), has been to make it visible that these are long dead
architectures (for example a kernel or libc does not support them at
all anymore or ever, they cannot be bootstrapped, etc) that do not
need to be supported anymore in packaging, and so that tooling that
pulls arch data from dpkg (such as lintian), can then start emitting
tags that those can be removed from packaging.

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).

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.

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.

[C] <https://lists.debian.org/debian-dpkg/2025/09/msg00009.html>

I guess autopkgtest might perhaps need something similar?

> 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.

During the above linked conversations, I also wondered whether the
arch definitions should instead be kept longer (or forever) and marked
somehow as obsolete, so that dpkg tooling (and other tooling using the
data files) could emit warnings, and then could error out for unknown
ones.

But I'm not sure whether the added complexity is worth it (and tooling
would need to be adapted to then handle the «obsolete» markings and act
on them), and so whether always emitting warnings for unknown ones is
enough, given that this might as well trigger errors (for example when
output on stderr anyway). And in principle I've been leaning into it
not being worth it.

> 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.

It might be that if the autopkgtest infra is running on an older
Debian release, then it still has the old arch definitions from dpkg,
and that's why you are not seeing this? (Although if you tested
everything locally, then I don't know. :)

In any case, I'm open to discussing alternatives here, if people think
other paths forward might make more sense.

Thanks,
Guillem