[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Failures for sklearn



On 2021-12-06 11:42, Andreas Tille wrote:
Hi Drew,

Am Sat, Dec 04, 2021 at 05:34:54PM +0100 schrieb Drew Parsons:
> Would you have any plans to fix the situation?


My first plan is for someone to notice that it's a team package that they
can fix themselves.

That's for granted.

There's a number of fixes needed, a different problem for each arch, but
each one is trivial on its own.

I admit I had a look into the arm64 issue but can't see how I can fix this
easily.

My backup plan it is to fix it myself if no one gets the job done before I
get round to it.

If you could give some hint I might lend a helping hand

Mind, I don't actually use sklearn myself (that's why I'm happy to let others help with it!), I've only been updating it to keep it from blocking other packages (it was recently blocking numpy, but numpy was then allowed top migrate into testing regardless).

In regards to the arm64 (and ppc64el, also s390x) failure, it's reported upstream at
https://github.com/scikit-learn/scikit-learn/issues/17798

It's 1 failed test next to 21756 passing tests, so my recommendation is to simply skip it on these arches until #17798 is fixed. debian/rules is already set up with EXCLUDE_TESTS for each architecture that needs it.

The i386 failure seems to be just a question of tolerance. It's set to relative tolerance 0.001, it gets 0.0012 on i386. Reported and discussed at https://github.com/scikit-learn/scikit-learn/issues/19230

The armel error might be related to https://github.com/scikit-learn/scikit-learn/issues/14997

The s390x feature_extraction FeatureHasher failure doesn't seem to be reported upstream yet.

There's only 1 or 2 tests failing in each case. They could each just be added in turn to EXCLUDE_TESTS and ignored if there's no easy way to actually fix the failures.

Drew


Reply to: