Commit Graph

235 Commits

Author SHA1 Message Date
Martin Kletzander
b030f47e0f Ignore clangd-related files and folders
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-08-03 10:57:47 +02:00
Pavel Hrdina
7e5d771d17 meson: now we can drop all autoconf related gitignore lines
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-08-03 09:27:09 +02:00
Daniel P. Berrangé
2621d48f00 gnulib: delete all gnulib integration
This deletes all trace of gnulib from libvirt. We still
have the keycodemapdb submodule to deal with. The simple
solution taken was to update it when running autogen.sh.

Previously gnulib could auto-trigger refresh when running
'make' too. We could figure out a solution for this, but
with the pending meson rewrite it isn't worth worrying
about, given how infrequently keycodemapdb changes.

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-02-07 15:03:54 +00:00
Pavel Hrdina
a1a18c6ab5 bootstrap.conf: disable VC ignore files
We already ignore most of these files and the .gitignore files as well.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 16:04:26 +01:00
Pavel Hrdina
71d3098e59 bootstrap.conf: drop gnulib tests from libvirt
We are in process of removing gnulib and adopting meson as our build
system.  In order to help with the transition let's drop gnulib tests.

This will also help with the fact that before we will be able to drop
gnulib completely we will store output of bootstrap in git.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 16:04:26 +01:00
Pavel Hrdina
4753fd0553 src: remote: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
ae98112a85 src: lxc: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
775d08f8c6 src: logging: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
787ea47680 src: locking: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
29b4dda5f5 src: hyperv: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
11a865b9f9 src: esx: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
d6be9e7f65 src: admin: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
b98f90cf91 src: access: generate source files into build directory
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
7b9cd113dc src: generate source files into build directory
This affects more than src/Makefile.am as the rule to generate source
files for protocols is generic for all sub-directories.

Affected files are:
    src/admin/admin_protocol.{h,c}
    src/locking/lock_protocol.{h,c}
    src/logging/log_protocol.{h,c}
    src/lxc/lxc_monitor_protocol.{h,c}
    src/remote/{lxc,qemu,remote}_protocol.{h,c}
    src/rpc/{virkeepalive,virnet}protocol.{h,c}

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:57 +01:00
Pavel Hrdina
8c9ca8a284 po: generate files into build directory
Historically we did not support VPATH builds and everything was
generated into source directory.  The introduction of VPATH builds
did not changed the way how our translation files are handled.

This patch changes the rules to generate everything into build
directory and stops distributing generated files in order to have
properly separated VPATH builds.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:51 +01:00
Pavel Hrdina
f7114e61db .gitignore: cleanup old and obsolete ignores
Now that we forbid builds in source directory we can remove a lot of
ignores that are created during build time.  To make the cleanup easier
in the future create a sections in our .gitignore file.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-08 17:07:50 +01:00
Michal Privoznik
b3739aa63f .gitignore: Ignore src/admin/libvirt_admin.{def,syms}
In v5.8.0-332-g3097282d86 the libvirt-admin.so was moved into
src/admin/ directory. However, corresponding .gitignore change
was left out.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-23 15:10:56 +02:00
Michal Privoznik
7530ebc7b4 bhyve: Ignore test_libvirtd_bhyve.aug
The file is generated during build, but not ignored.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-22 08:58:31 +02:00
Daniel P. Berrangé
fd3b8fe7ad tests: delete objectlocking test code
The object locking test code is not run by any CI tests and has
bitrotted to the point where it isn't worth the effort to try to
fix it.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-10 12:49:52 +01:00
Daniel P. Berrangé
56bd0665c7 build: import gnulib's syntax-check make rules
We're going to be eliminating autotools and gnulib, but we still wish to
have the 'make syntax-check' functionality.

This imports the minimal set of gnulib files required to keep this
working.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-09 13:36:29 +01:00
Andrea Bolognani
ffad19f94c ci: Move everything to a separate directory
We're going to have a few more CI-related files in a second, and
it makes sense to have a separate directory for them rather than
littering the root directory.

$(CI_SCRATCHDIR) can now also be created inside the CI directory,
and as a bonus the make rune necessary to start CI builds without
running configure first becomes shorter.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-21 18:58:13 +02:00
Daniel P. Berrangé
b28fd43a5e vz: introduce virtvzd daemon
The virtvzd daemon will be responsible for providing the vz API
driver functionality. The vz driver is still loaded by the main
libvirtd daemon at this stage, so virtvzd must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
b90e2c3923 bhyve: introduce virtbhyved daemon
The virtbhyved daemon will be responsible for providing the bhyve API
driver functionality. The bhyve driver is still loaded by the main
libvirtd daemon at this stage, so virtbhyved must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
60ee70e93e vbox: introduce virtvboxd daemon
The virtvboxd daemon will be responsible for providing the vbox API
driver functionality. The vbox driver is still loaded by the main
libvirtd daemon at this stage, so virtvboxd must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
23ab0f0bef lxc: introduce virtlxcd daemon
The virtlxcd daemon will be responsible for providing the lxc API
driver functionality. The lxc driver is still loaded by the main
libvirtd daemon at this stage, so virtlxcd must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
bb1021e369 qemu: introduce virtqemud daemon
The virtqemud daemon will be responsible for providing the qemu API
driver functionality. The qemu driver is still loaded by the main
libvirtd daemon at this stage, so virtqemud must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
12e30d1e54 libxl: introduce virtxend daemon
The virtxend daemon will be responsible for providing the libxl API
driver functionality. The libxl driver is still loaded by the main
libvirtd daemon at this stage, so virtxend must not be running at
the same time.

This naming is slightly different than other drivers. With the libxl
driver, the user still has a 'xen:///system' URI, and we provide it
in a libvirt-daemon-xen RPM, which pulls in a
libvirt-daemon-driver-libxl RPM.

Arguably we could rename the libxl driver to "xen" since it is the
only xen driver we have these days, and that matches how we expose it
to users in the URI naming.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
653ddc2e64 nwfilter: introduce virtnwfilterd daemon
The virtnwfilterd daemon will be responsible for providing the nwfilter API
driver functionality. The nwfilter driver is still loaded by the main
libvirtd daemon at this stage, so virtnwfilterd must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
e4de8857ad nodedev: introduce virtnodedevd daemon
The virtnodedevd daemon will be responsible for providing the nodedev API
driver functionality. The nodedev driver is still loaded by the main
libvirtd daemon at this stage, so virtnodedevd must not be running at
the same time.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
e23d5b0435 storage: introduce virtstoraged daemon
The virtstoraged daemon will be responsible for providing the storage API
driver functionality. The storage driver is still loaded by the main
libvirtd daemon at this stage, so virtstoraged must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
62d817a328 interface: introduce virtinterfaced daemon
The virtinterfaced daemon will be responsible for providing the interface API
driver functionality. The interface driver is still loaded by the main
libvirtd daemon at this stage, so virtinterfaced must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
1c27cef1e3 network: introduce virtnetworkd daemon
The virtnetworkd daemon will be responsible for providing the network API
driver functionality. The network driver is still loaded by the main
libvirtd daemon at this stage, so virtnetworkd must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
d353d57fcd secret: introduce virtsecretd daemon
The virtsecretd daemon will be responsible for providing the secret API
driver functionality. The secret driver is still loaded by the main
libvirtd daemon at this stage, so virtsecretd must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
b7ed8ce981 remote: introduce virtproxyd daemon to handle IP connectivity
The libvirtd daemon provides the traditional libvirt experience where
all the drivers are in a single daemon, and is accessible over both
local UNIX sockets and remote IP sockets.

In the new world we're having a set of per-driver daemons which will
primarily be accessed locally via their own UNIX sockets.

We still, however, need to allow for case of applications which will
connect to libvirt remotely. These remote connections can be done as
TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.

In the later case, the old libvirt.so clients will only know about
the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
and not the new driver sockets /var/run/libvirt/virtqemud-sock.

It is also not desirable to expose the main driver specific daemons
over IP directly to minimize their attack service.

Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
and back compat for the old libvirtd UNIX socket path(s). It will then
forward all RPC calls made to the appropriate driver specific daemon.

Essentially it is equivalent to the old libvirtd with absolutely no
drivers registered except for the remote driver (and other stateless
drivers in libvirt.so).

