GitLab

Functions like nmc_find_connection() and nmc_find_active_connection()
can easily find multiple matching results. For example, the
"connection.id" in NetworkManager is not enforced to be unique,
so if the user adds multiple connections with the same name,
they should be all selected.

The previous API had a @pos argument, that allowed to iterate over
the results. Change that, to return all matches in a GPtrArray.

Also, extend connection-show and other places, to anticipate that
a connection might be active multiple times in any moment.

Also, let the enum2str function return a non-translated string.
The user may choose to call gettext() on it.

Beside nmc_find_connection(), which is very similar.

Also, drop unused argument @cons.

At various places we sort our D-Bus paths. For example,
server sorts them before exporting them on D-Bus.

Server knows well, that a lot of these paths are build
by attaching an incrementing number as last component.
It looks nicer to sort by this number, instead of strictly
lexical with strcmp().

Note that this handles the cases correctly where paths have
different prefixes, or where they don't end with a number.

Like g_utf8_collate(), which complains about NULL strings.

Add a test to call `nmcli con up`, and also how the activated
state looks afterwards.

Let the computer do the hard stuff. Since we already call the tests,
why only check for one language?

Transition the states, so that `nmcli con up` can succeed.

- no more global variables, except those in the new variable "gl".

- don't pass that bus instance around. Use the singleton gl.bus.

- separate creation of ExportedObj from exporting on D-Bus.

- use enum values loaded from NM via GObject introspection.

- the visible change is that the generated D-Bus paths now start
  counting at one. That is also how NetworkManager behaves, and
  it looks nicer to have no zero ID for an object.

Thereby, drop unneeded NM_TEST_CLIENT_IN_DBUS_SESSION=0 environment
variable from Makefile.am.

This makes package updates more robust, avoiding in-place replaces of
the plugins.

Previously, if an upgrade transaction was terminated, NetworkManager
library could end up being of a different version than the plugins.
If the user was unfortunate enough to connect using a connection that
required a plugin (say, Wi-Fi), he would be left without a network
connection making it somewhat inconvenient to recover from the botched
upgrade.

This makes the whole situation a little bit less sad.

The VPN plugins are kept where they always have been -- the path is not
qualified with a version number.

When built with iwd support, add an option to use iwd in place of
wpa_supplicant.

The "boolean dependencies" are only supported since RPM 4.13, with older
versions just keep things the way they were before.

https://bugzilla.gnome.org/show_bug.cgi?id=746422

Honor dns-priority by using the preprocessed list of domains provided
by the manager.

Honor dns-priority by using the preprocessed list of domains provided
by the manager.

Do some preprocessing on the DNS configuration sent to plugins:

 - add the '~' default routing (lookup) domain to IP configurations
   with the default route or, when there is none, to all non-VPN
   IP configurations

 - use the dns-priority to decide which connection to use in case
   multiple connections have the same domain

 - consider a negative dns-priority value as a way to 'shadow' all
   subdomains from other connections

 - compute reverse DNS domains

and add the resulting domain list to NMDnsIPConfigData so that
split-DNS plugins can use that directly instead of reimplementing the
same logic themselves.

Reject domains containing ".." or starting with "."

Fixes: e91f1a7d

Fixes: ff8e5633

https://bugzilla.gnome.org/show_bug.cgi?id=795965

https://github.com/NetworkManager/NetworkManager/pull/110

- add find_devices() and find_device_first() functions,
  to not re-implement iterating the device list.

- for test functions, accept the device's "ident", instead
  of ifname. The "ident" must b unique, contrary to the "ifname".

Add a test which runs nmcli against our stub NetworkManager
service and compares the output.

The output formats of nmcli are complicated and not easily understood.
For example how --mode tabular|multiline interacts with selecting
output-fields (--fields) and output modes ([default]|--terse|--pretty).
Also, there are things like `nmcli connection show --order $FIELD_SPEC`.

