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.
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.
NMStrBuf can also contains NUL characters. We thus cannot use g_strndup(),
which uses strncpy() and truncates at the first NUL.
Fixes: 13d25f9d0b ('glib-aux: add support for starting with stack-allocated buffer in NMStrBuf')
Have "len" before "elem_size". That is consistent with g_qsort_with_data()
and bsearch(), and is also what I would expect.
Note that the previous commit just renamed the function. If a user
of the new, changed API gets backported to an older branch, we will
get a compilation error and note that the arguments need to be adjusted.
The "nm_utils_" prefix is just too verbose. Drop it.
Also, Posix has a bsearch function. As this function
is similar, rename it.
Note that currently the arguments are provided in differnt
order from bsearch(). That will be partly addressed next.
That is the main reason for the rename. The next commit
will swap the arguments, so do a rename first to get a compilation
error when backporting a patch that uses the changed API.
For convenience, allow also to match the UUID by prefix -- if the
"uuid" selector is used.
Note that still, there must be only one candidate found. The "uuid"
selector guarantees to find a unique connection.
$ nmcli -f connection.uuid,connection.id connection show uuid eb43d80c
The "connection.uuid" and the D-Bus path are supposed to be unique on
D-Bus. Anything else indicates to a bug somewhere.
Still, with `nmcli connection $operation [uuid|path] $arg ...` ensure
that the result is always unique.
In practice, this should make no difference. In the case of an
unexpected duplicate, it seems better to fail and uphold the
guarantee that these selectors give unique results.
Also, next we will accept matching prefixes of the UUID. While partial
match will then be supported, it should still be unique. That is, the
"uuid" specifier should always only yield one result. While this patch
should make not difference in practice today (albeit enforcing something
that should be valid), it will make a difference then.
Add a new flag to return a NULL string when the password is
empty. This is needed when creating the binding to some properties
that don't accept an empty value.
The default implementation of child_validity_changed() for containers
checks that every child widget is valid. For stacks, the validity
should be determined only by the active child.
find_parent_device_for_connection() must return a parent device even
if it's unrealized. In fact, callers already handle the unrealized
case; in specific:
- _internal_activate_device() will try to autoactivate a connection
on the unrealized parent to realize it;
- system_create_virtual_device()'s goal is to create a NMDevice
object, so it doesn't matter whether the parent is realized or not.
Relax the condition about managed-ness, since any unrealized
device is also unmanaged.
This change fixes the following scenario, where all profiles have
autoconnect=no and autoconnect-slaves=yes:
vrf0
-------------^----------------
| | |
| bridge0 bond0.4000
| .
bond0 <......................
---^---
| |
veth0 veth1
----> = controller
....> = VLAN parent
When profiles are added, unrealized devices are created for bond0 and
bridge0, but not for bond0.4000 becase its parent is unrealized. Then
the autoconnect-slaves machinery for vrf0 tries to activate all ports
but fails for bond0.4000 because it can't find a device for it.
https://bugzilla.redhat.com/show_bug.cgi?id=2101317
"-u" calls `git diff -name-only $UPSTREAM` to get a list of files.
However, if $UPSTREAM contains a file that doesn't exist in the current
checkout, we get a non-existing file name and clang-format will fail.
Avoid that, by filtering only files that exist.
Also, pass "--no-renames" option to git-diff.
nm_hash_update_vals() has variadic arguments and accepts (in principle) any
number of arguments. It works by copying the value to a packed struct on
the stack.
nm_hash_update_val() is essentially the same, but accepts only one
argument. Implement nm_hash_update_val() in terms of
nm_hash_update_vals().
Also, add nm_hash_vals(), and adjust nm_hash_val() to be implemented that way.
Maybe we should drop combine the val/vals variants into one, and not
have two variants. We only keep them because both are currently in use.
Also, we have nm_hash_update_valp(), which is useful but can only take one
argument. For naming consistency of nm_hash_update_val(), nm_hash_update_valp()
and nm_hash_update_vals() they are all kept.
When disposing NMPolicy all the devices in the devices hash-table should
be unregistered and removed from the hash-table.
Fixes: 7e3d090acb ('policy: refactor tracking of registered devices')