We could have modified libvirtd so none of the drivers are registed
to get the same end result. We could even add a libvirtd.conf parameter
to control whether the drivers are loaded to enable users to switch back
to the old world if we discover bugs in the split-daemon model. Using a
new daemon though has some advantages

 - We can make virtproxyd and the virtXXXd per-driver daemons all
   have "Conflicts: libvirtd.service" in their systemd unit files.
   This will guarantee that libvirtd is never started at the same
   time, as this would result in two daemons running the same driver.
   Fortunately drivers use locking to protect themselves, but it is
   better to avoid starting a daemon we know will conflict.

 - It allows us to break CLI compat to remove the --listen parameter.
   Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
   will default to zero. Either TLS or TCP can be enabled exclusively
   though virtd.conf without requiring the extra step of adding --listen.

 - It allows us to set a strict SELinux policy over virtproxyd. For
   back compat the libvirtd policy must continue to allow all drivers
   to run. We can't easily give a second policy to libvirtd which
   locks it down. By introducing a new virtproxyd we can set a strict
   policy for that daemon only.

 - It gets rid of the weird naming of having a daemon with "lib" in
   its name. Now all normal daemons libvirt ships will have "virt"
   as their prefix not "libvirt".

 - Distros can more easily choose their upgrade path. They can
   ship both sets of daemons in their packages, and choose to
   either enable libvirtd, or enable the per-driver daemons and
   virtproxyd out of the box. Users can easily override this if
   desired by just tweaking which systemd units are active.

After some time we can deprecate use of libvirtd and after some more
time delete it entirely, leaving us in a pretty world filled with
prancing unicorns.

The main downside with introducing a new daemon, and with the
per-driver daemons in general, is figuring out the correct upgrade
path.

The conservative option is to leave libvirtd running if it was
an existing installation. Only use the new daemons & virtproxyd
on completely new installs.

The aggressive option is to disable libvirtd if already running
and activate all the new daemons.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
5f449aea19 remote: conditionalize IP socket config in augeas definitions
Prepare for reusing libvirtd augeas defintions with other daemons by
making the config parameters for IP sockets conditionally defined by
the make rules.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
6d9e520db6 remote: conditionalize IP socket config in libvirtd.conf
Prepare for reusing libvirtd config to create other daemons by making
the config parameters for IP sockets conditionally defined by the make
rules.

The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
2cdabb1761 build: create all augeas test files in same dir as their source
The current make rules are inconsistent about which directory the
augeas test files are created in. Put them all in the same dir as
their source.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:05:06 +01:00
Daniel P. Berrangé
4feeb2d986 tools: split virt-login-shell into two binaries
The virt-login-shell binary is a setuid program that takes
no arguments. When invoked it looks at the invoking uid,
resolves it to a username, and finds an LXC guest with the
same name. It then starts the guest and runs the shell in
side the namespaces of the container.

Given this set of tasks the virt-login-shell binary needs
to connect to libvirtd, make various other libvirt API calls.
This is a problem for setuid binaries as various libraries
that libvirt.so links to are not safe. For example, they have
constructor functions which execute an unknown amount of code
that can be influenced by env variables.

For this reason virt-login-shell doesn't use libvirt.so,
but instead links to a custom, cut down, set of source files
sufficient to be a local client only.

This introduces a problem for integrating glib2 into libvirt
though, as once integrated, there would be no way to build
virt-login-shell without an external dependancy on glib2 and
this is definitely not setuid safe.

To resolve this problem, we split the virt-login-shell binary
into two parts. The first part is setuid and does almost
nothing. It simply records the original uid+gid, and then
invokes the virt-login-shell-helper binary. Crucially when
it does this it completes scrubs all environment variables.
It is thus safe for virt-login-shell-helper to link to the
normal libvirt.so. Any things that constructor functions
do cannot be influenced by user control env vars or cli
args.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-07 16:54:01 +01:00
Andrea Bolognani
571cb9db30 examples: Group all C programs together
All other examples are organized using the either the format/
or the format/category/ hierarchy already, and grouping all
C programs together removes the last remaining outliers.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-03 17:27:43 +02:00
Andrea Bolognani
4ebefac793 examples: Organize C examples into categories
Most C examples live in their own directory, which seems a
bit unnecessary especially considering that all virt-admin
related examples share a single admin/ directory. Reorganize
non-admin C examples in two categories: domain/ for those
that act on a domain, and misc/ for everything else.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-03 17:27:37 +02:00
Daniel P. Berrangé
89f8902a68 tests: add targets for building libvirt inside Docker containers
The Travis CI system uses Docker containers for its build environment.
These are pre-built and hosted under quay.io/libvirt so that developers
can use them for reproducing problems locally.

