These are just general purpose D-Bus utils, based on glib and GDBus.
They fit perfectly to libnm-glib-aux. Move the code.
Also, there is already the file "src/core/nm-dbus-utils.c", having two
files with the same name on our source tree is just confusing.
This verifies that what's in our public headers has version nodes, and
that they match Since: tags.
Not pretty (because python) but discovered a *lot* of issues.
Use of conditionals in makefiles needs to be kept to a necessary minimum
otherwise they get out of hand quickly. There's no indentation to aid
reading and conditional chunks longer than a screen and nested ones are
almost impossible to comprehend.
The "if HAVE_INTROSPECTION" part does both.
Let's make it a little less horrible. There's generally no point in
making unused targets or variable assignment unless they collide with
pre-built stuff or have multiple variants.
libnm-core-impl has lots of internal meta data about the properties.
In particular, which properties exist (their names), and their D-Bus
type.
We should use this information for our manual pages. For example,
currently `man nm-settings-dbus` has nonsense like: "Value Type: array
of string", when it should be reall "as".
In a first step, generate an XML with that meta data for later use.
This is the better name, becuse this is not in particular about "docs".
It's about generating an XML with the information from the settings
meta data for nmcli.
We will do something similar with the libnm-core meta data.
It just feels nicer to be explicit about the filenames and
not rely on a specific naming.
Also, in meson we can directly pass the target as argument, which
expands to the filename but also adds a dependency.
On rhel-8.7, we use a different gettext version, so the Makefile
looks different. Adjust patch the source.
Fixes: 7ee0da3eaf ('build: don't "update-po" during make dist')
We currently use the systemd LLDP client, which we consume by forking
systemd code. That is a maintenance burden, because it's not a
self-contained, stable library that we use. Hence there is a need for an
individual library or properly integrating the fork in our tree.
Optimally, we would create a new nettools project with an LLDP library.
That was not done because:
- nettools may want to be dual licensed with LGPL-2.1+ and Apache.
Systemd code is LGPL-2.1+ so it is fine for NetworkManager but
possibly not for nettools.
- nettools provides independent librares, as such they don't have an
event loop, instead they expose an epoll file descriptor and the user
needs to integrate it. Systemd and NetworkManager on the other hand
have their established event loop (sd_event and GMainContext,
respectively). It's simpler to implement the library on those terms,
in particular porting the systemd library from sd_event to
GMainContext.
- NetworkManager uses glib and has various helper utils. While it's
possible to do without them, it's more work.
The main reason to not write a new NetworkManager-agnostic library from
scratch, is that it's much simpler to fork the systemd library and make
it part of NetworkManager, than making it a nettools library.
Do it.
Taken from systemd's "Prioq".
Differences from Prioq:
- It is glib-ized, so certain operations cannot fail since g_malloc()
never fails.
- Unlike Prioq, this structure is stack allocated. I think that makes
sense, because we basically always want to embed the data structure
in another object. There is never a need for passing this around as a
pointer. And if you really want, you can box it yourself.
- The queue either accepts a GCompareFunc or a GComareDataFunc. This
is for convenience. The prioq_ensure_allocated() and
prioq_ensure_put() consequently are dropped, as they would be
cumbersome with this pattern and don't seem useful.
Instead, hack gettext's Makefile.
gettext has an issue with parallel make. See [1] and [2].
Reproduce with:
git reset --hard &&
git clean -fdx &&
NOCONFIGURE=yes ./autogen.sh &&
./configure --enable-gtk-doc --enable-introspection &&
make -j distcheck V=1
We worked around this by setting "DIST_DEPENDS_ON_UPDATE_PO = yes",
however that (obviously) results in regenerating source files during
dist. "Source files" in the sense that the po files are commited to git
and get distributed in the release. Doing this is very ugly.
In particular it's ugly, because `make -C po update-po` is not reproducible
and the output depends on the current time (*had one job*).
Otherwise, we could just regenerate the files before doing a release.
This means, running "release.sh" script ends up with a dirty tree
afterwards. Also, the distributed po files are not the ones from the source
tree when we did the release. Also, since "release.sh rc1" does two distributions
(once for the rc1 and once for the next devel snapshot), the commit for the
second distribution will have a large diff for the po files.
This reverts commit 978d8eb699 ('po: make dist depend on update-po')
and hacks around the problem.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1094#note_1435313
[2] https://lists.gnu.org/archive/html/bug-gettext/2022-06/msg00022.htmlhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1405
"nmp-base.h" really should only contain simple defines like enum types
or #define. As such, it almost does not need a source file.
However, the enum-to-string methods for the enums of "nmp-base.h" need a
place. Add "nmp-base.c" for that.
Our naming in libnm-platform is bad.
We have NMPlatform, which is a cache of objects. Consequently we have
platform methods like nm_platform_get_link().
We also have various other types that share the NMPlatform prefix, like
NMPlatformIP4Address. For those we have nm_platform_ip4_address_to_string().
"methods" of a type should have the same prefix as the type,
and we should not have types that share the same prefix.
Also, "NMPlatformIP4Address" is a long name, and inconsistent with the
strongly related NMPObjectIP4Address.
Add new files to move and rename parts of the platform API.
We already have src/linux-headers, where we have complete copies of linux
user space headers. Of course that exists, because we want to use certain
features and don't depend on the installed kernel headers. Which works
well, because kernel user space API is stable, and we anyway want to
support compiling against a newer kernel and run against an older (e.g.
in a container). So having our copy of newer kernel headers is merely
as if we compiled against as newer kernel.
Add "src/nm-compat-headers" which has a similar purpose, but a different
approach. Instead of replacing the included header entirely, include
the system header and patch it with #define.
Use this for "linux/if_addr.h". Of course, the approach here is that we
no longer include <linux/if_addr.h> directly, but instead include
"nm-compat-headers/linux/if_addr.h".
Imagine checking out the loopback feature branch and building. Thereby the
"src/libnm-client-impl/nm-property-infos-%.xml" files get generated
and contains a `<setting name="loopback"/>`.
Then switch back to `main` branch and type make again. Note that none
of the "src/libnm-core-impl/nm-setting-*.c" files changed, except that
"nm-setting-loopback.c" got removed.
Consequently, the XML won't be regenerated and the followup steps will
fail due to the leftover reference to the non-existing setting.
Fix that by regenerating "nm-property-infos-%.xml" if "libnm-core-impl.la"
changes.
For the ipoib connection, it is still considered as valid if the
profile does not set the device name. Also, the ifcfg reader should not
duplicate the checks that `nm_connection_verify()` performs (especially
not wrongly). Therefore, NM should skip validating the DEVICE when
reading the ifcfg file for the ipoib connection.
https://bugzilla.redhat.com/show_bug.cgi?id=2122703
Improve documentation by preserving paragraphs in the
nm-settings-nmcli man pages.
To do that structure of src/libnm-client-impl/nm-settings-docs-gir.xml
was changed to have "description" as subnode to property node instead
of attribute of property node. Another subnode "description-docbook"
was added - this node is then used when generating man pages.
tools/generate-docs-nm-settings-docs-gir.py and man/nm-settings-dbus.xsl
were also changed to accomodate for changes mentioned above.
Replace xsltproc tool with python script when generating
./src/libnmc-setting/settings-docs.h.
Deleted settings-docs.xsl since it was replaced by python script.
Change src/libnmc-setting/settings-docs.h.in accodring to newly
generated src/libnmc-setting/settings-docs.h
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/661https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1260
Recent gettext version can extract and merge back strings from and to
various file formats, no need for intltool anymore.
https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigrationhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/133https://github.com/NetworkManager/NetworkManager/pull/303https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/96
Clarification about the use of AM_GNU_GETTEXT_REQUIRE_VERSION:
In configure.ac, specify the minimum gettext version we require, rather
than the exact one. This fixes a situation where the autoconf macros
used for gettext will be the latest available on the system (for
example, 0.20); but the copied-in Makefile.in.in will be for the exact
version specified in configure.ac (in this case, 0.19).
In that situation, the gettext build rules will error out at `make` time
with the message:
*** error: gettext infrastructure mismatch: using a Makefile.in.in
from gettext version 0.19 but the autoconf macros are from gettext
version 0.20
Avoid that by specifying a minimum version dependency rather than an
exact one. This should not cause problems as we haven’t committed any
generated or external gettext files into git, so each developer will end
up regenerating the build system for their system’s version of gettext,
as expected.
See the subsection of
https://www.gnu.org/software/gettext/manual/html_node/Version-Control-Issues.html
for more information.
Note that autoreconf currently doesn’t recognise
AM_GNU_GETTEXT_REQUIRE_VERSION, so we must continue also using
AM_GNU_GETTEXT_VERSION. autopoint will ignore the latter if the former
is present. See
https://lists.gnu.org/archive/html/autoconf-patches/2015-10/msg00000.html.
[lkundrak@v3.sk: Fixed the meson build, adjusted autogen.sh:
droped "|| exit 1", dropped call to aclocal,
dropped --copy from gtkdocize.]
The typedefs in nm-types.h confuse gtkdoc-scan. It generates a
libnm-sections.txt file like this:
<SECTION>
<FILE>nm-types</FILE>
<TITLE>NMDeviceOvs</TITLE>
NMAccessPoint
NMActiveConnection
NMCheckpoint
NMClient
NMDevice
...
Note the wrongly picked title and, more importantly, the object types in
a bogus section. This in turn makes gtkdoc-mkdb fail to include the
property and signal documentation in appropriate sections.
Without nm-types.h, we need to mind the header dependencies. This means
that we need to order the headers that define types before the ones that
use them. Also, we need to break the depencency loops in few palces.
This was only for unit testing, to check whether our reader
for "/etc/machine-id" agrees with systemd's.
That unit test was anyway flawed, because it actually accesses
the machine-id on the test system.
Anyway. Drop this. Most likely our parser is good enough, and
if we get a bug report with a defect, we can unit test against
that.
The "unbound" DNS plugin was very rudimentary and is deprecated since
commit 4a2fe09853 ('man: mark [main].dns=unbound as deprecated') (Jun
2021).
It is part of dnssec-trigger tool, but the dnssec-trigger tool doesn't
actually use it. Instead it installs a dispatcher script
"/usr/lib/NetworkManager/dispatcher.d/01-dnssec-trigger".
Especially, since the plugin requires "/usr/libexec/dnssec-trigger-script",
which is provided by "dnssec-trigger" package on Fedora. At the same
time, the package provides the dispatcher script. So I don't this works
or anybody is using this.
https://mail.gnome.org/archives/networkmanager-list/2022-April/msg00002.html
This is long replaced by nettools' n-dhcp4 client.
Drop it.
We still require NMDhcpSystemd for the DHCPv6 client.
Note that "[main].dhcp=systemd" now falls back to the internal client.
But this option was undocumented and internal anyway.
We passed on the CFLAGS, but they also contain
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which causes compiler warnings:
GISCAN src/libnm-client-impl/NM-1.0.gir
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_object_type’:
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:251:13: warning: Not available before 2.70
251 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_fundamental_type’:
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:369:13: warning: Not available before 2.70
369 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
Filter them out.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
Previously, autotools would detect whether we have "black"
in the path. And if so, it would check formatting during `make check`.
That's problematic. When I run `./contrib/fedora/rpm/build_clean.sh -w test`
in certain cases, it would pick up black, but then fail with
Traceback (most recent call last):
File "/usr/bin/black", line 5, in <module>
from black import patched_main
File "/usr/lib/python3.6/site-packages/black.py", line 42, in <module>
from attr import dataclass, evolve, Factory
ModuleNotFoundError: No module named 'attr'
make[3]: *** [Makefile:21658: check-python-black] Error 1
That's an installation error of black, but still, during package build
there is no need to check the formatting. We could export
`NMTST_SKIP_PYTHON_BLACK=1` to prevent it, but it's still unnecessary.
We check proper formatting in gitlab-ci. That is enough, it doesn't
need to run during `make check`. In particular, because `black .`
takes 1.5 seconds on my machine.
libnm-core currently has a dependency on crypto libraries (either
"gnutls", "nss" or "null"). We need this huge dependency for few cases.
Move the crypto code to a separate static library"src/libnm-crypto/libnm-crypto.la".
The reasoning is that it becomes clearer where we have this dependency,
to use it more consciously, and to be better see how it's used.
We clearly need the crypto functionality in libnm. But do we also need
it in the daemon? Could we ever link the daemon without crypto libraries?
The goal of splitting the crypto part out, to better understand the
crypto dependency.
By having a ".md" extension, gitlab renders a nice page instead of
showing as plain text.
Currently our README is pretty bad. Partly, because it doesn't get
shown nicely.
Rename. The file effectively was already markdown. The old file is
gone.
For this we also need to change the automake flavor to "foreign"
(See [1]).
[1] https://autotools.info/automake/options.html#automake.options.flavors
NetworkManager-wait-online is a constant source of confusion,
as it seems to delay the boot (when it's often just the messenger
or either a network problem, a NetworkManager misconfiguration
or a misconfiguration of other systemd services).
Try to clear that up with a manual page.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1130