May 2020 - Devel - libvirt List Archives

[PATCH v3 0/9] Introducing TPM Proxy device support for PPC64
by Daniel Henrique Barboza 15 May '20

15 May '20

changes in v3 after reviews from Stefan Berger: - new patch 4: trivial change to allow g_autoptr() with virDomainTPMDefPtr - patch 5 (former 4): added g_autoptr(), removed VIR_FREE() calls - changed wording in patches 1 and 9 (former 8) to make it clear for users that this new device brings no benefits unless the guest is running on specialized PPC64 hardware - fixed identation in patch 6 (former 5). Added Stefan's r-b v2 link: https://www.redhat.com/archives/libvir-list/2020-May/msg00604.html v1 link: https://www.redhat.com/archives/libvir-list/2020-May/msg00604.html Daniel Henrique Barboza (9): docs: documentation and schema for the new TPM Proxy model qemu: Extend QEMU capabilities with 'spapr-tpm-proxy' conf, qemu: adding 'tpmproxy' in domain definition conf, domain: register AUTOPTR_CLEANUP_FUNC for virDomainTPMDef domain_conf.c: XML parsing for VIR_DOMAIN_TPM_MODEL_SPAPR_PROXY tests: add XML schema tests for the TPM Proxy device qemu: build command line for the TPM Proxy device tests/qemuxml2argvtest.c: add TPM Proxy command line tests docs/news.xml: update for the new TPM Proxy device docs/formatdomain.html.in | 18 +++++- docs/news.xml | 17 +++++ docs/schemas/domaincommon.rng | 1 + src/conf/domain_audit.c | 3 + src/conf/domain_conf.c | 63 +++++++++++++++++-- src/conf/domain_conf.h | 3 + src/qemu/qemu_alias.c | 16 +++++ src/qemu/qemu_capabilities.c | 4 ++ src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_cgroup.c | 12 +++- src/qemu/qemu_command.c | 21 +++++++ src/qemu/qemu_domain.c | 9 +-- src/qemu/qemu_validate.c | 12 ++++ src/security/security_dac.c | 14 +++++ src/security/security_selinux.c | 11 ++++ .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + tests/qemuxml2argvdata/ppc64-tpm-double.xml | 34 ++++++++++ .../ppc64-tpmproxy-double.xml | 38 +++++++++++ .../ppc64-tpmproxy-single.ppc64-latest.args | 34 ++++++++++ .../ppc64-tpmproxy-single.xml | 33 ++++++++++ .../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 37 +++++++++++ .../ppc64-tpmproxy-with-tpm.xml | 36 +++++++++++ tests/qemuxml2argvtest.c | 15 +++++ .../ppc64-tpmproxy-single.ppc64-latest.xml | 42 +++++++++++++ .../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 46 ++++++++++++++ tests/qemuxml2xmltest.c | 2 + 27 files changed, 514 insertions(+), 12 deletions(-) create mode 100644 tests/qemuxml2argvdata/ppc64-tpm-double.xml create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-double.xml create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-single.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-single.xml create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-with-tpm.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-with-tpm.xml create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy-single.ppc64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy-with-tpm.ppc64-latest.xml -- 2.26.2

3 21

[libvirt PATCH] qemu: prevent attempts to detach a device on a controller with hotplug='off'
by Laine Stump 15 May '20

15 May '20

Although the original patches to support controllers with hotplug='off' were checking during hotplug/attach requests that the device was being plugged into a PCI controller that didn't have hotplug disabled, but I forgot to do the same for device detach (the main impetus for adding the feature was to prevent unplugs originating from within the guest, so it slipped my mind). So although the guest OS was ultimately unable to honor the unplug request, libvirt could still be used to make such a request, and since device attach/detach are asynchronous operations, the caller to libvirt would receive a success status back (the device would stubbornly/correctly remain in the domain status XML however) This patch remedies that, by looking at the controller for the device in the detach request, and immediately failing the operation if that controller has hotplug=off. r changes. Lines starting Signed-off-by: Laine Stump <laine(a)redhat.com> --- src/qemu/qemu_hotplug.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index ab5a7aef84..5fe125b1a7 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -5891,6 +5891,33 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm, return -1; } + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { + int controllerIdx = virDomainControllerFind(vm->def, + VIR_DOMAIN_CONTROLLER_TYPE_PCI, + info->addr.pci.bus); + if (controllerIdx < 0) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("cannot hot unplug %s device with PCI guest address: " + VIR_PCI_DEVICE_ADDRESS_FMT + " - controller not found"), + virDomainDeviceTypeToString(detach.type), + info->addr.pci.domain, info->addr.pci.bus, + info->addr.pci.slot, info->addr.pci.function); + return -1; + } + + if (vm->def->controllers[controllerIdx]->opts.pciopts.hotplug + == VIR_TRISTATE_SWITCH_OFF) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("cannot hot unplug %s device with PCI guest address: " + VIR_PCI_DEVICE_ADDRESS_FMT + " - not allowed by controller"), + virDomainDeviceTypeToString(detach.type), + info->addr.pci.domain, info->addr.pci.bus, + info->addr.pci.slot, info->addr.pci.function); + return -1; + } + } /* * Issue the qemu monitor command to delete the device (based on * its alias), and optionally wait a short time in case the -- 2.25.4

3 2

Firmware auto-select limitation
by GUOQING LI 15 May '20

15 May '20

Hi everyone and Martin I would like to confirm the conversation we had in regard the possible limitation of firmware auto-select feature that’s been released since v5.20. I recall you saying that there were a lot of issues with auto select and later they shipped it into a Json file , it still didn’t solve all the problems, did it? Is it better to explicitly specify the loader and nvram path than using auto-select ? Just today, I encountered the issue of using firmware=“efi” on libvirt 5.4.0 I am running Ubuntu eoan 19.10, I am wondering how did it happen. Detailed error Error starting domain: internal error: process exited while connecting to monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on: Failed to lock byte 100 Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup self._backend.create() File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirt.libvirtError: internal error: process exited while connecting to monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on: Failed to lock byte 100

3 2

[PATCH v2 0/3] qemu: Use -numa memdev= if -numa mem= is unavailable
by Michal Privoznik 15 May '20

15 May '20

v2 of: https://www.redhat.com/archives/libvir-list/2020-May/msg00490.html diff to v1: - different approach used. I completely forgot about the discussion we had, but after Dan pointed it out to me, it clicked. Michal Prívozník (3): qemu: Track numa-mem-supported machine attribute qemuBuildNumaArgStr: Switch order of if() and for() qemuBuildNumaArgStr: Use modern -numa memdev= if old -numa mem= is unsupported src/qemu/qemu_capabilities.c | 44 ++- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_capspriv.h | 3 +- src/qemu/qemu_command.c | 17 +- src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 11 + .../caps_1.5.3.x86_64.xml | 60 ++-- .../caps_1.6.0.x86_64.xml | 68 ++--- .../caps_1.7.0.x86_64.xml | 76 ++--- .../caps_2.1.1.x86_64.xml | 92 +++--- .../caps_2.10.0.aarch64.xml | 204 +++++++------- .../caps_2.10.0.ppc64.xml | 84 +++--- .../caps_2.10.0.s390x.xml | 28 +- .../caps_2.10.0.x86_64.xml | 140 +++++----- .../caps_2.11.0.s390x.xml | 32 +-- .../caps_2.11.0.x86_64.xml | 140 +++++----- .../caps_2.12.0.aarch64.xml | 228 +++++++-------- .../caps_2.12.0.ppc64.xml | 100 +++---- .../caps_2.12.0.s390x.xml | 36 +-- .../caps_2.12.0.x86_64.xml | 148 +++++----- .../caps_2.4.0.x86_64.xml | 116 ++++---- .../caps_2.5.0.x86_64.xml | 124 ++++---- .../caps_2.6.0.aarch64.xml | 164 +++++------ .../qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 60 ++-- .../caps_2.6.0.x86_64.xml | 100 +++---- .../qemucapabilitiesdata/caps_2.7.0.s390x.xml | 16 +- .../caps_2.7.0.x86_64.xml | 108 +++---- .../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 20 +- .../caps_2.8.0.x86_64.xml | 124 ++++---- .../qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 80 +++--- .../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 24 +- .../caps_2.9.0.x86_64.xml | 132 ++++----- .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 104 +++---- .../caps_3.0.0.riscv32.xml | 10 +- .../caps_3.0.0.riscv64.xml | 10 +- .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 40 +-- .../caps_3.0.0.x86_64.xml | 156 +++++------ .../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 108 +++---- .../caps_3.1.0.x86_64.xml | 164 +++++------ .../caps_4.0.0.aarch64.xml | 264 +++++++++--------- .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 112 ++++---- .../caps_4.0.0.riscv32.xml | 10 +- .../caps_4.0.0.riscv64.xml | 10 +- .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 48 ++-- .../caps_4.0.0.x86_64.xml | 164 +++++------ .../caps_4.1.0.x86_64.xml | 176 ++++++------ .../caps_4.2.0.aarch64.xml | 52 ++-- .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 72 ++--- .../caps_4.2.0.x86_64.xml | 184 ++++++------ .../caps_5.0.0.aarch64.xml | 52 ++-- .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 76 ++--- .../caps_5.0.0.x86_64.xml | 176 ++++++------ .../caps_5.1.0.x86_64.xml | 176 ++++++------ tests/testutilsqemu.c | 6 +- 54 files changed, 2408 insertions(+), 2345 deletions(-) -- 2.26.2