Getting the right Docker command syntax to use them, however, is not
entirely easy. This patch addresses that usability issue by introducing
some make targets. To run a simple build (aka 'make all') using the
Fedora 28 container:

   make ci-build@fedora-28

To also run unit tests

   make ci-check@fedora-28

This is just syntax sugar for calling the previous command with a
custom make target

   make ci-build@fedora-28 CI_MAKE_ARGS="check"

To do a purely interactive build it is possible to request a shell

   make ci-shell@fedora-28

To do a MinGW build, it is currently possible to use the fedora-rawhide
image and request a different configure script

   make ci-build@fedora-rawhide CI_CONFIGURE=mingw32-configure

It is also possible to do cross compiled builds via the Debian containers

   make ci-build@debian-9-cross-s390x

In all cases the GIT source tree is cloned locally into a 'ci-tree/src'
sub-directory which is then exposed to the container at '/src'. It is
setup to use a separate build directory so the build takes place in a
subdir '/src/build'. A source tree build can be requested instead
by passing an empty string CI_VPATH= arg to make.

The make rules are kept in a standalone file that is included into the
main Makefile.am, so that it is possible to run them without having to
invoke autotools first.

It is neccessary to disable the gnulib submodule commit check because
this fails due to the way we have manually cloned submodule repos as
primary git repos with their own .git directory, instead of letting
git treat them as submodules in the top level .git directory.

  make[1]: Entering directory '/src/build'
  fatal: Not a valid object name origin
  fatal: run_command returned non-zero status for .gnulib
  .
  maint.mk: found non-public submodule commit
  make: *** [/src/maint.mk:1448: public-submodule-commit] Error 1

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-11 18:38:56 +01:00
Cole Robinson
fb0d6049cc docs: Remove search.php and all references
libvirt.org/search.php drops into some kind of screen which I guess
is supposed to show a search bar with options, but presently for me
renders as nothing but the following text:

Search the documentation on Libvirt.org

The search service indexes the libvirt APIs and documentation as well as the libvir-list@redhat.com mailing-list archives. To use it simply provide a set of keywords:

The main page search bar now redirects to google, this page is broken,
I say we just remove it and move on.

Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-04-04 18:45:06 -04:00
Andrea Bolognani
ce97c33a79 maint: Stop generating ChangeLog from git
Our ChangeLog is generated by basically redirecting the output
of 'git log' into it so, as can be expected, it has only gotten
bigger as development has progressed. As of today, its size has
reached pretty much comical levels:

  $ du -sk ChangeLog
  11328 ChangeLog

All of that for information *literally nobody* cares about: end
users and distro maintainers have proper release notes lovingly
compiled for them, while developers peruse the history either by
calling 'git log' directly or through their favorite $EDITOR's
git integration.

Replacing the generated ChangeLog with a short message pointing
interested parties to the git repository does not only reduce
the size of the unpacked sources from 259904 KiB to 248576 KiB
(~4% saving): from a quick test on my laptop, doing so reduces
the size of the *compressed* release archive from 15140 KiB to
12364 KiB (~18% saving) and also takes the time needed to run
'make distcheck' down from 4:44 to 4:21 (~8% saving).

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-03 09:45:25 +02:00
Andrea Bolognani
912fe2df9d Drop support for "Red Hat" init scripts
Despite the misleading name, these were supposed to be used
with a System V style init; however, none of the platforms we
target is using that kind of init anymore: almost all Linux
distributions have switched to systemd, those that haven't
(such as Gentoo and Alpine) are mostly using OpenRC with
custom init scripts, and the BSDs have been doing their own
thing all along.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-15 18:36:19 +01:00
Michal Privoznik
a87a75e579 tools: Keep wireshark plugin registration code in git
In order to be able to dissect libvirt protocol the wireshark
plugin needs to be registered. So far this plugin registration
code was generated on every build using a script that was copied
over from wireshark's tools/ directory.

