We do have something similar for installing init system files.
Basically I'm trying to avoid the following warning produced by
automake:
tools/Makefile.am:429: warning: uninstall-local was already defined in condition TRUE, which includes condition WITH_BSD_NSS ...
tools/Makefile.am:292: ... 'uninstall-local' previously defined here
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This target has been disabled historically for whatever reason.
Now that we do uninstall properly enable the test again.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function - in contrast with qemuBuildCommandLine - merely
constructs our internal command representation of a domain. This
is then later compared against expected output. Or, this function
is used also in virConnectDomainXMLToNative(). But due to a copy
paste error this function, just like its image - has @forceFips
argument that if enabled forces FIPS, otherwise mimics FIPS state
in the host. If FIPS is enabled or forced the generated command
line is different to state in which FIPS is disabled. Problem is,
while this could be desired in the virConnectDomainXMLToNative()
case, this is undesirable in the test suite as it will produce
unpredicted results.
Solution to this is to rename argument to @enableFips to
specifically tell whether we expect command line to be build in
either of fashions and make virConnectDomainXMLToNative()
implementation fetch FIPS state and pass it to
qemuProcessCreatePretendCmd().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This error message was too specific, based on the incorrect assumption
that any error was cause by auto-added bridges:
failed to create PCI bridge on bus 2: too many devices
with fixed addresses
In practice you can't know if a bridge with an index <= the bus it's
connecting to was added automatically, or if it was a mistake in
explicit config, and the auto-add problem is going to be dealt with in
a different way in an upcoming patch. The new message is this:
PCI Controller at index 1 (0x01) has "
bus='0x02', but bus must be <= index
(note that index is given in both decimal and hex because it is
formatted as decimal in the XML, but bus is formatted as hex, and
displaying the hex value of index makes it easier to see the problem
when index > 9 (which will often be the case with PCIe, since most
controllers only have a single port, not 32 slots as with standard
PCI)).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004593
No need to special-case this one: we can add it to EXTRA_DIST so
that it will be shipped in any case, and if WITH_LOGIN_SHELL
happens to be enabled we mark it for installation as well.
We can't use eg. @sysconfdir@ directly in the .pod file, because
pod2man(1) will interpret that as a variable name and format it
accordingly.
Instead, we use eg. SYSCONFDIR and use a subsequent sed(1) call
to turn it into the expected @sysconfdir@.
The generated man pages may contain information that depend on
the build configuration, so they should not be shipped but
rather always built on the user's machine.
After this commit, all man pages are generated using the same two
steps:
1. Process a source $command.pod file with pod2man(1) to obtain
a valid man page in $command.$section.in
2. Process $command.$section.in with sed(1) to obtain the final
man page in $command.$section
Instead of embedding the pod information inside the respective
source files, store them in separate files.
This allows us to reduce the number of custom build rules as
most of the information can be inferred for the file name;
moreover, text editors are more likely to use proper syntax
highlighting for standalone pod files.
When describing attributes and elements, we mostly stick to
a certain pattern; however, there are a few cases when the
information is not presented in the usual way.
Since there doesn't seem to be any reason not to follow the
tried and true formula, rework those bits to fit the rest of
the documentation.
Commit 61b070cf20 cleaned up a number of cases where the <dt>
element was used to document symbols, but the symbol itself was
not inside a <code> element.
To make sure we don't end up having to clean up again a few
months from now, introduce a syntax-check rule that can spot
such mistakes.
All existing exceptions are marked as such, with either file
or line granularity depending on the case.
libvirt-common.h is generated into builddir/include/libvirt. apibuild.py
only operated on srcdir/inlcude/libvirt. With VPATH build
srcdir/docs/libvirt-libvirt-common.html would not get generated and make
RPM failed.
This unifies the test scripts to all use the similar pattern added for
schematests in ace4aecd. This gives the following
- Enables running all tests from outside of tests/ dir
- Drops redundant abs_* definitions, which are set by test-lib.sh
- Drops unnecessary srcdir variable which was only used for sourcing
test-lib.sh
Behavior changes:
- srcdir can no longer be overwritten, but I don't know why anyone would
really need to...
- Script VERBOSE setting no longer prints commands executed by test-lib.sh.
if anyone cares I suggest handling this in test-lib.sh which already
has other verbose style handling
These old tests expect to run against a real xen connection via
xend running on the host. Our intentions for the test suite are
that it doesn't require interacting with any specific host resources,
so these don't really belong here.
Add bolding for <dt><code> elements to make them "stick out" on the
page rather that just a stream of text where the elements only differ
by slightly different font style.
The values are currently limited to LLONG_MAX which causes some
problems. QEMU conveniently changed their maximum to 1e15 (1 PB) which
is enough for some time and we need to adapt to that so that we don't
throw "Unknown error" messages. Strictly limiting these values actually
fixes some corner case values (off-by-one checks in QEMU probably).
Since values out of the new specified range do not overflow anything,
change the type of error as well.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Store the test list in libvirtd_test_scripts, and use it where
appropriate. This also fixes the fact that we didn't ship
virsh-uriprecedence when libvirtd build is disabled.
$ echo -n 'log_level=1' > ~/.config/libvirt/libvirtd.conf
$ libvirtd --timeout=10
2014-10-10 10:30:56.394+0000: 6626: info : libvirt version: 1.1.3.6, package: 1.fc20 (Fedora Project, 2014-09-08-17:50:42, buildvm-05.phx2.fedoraproject.org)
2014-10-10 10:30:56.394+0000: 6626: error : main:1261 : Can't load config file: configuration file syntax error: /home/rjones/.config/libvirt/libvirtd.conf:1: expecting a value: /home/rjones/.config/libvirt/libvirtd.conf
Rather than try to fix this in the depths of the parser, just catch
the case when a config file doesn't end in a newline, and manually
append a newline to the content before parsing
https://bugzilla.redhat.com/show_bug.cgi?id=1151409
IGMP is used on IPv4 networks tp setup multicast group memberships. On
IPv6, this job is done by Multicast Listener Discovery (MLD), which
uses ICMPv6 packets rather than its own IP protocol number like IGMP.
The nwfilter documentation lists "igmp-ipv6" as one of the possible
protocols, but this is ignored (and stripped from the xml). This patch
removes that erroneous reference.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1038888
According to the dnsmasq manpage, the netmask for IPv4 address ranges
will be auto-deteremined from the interface dnsmasq is listening on,
but it can't do this for IPv6 for some reason - it instead assumes a
network prefix of 64 for all IPv6 address ranges. If this is
incorrect, dnsmasq will refuse to give out an address to clients,
instead logging this message:
dnsmasq-dhcp[2380]: no address range available for DHCPv6 request via virbr0
The solution is for libvirt to add ",$prefix" to all IPv6 dhcp-range
arguments when building the dnsmasq.conf file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1033739
FreeBSD's sed(1) doesn't support using "\n" to insert a newline,
so the installed default.xml file ends up containing a literal
"n" between tags; to work around this problem, add a tr(1)
invocation as suggested by the sed FAQ[1].
[1] http://sed.sourceforge.net/sedfaq4.html (4.1 c)
Michal Privoznik