On Mon 2015-11-16 14:38:04 -0500, Guido Günther wrote:
> I'm sorry for being ignorant here but how exactly does this work? gpg
> looks for a running agent to see if the key is already unlocked, if not
> gpg-agent calls out for the pinentry, which then needs a D-Bus session
> bus?

it's rather complicated.  Below is the workflow for "modern" GnuPG
(2.1.x and higher) under GNOME 3:

 0) gpg looks for a running gpg-agent.

 1) if the agent doesn't exist, gpg starts one.

 2) gpg now asks the agent for the use of a secret key

 3) the agent checks if the key is already unlocked.

 4) If the key is not unlocked, gpg-agent spawns a pinentry.

 5) it spawns /usr/bin/pinentry by default, which is governed by

 6) pinentry is responsible for showing a prompt to the user.

 7) if /usr/bin/pinentry points to pinentry-gnome3, then it uses gcr
 (the gnome crypto toolkit) to do the prompting.

 8) gcr works by the running process communicating over dbus, using
 DBUS_SESSION_BUS_ADDRESS to find the correct unix-domain socket for 

> This is during the "normal" build process? What builder are you using,
> what does
>     gbp config buildpackage.builder
>     gbp config buildpackage.pbuilder
> show? I assume s.th. like:
>     $ gbp config buildpackage.builder
>     buildpackage.builder=dpkg-buildpackage
>     $ gbp config buildpackage.pbuilder
>     buildpackage.pbuilder=False


buildpackage.builder is the empty string, but

> If so, can you try to set the builder to a command that just dumps the
> environment into a file like:
>     gbp buildpackage --git-builder='printenv > /tmp/foo' --git-no-pbuilder
> and check if it has all the needed environment variables? If I do this I
> do find DBUS_SESSION_BUS_ADDRESS in there as well as several gpg related
> ones (like GPG_AGENT_INFO) and looking at the code we don't clear the
> env, we either extend it or leave it untouched (by passing None).

yes, i see DBUS_SESSION_BUS_ADDRESS in there too.  hmmmm.

> So are we sure it's environment variable related or maybe something else?
> Another possibility would be to use
>     strace -f -o /tmp/bla.log -s2048 dpkg-buildpackage
> as builder so we can maybe figure what's going wrong (i.e. if it's not
> possible to open the dbus socket)?

huh, this actually worked to build the package just fine.

But it helped me to narrow things down!  it looks like
--git-builder=debuild is what's causing the stripping, and when
buildpackage.builder is the empty string and debuild is available in the
$PATH, it prefers debuild to dpkg-buildpackage (which is probably

I'll go hassle the debuild folks now :)

Thanks for helping me debug,

git-buildpackage mailing list

Reply via email to