sci
sci copied to clipboard
sci-libs/itk: bump to 5.2.1, unbundle some deps & misc improvements
- Some bundled deps remain; I may try to unbundle them in the future. In particular, as discussed in gentoo/gentoo#25533, it could be possible to extract the forked libjpeg from both
gdcm
anddcmtk::gentoo
to a common package. - VTK 9 has a new build system that breaks lots of things. I did my best to make it work since it's the only version in ::gentoo, but there remains one configuration where it won't work (
sci-libs/gdcm[python,vtk]
, since with both USE flags some VTK python wrapping is needed and that has changed with VTK 9). - There's a merge commit as I worked on this with two branches, but let me know if a rebase is preferred.
- I could not find guidelines on maintainers for this overlay, so I've added myself as maintainer for the new packages; let me know if it's ok.
- There's a merge commit as I worked on this with two branches, but let me know if a rebase is preferred.
Rebasing is preferred over merging.
- I could not find guidelines on maintainers for this overlay, so I've added myself as maintainer for the new packages; let me know if it's ok.
Yes this is okay :+1:
We've got some complaints from pkgcheck:
2022-07-09T05:42:01.3454708Z [1m[34msci-libs/itk[0;10m
2022-07-09T05:42:01.3455802Z [39;49m [33mSizeViolation[0;10m: 'files/itk-5.2.1-system-openjpeg.patch' exceeds 20KiB in size; 22.9 KiB total
2022-07-09T05:42:01.3456711Z [39;49m [32mPythonCompatUpdate[0;10m: version 5.0.1: PYTHON_COMPAT updates available: python3_10, python3_11
2022-07-09T05:42:01.3457814Z [39;49m [32mPythonCompatUpdate[0;10m: version 5.1.0: PYTHON_COMPAT updates available: python3_10, python3_11
2022-07-09T05:42:01.3459073Z [39;49m [31mNonsolvableDepsInStable[0;10m: version 5.2.1: nonsolvable depset(depend) keyword(~x86) stable profile (default/linux/x86/17.0) (20 total): solutions: [ sci-libs/gdcm:0= ]
2022-07-09T05:42:01.3460436Z [39;49m [31mNonsolvableDepsInStable[0;10m: version 5.2.1: nonsolvable depset(rdepend) keyword(~x86) stable profile (default/linux/x86/17.0) (20 total): solutions: [ sci-libs/gdcm:0= ]
2022-07-09T05:42:01.3461389Z [39;49m [32mPythonCompatUpdate[0;10m: version 5.2.1: PYTHON_COMPAT update available: python3_11
Is is possible to make this patch any smaller? Or maybe fetch it from somewhere.
2022-07-09T05:42:01.0977670Z [1m[34msci-libs/gdcm[0;10m
2022-07-09T05:42:01.0978352Z [39;49m [33mMissingTestRestrict[0;10m: version 3.0.14: missing RESTRICT="!test? ( test )" with IUSE=test
2022-07-09T05:42:01.0979098Z [39;49m [33mNonexistentDeps[0;10m: version 3.0.14: DEPEND: nonexistent package: <sci-libs/vtk-9
2022-07-09T05:42:01.0979844Z [39;49m [33mNonexistentDeps[0;10m: version 3.0.14: RDEPEND: nonexistent package: <sci-libs/vtk-9
2022-07-09T05:42:01.0980771Z [39;49m [31mNonsolvableDepsInDev[0;10m: version 3.0.14: nonsolvable depset(depend) keyword(~amd64) dev profile (default/linux/amd64/17.0/x32) (4 total): solutions: [ <sci-libs/vtk-9 ]
2022-07-09T05:42:01.0981799Z [39;49m [31mNonsolvableDepsInDev[0;10m: version 3.0.14: nonsolvable depset(rdepend) keyword(~amd64) dev profile (default/linux/amd64/17.0/x32) (4 total): solutions: [ <sci-libs/vtk-9 ]
2022-07-09T05:42:01.0992524Z [39;49m [31mNonsolvableDepsInStable[0;10m: version 3.0.14: nonsolvable depset(depend) keyword(~amd64) stable profile (default/linux/amd64/17.1) (28 total): solutions: [ <sci-libs/vtk-9 ]
2022-07-09T05:42:01.0993666Z [39;49m [31mNonsolvableDepsInStable[0;10m: version 3.0.14: nonsolvable depset(rdepend) keyword(~amd64) stable profile (default/linux/amd64/17.1) (28 total): solutions: [ <sci-libs/vtk-9 ]
2022-07-09T05:42:01.0994563Z [39;49m [32mPythonCompatUpdate[0;10m: version 3.0.14: PYTHON_COMPAT updates available: python3_10, python3_11
2022-07-09T05:42:01.0995269Z [39;49m [33mPythonMissingDeps[0;10m: version 3.0.14: missing RDEPEND="${PYTHON_DEPS}"
2022-07-09T05:42:01.0996010Z [39;49m [33mPythonMissingRequiredUse[0;10m: version 3.0.14: missing REQUIRED_USE="${PYTHON_REQUIRED_USE}"
I noticed that you marked the conversations as resolved, but the ebuild still is the same. Did you perhaps forget to push your changes?
Yes, I did the changes locally and have not pushed them yet.
Because while testing python3_11 support for itk, I have a build failure, and noticed that this failure also happens to python3_{9,10}. It built fine previously, so I'm investigating the cause of the build failure. I updated my system, but do not know yet what exactly is the cause. I suspect it may be llvm 13->14 as a dependency of castxml. (Btw, it seems dev-cpp/castcml::science is now in gentoo as dev-libs/castxml::gentoo).
As I suspected, it is due to the llvm version castxml is built with. The issue is reported upstream there. Not sure there is something we can do in the ebuild, except for printing a warning if llvm 14 is installed.
Also itk does not seem to work with python 3.11.
As I suspected, it is due to the llvm version castxml is built with. The issue is reported upstream there. Not sure there is something we can do in the ebuild, except for printing a warning if llvm 14 is installed.
Is there a difference between dev-cpp/castxml
from ::sci and dev-libs/castxml
from ::gentoo? The ::gentoo version is more recent so maybe it will work better with llvm 14. Ideally I'd like to remove the version in ::sci to avoid unnecessary and confusing duplication.
We can use llvm.eclass
to depend on llvm<14 (LLVM_MAX_SLOT
), and to perform a corresponding check/warning in the setup phase.
I'm now using castxml::gentoo
and it has the same problem with itk: if castxml is built with llvm 14, it builds fine but then won't be able to compile itk. I'll switch the itk ebuild to use the one from gentoo (dev-libs); probably the one in ::science needs to be moved to dev-libs to ensure a smooth transition for users.
I don't know where the actual issue is, and don't think putting a versionned dependency is right: it's a build time thing and after building castxml one may want to reinstall llvm 14 (I did; in fact I had llvm 14 installed while building itk). Maybe the best we can do is issuing a warning in the itk ebuild telling that castxml needs to be build with llvm<14 for itk, if built with USE=python and llvm 14 is installed.
I've pushed my changes which I think addresses all comments, except for python3_11 for itk, because it doesn't build on my machine, and don't have the time to investigate.
Actually I've figured the python3_11 issue. All should be addressed now.
Awesome, Thanks :+1:
There is still a problem with gdcm[vtk] where it fails to compile because it can't find some libs. Probably we need to depend on some specific flag on vtk but I haven't figured out which one yet.