[3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers
wijnen at debian.org
Tue Dec 27 22:22:01 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
Sorry for the delay. I'm looking at the packages now. On the mentors page,
there are a lot of lintian messages that should be addressed. Aside from
those, I think the packages look good. I didn't test them yet, though.
If you want to maintain them within the team, please also change the
Maintainer: to this list and add yourself to Uploaders:.
All of them have "debian-changelog-line-too-long"; break the lines in
debian/changelog so they don't get too long.
Then there's "no-upstream-changelog", which is tricky: it seems there really
isn't a changelog file provided by upstream for libarcus and uranium. It's
probably a good idea to ask them about this.
python3-arcus says "python" in the description; that should be "Python".
Hardening seems to be disabled; the easiest way to fix that is setting the
debhelper compat level to 10, it automatically applies all hardening then.
"package-name-doesnt-match-sonames" on libarcus means that package should be
called "libarcus2" (the capital can be ignored, but the 2 is important to make
sure versioning works well). Don't change the name of the -dev package, just
the library's package itself.
I'm not sure about "no-symbols-control-file"; it doesn't appear on my local
system when I build it, and the build output suggests that the symbols file is
generated, but I don't see it. Does anyone else on this list know about it?
Otherwise, ask on the mentors list, or #debian-mentors on irc.
debian-watch-file-is-missing is self-explanatory; adding a watch file is a good
idea, and there are many packages from github to use as an example for how to
quilt-patch-missing-description is about adding some documentation to the
patch; dpkg-source --commit adds templates for that automatically. It's a good
idea to add the information.
Since 3.0 (quilt) is a well known source format, there is no need to add a link
to the quilt documentation for how to use it IMO, but if you like it you can
extended-description-is-probably-too-short is correct: you should add a few
lines to explain what the package does. Also, duplicate-long-description can
be easily fixed by adding a distinct line to each binary package saying what
its role in the system is ("This package contains the files needed for
compiling programs that use the library", etc).
CuraEngine has binary-without-manpage. The logical fix for that would be to
write a manual page. However, I think it is reasonable to consider CuraEngine
an implementation detail of cura. Such internal helper programs do not need a
manual page. They should also not be installed in the execution path. That
is, either write a manual page, or install the executable in
/usr/lib/cura-engine/ (or in a subdirectory of that).
cura also has binary-without-manpage, and there's no other way to fix it than
by writing a manual page (because cura obviously is a program that the user
should run directly). It doesn't have to be very long, but please avoid "there
was no man page, so now there is"; that's less useful than no man page at all,
because it silences lintian without fixing the problem (missing documentation)
and thus hides the problem (which is against our social contract).
font-in-non-font-package is also something that needs to be fixed. There
should be no fonts in any of your packages. It would be best if cura would
just look for fonts in /usr/share/fonts/; if that's too hard, add symlinks from
where it expects them to the fonts in there. You also need a dependency on the
package containing the fonts, of course.
It looks like the problematic files that were in there when I was packaging it
are gone, so there is no need to repackage the source. That means the source
package will still contain the fonts, so the copyright file should still
contain the apache license for them (in other words, don't remove it from the
license-problem-json-evil would be a serious problem, but it's a false positive
and you override it, which is appropriate.
If you have any problems fixing those things, let me know.
On Tue, Nov 29, 2016 at 07:00:47PM +0100, Gregor Riepl wrote:
> I wanted to give a little update:
> The Cura packaging scripts are mostly ready now, at least for Cura 2.1.3.
> 2.3 will follow once 2.1.3 is in the pipeline, as I still need to review the
> changes and dependencies.
> I collected all applicable licenses (to the best of my knowledge) and added
> a readme file giving credit to @thopiekar, whose own packaging efforts
> helped with building the dependency lists. He did not contribute directly,
> so I did not include him in debian/copyright.
> Now, I'm unsure where to go from here. I'll do a little more build testing,
> but what else is needed to make the packages release-ready and get them into
> Debian? What should I put into the changelogs for the first release?
> Here's the list of my clones, again:
> The packaging scripts (along with a copy of the 2.1.3 sources) live in the
> "debian" branch of each repository.
> 3dprinter-general mailing list
> 3dprinter-general at lists.alioth.debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the 3dprinter-general