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: #nnnnn". 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/
Attachment:
cura_2.3.0-1_amd64.build
Description: Binary data
Attachment:
signature.asc
Description: This is a digitally signed message part