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

[Bas Wijnen <wijnen@debian.org>]

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

Hi,

It looks like this has been forgotten?  I would like to get Cura into Debian,
so if there's anything I can do to help, let me know.

I also have some comments on the comments:

On Mon, Dec 19, 2016 at 10:51:52PM +0100, Gregor Riepl wrote:
> > * There seems to be a line in the changelog that is too long, it'd be
> >   nice to split it into two so it fits into the "80 character limit".
> 
> Ok, I thought this wasn't so important, so I ignored the lint warning.

To properly handle a lintian warning one of three things can be done:
- - Fix the code so it doesn't trigger the warning anymore.  This should be done
  if lintian is correct.
- - File a bug report against lintian.  This should be done if lintian is wrong,
  and this is not an exceptional case.
- - Add an override to the package.  This should be done if lintian is wrong, but
  it is unreasonable to expect lintian to be right in this case.

Leaving bugs in a package because it takes too much work to fix them is
acceptable (nobody can force you to do the work), but for a new package it
makes sense to aim for perfection, so making it initially lintian-clean is
recommended.

A pet peeve of me (which is not applicable here, but I'll take this opportunity
to complain about it anyway) is people who add lintian overrides because they
don't want to fix a bug and are bothered by the warning.  That is
counter-productive, and IMO violates our promise not to hide our problems.  If
you don't want to fix a bug, just say it.  Don't pretend that it is not a bug.
But enough of this; you didn't even do this. :)

> Who still uses a 80-character terminal in this day and age anyway? :)

Not many I suppose, but if we all follow this rule, it may make it easier for
programs to display the information is a good way.  In a case like this, even
if I wouldn't be able to come up with a reason for the rule, I'd fix it anyway
because it's so easy to do.

> > * Normally, the binary packages providing shared libraries are named
> >   as "libfooX" where foo would be the name of library and X the
> >   "major-version" [3]. In your case this would mean that the binary
> >   package that provides libArcus.so.3 should be named "libarcus3"
> >   instead of just "libarcus". However I don't quite get what's going
> >   on with this library's versioning. This packages provides
> >   "libArcus.so.1.1.0" and a link to it called "libArcus.so.3", is
> >   there a reason for this? To my understanding the latter should be
> >   called "libArcus.so.1" and therefore the binary package would end up
> >   being "libarcus1". Nevertheless, I'm no expert and it seems I'm
> >   missing something here.
> 
> Yes, I noticed the warnings as well.
> 
> However, upstream seems to prefer naming and versioning as they are now, so
> I didn't want to change them.
> As far as I can tell, this isn't going to be a problem, as there aren't any
> other packages besides Cura that use libArcus anyway.

This is quite confusing, and I would prefer to make it right in Debian.  And of
course try to convince upstream to make it right as well.  I'm not sure if it
generates junk; it might.  You should run piuparts to see if ldconfig creates a
symlink that is not cleaned up on package removal.

> >debian/rules
> >------------
> >
> > * Lintian reports the tags "hardening-no-fortify-functions" and
> >   "hardening-no-bindnow". There's an ongoing effort to "update as many
> >   packages as possible to use security hardening build flags". You
> >   might want to try to deal with it, sometimes it is as "simple" as
> >   adding "export DEB_BUILD_MAINT_OPTIONS = hardening=+all".
> 
> Ok, I'll try that.

Even simpler is to set the debhelper compat level to at least 10.  It will
default to enable all hardening.  (I didn't check the current level, but if it
is 10 and there's no hardening, it must have been explicitly disabled somehow.)

> >CuraEngine
> >==========
> >
> > * It would be nice to include a manpage explaining what the command
> >   CuraEngine does and the command-line options it accepts. Also it
> >   might be necessary to rename it to "curaengine" for the sake of tab
> >   completion and such, but I'm not sure about this right now.
> 
> This will definitely cause problems with Cura, as it expects the program to
> be named "CuraEngine" and I'd prefer not to modify the upstream sources
> unless it's strictly necessary.
> 
> Also, CuraEngine is a core component of Cura, and while I assume it can be
> used standalone, it's usually not meant to be executed from the command
> line.
> 
> But I can take a look and provide a simple man page, if that's desired.

No, you don't need to do that.  As you say, it's not meant to be used directly.
That means two things: it doesn't need a manpage, and it must not be in the
(default) executable path.  So install it under /usr/lib/cura/ or
/usr/lib/cura-engine/ and make sure the cura package calls it from there.

This means you do need to change the cura source, I suppose, but in this case
that's part of integrating the program with Debian, so it is "strictly
necessary".

Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJY1kzgAAoJEJzRfVgHwHE6abUP/jrimLLg8/xcGAyM62rp2Kmg
uCZFFOfL9LGPOSk6/YU3/0Z8Mu92x35jQunBp6ExbeDFjkF5d3TEeRmPLdKYzYvv
jQ2KOUna3wXVZtqBgNrYQ1U+V7uCKZIerGe4l7yvMOrAll6ZJOdlqlE9CCy2FBna
a+VAS0rqFhhnHsP9MYNjR+j21GCQ+WSF1gx1QyUW+5YviEH620r/tYFBGdCAOx8a
yeDtdHS3Eo6a9iqAviNpxZRVevi9OZy44KglsudRnxDcSal1uIEc1I7jSHqGGyWZ
Ej0fWw4UPhhrRsIQ27Wa2OYYvhR7P1WiDhAmH8VUs7p+7krZ2DGZS5UJbST8RoFi
Sa6QHg7oHu4ClS7wQpUcyk2eVFJo/6V++f+Z28jMebqeRJp7PCz/xk6fI1TzU9kN
MZcVZqPrfe7eMK4/spr5Mu+SdT2cWOUrT+Ph+ei9QrgDcpv85E1PJeX+QfBxJXkJ
3aw0+4YdsoirZfjq/ZR7Prcudpqn3PELab2DMQnBxFoaHKKwfPfl0UbX0pkxInO2
dp9ACBhyNocBm5QwNrBs5IiInxgpj1Zb988tM4ufwd41PA6Tdzjtxui7u31vmKWc
7yt198fUsYzV1X441MRr5WgFvPQJEcQJvlNNBkuNhpiMW3dUyKEf11uVUo9OGU1W
SEOy/fgdDFP08Ua5v5e4
=9xLD
-----END PGP SIGNATURE-----