Resolve the defaults in build.sh instead of RPM macros. This looks less
terrible maintaining the same defaults as well as options to override it
upstream.

Moving it to the block that downstreams (Fedora, Red Hat) keep
customized makes it possible for them to also maintain customized
defaults here.

In particular, the downstreams should be able to enable bcond_test
at least for their production release (otherwise there's little point in
actually running tests at package build time).

!1281

In the past, nmp_lookup_init_object() could both lookup all object for a
certain ifindex, and lookup all objects of a type. That fallback path
already leads to an assertion failure fora while now, so nobody should
be using this function to lookup all objects of a certain type (for
what, we have nmp_lookup_init_obj_type()).

Now, remove the fallback path, and rename the function to what it really
does.

NMPObject is a union. It's not clear to me that C guarnatees that
designated initializers will meaningfully set all fields to zero. Use
memset() instead.

!1282

Perhaps the test is not using call_nmcli*(), but still wants to use
@nm_test decorator to set up the mock service.

Useful for testing interactive commands against a mock service.

We'd like to use this for client unit testing.

It can be useful to choose a different "ipv6.addr-gen-mode". And it can be
useful to override the default for a set of profiles.

For example, in cloud or in a data center, stable-privacy might not be
the best choice. Add a mechanism to override the default via global defaults
in NetworkManager.conf:

  # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf
  [connection-90-ipv6-addr-gen-mode-override]
  match-device=type:ethernet
  ipv6.addr-gen-mode=0

"ipv6.addr-gen-mode" is a special property, because its default depends on
the component that configures the profile.

- when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode
  key means to default to "eui64".
- when configured via D-Bus, a missing addr-gen-mode property means to
  default to "stable-privacy".
- libnm's ip6-config::addr-gen-mode property defaults to
  "stable-privacy".
- when some tool creates a profile, they either can explicitly
  set the mode, or they get the default of the underlying mechanisms
  above.

  - nm-initrd-generator explicitly sets "eui64" for profiles it creates.
  - nmcli doesn' explicitly set it, but inherits the default form
    libnm's ip6-config::addr-gen-mode.
  - when NM creates a auto-default-connection for ethernet ("Wired connection 1"),
    it inherits the default from libnm's ip6-config::addr-gen-mode.

Global connection defaults only take effect when the per-profile
value is set to a special default/unset value. To account for the
different cases above, we add two such special values: "default" and
"default-or-eui64". That's something we didn't do before, but it seams
useful and easy to understand.

Also, this neatly expresses the current behaviors we already have. E.g.
if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64"
is a pretty clear thing.

Note that usually we cannot change default values, in particular not for
libnm's properties. That is because we don't serialize the default
values to D-Bus/keyfile, so if we change the default, we change
behavior. Here we change from "stable-privacy" to "default" and
from "eui64" to "default-or-eui64". That means, the user only experiences
a change in behavior, if they have a ".conf" file that overrides the default.

https://bugzilla.redhat.com/show_bug.cgi?id=1743161
https://bugzilla.redhat.com/show_bug.cgi?id=2082682

See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907

!1213

teamdctl_connect() has a parameter cli_type. If unspecified, the
library will try usock, dbus (if enabled) and zmq (if enabled).

Trying to use the unix socket if we expect to use D-Bus can be bad. For
example, it might cause SELinux denials.

As we anyway require libteam to use D-Bus, if D-Bus is available,
explicitly select the cli type.

!1255

This is essentially work started by Martin Blanchard and improved by
Javier Jardón with some fixups.

!1094

Hopefully for better not worse.

It's sad, old and unsupported. Also its gettext is old and smells of
elderberries.

This works around a race condition with gettext Makefile.

!1094 (comment 1435313)

Martin Blanchard authored Mar 31, 2021 and Lubomir Rintel committed Jun 27, 2022

Recent gettext version can extract and merge back strings from and to
various file formats, no need for intltool anymore.

https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration

#133

https://github.com/NetworkManager/NetworkManager/pull/303
!96

Clarification about the use of AM_GNU_GETTEXT_REQUIRE_VERSION:

In configure.ac, specify the minimum gettext version we require, rather
than the exact one. This fixes a situation where the autoconf macros
used for gettext will be the latest available on the system (for
example, 0.20); but the copied-in Makefile.in.in will be for the exact
version specified in configure.ac (in this case, 0.19).

In that situation, the gettext build rules will error out at `make` time
with the message:
   *** error: gettext infrastructure mismatch: using a Makefile.in.in
   from gettext vers...

Since kernel 5.18 there is a stricter validation [1][2] on the tos
field of routing rules, that must not include ECN bits.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f55fbb6afb8d701e3185e31e73f5ea9503a66744
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a410a0cf98854a698a519bfbeb604145da384c0e

