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: #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. 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.
Attachment:
signature.asc
Description: OpenPGP digital signature