Uploaded (was: RFS: ripit (updated package))
+ Elimar Riesebieter (Fri, 17 Apr 2009 19:04:15 +0200):
> Dear mentors,
Hello, Elimar. (Elimar is one of our capable ALSA maintainers, by the
> I am looking for a sponsor for the new version 3.7.0~beta20090329-1
> of my package "ripit".
> It builds these binary packages:
> ripit - Textbased audio cd ripper
> The package appears to be lintian clean.
> The upload would fix these bugs: 490082, 501925, 517561, 518720
I’ve uploaded your package. I have the following comments, please
consider improving your package based on this feedback on the next
* Please only close bugs with a “New upstream version” message if
they’re actually a wishlist bug asking for the new version to be
packaged. In case they are actual bugs, please do something like:
* New upstream release:
+ does not prepend “fast” to the “insane” preset. (Closes: #501925)
+ copes with lame sending --genre-list output to stderr.
+ fixes genre parsin or whatever. (Closes: #517561)
I hope you’ll agree that’s more useful for the person reading the
changelog, and it only takes a bit more effort. No need to
retroactively edit the changelog, though.
* Any reason not to make build-stamp in debian/rules depend directly
on $(QUILT_STAMPFN), instead of an intermediate configure-stamp
which, in addition, does not get touch'ed?
* rm'ing .pc in clean is unnecessary: the “unpatch” target does it.
Additionally, .pc is a directory, so at the moment your clean target
is not failing because “unpatch” gets to run first and deletes .pc.
* You could add a space after “Homepage:”.
Thanks for your contribution to Debian!
P.S.: I’m well aware most sponsors would have done another round of
packages and waited for the above issues to be fixed. I myself prefer to
upload unless there are serious or unacceptable issues. This way, is my
belief, sponsorees are taught to be more careful, rather than
unconsciously think “Ok, I have a preliminary version, sponsor will
catch mistakes”. Which is a disaster once they gain upload rights. Also,
if there are serious or unacceptable mistakes, I usually try the
“You introduce a serious issue in the clean target of debian/rules,
please see if you can find it” route first.
- Are you sure we're good?
-- Rory and Lorelai