Closed eloquence closed 2 days ago
I saw this on my system because I had the i386
architecture enabled for some legacy packages. After removing the architecture (which is not enabled by default), the notice disappears.
Open questions for me:
i386
architecture and explicitly enable it for our packages if they work on that architecture? Given the legacy nature of this architecture, I think "no" may be a perfectly reasonable answer there.Does the package actually work on non-amd64 architectures? I would assume the container is 64-bit and doesn't work on a i386 system. Also wondering about arm64 systems, those are starting to get more popular on Linux these days...
If it doesn't work on all architectures, we should switch the package to Architecture: amd64
(instead of the current Architecture: all
). If it does work on arm64 too, we can do Architecture: amd64 arm64
. We could then publish an empty i386 Release file, which will prevent the warning.
Thanks for the input @legoktm. You're right, the container is 64-bit, so it wouldn't work on an i386 system. As for arm64 Linux systems, users can build Dangerzone for them (we already do so for MacOS), but that would be a bespoke solution, not something we support.
For this reason, we already specify that this package is available only on amd64
architectures: https://github.com/freedomofpress/apt-tools-prod/blob/main/repo/conf/distributions. So, if having an empty arm64
/ i386
Release file is the way to go, we can move forward with that. I'd like to see if this is something that reprepro
can natively support, so that we don't delete this file by mistake when rebuilding the repo, but that would be a low priority task.
For this reason, we already specify that this package is available only on
amd64
architectures: https://github.com/freedomofpress/apt-tools-prod/blob/main/repo/conf/distributions.
That is the architectures we provide the repository for, but the package itself is marked as being compatible with all architectures:
# apt-cache show ./dangerzone_0.4.1-1_all.deb
Package: dangerzone
Version: 0.4.1-1
Architecture: all
...
(also the "all" in the filename gives it away...)
Presumably there's a setting for stdeb to set the package to Architecture: amd64
...will look.
Nope, it's hardcoded to check if there are extension modules, and if so, set Architecture: any
(which would be fine here, it just means to use whatever architecture it was built on): https://github.com/astraw/stdeb/blob/3e6522cefa240be365ebdc0dc0c7923ba7118999/stdeb/util.py#L882
Maybe if we end up doing something like https://github.com/freedomofpress/dangerzone/issues/323#issuecomment-1485548943 we can sed the correct value into place?
@legoktm Oh, I stand corrected, thanks for pointing that out. So, what you're saying is that we need to get our hands dirty if we want to change the architecture for the package created by stdeb
.
Also, since it's a package config issue, I assume that this means that the notice was always was there. If that's the case, then this issue is not a regression, which is good to know.
A user kindly pointed out that we can restrict this repo to just amd64 packages, by adding [arch=amd64]
to the Debian source line, i.e.:
deb [arch=amd64 signed-by=/etc/apt/keyrings/fpf-apt-tools-archive-keyring.gpg] https://packages.freedom.press/apt-tools-prod ${VERSION_CODENAME?} main
I tested it in a 32-bit Debian container, and the warning message is no longer displayed:
Before:
# sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://deb.debian.org/debian-security bookworm-security InRelease
Get:4 https://packages.freedom.press/apt-tools-prod bookworm InRelease [2307 B]
Fetched 2307 B in 1s (3503 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://packages.freedom.press/apt-tools-prod bookworm InRelease' doesn't support architecture 'i386'
After:
# sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://deb.debian.org/debian-security bookworm-security InRelease
Hit:4 https://packages.freedom.press/apt-tools-prod bookworm InRelease
Get:5 https://packages.freedom.press/apt-tools-prod bookworm/main amd64 Packages [723 B]
A potential issue with this fix though is that if a user is in a 32-bit system, they may erroneously install Dangerzone, which should not be available there. I think the fix that @legoktm suggested is better in the long run, but we haven't managed to work on it yet.
Running
sudo apt update
on Ubuntu 20.04 currently displays the following notice with our recommended packaging configuration: