Hi Benoît, On Sat, Jul 23, 2011 at 01:39:11AM +0200, Benoît Knecht wrote: > Kilian Krause wrote: > > > > On Fri, Jul 22, 2011 at 12:36:51PM +0200, Benoît Knecht wrote: > > > I am looking for a sponsor for the new version 1.0.21+dfsg-1 of my > > > package "minidlna". > > > - dget > > > http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.21+dfsg-1.dsc > > > > 1. Your upoad uses a tarball that's not identical to upstream's one. Please > > consider adding a get-orig-tarball target to debian/rules to verify what > > steps are required to generate it. > > Yes, that's what the +dfsg in the upstream version is all about; I've > replaced the icons.c file, which contained binary blobs of possibly > unfree images. I've included a script to generate it, but not a > get-orig-source yet, as I'm not sure how to achieve the "this target may > be invoked in any directory" part of the policy. Any advices welcome.
I'd either put a "dh_testdir" check in place if you don't want to make sure you can pull in the new file with `dirname $0` or just use the latter to make sure you refrence the same directory your rules file is in and build the new tarball in /tmp and then move it to the current working directory as per Debian Policy. > > 2. The 1.0.20+dfsg-2 never made it into Debian. Changes generated > > accordingly. Please double check next time. > > I'm not sure what you mean. I did some changes before 1.0.21 was > released and checked them into git; the next version came before I had a > chance to submit that one, so I added a new changelog entry and recorded > further changes there. I actually prefer this to merging the changelog > entries together, but maybe I should have tagged the previous version as > UNRELEASED. Yes, that would have been better. You had put up a version on mentors.d.n which had a 1.0.20+dfsg-2 entry labelled as if it was uploaded to unstable yet the dak doesn't show any such version ever made it. Thus I've made it a cumulative upload with "dpkg-buildpackage -v1.0.20+dfsg-1" covering both entries as opposed to only the newest one which would be the default. > > 3. Your patches don't use DEP-3 headers. It would be nice to have them to > > see which of those have already been pushed upstream etc.. > > I'll consider it, but right now I'm using the format generated by > git-format-patch, which I find quite convenient. As said, there's nothing wrong with what you have. No offense intended. It was just a remark that there's DEP-3 out there and may come in handy but if you already use git-format-patch that's fine, too! -- Best regards, Kilian
signature.asc
Description: Digital signature
