[buildd-tools-devel] Bug#843137: Bug#843137: Bug#843137: sbuild: fails to deal with sid chroots (missing gpg)

[Johannes Schauer]

Hi KiBi & Raphaël,

Quoting Cyril Brulebois (2016-11-04 08:29:06)
> Raphael Hertzog <hertzog at debian.org> (2016-11-04):
> > On Fri, 04 Nov 2016, Cyril Brulebois wrote:
> > > a brand new unstable chroot isn't usable for a build with default (as
> > > far as I can remember) sbuild configuration. Full log follows:
> > 
> > It's not a "default" sbuild configuration, it's one where you created
> > a signing key.
> 
> Pretty sure that doesn't make it a non-default configuration. That was
> even advertised in changelog:
> | sbuild (0.62.0-1) unstable; urgency=low
> | […]
> |   * sbuild:
> |     - Resolvers:
> |       + 'apt' is now the default build dependency resolver.  Users should
> |         not see any significant changes compared with the old 'internal'
> |         resolver.  Please note that you may need to generate a GPG key
> |         for the local archive created for dependency package
> |         installation, if one does not already exist; see sbuild-update
> |         (--keygen) for further details.
> | […]
> |  -- Roger Leigh <rleigh at debian.org>  Wed, 16 Mar 2011 16:10:31 +0000

Yes, until sbuild 0.67.0 it was strictly *required* to generate a
public/private keypair using "sbuild-update --keygen". There was no way around
this.

> I think it was even mandatory on new installs in the past, which Helmut seems
> to agree with in this message:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801798#10
> 
> (I seem to vaguely recall some versions trying to generate the key upon
> install which didn't work on all systems due to possible lack of
> entropy.)

Versions of apt before 0.8.16~exp3 do not support the [trusted=yes] option. But
they will also silently ignore it if it's present in the sources.list. Thus,
current sbuild in unstable unconditionally puts [trusted=yes] into its
sources.list.

> > Get rid of /var/lib/sbuild/apt-keys and it should work (at least on a
> > recent sbuild, I saw you reported it on an old version, not sure if that
> > version already has the fallback mentioned below).

sbuild in Jessie doesn't have this fallback (yet). To get it working today,
you'd have to use the version in jessie-backports to get this feature.

> > When a key is present there, sbuild wants to use it to sign the internal
> > repository and then your chroot needs to have gpg installed (and unstable
> > chroot no longer have it since apt dropped the dependency).
> 
> I don't have any internal repository in this chroot anyway.

Yes you do. Sbuild will turn the source package Build-Depends into a dummy
binary package which it puts into an internal dummy repository and hands that
one over to apt. So in the end apt is asked to install a dummy binary package
from a temporary internal repository.

In the future, we want to get rid of this way of installing build dependencies
but that will only be possible once apt with the functionality to install build
dependencies from .dsc files (>= 1.1~exp1) is in old-stable. So it will take
several more releases until we can do this.

> > That said, it would be nice if sbuild was smarter, it could check gpg's
> > availability before deciding to sign the repository and then fallback to
> > using the "[trusted=yes]" sources.list attribute instead.
> 
> sbuilds in stable needs to support building for unstable. With or without
> local repositories.

Patches are welcome. For anybody interested in implementing this, here are some
git commits which made sbuild cope with the whole gpg mess in unstable for
inspiration:

a8c4c1b179d48505dd05bbff33f3215b5a66df52
a5b75efc129330502cd9ed801fab33cba71bc160
2e7b4d9cc19aef82e0cede5e3640b8d8bec1826f
635097de980ad1ee39ff4edb8fe2a78c25a5a092
5ebb63bce633f00b27e0addedf5a96ce2c7a7a09
f957dae1b80aad33795cb312da73266e1b48fe9b
956fc29b2e297e20f1ab9a9ddb80ae8fa04c3370
ca66503b58ba8b46d98de4f25942670e010f4959
5cfa09c51a9167c8748330ba40206ec468fc8b47

And some of the relevant bugs giving an overview of all the problems that would
have to be fixed for a successful stable update:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827315
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801798
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831462
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833547
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792100

Thanks!

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