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-
