Not sure why we had this disabled.
This is for the nmcli/nmtui `agent` subcommand [0]
which allows it to act as a polkit agent.
> nmcli agent { secret | polkit | all }
> Run nmcli as a NetworkManager secret agent, or polkit agent.
For example, this is useful if you want to use nmcli/nmtui to authenti-
cate with polkit on a headless server.
[0]: https://developer.gnome.org/NetworkManager/stable/nmcli.html
* fix-paths.patch
We had to add a diff to revert [0] as it makes it use the python
from meson which won't be the specific pythonForDocs that
has pygobject (breaking the build). Unfortunate that upstream
made assumptions like "Of course, who needs a way to invoke
the interpreter that works accross different distributions!"
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.20.4/NEWS
[0]: c162dc00e5
Fixes problems such as:
systemd[1]: Failed to put bus name to hashmap: File exists
systemd[1]: dbus-org.freedesktop.nm-dispatcher.service: Two services allocated for the same bus name org.freedesktop.nm_dispatcher, refusing operation.
Problem is that systemd treats symlinks to files outside the service
path differently, causing our old workaround to look like two separate services.
These symlinks are intended to be a means for manually emulating
the behavior of the `Alias=` directive in these services.
Unfortunately even making these symlinks relative isn't enough,
since they don't make it to where it matters--
that only makes the links in /etc/static/systemd/system/*
relative, with systemd still being shown non-relative links
in /etc/systemd/system/*.
To fix this, drop all of this at the package level
and instead simply specify the aliases in the NixOS modules.
Also handle the same for modemmanager,
since the networkmanager NixOS module also handles that.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Our gobject-introspection patches make the shared library paths absolute
in the GIR files. When building docs, the library is not yet installed,
though, so we need to replace the absolute path with a local one during build.
Previously we used LD_PRELOAD to load libredirect and rewrite the installed paths
to ones in the build directory. That was unnecessary complicated and many people
spent whole night trying to figure out why it breaks some programs.
Using a symlink from the installed location to the build directory fixes
the issue as well, while having much less moving parts, thus being easier to grasp.
The symlink will be overridden during installation.
All hail Meson!
One serious issue is that building docs does not work.
We patch gobject-introspection to use absolute paths for shared libraries
in GIR files. Building the NetworkManager docs relies on the produced
introspection data but since the library is not yet installed
at the time the docs are generated, the build will fail.
It works in Autotools for some reason; they probably use
the pregenerated GIRs from the tarball.
Disabling the docs completely is not possible at the moment either,
since nmc [depends on them][1].
I have decided to fix this by pointing the installed location to the one
in the build directory using libredirect. Unfortunately, we cannot just set
the environment variables directly, since the build system runs
the documentation generator in a clean environment.
I have also added man, doc and devdoc outputs so the generated files have
somewhere to go.
Secondly, since Nix store is immutable, we also cannot use the package prefix
for configuration and mutable state data. At the same time, we cannot write
to the appropriate global directories during build. Autotools allowed to change
this in installFlags but Meson lacks similar mechanism so we need to patch
the build files.
Finally, I also removed the at_console patch since the permission has been
removed in 0.9.10.
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=796755
Compatibility with other distributions/software and expectation
of users coming from other systems should have higher priority over consistency.
In particular this fixes#51375, where the NetworkManager-wait-online.service
broke as a result of this.
