With the given input, this produces *exactly* the same XML as before.
- the parsing is now stricter (and thus the code more verbose). No
funny stuff, get the annotations correct.
- on parsing errors, we log now the affecting lines
- "nm-setting-ip-config.c" is a base class. Previously it was ignored
and for the moment we still do that. Next, we will allow to also
describe properties there.
- prepare the code to better preserve whitespace, indentation and line
wrappings. In particular, to honor a blank line to indicate a line break
and support paragraphs. This is not yet done to compare the output
to before, but will be turned on with a small patch next.
- the code will make it simple to promote the XML attributes to
nodes. Attributes aren't great, let's write XML nodes later.
We will only need to adjust the "keywords" dictionary for that,
but this change will require changes to the entire chain of tools.
Before:
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: (5) IP configuration could not be reserved (no available address, timeout, etc.).
0
After
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: (5) IP configuration could not be reserved (no available address, timeout, etc.).
4
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/902
For new uses of nm_uuid_generate_from_strings() we should generate version5
UUIDs and we should use unique namespace UUID arguments.
The namespace UUID was so far replaced by always passing a special prefix
as first string. It seems nicer to use a namespace instead.
Version3 UUIDs should not be used for new applications.
Hence, nm_uuid_generate_from_strings_v3() is no longer a desirable way to
generate UUIDs, so drop the wrapper.
Some snake oil, but this is a low level function and we don't know
whether the caller doesn't try to hash secret information. Just clear
the buffer after use.
nm_uuid_generate_from_strings() accepts a uuid_type and type_arg
parameter, so that we can use it to generate version 5 UUIDs.
This is a more flexible variant of nm_uuid_generate_from_strings_v3(),
which will be used to replace it. With the right parameters, the new
function behaves the same as nm_uuid_generate_from_strings_v3().
nm_uuid_generate_from_strings() uses variant3 UUIDs based on MD5.
We shouldn't use that in the future.
We will add a replacement, so rename this function so that the "good"
name is free again. Of course, code that uses this function currently
relies on that the behavior doesn't change. We cannot just drop it
entirely, but will replace it by something that gives the same result.
Rename.
`NM_UUID_INIT(00, 09, 01, ...)` would look as if the values are
octal numbers. That is not the case. The macro mangles them,
so that the look like the UUID in string form "000901...".
This is a bit odd. Maybe more confusing than helpful. Or maybe helpful?
We already redefine those checks to optimize for NMSimpleConnection.
Which, in particular when libnm-core is used by the daemon, is the only
implementation of the NMConnection interface.
Move those to the private header file. No need to keep it private to
"nm-connection.c".
NMConnection is an interface, and as such has no data itself.
In practice, there are only two implementations of this interface,
NMSimpleConnection and NMRemoteConnection. The latter only exists
in libnm, not the daemon.
Thus, lookup of the private data is already optimized for
NMSimpleConnection instances via _nm_simple_connection_private_offset.
Use the same mechanism also for NMSimpleConnection itself.
Instead, hack gettext's Makefile.
gettext has an issue with parallel make. See [1] and [2].
Reproduce with:
git reset --hard &&
git clean -fdx &&
NOCONFIGURE=yes ./autogen.sh &&
./configure --enable-gtk-doc --enable-introspection &&
make -j distcheck V=1
We worked around this by setting "DIST_DEPENDS_ON_UPDATE_PO = yes",
however that (obviously) results in regenerating source files during
dist. "Source files" in the sense that the po files are commited to git
and get distributed in the release. Doing this is very ugly.
In particular it's ugly, because `make -C po update-po` is not reproducible
and the output depends on the current time (*had one job*).
Otherwise, we could just regenerate the files before doing a release.
This means, running "release.sh" script ends up with a dirty tree
afterwards. Also, the distributed po files are not the ones from the source
tree when we did the release. Also, since "release.sh rc1" does two distributions
(once for the rc1 and once for the next devel snapshot), the commit for the
second distribution will have a large diff for the po files.
This reverts commit 978d8eb699 ('po: make dist depend on update-po')
and hacks around the problem.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1094#note_1435313
[2] https://lists.gnu.org/archive/html/bug-gettext/2022-06/msg00022.htmlhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1405
Our GObject structs should be internal API. In which case, we should
embed the private data in the struct themselves (`_priv`) and use the
_NM_GET_PRIVATE() macro. The advantage is better debugability because
following G_TYPE_INSTANCE_GET_PRIVATE() in the debugger is very
cumbersome. Another (less relevant) advantage is better performance.
Thus, warn about uses of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE().
Note that if the struct and is in a header file (which is usually only
necessary when subclassing the type), then the private data should be
an opaque pointer `_priv` instead, and we should use the _NM_GET_PRIVATE_PTR()
macro. In that case, the use of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE() is correct and the warning is false. But
this is only a warning, for the unusual case where we have deep object
hierarchies.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1396
It seems uncommon that a command line tool warns about duplicate
paramters. Usually, the latter just overwrites the former. That is also
useful so that you can have for example an alias that sets a default
type
nmcli_import="nmcli connection import type keyfile"
but still call it like
nmcli_import file $FILE type openvpn
This is a change in behavior. Not only stop we printing a warning, we
will now prefer the latter argument. Previously, the first was honored.
This change in behavior is a problem, but such uses were warned against
in the past, and hopefully nobody did this or relied on this.
If we're generating a connection for an externally configured slave,
refer the master by the UUID instead of the device name.
This doesn't matter most of the time. However, on a checkpoint restore
we need to make sure that a connection that is unambiguously the original
master is up.
Otherwise it could happen that a different connection was activated on the
same master device and the slaves being restored don't agree on which master
connection to bring up.
I can't think of any thing that would rely on this but I've been wrong
about more serious things before.
Fixes-test: @libnm_snapshot_reattach_unmanaged_ports_to_bridge
https://bugzilla.redhat.com/show_bug.cgi?id=2125615
If we're notified of a master appearing, make sure there's actually an
ifindex we're waiting for.
Triger an assertion failure if that is not the case, cause that's pretty
messed up.
Since commit a1de6810df ('device: don't ignore external slave removals')
we don't leave device_recheck_slave_status() on un-eslaving (that is
plink->master = 0) early enough.
This results in hooking of NM_MANAGER_DEVICE_IFINDEX_CHANGED even
when we're not actually waiting for any master device to come up,
accompanied by a messed up log entry:
device[3fa7cfc200be4e84] (portXc): enslaved to unknown device 0 (??)
We also log nonsense when we see any device's link being removed:
device[a9a4b65bde851bcf] (br0): ifindex: set ifindex 0 (old-l3cfg: 05c6a4409f84d9d2)
device[45d34e95fb71cce0] (portXa): master br0 with ifindex 0 appeared
We don't do further damage afterwards, so this is purely a cosmetic
annoyance.
This is something that does happen.
Is that a bug? If so, this should not be a warning message but an
assertion failure. If it's not a bug, then this does not warrant warning
level, because the user wouldn't know what to do about this and it's
something that occasionally happens.
Granted, the state handling in NMDevice is complex, that it's unclear
whether this indicates a problem or not. In any case, having a warning
does only confuse the user.
