Bug#706656: ITP: cura -- Controller for 3D printers
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
>> 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
[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
> 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
[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)
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
[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
> 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
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
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
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
[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
> 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
[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
>> 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
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
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
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
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
-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
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
> 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
> 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
-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
>> 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
> 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
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
-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
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
-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 chan
Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers
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. On
Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers
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
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
-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
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
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
-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
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
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
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" wrote: > > > > Package: wnpp > > Severity: wishlist > > Owner: Bas Wijnen > > > > * 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
+1 On May 2, 2013 6:18 PM, "Bas Wijnen" wrote: > > Package: wnpp > Severity: wishlist > Owner: Bas Wijnen > > * 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
Package: wnpp Severity: wishlist Owner: Bas Wijnen * 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-wnpp-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
