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

Gregor Riepl onitake at gmail.com
Tue Apr 4 21:36:37 UTC 2017


>> 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 <clipper.hpp> 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!




More information about the 3dprinter-general mailing list