2 7

[libvirt PATCH] docs: Update after libvirt-ruby repository rename
by Andrea Bolognani 15 May '20

15 May '20

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. docs/ci.rst | 10 +++++----- docs/downloads.html.in | 8 ++++---- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/ci.rst b/docs/ci.rst index fe59b98923..2a8788d0d7 100644 --- a/docs/ci.rst +++ b/docs/ci.rst @@ -76,16 +76,16 @@ Language bindings :target: https://gitlab.com/libvirt/libvirt-python/pipelines :alt: libvirt-python pipeline status + * - libvirt-ruby + - .. image:: https://gitlab.com/libvirt/libvirt-ruby/badges/master/pipeline.svg + :target: https://gitlab.com/libvirt/libvirt-ruby/pipelines + :alt: libvirt-ruby pipeline status + * - libvirt-rust - .. image:: https://gitlab.com/libvirt/libvirt-rust/badges/master/pipeline.svg :target: https://gitlab.com/libvirt/libvirt-rust/pipelines :alt: libvirt-rust pipeline status - * - ruby-libvirt - - .. image:: https://gitlab.com/libvirt/ruby-libvirt/badges/master/pipeline.svg - :target: https://gitlab.com/libvirt/ruby-libvirt/pipelines - :alt: ruby-libvirt pipeline status - Object mappings --------------- diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 506c2669b4..24ee27cc5c 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -179,14 +179,14 @@ <a href="https://libvirt.org/sources/ruby/">libvirt</a> </td> <td> - <a href="https://gitlab.com/libvirt/ruby-libvirt">gitlab</a> + <a href="https://gitlab.com/libvirt/libvirt-ruby">gitlab</a> </td> <td> - <a href="https://gitlab.com/libvirt/ruby-libvirt/-/issues">issues</a> + <a href="https://gitlab.com/libvirt/libvirt-ruby/-/issues">issues</a> </td> <td class="gitmirror"> - <a href="https://libvirt.org/git/?p=ruby-libvirt.git;a=summary">libvirt</a> - <a href="https://github.com/libvirt/ruby-libvirt">github</a> + <a href="https://libvirt.org/git/?p=libvirt-ruby.git;a=summary">libvirt</a> + <a href="https://github.com/libvirt/libvirt-ruby">github</a> </td> <td></td> </tr> -- 2.25.4

1 0

[libvirt-ruby PATCH v2 0/4] Introduce GitLab CI and merge requests
by Daniel P. Berrangé 15 May '20

15 May '20

In v2: - Renamed repo - Change way we conditionalize build rules Daniel P. Berrangé (4): doc: update for new git repo name and hosting gitlab: introduce CI jobs testing git master & distro libvirt gitlab: add CONTRIBUTING.rst file to indicate use of merge requests Remove obsolete mercurial ignore file .gitlab-ci.yml | 169 +++++++++++++++++++++++++++ .gitpublish | 4 - .hgignore | 7 -- CONTRIBUTING.rst | 28 +++++ ci/README.rst | 14 +++ ci/libvirt-centos-7.Dockerfile | 86 ++++++++++++++ ci/libvirt-centos-8.Dockerfile | 64 ++++++++++ ci/libvirt-debian-10.Dockerfile | 56 +++++++++ ci/libvirt-debian-9.Dockerfile | 59 ++++++++++ ci/libvirt-debian-sid.Dockerfile | 56 +++++++++ ci/libvirt-fedora-31.Dockerfile | 53 +++++++++ ci/libvirt-fedora-32.Dockerfile | 53 +++++++++ ci/libvirt-fedora-rawhide.Dockerfile | 54 +++++++++ ci/libvirt-opensuse-151.Dockerfile | 55 +++++++++ ci/libvirt-ubuntu-1804.Dockerfile | 59 ++++++++++ ci/libvirt-ubuntu-2004.Dockerfile | 56 +++++++++ ci/refresh | 27 +++++ doc/site/downloads.html | 12 +- doc/site/index.html | 2 +- 19 files changed, 892 insertions(+), 22 deletions(-) delete mode 100644 .gitpublish delete mode 100644 .hgignore create mode 100644 CONTRIBUTING.rst create mode 100644 ci/README.rst create mode 100644 ci/libvirt-centos-7.Dockerfile create mode 100644 ci/libvirt-centos-8.Dockerfile create mode 100644 ci/libvirt-debian-10.Dockerfile create mode 100644 ci/libvirt-debian-9.Dockerfile create mode 100644 ci/libvirt-debian-sid.Dockerfile create mode 100644 ci/libvirt-fedora-31.Dockerfile create mode 100644 ci/libvirt-fedora-32.Dockerfile create mode 100644 ci/libvirt-fedora-rawhide.Dockerfile create mode 100644 ci/libvirt-opensuse-151.Dockerfile create mode 100644 ci/libvirt-ubuntu-1804.Dockerfile create mode 100644 ci/libvirt-ubuntu-2004.Dockerfile create mode 100755 ci/refresh -- 2.26.2

