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