Hi!

you recently removed M-A:foreign from this package (which seems correct).
Instead of dropping it, please mark the package as M-A:same to allow
cross-builds that involve it in the dependency tree.

E.g., at the moment "turtlefmt" is not cross-buildable caused by this lack of
M-A annotation (although I am not sure it is the only problem ;)):

$ sbuild -d unstable --host arm64 turtlefmt
[..]
Setting up sbuild-build-depends-dose3-dummy:arm64 (0.invalid.0) ...
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 106179
(I)Dose_applications: Cudf Universe: 106179 packages
(I)Dose_applications: --checkonly specified, consider all packages as background packages
(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
foreign-architecture: arm64
report:
 -
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: arm64
  status: broken
  reasons:
   -
    missing:
     pkg:
      package: librust-reqwest-dev
      version: 0.12.28-1
      architecture: arm64
      unsat-dependency: librust-rustls-pki-types-1+default-dev:arm64 (>= 1.9.0-~~) | librust-rustls-pki-types-1+default-dev:arm64 (>= 1.9.0-~~)
     depchains:
      -
       depchain:
        -
         package: sbuild-build-depends-main-dummy
         version: 0.invalid.0
         architecture: arm64
         depends: librust-reqwest-0.12+blocking-dev:arm64 | librust-reqwest-0.12+blocking-dev:arm64

background-packages: 106178
foreground-packages: 1
total-packages: 106179
broken-packages: 1

I noticed this while investigating a fix for cross-builds involving cargo-c
which happened to involve reqwest as well, and thus regressed besides the
cargo-c issues because of the above. Given the prominence of reqwest it would
be great to get this fixed!

Thanks!

Hi Fabian,

Quoting Fabian Grünbichler (2026-01-23 09:01:35)
[...]

Marking as M-A:foreign when reverse dependencies are M-A:same is wrong,
so I removed that.

M-A:same when package itself is arch-all is wrong too.

I don't want to bloat the Debian archive and pressure the auto-builders
with multiple identical copies, so I won't artificially mark the
package as arch-all.

What I find the correct goal here is for most possible packages to be
marked arch-all and M-A:foreign, and a stepping stone to get there is
to not do Multi-Arch marking at all until Arch marking is optimal.

In short, I won't mark M-A:foreign because that would imply marking as
arch-any, which I disagree with doing.

Thanks for bringing it up,

 - Jonas

Control: tags -1 - wontfix
generally applying the Multi-Arch interpreter workaround and in return,
you would apply it whenever it would be practically relevant.

The question at hand effectively is: What is more important? Being able
to cross build turtlefmt or saving a few kilobytes of archive space?

We also agreed on the goal being that our tooling (dpkg, apt, dose, etc)
would become better at expressing this, but in the mean time we use the
tools that are available to us.

I know you disagree with reason and I can relate to those reasons. Some
developers sat down in Brest and devised a vague plan on how improve the
situation on the dpkg side, but it's not as easy as it looks. The
changes needed to the dpkg database are nontrivial sadly. Until that
better solution arrives, please do apply the workaround as you agreed to
earlier.

Helmut