2 7

[libvirt-java PATCH v2 0/2] Introduce GitLab CI and merge requests
by Daniel P. Berrangé 15 May '20

15 May '20

In v2: - Use different approach for conditional job rules - Use ubuntu for long term git job Daniel P. Berrangé (2): gitlab: introduce CI jobs testing git master & distro libvirt gitlab: add CONTRIBUTING.rst file to indicate use of merge requests .gitlab-ci.yml | 171 +++++++++++++++++++++++++++ .gitpublish | 4 - CONTRIBUTING.rst | 28 +++++ ci/README.rst | 14 +++ ci/libvirt-centos-7.Dockerfile | 88 ++++++++++++++ ci/libvirt-centos-8.Dockerfile | 55 +++++++++ ci/libvirt-debian-10.Dockerfile | 58 +++++++++ ci/libvirt-debian-9.Dockerfile | 61 ++++++++++ ci/libvirt-debian-sid.Dockerfile | 58 +++++++++ ci/libvirt-fedora-31.Dockerfile | 55 +++++++++ ci/libvirt-fedora-32.Dockerfile | 55 +++++++++ ci/libvirt-fedora-rawhide.Dockerfile | 56 +++++++++ ci/libvirt-opensuse-151.Dockerfile | 57 +++++++++ ci/libvirt-ubuntu-1804.Dockerfile | 61 ++++++++++ ci/libvirt-ubuntu-2004.Dockerfile | 68 +++++++++++ ci/refresh | 27 +++++ 16 files changed, 912 insertions(+), 4 deletions(-) delete mode 100644 .gitpublish create mode 100644 CONTRIBUTING.rst create mode 100644 ci/README.rst create mode 100644 ci/libvirt-centos-7.Dockerfile create mode 100644 ci/libvirt-centos-8.Dockerfile create mode 100644 ci/libvirt-debian-10.Dockerfile create mode 100644 ci/libvirt-debian-9.Dockerfile create mode 100644 ci/libvirt-debian-sid.Dockerfile create mode 100644 ci/libvirt-fedora-31.Dockerfile create mode 100644 ci/libvirt-fedora-32.Dockerfile create mode 100644 ci/libvirt-fedora-rawhide.Dockerfile create mode 100644 ci/libvirt-opensuse-151.Dockerfile create mode 100644 ci/libvirt-ubuntu-1804.Dockerfile create mode 100644 ci/libvirt-ubuntu-2004.Dockerfile create mode 100755 ci/refresh -- 2.26.2

2 3

[libvirt-ci PATCH] guests: don't force user to create a config.yaml file
by Daniel P. Berrangé 15 May '20

15 May '20

