| Message ID | 1427279169-3213-2-git-send-email-eduardo.otubo@profitbricks.com |
|---|---|
| State | New |
| Headers | show |
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? Thanks, Juan. > --- > configure | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/configure b/configure > index 589798e..cbe6495 100755 > --- a/configure > +++ b/configure > @@ -1848,14 +1848,13 @@ fi > # libseccomp check > > if test "$seccomp" != "no" ; then > - if test "$cpu" = "i386" || test "$cpu" = "x86_64" && > - $pkg_config --atleast-version=2.1.1 libseccomp; then > + if $pkg_config --atleast-version=2.2.0 libseccomp; then > libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`" > QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`" > seccomp="yes" > else > if test "$seccomp" = "yes"; then > - feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1" > + feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0" > fi > seccomp="no" > fi
Juan Quintela <quintela@redhat.com> 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> Just in case anyone is interested, default virt-test output with current qemu 15:05:01 ERROR| Qemu output: 15:05:01 ERROR| qemu-system-x86_64: -sandbox on: sandboxing request but seccomp is not compiled into this build 15:05:01 ERROR| 15:05:01 ERROR| 15:05:01 ERROR| FAIL type_specific.io-github-autotest-qemu.migrate.default.tcp -> VMStartError: VM 'virt-tests-vm1' failed to start: Qemu is defunct. Qemu output: qemu-system-x86_64: -sandbox on: sandboxing request but seccomp is not compiled into this build Notice that you can "fix" the problem running with --qemu_sandbox=off, but breaking the main test suite just before release looks wrong? Later, Juan. > > 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? > > Thanks, Juan. > > >> --- >> configure | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/configure b/configure >> index 589798e..cbe6495 100755 >> --- a/configure >> +++ b/configure >> @@ -1848,14 +1848,13 @@ fi >> # libseccomp check >> >> if test "$seccomp" != "no" ; then >> - if test "$cpu" = "i386" || test "$cpu" = "x86_64" && >> - $pkg_config --atleast-version=2.1.1 libseccomp; then >> + if $pkg_config --atleast-version=2.2.0 libseccomp; then >> libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`" >> QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`" >> seccomp="yes" >> else >> if test "$seccomp" = "yes"; then >> - feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1" >> + feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0" >> fi >> seccomp="no" >> fi
On 26 March 2015 at 14:09, Juan Quintela <quintela@redhat.com> wrote: > Notice that you can "fix" the problem running with --qemu_sandbox=off, > but breaking the main test suite just before release looks wrong? The main test suite is "make check" :-) -- PMM
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,
On Thu, Mar 26, 2015 at 03=09=19PM +0100, Juan Quintela wrote: > Juan Quintela <quintela@redhat.com> 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> > > > Just in case anyone is interested, default virt-test output with current > qemu > > > 15:05:01 ERROR| Qemu output: > 15:05:01 ERROR| qemu-system-x86_64: -sandbox on: sandboxing request but seccomp > is not compiled into this build > 15:05:01 ERROR| > 15:05:01 ERROR| > 15:05:01 ERROR| FAIL type_specific.io-github-autotest-qemu.migrate.default.tcp -> VMStartError: VM 'virt-tests-vm1' failed to start: Qemu is defunct. > Qemu output: > qemu-system-x86_64: -sandbox on: sandboxing request but seccomp is not compiled into this build > > > > Notice that you can "fix" the problem running with --qemu_sandbox=off, > but breaking the main test suite just before release looks wrong? Is it possible to temporarely disable this feature in your testing environment while libseccomp is not updated? Regards, > > Later, Juan. > > > > > 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? > > > > Thanks, Juan. > > > > > >> --- > >> configure | 5 ++--- > >> 1 file changed, 2 insertions(+), 3 deletions(-) > >> > >> diff --git a/configure b/configure > >> index 589798e..cbe6495 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -1848,14 +1848,13 @@ fi > >> # libseccomp check > >> > >> if test "$seccomp" != "no" ; then > >> - if test "$cpu" = "i386" || test "$cpu" = "x86_64" && > >> - $pkg_config --atleast-version=2.1.1 libseccomp; then > >> + if $pkg_config --atleast-version=2.2.0 libseccomp; then > >> libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`" > >> QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`" > >> seccomp="yes" > >> else > >> if test "$seccomp" = "yes"; then > >> - feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1" > >> + feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0" > >> fi > >> seccomp="no" > >> fi
On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote: > 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. Well, we shouldn't really be mandating latest-and-greatest versions of our upstream dependencies unless the maintainer of those dependencies feels the earlier versions are so badly broken that it would be better to refuse to use them at all. > It's important to remember that this patch is also the proper fix for > this bug: https://bugs.launchpad.net/qemu/+bug/1363641 If that only applies to certain architectures we can make the dependency version vary depending on which arch we're building for, I suppose. -- PMM
Peter Maydell <peter.maydell@linaro.org> wrote: > On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote: >> 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. > > Well, we shouldn't really be mandating latest-and-greatest versions > of our upstream dependencies unless the maintainer of those dependencies > feels the earlier versions are so badly broken that it would be better > to refuse to use them at all. +1 >> It's important to remember that this patch is also the proper fix for >> this bug: https://bugs.launchpad.net/qemu/+bug/1363641 > > If that only applies to certain architectures we can make the > dependency version vary depending on which arch we're building > for, I suppose. I will go for this. My concern is that virt-test will stop working until distributins gets updated. I can update it myself, or running with --qemu_sandbox=off, that is what I just did for the pull request just sent. But I feel bad that people on recent distributions are not able to use important features. Thanks, Juan.
On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote: > 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. Incidentally, "about two months" is actually a very short time between upstream-release and mandating it for QEMU. Consider that our glib dependency is 2.12, which was released in 2006, and we're still debating whether to move forward to 2.24 (released in 2010). Distro release schedules are often on a scale of years, especially for long-term-support distros, and we want to support as wide a range of them as we reasonably can. -- PMM
On Thu, Mar 26, 2015 at 02=44=14PM +0000, Peter Maydell wrote: > On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote: > > 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. > > Well, we shouldn't really be mandating latest-and-greatest versions > of our upstream dependencies unless the maintainer of those dependencies > feels the earlier versions are so badly broken that it would be better > to refuse to use them at all. > > > It's important to remember that this patch is also the proper fix for > > this bug: https://bugs.launchpad.net/qemu/+bug/1363641 > > If that only applies to certain architectures we can make the > dependency version vary depending on which arch we're building > for, I suppose. > This sounds more like a reasonable approach that could solve the above mentioned problem and also making virt-test to be able to keep using this feature as well -- which is also very important in order to get more important system calls for the whitelist. I'll roll out a new patch for that. Thanks for the idea, Paul. Sorry for the trouble on your side, Juan. Regards,
Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote: > On Thu, Mar 26, 2015 at 02=44=14PM +0000, Peter Maydell wrote: >> On 26 March 2015 at 14:37, Eduardo Otubo <eduardo.otubo@profitbricks.com> wrote: >> > 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. >> >> Well, we shouldn't really be mandating latest-and-greatest versions >> of our upstream dependencies unless the maintainer of those dependencies >> feels the earlier versions are so badly broken that it would be better >> to refuse to use them at all. >> >> > It's important to remember that this patch is also the proper fix for >> > this bug: https://bugs.launchpad.net/qemu/+bug/1363641 >> >> If that only applies to certain architectures we can make the >> dependency version vary depending on which arch we're building >> for, I suppose. >> > > This sounds more like a reasonable approach that could solve the above > mentioned problem and also making virt-test to be able to keep using > this feature as well -- which is also very important in order to get > more important system calls for the whitelist. I'll roll out a new patch > for that. > > Thanks for the idea, Paul. > Sorry for the trouble on your side, Juan. You are welcome. I was just trying to fix the prob0lem before somebody else hit it O:-) Later, Juan.
diff --git a/configure b/configure index 589798e..cbe6495 100755 --- a/configure +++ b/configure @@ -1848,14 +1848,13 @@ fi # libseccomp check if test "$seccomp" != "no" ; then - if test "$cpu" = "i386" || test "$cpu" = "x86_64" && - $pkg_config --atleast-version=2.1.1 libseccomp; then + if $pkg_config --atleast-version=2.2.0 libseccomp; then libs_softmmu="$libs_softmmu `$pkg_config --libs libseccomp`" QEMU_CFLAGS="$QEMU_CFLAGS `$pkg_config --cflags libseccomp`" seccomp="yes" else if test "$seccomp" = "yes"; then - feature_not_found "libseccomp" "Install libseccomp devel >= 2.1.1" + feature_not_found "libseccomp" "Install libseccomp devel >= 2.2.0" fi seccomp="no" fi
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> --- configure | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)