[buildd-tools-devel] Bug#604268: Bug#604268: QEMU linux-user support

[Roger Leigh]

On Sun, Nov 21, 2010 at 06:55:23PM +0100, Loïc Minier wrote:
>  I wrote a setup.d snippet which once dropped into
>  /etc/schroot/setup.d/11qemu will arrange for a static qemu linux-user
>  to be copied into the chroot on setup.  These are provided for many
>  architectures in the qemu-user-static (Debian) or qemu-kvm-extras
>  (Ubuntu) packages.
[...]
>  I'm attaching the setup.d wrapper; I've used it successfully to start
>  sessions in an armel chroot and with sbuild:
>     sbuild -d natty --arch armel hello_2.6-1.dsc
> 
>  I just downloaded my chroot from Launchpad as I explained in
>  Debian #602571, but "qemu-debootstrap" is a debootstrap wrapper doing
>  pretty much the same thing which allows creating chroots for schroot
>  just as if you'd use debootstrap.  I named my schroot config entry
>  "natty-armel" for the above to be picked up.

This is really cool stuff.  I'll be happy to include it in schroot.
Just a couple of issues with it:

1) It's not checking if $system_arch == $chroot_arch for all
   arches, just a limited hardcoded set; it should probably
   exit 0 if the above condition is true before looking for
   specific pairings.

2) The licence is not the same as the schroot packages, which is
   GPLv3+.  Would it be OK to have this licenced at GPLv2+ or 3+
   for compatibility with the rest of the package?

3) It would be nice to have a configuration in the script-config
   file to disable support completely, enable it unconditionally,
   or enable for selected architectures as at present.

Since we're frozen at the moment, I can't really include it just
now in a release, but it can certainly go into git for the next
release.

> # TODO
> # - allow setting the qemu interpreter in the script-config file
> # - allow forcing use of qemu even when not particularly needed
> # - test support for all architectures
> # - add support for more architectures

Setting in script-config will require writing a chroot facet object,
which is something I'd really like to see support for.  I'm
especially interested in support for kvm and qemu-kvm and qemu, so
these would all fit under the same umbrella.

Currently, we do require that the guest is a chrooted filesystem,
but I'd like to abstract that to allow running commands in entirely
isolated virtual systems such as kvm.


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/20101121/6da21d38/attachment.pgp>