Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

It looks like Ultimaker dropped official 32 bit support:
https://github.com/Ultimaker/CuraEngine/issues/547

@pere fixed a few obvious bugs, but testing and more patches (if required) are
welcome.
cura-engine 2.5.0 is available in sid.

Note that it's currently missing libArcus for integration into Cura, because
the package still needs to go through QA first.

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

>> Uranium and Cura are both ready for review.
> 
> Very good.  I'll have a look, and hope we can coordinate any fixes on
> IRC.
> 
> Btw, are you aware of http://dep.debian.net/deps/dep3/ >?

Partially. I know the guidelines for patches, but wasn't aware of this DEP.
I'll look at it.

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

[Gregor Riepl]
>> The only packages left now are uranium and cura.
>
> Uranium and Cura are both ready for review.

Very good.  I'll have a look, and hope we can coordinate any fixes on
IRC.

Btw, are you aware of http://dep.debian.net/deps/dep3/ >?

-- 
Happy hacking
Petter Reinholdtsen

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

> I've just uploaded libsavitar to NEW, after giving the d/copyright file a 
> close
> look.  I am aware of the several proposals for improvements, but concluded
> that those can be uploaded next time, and decided it was more important
> to get a slot in the NEW queue for now.
> 
> The only packages left now are uranium and cura.

Oh right, I totally forgot about Uranium. Cura itself should be ready I think.

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

[Gregor Riepl]
> For some very strange reason, I don't see this SEGFAULT when I run the build
> process in a 32-bit VM on an amd64 system. Valgrind doesn't report any errors
> either.

The cause was incorrect use of sprintf() with int64_t.  I've added patches
for this to the latest upload, see
https://anonscm.debian.org/cgit/3dprinter/packages/cura-engine.git/tree/debian/patches
 >.

I've since been told that upstream solved it differently, by moving away
from int64_t to int32_t.  I have no idea if that is a better way to handle
it, but guess we will get that approach as soon as we update to a new
upstream version.

I've just uploaded libsavitar to NEW, after giving the d/copyright file a close
look.  I am aware of the several proposals for improvements, but concluded
that those can be uploaded next time, and decided it was more important
to get a slot in the NEW queue for now.

The only packages left now are uranium and cura.

-- 
Happy hacking
Petter Reinholdtsen

Bug#706656: Info received (Bug#706656: ITP: cura -- Controller for 3D printers)

[Gregor Riepl]

A little update on the StringTest failures on 32-bit systems.

This was already reported upstream by thopiekar:
https://github.com/Ultimaker/CuraEngine/issues/619
I linked the sid build results there.

For some very strange reason, I don't see this SEGFAULT when I run the build
process in a 32-bit VM on an amd64 system.
Valgrind doesn't report any errors either.

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

[Gregor Riepl]
> Before you upload cura-engine, please pull again.
> I forgot to change the Maintainer to the list.

Then thing is, I can not upload cura-engine depending on libarcus as
long as libarcus is in NEW, as it will fail to build.  But I can upload
libsavitar and uranium, as they will go into NEW too.

I'm not sure if cura-engine work without libarcus myself, but disabling
it like this do not break the build, at least:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c2316d6..49ed5c8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,7 +3,7 @@ project(CuraEngine)
 cmake_minimum_required(VERSION 2.8.12)
 
 option (ENABLE_ARCUS
-"Enable support for ARCUS" ON)
+"Enable support for ARCUS" OFF)
 
 if (ENABLE_ARCUS)
 message(STATUS "Building with Arcus")

If this patch is acceptable, we can upload cura-engine right away, and
upload without it once libarcus is available in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

> So, libarcus is uploaded and in NEW, and cura-engine is ready to be
> uploaded but held off until its build dependency libarcus is in
> unstable (what about uploading without arcus support for now?)

Before you upload cura-engine, please pull again.
I forgot to change the Maintainer to the list.

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

Hi Petter

> So, libarcus is uploaded and in NEW, and cura-engine is ready to be
> uploaded but held off until its build dependency libarcus is in
> unstable (what about uploading without arcus support for now?)

CuraEngine is not of much use without libArcus, I'm afraid...
I'm not sure if it even works.

> I'm reluctant to touch the git repository of the remaining packages,
> given that their structure is going to change.  Please let me know when
> you complete a transition.

I'm on it, it's just taking a bit longer because I'm still struggling with
git-buildpackage and the standard Debian repo layout.
But it's coming.

libSavitar 2.6.0-1 is ready for review and Cura is under way.
2.6.0 is not a mistake: it contains a critical patch that was causing a
dependency problem. I changed Cura's dependencies accordingly.

> Bernd Zeimetz had a few comments on IRC regarding libSavitar:
> 
>  I don't know about 2.5/2.6, but mixing the versions sounds wring as 
> they usually are released together

As mentioned above, libSavitar 2.6.0 has a critical fix.
I can turn it into a Debian patch for 2.5.0, but I don't really see the point
since it will be updated to 2.7.0 soon anyway.

>  
> https://github.com/thopiekar/Cura-packaging/blob/master/libSavitar/rules
>  thats the upstream debian/rules file
>  which looks much more sane. the short one from onitake might do the 
> same, but I doubt it builds for all python versions as it should.
>  pere: uranium should remove the update checker plugin
>  https://github.com/thopiekar/Cura-packaging/blob/master/Uranium/rules 
> - again, see upstream
>  pere: also there are some dependencies/recommends missing.
>  numpy and blas on the first look
>  (blas is really recommended to have!)

Thanks for the note, I'll look into it ASAP.
Haven't looked at thopiekar's repo in a while, he didn't show much interest in
addressing Debian policy problems. So I moved away from his work.
But he's working a bit more closely with the Cura project, so it might still
be valuable.

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

So, libarcus is uploaded and in NEW, and cura-engine is ready to be
uploaded but held off until its build dependency libarcus is in
unstable (what about uploading without arcus support for now?)

I'm reluctant to touch the git repository of the remaining packages,
given that their structure is going to change.  Please let me know when
you complete a transition.

Bernd Zeimetz had a few comments on IRC regarding libSavitar:

 pere: the mentors link points to a mix of 2.5.0 and 2.6.0 versions
 ah 3dprinter git, found it
 bzed: yes, https://anonscm.debian.org/git/3dprinter/packages/ >
 I don't know about 2.5/2.6, but mixing the versions sounds wring as they 
usually are released together
 some of them are in some debian-* branches.  
 and cura 2.7.0 is out since a month or so
 my focus so far have not been on versions, but on packaging, but as I 
said, most work is done by onitake.
 pere: the c++ library parts seem to be fine.
 pere: what I think might be broken is th epython part.
 https://github.com/thopiekar/Cura-packaging/blob/master/libSavitar/rules
 thats the upstream debian/rules file
 which looks much more sane. the short one from onitake might do the 
same, but I doubt it builds for all python versions as it should.
 pere: uranium should remove the update checker plugin
 https://github.com/thopiekar/Cura-packaging/blob/master/Uranium/rules - 
again, see upstream
 pere: also there are some dependencies/recommends missing.
 numpy and blas on the first look
 (blas is really recommended to have!)
 I think there is a lot of stuff to merge from upstream
 bzed: sound like git write access would be very useful for you to get.
 pere: I'm not really keen on maintaining more packages
 I need to get rid of some others first
 neither am I, which is why onitake is doing most of the work. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

Hi,

Thanks both for getting this moving again!  I was distracted, so didn't reply,
sorry about that.  I agree that the packages are in pretty good shape, and any
problems that they still have can be dealt with after they have moved into
unstable.

