Control: reassign -1 src:linux/6.1.76-1
On Thu, 16 Jan 2025 at 12:39:39 +0000, Simon McVittie wrote:
> Control: retitle -1 Some packages consistently FTBFS with EFAULT (Bad
> address) on most mips64el buildds
>
> On Thu, 16 Jan 2025 at 12:40:07 +0100, Fabian Grünbichler wrote:
> > > 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:
> > > >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.
> >
> > 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')
> ...
> > 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
>
> Yes, I think this does look like a more general mips64el
> problem, which is certainly not a bug in librsvg specifically,
> and probably not a bug in rustc either.
On Sun, 19 Jan 2025 at 12:08:40 +0300, Sergei Golovan wrote:
> I'd like to confirm Erlang FTBFS on mips64el as well. Looking at log
> files at [1]
> one can see that starting from March 2024 mipsel-osuosl-03,
> mipsel-osuosl-04 and mipsel-osuosl-05 can't build erlang (freshly
> built Erlang compiler erlc emits efault).
>
> mipsel-osuosl-01 and mipsel-osuosl-02 build erlang just fine. By the
> way, erlang currently in testing also [cannot?] be built on osuosl-03--05,
> so if it will be necessary to update Erlang in trixy, we will not be
> able to do that on mips64el.
>
> The latest successful build on mipsel-osuosl-03 [2] has
> Kernel: Linux 5.10.0-21-loongson-3 #1 SMP PREEMPT Debian 5.10.162-1
> (2023-01-21) mips64el (mips64)
> Toolchain package versions: binutils_2.40-2 dpkg-dev_1.21.20
> g++-12_12.2.0-14 gcc-12_12.2.0-14 libc6-dev_2.36-8
> libstdc++-12-dev_12.2.0-14 libstdc++6_12.2.0-14
> linux-libc-dev_6.1.11-1
>
> The first failed build on mipsel-osuosl-03 [3] has
>
> Kernel: Linux 6.1.0-18-loongson-3 #1 SMP PREEMPT Debian 6.1.76-1
> (2024-02-01) mips64el (mips64)
> Toolchain package versions: binutils_2.42-3 dpkg-dev_1.22.6
> g++-13_13.2.0-18 gcc-13_13.2.0-18 libc6-dev_2.37-15.1
> libstdc++-13-dev_13.2.0-18 libstdc++6_14-20240303-1
> linux-libc-dev_6.7.9-1
...
> Also, I can say that erlang builds fine on the eberlin porterbox,
> which has an old kernel on some Loongson arch. And also, erlang builds
> fine on QEMU (with malta 5KEf processor and the current kernel and
> toolchain from sid).
When we build in a chroot or container, user-space comes from the chroot
and only the kernel comes from the host, so I think it's reasonable
to say this is either a kernel regression (=> assigning to the kernel)
or a hardware problem (=> we do not have a good package to assign it to).
Either way, reassigning to the kernel seems like a good next step.
librsvg (a rust package) also builds successfully on the old kernel, in
a chroot with (presumably) current user-space, which would similarly
point to this being a problem with the kernel or hardware.
> I wouldn't like to have
> all the Erlang based packages dropped from trixy (removing is already
> scheduled).
Release team: please could you monitor the situation and make sure that
doesn't happen? I don't think this would be fair on either the Erlang team,
or the majority of our users on non-mips64el architectures.
smcv
