We need this for intel-compute-runtime, see #63705

This fixes #67780.

Currently, using `mpv --hwdec=nvdec --msg-level=vd=debug` on NVIDIA results in:

```
[vd] Opening decoder hevc
[vd] Looking at hwdec hevc-nvdec...
Cannot load libcuda.so.1
[vd] Could not create device.
[vd] No hardware decoding available for this codec.
```

With just mpv patched, ffmpeg cannot load libnvcuvid.so.1:

```
[vd] Opening decoder hevc
[vd] Looking at hwdec hevc-nvdec...
[vd] Trying hardware decoding via hevc-nvdec.
[vd] Selected codec: hevc (HEVC (High Efficiency Video Coding))
[vd] Pixel formats supported by decoder: vaapi_vld cuda yuv420p10le
[vd] Codec profile: Main 10 (0x2)
[vd] Requesting pixfmt 'cuda' from decoder.
[ffmpeg/video] hevc: Cannot load libnvcuvid.so.1
[ffmpeg/video] hevc: Failed loading nvcuvid.
[ffmpeg/video] hevc: Failed setup for format cuda: hwaccel initialisation returned error.
```

With both mpv and ffmpeg patched, it works:

```
[vd] Opening decoder hevc
[vd] Looking at hwdec hevc-nvdec...
[vd] Trying hardware decoding via hevc-nvdec.
[vd] Selected codec: hevc (HEVC (High Efficiency Video Coding))
[vd] Pixel formats supported by decoder: vaapi_vld cuda yuv420p10le
[vd] Codec profile: Main 10 (0x2)
[vd] Requesting pixfmt 'cuda' from decoder.
Using hardware decoding (nvdec).
[vd] Decoder format: 3840x2160 cuda[p010] bt.2020-ncl/bt.2020/pq/limited/auto SP=10.000000 CL=unknown (auto 0.000000/0.000000/0.000000)
```

It might have been there as a transitive dependency but better be
explicity about it.

Previously only direct dependencies were available in the python search
path. Transitive dependencies would not be available and thus a few
features would not work due to import errors. Those import errors were
being caugth and gave a (wrong) hint why it wouldn't work. By using
`python.withPackages` instead of the crafted search path with only the
direct dependencies those missing feature should now be working.

See issue #67094 for details on the observed errors.

Fixes #67094

It is not a python module just an application using/based on python.

Putting the file in $out/share/bash-completion/completions means that it will be loaded on demand by nixpkgs.bash-completion.

With the old location, the user would either have to explicitly source the file during bash startup, or set BASH_COMPLETION_COMPAT_DIR before sourcing bash_completion.sh, which will eagerly load everything in that directory.

This is the default on most systems, most users want this one. The
value can still be overriden with the “PAGER” value.

Triggering this setupHook for dependencies at targetOffset does not work
in cross-compilation cases where such a dependency is lacking. This
simplified setupHook is more robust.

https://roy.marples.name/blog/dhcpcd-8-0-6-released

https://www.infradead.org/openconnect/changelog.html

( CVE-2019-16239 )

https://github.com/libuv/libuv/releases/tag/v1.32.0
https://github.com/libuv/libuv/releases/tag/v1.31.0

https://roy.marples.name/blog/openresolv-3-9-2-released

* libnm-glib is gone 👋️
* correct dbus_conf_dir
* remove legacy service symlink
* upstream defaults to 'internal' for dhcp
  NixOS module reflects this.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.20.2/NEWS

dhcpcd: 8.0.3 -> 8.0.6

QT 5.12 introduced a regression, where a QT program wouldn't show its
tray icon, if there was no tray bar during program startup. (QTBUG-73459)

QT 5.12 introduced a regression, where qtwebengine applications would
freeze in some wayland compositors if a surface from the instance was not
visible (for example having a qutebrowser window on another workspace in
sway would freeze all qutebrowser windows).

Both got fixed already in Qt 5.12.4, but according to #57042 and its
sibling issues/PRs it doesn't seem to get fixed in near future for
nixpkgs.

networkmanager: 1.18.2 -> 1.20.2

Update dbus-sys-dir to not use deprecated directory.

https://gitlab.freedesktop.org/mobile-broadband/ModemManager/blob/1.10.4/NEWS
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/blob/1.10.2/NEWS

Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>

modemmanager: 1.10.0 -> 1.10.4

This reverts commit a95a53a.
i.e. the change is moved from the master branch to staging.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

…em.d

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.

…em.d

Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.