If I'm to sponsor the package, I would suggest becoming a DM soon, so you don't
need to wait for me.  As I'm sure you noticed, I tend to be MIA at times.  In
such cases, also please send me a ping if I'm taking long.

On Thu, Sep 28, 2017 at 09:18:28AM +0200, Petter Reinholdtsen wrote:
> OK, so lets start with libArcus, then.  Should we coordinate on IRC? I
> joined #debian-3dprinting to help out.  If you got the time, I suspect
> we can get it uploaded into NEW today.

Great!  Thanks for your help.
Bas


signature.asc
Description: PGP signature

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

[Gregor Riepl]
> That must have changed in the meantime...
> It was still ok when I packaged 2.5.0 AFAIR.

Yes, it changed fairly recently.

> I did quite a bit of research, and I'm almost certain it's a false positive.
> The docs mention posting to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112 in such a case.
> I'll remove the override until this has been done (post-release).

I suggest you add the bts ref to the lintian comment to make this clear.
I have fairly high trust in this test in lintian, but have not
investigated your particular case, so see no basis to object to your
findings.  I am glad you have researched it. :)

> This problem has already been resolved. cura-engine will be given a new epoch
> (1:in), which makes it a working upgrade to the "old" CuraEngine. As far as I
> understand, the epoch was introduced for exactly this use case.

Yes, but you should not throw away the old changelog entries.

> libArcus is a dependency of Cura and CuraEngine, and libSavitar is
> needed by Cura. Both should be built first. After that, CuraEngine,
> then Uranium (that's the UI framework) and ultimately
> Cura. fdm-materials is an optional package containing only data files
> and can be built separately.

OK, so lets start with libArcus, then.  Should we coordinate on IRC? I
joined #debian-3dprinting to help out.  If you got the time, I suspect
we can get it uploaded into NEW today.

-- 
Happy hacking
Petter Reinholdtsen

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

> 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
>  https://qa.debian.org/developer.php?login=3dprinter-gene...@lists.alioth.debian.org
>  >.

Ok.

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

That must have changed in the meantime...
It was still ok when I packaged 2.5.0 AFAIR.

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

I did quite a bit of research, and I'm almost certain it's a false positive.
The docs mention posting to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112 in such a case.
I'll remove the override until this has been done (post-release).

> Did you consider multiarch when structuring the library packages?

I did follow the advice given in the maintainer docs, but I never tested if
building for other archs or parallel installation would actually work.

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

This problem has already been resolved. cura-engine will be given a new epoch
(1:in), which makes it a working upgrade to the "old" CuraEngine. As far as I
understand, the epoch was introduced for exactly this use case.

Bas agreed that we shouldn't change the package name, as that would be
confusing to users.

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

Ok... I'll look into this.

> Which package do you believe should be uploaded first?

libArcus is a dependency of Cura and CuraEngine, and libSavitar is needed by
Cura. Both should be built first. After that, CuraEngine, then Uranium (that's
the UI framework) and ultimately Cura. fdm-materials is an optional package
containing only data files and can be built separately.

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
https://qa.debian.org/developer.php?login=3dprinter-gene...@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

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

>> The package is on mentors.debian.net, but you also need to get all the
>> dependencies if you want to build it yourself:
>> https://mentors.debian.net/packages/uploader/onitake%40gmail.com
> 
> Is this the same code as on git.debian.org?

Yes. The source packages I pushed to Debian Mentors correspond to the branches
on git.debian.org.

> OK.  The most important part to review before uploading is
> debian/copyright.  Errors there will block the package from entering
> Debian.  All other errors can be fixed when the package is in unstable. :)

This was a concern initially, but has been resolved.
I checked all files for inconsistent license headers and verified that there
were no leftovers. Bas suggested removing shipped dependencies that are
already available in Debian, and I patched those out successfully.

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.

> 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.
But since Ultimaker doesn't do minor releases anyway (or hasn't so far), that
seems overkill.
I have no preference personally.

> Btw, you might find this look useful to include in your README:
> 
>   while quilt push ; do quilt refresh; done
> 
> It will refresh all patches unless one of them cause a problem.

Ok. That's a good idea. :)

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

Hi Gregor.

[Gregor Riepl]
> sorry about the delay. I was waiting for a review from Bas (or another
> DD).  The package is also currently stuck at version 2.5.0, due to a
> lack of time on my side, but I'll try to prepare and push an update
> ASAP.

No worries.

> The package is on mentors.debian.net, but you also need to get all the
> dependencies if you want to build it yourself:
> https://mentors.debian.net/packages/uploader/onitake%40gmail.com

Is this the same code as on git.debian.org?

> Thanks, I'll consider it.
> But I'd really prefer another review of the package before releasing
> it into the wild.

OK.  The most important part to review before uploading is
debian/copyright.  Errors there will block the package from entering
Debian.  All other errors can be fixed when the package is in unstable. :)

> I could also use some help with common usage of Debian git.
> My current build/release procedure for Cura is slightly complicated:
> https://anonscm.debian.org/cgit/3dprinter/packages/cura.git/tree/debian/README.source
> The same has to be repeated for all dependencies.

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.

Btw, you might find this look useful to include in your README:

  while quilt push ; do quilt refresh; done

It will refresh all patches unless one of them cause a problem.

-- 
Happy hacking
Petter Reinholdtsen

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

[Gregor Riepl]

Hi Petter,

sorry about the delay. I was waiting for a review from Bas (or another DD).
The package is also currently stuck at version 2.5.0, due to a lack of time on
my side, but I'll try to prepare and push an update ASAP.

The package is on mentors.debian.net, but you also need to get all the
dependencies if you want to build it yourself:
https://mentors.debian.net/packages/uploader/onitake%40gmail.com

> I need it for a project, and would love to get official Debian packages for
> it.  If a sponsor is needed, feel free to get in touch.  My sponsoring 
> preferences
> are available from http://www.hungry.com/~pere/debian-sponsoring.html >.

Thanks, I'll consider it.
But I'd really prefer another review of the package before releasing it into
the wild.

I could also use some help with common usage of Debian git.
My current build/release procedure for Cura is slightly complicated:
https://anonscm.debian.org/cgit/3dprinter/packages/cura.git/tree/debian/README.source
The same has to be repeated for all dependencies.

Regards,
Gregor

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

[Petter Reinholdtsen]

Hi.  What is the status for getting Cura into Debian?  What is holding up
the upload?

I need it for a project, and would love to get official Debian packages for
it.  If a sponsor is needed, feel free to get in touch.  My sponsoring 
preferences
are available from http://www.hungry.com/~pere/debian-sponsoring.html >.

-- 
Happy hacking
Petter Reinholdtsen

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

[Gregor Riepl]

Hi,

after going through another series of revisions and some cleanup, here is the
set of Cura 2.5 packages for review:

https://mentors.debian.net/package/libarcus
https://mentors.debian.net/package/libsavitar
https://mentors.debian.net/package/uranium
https://mentors.debian.net/package/cura-engine
https://mentors.debian.net/package/cura
https://mentors.debian.net/package/fdm-materials

I tried to address all the open issues and Lintian warnings.
There is now a README.source in every package that details my release process.
I'm open to suggestions for improvement, as it's a bit complicated.

libsavitar and libarcus still produce hardening warnings even though they're
now compiled with full hardening turned on. It seems g++ does not fully
support hardening, or protection is implemented differently. I will bring up
these issues with https://bugs.debian.org/673112 later on.

Thanks for testing, and have fun with Cura 2.5!

Regards,
Gregor



