Releases retrieved: 7.8.0 Upstream release that is considered latest: 7.8.0 Current version/release in rawhide: 7.6.3-4.fc39 URL: https://www.opencascade.com/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/16221/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/opencascade
Any chance of seeing this in Rawhide soon? I read through bug 2217295, and it seems like tbb was a blocker, but that’s now up to date starting with F40. (I’m trying to package https://pypi.org/project/cascadio/ and use the system opencascade, but I’m encountering "error: ‘class RWGltf_CafWriter’ has no member named ‘SetParallel’", which I think just indicates opencascade is too old.)
Looking now, thanks for the reminder. Looks like it build! :) But: error: Installed (but unpackaged) file(s) found: /builddir/build/BUILD/occt-V7_7_2/lib64/cmake/opencascade/OpenCASCADECompileDefinitionsAndFlags-relwithdebinfo.cmake Installed (but unpackaged) file(s) found: /builddir/build/BUILD/occt-V7_7_2/lib64/cmake/opencascade/OpenCASCADECompileDefinitionsAndFlags-relwithdebinfo.cmake Looks like the cmake config needs some tweaking :(
Whoops, was pulling the tag for 7.7.2, not 7.8.0, now have the above but also: File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKSTEPBase.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKSTEPAttr.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKSTEP209.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKSTEP.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKIGES.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKXDEIGES.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKXDESTEP.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKSTL.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKVRML.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKXDE.so.* File not found: /builddir/build/BUILDROOT/opencascade-7.8.0-1.fc41.x86_64/usr/lib64/libTKXDECascade.so.* Did they drop a bunch of libraries?
From https://dev.opencascade.org/doc/overview/html/occt__upgrade.html#upgrade_occt780: > DE TK components have been combined or separated based on specific CAD formats to support plug-in ability. > > Components now have a "TKDE" prefix. The available list includes TKDESTEP, TKDEOBJ, TKDEIGES, TKDEGLTF, TKDEVRML, TKDEPLY, TKDESTL. > The DE DRAW TK has been updated in a similar way: DRAW components now have a "TKXSDRAW" prefix. The available list includes TKXSDRAWSTEP, TKXSDRAWOBJ, TKXSDRAWIGES, TKXSDRAWGLTF, TKXSDRAWVRML, TKXSDRAWPLY, TKXSDRAWSTL. > > Migration problems may occur during configuration time or compile time. Ensure that you update your project configuration accordingly. So it sounds like that lines up with most of what you’re seeing. Caveat: I know *nothing* about OpenCASCADE.
Ok, got the spec somewhat updated, need to figure out where these go: /usr/lib64/libTKXSDRAWDE.so.7.8 /usr/lib64/libTKXSDRAWDE.so.7.8.0 /usr/lib64/libTKXSDRAWGLTF.so.7.8 /usr/lib64/libTKXSDRAWGLTF.so.7.8.0 /usr/lib64/libTKXSDRAWIGES.so.7.8 /usr/lib64/libTKXSDRAWIGES.so.7.8.0 /usr/lib64/libTKXSDRAWOBJ.so.7.8 /usr/lib64/libTKXSDRAWOBJ.so.7.8.0 /usr/lib64/libTKXSDRAWPLY.so.7.8 /usr/lib64/libTKXSDRAWPLY.so.7.8.0 /usr/lib64/libTKXSDRAWSTEP.so.7.8 /usr/lib64/libTKXSDRAWSTEP.so.7.8.0 /usr/lib64/libTKXSDRAWSTL.so.7.8 /usr/lib64/libTKXSDRAWSTL.so.7.8.0 /usr/lib64/libTKXSDRAWVRML.so.7.8 /usr/lib64/libTKXSDRAWVRML.so.7.8.0 Since they have DRAW in the name I'm tempted to just throw them into the -draw subpackage.
Ok, having done that and figuring out the cmake config issue I'm about to do a scratch build. If that completes no problem, then the following packages will need to be rebuilt: $ fedrq wr -F "name" -s opencascade-devel gmsh kicad netgen-mesher prusa-slicer smesh
Scratch build succeeded. https://koji.fedoraproject.org/koji/taskinfo?taskID=115615505
Updating here for posterity... OpenCascade has been built in side tag f41-build-side-86771, but... 1. netgen-mesher wants python3-mpi4py-mpich, but I can disable it in a conditional... DEBUG util.py:461: No match for argument: python3-mpi4py-mpich 2. There seems to be some funkyness in the CMake target exports in OpenCascade: CMakeLists.txt:76 (include) CMake Error at /usr/lib64/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake:102 (message): The imported target "TKernel" references the file "/usr/lib64${OCCT_INSTALL_BIN_LETTER}/libTKernel.so.7.8.0" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib64/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake" but not all the files it references.
Brute for fix for that problem using sed... Now after fixing two other issues with netgen-mesher, it is failing to build. I'm not sure I have enough energy to fix this whole stack.
Netgen-mesher needs to be updated to a new version to support OpenCascade 7.8.0... Sando, can you look at updating netgen-mesher to 6.4.x with support for OpenCascade 7.8.0?
@hobbes1069 Where can I find 6.4.x? The last available version AFAICS is v6.2.2402 (https://github.com/NGSolve/netgen/tags)
Typo, got the 4 in the wrong place. The latest version is 6.2.2402 which looks to be compatible based on commit history.
Right - this is building now and should be done shortly: https://koji.fedoraproject.org/koji/buildinfo?buildID=2438730
Latest issue... gmake[2]: *** [dox/CMakeFiles/Overview.dir/build.make:1361: doc/overview/html/occt_logo.png] Aborted (core dumped) gmake[2]: Leaving directory '/builddir/build/BUILD/occt-V7_8_0/redhat-linux-build' gmake[1]: *** [CMakeFiles/Makefile2:4344: dox/CMakeFiles/Overview.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs....
(In reply to Richard Shaw from comment #14) > Latest issue... > > gmake[2]: *** [dox/CMakeFiles/Overview.dir/build.make:1361: > doc/overview/html/occt_logo.png] Aborted (core dumped) > gmake[2]: Leaving directory > '/builddir/build/BUILD/occt-V7_8_0/redhat-linux-build' > gmake[1]: *** [CMakeFiles/Makefile2:4344: dox/CMakeFiles/Overview.dir/all] > Error 2 > gmake[1]: *** Waiting for unfinished jobs.... I tried building the current Rawhide spec locally with mock (using --enablerepo=local to be closer to Koji), and I got a cryptic Error 2 from make, without any preceding build errors that I could find. (I didn’t see that core-dump.) I tried asking CMake to use the ninja backend instead of the default "UNIX Makefiles" – ninja being consistently a bit faster for large builds like this, with no real downsides – and did get the abort from the Doxygen make file you reported, so there additionally seems to be an issue with the CMake-generated Makefiles. We might as well just use ninja going forward; I tend to do that preemptively on large CMake projects anyway. For the error > gmake[2]: *** [dox/CMakeFiles/Overview.dir/build.make:1361: > doc/overview/html/occt_logo.png] Aborted (core dumped) this happens while Doxygen is trying to build the HTML “overview” documentation – which is not installed by default, and which we are not installing. The easiest and probably the best fix is therefore just to disable building it with -DBUILD_DOC_Overview:BOOL=OFF. https://src.fedoraproject.org/rpms/opencascade/pull-request/3
Thanks for the quick PR. I assumed that was the case but unfortunately just getting fatigued by this package as of late and I don't have a lot of time for packaging anymore. Doing a test build now with 7.8.1 and if successful will be building it and its deps on COPR.
OpenCASCADE 7.8.1 build succeeded, first dep build error: f3d: CMake Error at plugins/occt/CMakeLists.txt:31 (message): occt plugin: TKXDESTEP and TKXDEIGES OCCT modules are not found. Turn off F3D_PLUGIN_OCCT_COLORING_SUPPORT or enable them in your OpenCascade build. Haven't dug yet, but likely these have been removed from OCCT. Tried building an updated build of f3d 2.4.0 to see if it has been updated but it requires dmon which is not packaged for Fedora: https://github.com/septag/dmon
Doesn't look like smesh has completely migrated to 7.8.x either: In file included from /builddir/build/BUILD/smesh-9.8.0.2/src/SMESH/src/SMESHUtils/SMESH_MeshAlgos.hxx:37, from /builddir/build/BUILD/smesh-9.8.0.2/src/SMESH/src/SMESHUtils/SMESH_Block.cxx:32: /builddir/build/BUILD/smesh-9.8.0.2/src/SMESH/src/SMESHUtils/SMESH_TypeDefs.hxx:264:10: fatal error: NCollection_DefineSequence.hxx: No such file or directory 264 | #include <NCollection_DefineSequence.hxx>
prusa-slicer: PrusaSlicer has no intentions of keeping up with more current OCCT versions: https://github.com/prusa3d/PrusaSlicer/issues/11361 I would therefore recommend that end users move to the Flatpak version.
A comment in that PrusaSlicer issue suggested that going with 7.7.2 seems to have no ill effect. So we might be able to just patch the CMakeLists.txt to go with the 2.8.* version in Fedora like https://src.fedoraproject.org/rpms/prusa-slicer/pull-request/35 showed (similar to what we did for PrusaSlicer 2.5.0 to make it work with Fedora's opencascade 7.6.3), or or remove the version from the find_package altogether. Can't you just go ahead with the rebase and let the depending packages deal with the fallout?
That's pretty much where I'm at now... I should have time to work on it this weekend.
FEDORA-2024-abf72d8f98 (gmsh-4.13.1-2.fc41, kicad-8.0.2-3.fc41, and 3 more) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-abf72d8f98
Everything built but smesh and f3d.
FEDORA-2024-abf72d8f98 (gmsh-4.13.1-2.fc41, kicad-8.0.2-3.fc41, and 3 more) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.