[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#829151: RFS: setcolortemperature/1.1-1 ITP



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".

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.

> > 
> > 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.

> > 
> > 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 :)

> > 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.

> > 7. The language in d/copyright ("I doubt if it's copyrightable"
> > etc.)  isn't appropriate.  You need to determine whether or not it
> > is copyrightable and make a clear statement of that.
> 
> That wording is not mine, but written by Ingo Thies, who would have
> copyright over the whitepoints data if it is copyrightable. Putting it
> there was the advice I got from debian-legal (see below).

Thanks for the link to the debian-legal thread.  That was useful for me
to read.  I think you are good if you re-organise the Copyright: for
sct.c as suggested above.

> > 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.

-- 
Sean Whitton


Reply to: