sci-libs/itk: bump to 5.2.1, unbundle some deps & misc improvements

[fx-carton]

• 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 and dcmtk::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.

[AndrewAmmerlaan]

• 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:

[AndrewAmmerlaan]

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}"

[fx-carton]

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).

[fx-carton]

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.

[AndrewAmmerlaan]

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.

[fx-carton]

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.

[fx-carton]

Actually I've figured the python3_11 issue. All should be addressed now.

[AndrewAmmerlaan]

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.