Re: [PATCH] dockerfiles: add diffutils to Fedora
On Sat, Oct 3, 2020 at 4:51 AM Paolo Bonzini wrote: > > For some reason diffutils is not included in the Fedora containers anymore, > causing the build to fail. > > Signed-off-by: Paolo Bonzini > --- > tests/docker/dockerfiles/fedora.docker | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/docker/dockerfiles/fedora.docker > b/tests/docker/dockerfiles/fedora.docker > index 71e4b56977..ec783418c8 100644 > --- a/tests/docker/dockerfiles/fedora.docker > +++ b/tests/docker/dockerfiles/fedora.docker > @@ -11,6 +11,7 @@ ENV PACKAGES \ > cyrus-sasl-devel \ > dbus-daemon \ > device-mapper-multipath-devel \ > +diffutils \ > findutils \ > gcc \ > gcc-c++ \ > -- > 2.26.2 > > Reviewed-by: Neal Gompa -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v3 0/2] block: deprecate the sheepdog driver
On Fri, Oct 2, 2020 at 7:34 AM Daniel P. Berrangé wrote: > > 2 years back I proposed dropping the sheepdog mailing list from the > MAINTAINERS file, but somehow the patch never got picked up: > > https://lists.gnu.org/archive/html/qemu-block/2018-03/msg01048.html > > So here I am with the same patch again. > > This time I go further and deprecate the sheepdog driver entirely. > See the rationale in the second patch commit message. > > Changes in v3: > > - A few minor text changes > - Don't initialize static variable to false > > Daniel P. Berrangé (2): > block: drop moderated sheepdog mailing list from MAINTAINERS file > block: deprecate the sheepdog block driver > > MAINTAINERS| 1 - > block/sheepdog.c | 14 ++ > configure | 5 +++-- > docs/system/deprecated.rst | 9 + > 4 files changed, 26 insertions(+), 3 deletions(-) > > -- > 2.26.2 > Series looks good to me. Reviewed-by: Neal Gompa -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v2 0/2] block: deprecate the sheepdog driver
On Tue, Sep 22, 2020 at 1:43 PM Daniel P. Berrangé wrote: > > On Tue, Sep 22, 2020 at 01:09:06PM -0400, Neal Gompa wrote: > > On Tue, Sep 22, 2020 at 12:16 PM Daniel P. Berrangé > > wrote: > > > > > > 2 years back I proposed dropping the sheepdog mailing list from the > > > MAINTAINERS file, but somehow the patch never got picked up: > > > > > > https://lists.gnu.org/archive/html/qemu-block/2018-03/msg01048.html > > > > > > So here I am with the same patch again. > > > > > > This time I go further and deprecate the sheepdog driver entirely. > > > See the rationale in the second patch commit message. > > > > > > Daniel P. Berrangé (2): > > > block: drop moderated sheepdog mailing list from MAINTAINERS file > > > block: deprecate the sheepdog block driver > > > > > > MAINTAINERS| 1 - > > > block/sheepdog.c | 15 +++ > > > configure | 5 +++-- > > > docs/system/deprecated.rst | 9 + > > > 4 files changed, 27 insertions(+), 3 deletions(-) > > > > > > -- > > > 2.26.2 > > > > > > > > > > I don't know of anyone shipping this other than Fedora, and I > > certainly don't use it there. > > > > Upstream looks like it's unmaintained now, with no commits in over two > > years: https://github.com/sheepdog/sheepdog/commits/master > > > > Can we also get a corresponding change to eliminate this from libvirt? > > This is only deprecation in QEMU, the feature still exists and is > intended to be as fully functional as in previous releases. > > Assuming QEMU actually deletes the feature at end of the deprecation > cycle, then libvirt would look at removing its own support. > Does that stop us from deprecating it in libvirt though? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v2 0/2] block: deprecate the sheepdog driver
On Tue, Sep 22, 2020 at 12:16 PM Daniel P. Berrangé wrote: > > 2 years back I proposed dropping the sheepdog mailing list from the > MAINTAINERS file, but somehow the patch never got picked up: > > https://lists.gnu.org/archive/html/qemu-block/2018-03/msg01048.html > > So here I am with the same patch again. > > This time I go further and deprecate the sheepdog driver entirely. > See the rationale in the second patch commit message. > > Daniel P. Berrangé (2): > block: drop moderated sheepdog mailing list from MAINTAINERS file > block: deprecate the sheepdog block driver > > MAINTAINERS| 1 - > block/sheepdog.c | 15 +++ > configure | 5 +++-- > docs/system/deprecated.rst | 9 + > 4 files changed, 27 insertions(+), 3 deletions(-) > > -- > 2.26.2 > > I don't know of anyone shipping this other than Fedora, and I certainly don't use it there. Upstream looks like it's unmaintained now, with no commits in over two years: https://github.com/sheepdog/sheepdog/commits/master Can we also get a corresponding change to eliminate this from libvirt? Reviewed-by: Neal Gompa -- 真実はいつも一つ！/ Always, there's only one truth!
[Bug 1893667] [NEW] Btrfs commands don't work when using user-space emulation of other architectures
Public bug reported: Description of problem: When doing cross-arch builds with mock, it uses qemu-user-static under the hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that btrfs(8) commands work correctly. This is especially important for being able to do cross-arch image builds. How reproducible: Always (on Fedora 33 with qemu-5.1.0-2.fc33) Steps to Reproduce: $ sudo dnf install mock qemu-user-static wget $ sudo usermod -a -G mock $USER $ newgrp mock $ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux $ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img && mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol create /foo/subvol && umount /foo && losetup -d /dev/loop9' Actual results: Fails with errors like "ERROR: cannot create subvolume: Function not implemented" Expected results: Succeeds and creates subvolumes properly. Additional info: There is a patch series from a few days ago to add support for many btrfs ioctls which could fix this... https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html ** Affects: qemu Importance: Undecided Status: New ** Affects: qemu (Fedora) Importance: Unknown Status: Unknown ** Bug watch added: Red Hat Bugzilla #1872918 https://bugzilla.redhat.com/show_bug.cgi?id=1872918 ** Also affects: qemu (Fedora) via https://bugzilla.redhat.com/show_bug.cgi?id=1872918 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1893667 Title: Btrfs commands don't work when using user-space emulation of other architectures Status in QEMU: New Status in qemu package in Fedora: Unknown Bug description: Description of problem: When doing cross-arch builds with mock, it uses qemu-user-static under the hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that btrfs(8) commands work correctly. This is especially important for being able to do cross-arch image builds. How reproducible: Always (on Fedora 33 with qemu-5.1.0-2.fc33) Steps to Reproduce: $ sudo dnf install mock qemu-user-static wget $ sudo usermod -a -G mock $USER $ newgrp mock $ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux $ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img && mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol create /foo/subvol && umount /foo && losetup -d /dev/loop9' Actual results: Fails with errors like "ERROR: cannot create subvolume: Function not implemented" Expected results: Succeeds and creates subvolumes properly. Additional info: There is a patch series from a few days ago to add support for many btrfs ioctls which could fix this... https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1893667/+subscriptions
Re: [Qemu-devel] converting build system to Meson?
On Thu, Mar 7, 2019 at 1:44 PM Paolo Bonzini wrote:
>
> On 07/03/19 14:09, Peter Maydell wrote:
> > On Thu, 7 Mar 2019 at 12:56, Paolo Bonzini wrote:
> >> In any case, this wouldn't change; as you suggest below, configure could
> >> remain as a front-end (well, in-srcdir builds are not supported by
> >> Meson, so "../configure && ninja" perhaps).
> >
> > As an aside, it might be a nice idea to drop the in-srcdir
> > build altogether for QEMU anyway -- it's not really a very
> > good idea and it means our build system has to cope with two
> > different ways of working to no particularly useful end.
>
> I was actually going to propose that, but I was afraid of throwing two
> bombs in the same day. :)
>
> > Of the various hosts I do builds on:
> > * OSX is 2.7 only
> > * the ppc64 box in the gcc compile farm is 2.7 and 3.4
> >("Centos 7.5.1804")
> > * the aarch64 box in the gcc compile farm is 2.7 and 3.4
> >("Ubuntu 14.04.5 LTS", aka trusty)
>
> OS X will need to get Python 3 from Homebrew sooner or later anyway.
>
> Trusty does have a python3.5 package, perhaps you could ask the
> maintainers to install it.
>
> CentOS 7 doesn't have "native" Python 3 (even the 3.4 version you have
> there is probably coming from Fedora) but it has software collections,
> where you have to do "scl enable rh-python35 './configure && make'".
> You can check if scl and the rh-python35 software collections are
> already installed.
>
Most normal users of CentOS use it with EPEL. In this case, EPEL 7 is
transitioning to Python 3.6 (both are available in EPEL 7 today, and
Meson is built there against 3.6).
macOS already has Python 3 in Homebrew, as well as Meson itself.
Eventually Apple will change the native Python runtime to 3.x as well.
Ubuntu 14.04 LTS is EOL next month, and Ubuntu 16.04 LTS ships Python
3.5 and offers a recent Meson in backports.
--
真実はいつも一つ！/ Always, there's only one truth!
