Install a configuration snippet on Fedora 40+, that sets the default for
"wifi.cloned-mac-address" to "stable-ssid" (otherwise, the built-in default
is "preserve").
This will mean, that on Wi-Fi profiles that don't explicitly override
the property "wifi.cloned-mac-address", a stable address is generated.
The benefit is, that Fedora will randomize the MAC address by default.
Note that this also affects all pre-existing Wi-Fi profiles, that don't
explicitly configure the property in the profile. Depending on how you
see it, this is desirable. Randomization should be done, unless the user
opts-out (not the other way around).
Note that setting "wifi.cloned-mac-address=stable-ssid" is similar to
setting a stable ID "${NETWORK_SSID}" and "wifi.cloned-mac-address=stable".
The difference is that the latter also affects other properties, like
- "ipv6.addr-gen-mode=stable-privacy"
- "{ethernet,wifi}.cloned-mac-address=stable"
- "ipv4.dhcp-client-id=stable"
- "ipv6.dhcp-duid=stable-{llt,ll,uuid}"
- "{ipv4,ipv6}.iaid=stable"
Especially with "ipv6.addr-gen-mode=stable", changing the stable ID
would mean that also all IPv6 addresses change. We want to avoid that by
only changing the cloned-mac-address to "stable-ssid".
This means, after upgrade to F40, different MAC addresses will be used
on most users' Wi-Fi. This means, DHCP might hand out different IP
addresses, sessions might expire, and configuration that depended on the
previous MAC address will be affected.
https://pagure.io/fedora-workstation/issue/350
Now that we no longer test on CentOS7, we also have no more tests that
build using Python2.
Note that build with Python2 is currently broken already (which would be
fixable).
Drop Python2 too.
Existing Python scripts still use a common subset of Python2 and
Python3. They can be improved to use Python3 features in the future.
The license identifier was updated for the main package, but not for
libnm which overrides it to LGPL 2.1 or later. Update it too.
Fixes: 8c5aec7a1b ('contrib/rpm: migrate to SPDX license')
network-online.target should not be reached before nm-cloud-setup
completes configuring the network, which may make user service get
started before the network is fully configured.
Setting nm-cloud-setup.service as "Before=network-online.target" would
maybe have already achieved that. However, also use a pre-up dispatcher
script, so that the device activation in NetworkManager is also waiting
for nm-cloud-setup to complete.
https://bugzilla.redhat.com/show_bug.cgi?id=2151040https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1653
Originally, the package was called vala-devel (it still is on CentOS7).
Then it was renamed to libvala-devel, but keeping a Provides.
On Fedora 39, the Provides was dropped. Workaround.
- We need to fetch more entries per page. 100 is the maximum without
pagination, but that is enough for us.
- Previously, we checked all stages. Now, let's skip the "prep" and "tier3" stages.
This change should work both with old and new pipelines.
A "minor" release can still be the latest release. It depends
on which minor release you do. The script isn't smart enough
to understand the difference, so make the hint a bit clearer.
"configure-for-system.sh" is supposed to be in sync with
NetworkManager.spec. Update for the recent changes.
Also add a make/ninja call at the end. Almost always we want to build
after the configure.
[thaller@redhat.com: I introduced this bug when taking the original patch].
Fixes: 820f6f3a4a ('contrib/rpm: sync obsoletes_{initscripts_updown,ifcfg_rh} version')
Initially, when we obsoleted {initscripts_updown,ifcfg_rh}, the package
versions that we build from this upstream spec file differed from what
we put into Fedora/RHEL.
By now, this is long gone, and for upstream package builds we don't care
to accurately track the version, when using upstream/copr builds. Just
sync the version to what they are in Fedora/RHEL.
Fixes: 096b9955d6 ('contrib/fedora: make "lto" in the spec file configurable')
Fixes: 7a62845424 ('contrib/rpm: fix condition in "NetworkManager.spec"')
Fixes: 096b9955d6 ('contrib/fedora: make "lto" in the spec file configurable')
Fixes: 7a62845424 ('contrib/rpm: fix condition in "NetworkManager.spec"')
When we build a copr image, we run the "nm-copr-build.sh" script.
That script, should honor "LTO=0|1|" to explicitly enable/disable
LTO. Since the copr script only builds a SRPM, which then gets build
we need that the default LTO flag in the SRPM is templated.
Fixes: 0566e9dc63 ('contrib: support disabling "LTO" in "nm-copr-build.sh"')
With the meson build configuration, there is obviously python3 installed
and in the path. The build script will pick that up as preferred python.
However, we will also need working pygobject to build the documentation.
But we only have that for python2 installed. Fix that, by installing
"python36-gobject".
We have "BuildRequires: ppp-devel". While in Fedora 37 that has a
dependency on "ppp" package, that is not the case on Centos7. I didn't
test others, but the point is it's not always there.
"/usr/sbin/pppd" is provided by "ppp" package, and we might not have it
installed via the build requirements. But we only need it to detect the
path, which is not necessary on RHEL/Fedora. Just set the path
explicitly with the respective configure option.
This will use the same option as when we do an RPM build.
The purpose is that you could type `make install` with such
a build, and it would replace the files that you'd get by installing
the NetworkManager RPMs.
Of course, you would not want to do that on your work station, but it
will be useful in a container, where we don't mind messing up the
installation.
autotools accepts both --with-$OPTION/--without-$OPTION and
--with-$OPTION=yes|no. Consistently use the latter.
The advantage is that whether it's enabled becomes an argument, so in a
script you could do
"--with-$OPTION=$VALUE"
Same for enable/disable option.
The test bcond is used to make test suite failure terminate the %check
phase. That should generally be done for distro builds.
What the distro builds shouldn't do is terminate the build on compiler
warnings, because they're fairly likely to appear on toolchain updates
without indicating actual bugs.
However, currently that's precisely what do we do now.
Let's use -Werror on debug builds instead. They are intentionally made
more prone to fail (e.g. trip more runtime assertions) because failures
can be more rapidly addressed and don't affect distro builds.
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).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1286
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/GettextMigrationhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/133https://github.com/NetworkManager/NetworkManager/pull/303https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/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 version 0.19 but the autoconf macros are from gettext
version 0.20
Avoid that by specifying a minimum version dependency rather than an
exact one. This should not cause problems as we haven’t committed any
generated or external gettext files into git, so each developer will end
up regenerating the build system for their system’s version of gettext,
as expected.
See the subsection of
https://www.gnu.org/software/gettext/manual/html_node/Version-Control-Issues.html
for more information.
Note that autoreconf currently doesn’t recognise
AM_GNU_GETTEXT_REQUIRE_VERSION, so we must continue also using
AM_GNU_GETTEXT_VERSION. autopoint will ignore the latter if the former
is present. See
https://lists.gnu.org/archive/html/autoconf-patches/2015-10/msg00000.html.
[lkundrak@v3.sk: Fixed the meson build, adjusted autogen.sh:
droped "|| exit 1", dropped call to aclocal,
dropped --copy from gtkdocize.]
NetworkManager does not support by default legacy ifcfg configuration
files anymore, this support is now provided in a separate package
(https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/).
ifcfg directory (/etc/sysconfig/network-scripts/) should always be present,
regardless of NetworkManager support for network scripts. This change makes the
directory always present, not only when the recently splitted ifcfg subpackage
is installed, and also make it persistent after the package removal.
Fixes: 50a6627fd7 ('rpm: split ifcfg-rh settings plugin into a separate package')
