[buildd-tools-devel] Bug#834330: Bug#834330: says failed to import public key while it tried to import a private one

Johannes Schauer josch at debian.org
Mon Aug 15 10:32:24 UTC 2016


Control: tag -1 + pending

Hi,

Quoting Marc Haber (2016-08-14 16:11:14)
> line 1235 in ResolverBase.pm gives the error message "Failed to import
> public key". This line, however, covers errors importing a _private_
> key. This is most probably a copy-and-paste error.

it probably is. Fixed in git. Thanks!

> While we are in this line at the first place, is it possible that this
> sbuild only works once and fails every following time because the
> private key is already there, gpg --import thus returning 2 and not 0?
> 
> I have only seen this behavior when sbuild is being called from
> mini-buildd, so this can be a mini-buildd issue. Does standalone
> sbuild start over from an empty keyring every time?

Yes. Sbuild creates a new $GNUPGHOME environment in /build/resolver-XXXXXX/gpg
for every package build. The directory is created by mktemp so the XXXXXX part
is random. This directory gets removed after every package build.

I would be interested to know how you convince sbuild to not do this. I don't
see that in the code right now.

You can file another bug for that issue.

Also, do you require signing of the internal dummy repository in the first
place? If not, you can just delete /var/lib/sbuild/apt-keys and then sbuild
will stop trying to sign the internal repository. Having it signed is only
necessary for apt versions in squeeze or older. Since wheezy, apt supports the
[trusted=yes] option in its sources.list.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160815/d20effd6/attachment.sig>


More information about the Buildd-tools-devel mailing list