Fixes the following failure:

  >>> src/core/platform/tests/test-route-linux
  >>> ...
  # NetworkManager-MESSAGE: <warn>  [1656321515.6604] platform-linux: do-add-rule: failure 22 (Invalid argument - Invalid dsfield (tos): ECN bits must be 0)
  >>> failing... errno=-22, rule=[routing-rule,0x13d6e80,1,+alive,+visible; [6] 0: from all tos 0xff fwmark 0x4/0 suppress_prefixlen -459579276 action-214 protocol 255]
  >>> existing rule: * [routing-rule,0x13d71e0,2,+alive,+visible; [6] 0: from all sport 65534 lookup 10009 suppress_prefixlen 0 none]
  >>> existing rule:   [routing-rule,0x13d7280,2,+alive,+visible; [4] 0: from all fwmark 0/0x9a7e9992 ipproto 255 suppress_prefixlen 0 realms 0x00000008 none protocol 71]
  >>> existing rule:   [routing-rule,0x13d7320,2,+alive,+visible; [6] 598928157: from all suppress_prefixlen 0 none]
  >>> existing rule:   [routing-rule,0x13d73c0,2,+alive,+visible; [4] 0: from 192.192.5.200/8 lookup 254 suppress_prefixlen 0 none protocol 9]
  >>> existing rule:   [routing-rule,0x13d7460,2,+alive,+visible; [4] 0: from all ipproto 3 suppress_prefixlen 0 realms 0xffffffff none protocol 5]
  >>> existing rule:   [routing-rule,0x13d7500,2,+alive,+visible; [4] 0: from all fwmark 0x1/0 lookup 254 suppress_prefixlen 0 action-124 protocol 4]
  >>> existing rule:   [routing-rule,0x13d75a0,2,+alive,+visible; [4] 0: from all suppress_prefixlen 0 action-109]
  0:      from all fwmark 0/0x9a7e9992 ipproto ipproto-255 realms 8 none proto 71
  0:      from 192.192.5.200/8 lookup main suppress_prefixlength 0 none proto ra
  0:      from all ipproto ggp realms 65535/65535 none proto 5
  0:      from all fwmark 0x1/0 lookup main suppress_prefixlength 0 124 proto static
  0:      from all 109
  0:      from all sport 65534 lookup 10009 suppress_prefixlength 0 none
  598928157:      from all none
  Bail out! nm:ERROR:../src/core/platform/tests/test-route.c:1787:test_rule: assertion failed (r == 0): (-22 == 0)

Fixes: 5ae2431b ('platform/tests: add tests for handling policy routing rules')

!1274

#1037

!1269

This makes it more consistent with nettools' lease_to_ip4_config().
The benefit of having a self pointer, is that it provides the necessary
context for logging. Without it, these functions cannot correctly log.

At this point, it's clearer to get the necessary data directly from the
DHCP client instance, instead of having the caller passing them on
(redundantly).

For an IPv4 subnet mask we expect that all the leading bits are set (no
"holes"). But _nm_utils_ip4_netmask_to_prefix() does not enforce that,
and tries to make the best of it.

In face of a netmask with holes, normalize the mask.

Do the same as dhclient plugin in nm_dhcp_utils_ip4_config_from_options().

#1037

We have two variants of the function: nm_utils_ip4_netmask_to_prefix()
and _nm_utils_ip4_netmask_to_prefix(). The former only exists because it
is public API in libnm. Internally, only use the latter.

nm_utils_ip4_netmask_to_prefix() and nm_utils_ip4_prefix_to_netmask()
are public API in libnm.

We thus already have an internal implementation _nm_utils_ip4_prefix_to_netmask(),
for non-libnm users. Internally, we should never use the libnm variant.

For consistency and so that we have the helper available in
libnm-glib-aux, add _nm_utils_ip4_netmask_to_prefix().

There was already an nm_assert() assertion. Upgrade this
to a g_return_val_if_fail(). This function is public API,
so this is potentially an API break. But it should highlight
a bug in the caller.

!1279

Or, well, work around a bug.

Apt is run for each package separately and errors are ignored. This is
not great -- it's slow and ignores errors. Therefore we sometimes end
up without packages we need.

Let's tolerate errors only for packages that we are know can fail to
install safely.

Fixes: 919a61bc ('platform/netlink: extend nl_nlmsghdr_to_str() for genl messages')

!1280

!1278

The lock attribute is a boolean, it can also be FALSE. We need
to handle that case, and don't add serialize "$NAME lock 0" for them.

In practice, the profile probably validates, so all the
attribute names are well-known. There is thus no attribute
name that has "lock-" in the middle of the string.

Still, fix it. We want to match only at the begin of the
name.