I've wrestled with building CURA on FreeBSD before, too. It's a bear. Just look at that dependency list! But 5.4 Adds the XMAS tree support. It is truly revolutionary. Complicated and delicate models with supports that are actually quite easy to remove. While only a minor release from 5.3 --- 5.4 represents something I would say is the new baseline of Cura. FreeBSD needs this for it's makers.
I agree with need this port. The last time I went to update it (months ago I admit) I ran into dependencies that were used by other packages but also seemed needed to be updated for Cura. IMHO ideally there should be a 3D printing group to coordinate the patches but I digress. I'll give it a look ASAP.
Created attachment 250218 [details] Attempt to update Cura to 5.7.0 (v1) Hi, I've tried my hand at this upgrade. It's kind of a mess, the 5.x branch introduced conan to install deps at build time -- the kind of things that make packagers cry. I went the same way as the Fedora packagers: retrieving the 4.13 era CMakeLists.txt and related files, update them as needed and use them to build the projects. I got to a point where Cura 5.7 build, install can run with some issues. A python dep is missing for MakerBot printers, CuraEngine will segfault if build in "Release" version (and not in RelWithDebInfo). But I managed to slice projects and connect to my octoprint instance. I don't think it's ready for commit, but if somebody want to have a look to test/polish the patchset... Updates ports: net/libarcus cad/cura-engine devel/libnest2d-ultimaker devel/py-pynest2d cad/uranium net/libcharon devel/libsavitar cad/fdm_materials cad/cura
Created attachment 251287 [details] Attempt to update Cura to 5.7.0 (v2: switch to sip 6) Hi, I've been using this version for a few weeks, not intensively but without issues. I see the packages are threatened by devel/py-sip4 a the end of the month. It's a bit hacky, but getting some files from graphics/qgis (for sip5) and trying to adapt them a bit, I managed to port things to use devel/py-sip. Poudriere did not complain during a full rebuild and it seems to run well enough for me (tm), more testing would probably be welcome, but time is now running...
(In reply to Matthieu Volat from comment #3) I just tried to build Cura 5.7 using your patch, but libcharon 5.0.0 has some stupid hard-dependency on Python 3.10 and hence fails to build: CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find Python: Found unsuitable version "3.11.9", but required is exact version "3.10" (found /usr/local/bin/python3.11, found components: Interpreter) Also libnest2d fails to extract: => SHA256 Checksum OK for Ultimaker-libnest2d-5.3.0_GH0.tar.gz. cp: /usr/ports/devel/libnest2d-ultimaker/files/Findclipper.cmake: No such file or directory *** Error code 1
(In reply to Sebastian from comment #4) Thanks for testing, sorry for answering a bit late, but end of the week was busy and some weird zfs corruption made me loose my zroot partition (along /usr/ports). Good news is that I can apply the patch from scratch like everybody else :) First issue (net/libcharon): argh, I must admit when facing the coding rush, I did it with my (at the time) python 3.10 configured system. It's not as much a hardcoded version as much as a default, the desired version can be provided command-line but devs went weird again and used Python_VERSION where cmake usually have PYTHON_VERSION : I'll redo the patchset, but you can juste replace line 20 of net/libcharon/Makefile with the correct case. Second issue (devel/libnest2d-ultimaker): I'm sorry, I cannot reproduce this even starting from scratch, the file is present in the diff (starting line 13657) and in my tree after applied. Or is it some issue with FILESDIR?
Created attachment 251618 [details] 251287: Attempt to update Cura to 5.7.0 (v3: fix libcharon python version, some wrong variable substitutions in cura pkg-plist) Here's the complete patchset successfully build with Python 3.11. There were some issues in Cura's pkg-plist due to filenames with 310 in their name being substituted to %%PYTHON_VERSION%% which then wasn't 310.
(In reply to Matthieu Volat from comment #5) > Good news is that I can apply the patch from scratch like everybody else :) I also was able to apply it without errors. > First issue (net/libcharon): argh, I must admit when facing the coding rush, I did > it with my (at the time) python 3.10 configured system. It's not as much a > hardcoded version as much as a default, the desired version can be provided > command-line but devs went weird again and used Python_VERSION where cmake usually > have PYTHON_VERSION : I'll redo the patchset, but you can juste replace line 20 of > net/libcharon/Makefile with the correct case. This explains why putting "PYTHON_VERSION" in an .if ${.CURDIR:M*/net/libcharon} statement didn't work. Sorry if I was a bit off-putting here, I had to deal with one too much hard-coded dependencies to ancient or non-mainstream versions of obscure software last week. Really apprechiate your work here! Libcharon now builds without any errors with the new patch. > Second issue (devel/libnest2d-ultimaker): I'm sorry, I cannot reproduce this even > starting from scratch, the file is present in the diff (starting line 13657) and in > my tree after applied. Or is it some issue with FILESDIR? That port now also builds without any problems - not sure what caused the error, but can't reproduce it any more. It was consistent for 3 build attempts before... (In reply to Matthieu Volat from comment #6) > Here's the complete patchset successfully build with Python 3.11. Builds fine, installs fine. I will slice some models later today and report back if I encounter any issues. Thanks for all your work!
% cura Traceback (most recent call last): File "/usr/local/bin/cura", line 32, in <module> from cura.CrashHandler import CrashHandler File "/usr/local/lib/python3.11/site-packages/cura/CrashHandler.py", line 27, in <module> from UM.Application import Application File "/usr/local/lib/python3.11/site-packages/UM/Application.py", line 10, in <module> from UM.Controller import Controller File "/usr/local/lib/python3.11/site-packages/UM/Controller.py", line 4, in <module> from UM.Scene.Scene import Scene File "/usr/local/lib/python3.11/site-packages/UM/Scene/Scene.py", line 12, in <module> from UM.Mesh.ReadMeshJob import ReadMeshJob # To reload a mesh when its file was changed. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/UM/Mesh/ReadMeshJob.py", line 8, in <module> from UM.FileHandler.ReadFileJob import ReadFileJob File "/usr/local/lib/python3.11/site-packages/UM/FileHandler/ReadFileJob.py", line 5, in <module> from UM.FileHandler.FileHandler import FileHandler File "/usr/local/lib/python3.11/site-packages/UM/FileHandler/FileHandler.py", line 12, in <module> from UM.PluginRegistry import PluginRegistry File "/usr/local/lib/python3.11/site-packages/UM/PluginRegistry.py", line 26, in <module> from UM.Trust import Trust, TrustBasics, TrustException File "/usr/local/lib/python3.11/site-packages/UM/Trust.py", line 14, in <module> from cryptography.hazmat.primitives import hashes, serialization File "/usr/local/lib/python3.11/site-packages/cryptography/hazmat/primitives/hashes.py", line 9, in <module> from cryptography.hazmat.bindings._rust import openssl as rust_openssl RuntimeError: OpenSSL 3.0's legacy provider failed to load. This is a fatal error by default, but cryptography supports running without legacy algorithms by setting the environment variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY. If you did not expect this error, you have likely made a mistake with your OpenSSL configuration. Oh dear... does python crypto still require insecure LEGACY algorithms? % pkg info openssl | grep LEGACY LEGACY : off If setting the CRYPTOGRAPHY_OPENSSL_NO_LEGACY environment variable to YES, cura starts but it not only ignores my present configuration/profiles/printers (most likely because it now puts config in ~/cura instead of ~/.config/cura), it completely nukes it if I copy the existing 4.13 folder to the new path and rename the folder to 5.7. Seems there is no way to import those settings either (the import function ignores the folders from earlier versions - I can never import anything..), so if that's the status quo, Cura has become pretty much useless for me and I have to figure out how to keep the 4.13 Version running (e.g. in a jail with old package versions...)
Created attachment 251791 [details] Attempt to update Cura to 5.7.0 (v4: fix Cura user settings path) I had not seen that the settings were recreated in $HOME/cura, and my bad, there was actually a patch in cad/uranium for this, but as it did not apply anymore and I thought I'd get back to it if/when something would go wrong. This is fixed, if you have previous config directories migration is working but do not try to move a 5.7 config dir in ~/.config/cura. As for the other error, I think that's something with your personal repository, cura do not install port's openssl for me (on 14.x)?
Created attachment 251793 [details] Attempt to update Cura to 5.7.0 (v5: fix Cura user settings path + restore cura deps) Oops, I had removed from cad/cura dependencies net/py-zeroconf to test (it fails to build ATM), but it should stay. Btw today is the day of devel/sip4 removal...
(In reply to Matthieu Volat from comment #10) With this patch, using ports on a -CURRENT machine, I get stuck at py-pandas not compiling (curiously, the build ends with it not recognising the Cython that is installed as sufficient for it's "rule"). I have a current poudriere running now too, but this hasn't built yet, for me.
... verified. If I somehow have py311-sip4 built already, I can push cura-engine to compile, but I cannot build in poudriere (even if I remove the BROKEN). Help?
(In reply to dgilbert from comment #12) I'll look today. Please keep in mind each of the myriad of ports involved in this upgrade is supposed to have it's own PR. *sigh* Let me look at this today first.
I get that. I really want it to work. sip1.4 seems old, tho --- it might be much better if it could use a newer sip.
It would be helpful if someone could regenerate a new diff using: https://docs.freebsd.org/en/books/porters-handbook/book/ "To make it easier for committers to apply the patch on their working copy of the ports tree, please generate the .diff from the base of your ports tree. Again, eventually this massive diff is going to have to be split out into individual PRs. We can start getting some pieces of the port needed into the tree that way. Thank you in advance!
Created attachment 252737 [details] Update Cura to 5.7.0 (v6: generated with format-patch) Here you go, it's a bit too hot where I am to do a final sanity test run, but there was no merge issue updating the port tree.
I'm spooling up that test right now.
both py-nest2d and py-sip4 are gone from git due to them not working with modern python so I had a battle with the diff file. I will attach the diff I managed to get against present tree but N.B. py-nest2d will need work first. libnest2d is switching build systems. I'll have a look. https://github.com/Ultimaker/libnest2d Note: We are currently in the process of switch our builds and pipelines to an approach which uses Conan and pip to manage our dependencies, which are stored on our JFrog Artifactory server and in the pypi.org.
Created attachment 252825 [details] Up to date git diff with present tree I had to regenerate this diff. git diff against the present ports tree. I don't think I missed anything.
(In reply to Diane Bruce from comment #19) Does that mean I should cancel my poudriere that is running, redo for the new patch and restart?
(In reply to dgilbert from comment #20) No let it go. Hopefully it is done now.
My poudriere is winding down, but I can confirm that cura 5.7 is compiling on 14.1 ... which is good.
OK. Problem. The Cura this makes won't load a .STL file. Reproduce? Run Cura, attempt to load any .stl file. The file dialog no longer lists .stl as supported... but sort to all files and selecting an STL file doesn't load. 3mf files load... a few other things... but not STL.
(In reply to dgilbert from comment #23) I haven't had such issue, did you try to run cura from commandline? There's a lot of debug info when doing so.
Created attachment 252987 [details] Patch to net/libarcus following protobuf update I think the latest protobuf update breaks libarcus due to a inherited class needing more stuff to implement its abstract parent. I haven't seen any upstream change to fix, so I just put some stubs to make the compiler happy and it builds and I can load STL models and slice them.
I have run into this error with building libarcus. I am not 100% sure I have all the diffs applied either. If someone can tar up just the libarcus port and put it somewhere so I can compare that would be great. CMake Error at CMakeLists.txt:4 (find_package): By not providing "Findstandardprojectsettings.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "standardprojectsettings", but CMake did not find one. Could not find a package configuration file provided by "standardprojectsettings" with any of the following names: standardprojectsettingsConfig.cmake standardprojectsettings-config.cmake Add the installation prefix of "standardprojectsettings" to CMAKE_PREFIX_PATH or set "standardprojectsettings_DIR" to a directory containing one of the above files. If "standardprojectsettings" provides a separate development package or SDK, be sure it has been installed.: It's outlined here https://github.com/Ultimaker/libSavitar/issues/52 Sooner or later we will have to do the conan build in the python venv stuff as outlined here: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source but if you lot have it compiling without I'd like to see what you are doing different.
Created attachment 253100 [details] libarcus If you get this error, it means the post-extract phase is not properly executed and you are running the upstream, conan-based Makefile. I did not test the makefile with non /usr/ports port directory, maybe I missed something here? Here's my directory. Regarding conan, I tried at first to use it, and it it's a major pain. I suspect making a port from it would end in creating a single Cura fat package that would require a lot of scripting to pre-fetch the deps, a bit like what nodejs ports do.
I've tried applying these patches in various combinations to retry the arcus stuff, among other things. Can we have a rolled up patch?
BTW ... 5.8 is out now, too.
(In reply to dgilbert from comment #28) I'll have one in the morning. Testing against head now.
(In reply to dgilbert from comment #29) Once we have a working 5.7 in the tree, 5.8 will be easier.
(In reply to Matthieu Volat from comment #27) I have a working tree tonight. Finally. If you wouldn't mind making a separate PR for the various pieces that will make it easier to get this all into the tree. Thanks for all the work I know BTDT. P.S. I agree with you on conan
ok I think this is the correct tarball for all of cura. Please let me know if this looks good. fetch www.FreeBSD.org/~db/cura_5.tar.bz2 be sure to clean out the old versions as I note that a lot of files are now deleted. Here's a git diff against head as well. fetch www.FreeBSD.org/~db/cura_5_git.diff I cannot get rust to compile on FreeBSD-HEAD hence I am only testing against 14.1
[2:58:358]root@vr:~> fetch http://www.freebsd.org/~db/cura_5_git.diff cura_5_git.diff 0 B 0 Bps 00s ... 0 byte file. Also... What of all the other changes? Are they checked in?
(In reply to dgilbert from comment #34) Try now.
(In reply to Matthieu Volat from comment #16) I finally have a working cura on 14.1 on my laptop. Thank you Matthieu Volat for that. I've updated the cura git diffs and tar ball on www.FreeBSD.org/~db I'd like to see this all the tree pronto as well as I need to do some 3D printing. ;) This monster port needs to be split up into smaller PRs. I could do that all but help would be nice. ;)
Tell me what to do and I'll do the busy work? Split by port for the patch?
libarcus failed to patch with the given tar file. https://pkg.daveg.ca/data/freebsd_14_1_x64-HEAD-ALL/2024-08-28_16h39m29s/logs/errors/libArcus-5.3.0,1.log ... do I need to restart with the diff?
I restarted with a fresh copy of ports and the diff a couple of responses above. libarcus still didn't build. https://pkg.daveg.ca/data/freebsd_14_1_x64-HEAD-Cura/2024-09-01_16h04m17s/logs/errors/libArcus-5.3.0,1.log
Just had a success with libarcus --- applying both Diane's patches and then Mathieu's patch to just libarcus --- well... his patch file to insert into the arcus' files.
I just pushed libarcus to repo.
Spoke too soon. Finally got to run the properly compiled binary. It still refuses to load .STL files. So... if you attempt to open a file, the file open dialog doesn't even offer .STL files. If you select "all" files and select an STL file, it will refuse to load it with the uploaded error dialogue
Created attachment 253334 [details] invalid file (specifically: STL) dialogue I get this when I attempt to open an STL.
It strikes me, playing with it, that also many of the extensions are broken.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1054fc2ae4a857c574d61b83e67aab3e723318b6 commit 1054fc2ae4a857c574d61b83e67aab3e723318b6 Author: Matthieu Volat <mazhe@alkumuna.eu> AuthorDate: 2024-09-04 21:01:44 +0000 Commit: Diane Bruce <db@FreeBSD.org> CommitDate: 2024-09-04 21:01:44 +0000 cad/cura: upgrade to 5.7.0 - rework build system PR: ports/272857 cad/cura/Makefile | 51 +- cad/cura/distinfo | 6 +- cad/cura/files/CMakeLists.txt (new) | 104 + cad/cura/files/CuraPluginInstall.cmake (new) | 105 + cad/cura/files/CuraTests.cmake (new) | 84 + cad/cura/files/CuraVersion.py.in (new) | 13 + .../files/com.ultimaker.cura.appdata.xml (new) | 33 + cad/cura/files/com.ultimaker.cura.desktop.in (new) | 19 + cad/cura/files/mod_bundled_packages_json.py (new) | 73 + cad/cura/files/patch-CMakeLists.txt (gone) | 11 - .../patch-cura_OAuth2_KeyringAttribute.py (gone) | 11 - cad/cura/files/patch-cura__app.py (gone) | 8 - ...rinting_USBPrinterOutputDeviceManager.py (gone) | 14 - cad/cura/pkg-plist | 6571 +++++++++++++++----- 14 files changed, 5516 insertions(+), 1587 deletions(-)
I'm going to close this PR. If there are fixes to be made, a new PR will keep it clear.