Hi, Am Thu, Jan 19, 2023 at 12:52:13AM +0100 schrieb Drew Parsons: > On 2023-01-18 22:31, Rebecca N. Palmer wrote: > > > > This "broken by numpy 1.24" bug looks to me like 17033, not 17630. > > This has what looks like a trivially-backportable patch, though I > > haven't actually tried that: > > https://github.com/scipy/scipy/pull/17035 > > We can try applying that patch to scipy 1.8 and see if it fixes test > failures.
+1 > > Given that the transition freeze was on 2023-01-12, it's too late to > > move to scipy 1.10 if that's likely to cause significant breakage. > > (Do we have a guess of whether it will, or do we need a package that > > builds in experimental to test that?) > > It's a good question. I figure it wouldn't be much worse than switching the > default python to 3.11 two weeks before freeze. I'm also assuming that Python 3.11 creates more noise in the archive than scipy 1.10. I was motivated to look into scipy upgrade since some Debian Med package needed a more recent scipy than we currently have in unstable. The need for this newer scipy was relaxed thanks to a patch from Nilesh. However, having a recent scipy inside the next stable release is nice to have. If we realise that switching scipy might ease the 3.11 migration it might be something we could convince the release team about despite we are in transition freeze. > A handful of deprecated > functions got removed, likely some package will break but it is probably > fixable. But best to upload to experimental first. We should do so in any case. > > The scipy 1.10 FTBFS in salsa ( > > https://salsa.debian.org/python-team/packages/scipy/-/pipelines/486634 > > ) is it trying to download test data, which isn't allowed for a > > build-time test. We could make those tests autopkgtest-only, or if > > the data is reasonably sized, add it to the package: Pooch can use a > > local cache. > > https://sources.debian.org/src/pooch/1.6.0-2/README.rst/ > > pooch is used for scipy.datasets, which is a new scipy submodule. As such > it's fair enough to just skip those new tests if necessary. Skipping at > build-time is simpler than caching, though the cached dataset tests are > light (the downloaded datasets are not so large, 3 files 1.9M total) The > default cache is ${HOME}/.cache/scipy-data, we'd need to learn how to point > it at, say, debian/scipy-data instead. > > The 3 files in question are defined in datasets/_registry.py, > > registry_urls = { > "ascent.dat": > "https://raw.githubusercontent.com/scipy/dataset-ascent/main/ascent.dat";, > "ecg.dat": > "https://raw.githubusercontent.com/scipy/dataset-ecg/main/ecg.dat";, > "face.dat": > "https://raw.githubusercontent.com/scipy/dataset-face/main/face.dat"; > } > > The test_data tests that break (with no internet or cache) are > test_existence_all > test_ascent > test_face > test_electrocardiogram > > If we're in a rush because of the freeze then skipping these tests at > build-time is reasonable. +1 Kind regards Andreas. -- http://fam-tille.de
