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

Tue Mar 28 09:28:03 UTC 2017

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Tue, Mar 28, 2017 at 01:42:04AM +0200, Gregor Riepl wrote:
> 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.

That's possible.  While it may be acceptable to leave them unfixed in that
case, I still prefer to fix them as long as it doesn't make the program worse.

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

Yes.  But you can't make it up; upstream needs to write it.  And I wouldn't
want them to waste their time on reverse engineering their changelog.  So I
think this is something that may deserve a lintian override.

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

Did you change any of the filenames?  If not, did you check with piuparts that
everything is cleaned up after install and remove?

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

Yes, it's fine to ignore it for now I suppose.  I would be interested to know
what's happening though.

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

That's fine, as a packager you are an expert user and that should be good
enough for writing this.  I'll check them when you upload the new packages.

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

Sounds good.

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

Every program in Debian that the user can run directly must have one.  Programs
that can be launched from a menu system can still also be lauched from the
commandline.  I use that all the time: I know the names of the programs I want
to run, but don't know where to find them in the menu structure.  So I open a
terminal and type the name.

If a program has its documentation in some other form (a website, or as part of
the program), the manpage can just point to that.  Having a manpage is useful
anyway, because it makes the program show up when searching the man page
directory (man -k keyword).  In this case, it should probably contain the long
description of the package, a statement that it doesn't accept any commandline
arguments, and a pointer to the web site.

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

Hmm, it looks like this font is indeed not packaged:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701478

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

Creating a new package for it would be the way to go.  The alternative would be
to use a different font, but that would mean patching Cura, and I agree with
you that that wouldn't be nice.

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

Great, thanks for your work!
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJY2iyiAAoJEJzRfVgHwHE6UwkP/jPpE5moGGjbqbGW69fk/pi2
U5Xxh0MMLCGhPCL/AFlCXn+33dIC6LATrBCxaEE+PDTvuWW9rt+hxoFnBsQ8IOoh
n99WnmWaSy6tH3E/JkegjPyF5rOLEFmNq6OqfkFaWVZouGhjKzBmESIRIMQWxxct
6yhCOO1WWA8bz0iGKkMSYiT/mrVVGQshzqxn5LUk9YUggBQbY+OCWXtVx4AnqbZc
bJ5PD2yGGiJZHxhbtCI+/M7FXJ7ycbcmIBdvdYnoDBEw151JDfOvvrtQkMMiSCLJ
UyBVzOKkGvyTnBWCfVCXrx/3FNw3QEonJTC5G5dGLgB45LMYgVXRYq2C4Xcp9eJM
KhxqJ9+R1LJjWUwetxsuCCzkcPcrRP0j+68GkRsX/m9GKSDUlQWwJkfdmfi6OHUC
kVtIJPBuxqCrIeRZsOc3vhkop9+Rszd63GWx7P5DYtGLFHq263aSlJKZyWMe8lks
PP2x0s0AnT+oS6V508NmLNaHqSQwE8Hhonzcj8R7MxiqfGlYkvx2dfffp3YYKGT7
E73f9IXWVhiP1fzmPKIRGutvLuzFfrEjeCuukZE85za+FfwtZRN1iPb6eW1UQ7Fi
I1ZBN4Qhg/OViDez7KnfUOlsBjIWbXsMeAXe1QwWI6V7ILBc2nsO1w4RK1YqJZP8
Bw0da3L5Y8yEdhv1aJ8D
=CAfC
-----END PGP SIGNATURE-----