We need unit tests to ensure that we don't change the output
accidentally.

When building with --disable-introspection, we re-use the pre-generated
clients/common/settings-doc.h.in file.

When building with --enable-introspection, we generate
clients/common/settings-doc.h, and let `make check` verify that the
generated file is identical to what we would generate.

The common case where the generated file differ, is when code changed,
in this case, the developer is advised to update settings-doc.h.in.

Interpret environment variable NM_TEST_REGENERATE=1 to do this
automatically during `make check`.

This will be useful, as there might be several tests that compare a
generated file with a file from version control. NM_TEST_REGENERATE=1
will be the general way to re-generate all these files.

  $ NM_TEST_REGENERATE=1 make check

tools/test-networkmanager-service.py is our NetworkManager stub server.

NetworkManager uses libnm(-core) heavily, for example to decide whether
a connection verifies (nm_connection_verify()) and for normalizing
connections (nm_connection_normalize()).

If the stub server wants to mimic NetworkManager, it also must use these
function. Luckily, we already can do so, by loading libnm using python
GObject introspection.

We already correctly set GI_TYPELIB_PATH search path, so that the
correct libnm is loaded -- provided that we build with introspection
enabled.

We still need to gracefully fail, if starting the stub server fails.
That requries some extra effort. If the stub server notices that
something is missing, it shall exit with status 77. That will cause
the tests to g_test_skip().

With autotools, we use libtool so that the right libraries are
automatically found. Still, we won't find the right GI typelib.

Add a mechanism so that when make/meson invokes the run-nm-test.sh
runner, it passes the build-root directory.

Also, try to autodetect when invoked manually.

https://mail.gnome.org/archives/networkmanager-list/2018-May/msg00000.html

This is broken -- looks for VPN plugins in a version-qualified path,
which is wrong and break installed VPN plugins.

This reverts commit 6384ad4e.

https://github.com/NetworkManager/NetworkManager/pull/105

The present version of the specification is somewhat unclear at times,
Unclear points were discussed with the maintainers [1] and probably
some new version will address those.

https://www.spinics.net/lists/util-linux-ng/msg15222.html

Until then here's how the implementation copes with ambiguities
(after the discussion with util-linux maintainers):

1.) It is unclear whether multiple .schem files should override each
    other or be merged. We use the overriding behavior -- take the
    highest priority one and ignore the rest.

2.) We assume "name.schem" is more specific than "@term.schem".

3.) We assume the "Color name" are to be used as aliases for the color
    sequences and translate them to ANSI escape sequences.

4.) The "Escape sequences" are of no use since the specification
    pretty much assumes an ANSI terminal and none of the sequences make
    any sense in ANSI color codes. We don't support them.
    accept that.

5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
    what should it do.

This basically replaces the (NMMetaTermColor, NMMetaTermFormat) combo
with NMMetaColor that describes the colored element semantically as
opposed to storing the raw attributes.

A (currently static) paletted is used to translate the semantic color
code to the actual ANSI controle sequence. This matches what
terminal-colors.d(5) schemes use, making it convenient to implement
customizable palettes.

This actually makes very little difference at the moment, but will make
things more confortable later on, when the logic of enabling/disabling
coloring will involve terminal-colors.d(5).

Instead of deciding whether to use colors lazily with use_colors(), it's
done very early on nmcli initialization and a boolean use_colors field
is stored in the NmcConfig instance instead of the raw tristate option
of NmcColorOption type (which is now confined to nmcli.c).

Wherever the NmcColorOption was used previously, the whole NmcConfig
instance is passed around. That might seem pointless (since only the
use_colors boolean is actually used at the moment), but will be utilized
to pass around the actual color palette in future.

It's undocumented, useless, somewhat expensive in volume of code and
probably just downright stupid. We'll get a more general way to set
colors.

Hacking in some code to keep this working wouldn't be too difficult, but
it seems entirely pointless.