[3dprinter-general] Cura 5.0.0

[Christoph Berg]

Re: To Sebastian Kuzminsky
> > I have updated the packages for Cura and its dependencies from Ultimaker.
> 
> Thanks for working on that!

I've just finished going through all packages and uploading them to
experimental. Thanks for preparing them!

The only real change I added was making cura depend on
"qml6-module-qt-labs-folderlistmodel" because otherwise the file open
dialog wouldn't open. (Wtf, is that a qt6 bug that it doesn't depend
on a package that provides such a basic functionality? Or rather, why
is that a separate package at all?)

> > * libsavitar version is 5.0.0, it installs `libSavitar.so.5.0.0`, but the
> > package name is `libsavitar0.deb`.  Should it be `libsavitar5.deb`?
> > 
> > * Similarly libarcus installs `libArcus.so.5.0.0`, but the package name is
> > `libarcus3.deb`.
> 
> Did that change with 5.0? In any case, we should fix that by renaming
> the packages.

It is a 5.0 change, so the packages were correct before, and I bumped
the sonames before uploading. (Another reason why experimental makes
sense.)

> > * The `cura` and `cura-engine` repos come with tests, but a number of the
> > tests fail.  I've disabled the failing tests via debian/patches, but I don't
> > know how much diligence is expected in debugging these failures.  Upstream
> > does not appear to use a public CI/CD system as far as I can tell, and their
> > github actions are broken and don't run the tests.
> 
> There's a debian/README.Debian in one of them, explaining how to copy
> the required test files from the other package. (Iirc cura-engine
> needs two .json files copied from cura to debian/tests/.)

I now realize that you meant the build-time tests, while I was talking
about the debian/tests/ for autopkgtest. TBH I haven't inspected the
patches, but since it's "only" experimental we can still revisit the
patches when it's time for unstable.

For debian/tests, I updated the json files, but the test fails with
the message

[ERROR] Trying to retrieve setting with no value given: 'adhesion_extruder_nr'

I can fix the test by adding `-s adhesion_extruder_nr=0` to the
CuraEngine command line, but I have no idea if that's the correct fix,
or if there's something wrong, so I have left it alone for now.
(Again, revisit that when going to unstable.)

> > * I expect the git hygiene in some of those repos may not pass muster. I
> > welcome feedback and will try to address any issues.
> 
> I'll see if I can find some time here in Hamburg at the Debian Reunion.

I found your git trees all very nicely shaped with separate commits
for separate changes, with nice commit messages. Thanks for that!

Christoph