[buildd-tools-devel] Bug#606278: Bug#606278: aptitude resolver is completely broken in 0.60.6

[Roger Leigh]

On Wed, Dec 08, 2010 at 02:47:14AM +0200, Modestas Vainius wrote:
> Hello,
> 
> On trečiadienis 08 Gruodis 2010 01:58:13 Roger Leigh wrote:
> > On Wed, Dec 08, 2010 at 01:38:26AM +0200, Modestas Vainius wrote:
> > > aptitude resolver no longer works in 0.60.6. I suppose it has become
> > > pretty important because it's the only which supports experimental
> > > properly. See sample build log below.
> > > 
> > > dpkg-deb: failed to open package info file
> > > `/tmp/resolver-nGygHK/sbuild-build-depends-core-dummy/DEBIAN/control'
> > > for reading: No such file or directory Dummy package creation failed
> > > Core source dependencies not satisfied; skippingNot cleaning session:
> > > cloned chroot in use Keeping session:
> > > debian-experimental-amd64-sbuild-5b96bbf9-3747-4053-8607-bdb68178e9e7
> > 
> > This is odd.  It's working fine on my system, so I wonder what's
> > different?
> > 
> > It's clearly failing when trying to create the dummy dependency
> > package.  What is the content of /tmp/resolver-nGygHK ?
> 
> /tmp/resolver-* is created on my system, but 'dpkg-deb', '--build' is run 
> inside chroot session. So I guess I have to bind mount /tmp since 0.60.6 or is 
> this unintentional?

Totally unintentional.  I'll fix it to use a path inside the chroot,
and this should be fixed.  I do bind mount /tmp on my system; I'll stop
doing that in the future.

> When I bind-mounted /tmp, it went a bit further but now it failed with:
> 
> dpkg-deb: building package `sbuild-build-depends-core-dummy' in 
> `/tmp/resolver-D4hCcH/apt_archive/sbuild-build-depends-core-dummy.deb'.
> gpg: no default secret key: secret key not available
> gpg: signing failed: secret key not available
> Failed to sign dummy archive Release file.
> Core source dependencies not satisfied; skippingNot cleaning session: cloned 
> chroot in use
> 
> I guess now it wants a key. I spotted `sbuild-update --keygen` in the 
> changelog and used it. Now it went much further but failed to pick up required 
> build-deps from experimental (attached). Please note that sbuild 0.60.5 was 
> fine with this phonon-backend-vlc dsc (get it from incoming).

The key should have been autogenerated if you didn't run sbuild-update
--keygen.  I'll take a look into that as well.

> This means that my setup might need even more changes now. Well, sigh. It begs 
> the question why it has to be so complicated?

The main reason is so that apt-get and aptitude can install the
dependency package directly from an archive.  The existing practice of
breaking the system by forcing installation of the package and then
getting the package manager to fix up the breakage wasn't that nice.
This is cleaner and more robust.

Your comment about the entropy is valid.  However, this only needs doing
once ever, and you can then use the same key for all builds.  You can
even generate it on another machine if you wish.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101208/c9c4b9aa/attachment.pgp>