On Fri, 25 Oct 2024 10:41, Simon McVittie <s...@debian.org> wrote:
Source: loupe
Version: 47.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-r...@lists.debian.org
loupe failed to build (again) on the 32-bit release architectures armel,
armhf and i386:
https://buildd.debian.org/status/fetch.php?pkg=loupe&arch=armel&ver=47.1-2&stamp=1729795225&raw=0
Running `CARGO=/usr/share/cargo/bin/cargo […]
/<<PKGBUILDDIR>>/obj-arm-linux-gnueabi/src/armv5te-unknown-linux-gnueabi/release/deps/loupe-c4a9e232bbfbc423
--test-threads=1 --config profile.release.lto=false`
error: Unrecognized option: 'config'
These are exactly the architectures where this package is built with
"optimize=-lto" in DEB_BUILD_OPTIONS, to work around previous versions
running out of virtual address space on 32-bit machines.
The handling of passing along this flag was broken in earlier versions
of the wrapper ( /usr/share/cargo/bin/cargo ) we invoke to build loupe.
I don't know Rust, but this looks to me to be more like a problem with
how `cargo test` is invoking the test executable, rather than a problem
with this specific package.
yes. Now the "cargo test" command suffers from a similar issue by
incorrectly passing along the lto flag.
loupe is almost a leaf package (gnome-core depends on it, but nothing
else does). If it is going to have recurring build problems on 32-bit,
perhaps instead of disabling LTO we should just not build it on the
32-bit architectures, and make gnome-core depend on loupe on 64-bit
architectures and eog on 32-bit?
I think once the wrapper is fixed loupe *should* build fine on all
release arches. If more problems pop up in similiar fashion feel free to
let gnome-core depend on a loupe / eog mix.
best,
werdahias