Only the "install" command requires a per-user config.yaml with a password set. We should not require this for the other commands to be run. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- guests/lcitool | 51 +++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/guests/lcitool b/guests/lcitool index 27aee7b..1f093d0 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -138,11 +138,15 @@ class Config: with open(os.path.join(base, "config.yaml"), "r") as fp: self.values = yaml.safe_load(fp) + user_config_path = self._get_config_file("config.yaml") + if not os.path.exists(user_config_path): + return + try: - with open(self._get_config_file("config.yaml"), "r") as fp: + with open(user_config_path, "r") as fp: user_config = yaml.safe_load(fp) except Exception as e: - raise Exception("Missing or invalid config.yaml file: {}".format(e)) + raise Exception("Invalid config.yaml file: {}".format(e)) if user_config is None: raise Exception("Missing or invalid config.yaml file") @@ -181,20 +185,13 @@ class Config: if k not in known_keys: del _dict[k] - def _validate_section(self, config, section, mandatory_keys): + def _validate_section(self, config, section): # remove keys we don't recognize self._remove_unknown_keys(config[section], self.values[section].keys()) - # check that the mandatory keys are present and non-empty - for key in mandatory_keys: - if config.get(section).get(key) is None: - raise Exception(("Missing or empty value for mandatory key" - "'{}.{}'").format(section, key)) - # check that all keys have values assigned and of the right type for key in config[section].keys(): - # mandatory keys were already checked, so this covers optional keys if config[section][key] is None: raise Exception( "Missing value for '{}.{}'".format(section, key) @@ -209,22 +206,6 @@ class Config: # delete sections we don't recognize self._remove_unknown_keys(config, self.values.keys()) - if "install" not in config: - raise Exception("Missing mandatory section 'install'") - - self._validate_section(config, "install", ["root_password"]) - - # we only need this for the gitlab check below, if 'flavor' is missing - # that's okay, we'll provide a default later - flavor = config["install"].get("flavor") - if flavor is not None and flavor not in ["test", "jenkins", "gitlab"]: - raise Exception( - "Invalid value '{}' for 'install.flavor'".format(flavor) - ) - - if flavor == "gitlab": - self._validate_section(config, "gitlab", ["runner_secret"]) - def _update(self, values): self.values["install"].update(values["install"]) @@ -561,10 +542,28 @@ class Application: for project in self._projects.expand_pattern("all"): print(project) + def _validate_install_config(self, config): + if config.values["install"].get("root_password") is None: + raise Exception("Missing mandatory install.root_password config.yaml parameter") + + # we only need this for the gitlab check below, if 'flavor' is missing + # that's okay, we'll provide a default later + flavor = config.values["install"].get("flavor") + if flavor is not None and flavor not in ["test", "jenkins", "gitlab"]: + raise Exception( + "Invalid value '{}' for 'install.flavor'".format(flavor) + ) + + if flavor == "gitlab": + if config.values["gitlab"].get("runner_secret") is None: + raise Exception("Missing mandatory gitlab.runner_secret config.yaml parameter") + def _action_install(self, args): base = Util.get_base() config = self._config + self._validate_install_config(config) + for host in self._inventory.expand_pattern(args.hosts): facts = self._inventory.get_facts(host) -- 2.26.2

2 1

[PATCH] README: Replace "configure" with "autogen.sh" for correct installation
by Yi Wang 15 May '20

15 May '20

From: LiaoPingfang <liao.pingfang(a)zte.com.cn> First of all, there is no "configure" file. We need use autogen.sh at first to create "configure" file. Then in autogen.sh "configure" will be executed according to user as root or non-root. Signed-off-by: Liao Pingfang <liao.pingfang(a)zte.com.cn> --- README.rst | 4 ++-- autogen.sh | 4 ++++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/README.rst b/README.rst index cdcc97b..82b4b31 100644 --- a/README.rst +++ b/README.rst @@ -53,7 +53,7 @@ in a manner that is suitable for installing as root, use: :: $ mkdir build && cd build - $ ../configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var + $ ../autogen.sh $ make $ sudo make install @@ -62,7 +62,7 @@ While to build & install as an unprivileged user :: $ mkdir build && cd build - $ ../configure --prefix=$HOME/usr + $ ../autogen.sh $ make $ make install diff --git a/autogen.sh b/autogen.sh index 4e1bbce..3c119e1 100755 --- a/autogen.sh +++ b/autogen.sh @@ -27,6 +27,10 @@ if test "x$1" = "x--system"; then libdir=$prefix/lib64 fi EXTRA_ARGS="--prefix=$prefix --sysconfdir=$sysconfdir --localstatedir=$localstatedir --libdir=$libdir" + if [ "$HOME" != "/root" ]; then + prefix=$HOME/usr + EXTRA_ARGS="--prefix=$prefix" + fi fi cd "$olddir" -- 2.9.5

5 6

[libvirt PATCH] cpu_arm: Drop unused variable
by Jiri Denemark 15 May '20

15 May '20

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Pushed. It is trivial and should fix the build on FreeBSD. src/cpu/cpu_arm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/cpu/cpu_arm.c b/src/cpu/cpu_arm.c index 66f6942ab9..6f6c6a1479 100644 --- a/src/cpu/cpu_arm.c +++ b/src/cpu/cpu_arm.c @@ -325,7 +325,6 @@ virCPUarmModelParse(xmlXPathContextPtr ctxt, { virCPUarmMapPtr map = data; g_autoptr(virCPUarmModel) model = NULL; - g_autofree xmlNodePtr *nodes = NULL; g_autofree char *vendor = NULL; model = g_new0(virCPUarmModel, 1); -- 2.26.2

1 0