Leave a hint about core-dumps.
Also, now we have `contrib/fedora/rpm/configure-for-system.sh` script,
which can configure the build in a way similar to what we get
when doing an RPM build.
That means, inside "contrib/scripts/nm-in-container.sh" we
can just type `make install`, and it will replace the pre-installed
NetworkManager.
The main advantage is that it becomes convenient to run NetworkManager
as a systemd service. Previously, the suggested was to to install
NetworkManager inside another prefix, and run it in the terminal.
Running NetworkManager as systemd service is also necessary for NM-ci,
which restarts the NetworkManager service, and you couldn't run a test,
if you just started NetworkManager in a terminal.
Previously, you had to build a complete RPM, which takes a lot of time.
Yes, it's a large dependency. But on your outer host you
probably configured NetworkManager with QT enabled (for the
example scripts). We want to compile the same work tree inside
the container. So install qt-devel.
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
Otherwise, the path "src/c-stdaux/src/docs/conf.py" matches for
formatting. But this file is imported via git-subtree, we don't
want to format it.
Filter out such paths.
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.]
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.
It's just convenient to have some tools around, not only
for testing, but also for (some limited) development.
In particular, because we bind-mount .vimrc inside the container, and
if I use vim, black/clang-format is just one key binding away.
You can of course just clone NetworkManager repository and start hacking
as you like. However, there are a few things like git-notest which are
interesting to setup.
Add a script to do this.
The script is supposed to be idempotent and do nothing, unless
necessary. By default it also only prints what it would do.
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')
It doesn't work anymore:
$ git clone git://github.com/thom311/libnl.git
Cloning into 'libnl'...
fatal: remote error:
The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.
On recent Fedora and RHEL we no longer have differing "rpm_version"
and "real_version". So usually "rpm_version" is just the same as
"real_version".
Update the template spec file to reflect that. For the "build_clean.sh"
script, we anyway always set them both to "__VERSION__".
With "rc1" mode, we install more than one tarballs (the one for 1.37.90
and 1.39.0). If we reach this point, we already pushed the git tags.
There is no way back.
Ignore errors at first and try to release all tarballs. Only signal the error
at the end.
"find-backports" script parses the commit messages to figure out which
patches to backport. We use "refs/notes/bugs" notes to extend the
meta data after the commit was merged. If you don't setup the
notes, the output is likely incomplete or wrong.
Yes, this is annoying. It requires you to setup the notes as described
in "CONTRIBUTING.md". Also because the "release.sh" script runs "find-backports",
so that means you cannot do releases without setting up the notes
(unless you manually disable running "find-backports"). But you really shouldn't
make a release based on incomplete information.
"Ignore-Backport:" is already in use. For the find-backports script it
has the same meaning as a "cherry picked from" line, that means, we
assume that the referenced patch was backported already and the fix
applied.
This is of course useful to make the script shut up about backports that
we don't want to do. However, it requires us to tag the old branch
with this, so that the script thinks that the patch is already there.
Imaging we have a wrong commit on "next" branch with a Fixes line. We
don't want to backport it, so we would have to tag the "old" branch with
"Ignore-Backport:". That is cumbersome.
Instead, now also support that if a commit contains a "Fixes:" line any
an "Ignore-Fixes:" for the same fixed commit, then this let's the
"Fixes:" line be ignored.
This is more for completeness, to go along "nm-code-format.sh"
script.
Usually it's very simple to run black directly (you may still do that).
However, black by default only reformats files with ".py" extension.
So to get all our python files, you'd need to know and explicitly
select them... or use this script.
Also, `black .` scans the entire source tree, and is rather slow.
This script knows which files to select and is thus faster.