signature.asc
Description: OpenPGP digital signature

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

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Wed, May 03, 2017 at 08:57:54AM +0200, Gregor Riepl wrote:
> I just found a few more packages to build:
> https://github.com/Ultimaker/cura-build/tree/master/projects
> 
> fdm_materials seems relatively important, I packaged it and added it as a
> "Recommends" dependency to Cura. Cura will work without the definitions, but
> having them makes it much more useful.

Sounds good.

> Here: https://anonscm.debian.org/cgit/3dprinter/packages/fdm-materials.git/
> Any opinions? Should I name the package differently?

It looks good to me.  The only thing I'm not sure about is "fdm" in the name;
in scientific articles, I've learned to use "fff" (fused filament fabrication),
because "fdm" is trademarked AFAIK.  But it's certainly legal to use it in this
way, and since they've put it in the name, I would just keep it.

> I also added python3-zeroconf to Recommends:, this allows Cura to autodiscover
> networked UM3 printers.

Yes, that sounds useful.

> Cura-Doodle3D and Cura-Postprocessing are still missing, but I think those
> aren't crucial for the moment. I'll add them later.

Agreed.  First priority is to get Cura into Debian.

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

iQIbBAEBAgAGBQJZCsMoAAoJEJzRfVgHwHE6KaUP+O1jn0tb+SK24sjQuK4XPZOF
hd+uPD5g5HM3CJOkZgyfBNDksj+aOa80GMS6YFO90KhjailwByMHr4bsHv/ro+LE
R1O1KDtLZZPg6JR2pc+Lwd99iwiWAhkw8WXqM+OF49wIzCO2GUNzYCtD/MwjK+L2
5CCE32CRGljijLRkgaI+NUuLm6ElklBrMT41ZrCDukB8NVP2SeYuW3tb5ax9bhXz
9igAHRZjZnS9xBJ034p2yyJmBWDbcpCrD2Rk6gWj/H/KeFzaffFfssLTqvZSI6QE
Jsrl1Q6KOAHHnuFfWlLUGmecExciZlJb3rmvvGmv05PUpz8grDvwp7w/AEvap45l
vS7i/T26Pcc8i3q6WTuaGY0FIonHe3ZrOpVuKcTw3kTHSueIZ+ClsN018InIx9a1
sTk4+dnW5jujMJ2x+PMH7MUKJ/HDhAg+vp/8rQEjYurfVY+1fY+vMVNkIQEOGDxe
ikgpL8LIvnJOJycoQenHyLujvN1TU2ck5butNEWFPLvYQgmY+fQvfjSOkAk3dOCB
rJ+ioYmt5F0w75mQs5t91eiodwK7aqW0ojRBXOAlutF0YNBkHXOVOwMH66kIDXY0
i8JwjL66XxmTLzhKerFWraAESZImy6c4PfRecr1sD5wLBo4XeORLmOPA/ObgvYxt
E5fkqx5vB2yYjqa38G8=
=srKj
-END PGP SIGNATURE-

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

[Gregor Riepl]

Hi,

I just found a few more packages to build:
https://github.com/Ultimaker/cura-build/tree/master/projects

fdm_materials seems relatively important, I packaged it and added it as a
"Recommends" dependency to Cura. Cura will work without the definitions, but
having them makes it much more useful.

Here: https://anonscm.debian.org/cgit/3dprinter/packages/fdm-materials.git/
Any opinions? Should I name the package differently?

I also added python3-zeroconf to Recommends:, this allows Cura to autodiscover
networked UM3 printers.

Cura-Doodle3D and Cura-Postprocessing are still missing, but I think those
aren't crucial for the moment. I'll add them later.

Have a good day,
Greg



signature.asc
Description: OpenPGP digital signature

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

[Gregor Riepl]

> I agree this is the best way; my point was that you should not have a
> repository on github with a copy of the source, and the watch file should 
> point
> to Ultimaker's github.  Having a repository with the packaging is good.  You
> can also host that in our team repository on Alioth.  You are a member with
> commit access.

Oh!
I didn't know that.
Gonna move the 4 repos over to Alioth then, once I've figured out the hows and
wheres.

> Ah yes, I heard someone talk about that, and was told that it worked, but
> getting 2.4 was the easier fix for me. :)

Here's the discussion: https://github.com/Ultimaker/Cura/issues/537



signature.asc
Description: OpenPGP digital signature

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

[Gregor Riepl]

> Ah yes, clipper has weird and annoying naming.  I talked to upstream about it,
> but they don't want to change it.  I think it had something to do with a
> package naming conflict in Red Hat.  In any case, the package is called
> libpolyclipping.  There is a pkg-config file with it, but it's broken, so I
> changed it.  I don't think the change made it in upstream's release, although
> I'm not sure.  Code should use #include  and be compiled with:

Actually, polyclipping/clipper.hpp is correct.
pkg-config gives me -I/usr/include.

