Hi Thomas, Reply follows in-line:
Thomas Koch <tho...@koch.ro> writes: > Hi Nicholas, > > I just uploaded persist-el. Thank you and sorry for the delay. This > was my first sponsorship and I also had to setup a new laptop. I'm > just waiting for the confirmation mail for the upload. > Thank you for sponsoring! Best of luck with the toil of getting the new laptop setup (eg: MUA line wrapping, and weird trailing white-space in lintian output). Did you upload twice btw? [22-04 edit: Oh! Sébastien, thank you!] > There are a few nitpicks and I'd be grateful if you could track them, > e.g. in bugs.d.o after the package enters the archive: > > - It's a pity that we can not include the info file due to the > license. Could you ask upstream to consider another license? Sure thing, I've added it to my TODO. BTW, because it's a GNU ELPA project I'm pessimistic they'll relicense the docs... > - As long as the doc is not included, I think you don't need to build > depend on texinfo. Agreed, I'll either drop it for the -2 upload, or if upstream relicenses their texinfo source then I'll build the info file. > - If upstream also uses Git, I prefer to track upstreams master branch > as upstream branch in the packaging repo. You could still merge their > branch in your existing repo or restart the repo? I also prefer to track upstream's master branch; however, persist.el is part of the GNU ELPA mondo-repo, which contains many other packages, and our team uses one repo per source package. > - Lintian also had two nitpicks, see below. I'm guilty of the "wrong" > section myself for elpa-editorconfig. What is the teams stand on this? > I've discussed similar issues with the team before, and the consensus is that it's not worth the trouble of a section change. Having filed a couple of section change requests in the past, an ftpmaster sometimes moved them to weird/generic sections...eg: I requested a move for Elpy (Python IDE) to Development from either Lisp or Editors, and they moved it to Text... Dh-make-elpa also used to use section "lisp" but now uses section "editors", and this is also a case where where "editors" seems to be team-endorsed (via dh-make-elpa), and I think the team consensus is that lintian's claim is wrong. IIRC the "info" severity is a compromise between our team and whoever believes all packages that are implemented in lisp should be in section lisp... When it was a warning I filed a bunch of section change requests (editors-to->lisp) that ftpmasters didn't seem to appreciate. That said, upon further consideration I agree that "lisp" might have been the most appropriate section, because persist.el has no interactive functions and is thus more of a library than an editor. If there's a way to attach a note to the ftpmaster review, then let's do that! I'm of course happy to happy to correct the package's classification in control so that it matches the archive. > I: persist-el source: public-upstream-key-not-minimal > upstream/signing-key.asc has 1 extra signature(s) for keyid 066DAFCB81E42C40 > > N: > > > N: The package contains a public upstream signing key with extra > > > N: signatures. The signatures are unnecessary and take up space in the > > > N: archive. > > > N: > > > N: Please export the upstream key again with the command: > > > N: > > > N: $ gpg --armor --export --export-options export-minimal,export-clean > > > N: > > > N: and use that key instead of the key currently in the source package. > > > N: > > > N: Refer to the uscan(1) manual page for details. > > > N: > > > N: Severity: info > > > N: > > > N: Check: debian/upstream/signing-key > > > N: It was PITA to get a copy of the GNU ELPA key, and to get it to work properly...specifically I remember something odd about how they configured identities. IIRC I tested a minimised key and it didn't work properly. Also, IIRC, the last time their key expired they did something like changing the subkey instead of renewing it, and I think the reason for the extra signature might be related to that, so I'd like to keep the key as-is for now. With enough GNU ELPA packages it might be also be worth documenting or scripting away the toil. Thank you for taking the time to review and sponsor! Regards, Nicholas
signature.asc
Description: PGP signature
