python-mne fails to build with Python 3.10.0a4. =================================== FAILURES =================================== _______________________________ test_object_size _______________________________ mne/utils/tests/test_numerics.py:305: in test_object_size assert lower < size < upper, \ E AssertionError: 100 < 64 < 400: E {} E assert 100 < 64 For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01865172-python-mne/ For all our attempts to build python-mne with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-mne/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This is a mass-posted update. Sorry if it is not 100% accurate to this bugzilla. The Python 3.10 rebuild is in progress in a Koji side tag. If you manage to fix the problem, please commit the fix in the rawhide branch, but don't build the package in regular rawhide. You can either build the package in the side tag, with: $ fedpkg build --target=f35-python Or you can the build and we will eventually build it for you. Note that the rebuild is still in progress, so not all (build) dependencies of this package might be available right away. Thanks. See also https://fedoraproject.org/wiki/Changes/Python3.10 If you have general questions about the rebuild, please use this mailing list thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/G47SGOYIQLRDTWGOSLSWERZSSHXDEDH5/
The f35-python side tag has been merged to Rawhide. From now on, build as you would normally build.
*** Bug 1969031 has been marked as a duplicate of this bug. ***
Some of this seems to be fixed in Git, for example: https://github.com/mne-tools/mne-python/commit/e8727cb016d034263a4f17e68e12b1ebf5dacc8d but it'll need to be backported to this release (doesn't apply cleanly). Aniket, do you think this is worth doing, or should we package the current snapshot for the time being maybe? Thoughts?
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Waiting for Scipy to create a release with Py3.10 support. As soon as it is released, the next version of python-mne with py3.10 support can be provided. https://mne.discourse.group/t/mne-python-new-release/3558/4
Note that SciPy already works with Python 3.10, it is just they have not yet released wheels.
I've tried to build the tarball from the unreleased branch, but I've ended up with: ==================================== ERRORS ==================================== _________________ ERROR collecting tools/generate_codemeta.py __________________ tools/generate_codemeta.py:61: in <module> all_names = [parse_name(line) for line in lines] tools/generate_codemeta.py:61: in <listcomp> all_names = [parse_name(line) for line in lines] tools/generate_codemeta.py:25: in parse_name _, name_and_email = name.strip().split('\t') E ValueError: not enough values to unpack (expected 2, got 1)
Hey Miro, Thanks for trying it out! :D From what I could gather, the files in `tools/` are the helper files for the GitHub workflows and are not required for building the package (outside the GitHub env). Pytest also collects these files while collecting tests and runs them (since they are scripts). If these scripts were run within the Git directory, there wouldn't be an issue since it runs `git shortlog -nse` to get a list of the authors. One could simply remove the files in `tools/` and manually build the package without any issues.
That leaves: =================================== FAILURES =================================== _____________________________ test_module_nesting ______________________________ mne/tests/test_import_nesting.py:43: in test_module_nesting assert code == 0, stdout + stderr E AssertionError: E Found un-nested import(s) for ["scipy submodules: ['misc', 'sparse']"]/builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! E scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 E icount = indentcount_lines(lines[1:]) E /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! E scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 E icount = indentcount_lines(lines[1:]) E /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! ...snip... E scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 E icount = indentcount_lines(lines[1:]) E /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! E scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 E icount = indentcount_lines(lines[1:]) E /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! E scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 E icount = indentcount_lines(lines[1:]) E E assert 1 == 0 ----------------------------- Captured stdout call ----------------------------- Running subprocess: /usr/bin/python3 -c import sys import mne out = set() # check scipy (Numba imports it to check the version) ok_scipy_submodules = set(['scipy', 'numpy', # these appear in old scipy 'version']) scipy_submodules = set(x.split('.')[1] for x in sys.modules.keys() if x.startswith('scipy.') and '__' not in x and not x.split('.')[1].startswith('_') and sys.modules[x] is not None) bad = scipy_submodules - ok_scipy_submodules if len(bad) > 0: out |= {'scipy submodules: %s' % list(bad)} # check sklearn and others for x in sys.modules.keys(): for key in ('sklearn', 'pandas', 'mayavi', 'pyvista', 'matplotlib', 'dipy', 'nibabel', 'cupy', 'picard', 'pyvistaqt'): if x.startswith(key): x = '.'.join(x.split('.')[:2]) out |= {x} if len(out) > 0: print('\nFound un-nested import(s) for %s' % (sorted(out),), end='') exit(len(out)) /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 icount = indentcount_lines(lines[1:]) /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 ...snip... /builddir/build/BUILD/mne-python-maint-0.23/mne/utils/docs.py:2329: DeprecationWarning: `indentcount_lines` is deprecated! scipy.misc.indentcount_lines is deprecated in SciPy 1.3.0 icount = indentcount_lines(lines[1:]) Found un-nested import(s) for ["scipy submodules: ['misc', 'sparse']"]
Already reported upstream. Thanks for helping us out Miro :') While we're at it, I was also trying to find a way to run the graphical tests. Although I tried out running a xvfb buffer but it somehow doesn't work in mock. It usually results in a segfault in mock but works fine on my system. Is there any way to diagnose the issue and find a solution for the same? I had a similar issue earlier with some other tool with some graphical tests but I couldn't find a solution then and had to leave the tool unpackaged.
> Is there any way to diagnose the issue and find a solution for the same? No idea. I can certainly have a look if you give me a spec file to try, but no promises.
https://src.fedoraproject.org/rpms/python-mne/pull-request/3 https://src.fedoraproject.org/rpms/python-mne/pull-request/4 Nominating as beta freeze exception, as the package does not even install otherwise.
FEDORA-2021-357e8396cc has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-357e8396cc
FEDORA-2021-844d3220ea has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-357e8396cc has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-357e8396cc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-357e8396cc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks for the PR Miro! I'll still have to talk to upstream about their compatibility with armv7 support, because my scratch builds were failing on that arch for some reason. This is great, thanks for your help! :D
+3 in https://pagure.io/fedora-qa/blocker-review/issue/418 , marking accepted.
FEDORA-2021-357e8396cc has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.