- Package:
- src:scikit-learn
- Source:
- scikit-learn
- Submitter:
- Neil Williams
- Date:
- 2024-02-18 00:45:10 UTC
- Severity:
- serious
- Tags:
The new version of scikit-learn has not migrated to testing because it has not built on all required architectures. This is now affecting other packages as the version of scikit-learn in testing is too old to allow reverse dependencies to build. e.g. opentsne https://buildd.debian.org/status/package.php?p=scikit-learn This error crops up in the in-build tests: =================================== FAILURES =================================== [31m[1m________ [doctest] sklearn.ensemble._weight_boosting.AdaBoostRegressor _________[0m 1004 Examples 1005 -------- 1006 >>> from sklearn.ensemble import AdaBoostRegressor 1007 >>> from sklearn.datasets import make_regression 1008 >>> X, y = make_regression(n_features=4, n_informative=2, 1009 ... random_state=0, shuffle=False) 1010 >>> regr = AdaBoostRegressor(random_state=0, n_estimators=100) 1011 >>> regr.fit(X, y) 1012 AdaBoostRegressor(n_estimators=100, random_state=0) 1013 >>> regr.predict([[0, 0, 0, 0]]) Expected: array([4.7972...]) Got: array([5.74049295])
Hi, I have uploaded the attached debdiff as NMU to DELAYED/2. Please let me know if I should cancel the upload. Paul
Hi,
as I explained to Debian Science list[1] I'd recommend to drop armel and
armhf architectures. I checked the build logs and noticed that these
architectures are failing with "Bus error". While I subscribe to the
reasoning that this could be caused by some coding bug which hides
somewhere and is not detected on other architectures I think we should
draw some line here. Obviously we do not have the power to maintain
this code for all architectures neither do I expect that there is any
honest user of this code on the said architectures. So I would simply
exclude these from the list of architectures.
For the other architectures I opened two different issues upstream:
Test suite failure for arm64, ppc64el, s390x, ppc64 and risc64[2]
and
Second build failure for s390x and ppc64[3]
Kind regards
Andreas.
PS: Volunteers to sort out the Bus error on the 32 bit arm architectures
are welcome.
[1] https://lists.debian.org/debian-science/2022/02/msg00029.html
[2] https://github.com/scikit-learn/scikit-learn/issues/22503
[3] https://github.com/scikit-learn/scikit-learn/issues/22504
Dear Arm Porters Is anyone able to help with the bus error on armhf please?
Hello! 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. Adrian
HellO! So, I have skimmed over the build logs and one of the main issues is the use of -march flags to enforce a certain baseline [1]: powerpc64le-linux-gnu-gcc: error: unrecognized command-line option ‘-march=native’; did you mean ‘-mcpu=native’? This is a policy violation and must be fixed in any case. Blacklisting architectures is not enough in this case as forcing the baseline of the buildds can lead to code that won't run on the user's machines. Adrian
Hi Christian! I'm happy to look at this issue but first the baseline issue must be fixed as this is a Debian Policy violation. Thanks, Adrian
Hi, 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. Best, Christian
Hi,
Am Wed, Feb 16, 2022 at 12:09:23PM +0100 schrieb John Paul Adrian Glaubitz:
the amd64 build log[2]:
...
running build_clib
customize UnixCCompiler
customize UnixCCompiler using build_clib
CCompilerOpt.cc_test_flags[1013] : testing flags (-march=native)
C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
creating /tmp/tmpk22ehoi2/usr
creating /tmp/tmpk22ehoi2/usr/lib
creating /tmp/tmpk22ehoi2/usr/lib/python3
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils/checks
compile options: '-c'
extra options: '-march=native'
CCompilerOpt.cc_test_flags[1013] : testing flags (-O3)
C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
...
I admit I'm not sure at what point / what tool might inject this string and
I'm also not sure whether the option -march=native is really used in the
amd64 case.
Kind regards
Andreas.
[2] https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=amd64&ver=1.0.2-1&stamp=1644952702&raw=0
Hi,
Am Sat, Jul 16, 2022 at 05:58:33PM +0200 schrieb julien.puydt@gmail.com:
I have extremely bad experiences when upstream was running circles to
finally get the guest account and gave up. There was also some
discussion in this bug log[1]
Before we stop progress in Debian for many other architectures since we
cant't solve this on our own or otherwise are burning patience of
upstream I'd alternatively consider droping armel as supported
architecture.
Kind regards
Andreas.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003165#37
I am definitely +1 for this, however scikit-learn is a key package and dropping it from armel would mean dropping several revdeps as well. I am a bit unsure if that is fine or not.
Hi Nilesh,
Am Wed, Jul 20, 2022 at 06:21:19PM +0530 schrieb Nilesh Patra:
Its not fine at all and I would not be happy about it. However, the other
side of a key package is, that lots of package have testing removal warnings
on architectures which are widely used and we have real trouble because of
this.
Kind regards
Andreas.
Hi Graham,
Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs:
... this was five months ago and silence since then. We've lost lots of
packages in testing and I see no progress here. It seems upstream is not
actually keen on working on this as well. Meanwhile they stepped forward
with new releases and I simply refreshed the issues for the new version
(which are the same and not solved).
Currently we have bus errors on arm 32 bit architectures and a baseline
violation on power. If there is no solution at the horizon I'd vote for
excluding these three architectures instead of sit and wait (which is all
I can personally do in this topic).
Could someone give this a try? I know I could use a porter box to do
so but my time is to limited to do it in a sensible time frame.
Kind regards
Andreas.
Hi, From my (very limited!) understanding, this is just setuptools(?) trying out various compiler options. The actual C compiler invocations look more à la: x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.10/sklearn/ensemble/_hist_gradient_boosting/_bitset.o -Lbuild/temp.linux-x86_64-3.10 -o /<<PKGBUILDDIR>>/.pybuild/cpython3_3.10/build/sklearn/ensemble/_hist_gradient_boosting/_bitset.cpython-310-x86_64-linux-gnu.so -fopenmp Moreover, the build finishes with: ########### EXT COMPILER OPTIMIZATION ########### Platform : Architecture: x64 Compiler : gcc CPU baseline : Requested : 'min' Enabled : SSE SSE2 SSE3 Flags : -msse -msse2 -msse3 Extra checks: none CPU dispatch : Requested : 'max -xop -fma4' Enabled : SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_KNL AVX512_KNM AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL Generated : none CCompilerOpt.cache_flush[809] : write cache to path -> /<<PKGBUILDDIR>>/build/temp.linux-x86_64-3.10/ccompiler_opt_cache_ext.py ########### CLIB COMPILER OPTIMIZATION ########### Platform : Architecture: x64 Compiler : gcc CPU baseline : Requested : 'min' Enabled : SSE SSE2 SSE3 Flags : -msse -msse2 -msse3 Extra checks: none CPU dispatch : Requested : 'max -xop -fma4' Enabled : SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_KNL AVX512_KNM AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL Generated : none ... and similarly on armel. I don't know the internal magic of these tools at all, but it seems superficially plausible that the march=native invocations are just instances of the compiler being probed.
I have a long-term power 9 VM (not QEMU) as testbed. I'm trying to investigate the issues for release architectures, but this package is too slow to build with QEMU (multiple hours). (abel.debian.org is also extremely slow for scikit-learn) I've not yet given up, but the build speed means I cannot address this issue in timely manner.
Am Thu, Jul 28, 2022 at 08:15:45PM -0700 schrieb M. Zhou:
architectures, that we will not manage to fix it, it is in the interest
of our users to not support the problematic architectures in favour of
providing it for the architetures where the package is used in practice.
I have perfectly understood that we will loose several packages on that
architectures and that this is not a good step. But having those
packages not at all is eve worse.
Kind regards
Andreas.
We believe that the bug you reported is fixed in the latest version of astrometry.net, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1003165@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ole Streicher <olebole@debian.org> (supplier of updated astrometry.net package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Sun, 31 Jul 2022 16:12:38 +0200 Source: astrometry.net Architecture: source Version: 0.89+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org> Changed-By: Ole Streicher <olebole@debian.org> Closes: 983306 1003165 Changes: astrometry.net (0.89+dfsg-2) unstable; urgency=medium . [ Jenkins ] * Set upstream metadata fields: Bug-Submit, Repository, Repository-Browse. * Remove obsolete field Name from debian/upstream/metadata . [ Ole Streicher ] * Switch build depends on libnetpbm10-dev to libnetpbm-dev (Closes: #1003165) * Push Standards-Version to 4.6.1. No changes needed * Fix copyright for kdtree files (Closes: #983306) Checksums-Sha1: 1cb86aee7d2b1818e037952f9128142d7424b46f 2476 astrometry.net_0.89+dfsg-2.dsc 7e443600e84ac174b543b3450d98776d5db9b02e 44824 astrometry.net_0.89+dfsg-2.debian.tar.xz Checksums-Sha256: 7711ea41cffe97081635990653f8c105e530fa5e860c05d082c70972c494c272 2476 astrometry.net_0.89+dfsg-2.dsc d4a8a3c5e7e167d3536bb495ada7f4aa9c43ec8068ad089cc54f0998257c372d 44824 astrometry.net_0.89+dfsg-2.debian.tar.xz Files: c96b5af05526d9e10c754e9d9c99f76a 2476 science optional astrometry.net_0.89+dfsg-2.dsc a532bd54f35908c6a447cacc140d3c3b 44824 science optional astrometry.net_0.89+dfsg-2.debian.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE7/BpV0Ra2/h0L3qtmk9WvbkOGL0FAmLmj9IACgkQmk9WvbkO GL3hYQ//e+djKZ/lSkL9k1SU9LSad5pqWxHtyaeDZNE1FSRD1hCThxKvpWTtlZJA Blmd8Y0qjqgBYLjGr7+SoLCO0DJbsaWbn7AnmagZkQGvtMnbIBn6X8ICpD0IaLw+ cAA7eIxPKPNuBHbk2p5B9u7Ar/lX+WyZUBdSm0olMN+flurUgGyuzQ+E7gNovNd3 7HBlDBCRJ5jYkYuhBK1QWgGMO3UCIsro8qtA1kgSq08HKHglrFYGKUWFKcyqewFE JZbafl23djyxRoK/g7NyHqEi5HydLu7QkThbld5JWWLVVpY2y4naQ+ikafgHPdj7 Cn9OvtXk/RpOjqEmyrroFOF6cHlikoG8TTZ5/hrz/popgHqW6Wy88PAZ+Q23kz3M iMqut3fYsFrJJ/TAg3fn32Y1W//HBZtf/V8Ds7tP064PD/HRGjY1bUAmRkWbKkj6 7YLQ/+ZPrTUOks66OU7AqxkkdlNNrk96Ri/cLV4m9XX2jV3NX40+oqN79IUTGrN+ O716wxD5BlG38qh+dFxaN+L+e+fV0h9dfJHz8MDMjmNddbTuADUuskiFTAMh3sL5 5lFtXcIdShU/54VNlJjJfr9xV+BXpK+DTrCngv0ngsr5dg20n3y8LPKfcOO8C1Bg ShxkdzRe1XHhmO733ru9kV8nKJlUVRbFR1vT65VwVi9AXAlMXoI= =BjpE -----END PGP SIGNATURE-----
reopen 1003165 thanks The astrometry.net d.changelog contains a reference to the wrong bug. Please consider using debchange --closes in future which checks that the bug number assigned to the package being uploaded. 1016400 has not been closed. 1003165 is the wrong bug number and a different package. The B-D bug in astrometry.net is 1016400. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016400
Hi again,
Am Fri, Jul 29, 2022 at 06:09:26AM +0200 schrieb Andreas Tille:
scikit-learn restricted to those architectures only which have all tests
passing and will ask ftpmaster for removal of the others. If you think
this is a bad idea please give good reasons not to do so or even better
fix the package for the problematic architectures.
Kind regards
Andreas.
Hi again,
Am Thu, Aug 04, 2022 at 01:25:42PM +0200 schrieb Andreas Tille:
When looking at the rules file I noticed that we currently exclude
(more or less randomly) certain tests for certain architectures.
So I had two options:
1. Simply add the other failing tests
2. Ignore all failures but print the failures into the build logs
I decided for the latter now in scikit-learn_1.1.2+dfsg-3 and you see
that the package is building now. I've added according README.Debian
which are *architecture specific*[1] to inform our users about
poptential issues.
The drawback of this solution is that we will not get any warning for
new *potentially more important* issues since all test failures will be
ignored now. For me this is outweighted by the advantage that we can
present upstream a full log of all issues in certain architectures and
can open according issues. I admit I'm not really enthusiastic that
upstream will care much about this - but at least we have the logs at
hand and can do something in case someone wants to invest time into
this.
I do not plan to close bugs #1003165 and #1008369 but I think it is
appropriate to reduce its severity to important and thus enable the
package and its dependencies to migrate to testing (I have not checked
debci yet).
Any comments about this strategy?
Kind regards
Andreas.
[1] https://salsa.debian.org/science-team/scikit-learn/-/blob/master/debian/rules#L227
Considering long term maintainance this does not seem to be nice especially keeping in mind the fact that sklearn is a key package. I think it is OK to do it _for the moment_ to allow the dust to settle a bit, and rm'ed packages to get to their destination once again but I'd suggest ``incrementally'' enabling the tests once everything is in place. I agree that upstream is probably not very enthusiastic about fixing those, but if we get fixes, we should keep propagating them. In a nutshell, IMO the sklearn revision that enters bookworm _should_ have tests enabled, without hacks and the tests that do not pass can be disabled (after all, it does not come from our end) Sounds good, and thanks for caring for it.
Hi,
as discussed on Debian Science the affected test suite errors are
ignored for the moment so the package does not FTBFS any more and
thus the bug is not serious any more. Since issues are remaining
the bugs are not closed yet.
Kind regards
Andreas.
Hi Adrian On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: It was pointed out by Gard Spreemann [1], but I notice now that debian-arm was not in CC: 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/
We believe that the bug you reported is fixed in the latest version of
scikit-learn, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1003165@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Tille <tille@debian.org> (supplier of updated scikit-learn package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 17 Feb 2024 14:59:42 +0100
Source: scikit-learn
Architecture: source
Version: 1.4.1.post1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Andreas Tille <tille@debian.org>
Closes: 1003165 1008369 1018635 1027208 1029701 1046775 1049646 1059206
Changes:
scikit-learn (1.4.1.post1+dfsg-1) unstable; urgency=medium
.
* Team upload.
* New upstream version
Closes: #1029701, #1008369, #1027208, #1003165
* Build-Depends: s/dh-python/dh-sequence-python3/ (routine-update)
* Build-Depends: python3-sphinx-copybutton
* Support loong64
Closes: #1059206
* Drop nose from Build-/Test-Depends
Closes: #1018635
* Fix clean target
Closes: #1046775, #1049646
* Work around unknown key 'recommender' in sphinx
* Exclude minimized jquery JS from source and use symlink to Debian
packaged min.js instead (crossing fingers that the version plays nicely)
Checksums-Sha1:
978606cc96691237880a3a2be6ed02ab48cb8d66 3087 scikit-learn_1.4.1.post1+dfsg-1.dsc
6ac713f80103107381d0b104041df96bddaa9fbd 6389528 scikit-learn_1.4.1.post1+dfsg.orig.tar.xz
8fb820f431db091a454ef18754aca750e1b0ae61 23312 scikit-learn_1.4.1.post1+dfsg-1.debian.tar.xz
22158fff23ff6e5925c620b3949954429b024a43 14091 scikit-learn_1.4.1.post1+dfsg-1_amd64.buildinfo
Checksums-Sha256:
52a55300a41630a6a7a79bce38947f7dacfb643bfba558049944f4b5aad19a6a 3087 scikit-learn_1.4.1.post1+dfsg-1.dsc
25cd7954717180112f66a8e8b0340021a58e3b2cdbd59f82c83d7991dca5ff9f 6389528 scikit-learn_1.4.1.post1+dfsg.orig.tar.xz
62c3ee142fd41ee13bf925e2a1efa3cbbe835c1db3fb8a0a829ffaa1eb7f3ced 23312 scikit-learn_1.4.1.post1+dfsg-1.debian.tar.xz
ce99b0a829e7f4ccbae52e3c609d4c00ae434524b01f5b58e0923fdad5ac422b 14091 scikit-learn_1.4.1.post1+dfsg-1_amd64.buildinfo
Files:
afe4d752ce09c233ff177c28208ae191 3087 python optional scikit-learn_1.4.1.post1+dfsg-1.dsc
313775874d682e4ababcbc4a08e740a6 6389528 python optional scikit-learn_1.4.1.post1+dfsg.orig.tar.xz
459683bbda96e5072242b20d7e36bffe 23312 python optional scikit-learn_1.4.1.post1+dfsg-1.debian.tar.xz
e16b327c5110e32b273e44290c324ff6 14091 python optional scikit-learn_1.4.1.post1+dfsg-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJFBAEBCAAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmXQy6IRHHRpbGxlQGRl
Ymlhbi5vcmcACgkQV4oElNHGRtGbORAAm3M86V3z/Q/2ByGlDFQFHBnyaRCDxbTm
jrqSVT6JBW4YEQXs1jPw4a+4mV3mqh+pIQ2tmH5u+u4VJhNPqWiqjQjyG3RpeVhq
USiVX/7XaWYzcbvtyVynksqxGJY+of0RN1L16d6wLfJhSjNKBTBtKtyv4lL730eB
3q3YoRWeuUtH+/jrn1/uPIsjNry07l98TrauupZvLojKvuyQr9xgK3Me2yddu/v4
lcKigj5Yk+tJJLBy4f1ZqsWDtonGNT3YNnde3DbM+fmLheCOAlNo7OQaCuMhN1Om
dvCZEd65RdvfLJXzpYSq5RrExN/B0xtmO5BBn/2lAbTWHXadFKonLTOC/U4skUXP
4tp0C6j/Zj/a6uBy1ZejEKLYmqclChgahPRj6l4c3lTrfla1YpLOnsZRRBKQQ/PC
7GLjhZxusBzxIYCoprMXwktmCcICIi/wvEdszjS8MlEr+uRsnec45vbEu3+d7Z+C
njaG3TQAV7B1b988LrFLZ0ia2xq6WVYyO4NAth6J/+1emoLmk2nZdHwoDmXJu+rn
oh10ozbcT8/j3L84cxB3gZCa8lC1VgwA86EieZjE54Kl0afsZqUiwqWSW9OUqR1r
JWdLoWBHnkMYf0ogOVAm7rp4BkcBMV7BDp74O0SSRbfcbShTQgOuWTABhg/SrEWz
iSJHBfpNqAU=
=z95P
-----END PGP SIGNATURE-----