On Thu, Dec 13, 2012 at 11:38:21AM +0100, Csillag Tamas wrote: > On Thu, Dec 13, 2012 at 10:45:05AM +0100, Guido Günther wrote: > > On Thu, Dec 13, 2012 at 09:31:41AM +0100, Csillag Tamas wrote: > > > On Thu, Dec 13, 2012 at 09:26:02AM +0100, gregor herrmann wrote: > > > > On Thu, 13 Dec 2012 09:03:07 +0100, Csillag Tamas wrote: > > > > > On Wed, Dec 12, 2012 at 05:30:27PM +0100, gregor herrmann wrote: > > > > > > On Wed, 12 Dec 2012 16:17:15 +0100, Guido Günther wrote: > > > > > ... > > > > > > The problem is still that the name of the new tarball is only > > > > > > reported as a message by uscan which is not parsed by > > > > > > /usr/share/pyshared/gbp/deb/uscan.py if I'm reading ot correctly. > > > > > My previous patch works happily with the version in wheezy (and you > > > > > are right > > > > > that I should have worked on the newest available version in the > > > > > first place.) > > > > > > > > Oh, just to clarify: My test was without your patch, just with the > > > > current gbp installed, as an answer to Guido's "shouldn't this work > > > > already?" > > > > > > Okay just the patched version results in a much easier workflow and it > > > solves > > > the problem for me so I will try to gently push it forward ;-) > > > > That's fine. I just wonder if it wouldn't be even better to enhance > > uscan to put out the name of the repacked tarball in a different xml > > element and slurp this in git-buildpackage then? This would be much more > > robust. Would you feel comfortable in enhancing uscan that way? > > I was thinking about this. I am not sure if it makes sense to expose this > information there. > > If this kind of information can be useful elsewhere (not just for > git-buildpackage) then IMHO uscan should be enhanced too. > But not so sure if only git-buildpackage uses this info (or not). > > I looked into uscan (it is a perl script ;-) and if we want to improve it to > know about repack then repack should be made a special command in the watch > file. > As currently repack uses a common command execution uscan cannot handle it any > special as it cannot know for sure if it is a repack script or anything else. Doesn't that imply that we can't detect the output filename reliably?
> > If you agree that it should be done this way (as you can read in the paragraph > above) I am happy to work on uscan then the patch for git-buildpackage can be > better. I think extending uscan is the only sensible way to go. Scraping command output is way to fragile. So if you can handle the uscan side I'd be happy to handle the gbp side ;) Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
