On 07/05/2016 07:46 PM, Sean Whitton wrote: > Hello Peter and Jacob, > > On Tue, Jul 05, 2016 at 11:19:55PM +0300, Peter Pentchev wrote: >> Actually I don't see a problem with the machine-readable copyright >> specification here; if you're referring to the fact that the contents >> of the "Copyright" field is not in the usual "list of <year> <author>" >> format, this is perfectly fine: the Copyright field is free-form text as >> described in: >> >> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field >> >> It is true that the examples in the copyright-format specification also >> follow the "list of <year> <author>" format, but it is not codified in >> the text. > > You're right -- thanks for your input. I was wrong to say that it > doesn't satisfy DEP-5. However, I still think that the text could be > more clearly laid out so the division of sct.c is obvious. You could > write something like "remainder of C code copyright Ted Unangst". I've phrased it that way for now. Not sure I'm a huge fan of that wording, but I can't think of anything else that doesn't lose clarity. (I tried "everything else copyright..." but that seems too vague) > > On Tue, Jul 05, 2016 at 04:51:51PM -0400, Jacob Adams wrote: >>> 1. Could you explain why you are packaging your fork rather then the >>> original? (This kind of thing should go in the ITP.) >> >> The original was released in a blog post as a sort of code dump >> (http://www.tedunangst.com/flak/post/sct-set-color-temperature ) >> I thought it would improve long term maintainability if there was a real >> build system and active upstream. It's pretty hard to package software >> without a tarball or VCS. If this is discouraged, I'd be happy to email >> the real upstream about it, but I simply thought this would be easier >> for everyone. >> If I need to send a mail explaining this to the ITP I can do that. > > This is perfectly reasonable :) It would be good to append it to the ITP > in case anyone else is wondering. Done. > >>> >>> 2. Could you put your Debian packaging in git, please? It makes >>> reviewing easier. Perhaps as a 'debian' branch of your repo. >> >> Whoops. Actually I already do this in a different git repo and I just >> filled out the relevant fields of d/control incorrectly. Thanks for >> catching that! > > Great. Since you are the upstream maintainer and the (prospective) > Debian package maintainer, is there any reason you're using two seprate > git repos? You could just add a debian/ directory to your main repo. > > What you are doing is completely acceptable (and there are some Debian > Developers who think that that is the way it should be done) but as > someone who is the upstream maintainer and Debian maintainer (of > git-remote-gcrypt), I find it a lot easier just to have one repo. Or > you can have a debian branch containing the debian/ subdir and you can > merge master into that branch periodically. I separated the two because that's what the upstream guide in the debian wiki recommends. I can see the benefits of having it all in the same repo but for this package I think I will keep them separate for now. I might try the combined approach later if the separated one becomes too much of a burden. > >>> >>> 3. The formatting of the long description in debian/control is a bit >>> strange. Please separate paragraphs using a line with the string " >>> .". Probably best to wrap at 70 chars, too. >> >> I think I fixed this now. > > Sorry for the pedantry but you're missing a period at the end of line 19 :) Fixed. > >>> 4. The wording of the long description could be improved. The first >>> sentence isn't really a sentence -- it would be better to write "sct >>> is a small C program to change the screen color temperature. It can >>> be used to reduce or increase the amount of blue light produced by >>> the screen." Please take another look at your wording :) >> >> Wow that description was a mess. I've fixed it up now and I think it's >> much clearer. > > I agree. Good job. > >>> >>> 6. 'sct' is a very short command name for /usr/bin ... have you >>> confirmed that it doesn't clash with any other packages in Debian? >>> You might have to set the priority to 'extra'. >> >> Is there any way to check if other packages have binaries called sct? A >> quick search of packages.d.o would seem to indicate there is not but is >> there a better way to check? > > There are several different ways, but the most convenient is probably > the apt-file(1) tool. That's pretty useful thanks! According to apt-file there are no conflicts with /usr/bin/sct >>> 10. You're missing at least one build dependency. Please try building >>> in a clean sid chroot (see the pbuilder or sbuild tools). >> >> Yep. Was missing libx11-dev and libxrandr-dev (dpkg -S is the best :) ). >> I've fixed it now. Thanks for finding that. > > It builds now, and I also confirmed that it installs and works. > Thanks for all your help! -- Jacob Adams GPG Key: AF6B 1C26 E2D0 A988 432B 94F4 24C0 2B85 B59F E5A9
Attachment:
signature.asc
Description: OpenPGP digital signature