On 23.10.24 12:00, Simon McVittie wrote:
Source: loupe
Version: 47.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-r...@lists.debian.org, b...@debian.org
Control: block 1085885 by -1
User: debian...@lists.debian.org
Usertags: i386
loupe failed to build from source on i386:
https://buildd.debian.org/status/fetch.php?pkg=loupe&arch=i386&ver=47.0-3&stamp=1728056118&raw=0
running 2 tests
test src/util/gettext.rs - util::gettext::apply_unicode_escapes (line 46) ...
FAILED
test src/util/gettext.rs - util::gettext::hex_to_char (line 83) ... FAILED
failures:
---- src/util/gettext.rs - util::gettext::apply_unicode_escapes (line 46)
stdout ----
rustc-LLVM ERROR: out of memory
Allocation failed
Couldn't compile the test.
---- src/util/gettext.rs - util::gettext::hex_to_char (line 83) stdout ----
rustc-LLVM ERROR: out of memory
Allocation failed
Couldn't compile the test.
This seems to be repeatable: the build of 47.0-3 was retried a couple of
times and it fails like this every time. 47.0-1 and -2 had what appears
to be the same issue.
Right, I have been meaning to look into this.
I think the most recent version that built successfully on i386, 46.2-2,
might not have had a test suite at all?
yes, the compile tests are a nuisance; I disabled lto because of this
for three gtk-rust apps already (and extended the timeout generously).
47.0-1 appears to have had the same symptom on armel and armhf, our only
other 32-bit architectures where loupe's build-dependencies are available,
and that was addressed by disabling LTO on those architectures. If
the problem is that the buildd ran out of virtual address space, then
it's going to affect every 32-bit architecture equally, so perhaps this
workaround needs to be extended to all 32-bit architectures? That would
look something like:
-ifneq (,$(filter armel armhf,$(DEB_HOST_ARCH)))
+ifeq ($(DEB_HOST_ARCH_BITS),32)
(Or perhaps the Rust team could arrange for rustc/dh_cargo to disable
memory-hungry optimizations like LTO in all 32-bit builds automatically?)
This might be a sensible default. While it is only an issue for large
binaries such as loupe, snapshot and glycin-loaders I think the are no
downsides to making it the default since GTK+rust always takes long to
compile (even on my build machine with 32 GBs of RAM).
Since f_g kindly fixed the escaping in the wrapper it now can be
simplified to
ifeq ($(DEB_HOST_ARCH_BITS),32)
DEB_BUILD_OPTIONS=-lto
endif
I will upload a fixed version later today incorporating this.
best,
werdahias
