On Thu, Mar 26, 2015 at 02=38=55PM +0100, Juan Quintela wrote:
> Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote:
> > Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
> > is now removed. It's supposed to work on armv7l as well.
> >
> > Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
> >
> > Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com>
> 
> This prevent compliation on x86_64 on Fedora 21.
> 
> (migration/next)$ make -j5 -C /scratch/tmp/next/all/
> make: Entering directory '/scratch/tmp/next/all'
> config-host.mak is out-of-date, running configure
> 
> ERROR: User requested feature libseccomp
>        configure was not able to find it.
>        Install libseccomp devel >= 2.2.0
> 
> Makefile:30: recipe for target 'config-host.mak' failed
> make: *** [config-host.mak] Error 1
> make: Leaving directory '/scratch/tmp/next/all'
> (migration/next)$ rpm -qa | grep seccomp
> libseccomp-2.1.1-5.fc21.x86_64
> libseccomp-devel-2.1.1-5.fc21.x86_64
> libseccomp-debuginfo-2.1.1-5.fc21.x86_64
> (migration/next)$ 
> 
> This was compiling correctly until this patch got in.  And virt-test
> uses seccomp by default.
> 
> Fedora 21 is less than 3 months old.  Do we really want to avoid
> compilation there?

Hello Juan,

I completely understand your concern. Perhaps a ping on libseccomp
Fedora package maintainer would be a better way to tackle this issue
instead of reverting this commit. Libseccomp 2.2.0 is released since Feb
12th and I actually gave it a little time frame for other distros to
update their packages so we don't run into issues like this.

It's important to remember that this patch is also the proper fix for
this bug: https://bugs.launchpad.net/qemu/+bug/1363641

Regards,

-- 
Eduardo Otubo
ProfitBricks GmbH