similar to: Attn Fedora Rawhide users

Also add kickstarts for F17 Signed-off-by: Mike Burns <mburns at redhat.com> --- recipe/Makefile.am | 2 +- recipe/ovirt17-install.ks | 1 + recipe/ovirt17-minimizer.ks | 1 + recipe/ovirt17-pkgs.ks | 1 + recipe/ovirt17-post.ks | 1 + 5 files changed, 5 insertions(+), 1 deletions(-) create mode 120000 recipe/ovirt17-install.ks create mode 120000

On Thu, May 21, 2015 at 02:37:31PM +0100, Richard W.M. Jones wrote: > > Previous attempt: > https://www.redhat.com/archives/libguestfs/2015-April/msg00013.html > > supermin needs to download packages (eg. RPMs) when preparing the > appliance. > > After a lot of work, 'dnf download' can now be used as a replacement > for the (deprecated) 'yumdownloader'

Hi (Eric?), A couple of questions while using the 'virsh blockpull' Summary: 1] Created snapshots this way: base<-snap1<-snap2<-snap3 (online, external snapshot --disk-only) 2] I did a 'virsh blockpull' from snap2 into snap3 3] Next, did another 'virsh blockpull' from snap1 into snap3 - Here, 'qemu-img info /path/to/snap3' shows its backing file

I just installed the Rawhide package on my CentOS 5 system. The one item that bit me is that the config file defaults to using interface "[::]" so it only listens on IPv6. (This is from a patch in the package that changes the upstream default of "*", so it only affects those using the Fedora package.) For those wanting to track the issue, here's the Bugzilla:

supermin needs to download packages (eg. RPMs) when preparing the appliance. 'dnf download' finally appears to have made parallel downloads reliable[1]. Better late than never. So I have experimentally switched Rawhide's supermin to use 'dnf download' instead of the (deprecated) 'yumdownloader' program. This only affects the 'supermin --prepare' phase, which

https://bugs.freedesktop.org/show_bug.cgi?id=36512 Summary: Xorg Beta 1.10.99.1 - Provided by Fedora - Rawhide Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

Fedora rawhide now builds on ARM as well as 32-bit and 64-bit x86, and while the x86 builds are successful, the ARM build is failing. I was able to fix the first problem, which was reported in a Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715424 However, there are further build errors for which I haven't found appropriate fixes. It looks like there might be a namespace

On Tue, May 26, 2015 at 09:44:33AM +0100, Richard W.M. Jones wrote: > On Mon, May 25, 2015 at 10:22:35PM +0200, Kashyap Chamarthy wrote: > > I just built `supermin` from source on my Fedora 22 machine, and somehow > > it can't seem to detect RPM (but `supermin` from Rawhide detects it). > > Exact error: > > > > supermin: could not detect package manager

On Mon, May 25, 2015 at 10:22:35PM +0200, Kashyap Chamarthy wrote: > I just built `supermin` from source on my Fedora 22 machine, and somehow > it can't seem to detect RPM (but `supermin` from Rawhide detects it). > Exact error: > > supermin: could not detect package manager used by this system or > distro. > > which is coming from:

Previous attempt: https://www.redhat.com/archives/libguestfs/2015-April/msg00013.html supermin needs to download packages (eg. RPMs) when preparing the appliance. After a lot of work, 'dnf download' can now be used as a replacement for the (deprecated) 'yumdownloader' program. This only affects the 'supermin --prepare' phase, which means it only affects people building

This is now complete and soon the new packages will be merged into Fedora Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2e0b2d6395 A few non-critical packages failed to build, and I will look at these later unless someone gets around to it before me. The failures are listed at the end. Notable changes: - Release notes: https://ocaml.org/releases/4.09.0.html - ocaml-camlp4

Hi, I've just updated compiz in fedora rawhide and wanted to post a quick overview of the patches we still carry. Patch details are available here: http://cvs.fedora.redhat.com/viewcvs/rpms/compiz/devel terminate-move.patch restart.patch These are already upstream, but not yet in a released version. aiglx-defaults.patch tfp-server-extension.patch These two paper over a problem in

Building is broken in Rawhide. I have fixed everything but we're waiting for one kernel change to go upstream. The issues were: * https://bugzilla.redhat.com/show_bug.cgi?id=710882 parted failed to parse the Linux "3.0" string Fixed upstream, and I have added the patch to the Rawhide parted package. * https://bugzilla.redhat.com/show_bug.cgi?id=710921 ftrace doesn't

https://fedoraproject.org/wiki/Ovirt_Node_Spin I noticed that virt-manager-tui is in rawhide finally, but the package name implies that it's not going to be in f16? virt-manager-tui.noarch 0.9.0-4.fc17 rawhide Cole, is this intentional or just smth that we need to follow up on? Also, I've noticed that ovirt-node needs refreshing... iirc apevec did tag/release of 2.0.1 from

Same picture for any repo. --- On Tue, 10/6/09, John Levon <john.levon@sun.com> wrote: From: John Levon <john.levon@sun.com> Subject: F12 rawhide PV HTTP install To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: xen-discuss@opensolaris.org Date: Tuesday, October 6, 2009, 5:49 PM On Tue, Oct 06, 2009 at 07:19:40AM -0700, Boris Derzhavets wrote: > I''ve

$ libguestfs-test-tool ... libguestfs: launch: version=1.42.0fedora=33,release=5.fc33,libvirt ... libguestfs: build appliance libguestfs: error: cannot find any suitable libguestfs supermin, fixed or old-style appliance on LIBGUESTFS_PATH (search path: /usr/lib/guestfs) ... It appears that this configure test is now failing:

Just a note [possibly more of a warning] that I'm intending to switch the default backend in Fedora 18+ to libvirt this week. For more information about what this means, see: https://rwmj.wordpress.com/2012/07/23/new-in-libguestfs-use-libvirt-to-launch-the-appliance/#content Barring any bugs, the change ought to be transparent. The reasons why we're making this change in Fedora are:

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt

If you are interested in trying the new paravirt_ops kernels, I've created some packages and uploaded them to: http://et.redhat.com/~chrisw/paravirt_ops/ There you'll find a yum repo (see yum.README for details) and an INSTALL file for getting started. With this package you can use a single kernel[1] for both native (w/out a hypervisor, or under a full virt hypervisor), domU paravirt