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