This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.
Removing the libraries allows us to:
* Remove the horrible hacks that were in place to deal with accidental use
of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
strings.
* Get rid of known bad code without chances of ever getting fixed
(libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace
If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.
https://github.com/NetworkManager/NetworkManager/pull/308
Using test-networkmanager-servic.py, I get the following error when
trying to add manual config with a dns address:
Error: g-io-error-quark: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 707, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "tools/test-networkmanager-service.py", line 1727, in AddConnection
return self.add_connection(con_hash)
File "tools/test-networkmanager-service.py", line 1731, in add_connection
con_inst = Connection(self.c_counter, con_hash, do_verify_strict)
File "tools/test-networkmanager-service.py", line 1601, in __init__
NmUtil.con_hash_verify(con_hash, do_verify_strict=do_verify_strict)
File "tools/test-networkmanager-service.py", line 497, in con_hash_verify
BusErr.raise_nmerror(e)
File "tools/test-networkmanager-service.py", line 419, in raise_nmerror
raise e
Exception: Unsupported value ipv4.dns = dbus.Array([dbus.UInt32(168430090L), dbus.UInt32(218893066L)], signature=dbus.Signature('u'), variant_level=1) (Cannot convert array element to type 'u': Must be number, not Variant)
https://mail.gnome.org/archives/networkmanager-list/2019-March/msg00013.html
(cherry picked from commit 9a71d7d273)
Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API.
"AddAndActivate2" replaces "AddAndActivate" with more options.
It also has a dictionary argument to be forward compatible so that we
hopefully won't need an "AddAndActivate3". However, it lacked a similar
output dictionary. Add it for future extensibility. I think this is
really to workaround a shortcoming of D-Bus, which does provide strong
typing and type information about its API, but does not allow to extend
an existing API in a backward compatible manner. So we either resort to
Method(), Method2(), Method3() variants, or a catch-all variant with a
generic "a{sv}" input/output argument.
In libnm, rename "nm_client_add_and_activate_connection_options()" to
"nm_client_add_and_activate_connection2()". I think libnm API should have
an obvious correspondence with D-Bus API. Or stated differently, if
"AddAndActivateOptions" would be a better name, then the D-Bus API should
be renamed. We should prefer one name over the other, but regardless
of which is preferred, the naming for D-Bus and libnm API should
correspond.
In this case, I do think that AddAndActivate2() is a better name than
AddAndActivateOptions(). Hence I rename the libnm API.
Also, unless necessary, let libnm still call "AddAndActivate" instead of
"AddAndActivate2". Our backward compatibility works the way that libnm
requires a server version at least as new as itself. As such, libnm
theoretically could assume that server version is new enough to support
"AddAndActivate2" and could always use the more powerful variant.
However, we don't need to break compatibility intentionally and for
little gain. Here, it's easy to let libnm also handle old server API, by
continuing to use "AddAndActivate" for nm_client_add_and_activate_connection().
Note that during package update, we don't restart the currently running
NetworkManager instance. In such a scenario, it can easily happen that
nmcli/libnm is newer than the server version. Let's try a bit harder
to not break that.
Changes as discussed in [1].
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
Add a new CON_DEFAULT() macro that places a property name into a
special section used at runtime to check whether it is a supported
connection default.
Unfortunately, this mechanism doesn't work for plugins so we have to
enumerate the connection defaults from plugins in the daemon using
another CON_DEFAULT_NOP() macro.
This adds the new methods nm_client_add_and_activate_connection_options_*
and ports the existing methods to use the new AddAndActivateConnection2
call rather than AddAndActivateConnection, allowing further parameters
to be passed in.
Try to make check-docs.sh script more readable.
Also, previously the script would check that one side was a subset
of the other side. Tighten this check up, now both sides of the
comparison must agree and yield the same lines.
Under valgrind, we cannot create an NAcd instance.
--10916-- WARNING: unhandled amd64-linux syscall: 321
--10916-- You may be able to write your own handler.
--10916-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--10916-- Nevertheless we consider this a bug. Please report
--10916-- it at http://valgrind.org/support/bug_reports.html.
This limitation already poses a problem, because running NetworkManager
under valgrind might fail. However, for tests it doesn't matter and we
can just skip them.
When building with meson -Dppp=false, the following message is printed
during build:
[623/671] Generating NetworkManager.ver with a custom command. find: ‘./src/ppp/’: No such file or directory
The message is harmless. Hide it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/43
The script didn't include all the symbols needed by plugins because
libNetworkManager.a, as built by meson, doesn't include symbols from
other static libraries that are linked in. Since we used
libNetworkManager.a to know which symbols are potentiall available
from NM, the result was an incomplete list.
Unfortunately, the only way to include the whole static library is to
create a dependency object and use 'link_whole', but this is only
available in meson >= 0.46. Since 'link_whole' is available for
executables in meson >= 0.40, create a fake executable and use that to
enumerate symbols.
Also add tests to check that plugins can be loaded correctly.
Fixes: dfa2a2b40c
Adapt the meson post-installation script to handle the $DESTDIR
variable supplied by user to specify the installation target
directory. While at it, convert the script to shell because it seems
simpler to me.
NetworkManager.ver needs to whitelist symbols needed by device,
settings, and ppp plugin. Fix the generator script to also allow
using c_siphash_*() symbols. These are needed by nm_hash_*().
Without this, wifi device plugin is broken.
Fixes: ccf36ff4ce
The function is supposed to return the IPv4 address as 32 bit integer in
network byte order (bit endian). The ip4_addr_ne32() name is confusing,
because "ne" commonly stands for "native endianness".
Compare also "unaligned.h" and unaligned_read_ne32(), which also
stands for native endianness (host order), not network order (big
endian).
Rename.
Tests might just take longer than 20 seconds.
Also, we already watch stdin to determine whether the service
should exit.
(cherry picked from commit 4e18ef49bf)
Now that nmcli initiates a scan before displaying Wi-Fi networks,
the stub service must properly support that as well.
For the moment, the stub service chooses "now" as LastScan timestamp.
This causes nmcli not to trigger a new scan, because nmcli gives
unstable output if multiple nmcli processes in parallel race to
trigger a Wi-Fi scan. That should be fixed.
(cherry picked from commit 56a0488bba)
This opens the tests up to races. If we want to change the strength, we
need to do it in a controlled, race-free manner. This is especially the
case, because clients/tests run a large number of nmcli instances in
parallel, and it's thus racy which signal the nmcli processes will
see.
This also fixes a bug at
self._dbus_property_set(IFACE_WIFI_AP, PRP_WIFI_AP_STRENGTH, strength)
@strength must be a D-Bus type, so that python-dbus knows the correct
type for serialization.
(cherry picked from commit 7e118c0091)
Currently, nmcli does not sort the list of available connections
for display. Instead, it shows them in the order as NetworkManager
exposes them on D-Bus.
Previously, test-networkmanager-service.py, would generate the list
of available connections by iterating the connections dictionary.
In Python (at least until Python 3.6), the order when iterating over
dictionaries is undefined. This inconsistancy lets tests behave
differently depending on the python version. Possibly with Python
3.4 and 3.5, tests might even behave differently between individual
runs (since Python there uses siphash with a randomized hash seed).
At several places, "test-networkmanager-service.py" uses generated numbers
with a defined seed. For example, generated connection's UUID is
generated in a predictable, but randomized way (if you forgive the
inprecise use of the word "random" in context of using a deterministic
seed).
Aside the connection's UUID, this becomes more interesting in the next commit
where the stub server generates a list of IP and DHCP settings in a predictable
randomized way.
For "clients/tests" we spawn the test service multiple times, but also
create similar environments by calling init_001(). This is done for
convenience, where out of lazyness all the tests share one setup. But it's
still a good idea that these tests generate slightly different setups,
wherever applicable. this increases the possible setups which get tested.
For example, the number of static IPv4 addresses (the following commit) is
interested to explicitly test for zero or a non-zero number of
addresses. If all tests happen to use the same seed, the tests are expected
to also generate the same number of addresses, and we miss an opportunity to
hit interesting test cases.
There is still no guarantee that all interesting cases are hit, the chances are just
better. The approach of generating the setup randomly, does not preclude that
the stub-server allows to explicitly configure the setup. However, due to the
sheer number of combinations that might be interesting to test, it's much simpler
to rely on some randomization and have the justifid hope we catch interesting cases.
Also in terms of runtime of the test, the cli unit tests should complete within
few seconds. Testing every combination would result in huge tests and long runtimes.
Also, the patch refactors generating random numbers in
"test-networkmanager-service.py". For example, it introduces
Util.RandomSeed(), which can be used to generate a sequence of different
random numbers. It works by having an internal state and a counter which is
combined to chain the seed and generate different numbers on each call.
Just to give it some variety. Also, note how the message from the
server cannot be translated. Which is the case with real NetworkManager
as well, and is a major usability issue.
The real NetworkManager service has a clear understanding how a valid
connection looks like. This is what nm_connection_verify() returns.
Let also our stub-service verify connections the same way.
Note that this is cumbersome, because the stub service uses python's
dbus module, while libnm only accepts creating NMConnection instances
from GVariant. Thus, we need to a cumbersome conversion first.
It would be better if test-networkmanager-service.py would also expose
normalized connections on D-Bus. But that requires the inverse converion
from GVariant to python dbus.
lso, the name "connection" and "con" is overused.
Use "con_inst" where we mean an instance of a "Connection" class,
that is, the object exposed on D-Bus.
- don't use "hash" for a local variable in python.
The editor highlights it like a special python name.
- don't use "settings" for Connection.settings. Name it
Connection.con_hash. The name "settings" is over-used already.
"con_hash" really is the nested dictionary that we expose/receive
from D-Bus. If we would use libnm for it, it would be an
NMSimpleConnection instance, but we don't.
