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

[Petter Reinholdtsen]

[Gregor Riepl]
> Yes. The source packages I pushed to Debian Mentors correspond to the
> branches on git.debian.org.

Very good.  I had a quick look at some of the packages, and noticed a
few things, none of which is serious enough to delay an upload to the
NEW queue for review.

Do you plan to maintain these packages as part of the 3dprinter group?
If so, the maintainer should be changed from your name to the mailing
list, to make sure the packages show up on
<URL: https://qa.debian.org/developer.php?login=3dprinter-general@lists.alioth.debian.org >.

The packages have outdated standards-version.  The current one is 4.1.0,
if I am not mistaken.

You mention that you suspect the lintian issue
hardening-no-fortify-functions might be a bug in lintian or g++.  I am
quite sure it is not a bug in lintian, and suggest to not hide it until
you figure out what is going on.

Did you consider multiarch when structuring the library packages?

The cura-engine package is already in Debian, so a new upload should
either use a different package name or continue the d/changelog from
where the last upload left off.

> As far as I can see, there is nothing in the way of code licenses that
> would block a release. A license compatibility cross-check may still
> be useful - perhaps I missed something.

I did not see anything obvious.

>> It did seem quite complicated.  Some of it could be made easier by
>> adding a debian/gpb.conf file, and some of it could perhaps be made
>> easier by using gbp import-orig.  Why do you use release branches?  I
>> normally do not.
>
> Mostly because upstream works with release branches too. Branches make code
> comparison a bit easier.

I suspect you can get a similar effect by importing orig tarballs (with
pristine-tar, preferably) using the --upstream-vcs-tag=tag_name
argument.

Which package do you believe should be uploaded first?

-- 
Happy hacking
Petter Reinholdtsen