[git-buildpackage] Would it be possible for pristine-tar to not be an absolute path?
nish.aravamudan at canonical.com
Wed Aug 30 22:49:57 CEST 2017
On 30.08.2017 [21:47:08 +0200], Guido Günther wrote:
> On Wed, Aug 30, 2017 at 10:18:10AM -0700, Nish Aravamudan wrote:
> > On 30.08.2017 [19:02:20 +0200], Guido Günther wrote:
> > > Hi,
> > > On Wed, Aug 30, 2017 at 09:37:28AM -0700, Nish Aravamudan wrote:
> > > > Hello,
> > > >
> > > > I am currently using gbp in a snap for `git-ubuntu`, a tool similar to
> > > > dgit for doing Ubuntu source package work. The snap contains all its
> > >
> > > Can you point me to the snap?
> > Yep; I interpreted your statement in three different ways :)
> > 1) To install the snap:
> > sudo snap install git-ubuntu --classic
> > 2) Source:
> > https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master
> That's the one I was after. Thanks a lot! Looking at the code it seems
> there's some overlap with things gbp implements.
Yep, for sure. And, tbh, I'd like to consolidate those out to be calls
to the cli or API if possible. Right now, our gbp direct calls are all
pristine-tar related and the importer, I believe, is outside the scope
of gbp (we could use gbp-import-dsc after downloading each dsc, but we
have relatively specific rules for parenting, etc.).
> Note that you can also do "import gbp" and call things directly from
> python if you prefer. The stuff outside scripts/ aims for a stable
This is a good point. I couldn't do that until the work I'm doing now to
use gbp from git, because git-buildpackage as packaged in Ubuntu only
is installed for python2.
> > The snap is automatically built from master currently.
> > 3) The error we get (without pristine-tar installed in the host, which
> > is what I'm trying to avoid requiring by putting it in the snap) is:
> > gbp:debug: /usr/bin/pristine-tar  ['commit', '/tmp/tmpk6ru7ya5/.git/git-ubuntu-cache/virt-manager_0.5.4.orig.tar.gz', 'c0a614c62bad2d63e671ff3c1ae853380e952cab']
> > gbp:error: Import of /tmp/tmpk6ru7ya5/.git/git-ubuntu-cache/virt-manager_0.5.4.orig.tar.gz failed: Couldn't commit to 'pristine-tar' with upstream 'c0a614c62bad2d63e671ff3c1ae853380e952cab': execution failed: [Errno 2] No such file or directory
> > ...
> > The host doesn't have pristine-tar, but it is available at:
> > /snap/git-ubuntu/current/usr/bin/pristine-tar.
> > The former ends up in snaps as $SNAP and we have a wrapper around our
> > commands that ensures $SNAP/usr/bin (and a bunch of other common paths)
> > are in $PATH.
> > To be clear, we only use gbp for orig tarball handling currently (we
> > import-orig the tarballs published for Debian & Ubuntu, and use
> > buildpackage (eventually export-orig, once it's available) to get the
> > tarballs back out).
> gbp export-orig is already in the versions in experimental. It will gain
> some more features in the near future (like checking out arbitrary
> versions without having a working copy).
Nice, that's good to know. It's a bit tricky with the Launchpad snap
builders to point to repositories outside of Ubuntu, which is what I
meant above. Now that I'm building from git, though, I can switch to
using master (or once the experimental version goes to unstable,
whatever version that gets tagged as) and it'll get pulled into our snap
directly, instead of relying on the version packaged in 17.10.
Unlike other snapped applications, I'm really trying to avoid rebuilding
core stuff (like dpkg itself) and am using packages in our snap.
> > > > dependencies, including pristine-tar at paths within the snap (which I
> > > > ensure are in PATH when my tool runs), but gbp has a hard-coded path
> > > > to pristine-tar:
> > > >
> > > > gbp/pkg/pristinetar.py:
> > > > ...
> > > > class PristineTar(Command):
> > > > """The pristine-tar branch in a git repository"""
> > > > cmd = '/usr/bin/pristine-tar'
> > > >
> > > > Is that strictly necessary for the way Command works? Would it be
> > > > possible to allow the cli (since it may not be override-able
> > > > otherwise) to specify where pristine-tar lives rather than it being
> > > > hardcoded?
> > >
> > > Is pristine-tar in your $PATH? As with subprocess when not going through
> > > a shell we need an absolute path. I'm happy to add logic to check in
> > > $PATH or different locations but I rather understand the problem first.
> > > (I'd be great if we wouldn't need even more cli options).
> > Yeah, pristine-tar is in $PATH (within the context of the snap wrapper
> > scripts, which are the only entry points to our programs anyways).
> > I see what you're saying, since we aren't using a shell, we don't have a
> > PATH to resolve?
> Exactly. I've pushed a patch that checks $PATH, this also helps when
> testing unreleased pristine-tar versions.
Excellent, thanks, I'll test with that!
More information about the git-buildpackage