Better fix for https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/732
The original issue was that when compiling NetworkManager with slibtool
the create-exports-NetworkManager.sh script gave the NetworkManager-all-sym
slibtool wrapper script to nm(1) instead of the actual binary. This is
because slibtool and GNU libtool do not place the compiled programs in
the same location. The original fix was to test both locations, but this
is bit of a hack especially since the build system should not be using the
.libs directory directly. However with $(LIBTOOL) --mode=execute this is
not a problem since both implementations can figure out where the correct
binary is.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/805
initscripts don't support "$VLAN_ID". They actually support "$VID",
which NetworkManager doesn't.
"$VLAN_ID" was introduced by commit 10b32be37b ('ifcfg-rh: various VLAN
cleanups'). It has a comment about "backward compatibility" for the case
where the reader would ignore "$VLAN_ID" if "$DEVICE"'s name contains
a suffix that is parsable as VLAN ID.
That is wrong. If a new feature gets introduce (like NetworkManager
supporting "$VLAN_ID"), then there is no way that an older version of the
tool -- which doesn't know the new feature yet (initscripts) -- supports it.
This is not what backward compatibility means. Backward compatibility
means that if a user has an old ifcfg-file without "$VLAN_ID", then we
continue parsing it as before.
Consider, when a user (or NetworkManager) writes a configuration
DEVICE=vlan9
PHYSDEV=eth0
VLAN_ID=10
then it makes no sense to ignore VLAN_ID=10 and use "9" instead.
Otherwise the user (or NetworkManager) should not have written the
file this way.
Also, NetworkManager profiles support "connection.interface-name=vlan9"
together with "vlan.id=10". Such a configuration is valid and must be
expressible in ifcfg-rh format. The ifcfg-rh writer code did not somehow
restrict the setting of "$VLAN_ID" to account for this odd behavior. Whenever
NetworkManager in the past wrote VLAN_ID variable to file, it really meant
it.
https://bugzilla.redhat.com/show_bug.cgi?id=1907960https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/794
In file included from ./src/libnm-glib-aux/nm-default-glib.h:11:0,
from ./src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13,
from src/libnm-log-null/nm-logging-null.c:6:
./src/libnm-std-aux/nm-default-std.h:32:26: fatal error: config-extra.h: No such file or directory
#include "config-extra.h"
^
compilation terminated.
make[1]: *** [src/libnm-log-null/src_libnm_log_null_libnm_log_null_la-nm-logging-null.lo] Error 1
We should write our CONTRIBUTING files in markdown syntax, because
it's nice to read a plain text and gets nicely rendered.
However, if the file doesn't have a ".md" extension, gitlab's
web interface shows it as plain text file.
Rename the file.
This possibly breaks links like [1], but referring to a branch name
(and not a commit ID or a tag) is anyway fragile. Hence, I don't try
to fix that by adding a symlink or similar, because I think that just
makes it more confusing.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/CONTRIBUTING
CC src/libnm-platform/wifi/libnm_platform_la-nm-wifi-utils-wext.lo
In file included from ../src/libnm-platform/wifi/nm-wifi-utils-wext.c:7:
In file included from ../src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13:
In file included from ../src/libnm-glib-aux/nm-default-glib.h:11:
../src/libnm-std-aux/nm-default-std.h:30:10: fatal error: config-extra.h file not found
#include "config-extra.h"
^~~~~~~~~~~~~~~~
...
GEN config-extra.h
Note that "test-client.py" currently only tests nmcli. But what it does
is to spawn test-networkmanager-service.py and run nmcli against it.
As such, it could really be used to test any NetworkManager client
against the stub service. Hence this test is not under
"src/nmcli/tests", but under "src/tests/client/" where it is more
general.
Note that we take defines from "src/core/nm-config.h" which
are GPL-2.0-or-later licensed.
libnm-base we want to include in other LGPL licensed sources,
we it must also be LGPL.
"relicense" the code that I take. I don't think it's a problem, because:
- these are only plain defines. To which extend is that even
copyrightable?
- as far as I see, all the code was contributed by people who agreed
to such relicensing. See RELICENSE.md file.
Internally we set CPPFLAGS, because setting CFLAGS disables inheriting AM_CFLAGS --
which we use for example for "-Wno-pragmas" from the configure script.
"nm-compat.h" is not intended to be used by NetworkManager itself.
Instead, it's intended to be copied into the source tree of VPN plugins,
as adapter for different libnm versions.
Move it to "src/contrib/".
This file was intended to be used by VPN plugins (by copying it).
However, it was also used internally.
Split the file, and move the internally used part to libnm-glib-aux.
The part that is only there for out of tree users, moves to
"nm-compat.h".
This file is not actually to be used by NetworkManager itself.
Instead, every (glib based) VPN plugin will want something like this,
hence we have a copy here.
Move it to a new directory "src/contrib/".
This helper code is already used by several of our unit tests.
Compile it as a separate library.
Previously, the source code lingered unmotivated under "shared/",
which is confusing.
"nm-test-utils.h" is a header-only, helper library for our unit tests.
It was somewhat unmotivated in "shared/nm-utils", because all tests use
it, but it was not part of a "module".
Move it to "src/libnm-glib-aux/". It fits there very well. They both
have (only) a dependency on glib.
This is really just a different implementation of
"nm-glib-aux/nm-logging-fwd.h", that parallels libnm-log-core.
It's also not only useful to shared/systemd, but also share/nm-platform,
which also requires linking with a logging backend.
glib requires G_LOG_DOMAIN defined so that log messages are labeled
to belong to NetworkManager or libnm.
However, we don't actually want to use glib logging. Our library libnm
MUST not log anything, because it spams the user's stdout/stderr.
Instead, a library must report notable events via its API. Note that
there is also LIBNM_CLIENT_DEBUG to explicitly enable debug logging,
but that doesn't use glib logging either.
Also, the daemon does not use glib logging instead it logs to syslog.
When run with `--debug`.
Hence, it's not useful for us to define different G_LOG_DOMAIN per
library/application, because none of our libraries/applications should
use glib logging.
It also gets slightly confusing, because we have the static library like
`src/libnm-core-impl`, which is both linked into `libnm` (the library)
and `NetworkManager` (the daemon). Which logging domain should they use?
Set the G_LOG_DOMAIN to "nm" everywhere. But no longer do it via `-D`
arguments to the compiler.
See-also: https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.
Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.
The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.