snapcraft download debian package from incorrect arch
Metadata
Current evaluation
Cross-building for arm64 on amd64 resolved explicitly qualified bsdmainutils:arm64 to an amd64 package; the valid report remains untriaged and a similar bug is still open.
Suggested action: needs triage
Reason: The report provides Snapcraft 7.3.1 revision 8931, a complete configuration, build-on amd64/build-for arm64, an arm64 repository, and the concrete result that bsdmainutils:arm64 staged amd64 files. It has no labels, maintainer response, comments, or explicit resolving linkage; relevant target-architecture commits exist, but the evidence is insufficient to declare it resolved.
Evaluated by: mr-cal-bot
Impact:
68
Quick Win:
21
Complexity:
64
Confidence:
84
Actionability:
85
Issue body
Hi,
I am using snapcraft 7.3.1 revision 8931 to build a gadget snap on a focal vagrant environment, and here is the snapcraft.yaml
"""
name: test-gadget
base: core22
version: 22-0.1
summary: test
description: |
test only
type: gadget
architectures:
- build-on: amd64
build-for: arm64
confinement: strict
grade: stable
package-repositories:
- type: apt
architectures: [ arm64 ]
components: [ main ]
suites: [ jammy, jammy-security, jammy-updates, jammy-backports ]
key-id: F6ECB3762474EDA9D21B7022871920D1991BC93C
url: http://ports.ubuntu.com/ubuntu-ports
parts:
prepare-device-deps:
plugin: nil
stage-packages:
- bsdmainutils:arm64
stage:
- usr/bin/hexdump
"""
After the snap is built successfully, it turns out that the bsdmainutils downloaded is actually from amd64 instead of arm64.
I have done some investigation and come up with two potential solution
1. the python-apt somehow return a amd64 package name in "get_providing_packages()" in "python-apt/apt/cache.py", so maybe we can try to check the arch before return the list. However, the "mark_packages()" in "craft_parts/packages/apt_cache.py" will also need to check the length of returned list first instead of accessing the first element directly
2. maybe check the arch in the "mark_packages()" in "craft_parts/packages/apt_cache.py"
Please let me know if you need any further info from me, any suggestions for how to fix is very welcome, and I am happy to try to provide fix with PR as well if there is a plan on how to fix
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
68
Quick Win:
21
Complexity:
64
Confidence:
84
Actionability:
85
|
needs triage | Cross-building for arm64 on amd64 resolved explicitly qualified bsdmainutils:arm64 to an amd64 package; the valid report remains untriaged and a similar bug is still open. | |
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
27
Complexity:
43
Confidence:
87
Actionability:
82
|
needs triage | Cross-building a core22 gadget on amd64 for arm64 stages bsdmainutils:arm64 from amd64; the exact reproducer is supplied, but the issue has no maintainer triage. | |
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
22
Complexity:
52
Confidence:
79
Actionability:
80
|
needs triage | Cross-building an arm64 gadget on amd64 resolves the explicitly requested bsdmainutils:arm64 stage package to amd64; the issue remains untriaged with no maintainer activity. | |
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
26
Complexity:
44
Confidence:
89
Actionability:
79
|
needs triage | An amd64 host builds an arm64 gadget snap but downloads explicitly requested bsdmainutils:arm64 from the amd64 repository. The detailed reproducer remains untriaged. | |
| qwen3.6-35b-a3b-mtp-q6 |
Impact:
70
Quick Win:
35
Staleness:
85
Complexity:
50
Confidence:
70
Support Request:
15
|
needs triage | Cross-architecture gadget snap downloads wrong arch deb (amd64 instead of arm64). Issue is 1249 days old with no maintainer engagement, labels, or assignee. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
40
Confidence:
85
Support Request:
10
|
close stale | Bug report on incorrect architecture package downloads during snapcraft builds, including reproduction steps and potential fixes. Unaddressed for over 3 years with zero maintainer interaction. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
65
Confidence:
90
Support Request:
10
|
needs triage | Bug where snapcraft downloads amd64 packages instead of specified arm64 architecture when building gadget snaps. Untriaged, no maintainer response, inactive for over 3 years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
60
Confidence:
90
Support Request:
10
|
close stale | Bug where snapcraft downloads amd64 packages instead of arm64 when cross-compiling gadget snaps. Unlabelled, no maintainer response, inactive for over 3 years. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Duplicate Of:
snapcraft (launchpad)#2012503
(confidence 94%)
Reports the same cross-build failure where stage packages are fetched as amd64 instead of arm64 and remains open.
-
Likely Fixed By:
snapcraft#3416
(confidence 62%)
Commit 8f418e3d9 is titled "repo: default to target arch for stage package cache" and is directly relevant, but no evidence explicitly links it to this report.
-
Related To:
snapcraft#3461
(confidence 58%)
Commit 0bf7a2e66 accounts for architecture and version when filtering stage packages, matching the suspected filtering path.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #5219 Snapcraft unable to compile ARM64 kernel | snapcraft | open | ARM64 core20 kernel cross-builds fail while fetching snapd:arm64; a minimal apt reproducer exists, but the report has no maintainer triage or release mapping. | |
| #1881515 Snapcraft pulling wrong arch of debs when building foreign snaps | snapcraft (launchpad) | closed | Reported --target-arch pulling wrong debs for foreign arch builds. Maintainers noted the feature was broken and disabled for core20. Marked resolved as cross-builds have been significantly improved in recent Snapcraft versions. | |
| #1698888 Snapcraft dpkg-query error on multiarch OS | snapcraft (launchpad) | open | The 2017 multiarch `dpkg -L libc6` build failure was acknowledged, but the affected legacy code has since disappeared; current Snapcraft no longer contains that call. | |
| #2012074 snapcraft cannot build snap by default on aarch64 | snapcraft (launchpad) | open | ARM64 default builds failed on Snapcraft 7.3.1 because core20 selected amd64-only Multipass images; later defaults use core22/LXD on Linux, addressing the reported path. | |
| #1641123 snapcraft does not properly detect the architecture when kernel is 64 bits but userspace is 32 | snapcraft (launchpad) | closed | Fixed in snapcore/snapcraft#1089 by deriving the build architecture from the compiler target, preventing 32-bit ARM artifacts from being mislabeled arm64. | |
| #2012503 wrong arch of stage packages | snapcraft (launchpad) | open | Confirmed cross-build stage packages are fetched for amd64 instead of arm64; no fix or verification is recorded, so the valid cross-compilation bug remains open. | |
| #1943603 snapcraft --target-arch=i386 does not build i386 images, because core20 does not support i386 and yet the build starts and wastes time | snapcraft (launchpad) | open | Legacy Snapcraft accepted an unsupported core20/i386 target, wasted build time, and produced an amd64 snap; current validation excludes i386 and drops core20. | |
| #1534531 snapcraft-examples opencv example cannot run on armhf | snapcraft (launchpad) | closed | Duplicate of snapcraft#1534530, where the armhf OpenCV failure was attributed to building on Wily for an older target; building on Xenial worked, so no code fix was needed. | |
| #1534530 snapcraft-examples opencv example cannot run on armhf | snapcraft (launchpad) | closed | Reporter built snapcraft-examples opencv snap on Wily and ran it on a device with older libstdc++ (GLIBCXX_3.4.21 missing). Maintainer explained it must be built on the target release; reporter verified on Xenial and closed the report as invalid. |