Hi Guido,
On Wed, Dec 12, 2012 at 04:17:15PM +0100, Guido Günther wrote:
> Hi cstamas,
> On Wed, Dec 12, 2012 at 01:05:31AM +0100, Csillag Tamas wrote:
> > Hi,
> >
> > I think I have a patch. :)
> >
> > it is against git-buildpackage 0.6.0~git20120601
> >
> > ------------------------------------------------
> > --- /usr/lib/python2.6/dist-packages/gbp/deb/__init__.py-backup 2012-12-12
> > 00:39:50.722558020 +0100
> > +++ /usr/lib/python2.6/dist-packages/gbp/deb/__init__.py 2012-12-12
> > 00:48:29.630557999 +0100
> > @@ -290,6 +290,12 @@
> > print source
> > if not os.path.exists(source):
> > source = None
> > + # perl repack support #635920
> > + for row in out.split("\n"):
> > + m = re.match(r"\*\*\* ([^\s]+) ready", row)
> > + if m:
> > + source = "%s" % m.group(1)
> > + break
> > return (True, source)
> > ------------------------------------------------
> >
> > I can be wrong as it starts to become late here, but this seems to be a
> > possible way to solve the issue.
> > What do you think?
>
> Thanks for your patch. Is this still an issue with current git? We're
> parsing the upstream tarballs name hopefully correctly now. Could you
> check and if not pass along a testcase?
The issue is that when a repack script
(http://pkg-perl.alioth.debian.org/howto/repacking.html#5__package_upgrades)
that the Debian Perl team uses is being run it actually creates a new tarball.
uscan itself is unaware of the fact and the end result is that gbp uses
(commits with pristine-tar) the original non dfsg free upstream package.
My change above handles this issue as parsing the output of the script (which
is in one of the message blocks).
I can confirm that 0.6.0~git20121124 still has this bug.
To reproduce:
gbp-clone --all --pristine-tar
git://anonscm.debian.org/pkg-perl/packages/libmojolicious-perl.git
cd libmojolicious-perl
git-import-orig --uscan
Regards,
cstamas
--
CSILLAG Tamas (cstamas) - http://cstamas.hu/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
