Adds support for the cura engine for lulzbot printers Reproducible: Always
Created attachment 482958 [details] media-gfx/curaengine-lulzbot-14.03.ebuild
Created attachment 482960 [details] media-gfx/curaengine-lulzbot-9999.ebuild
Created attachment 482962 [details, diff] Fixes log compile errors in earlier engine
Created attachment 484904 [details] media-gfx/curaengine-14.03.ebuild Oops - put the license into SRC_URI rather than LICENSE
Created attachment 484938 [details] media-gfx/curaengine-lulzbot-14.03.ebuild Blocks media-gfx/curaengine
Created attachment 484940 [details] media-gfx/curaengine-lulzbot-9999.ebuild Blocks media-gfx/curaengine
Hi Richard, Can you have a quick review of this package, and we'll have a look-see into the possibility of the "3D-print project" adopting it? I'm hoping to have a mass review of the Cura[Engine] ebuilds, as the Gentoo tree is a long way behind current releases, and I am in contact with upstream to tidy up packaging for us. Thanks!
(In reply to Michael Everitt (IRC: veremitz) from comment #7) > Hi Richard, > > Can you have a quick review of this package, and we'll have a look-see into > the possibility of the "3D-print project" adopting it? Thanks for the heads-up. I checked the repo a few weeks ago and only noted a minor revision... a closer look shows that they've moved their git repo to a different location. I'll work out a new ebuild using their latest release...
Ok, so after some investigation, I've got good news and bad news. The good news - lulzbot upstream has written their own ebuilds! They can be reached at https://code.alephobjects.com/source/curabuild-lulzbot/browse/stable_2.6/gentoo/ The bad news - they forked their own versions of libarcus, libsavitar, uranium curaengine, and of course cura. These are all forked from Ultimaker. Unfortunately, unless someone can convince the two parties to merge, test, and release unified code for these libraries, we need separate ebuilds for each to accommodate both vendors. At this point I have no idea what that might mean for any users that somehow have both printers running on the same machine. Perhaps the most sensible thing we can do at this moment is to create an overlay for these ebuilds. Aside from maybe breaking their -9999 ebuilds into various tagged releases, I think we would be best off letting them maintain their ebuilds and contribute directly upstream if we have any constructive changes.
As OP, perhaps you can help with the appropriate use case! You would certainly be welcome to create an overlay, which Gentoo can host, and it would easily be possible to 'curate' tagged versions, which could then be subject to QA procedure and validation, etc. It certainly doesn't make sense to duplicate effort, so it would very much be a case of "what can we add here". Perhaps you would like to contact 'upstream' and let them know of this bug, and see what they think?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=47d75d8d256f4ceebd70bf95261c09cb54fcddd4 commit 47d75d8d256f4ceebd70bf95261c09cb54fcddd4 Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2023-08-12 12:23:44 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2023-08-12 12:42:16 +0000 media-gfx/curaengine: treeclean Closes: https://bugs.gentoo.org/895216 Closes: https://bugs.gentoo.org/840758 Closes: https://bugs.gentoo.org/869302 Closes: https://bugs.gentoo.org/624516 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> media-gfx/curaengine/Manifest | 1 - media-gfx/curaengine/curaengine-4.13.1.ebuild | 85 --------------------------- media-gfx/curaengine/metadata.xml | 35 ----------- profiles/package.mask | 1 - 4 files changed, 122 deletions(-)
