On Tue, Sep 19, 2017 at 10:10 AM, Guido Günther <[email protected]> wrote: > Hi, > On Mon, Sep 18, 2017 at 11:24:21AM -0700, Nish Aravamudan wrote: >> On 30.08.2017 [21:47:08 +0200], Guido Günther wrote: >> > Hi, >> > 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. 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 API. >> > >> > > 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). >> > >> > > > > 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. >> >> Python question, as I ended up needing to do something very similar in >> our code to call out to LXD ;) >> >> https://git.sigxcpu.org/cgit/git-buildpackage/commit/?id=4c6f8fce0dd9b89947b6b123bf38e0568ce6d83c >> >> seems buggy in _find_in_path? >> >> Specifically >> >> for p in os.getenv("PATH", "/usr/bin:/bin"): >> >> should be >> >> for p in os.getenv("PATH", "/usr/bin:/bin").split(":"): >> >> otherwise p ends up iterating the characters in PATH? > > You are perfectly right! So I wondered why things worked at all after > the change and it turns out that python3 does a path lookup by itself: > > https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1257 > > so I could remove the complete path lookup code.
I was wondering the same thing! Thanks for digging into that. -Nish _______________________________________________ git-buildpackage mailing list [email protected] http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