This is suboptimal, because the way that plugins register changes
across wireshark releases. Therefore, let's keep the generated
file in the git, put the command line used to generate the file
into a comment and remove the script.

This solution allows us to put different registration mechanism
into one file (under #ifdef-s) and thus compile with wider range
of wireshark releases.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 09:22:59 +01:00
Daniel P. Berrangé
a3857dbeeb po: minimize & canonicalize translations stored in git
Similar to the libvirt.pot, .po files contain line numbers and file
names identifying where in the source a translatable string comes from.
The source locations in the .po files are thrown away and replaced with
content from the libvirt.pot whenever msgmerge is run, so this is not
precious information that needs to be stored in git.

When msgmerge processes a .po file, it will add in any msgids from the
libvirt.pot that were not already present. Thus, if a particular msgid
currently has no translation, it can be considered redundant and again
does not need storing in git.

When msgmerge processes a .po file and can't find an exact existing
translation match, it will try todo fuzzy matching instead, marking such
entries with a "# fuzzy" comment to alert the translator to take a
look and either discard, edit or accept the match. Looking at the
existing fuzzy matches in .po files shows that the quality is awful,
with many having a completely different set of printf format specifiers
between the msgid and fuzzy msgstr entry. Fortunately when msgfmt
generates the .gmo, the fuzzy entries are all ignored anyway. The fuzzy
entries could be useful to translators if they were working on the .po
files directly from git, but Libvirt outsourced translation to the
Fedora Zanata system, so keeping fuzzy matches in git is not much help.

Finally, by default msgids are sorted based on source location. Thus, if
a bit of code with translatable text is moved from one file to another,
it may shift around in the .po file, despite the msgid not itself changing.
If the msgids were sorted alphabetically, the .po files would have
stable ordering when code is refactored.

This patch takes advantage of the above observations to canonicalize
and minimize the content stored for .po files in git. Instead of storing
the real .po files, we now store .mini.po files.

The .mini.po files are the same file format as .po files, but have no
source location comments, are sorted alphabetically, and all fuzzy
msgstrs and msgids with no translation are discarded. This cuts the size
of content in the po directory from 109MB to 19MB.

Users working from a libvirt git checkout who need the full .po files
can run "make update-po", which merges the libvirt.pot and .mini.po
file to create a .po file containing all the content previously stored
in git.

Conversely if a full .po file has been modified, for example, by
downloading new content from Zanata, the .mini.po files can be updated
by running "make update-mini-po". The resulting diffs of the .mini.po
file will clearly show the changed translations without any of the noise
that previously obscured content. Being able to see content changes
clearly actually identified a bug in the zanata python client where it
was adding bogus "fuzzy" annotations to many messages:

  https://bugzilla.redhat.com/show_bug.cgi?id=1564497

Users working from libvirt releases should not see any difference in
behaviour, since the tarballs only contain the full .po files, not the
.mini.po files.

As an added benefit, generating tarballs with "make dist", will no
longer cause creation of dirty files in git, since it won't touch the
.mini.po files, only the .po files which are no longer kept in git.

To avoid creating a single commit 100+MB in size, each language is
minimized separately in a following commit.

Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-19 11:11:08 +01:00
Daniel P. Berrangé
c0a8ea450d po: provide custom make rules for po file management
Historically we have relied on autopoint/gettextize to install a
standard po/Makefile.in.in. There is very limited scope for customizing
this and it also causes a bunch of extra stuff to be pulled into
configure.ac which potentially clashes with gnulib. Writing make rules
for po file management is no more difficult than any other rules libvirt
has, so stop using autopoint/gettextize.

Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-19 10:35:58 +01:00
Ján Tomko
ab20f5059c Do not generate polkit rules file
This essentially reverts commit <e1019e9>, which added
an extra step for generating the policy file.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-03-14 12:46:26 +01:00
Daniel P. Berrangé
3f055b5997 daemon: move logrotate files to src/remote/
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-02-22 12:26:57 +00:00
Daniel P. Berrangé
21ea3828f7 daemon: move misc libvirtd policy files to src/remote/
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-02-22 12:26:50 +00:00