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

Help from Git-buildpackage experts wanted (Was: New upstream version of python-csb)

Hi Tomás,

On Fri, Dec 21, 2012 at 02:20:44PM +0100, Tomás Di Domenico wrote:
> So, I believe I've sorted this out. Seems like it was basically a
> problem with the naming of the tarball that was getting into
> pristine-tar. I've recreated the repo in order to avoid having all the
> previous mess in there, and it works for me now after getting a copy
> with debcheckout. Could you please see if it works also for you now?

Thanks for your effort into this.  I admit that frustratingly the
procedure seems to be fragile enough that there seem to be more pitfalls
than for a standard procedure should happen.  Due to your effort now at
least the error message has changed:

$ git-buildpackage
gbp:info: Orig tarball 'python-csb_1.1.1+dfsg.orig.tar.gz' not found at '../tarballs/'
tar: /tmp/pristine-tar.rpEhoamtcq/recreatetarball: Wrote only 8192 of 10240 bytes
tar: Error is not recoverable: exiting now
pristine-tar: command failed: tar cf /tmp/pristine-tar.rpEhoamtcq/recreatetarball --owner 0 --group 0 --numeric-owner -C /tmp/pristine-tar.rpEhoamtcq/workdir --no-recursion --mode 0644 --files-from /tmp/pristine-tar.rpEhoamtcq/manifest
pristine-tar: failed to generate tarball
gbp:error: Couldn't checkout "python-csb_1.1.1+dfsg.orig.tar.gz": /usr/bin/pristine-tar returned 2

I wonder whether there is somebody able to write a brain dead simple,
unbreakable robust procedure to avoid such problems which might become
demotivating to newcomers.  I have no idea what could be the source of
this new problem I can only say that I have a (felt, not measured)
ratio of about 20% Git repositories from sponsees that do not work out
of the box and I'm far from blaming the sponsees responsible for this
problem.  Moreover I somehow feel my hands bound because of hard to
debug hidden Git magic (at least from my perspective.)

I would love to file a bug report against git-buildpackage /
pristine-tar if I only would understand these various pitfalls that
might happen.  IMHO there should be at least some automatic test whether
the just imported tarball can be recreated or something like this.

Any idea how to help out Tomás specifically and how to make the
process more robust in general?

Tomás, I'd really like to upload before Christmas - if we do not manage
with git-buildpackage please send me your orig tarball and I will build
the package "the traditional way".  If I would recreate the '+dfsg'
tarball myself it will not feature the same md5sum and we would need
to recreate the repository again to get a clean pristine-tar in.  If
you want me to do this I could also do it and replace your repository.
I think you have now wasted enough time with this.

Kind regards and thanks again for your effort into this



Reply to: