I am pleased to announce that a new release of the libvirt-glib package, version 5.0.0, is now available from
https://libvirt.org/sources/glib/
The packages are GPG signed with
Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
Changes in this release:
- Fix compatiblity with libxml2 >= 2.12.0
- Bump min libvirt version to 2.3.0
- Bump min meson to 0.56.0
- Require use of GCC >= 4.8 / CLang > 3.4 / XCode CLang > 5.1
- Mark USB disks as removable by default
- Add support for audio device backend config
- Add support for DBus graphics backend config
- Add support for controlling firmware feature flags
- Improve compiler flag handling in meson
- Extend library version script handling to FreeBSD
- Fix pointer sign issue in capabilities config API
- Fix compat with gnome.mkenums() in Meson 0.60.0
- Avoid compiler warnings from gi-ir-scanner generated code by not setting glib version constraints
- Be more robust about NULL GError parameters
- Disable unimportant cast alignment compiler warnings
- Use ‘pragma once’ in all header files
- Updated translations
Thanks to everyone who contributed to this new release.
I am pleased to announce that a new release of the libvirt-glib package, version 4.0.0, is now available from
https://libvirt.org/sources/glib/
The packages are GPG signed with
Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
Changes in this release:
- Replace autotools build system with meson
- Mandate libvirt >= 1.2.8
- Mandate libxml2 >= 2.9.1
- Mandate glib >= 2.48.0
- Mandate gobject-introspection >= 1.46.0
- Fix docs incompatibility with gtk-doc >= 1.30
- Updated translations
- Misc API docs fixes
- Add constants related to NVRAM during domain delete
- Add domain config API for controller ports attribute
- Fix compat with newer glib by avoid volatile for enum types
Thanks to everyone who contributed to this new release.
I am pleased to announce that a new release of the libvirt-glib package, version 3.0.0, is now available from
https://libvirt.org/sources/glib/
The packages are GPG signed with
Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
Changes in this release:
- Add support for bochs video device
- Add API to query firmware config
- Improve testing coverage
- Validate min/max glib API versions in use
- Remove deprecated G_PARAM_PRIVATE
- Fix docs build linking problems
- Convert python demos to be python 3 compatible & use modern best practice for pyobject introspection bindings
- Add API to query domain capaibilities
- Refresh translations
- Simplify build process for handling translations
- Fix some memory leaks
- Add API for setting storage volume features
Thanks to everyone who contributed to this new release through testing, patches, bug reports, translations and more.
I am pleased to announce that a new release of the libvirt-glib package, version 1.0.0, is now available from
https://libvirt.org/sources/glib/
The packages are GPG signed with
Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
Changes in this release:
- Switch to new release numbering scheme, major digit incremented each year, minor for each release, micro for stable branches (if any)
- Fix Libs.private variable in pkg-config file
- Fix git introspection warnings
- Add ability to set SPICE gl property
- Add support for virtio video model
- Add support for 3d accel property
- Add support for querying video model
- Add support for host device config for PCI devs
- Add docs for more APIs
- Avoid unused variable warnings
- Fix check for libvirt optional features to use pkg-config
- Delete manually written python binding. All apps should use PyGObject with gobject introspection.
- Allow schema to be NULL on config objects
- Preserve unknown devices listed in XML
- Add further test coverage
libvirt-glib comprises three distinct libraries:
- libvirt-glib – Integrate with the GLib event loop and error handling
- libvirt-gconfig – Representation of libvirt XML documents as GObjects
- libvirt-gobject – Mapping of libvirt APIs into the GObject type system
NB: While libvirt aims to be API/ABI stable forever, with libvirt-glib we are not currently guaranteeing that libvirt-glib libraries are permanently API/ABI stable. That said we do not expect to break the API/ABI for the forseeable future and will always strive avoid it.
Follow up comments about libvirt-glib should be directed to the regular libvir-list@redhat.com development list.
Thanks to all the people involved in contributing to this release.
The historical philosophy of libvirt is for all our core libraries to be written in C and then create bindings to other programming languages or mappings to alternative object models. Thus far we have bindings to Python, Perl, Ruby, OCaml, Php, C#, Java and mappings to the QMF (Matahari), CIM and SNMP object models. The virt-install and virt-manager applications use the python binding to libvirt, but even very early in development of virt-manager it was clear that the libvirt python API is not a natural fit for an application using GTK, since it does not integrate with GObject and in particular GObject signals. Thus virt-manager wraps the libvirt python objects to create real GObjects it then works with. This has been quite successful, but because all the virt-manager code is in python other applications have not been able to take advantage of the higher level libvirt API virt-manager has evolved. In addition the virt-install code (which is called internally by virt-manager) contains a set of Python objects which represent the various libvirt XML schemas as plain old objects with properties and setters/getters. If you’ve developed applications against libvirt, you’ll likely appreciate just how useful such an API would be. Again though, because the API is in Python and (technically) internal to the virt-install codebase, it is not accessible to many other applications
There was clearly space for an independent library mapping the libvirt API and XML schemas to GObject, which could then be used by any application. The task of creating a libvirt GObject library API is large enough, without considering the task of also ensuring it is accessible from all the non-C programming languages. Fortunately, with the release of GNOME-3, GObject introspection has now matured to the point where it can really be used in anger for real application development. The upshot is that it is now feasible to attempt development of a proper libvirt GObject API.
The libvirt-glib package is the result, and it actually contains three related libraries
- libvirt-gib – non-object based glue code between GLib and libvirt. In particular this has APIs to convert libvirt virErrorPtr instances into GError instances, and provides an implementation of the libvirt event loop contract, using the GLib GMain APIs.
- libvirt-gconfig – object based APIs which map libvirt XML documents/schemas into GObject classes. This library explicitly has no direct link to the libvirt API, solely concerning itself with XML management. This is to allow use of libvirt-gconfig from applications which are using one of the object mappings like QMF/CIM/SNMP, instead of the direct libvirt API. This where the current virt-install XML handling objects will be replicated
- libvirt-gobject – object based APIs which map libvirt types and APIs into GObject classes. This library depends on libirt-glib and libvirt-gconfig, and is where the current virt-manager object mapping APIs will be replicated. This library is also adopting the GIO paradigm for allowing asynchronous API invocation & completion, for long running applications. This eliminates much of the need for applications to explicitly use threads (thread usage is hidden behind the async API impl).
From day 1, all the APIs are being developed with GObject introspection in mind., so all methods are fully annotated, and we are generating the glue layer for Vala bindings as standard in order to support the GNOME Boxes application. It is still very early days for development and very little of the libvirt API has been mapped into GObject thus far and work is only just starting on the XML object mappings. The overall target, however, is to develop the library to the state where it can support the aforementioned GNOME Boxes application in Fedora 17, as well as an application sandbox framework I am developing for Fedora 17 (more on that in a later blog post).
For more information