re-adding debian-mips@ and the bug ;) > Matthias Geiger <werdah...@riseup.net> hat am 16.01.2025 11:55 CET > geschrieben: > On Thu, 16 Jan 2025 11:45, Simon McVittie <s...@debian.org> wrote: > >Source: librsvg > >Version: librsvg/2.59.2+dfsg-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, debian-m...@lists.debian.org > >User: debian-m...@lists.debian.org > >Usertags: mips64el > >Control: block 1091629 by -1 > > > >librsvg/2.59.2+dfsg-1 failed to build on mips64el across multiple retries, > >most recently in > ><https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.59.2%2Bdfsg-1&stamp=1736998842&raw=0>. > >The end of its output looks like this, during dh_auto_build: > > > >> [14/15] /usr/bin/meson --internal exe --unpickle > >> /build/reproducible-path/librsvg-2.59.2+dfsg/obj-mips64el-linux-gnuabi64/meson-private/meson_exe_cargo_wrapper.py_ea39adf033191d3f6abd46936a8fd06c312c29f5.dat > >> warning: `/build/reproducible-path/librsvg-2.59.2+dfsg/.cargo/config` is > >> deprecated in favor of `config.toml` > >> note: if you need to support cargo 1.38 or earlier, you can symlink > >> `config` to `config.toml` > >> Compiling syn v2.0.72 > >> Compiling gdk-pixbuf-sys v0.20.0 > >> Compiling pixbufloader-svg v0.0.1 > >> (/build/reproducible-path/librsvg-2.59.2+dfsg/gdk-pixbuf-loader) > >> error: failed to acquire jobserver token > >> > >> Caused by: > >> Bad address (os error 14) > >> warning: build failed, waiting for other jobs to finish... > >... > >> FAILED: gdk-pixbuf-loader/libpixbufloader_svg.so > > > >Earlier build attempts had a similar error either at the same point in > >the build, or at a diferent point, during dh_auto_test: > > > >> https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.59.2%2Bdfsg-1&stamp=1734507441&raw=0 > >> ␛[1m␛[32m Compiling␛[0m cairo-sys-rs v0.20.0 > >> ␛[1m␛[32m Compiling␛[0m librsvg-c v2.59.2 (/<<PKGBUILDDIR>>/librsvg-c) > >> ␛[1m␛[32m Compiling␛[0m gdk-pixbuf v0.20.0 > >> ␛[1m␛[31merror␛[0m␛[1m:␛[0m failed to acquire jobserver token > >> > >> Caused by: > >> Bad address (os error 14) > >> ␛[1m␛[33mwarning␛[0m␛[1m:␛[0m build failed, waiting for other jobs to > >> finish... > > > >The error message "failed to acquire jobserver token" seems to come from > >rustc or cargo, so I think this FTBFS bug should probably be reassigned > >to rustc for investigation by the mips64el porting team. > This is a known bug on mips64el with rust. loupe already ran into this > too; also swayosd ran into this: > [0] > >"Bad address" seems like it ought to mean EFAULT, which would seem to > >indicate that rustc/cargo or some dependency of rustc/cargo is passing > >a dangling pointer to a system call, or some similar problem? > > > Not sure tbh. > >librsvg is a key package and is required by most of our desktop > >environments, for its use in rendering SVG icons and wallpaper. If this > >FTBFS cannot be fixed or worked around, we will have to look into doing > >architecture-specific removals from mips64el, because it isn't sustainable > >for mips64el to be holding more widely-used architectures hostage - > >but if it is removed, most of the desktop ecosystem will go with it. > > > > Givebacks on mips64el semt to work; but I am not surewhat the underlying > cause is here. Note that current rustc on mips64el in exp ran into the > same issue.
not the one in experimental (that one has a different mips64el issue atm), but it did hit it in the past. firefox-esr ran into it as well (https://bugs.debian.org/1087809) as did loupe (https://bugs.debian.org/1086028), and git triggered it in a unit test as well with no rust involved: https://buildd.debian.org/status/fetch.php?pkg=git&arch=mips64el&ver=1%3A2.45.2-1.2&stamp=1731806317&raw=0 (grep for 'bad address') relevant quotes from IRC from that: 20:45:50 <f_g> XXX: the original log looks like read(2) returns EFAULT, according to the man page that means the buffer being read into is outside of the accessible address sapce 20:46:19 <f_g> which is weird, given that it's declared right above the read with a 16k size 20:46:31 <f_g> assuming the error message and the single location my grep turned up actually line up 20:46:53 <f_g> (line 72 of builtin/upload-archive.c) 21:12:24 <f_g> yeah, seems weird. I mean, that test in particular also seems weird, it sets a limit of 500k and the test output says the minimum for that limit is 1M, and the test data is 1M ;) 21:12:47 <f_g> so maybe that causes some edge case, but why that would only affect mips64el I don't know 21:13:47 <f_g> nothing there screams mips64el specific to me so far, but I am far from an expert for such things :) notable the git issue back then was not reproducible on eberlin, and a give back "solved" it by virtue of being scheduled on a different buildd (after failing in a different fashion on yet another buildd): https://buildd.debian.org/status/logs.php?pkg=git&ver=1%3A2.45.2-1.2&arch=mips64el I kind of assumed all of the above are the same underlying (hardware?) issue, and cargo just has a particular code/memory access pattern that triggers it more often.. but maybe the two are unrelated, and it is actually two bugs.. I did take a cursory glance at the job token in cargo/jobserver and nothing there looked problematic..
