Bug#1086025: loupe: FTBFS with DEB_BUILD_OPTIONS=optimize=-lto: Unrecognized option: 'config'

[Matthias Geiger]

On Fri, 25 Oct 2024 10:41, Simon McVittie <smcv at 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-rust at 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