guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/5] gnu: qemu: Enable spice support.


From: Mark H Weaver
Subject: Re: [PATCH 3/5] gnu: qemu: Enable spice support.
Date: Sat, 06 Aug 2016 12:07:58 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hi David,

David Craven <address@hidden> writes:

>> Unfortunately, 'spice' only builds successfully on x86_64, so with this
>> patch, i686 and armhf lose 'qemu'.
>
> 'usbredir' is needed by 'spice-gtk' which is only needed to run the tests
> for spice. This can be fixed by removing the automated tests configure-flag
> and removing spice-gtk from the dependencies on i686.

I would prefer to fix 'usbredir' on i686.  The same error occurs on all
non-x86_64 systems, so if you can fix it on i686, there's a good chance
it will work on mips64el and armhf as well.  Hydra will check that.

In any case, i686 is the most important for now.  You can see the failed
build log via this link:

  https://hydra.gnu.org/job/gnu/master/usbredir-0.7.1.i686-linux

Here's the relevant excerpt:

--8<---------------cut here---------------start------------->8---
  CC       libusbredirhost_la-usbredirhost.lo
usbredirhost.c: In function ‘usbredirhost_can_write_iso_package’:
usbredirhost.c:1023:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format=]
             DEBUG("START dropping isoc packets %lu buffer > %lu hi threshold",
             ^
usbredirhost.c:1023:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
usbredirhost.c:1028:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format=]
             DEBUG("STOP dropping isoc packets %lu buffer < %lu low threshold",
             ^
usbredirhost.c:1028:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
usbredirhost.c: In function ‘usbredirhost_set_iso_threshold’:
usbredirhost.c:1162:5: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format=]
     DEBUG("higher threshold is %lu bytes | lower threshold is %lu bytes",
     ^
usbredirhost.c:1162:5: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
cc1: all warnings being treated as errors
--8<---------------cut here---------------end--------------->8---

> If supported-systems is set correctly, will guix try to build without
> the required package?

No.  A package is considered "unsupported" on a given architecture if
any of its transitive inputs are unsupported there.  See
'package-transitive-supported-systems' and 'supported-package?'
in guix/packages.scm.

> Trying to build with guix build --system=armhf-linux tells me that I'm
> x86-64-linux and the same for --system=mipsel-linux. It would be
> nice if guix build would spin up a qemu instance in this case.

I agree that would be very nice, but no one has implemented it yet.

> Before reinventing the wheel or deploying my own hydra build farm
> (or cuirass), is there a simple way to build a package for all supported
> platforms?

No, it currently requires having access to a system of the desired
architecture running Guix.  If you have this, then you can arrange for
builds to be automatically "offloaded" to that machine as needed.  See
section 2.4.2 (Using the Offload Facility) in the Guix manual for
details.

Note that if GuixSD included support for mips64el or armhf running qemu,
then you could use "guix system vm" to create a virtual system of the
desired system, and then configure Guix to offload builds to it, and
this could be automated.  However, at present, you'd need to install a
different distro within qemu, install Guix within it, and then set up
offloading manually.

Anyway, it is always possible to build for i686 on an x86_64 system
without offloading, and fortunately that should be sufficient to make
progress on this issue.

> It looks like guix ignores the supported-systems property and
> doesn't make use of it anywhere.

It's used to determine which build jobs are attempted on Hydra, affects
the output of "guix package --list-available", and maybe a few other
things.

> Say it doesn't prevent building a package on i686-linux when only
> x86_64-linux is in the list.

Yes, Guix will attempt a build if you ask it to, even if the package is
listed as unsupported on your system.

Thanks for your efforts!

     Regards,
       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]