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

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: