[3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

Hi Bas,

Here's some feedback to your previous comments.

In general, I think some of the Lintian warnings seem overly picky.
Many of them are warnings are of the 'I' class, and while it's good that they
are logged, not all of them make sense.
As for the 'W' and 'E' ones, most of them are addressed now.

> All of them have "debian-changelog-line-too-long"; break the lines in
> debian/changelog so they don't get too long.

This should be fixed now.

> 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.

What's supposed to be in there?
Can it be free-form?

Cura has a ChangeLog.txt in their ChangeLogPlugin, perhaps this can be used.

I haven't found anything of the sort for Arcus, Uranium and CuraEngine.
CuraEngine has something, but it's sorely out of date.

I can open bug reports on their repos, but really don't thing Ultimaker will
maintain separate changelogs for all their components.

> python3-arcus says "python" in the description; that should be "Python".

My bad.
Fixed.

> 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.

Done, for all packages.

> "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.

Since there is no conclusive response from upstream, I fixed this by naming
the package libarcus3. The other packages have been kept as-is.

> 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.

This is classified as 'I', and seems overly picky to me.
But I don't fully understand the implications either, so it may need to be
discussed with an expert.

> 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
> write it.

Added. Also, fixed the Vcs-* variables in debian/control so they point to my
repositories.

> 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.

I added a short description to each patch.

> 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).

Added some marketing blurb from the Cura homepage.
As I'm not a Cura author, I can only make something up, but I can't really
speak on their behalf. May need a review.

> 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).

I generated a man page with help2man and edited it a bit.
Maybe a fully autogenerated manpage is possible with proper parameters.
Will look into this later.

CuraEngine can be run manually, and it provides helpful output with the 'help'
parameter, so a manpage makes sense here.

> 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).

This absolutely doesn't make sense to me. Cura doesn't accept any command line
arguments as far as I can tell and is meant to be launched from a graphical
desktop anyway.

Why does it need a manpage?

> 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.

This one is a bit hard.
The only Debian package containing Open Sans that I could find is
texlive-fonts-extra, and that one is huge and doesn't even include them in
TrueType format.

Would you rather suggest I create a fonts-opensans package from upstream
(Google in this case) first?
Or would one specific to Cura be ok?

> 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
> copyright file).

Ok...

> If you have any problems fixing those things, let me know.

Once the remaining warnings (fonts and Cura manpage) are fixed, I will
resubmit to debian-mentors, then prepare updated packages for 2.4.0.

Best regards,
Gregor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/3dprinter-general/attachments/20170328/bcf1398c/attachment.sig>