On Tue, Jul 03, 2018 at 11:31:32PM +0200, Gerardo Ballabio wrote: > Hello Markus and all, > I've built the Galois package and would like to post it for review > (it's my first attempt at packaging so feel free to use the > cluestick). Glad to hear it, I'll have a go at answering your questions. > May I ask a few questions: > - Where can I post it? > - What do I need to post? Only the debian directory (.debian.tar.xz > file)? The full source package (.debian.tar.xz, .dsc, .orig.tar.gz)? > The binary package too? The full source package, if you host them on a webserver, you can then just provide the link to .dsc as that's what mentors does. I had a look to try and determine your upstream version control, but couldn't find anything other than an (empty?) CVS repo. I strongly recommend putting at least the debian packaging into source control, particularly git, particularly following this branching scheme: https://dep-team.pages.debian.net/deps/dep14/. Then you can just push to salsa.debian.org and ask for feedback, rather than going via .dsc. > - I listed myself as Maintainer. If you wish, I am willing to give it > to Debian Games Team instead. In that case I guess I should list > myself as Uploader? It's perfectly normal to use "Maintainer" as the team and "Uploader" as the actual person who's most likely to respond to packaging issues, upload new releases etc. This helps us to work together to improve the packaging, make cross-package changes and increase the "bus factor". I learnt a lot quickly by observing team commits. That said, not every game is team-maintained (e.g. freespace2), it is acceptable to maintain it solo, but I definitely wouldn't recommend it for your first package. > - The package isn't signed; I haven't yet generated a GPG key and had > it signed by Debian Developers. Is that something that I should do > before posting the package, or can I do it later (of course before the > actual upload to Debian)? You can do it later, but earlier is better. Your sponsor will sign the actual upload and you don't need DD signatures at this stage. The main advantage of a GPG key initially is it lets you upload your package to mentors.debian.net, which automatically runs simple checks and hosts it. > - Not having a machine running unstable, how can I test the binary > package? I downloaded a live image of testing from > https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/ > (there seems to be no live image of unstable) and tested inside it > (works good as far as I can see), but maybe there's a better way? Live image, virtual machine, create a local "backport" will all work. My main issue is unstable changes so fast that every time I want to test things, I need to wait for an apt upgrade first. For building I use pbuilder chroots, which ensures I'm working with clean dependencies. > Please also advise what I should do with these lintian warnings (all > at wishlist severity): If that's all you've got left, then you've done well at understanding and processing the requirements! > - testsuite-autopkgtest-missing I've got this for most of my packages too, its intent for testing the package actually works after install, i.e. it runs the game. You can leave it open for someone else to work on, don't override it! > - hardening-no-bindnow usr/games/galois > I couldn't find how to add the required flags. I tried adding > "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" to debian/rules > (copied from another package) but the warning didn't disappear. I don't know about this one, sorry, if the recommended solution doesn't work, you could look into what compiler flags it's using under the hood. > - extra-license-file usr/share/gnome/help/galois/C/gpl.dbk > - extra-license-file usr/share/gnome/help/galois/it/gpl.dbk > Lintian says that all license information should be collected in > debian/copyright, but these copies of the GPL are contained in the > upstream source tarball (they're part of the documentation). I'm not > sure whether I should add a Lintian override or just leave this as it > is. Is the package using embedded copies of third-party code? So long as debian/copyright includes the relevant information, it's ok to leave cruft in the .orig.tar.gz, but this looks like you've included it in the build? At the very least if these files are identical I'd create them as symlinks. If they're generated by a documentation tool, how that tool is packaged in debian probably hints as to how to handle it, which might need another dependency. Whatever you choose, if they're supposed to be there, then create an override with a comment documenting the reason. Hope that helps. -- Phil Morrell (emorrp1)
Attachment:
signature.asc
Description: PGP signature