I updated the patch accordingly and dropped the removal of libs/*. This should
be sufficient for cmake to not pick any leftovers.

> g++ `pkg-config --cflags polyclipping` -c source.cpp -o object.o
> g++ `pkg-config --libs polyclipping` object.o -o target
> 
> This will add -I/usr/include/polyclipping and -lpolyclipping respectively.

Solved by https://cmake.org/cmake/help/v3.0/module/FindPkgConfig.html

It's building and working as expected.

>> I'm going to double-check if I've missed any files, and then I'll patch up 
>> the
>> the sources to 2.4.0. Hopefully that fixes things.

This, and fonts-open-sans - and we should be good to go.
I haven't received more feedback from the font maintainers, need to check back
and see if the package is ok now.

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

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Apr 04, 2017 at 11:36:37PM +0200, Gregor Riepl wrote:
> > Of course it is still useful to have your packaging (the debian directory) 
> > under version control as well, and using names for those releases also
> > makes sense.  If you want to name them debian-* that's fine, although given
> > that they only contain the debian directory, it doesn't seem like it would
> > confuse anyone anyway.
> 
> Well, this is the best way to do it when using git-buildpackage.
> If you have other suggestions, I'm all ears. :)

I agree this is the best way; my point was that you should not have a
repository on github with a copy of the source, and the watch file should point
to Ultimaker's github.  Having a repository with the packaging is good.  You
can also host that in our team repository on Alioth.  You are a member with
commit access.

> If at all possible, I'd like to stick to cmake modules and not use anything
> external like pkg-config.
> Or maybe there's a cmake module for pulling in information from .pc files?

It seems like there is:
https://cmake.org/cmake/help/v3.0/module/FindPkgConfig.html

> >> Cura's clipper consists of two files and has no external dependencies. I
> >> don't think repackaging it is worth the effort. Should a
> >> security-critical bug be discovered, it's not going to be too hard to
> >> convince the Cura developers to patch CuraEngine.
> > 
> > When I packaged the previous version of Cura (of which only CuraEngine made
> > it into Debian), I thought it was worth the effort, so luckily for you I
> > already packaged it. :)
> 
> Ok... If it doesn't require too many modifications in the build system.

It shouldn't.  Worst case, you can remove the bundled files and replace them
with symlinks as part of the build.  But using pkg-config is better; if
anything changes, that will change with it and it will continue to work.

> > I tried the earlier version from you, which was also unusable for me
> > because it didn't support delta printers.  I downloaded their new release
> > (2.4), which works fine for me.
> 
> It did - if you built your own printer definition with a custom keepout area
> like I did. ;)

Ah yes, I heard someone talk about that, and was told that it worked, but
getting 2.4 was the easier fix for me. :)

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

iQIcBAEBAgAGBQJY5JFPAAoJEJzRfVgHwHE6+tcP/Rsyb//VpCxA+qp7m9arLvlH
G5BbdKqalyIc6b0y9X+A7UhumlKTFKPgwtLoqzQAR/GNsIcZykA8aQDWIXOajezS
yF3pYin/iB1EOTbKqtBX8qtbVtmI/nCEpKjrHj3ATv/eQ98ojK4Zlxyc7uV9mysg
niqw+SNhOr/4xvtLP6+3OPTfRHDH8W0EceXb2dUlxr5qeZVt5hu6SII0G1chJuCH
B1G4SjhaWeAmp6WRJd2We6zsdFvFXivRZ0rqebHAeTUzRCeyN9EI35hX9Ddl8IFL
40JFDJ7JLVr0HxfuVRbzuVoE17b77BCIorH2dsFnbQNgABE2CdcyDNIJ0UUwrcIX
gTcWTbthoIaW1vPKsZ6D1EevC/jAEJeJlv108wKHn3LDllcIeiBil1crZJAPj7lw
86XX0egUb1YeTxoLuauUO2Dg6eeHqr0TYWjpGfHroIMNdhLvfev8OpY5KeEt13/V
jxaPxuoFnh61/5xE3kbhC2Gw2+cnhm/RC6dROBpIfrz13bI+C12yJNQqfH1gB4Hn
3aVwcrUdGn3Vxg6XNFUlOCDOiyqoU2foYAlW1S3eO/lB5BAOCgXkrXourU57zi9H
ChGM4vhIS3omvsXWFYhp++wFQ8ACqTAvjRCuJLdxSz+8nfnxRIpsNbrGmzne6NcC
o/TVYc7LfL5x/NrkKW7w
=iHHt
-END PGP SIGNATURE-

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

[Gregor Riepl]

>> I'll probably settle for debian-2.3.1 (branches) and debian-2.3.1-1
>> (tags).
> 
> Ah, I see.  I think you should use upstream's releases anyway; if you need
> to make changes for the packaging, they should just be part of the package,
> not a fork from upstream.  Especially if the only change that your personal
> upstream has compared to the real upstream is the version number.
> 
> So unless I'm missing something, I think you should use Ultimaker's source
> as upstream.  If you need any changes (such as using packaged libraries),
> they should be part of the packaging (through patches).

This is basically what I'm doing. I'm not maintaining a fork, rather I'm
pulling in the upstream sources as a separate git remote when I'm building
packages.

git-buildpackage handles this very well, if you give it the right arguments.
It will tell you right away if you modified anything outside debian/ that is
not patched by quilt.

> Of course it is still useful to have your packaging (the debian directory) 
> under version control as well, and using names for those releases also
> makes sense.  If you want to name them debian-* that's fine, although given
> that they only contain the debian directory, it doesn't seem like it would
> confuse anyone anyway.

Well, this is the best way to do it when using git-buildpackage.
If you have other suggestions, I'm all ears. :)

>> Ok, so... libclipper is not what you think it is. The one used by Cura
>> comes from here: http://www.angusj.com/delphi/ While the one in Debian is
>> this one: http://www.ysbl.york.ac.uk/~cowtan/clipper/clipper.html
> 
> Ah yes, clipper has weird and annoying naming.  I talked to upstream about
> it, but they don't want to change it.  I think it had something to do with
> a package naming conflict in Red Hat.  In any case, the package is called 
> libpolyclipping.  There is a pkg-config file with it, but it's broken, so
> I changed it.  I don't think the change made it in upstream's release,
> although I'm not sure.  Code should use #include  and be
> compiled with:
> 
> g++ `pkg-config --cflags polyclipping` -c source.cpp -o object.o g++
> `pkg-config --libs polyclipping` object.o -o target
> 
> This will add -I/usr/include/polyclipping and -lpolyclipping respectively.

If at all possible, I'd like to stick to cmake modules and not use anything
external like pkg-config.
Or maybe there's a cmake module for pulling in information from .pc files?

>> Cura's clipper consists of two files and has no external dependencies. I
>> don't think repackaging it is worth the effort. Should a
>> security-critical bug be discovered, it's not going to be too hard to
>> convince the Cura developers to patch CuraEngine.
> 
> When I packaged the previous version of Cura (of which only CuraEngine made
> it into Debian), I thought it was worth the effort, so luckily for you I
> already packaged it. :)

Ok... If it doesn't require too many modifications in the build system.

>> rapidjson is a different story. I managed to build CuraEngine with 
>> librapidjson from sid by patching CMakeLists and removing rapidjson from
>> the tree. I'm not particulary happy with the solution, but it seems to
>> work.
> 
> Sounds good.  I think this is the way to go; I understand upstream when
> they want to bundle their dependencies, so it's not useful to try to
> convince them to stop doing that (aside from the fact that we most likely
> wouldn't succeed). But them bundling them doesn't mean that we should use
> those version.  One point of having a distribution is that we can trust our
> packages, so we don't have to fear our dependencies doing weird things
> without us knowing about it.
> 
>> Now, as for the final result: It is mostly unusable, and I don't know yet
>> if it's upstream's fault or that I missed some files. In any case, there
>> was a regression in 2.3 that made the UI unusable on small screen
>> resolutions. 2.1.3 had worked fine.
> 
> I tried the earlier version from you, which was also unusable for me
> because it didn't support delta printers.  I downloaded their new release
> (2.4), which works fine for me.

It did - if you built your own printer definition with a custom keepout area
like I did. ;)

>> I'm going to double-check if I've missed any files, and then I'll patch
>> up the the sources to 2.4.0. Hopefully that fixes things.
> 
> Sounds good.  Thanks for your work!

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

[Gregor Riepl]

> Any reason you took this off-list?  I'm not sending your mail back to it
> without your permission, but if it was a mistake, feel free to post any of my
> replies back to the list as well.

I'm sorry, that wasn't my intention. I believe one of your responses was
addressed to me personally, so I thought you wanted to discuss the issue in
private first to reduce list noise. Or, maybe I forgot the Cc myself at some
point, and your responses were off-list after that.

Looks like this was a total misunderstanding!

The previous discussion follows:

>> >> Looking at libArcus, I see two things: the problem that it detects is
>> >> that the watch file doesn't match any file on github.  This is because of
>> >> the "d" you left in there, which means it will only match versions
>> >> starting with a literal d.  If you remove it, it accepts any file that
>> >> starts with a number (and ends with .tar.gz).
>> > 
>> > Argh. I thought I had copy-pasted the Github rule from the Debian docs.
>> > Looks like I messed that up.
>> 
>> Now I remember why I did this:
>> I was planning to tag my Debian releases as 'd2.3.1' to differentiate them
>> from the upstream '2.3.1'. But that's not the best idea, and they still lack
>> the Debian release ('2.3.1-1').
>> 
>> I'll probably settle for debian-2.3.1 (branches) and debian-2.3.1-1 (tags).
> 
> Ah, I see.  I think you should use upstream's releases anyway; if you need to
> make changes for the packaging, they should just be part of the package, not a
> fork from upstream.  Especially if the only change that your personal upstream
> has compared to the real upstream is the version number.
> 
> So unless I'm missing something, I think you should use Ultimaker's source as
> upstream.  If you need any changes (such as using packaged libraries), they
> should be part of the packaging (through patches).
> 
> Of course it is still useful to have your packaging (the debian directory)
> under version control as well, and using names for those releases also makes
> sense.  If you want to name them debian-* that's fine, although given that 
> they
> only contain the debian directory, it doesn't seem like it would confuse 
> anyone
> anyway.
> 
>> Ok, so... libclipper is not what you think it is.
>> The one used by Cura comes from here: http://www.angusj.com/delphi/
>> While the one in Debian is this one:
>> http://www.ysbl.york.ac.uk/~cowtan/clipper/clipper.html
> 
> Ah yes, clipper has weird and annoying naming.  I talked to upstream about it,
> but they don't want to change it.  I think it had something to do with a
> package naming conflict in Red Hat.  In any case, the package is called
> libpolyclipping.  There is a pkg-config file with it, but it's broken, so I
> changed it.  I don't think the change made it in upstream's release, although
> I'm not sure.  Code should use #include  and be compiled with:
> 
> g++ `pkg-config --cflags polyclipping` -c source.cpp -o object.o
> g++ `pkg-config --libs polyclipping` object.o -o target
> 
> This will add -I/usr/include/polyclipping and -lpolyclipping respectively.
> 
>> Cura's clipper consists of two files and has no external dependencies. I 
>> don't
>> think repackaging it is worth the effort. Should a security-critical bug be
>> discovered, it's not going to be too hard to convince the Cura developers to
>> patch CuraEngine.
> 
> When I packaged the previous version of Cura (of which only CuraEngine made it
> into Debian), I thought it was worth the effort, so luckily for you I already
> packaged it. :)
> 
>> rapidjson is a different story. I managed to build CuraEngine with
>> librapidjson from sid by patching CMakeLists and removing rapidjson from the
>> tree. I'm not particulary happy with the solution, but it seems to work.
> 
> Sounds good.  I think this is the way to go; I understand upstream when they
> want to bundle their dependencies, so it's not useful to try to convince them
> to stop doing that (aside from the fact that we most likely wouldn't succeed).
> But them bundling them doesn't mean that we should use those version.  One
> point of having a distribution is that we can trust our packages, so we don't
> have to fear our dependencies doing weird things without us knowing about it.
> 
>> Now, as for the final result: It is mostly unusable, and I don't know yet if
>> it's upstream's fault or that I missed some files. In any case, there was a
>> regression in 2.3 that made the UI unusable on small screen resolutions. 
>> 2.1.3
>> had worked fine.
> 
> I tried the earlier version from you, which was also unusable for me because 
> it
> didn't support delta printers.  I downloaded their new release (2.4), which
> works fine for me.
> 
>> I'm going to double-check if I've missed any files, and then I'll patch up 
>> the
>> the sources to 2.4.0. Hopefully that fixes things.
> 
> Sounds good.  Thanks for your work!
> Bas
> 

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

[Gregor Riepl]

And here's my (updated) response to Rock's comments:

> libArcus
> 
> 
> debian/changelog
> 
> 
>  * 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".

Done.

>  * Typically, new packages contain only a single entry with a line
>similar to "Initial Release. Closes: #n". The changelog should
>only contain entries for actually released revisions. In this case,
>if version 2.1.3-1 never made it into Debian it should be removed
>and if version 2.3.0-1 is going to be the first to get into then
>this should be the one and only entry in the changelog.

Fixed.

> debian/control
> --
> 
>  * Since "3.0 (quilt)" souce package format it is no longer needed to
>list "quilt" as a build-dependency [1]. Patches can now be handled
>by dpkg-source. In fact you don't even need the "--with quilt" flag
>on debian/rules (I tried removing this flag and it built correctly,
>please let me know if doesn't work for you)

Removed.

>  * The VCS fields should point to "where the Debian source package is
>developed" [2], that is, where the changes to the debian folder are
>made, which in this case would be your GitHub repository and not
>upstream's.

Thanks for the hint, the exact meaning of those fields wasn't clear to me. 
Fixed.

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

Fixed by naming the binary package libarcus3.
The other packages were left as-is, I assumed that's ok.

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

As suggested by Bas, I set compat to 10 and added a dependency on debhelper
10. This should have the same effect.

> debian/watch
> 
> 
>  * It'd be nice to include a watch file, some Debian tools rely on this
>file to i.e. estimate the "freshness" of the Debian repository as a
>whole. It should be particularly easy to write a wath file in your
>case since upstream uses GitHub, check out this template [4].

Done, for all 4 packages.

> debian/patches
> --
> 
>  * Although not mandatory you might want to adhere to the "Patch
>Tagging Guidelines" [5]

Done.

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

Done, with the help of help2man.
Some manual editing was necessary. Perhaps it's possible to fully autogenerate
with the right options.

> Cura
> 
> 
>  * This one I haven't been able to build. I'm attaching the build log.
>It might be an error on my building tool-chain but please check it
>out, just in case. Error shows up around line 583.

This issue should be fixed now.




signature.asc
Description: OpenPGP digital signature

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

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Mon, Mar 27, 2017 at 09:04:21AM +0200, Gregor Riepl wrote:
> > 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'm sorry for the lack of action on my part, progress was stalled since some
> of the criticised points are a bit difficult to fix, and I've been too busy to
> invest much time into the them.

No problem, thanks for working on it!

> I did cut down on them a bit, but the packages are still not done yet.

Cool.  I'm sure we'll get there. :)

> > 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.
> 
> I reported the issue upstream, but haven't received a conclusive repsonse:
> https://github.com/Ultimaker/libArcus/issues/52

That looks good.  I hope they will respond.  It is bad for users if Debian's
and upstream's SONAMEs are incompatible; if they install something from us and
from online, it will break things.

> One of my suggested options would require changing upstream versioning
> altogether, the other would assimilate the Debian package version to what they
> are already using. And awhienstra said they would be changing Arcus versioning
> anyway.
> 
> So I'm not sure what to do.

The important part in terms of compatibility is the SONAME.  So the version of
the package doesn't really matter, but the files and symlinks in /usr/lib
should be properly named, and if possible, the SONAME should be identical to
what upstream uses.

> >> 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".
> 
> I'm a bit reluctant to do this, as it will introduce additional maintenance
> overhead. But if this is the 'proper' way to go, I'll look into it.

Well, the other option is to say that users can use it directly.  This is a
reasonable thing to say; I'm actually planning to set up some automated slicing
system which uses only the engine, not the gui.  So in that case, it should be
in the executable path, and it should also have a manpage.  For programs like
this, most of that manpage can be the contents of the --help output.

As for the capitals in the filename: I don't think there's a rule against it.
Most programs don't have capitals in them, so you could ask upstream to
consider changing it (but you can also not bother them), but it's not a big
deal, and having the same name as upstream is more important than it being
lowercase.

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

iQIcBAEBAgAGBQJY2N/gAAoJEJzRfVgHwHE6fl8P/1EabLSF7TUxKvv/jafwwHs0
hTTAjmqy2qgsA/dFN3X2YIMKmX14cxf5fXd3XZ0ASYAWPSKA7hLcTwN4hH8aM69Y
8fB7EYAq2O0COZ7txPRKp4nWXxX8Rn2zoaFpnXEKgjgRNIcZjtl4sT4JoNR2MFu/
T8Hv/8MjVLB5IdoKCX0eaWhE2DlT3Cd+o4n4q1x65vFhbt9f61SYto+kHCRfc7qA
nq4k8O3fxPdEpZkh89P/5ra8TTQhxvvStNsZHUNaT3TXVS5WIMOZA28RzDvP4Y77
ISyQ81eLOmdGZT8VoGHqbwH1Pj3iW9eddOSymR+mi1m1IzNB7jmBHQdLff3HbzPT
SI1BotEO8krT8okKqMEjK46zbabjhh6tcvSWPV9olylCM8zyRns9WYdtVMsxhiij
FMZqTCMpKfV3cBMbwyxqLXfB/ArQyDT4eFgKGGrqhOoIvBHlConYjWA2+q+rKOHi
zBXH5gL6WCbdjIiGpvgQKvA5z+Hx3eCJh9pXVK7lAH+5Ylpqfl1qO5yLvjAnqO9N
gFjhk+xjSrh4+7PnYHm6W8nHti/jWQW9FVLtfS1nmfHmBoMPR9ac46CROA29JB7y
TNi/qpTv2fRImhhRP+NxhlBiD1Wy8PSTxhm6PMzTjebmwpKIRzjrukVvQtpVo4WA
cJQiM/pLA+TSrwqJxyu1
=NPau
-END PGP SIGNATURE-

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

[Gregor Riepl]

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'm sorry for the lack of action on my part, progress was stalled since some
of the criticised points are a bit difficult to fix, and I've been too busy to
invest much time into the them.

I did cut down on them a bit, but the packages are still not done yet.

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

Please excuse me, then. I will take more care about these things from now on.

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

I reported the issue upstream, but haven't received a conclusive repsonse:
https://github.com/Ultimaker/libArcus/issues/52

One of my suggested options would require changing upstream versioning
altogether, the other would assimilate the Debian package version to what they
are already using. And awhienstra said they would be changing Arcus versioning
anyway.

So I'm not sure what to do.

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

Ok, I will test that.

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

I'm a bit reluctant to do this, as it will introduce additional maintenance
overhead. But if this is the 'proper' way to go, I'll look into it.

Best regards,
Greg



signature.asc
Description: OpenPGP digital signature

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

[Bas Wijnen]

-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 

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

[Gregor Riepl]

Hi Rock,


Here are my comments, I must say I don't use the software so I only
checked the building and the packaging. I trust you are testing that
once installed all four packages perform as expected :).


Thanks for the review!
I'll comment below.

> libArcus
> 
>
> debian/changelog
> 
>

 * 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.
Who still uses a 80-character terminal in this day and age anyway? :)


 * Typically, new packages contain only a single entry with a line
   similar to "Initial Release. Closes: #n". The changelog should
   only contain entries for actually released revisions. In this case,
   if version 2.1.3-1 never made it into Debian it should be removed
   and if version 2.3.0-1 is going to be the first to get into then
   this should be the one and only entry in the changelog.


There is a particular reason why packaged 2.1.3 first:
2.3.0 has several usability problems for me, such as widgets that are cut off 
at the bottom and blurry font rendering. These were not present in 2.1.3.


I still need to test 2.3.1 though, perhaps these problems have been fixed 
already.

Also, when I submitted Cura to Debian Mentors, I hadn't tested 2.3.0 and 2.3.1 
yet and wanted to get feedback on the packaging as a whole first. But I will 
certainly update the changelog accordingly, when review is complete.


> debian/control
> --
>

 * Since "3.0 (quilt)" souce package format it is no longer needed to
   list "quilt" as a build-dependency [1]. Patches can now be handled
   by dpkg-source. In fact you don't even need the "--with quilt" flag
   on debian/rules (I tried removing this flag and it built correctly,
   please let me know if doesn't work for you)


Ok, I didn't know this. Will be corrected.


 * The VCS fields should point to "where the Debian source package is
   developed" [2], that is, where the changes to the debian folder are
   made, which in this case would be your GitHub repository and not
   upstream's.


Ok.


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



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.


debian/watch


 * It'd be nice to include a watch file, some Debian tools rely on this
   file to i.e. estimate the "freshness" of the Debian repository as a
   whole. It should be particularly easy to write a wath file in your
   case since upstream uses GitHub, check out this template [4].


Ok.


debian/patches
--

 * Although not mandatory you might want to adhere to the "Patch
   Tagging Guidelines" [5]


I'll have a look.


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.


Cura


 * This one I haven't been able to build. I'm attaching the build log.
   It might be an error on my building tool-chain but please check it
   out, just in case. Error shows up around line 583.


Woops, looks like I forgot to merge a patch back into the 2.3.0 branch. 

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

[Rock Storm]

Hi Gregor,

Here are my comments, I must say I don't use the software so I only
checked the building and the packaging. I trust you are testing that
once installed all four packages perform as expected :).


libArcus


debian/changelog


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

 * Typically, new packages contain only a single entry with a line
   similar to "Initial Release. Closes: #n". The changelog should
   only contain entries for actually released revisions. In this case,
   if version 2.1.3-1 never made it into Debian it should be removed
   and if version 2.3.0-1 is going to be the first to get into then
   this should be the one and only entry in the changelog.


debian/control
--

 * Since "3.0 (quilt)" souce package format it is no longer needed to
   list "quilt" as a build-dependency [1]. Patches can now be handled
   by dpkg-source. In fact you don't even need the "--with quilt" flag
   on debian/rules (I tried removing this flag and it built correctly,
   please let me know if doesn't work for you)
 
 * The VCS fields should point to "where the Debian source package is
   developed" [2], that is, where the changes to the debian folder are
   made, which in this case would be your GitHub repository and not
   upstream's.
 
 * 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.


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


debian/watch


 * It'd be nice to include a watch file, some Debian tools rely on this
   file to i.e. estimate the "freshness" of the Debian repository as a
   whole. It should be particularly easy to write a wath file in your
   case since upstream uses GitHub, check out this template [4].


debian/patches
--

 * Although not mandatory you might want to adhere to the "Patch
   Tagging Guidelines" [5]


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.


Cura


 * This one I haven't been able to build. I'm attaching the build log.
   It might be an error on my building tool-chain but please check it
   out, just in case. Error shows up around line 583.


Regards,

Rock Storm
Debian 3D-Printer Packaging Team

--
[1] https://pkg-perl.alioth.debian.org/howto/quilt.html#The_%22Post-Mod
ern%22_Way_%28%223.0_%28quilt%29%22%29
[2] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-
VCS-fields
[3] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-share
dlibs-runtime
[4] https://wiki.debian.org/debian/watch#GitHub
[5] http://dep.debian.net/deps/dep3/

cura_2.3.0-1_amd64.build
Description: Binary data


signature.asc
Description: This is a digitally signed message part

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

[Gregor Riepl]

Hi Alvaro,


I'm sorry it took me this long to start reviewing your work. I was about to
try to build your packages but I haven't been able to figure out how to do it.
How do you build your packages? Do you use git-buildpackage? I'm missing a
branch named "upstream" or something similar. A typical branch layout is
briefly explained here https://wiki.debian.org/3D-printer/gbp.


Sorry about that.

I wasn't very happy with the defaults that gbp assumes, so I named the 
branches a bit differently. IMHO, "master" should be the upstream branch, not 
the debian build branch. I also removed all the upstream branches from my 
repository, so those need to be fetched separately.


This is what you can use to build a certain version:

# or Uranium or CuraEngine or Cura
PACKAGE=libArcus
VERSION=2.1.3
git clone https://github.com/UltiMaker/$PACKAGE
cd $PACKAGE
git remote add onitake https://github.com/onitake/$PACKAGE
git fetch --all
git checkout debian-$VERSION
debian/rules clean
gbp buildpackage --git-upstream-branch=master 
--git-debian-branch=debian-$VERSION --git-upstream-tree=$VERSION


Please note that some of the packages have build dependencies on each other, 
so you need to build libArcus and Uranium first.


Bas requested that I also submit to Debian Mentors, so you can find signed 
source packages here:

https://mentors.debian.net/packages/uploader/onit...@gmail.com

Thanks for reviewing them!
Greg

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

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gregor,

On Thu, Sep 22, 2016 at 01:02:26PM +0200, Gregor Riepl wrote:
> > I can help you with that.  If you choose to maintain it in the 3-D printer
> > team, others in the team can also help you out with that.
> 
> Very good, how do I sign up? :)

You'll want to subscribe to the mailing list.  If you tell me your username on
alioth (make one if you don't have one yet), I'll add you as a team member.
You will probably want to read the wiki on our packaging procedures (seems
approximately what you do now, I think).

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

iQIcBAEBAgAGBQJX4/CRAAoJEJzRfVgHwHE6t0kP/0Z+V6s/qkeBIzf4UTakQPg4
YxrgyyAuCXzx8M83iqCX4EgsLuxkx3iR0JpK/i0n4phXtiCOdr35KMjRslc/r4uy
yeWbrirGAGtEB2e2L+snZYHM0BY6+gZ1V309Wiu90J3hhL9KrspYkMaXDV1+Hdq8
zMdHqpJcNbx+HQOTesQkZN/sDBcLq/ce9OoQEdocrjptU75eMFyLxMTBSWCxmxGM
QKb3pa+ok7YmCYg16Or2l0A7i5gRdCD0+JWb/yqaqF0q5gWCqvBVUbW9fTKHt5oz
vgUUMy8IuGZocBYYIDBbreh8kN31dlR/Zt0JXk0BOjXHhidh0Ofz/UsyMp0Z4VCQ
o3rWmVHT8C+oee5v/2MTTHJsbKsPqI6KoI+anczRZ9aUWiEevRi8fiGX+n1p6oF8
WymckA/aky3MWQ0k1vBzuXN7i2kpETRFB9Ug3Uau6aukpettUMIz64QmtP3kTgOb
WWlwPaeBH+dXzbhIZVLbyme48agmauaH8IJkmCboa06EbugcTNm309jB8Kp+datL
V6fn9Rbq3OOQ6OXLVDaQ+YHWtsGepBZgNGC/GJPe13HrzqLhNp+evcY6kBBy243d
yoqQ3HKcv+rkzc/4bYzCGAKJs+CdPKzp9qegwEwIJnUEK9wRSoj/A/XcJuBgBEyB
06jwZ6ma6I1g6VnHH76l
=TTS/
-END PGP SIGNATURE-

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

Hi Bas,

> Thanks for taking this on!  I've been meaning to do that for quite some
> time, but didn't get to it so far.
> 
> Would you be interested in maintaining it inside the 3-D printer team?

Thanks for your comments!
Working with others will certainly speed up things.

I also got pointed to this PPA repo here:
https://github.com/thopiekar/Cura-packaging
It probably needs some tweaking, but the dependency lists are much more refined 
than mine. May be a better starting point.

> Last time I tried to upload Cura (that was before Uranium, so a lot probably
> changed), there were quite a few non-free files in the source.  What I
> still needed to do was remove them (none of them were required for building
> the package).  Did you check if they are still there, and remove them if
> so?

No, I haven't. I'm not 100% sure what to look for, but I'll check.

> Debian doesn't really have preferred licenses.  It is certainly compatible
> with the DFSG, some people in Debian hate it and others like it (like me; I
> use it for most of my own code).
> 
> By the way, is it AGPL3 or AGPL3+?  That is, did they specify "or any later
> version"?  If not, that's something to ask if that was intentional.  The
> license is acceptable for Debian regardless though.

Good point. As far as I can tell, all sources are covered under AGPL3+.
cura_app.py says:
# Cura is released under the terms of the AGPLv3 or higher.
Uranium is missing a LICENSE file, but the source code files carry this line 
too. I haven't checked all of them, though.

> I was going to file a request to remove the old package entirely.  It is
> broken and there is no reason to fix it; it needs to be replaced with the
> new version. Since the old version is much larger than the new one, you can
> use an epoch (1:2.1.3) to force this to be a higher version.

Interesting, I didn't know this works.
This is exactly what thopiekar did in his PPA.

> With the same name for the package, there is no need for a Breaks:.

Ah, of course.

> Building in the source tree is not a problem in itself, but "debian/rules
> clean" should restore or remove all the generated and/or changed files. 
> That is, the tree should be identical after "debian/rules clean" and
> "debuild && debian/rules clean".

I'll check if/how this is possible. Building out-of-tree will probably be 
easier, though.
Is there a cmake/dh flag to do this. I searched, but haven't found anything 
suitable...

> I hope to try it out soon and let you know.

After reading thopiekar's package files, I think there may be some dependency 
problems. I'll look into this.

> I can help you with that.  If you choose to maintain it in the 3-D printer
> team, others in the team can also help you out with that.

Very good, how do I sign up? :)

Bug#706656: ITP: cura -- Controller for 3D printers

[Philip Hands]

Gregor Riepl  writes:

> Package: wnpp
> Followup-For: Bug #706656
> Owner: Gregor Riepl 
>
> Hello, I've been using Cura (new Cura, not the legacy one) for a while, and
> decided that it would be a good idea to package it up for Debian.
>
> Upstream does not make this particularly easy, but thanks to the use of
> standard build tools, it wasn't very hard either.
>
> Therefore, I present debianized forks of the upstream Cura git repository and
> its dependencies:
> https://github.com/onitake/libArcus
> https://github.com/onitake/Uranium
> https://github.com/onitake/CuraEngine
> https://github.com/onitake/Cura
>
> Each of these repositories has a branch "debian" that contains a debian/
> directory with all relevant build files. The dependencies are taken care of -
> at least to the best of my knowledge. Please note that I am not an experienced
> Debian maintainer, so there may be mistakes.
>
> A few notes:
> - All code is released under Affero GPLv3. I believe this is not one of the
> preferred Debian package licenses, but it was deemed compatible with the DFSG
> previously.

AGPL is fine

> - libArcus is built into multiple packages: a shared library, development
> files/headers, and a python3 library. The python library is named
> python3-libarcus to reflect the relationship/dependency with libarcus itself.
> - The CuraEngine package was named cura-engine2 to avoid conflicts with old
> Cura, which used a very different and incompatible versioning scheme. A
> "Breaks: cura-engine" was added, because both executables install under the
> same name.

I'd think that should be a Conflicts: rather than a Breaks -- see:

  https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

and also perhaps:

  https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
  https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gregor,

Thanks for taking this on!  I've been meaning to do that for quite some time,
but didn't get to it so far.

Would you be interested in maintaining it inside the 3-D printer team?

Last time I tried to upload Cura (that was before Uranium, so a lot probably
changed), there were quite a few non-free files in the source.  What I still
needed to do was remove them (none of them were required for building the
package).  Did you check if they are still there, and remove them if so?

I didn't look at the package yet, but already have some feedback to what you
write.  I also CCd the 3-D printer team, so others know this is happening.

On Thu, Sep 22, 2016 at 12:57:27AM +0200, Gregor Riepl wrote:
> - All code is released under Affero GPLv3. I believe this is not one of the
> preferred Debian package licenses, but it was deemed compatible with the DFSG
> previously.

Debian doesn't really have preferred licenses.  It is certainly compatible with
the DFSG, some people in Debian hate it and others like it (like me; I use it
for most of my own code).

By the way, is it AGPL3 or AGPL3+?  That is, did they specify "or any later
version"?  If not, that's something to ask if that was intentional.  The
license is acceptable for Debian regardless though.

> - libArcus is built into multiple packages: a shared library, development
> files/headers, and a python3 library. The python library is named
> python3-libarcus to reflect the relationship/dependency with libarcus itself.

Sounds good.

> - The CuraEngine package was named cura-engine2 to avoid conflicts with old
> Cura, which used a very different and incompatible versioning scheme. A
> "Breaks: cura-engine" was added, because both executables install under the
> same name.

I was going to file a request to remove the old package entirely.  It is broken
and there is no reason to fix it; it needs to be replaced with the new version.
Since the old version is much larger than the new one, you can use an epoch
(1:2.1.3) to force this to be a higher version.

With the same name for the package, there is no need for a Breaks:.

> - The debian branch is currently tied to the 2.1.3 release, I will try to keep
> it in sync with upstream releases.

Good idea.

> - Building the packages pollutes the source tree. I have not found a way to
> address this, any hints are appreciated.

Building in the source tree is not a problem in itself, but "debian/rules
clean" should restore or remove all the generated and/or changed files.  That
is, the tree should be identical after "debian/rules clean" and "debuild &&
debian/rules clean".

> Please test it and give me feedback, I will apply corrections and improvements
> as needed.

I hope to try it out soon and let you know.

> If the packages are accepted into Debian, I would like to request sponsorship
> from a Debian maintainer, as I do not have commit access.

I can help you with that.  If you choose to maintain it in the 3-D printer
team, others in the team can also help you out with that.

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

iQIcBAEBAgAGBQJX43N7AAoJEJzRfVgHwHE6XuoP/3YVYJUYtkv8nYK4UqM/hO8O
Hu98a3QqBB7cvj+FNsP3YnMBvIdSQ3CBTIY2WHIOkjemFT3xw4hVPZvtX1Mk0bvM
ofH9i/bVl72F7nKKKmOne81sxb5fiaVyhu5SjfhsCCjfvDZ1RE9gG4ofMgTZ4evb
tkPyyEi1BxWb/wZuUoyRx5EDNUS+kjBLmY77EU20PULFdH8rFqZ/IXOprllDtWnq
/spp/n13A1sKK1oueAsLUJwU42zBrppqMWQBvv+sL7QgPemJOBTZsqbx+bBUw9/g
HucUg0ZUnT29Qvrt73M0BHp6D0NAphQCGH64QpqOx/gCGeQ8q5Zgb583q1OfvlIG
RnvGQSy2iK/ggTeQZ0HNf5Z8/da3Z+wcYRfEZLJdO/Z3k/D5sok6lzyPAtg7xVMz
eC31FEUDP7ktVs4eyOQe/CypkIt/N+EXMmAxmyL/fAwLxo4Ayv4f0zOc2GPiJe8q
o6ztd4Z7VGqEfzGG4P+FF7xT7dy62WtwCH5YevDji4BcE1OzOFl2Ur4NFeV7QK3u
N8EzDZkn5NWjyp6Y4ORpoPEx3iEMiQz+/CHIlTgSQk2/Eh93vt7B58A0pri62jSf
5MCmFr6YtYJ+ofyk4uzOIdnGQwJeDxh7feTEzjgqR8KWwZPf76EQC03v+0Bpk0G8
kRU+xIrW6piXulNuXOeq
=8kBV
-END PGP SIGNATURE-

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

I forgot one thing:
- libArcus carries the same version as the rest of the packages, but it 
actually uses a different versioning scheme. The shared library is named 
libArcus.so.1.0.0, with the SONAME = libArcus.so.2. This may or may not be 
correct. A bug report was filed upstream: https://github.com/Ultimaker/
libArcus/issues/43

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

Package: wnpp
Followup-For: Bug #706656
Owner: Gregor Riepl 

Hello, I've been using Cura (new Cura, not the legacy one) for a while, and
decided that it would be a good idea to package it up for Debian.

Upstream does not make this particularly easy, but thanks to the use of
standard build tools, it wasn't very hard either.

Therefore, I present debianized forks of the upstream Cura git repository and
its dependencies:
https://github.com/onitake/libArcus
https://github.com/onitake/Uranium
https://github.com/onitake/CuraEngine
https://github.com/onitake/Cura

Each of these repositories has a branch "debian" that contains a debian/
directory with all relevant build files. The dependencies are taken care of -
at least to the best of my knowledge. Please note that I am not an experienced
Debian maintainer, so there may be mistakes.

A few notes:
- All code is released under Affero GPLv3. I believe this is not one of the
preferred Debian package licenses, but it was deemed compatible with the DFSG
previously.
- libArcus is built into multiple packages: a shared library, development
files/headers, and a python3 library. The python library is named
python3-libarcus to reflect the relationship/dependency with libarcus itself.
- The CuraEngine package was named cura-engine2 to avoid conflicts with old
Cura, which used a very different and incompatible versioning scheme. A
"Breaks: cura-engine" was added, because both executables install under the
same name.
- The debian branch is currently tied to the 2.1.3 release, I will try to keep
it in sync with upstream releases.
- Building the packages pollutes the source tree. I have not found a way to
address this, any hints are appreciated.
- libArcus should be built first, as the other packages depend on it.

Please test it and give me feedback, I will apply corrections and improvements
as needed.

If the packages are accepted into Debian, I would like to request sponsorship
from a Debian maintainer, as I do not have commit access.

Bug#706656: ITP: cura -- Controller for 3D printers

[Tony Godshall]

+1

On May 2, 2013 6:18 PM, Bas Wijnen wij...@debian.org wrote:

 Package: wnpp
 Severity: wishlist
 Owner: Bas Wijnen wij...@debian.org

 * Package name: cura
   Version : 13.04~git20130502-1
   Upstream Author : David Braam (daid...@gmail.com)
 * URL : http://daid.github.io/Cura/
 * License : AGPL-3+
   Programming Lang: Python
   Description : Controller for 3D printers

 Cura is a project which aims to be an single software
 solution for 3D printing. While it is developed to be used
 with the Ultimaker 3D printer, it can be used with other
 RepRap based designs.

 Cura helps you to setup an Ultimaker
 Cura shows your 3D model, allows for scaling/positioning
 Cura can slice the model to 3D GCode
 Cura can send this GCode to the 3D printer for printing
 And more...


 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
 Archive:
http://lists.debian.org/20130503011533.13027.38521.report...@heights-197-63.mtu.edu

Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

Update: I'm having a discussion with upstream, and hopefully we will
soon have a package in the archive.  I was waiting for the new release,
which has now happened; now we're looking at the clipperlib that is
used, which seems to be different from the one in Debian.

Thanks,
Bas

On Sat, Jul 27, 2013 at 08:02:36AM -0700, Tony Godshall wrote:
 +1
 
 On May 2, 2013 6:18 PM, Bas Wijnen wij...@debian.org wrote:
 
  Package: wnpp
  Severity: wishlist
  Owner: Bas Wijnen wij...@debian.org
 
  * Package name: cura
Version : 13.04~git20130502-1
Upstream Author : David Braam (daid...@gmail.com)
  * URL : http://daid.github.io/Cura/
  * License : AGPL-3+
Programming Lang: Python
Description : Controller for 3D printers
 
  Cura is a project which aims to be an single software
  solution for 3D printing. While it is developed to be used
  with the Ultimaker 3D printer, it can be used with other
  RepRap based designs.
 
  Cura helps you to setup an Ultimaker
  Cura shows your 3D model, allows for scaling/positioning
  Cura can slice the model to 3D GCode
  Cura can send this GCode to the 3D printer for printing
  And more...
 
 
  --
  To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
  with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
  Archive:
 http://lists.debian.org/20130503011533.13027.38521.report...@heights-197-63.mtu.edu
 


signature.asc
Description: Digital signature

Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen wij...@debian.org

* Package name: cura
  Version : 13.04~git20130502-1
  Upstream Author : David Braam (daid...@gmail.com)
* URL : http://daid.github.io/Cura/
* License : AGPL-3+
  Programming Lang: Python
  Description : Controller for 3D printers

Cura is a project which aims to be an single software
solution for 3D printing. While it is developed to be used
with the Ultimaker 3D printer, it can be used with other
RepRap based designs.

Cura helps you to setup an Ultimaker
Cura shows your 3D model, allows for scaling/positioning
Cura can slice the model to 3D GCode
Cura can send this GCode to the 3D printer for printing
And more...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org