Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[Graham Inggs]

Hi Adrian

On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> On 2/16/22 12:33, Christian Kastner wrote:
> >> Bus errors are normally easy to spot. Just run the code in question through
> >> GDB and see where it crashes. Then look at the backtrace with the debug
> >> symbols installed.
> >>
> >> Usually it's a result of bad pointer arithmetics which should definitely be
> >> fixed as such operations usually violate the C/C++ standards.
> >>
> >> I can have quick look.
> >
> > one of these errors has been reported in the past, and I already did
> > some analysis way back then:
> >
> >     https://github.com/scikit-learn/scikit-learn/issues/16443
> >
> > Check the last comment. The relevant Cython code doesn't look wrong, so
> > I guess the problem is with the binary result produced during build, as
> > you point out.
>
> I'm happy to look at this issue but first the baseline issue must be fixed
> as this is a Debian Policy violation.

It was pointed out by Gard Spreemann [1], but I notice now that
debian-arm was not in CC:

> it seems superficially plausible that the march=native
> invocations are just instances of the compiler being probed.

I have also had a look and cannot see that '-march=native' is used in
the actual builds on any of the architectures.

It would be very much appreciated if the arm porters could take a look
at this issue, as it still plagues the scikit-learn autopkgtests on
armhf [2], and currently prevents quite a number of packages from
being part of testing.  It appears that armel [1] has the same error,
so hopefully one fix could resolve both.

Regards
Graham


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003165#86
[2] https://ci.debian.net/packages/s/scikit-learn/testing/armhf/
[3] https://ci.debian.net/packages/s/scikit-learn/testing/armel/