Snapcraft pulling wrong arch of debs when building foreign snaps
Metadata
Current evaluation
2018 report: --target-arch=armhf on x86 pulls x86-64 stage-packages debs instead of armhf. No labels, comments, or maintainer response in 6+ years. Legacy --target-arch flag removed; modern cross-compile documents the :$CRAFT_ARCH_BUILD_FOR suffix requirement.
Suggested action: close stale
Reason: The issue is 2283 days old with zero comments, no labels, and no maintainer engagement, and it targets the legacy --target-arch flag that no longer exists in modern snapcraft (legacy mode removed in core22+). The equivalent modern cross-compile behavior was explicitly ruled expected in snapcraft#5335 (closed: stage packages need an explicit :$CRAFT_ARCH_BUILD_FOR suffix plus the ubuntu-ports repo, now documented), so the original problem is no longer reproducible or applicable.
Impact:
20
Quick Win:
11.0
Staleness:
95
Complexity:
45
Confidence:
72
Support Request:
30
Issue body
snapcraft --destructive-mode --target-arch=armhf to build a foreign cpu arch snaps on a x86 machine.
debs specified in stage-packages is not reflecting to the --target-arch=CPU_ARCH when building a snap.
---
Step to reproduce: ( with the attached snapcraft.yaml )
run "snapcraft --destructive-mode --target-arch=armhf"
Expected result:
$> file $SNAP/usr/bin/hello
usr/bin/hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=cb9b55fcb9c1b16033fbd3724d0fac693dd346d1, stripped
Actual result:
$> file $SNAP/usr/bin/hello
squashfs-root/usr/bin/hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4fdca4285732fa8a76721f495e5c5e5295ec237b, for GNU/Linux 3.2.0, stripped
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
20
Quick Win:
11.0
Staleness:
95
Complexity:
45
Confidence:
72
Support Request:
30
|
close stale | 2018 report: --target-arch=armhf on x86 pulls x86-64 stage-packages debs instead of armhf. No labels, comments, or maintainer response in 6+ years. Legacy --target-arch flag removed; modern cross-compile documents the :$CRAFT_ARCH_BUILD_FOR suffix requirement. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
45
Confidence:
90
Support Request:
10
|
close stale | Snapcraft incorrectly pulls x86-64 debs instead of armhf when using --target-arch on x86 machines. The issue has been inactive for over six years with no maintainer response or comments. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
45
Confidence:
85
Support Request:
15
|
close stale | Snapcraft incorrectly pulls x86-64 DEBs instead of armhf when using --target-arch for cross-architecture builds. Unaddressed for over six years with no maintainer interaction or labels. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
98
Complexity:
65
Confidence:
75
Support Request:
15
|
close stale | Snapcraft pulls x86-64 debs instead of the target architecture during foreign builds. The report is over six years old with zero maintainer interaction or updates. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
98
Complexity:
50
Confidence:
85
Support Request:
15
|
close stale | Snapcraft incorrectly pulls x86-64 debs instead of armhf when using --target-arch on x86 hosts. Issue is six years old with no maintainer response or labels. |
Update history
No update history recorded yet.
Related work
-
Related To:
snapcraft#5335
(confidence 85%)
Modern equivalent (build-on/build-for wrong-arch stage packages) closed as expected behavior requiring the :$CRAFT_ARCH_BUILD_FOR suffix and ubuntu-ports repo; documented in official guides.
-
Related To:
snapcraft (launchpad)#2012503
(confidence 75%)
Nearly identical report (Snapcraft 7.3 picks host arch for stage packages when cross-building); its summary points to #5335's expected-behavior resolution.
-
Related To:
snapcraft#5411
(confidence 60%)
More recent, still-open issue on fetching stage packages for non-host architectures; distinct apt unmet-deps problem but same cross-arch stage-packages area.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #2012503 wrong arch of stage packages | snapcraft (launchpad) | open | Snapcraft 7.3 picks host architecture for stage packages when cross-building (build-on amd64, build-for arm64). No maintainer response in 3.4 years. Nearly identical issue #5335 was closed as expected behavior requiring explicit :$CRAFT_ARCH_BUILD_FOR suffix on stage packages. | |
| #1813634 not reliable way to detect target architecture | snapcraft (launchpad) | open | Snapcraft 3.0.1: project.target_arch and SNAPCRAFT_ARCH_TRIPLET give inconsistent values for target arch across native, cross, and multi-arch (build-on/run-on) builds. No maintainer response, no labels, inactive ~7 years. | |
| #2015091 snapcraft download debian package from incorrect arch | snapcraft (launchpad) | open | Cross-architecture gadget snap downloads wrong arch deb (amd64 instead of arm64). Issue is 1249 days old with no maintainer engagement, labels, or assignee. | |
| #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 | Reports that snapcraft --target-arch=i386 on a core20 base silently builds an amd64 snap instead of failing early, wasting build time. Unlabelled, 0 comments, inactive ~5 years; a related core20/i386 bug was closed as superseded by improved arch parsing. | |
| #1817288 snapcraft cleanbuild produces incorrect architecture snap | snapcraft (launchpad) | closed | Abandoned and closed without resolution. The legacy mode cleanbuild multi-arch naming bug remains unfixed due to lack of activity and deprecation of legacy mode. | |
| #1835638 inconsistent to arch behaviour | snapcraft (launchpad) | open | Snapcraft 3.6 stage-packages with 'on <arch>'/'to <arch>' conditionals behave inconsistently: cross-compiling works but native builds fail to pull required packages, and adding 'else' under 'on amd64' mixes arch packages. No maintainer response in 7+ years. | |
| #1835556 No way to natively build for the non-host arch | snapcraft (launchpad) | open | 2018 feature request for snapcraft to build for non-host architectures (e.g. --arch=i386) by launching a matching VM/container. Zero comments, no labels, dormant 7+ years; modern snapcraft now supports cross-arch builds via --build-for, so the request is effectively fulfilled. | |
| #1997752 base core20: wrong arch triplet | snapcraft (launchpad) | closed | Closed without a fix or resolution, likely abandoned due to inactivity. The report indicated Snapcraft incorrectly sets SNAPCRAFT_ARCH_TRIPLET when building on a mismatched host architecture. No comments or patches were submitted. | |
| #4268 [cross-compile] when a deb package that has a dependency to non-architecture deb package, snapcraft does not recognize that and throws a dependency error | snapcraft | open | Cross-compiling a core22 snap with an arch-pinned stage package (gpsd-clients:arm64) fails with 'unmet dependencies: python3-serial' because non-arch-specific deps aren't resolved for the target arch. Maintainer offered a workaround and asked if it reproduces on core24; no reply yet. | |
| #1660302 foreign architecture builds doesn't work with classic snaps | snapcraft (launchpad) | open | Cross-arch builds (--target-arch) of classic snaps fail because the build environment lacks the core snap. Reported 2016 against snapcraft 2.x; 0 comments, no maintainer response; codebase since fully rewritten. |