Re: RFS: hashalot
* Adam Borowski <kilobyte@angband.pl>, 2011-07-26, 15:24:
I'd like to ask for a sponsor for an update to hashalot (a tool
needed by cryptsetup, obsolete nowadays but some folks still use it).
There's just one minor documentation fix, but I also nuked the whole
debian/rules replacing it with oh-so-long dh two liner.
Did you verify that your new d/rules does everything that the old one
did?
Yes, actually it does a bit more: the old one failed to install the
upstream changelog.
FWIW, that's because of bumping debheleper compat to 7.
I just checked that it cross-builds correctly too, dh is smart enough
to disable the testsuite on cross builds like the old d/rules did.
What raised my suspicion was that that the old d/rules had:
| ifneq "$(wildcard /usr/share/misc/config.sub)" ""
| cp -f /usr/share/misc/config.sub config.sub
| endif
| ifneq "$(wildcard /usr/share/misc/config.guess)" ""
| cp -f /usr/share/misc/config.guess config.guess
| endif
dh certainly doesn't do anything like that. Granted, this code was
silly[0] and, in this particular case, completely unnecessary[1], but
I'd prefer to learn about such changes from the changelog.
You bumped debian/compat, bumped standards version, added Homepage
field - none of these things are documented in the changelog.
I do believe that such entries are spam that is counterproductive and
hides real changes:
* debian/compat is implied by migrating to dh
Er, no. These are orthogonal things.
* updating standards is something every single sane sourceful upload
does (lintian screaming at people helps here)
Did upgrading to the latest version require any changes in packaging?
(I normally don't ask this question, as the answer is in the
changelog...)
* Homepage is just moving around stuff that used to be in
debian/copyright
This is actual improvement to your binary package; now I can type
"dhomepage hashalot" and the upstream homepage (or rather "homepage")
pops up.
Thus, I'd prefer to avoid useless entries.
I do insist that my sponsorees document all these little things, for
various reasons:
1) It makes life easier for me, because I don't have to judge if
something is "important enough" or not to document. It's also easier for
sponsorees, since they don't have to guess if I will be happy with
omitting a thing from d/changelog or not.
2) I try to teach my sponsorees to read debdiffs before requesting
sponsoring and I consider complete changelog a proof that the maintainer
actually did it. (My success in that area is limited so far; I often
find gaps, not so minor as in this particular case... but I'm not giving
up. :P)
3) I hate when changelog diverges from reality, which IME happens way to
often. For example, the last item in your changelog mentions S-V is
"Policy version 3.7.2 (no changes needed)", which has nothing to do with
what actually is in d/control.
4) There are other reasons, but I don't have time to write them out. :P
A few more things:
hashalot.c has inconsistent indentation: sometimes tabs and sometimes
spaces are used. At least one such inconsistency was introduced by
debian diff. (Of course, it's nothing important, just saying...)
Quoting DEP-5: "if [remaining lines of the License field are] left blank
here, the file must include a stand-alone License paragraph matching
each license short name listed on the first line (see the Standalone
License Paragraph section)." All but one of your files paragraph violate
this requirement.
I wonder about the license of sha512.* files. The comment inside them
says "Redistribution of this file is permitted under the GNU Public
License." Could you clarify with the copyright holder if he in fact
meant GNU *General* Public License?
[0] One should either update config.{sub,guess} unconditionally or not
all.
[1] The configure script doesn't use config.{sub,guess} at all, and
neither they are shipped in the upstream tarball.
--
Jakub Wilk
Reply to: