Notice when installing from packages.freedom.press

[eloquence]

Running sudo apt update on Ubuntu 20.04 currently displays the following notice with our recommended packaging configuration:

N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://packages.freedom.press/apt-tools-prod focal InRelease' doesn't support architecture 'i386'

[eloquence]

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:

• Should we test on the 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.
• If we don't enable it, should we do anything else to silence this notice for users who have it enabled?

[legoktm]

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.

[apyrgio]

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.

[legoktm]

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.

[legoktm]

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 #323 (comment) we can sed the correct value into place?

[apyrgio]

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

[apyrgio]

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]

[apyrgio]

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.