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