Description: Compiling Python code using LLVM SRPM: https://fedorapeople.org/~limb/review/python-numba/python-numba-0.59.1-1.fc41.src.rpm SPEC: https://fedorapeople.org/~limb/review/python-numba/python-numba.spec Reproducible: Always
Reviewing 2271634, but feel free to take the review as will not get to it before the weekend. *** This bug has been marked as a duplicate of bug 2271634 ***
So I've updated my package to 0.60.0 and I've started patching for Python versions, but many of the threading calls are different in ways I'm not confident in altering. It looks like 0.61.0 will be out soon, I'll see if that's better.
The Arch and Suse packages seem ok: https://gitlab.archlinux.org/archlinux/packaging/packages/python-numba/-/blob/main/PKGBUILD https://build.opensuse.org/projects/openSUSE:Factory/packages/python-numba/files/python-numba.spec?expand=1 CUDA license is likely not acceptable: https://docs.nvidia.com/cuda/archive/11.2.2/eula/index.html https://github.com/numba/numba/blob/main/LICENSES.third-party#L496 Should the entire cuda subdirectory be removed? It may be helpful to provide 3 builds: a) without OpenMP and without TBB b) with OpenMP and without TBB c) without OpenMP and with TBB https://numba.readthedocs.io/en/stable/user/installing.html Initial build: https://copr.fedorainfracloud.org/coprs/fed500/python-numba/build/8452585/
Oh, gosh, how I love CPU-specific options. We should probably drop cuda. Regarding OpenMP and TBB, I think it would be better to use per-arch conditionals to build with them where available. Does that work for you?
OpenMP should work everywhere. Am less sure about OneTBB, official support is for x86_64 though the Fedora spec file does not have any architecture limitations and the tests are run. Main problem with threading is more likely that a user code which uses threading and then calls numba may create threading problems. In these cases, it is good to have a serial option without OpenMP or TBB. Probably modules similar to what is done for MPI would be the cleanest option. However, would start doing a build with neither OpenMP or TBB, then add these afterwards. This would at least get things working and allow other software to use numba, even if performance would not be the best possible.
That makes sense. I've prepped my spec with that, and will await 0.61.0.
Related issue upstream https://github.com/numba/numba/issues/9881
> We should probably drop cuda. Regarding OpenMP and TBB, I think it would be > better to use per-arch conditionals to build with them where available. I've not seen issues for some time (likely years) on TBB on different arches so I think it should be fine. OpenMP is widely supported across all arches. I would start with a single build with them both and if there's issues show up address them then as they're likely bugs anyway. Where are we generally with this review? 0.61.2 is out with support for numpy 2.2.
SPEC: https://fedorapeople.org/~limb/review/python-numba/python-numba.spec SRPM: https://fedorapeople.org/~limb/review/python-numba/python-numba-0.61.2-1.fc43.src.rpm Build fails if I remove cuda. Import tests fail if I leave it in place.
Copr build: https://copr.fedorainfracloud.org/coprs/build/9100092 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2273016-python-numba/fedora-rawhide-x86_64/09100092-python-numba/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.