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

Re: RFS: minidlna (updated package and FTBFS fix)

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

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,

Attachment: signature.asc
Description: Digital signature

Reply to: