g-ir-scanner does not support building with clang, due to [1], [2], [3].
It triggers
checking if /usr/bin/g-ir-scanner works... no (compiler failure -- check config.log)
configure: error: introspection enabled but can't be used
with
clang-7: error: unknown argument: '-fstack-clash-protection'
See also commit 99b92fd992, which adds this configure
check.
Honor the environment variable WITH_DOCS to allow the caller to overwrite
the automatic detection that the script does.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=757934
[2] https://gitlab.gnome.org/GNOME/gobject-introspection/issues/150
[3] c14d037228
To run the tests with python3, we need python3-gobject.
Note that "contrib/fedora/REQUIRED_PACKAGES" is called by
"contrib/scripts/nm-ci-run.sh" script to install the packages
in Fedora.
Currently, default-routes cannot be added like regular static-routes
as ipv4.routes setting.
Instead, one has to configure "ipv4.gateway" and "ipv4.never-default".
That of course should be fixed, for example to configure a default-route
in different routing tables.
As it is, both nmcli's parse function and libnm's
NMSettingIPConfig:verify() functions reject default-routes.
But nmcli goes way beyond that, it also rejects all networks with
"0.0.0.0"/"::" even if their prefix length is not zero. Such routes are
not default-routes, and nmcli has no business rejecting them. The
correct way for checking for a default-route is to check the prefix-length
for zero.
Drop the wrong validation in nmcli.
Note, it may still not be the best idea to add catch-all routes like
"0.0.0.0/1" and "128.0.0.0/1". It just defeats what counts as a default-route.
NM has other means (like configuring the route-metric) to handle routing
in face of multiple interfaces. But sure, whatever works for you.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/114https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/75
Otherwise the following fails:
$ ./contrib/fedora/rpm/build_clean.sh -g -s x.1
...
error: parse error in expression
error: /data/src/_NetworkManager/contrib/fedora/rpm/NetworkManager.20190207-165257.XOkW4i/SPECS/NetworkManager.spec:35: bad %if condition
ERROR: rpmbuild FAILED
Even with the fix, not all characters are allowed:
$ ./contrib/fedora/rpm/build_clean.sh -g -s x-1
...
error: line 112: Illegal char '-' (0x2d) in: Release: 22165.x-1.25b13e2053.fc29
ERROR: rpmbuild FAILED
We need to build libnm-core first. Especially, because libnm
sources require the "libnm-core/nm-core-enum-types.h" header
to be generated first.
Add a missing dependency.
"libnm/fake-typelib/meson.build" modifies the variable "sources",
which is defined by the outer "libnm/meson.build" file.
That is confusing. If a variable is not only used within one "meson.build"
file alone, it should have a unique name. Rename the variable to
"libnm_utils_sources".
Also avoid local variable "deps" which is only used at one place.
Just calling nm_connection_verify() is not correct. We need
nm_connection_normalize() because otherwise we miss out on places
where we have common normalization steps implemented to fix a
connection. This is also what server-side is done.
Revert the patch, as it breaks CI tests.
I wonder also whether this is the right place. There are already
several places in "clients/cli/connections.c" that call verify()
and normalize(). These places should be unified so that there is
one place where we complete the connection. And it probably should be
done as a separate step before the add_new_connection()/update_connection()
calls.
This reverts commit ca58bcca0c.
For static functions inside a module, the compiler determines on its own
whether to inline the function.
Also, "inline" was used at some places that don't immediatly look like
candidates for inlining. It was most likely a copy&paste error.
211cfc5abc fix spelling in API documentation and code comment
b24d2e2048 build: only run full matrix on default CI
8f1fdb72a0 build: update build system
git-subtree-dir: shared/c-siphash
git-subtree-split: 211cfc5abc3813cddd10d237ba9d843b8d3a8995
These were dropped earlier as new sync API must not be the primary way
of calling new routines in libnm.
In this particular case the DBus calls are simple and unlikely to fail.
Most users should use the normal async API and call the finish routine.
However, if the API user is not interested in the result, then they can
simply set the callback to NULL to ignore it.
[thaller@redhat.com: added options argument to start-find method]
And, while at that, add a hint to the developer adding new items. It's
helps avoid a mistake that I believe is common (because I just made it
twice...).
When SAE key managmenet is used, the supplicant can still use the "psk"
property. Only when the pass phrase doesn't conform to WPA-PSK
limitations, the sae_password must be used.
This adds support for configuring the Wi-Fi connections to use SAE. SAE
is a password-based authentication mechanism that replaces WPA-PSK in
WPA3-Personal.
The pass phrase is still stored in the "psk" property, with some
limitations lifted.
The generic connection validation produces a good result:
Error: failed to modify 802-11-wireless-security.psk: ':(' is not a valid PSK.
vs.:
Error: Failed to add 'wifi666' connection: 802-11-wireless-security.psk: property is invalid
