call_nmcli_l() would test for 3 languages: 'C', 'de', and 'pl'. There
is no fundamental difference between 'de' and 'pl', so there is no need
to test for two languages.
Activate the same profile on two devices. Arguably, real NetworkManager
(currently) does not allow that. But the D-Bus API is fine with
having multiple ActiveConnections for one SettingsConnection.
So, also the client should do something sensible.
Also, later we will add wildcard support to NetworkManager, which means
that a profile can be active multiple times (simultaneously).
This is purely for (manual) printf debugging. Hence, it is unused in the commited code.
The point is, to add printf statements to nmcli or libnm, like
if (getenv ("MY_HACK1")) { ...
and trigger it from test-client.py via
self.call_nmcli(..., extra_env = { 'MY_HACK1': '1' } )
- 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.
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.
