- 07 5月, 2013 3 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=924501 tracks a problem that occurs if uid 107 is already in use at the time libvirt is first installed. In response that problem, Fedora packaging guidelines were recently updated. This fixes the spec file to comply with the new guidelines: https://fedoraproject.org/wiki/Packaging:UsersAndGroups * libvirt.spec.in (daemon): Follow updated Fedora guidelines. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit a2584d58) Conflicts: libvirt.spec.in - no backport of c8f79c9b %if reindents
-
由 Jiri Denemark 提交于
When a changelog entry references an RPM macro, % needs to be escaped so that it does not appear expanded in package changelog. Fri Mar 4 2009 is incorrect since Mar 4 was Wednesday. Since libvirt-0.6.1 was released on Mar 4 2009, we should change Fri to Wed. (cherry picked from commit 53657a0a)
-
由 Jiri Denemark 提交于
The macro was made to help installing broken packages that did not use DESTDIR correctly by overriding individual path variables (prefix, sysconfdir, ...). Newer rpm provides fixed make_install macro that calls make install with just the correct DESTDIR, however it is not available everywhere (e.g., RHEL 5 does not have it). On the other hand the make_install macro is simple and straightforward enough for us to use its expansion directly. (cherry picked from commit d45066a5)
-
- 02 4月, 2013 1 次提交
-
-
由 Cole Robinson 提交于
-
- 29 1月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=888071 (cherry picked from commit d60c7f75)
-
由 Cole Robinson 提交于
-
- 10 1月, 2013 1 次提交
-
-
由 Yufang Zhang 提交于
When building libvirt rpms on rhel5, I got the following error: File must begin with "/": rm File must begin with "/": -f File must begin with "/": $RPM_BUILD_ROOT/etc/sysctl.d/libvirtd Installed (but unpackaged) file(s) found: /etc/sysctl.d/libvirtd It is triggerd by the %files list of libvirt daemon: %if 0%{?fedora} >= 14 || 0%{?rhel} >= 6 %config(noreplace) %{_prefix}/lib/sysctl.d/libvirtd.conf %else rm -f $RPM_BUILD_ROOT%{_prefix}/lib/sysctl.d/libvirtd.conf %endif After checking document of rpm spec file, I think it would be better to move the file deleting line from %files list to %install script. Bug introduced in commit a1fd56cb. (cherry picked from commit daef7c9e)
-
- 09 1月, 2013 1 次提交
-
-
由 Viktor Mihajlovski 提交于
In a non-systemd environment the post and preun scripts of libvirt-client fail, since the required files are in libvirt-daemon. Moved them to client. Doing that I noticed %{_unitdir}/libvirt-guests.service was contained in both libvirt-client and libvirt-daemon, which I don't think was intended. Removed the extra copy from daemon. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com> (cherry picked from commit b7159dca) Conflicts: libvirt.spec.in - no virtlockd service
-
- 08 1月, 2013 3 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=887017 reports that even though libvirt attempts to set fs.aio-max-nr via sysctl, the file was installed with the wrong name and gets ignored by sysctl. Furthermore, 'man systcl.d' recommends that packages install into hard-coded /usr/lib/sysctl.d (even when libdir is /usr/lib64), so that sysadmins can use /etc/sysctl.d for overrides. * daemon/Makefile.am (install-sysctl, uninstall-sysctl): Use correct location. * libvirt.spec.in (network_files): Reflect this. (cherry picked from commit a1fd56cb)
-
由 Cole Robinson 提交于
Most of this deals with moving the libvirt-guests.sh script which does all the work to /usr/libexec, so it can be shared by both systemd and traditional init. Previously systemd depended on the script being in /etc/init.d Required to fix https://bugzilla.redhat.com/show_bug.cgi?id=789747 (cherry picked from commit d13155c2)
-
由 Jim Fehlig 提交于
Based on a patch originally authored by Daniel De Graaf http://lists.xen.org/archives/html/xen-devel/2012-05/msg00565.html This patch converts the Xen libxl driver to support only Xen >= 4.2. Support for Xen 4.1 libxl is dropped since that version of libxl is designated 'technology preview' only and is incompatible with Xen 4.2 libxl. Additionally, the default toolstack in Xen 4.1 is still xend, for which libvirt has a stable, functional driver. (cherry picked from commit dfa1e1dd) Conflicts: src/libxl/libxl_conf.c - commit e5e8d5 not backported src/libxl/libxl_driver.c - commit 1c04f999 not backported
-
- 10 12月, 2012 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Václav Pavlín 提交于
https://bugzilla.redhat.com/850186 I added %with_systemd_macros so it should now work in F17 with old scriptlets and in F18+/RHEL7+ with systemd macros (see https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd) I missed libvirt-guests.service because there is no systemctl call for it. So I only added systemd macros calls. (cherry picked from commit ec02d49d)
-
- 17 11月, 2012 1 次提交
-
-
由 Dan Horák 提交于
QEMU in Fedora >= 18 is configured with ppc64 and s390x as architectures where KVM is enabled. https://bugzilla.redhat.com/show_bug.cgi?id=872545 (cherry picked from commit 041b1ff2)
-
- 06 11月, 2012 1 次提交
-
-
由 Eric Blake 提交于
In Fedora 16, we quit enabling cgconfig because systemd set up default cgroups that were good enough for our use. But in F17, when we switched to systemd, we reverted and started up cgconfig again. See also the tail of this thread: https://www.redhat.com/archives/libvir-list/2012-October/msg01657.html * libvirt.spec.in (with_systemd): Rely on systemd for cgroups. (cherry picked from commit b61eadf3)
-
- 28 10月, 2012 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Cole Robinson 提交于
If building on a 64bit host, rename the affected tapsets to <name>-64.stp. This is similar to what the python package does in fedora. https://bugzilla.redhat.com/show_bug.cgi?id=831425 (cherry picked from commit 18d0632d)
-
- 19 10月, 2012 3 次提交
-
-
由 Peter Krempa 提交于
libssh2 unfortunately doesn't support symbol versioning so RPM can't figure out what version is needed for the currently installed libvirt package. This patch adds a runtime requirement, so that the correct version of libssh2 can be installed along with libvirt. (cherry picked from commit cb4f41b8)
-
由 Peter Krempa 提交于
Libssh2 transport support was enabled lately but the spec file wasn't updated to take this into account. This caused libvirt to be built without libssh2 support in Red Hat based OSes. (cherry picked from commit 1e25c54f)
-
由 Eric Blake 提交于
I noticed that in two places, we require util-linux, and in a third, we require util-linux-ng. On Fedora (I tested F15 through rawhide), util-linux-ng is obsoleted by util-linux; on RHEL 6, util-linux is obsoleted by util-linux-ng. That is, on either platform, either name will get you the correct package installed (where the preferred name on fedora is util-linux, and on RHEL 6 is util-linux-ng). But on RHEL 5, there is no util-linux-ng * libvirt.spec.in (Requires): Use util-linux, not util-linux-ng. (cherry picked from commit a9087ad1)
-
- 24 9月, 2012 4 次提交
-
-
由 Daniel Veillard 提交于
* configure.ac docs/news.html.in libvirt.spec.in: update for the release * po/*.po*: update from transifex and regenerate
-
由 Daniel Veillard 提交于
without systemd we should not try to package the non-installed %{_sysconfdir}/rc.d/init.d/libvirtd
-
由 Daniel Veillard 提交于
$RPM_BUILD_ROOT was embedded in /etc/rc.d/init.d/libvirt-guests
-
由 Daniel P. Berrange 提交于
The Fedora policies don't want us installing the legacy initscripts in parallel with the systemd ones, so switch to only install the systemd unit Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 19 9月, 2012 1 次提交
-
-
由 Doug Goldstein 提交于
Based exclusively on work by Eric Blake in a patch posted with the same subject. However some modifications related to comments and my plans to add another backend. Added WITH_INTERFACE as the only automake variable deciding whether to build the driver and using WITH_NETCF to identify that we're wanting to use the netcf library as the backend. * configure.ac: Added with_interface * src/interface/netcf_driver.c: Renamed.. * src/interface/interface_backend_netcf.c: ..to this to match storage. * src/interface/netcf_driver.h: Renamed.. * src/interface/interface_driver.h: ..to this. * daemon/Makefile.am: Respect WITH_INTERFACE and WITH_NETCF. * libvirt.spec.in: Add RPM support for --with-interface
-
- 07 9月, 2012 2 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
When building RPMs the host kernel cannot be assumed to match the target OS kernel. Thus auto-detecting /selinux vs /sys/fs/selinux based on the host kernel can result in the wrong choice (eg F18 builds on a RHEL6 host kernel) Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 06 9月, 2012 1 次提交
-
-
由 Laine Stump 提交于
A previous patch forced libnl-3 and netcf-0.2.2 (which itself requires libnl-3) when *building* for Fedora 18+ (and RHEL 7+), but the install-time Requires: for netcf has always been implicit due to libvirtd linking with libnetcf.so. However, the since the API of netcf didn't change when it was rebuilt to use libnl-3, the internal library version didn't change either, making it possible (from rpm's point of view) to upgrade libvirt without upgrading netcf (in reality, that leads to a segfault - see https://bugzilla.redhat.com/show_bug.cgi?id=853381). The solution is to put an explicit Requires: line in libvirt's specfile for fedora >= 18 and rhel >= 7.
-
- 05 9月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The libvirt storage driver uses librbd.so for its functionality. RPM will automatically add a dependency on the library, so there is no need to have an explicit dependency on the ceph RPM itself. This allows newer Fedora distros to avoid pulling in the huge ceph RPM, in favour of just having the libraries installed
-
- 31 8月, 2012 1 次提交
-
-
由 Daniel Veillard 提交于
* configure.ac docs/news.html.in libvirt.spec.in: update for release * po/*.po*: pulled localization updates for sp,ja,mr,pa,uk,zh_CN,zh_TW and regenerated
-
- 29 8月, 2012 1 次提交
-
-
由 Daniel Veillard 提交于
* configure.ac docs/news.html.in libvirt.spec.in: updates for the release * po/*.po*: update localizations for zh_CN, uk, ja, pt_BR, as, sp, mr, zh_TW
-
- 27 8月, 2012 1 次提交
-
-
由 Laine Stump 提交于
Everything is ready in both netcf and libvirt to switch over to libnl3 in future releases of both Fedora and RHEL. This needs to be done more or less simultaneously in both packages, though, because you can't mix libnl1.1 and libnl3 in the same process (e.g. libvirtd using libnl-3.so and libnetcf.so, while libnetcf.so uses libnl.so) This patch does two things when fedora >= 18 || rhel >= 7): 1) requires libnl3-devel 2) requires netcf-devel-0.2.2 or greater (the idea is that a similar patch is going into netcf's specfile, so that when a build of netcf is done on F18 or later (or RHEL7 or later) netcf will be guaranteed to be built with libnl3 rather than libnl-1.1)
-
- 23 8月, 2012 1 次提交
-
-
由 Daniel Veillard 提交于
Communication with the firewall daemon uses DBus so if we compile with firewalld support, the dbus-devel is required for building
-
- 22 8月, 2012 1 次提交
-
-
由 Thomas Woerner 提交于
* configure.ac, spec file: firewalld defaults to enabled if dbus is available, otherwise is disabled. If --with_firewalld is explicitly requested and dbus is not available, configure will fail. * bridge_driver: add dbus filters to get the FirewallD1.Reloaded signal and DBus.NameOwnerChanged on org.fedoraproject.FirewallD1. When these are encountered, reload all the iptables reuls of all libvirt's virtual networks (similar to what happens when libvirtd is restarted). * iptables, ebtables: use firewall-cmd's direct passthrough interface when available, otherwise use iptables and ebtables commands. This decision is made once the first time libvirt calls iptables/ebtables, and that decision is maintained for the life of libvirtd. * Note that the nwfilter part of this patch was separated out into another patch by Stefan in V2, so that needs to be revised and re-reviewed as well. ================ All the configure.ac and specfile changes are unchanged from Thomas' V3. V3 re-ran "firewall-cmd --state" every time a new rule was added, which was extremely inefficient. V4 uses VIR_ONCE_GLOBAL_INIT to set up a one-time initialization function. The VIR_ONCE_GLOBAL_INIT(x) macro references a static function called vir(Ip|Eb)OnceInit(), which will then be called the first time that the static function vir(Ip|Eb)TablesInitialize() is called (that function is defined for you by the macro). This is thread-safe, so there is no chance of any race. IMPORTANT NOTE: I've left the VIR_DEBUG messages in these two init functions (one for iptables, on for ebtables) as VIR_WARN so that I don't have to turn on all the other debug message just to see these. Even if this patch doesn't need any other modification, those messages need to be changed to VIR_DEBUG before pushing. This one-time initialization works well. However, I've encountered problems with testing: 1) Whenever I have enabled the firewalld service, *all* attempts to call firewall-cmd from within libvirtd end with firewall-cmd hanging internally somewhere. This is *not* the case if firewall-cmd returns non-0 in response to "firewall-cmd --state" (i.e. *that* command runs and returns to libvirt successfully.) 2) If I start libvirtd while firewalld is stopped, then start firewalld later, this triggers libvirtd to reload its iptables rules, however it also spits out a *ton* of complaints about deletion failing (I suppose because firewalld has nuked all of libvirt's rules). I guess we need to suppress those messages (which is a more annoying problem to fix than you might think, but that's another story). 3) I noticed a few times during this long line of errors that firewalld made a complaint about "Resource Temporarily unavailable. Having libvirtd access iptables commands directly at the same time as firewalld is doing so is apparently problematic. 4) In general, I'm concerned about the "set it once and never change it" method - if firewalld is disabled at libvirtd startup, causing libvirtd to always use iptables/ebtables directly, this won't cause *terrible* problems, but if libvirtd decides to use firewall-cmd and firewalld is later disabled, libvirtd will not be able to recover.
-
- 01 8月, 2012 3 次提交
-
-
由 Jiri Denemark 提交于
-
由 Daniel Veillard 提交于
The 'make check' was rebuilding the binaries just overrided, so for more safety also override the C program Also daemon-conf isn't built anymore so remove it from the list
-
由 Dmitry Guryanov 提交于
Parallels Cloud Server is a cloud-ready virtualization solution that allows users to simultaneously run multiple virtual machines and containers on the same physical server. More information can be found here: http://www.parallels.com/products/pcs/ Also beta version of Parallels Cloud Server can be downloaded there. Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
-
- 24 7月, 2012 1 次提交
-
-
由 Wen Congyang 提交于
libvirt-daemon-driver-XXX should be a dependency only when with_driver_modules is 1. libvirt-daemon-driver-libxl should be a dependency only when with_libxl is 1. libvirt-daemon-driver-lxc should be a dependency only when with_lxc is 1. libvirt-daemon-driver-qemu should be a dependency only when with_qemu is 1. libvirt-daemon-driver-uml should be a dependency only when with_uml is 1. libvirt-daemon-driver-xen should be a dependency only when with_xen is 1.
-
- 19 7月, 2012 2 次提交
-
-
由 Daniel P. Berrange 提交于
Turning on the building of driver modules in libvirt.spec.in means that installing 'libvirt' no longer pulls in all the drivers. For upgrade compatibility we need to list all drivers module sub-RPMs against the 'libvirt' RPM. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Sebastian Wiedenroth 提交于
This patch brings support to manage sheepdog pools and volumes to libvirt. It uses the "collie" command-line utility that comes with sheepdog for that. A sheepdog pool in libvirt maps to a sheepdog cluster. It needs a host and port to connect to, which in most cases is just going to be the default of localhost on port 7000. A sheepdog volume in libvirt maps to a sheepdog vdi. To create one specify the pool, a name and the capacity. Volumes can also be resized later. In the volume XML the vdi name has to be put into the <target><path>. To use the volume as a disk source for virtual machines specify the vdi name as "name" attribute of the <source>. The host and port information from the pool are specified inside the host tag. <disk type='network'> ... <source protocol="sheepdog" name="vdi_name"> <host name="localhost" port="7000"/> </source> </disk> To work right this patch parses the output of collie, so it relies on the raw output option. There recently was a bug which caused size information to be reported wrong. This is fixed upstream already and will be in the next release. Signed-off-by: NSebastian Wiedenroth <wiedi@frubar.net>
-