Otherwise, we will try to install "src/nm-dispatcher/nm-dispatcher.conf"
to "/usr/share/dbus-1/system.d", which is not correct, when we want a separate
prefix.
- also accept empty value to autodetect. This makes it similar
to what is done with meson.
- log the chosen udev-dir.
- use ${prefix} instead of $(prefix). It's usually used at other
places.
Fixes this error:
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
./configure: line 30294: ,as_fn_error: command not found
checking for a Python interpreter with version >= 3... python
checking for python... /usr/bin/python
Fixes: 3affccf29b ('tests: fix undefined references to pthread')
(cherry picked from commit a8284b1d3b)
Fixes this error:
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
./configure: line 30294: ,as_fn_error: command not found
checking for a Python interpreter with version >= 3... python
checking for python... /usr/bin/python
Fixes: 3affccf29b ('tests: fix undefined references to pthread')
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
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.
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
Currently it is possible to specify a list of default settings plugins
to be used when configuration doesn't contain the main.plugins key.
We want to add a mechanism that allows to automatically load any
plugin found in the plugins directory without needing
configuration. This mechanism is useful when plugins are shipped in a
different, optional subpackage, to automatically use them.
With such mechanism, the actual list of plugins will be determined
(in order of evaluation):
1. via explicit user configuration in /etc, if any
2. via distro configuration in /usr, if any
3. using the build-time default, if any
4. looking for known plugins in /usr/lib
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
Ask systemd instead of hardcoding the path. While this is a bit nicer,
it should have precisely zero effect as the discovered path should be
the same as we were hard-coding.
We default to placing the unit file under the same $prefix as the user is
installing into. This seems to be the correct thing to do if the user is
installing to /usr/local (according to systemd-path(1),
/usr/local/lib/systemd/system is all right), but can install the unit
file into wrong path if the user chooses to install into some obscure
location. I guess it's their responsibility in the end.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1101
- `m4/ax_lib_readline.m4` was already aware of "$with_readline".
Move the entire handling of the parameter inside the AX_LIB_READLINE
macro.
This lets our fork of ax_lib_readline.m4 further deviate from upstream
version, but it's already so different that this is no new problem.
- raise an error if the user requested --with-readline=libreadline|libedit
but the library was not found.
- only allow yes|no for --with-nmcli argument. But still default to
"yes", which will always require one libreadline library to be
detected. In particular, don't automatically disable nmcli if
libreadline is not available, because building without nmcli
should be an explicit choice. That is like before.
- update the "$with_readline" variable for the "auto" case to reflect
what was detected.
This commit provides support for --with-readline=auto|libreadline|libedit|none option
for the configure script.
It allows building the NetworkManager's nmcli tool with libedit instead
of libreadline.
With --with-readline=auto the system looks for any eligible readline library
to use.
Moreover, in this commit all required defines are provided (e.g.
HAVE_EDITLINE_READLINE) to allow correct buil of the code.
The goal of this code is to detect python, but prefer python3 while
also allowing the user to override the path.
That did not work in all cases, due to what seems like a bug in
AM_PATH_PYTHON(). AM_PATH_PYTHON() is documented to ignore failure
if [action-if-not-found] is given. So one might assume that:
AM_PATH_PYTHON([3], [], [PYTHON=])
if test -z "$PYTHON"; then
AM_PATH_PYTHON([], [], [PYTHON=python])
fi
first tries to look for v3, and if that fails search for any python
interpreter. That did not work however with:
$ ./configure PYTHON=/usr/bin/python2
...
checking pkg-config is at least version 0.9.0... yes
checking whether /usr/bin/python2 version is >= 3... no
configure: error: Python interpreter is too old
because the first AM_PATH_PYTHON() is fatal.
Work around that.
Fixes: 54a1cfa973 ('build: prefer python3 over python2 in autotools's configure script')
"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.
Add new configure option to set the path to "polkit-agent-helper-1".
The path cannot be obtained from pkg-config and `pkg-config
--variable=prefix polkit-agent-1` is not good enough.
On Fedora, the path is "/usr/lib/polkit-1/polkit-agent-helper-1".
On Debian Buster, the path is "/usr/lib/policykit-1/polkit-agent-helper-1"
On Debian Sid, the path is "/usr/libexec/polkit-agent-helper-1" (but
currently it is also symlinked from "/usr/lib/policykit-1/polkit-agent-helper-1".
(cherry picked from commit 801c41a11c)
Add new configure option to set the path to "polkit-agent-helper-1".
The path cannot be obtained from pkg-config and `pkg-config
--variable=prefix polkit-agent-1` is not good enough.
On Fedora, the path is "/usr/lib/polkit-1/polkit-agent-helper-1".
On Debian Buster, the path is "/usr/lib/policykit-1/polkit-agent-helper-1"
On Debian Sid, the path is "/usr/libexec/polkit-agent-helper-1" (but
currently it is also symlinked from "/usr/lib/policykit-1/polkit-agent-helper-1".
"nm-version-macros.h" is used directly by libnm-core and indirectly by
libnm and core.
Let's not have it randomly under shared/. Move it closer to where it's
used.
Add a new `main.rc-manager=auto` setting, that favours to use
systemd-resolved (and not touch "/etc/resolv.conf" but configure
it via D-Bus), or falls back to `resolvconf`/`netconfig` binaries
if they are installed and enabled at compile time.
As final fallback use "symlink", like before.
Note that on Fedora there is no "openresolv" package ([1]). Instead, "systemd"
package provides "/usr/sbin/resolvconf" as a wrapper for systemd-resolved's
"resolvectl". On such a system the fallback to resolvconf is always
wrong, because NetworkManager should either talk to systemd-resolved
directly or not but never call "/usr/sbin/resolvconf". So, the special handling
for resolvconf and netconfig is only done if NetworkManager was build with these
applications explicitly enabled.
Note that SUSE builds NetworkManager with
--with-netconfig=yes
--with-config-dns-rc-manager-default=netconfig
and the new option won't be used there either. But of course, netconfig
already does all the right things on SUSE.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=668153
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
On Debian sid, pygobject no longer builds "python-gobject" for
python2. Still, python2 may be installed and detected preferably
by AM_PATH_PYTHON(). Add workaround.
