similar to: [PATCH 1/2] lib: Add CLEANUP_FREE macro which automatically calls 'free' when leaving scope.

This patch series changes a small part of the library to use __attribute__((cleanup(...))) to automatically free memory when pointers go out of the current scope. In general terms this seems to be a small win although you do have to use it carefully. For functions where you can completely get rid of the "exit code paths", it can simplify things. For a good example, see the

This way it is possible to cleanup properly structs in the daemon, when using them within other daemon functions. --- .gitignore | 2 + daemon/Makefile.am | 4 ++ daemon/daemon.h | 1 + generator/daemon.ml | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++ generator/daemon.mli | 2 + generator/main.ml | 4 ++ 6 files changed, 114 insertions(+) diff --git

Implement the GUESTFS_ADD_DRIVE_OPTS_SECRET argument of guestfs_add_drive_opts. For libvirt we have to save the secret in libvirtd first, get a UUID, and then pass the UUID back through the domain XML. --- src/launch-libvirt.c | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 224 insertions(+), 3 deletions(-) diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c

On Thu, Nov 23, 2017 at 02:23:52PM +0100, Pino Toscano wrote: >While YAJL mostly works fine, it did not see any active development in >the latest 3 years. OTOH, Jansson is another JSON C implementation, >with a very liberal license, and a much nicer API. > >Hence, switch all of libguestfs from YAJL to Jansson: >- configure checks, and buildsystem in general >- packages pulled

The yara_load API allows to load a set of Yara rules contained within a file on the host. Rules can be in binary format, as when compiled with yarac command, or in source code format. In the latter case, the rules will be first compiled and then loaded. Subsequent calls of the yara_load API will result in the discard of the previously loaded rules. Signed-off-by: Matteo Cafasso

This likely causes a double-free in the ‘ldmtool_scan_devices’ API. --- daemon/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/ldm.c b/daemon/ldm.c index 8ad2fb33b..7753b0d82 100644 --- a/daemon/ldm.c +++ b/daemon/ldm.c @@ -316,7 +316,7 @@ do_ldmtool_scan_devices (char * const * devices) { char **ret; size_t i, nr_devices; - CLEANUP_FREE_STRING_LIST const

If libmagic isn't installed then the guestfs_file_architecture API doesn't work. This means that inspection will always return <arch>unknown</arch> for every guest. This subtly breaks a few features. In particular it was reported that the virt-builder/virt-customize --install option did not work because the "unknown" architecture of the guest was not compatible

Require qemu >= 1.3.0, the first version that supported `qemu-img --output=json'. This means we require yajl (for parsing the JSON output of qemu-img), and that in turn has consequences elsewhere. --- README | 10 +- builder/Makefile.am | 2 - builder/sources.ml | 9 +- builder/yajl-c.c | 30 ----- builder/yajl.ml | 2 - builder/yajl.mli

After the previous refactoring, we are able to link the daemon to common/utils, and also remove some of the "duplicate" functions that the daemon carried ("duplicate" in quotes because they were often not exact duplicates). Also this removes the duplicate reimplementation of (most) cleanup functions in the daemon, since those are provided by libutils now. It also allows us in

Simply a file rename, no other change. --- daemon/Makefile.am | 2 +- daemon/command.c | 319 ----------------------------------------------------- daemon/sh.c | 319 +++++++++++++++++++++++++++++++++++++++++++++++++++++ po/POTFILES | 2 +- 4 files changed, 321 insertions(+), 321 deletions(-) delete mode 100644 daemon/command.c create mode 100644 daemon/sh.c diff --git

Since all the usage of augeas is done in OCaml parts (via ocaml-augeas), drop all the C code using the C augeas library. --- daemon/Makefile.am | 2 - daemon/augeas.c | 91 --------------------------------------------- daemon/cleanups.c | 11 ------ daemon/daemon.h | 34 ----------------- daemon/lvm-filter.c | 2 - docs/C_SOURCE_FILES | 1 - po/POTFILES | 1 - 7 files

Since all the usage of augeas is done in OCaml parts (via ocaml-augeas), drop all the C code using the C augeas library. --- daemon/Makefile.am | 2 - daemon/augeas.c | 91 --------------------------------------------- daemon/cleanups.c | 11 ------ daemon/daemon.h | 34 ----------------- daemon/lvm-filter.c | 2 - docs/C_SOURCE_FILES | 1 - po/POTFILES | 1 - 7 files

On Tue, Apr 25, 2017 at 12:20:02AM +0300, Matteo Cafasso wrote: > The yara_load API allows to load a set of Yara rules contained within a > file on the host. > > Rules can be in binary format, as when compiled with yarac command, or > in source code format. In the latter case, the rules will be first > compiled and then loaded. > > Subsequent calls of the yara_load API

Proposed patches to fix https://bugzilla.redhat.com/show_bug.cgi?id=858126

The yara_load API allows to load a set of Yara rules contained within a file on the host. Rules can be in binary format, as when compiled with yarac command, or in source code format. In the latter case, the rules will be first compiled and then loaded. Subsequent calls of the yara_load API will result in the discard of the previously loaded rules. Signed-off-by: Matteo Cafasso

When using the direct backend, you should see the result of testing the qemu binary for the availability of KVM: libguestfs: qemu KVM: enabled Thanks: Andrea Bologna. --- lib/guestfs-internal.h | 1 + lib/launch-direct.c | 40 +++++------------- lib/qemu.c | 94 +++++++++++++++++++++++++++++++++++++++++- 3 files changed, 105 insertions(+), 30 deletions(-) diff --git

Hi, I just started with R and I found that there are many options to rearrange the data to do mixed models. I want to use the reshape function. I have 2 between subject variables and one within. I was able to change the data structure but still - the result of the aov functions are calculating everything as a within subject. the table looks like this: SerialNo breed treatment distance_1

Hi everyone, On CentOS 7 I'm running into an issue with the latest nvidia driver from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64 This driver version seem to introduce issue in detecting video modes when a monitor is connected using DVI. As soon as the machine attempts to start X, nothing happens and the monitor goes into sleep mode reporting that it has 'no signal'. It is

On 03/01/18 15:45, Danny Smit wrote: > Hi everyone, > > On CentOS 7 I'm running into an issue with the latest nvidia driver > from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64 > This driver version seem to introduce issue in detecting video modes > when a monitor is connected using DVI. As soon as the machine attempts > to start X, nothing happens and the monitor goes

I've been working on this issue for quite a while. Back in January of 2015 I posted about how well external monitors worked with the out-of-the-box CentOS 7 ATI radeon drivers and my Dell M6500 with an ATI FirePro M7820. At the time the support was seamless and 'Just Worked' without any issue. A few months later, some update came down the pipe and this broke completely, with the