diffoscope-190 already contains the fix:

    applying patch /nix/store/icfygfs9d249x7if0w7004vimzkj4082-fix-uimage-on-file-5.41.patch
    patching file tests/comparators/test_uimage.py
    Hunk #1 FAILED at 98.
    1 out of 1 hunk FAILED -- saving rejects to file tests/comparators/test_uimage.py.re

    $ diffoscope '...-hdf5-1.12.1' '...-hdf5-1.12.1.check'
    --- ...-hdf5-1.12.1/lib/libhdf5.settings
    +++ ...-hdf5-1.12.1.check/lib/libhdf5.settings
     -1,17 +1,17 @@
                      HDF5 Version: 1.12.1
    -                Configured on: Thu Oct 28 17:42:30 UTC 2021
    +                Configured on: Sat Nov  6 19:02:02 UTC 2021
                     Configured by: nixbld@
                       Host system: x86_64-unknown-linux-gnu
    -            Uname information: Linux localhost 5.10.76 #1-NixOS SMP Wed Oct 27 07:56:57 UTC 2021 x86_64 GNU/Linux
    +            Uname information: Linux localhost 5.14.15 #1-NixOS SMP Wed Oct 27 07:59:56 UTC 2021 x86_64 GNU/Linux

The patch removes `Configured on`, `Configured by` and `Uname information` fields.

Without the change build fails as:

    patch -p0 < patches/zkc-3.4.5-gcc-8.patch 2>&1
    patching file zkc-3.4.5/c/src/zookeeper.c
    Hunk #1 FAILED at 3418.
    1 out of 1 hunk FAILED -- saving rejects to file zkc-3.4.5/c/src/zookeeper.c.rej

The test failed with

> Test "test5 user should not be able to run commands under root" failed with
> error: "invalid literal for int() with base 10: ''"

since 2492da8.

The reason for this is that `sudo(8)` writes the lecture to the
tty[1] and only as a fallback to stdout[2]. This means that the
`base64 --wrap 0` executed by `machine.execute()` doesn't affect the
text written to the terminal, however the lecture is part of the string
that's read from the VM via `shell.recv()`.

I confirmed the problem in an interactive test session[3]:

    >>> command = "sudo -u test5 sudo -n -u root true"
    >>> out_command = f"( set -euo pipefail; {command} ) | (base64 --wrap 0; echo)\n"
    >>> machine.shell.send(out_command.encode())
    84

    >>> machine # [   99.015512] sudo[877]:     root : TTY=hvc0 ; PWD=/tmp ; USER=test5 ; COMMAND=/run/wrappers/bin/sudo -n -u root true
    machine # [   99.019373] sudo[877]: pam_unix(sudo:session): session opened for user test5(uid=1005) by (uid=0)
    machine # [   99.038692] sudo[879]: pam_unix(sudo:auth): conversation failed
    machine # sudo: a password is required
    machine # [   99.041860] sudo[879]: pam_unix(sudo:auth): auth could not identify password for [test5]
    machine # [   99.046901] sudo[877]: pam_unix(sudo:session): session closed for user test5
    >>>
    >>> x=machine._next_newline_closed_block_from_shell()
    >>> print(x)
    <newline>
    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:
    <newline>
        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.
    <newline>
    <newline>
    <newline>
    >>>

Since the lecture isn't strictly necessary to confirm that
`security.sudo` works as expected, I decided to disable lecturing
inside the test, however we may want to fix the underlying problem in
the test-driver at some point.

[1] https://github.com/sudo-project/sudo/blob/SUDO_1_9_9/plugins/sudoers/check.c#L275-L283
[2] https://github.com/sudo-project/sudo/blob/SUDO_1_9_9/src/conversation.c#L95-L120
[3] I replaced each empty line with `<newline>` to make sure these
    aren't swallowed by git.

This effectively fixes the majority of all VM tests which were broken
because `/dev/vda` (or any other block device) wasn't mountable:

      machine # mounting /dev/vda on /...
      machine # mount: mounting /dev/vda on /mnt-root/ failed: No such device[    2.820976] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
      machine # [    2.821757] CPU: 0 PID: 1 Comm: init Not tainted 5.10.72 #1-NixOS
      machine # [    2.821757] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      machine # [    2.821757] Call Trace:
      machine # [    2.821757]  dump_stack+0x6b/0x83
      machine # [    2.821757]  panic+0x101/0x2c8
      machine # [    2.821757]  do_exit.cold+0x14/0xb3
      machine # [    2.821757]  do_group_exit+0x33/0xa0
      machine # [    2.821757]  __x64_sys_exit_group+0x14/0x20
      machine # [    2.821757]  do_syscall_64+0x33/0x40
      machine # [    2.821757]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      machine # [    2.821757] RIP: 0033:0x7f67ec2800f6
      machine # [    2.821757] Code: 00 4c 8b 0d 2c 5d 11 00 eb 19 66 2e 0f 1f 84 00 00 00 00 00 89 d7 89 f0 0f 05 48 3d 00 f0 ff ff 77 22 f4 89 d7 44 89 c0 0f 05 <48> 3d 00 f0 ff ff 76 e2 f7 d8 64 41 89 01 eb da 66 2e 0f 1f 84 00
      machine # [    2.821757] RSP: 002b:00007fff8f5a71d8 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
      machine # [    2.821757] RAX: ffffffffffffffda RBX: 0000000000699704 RCX: 00007f67ec2800f6
      machine # [    2.821757] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
      machine # [    2.821757] RBP: 0000000000000004 R08: 00000000000000e7 R09: ffffffffffffff80
      machine # [    2.821757] R10: 00007f67ec33f3e0 R11: 0000000000000202 R12: 000000000000000b
      machine # [    2.821757] R13: 00007fff8f5a75a8 R14: 0000000000000000 R15: 00000000004fc198
      machine # [    2.821757] Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      machine # [    2.821757] Rebooting in 1 seconds..

This happened because the kernel failed to load modules such as `ext4`
from `boot.initrd.availableKernelModules`[1] on e.g. a `mount(2)` syscall.

The problem is that `kmod` isn't linked against `libpthread.so.0`
anymore because it got merged into `libc.so.6` (however, the .so still
exists), but still needs it:

      machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory)
      machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory)
      machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory)
      machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      machine # writev(2, [{iov_base="/nix/store/kdc9n48ksdc1a8y8w512w"..., iov_len=69}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libpthread.so.0", iov_len=15}, {iov_base=": ", iov_len=2}, {iov_base="cy
      machine # ) = 184
      machine # exit_group(127)                         = ?
      machine # +++ exited with 127 +++
      machine # mount: mounting /dev/vda on /mnt-root/ failed: No such device
      machine # [   19.167180] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
      machine # [   19.167711] CPU: 0 PID: 1 Comm: init Not tainted 5.10.72 #1-NixOS

This is not a problem

* inside stage-1 because `LD_LIBRARY_PATH` points to `$out/lib` of
  extra-utils where `libpthread.so.6` also exists.
* on a running system because `${pkgs.glibc}/lib` is part of kmod's
  rpath.

However this is a problem inside the kernel which calls `modprobe` (in
our case `kmod`) to load modules and doesn't know about
`LD_LIBRARY_PATH`. Also, the rpath-reference was nuked.

To work around this, the kernel's `modprobe`
(i.e. `/proc/sys/kernel/modprobe`) now points to a wrapper which
explicitly declares `LD_LIBRARY_PATH`. We can't use `makeWrapper` here
because `modprobe` itself must not be renamed. Otherwise, `kmod` (which
is the link-target of `modprobe`) won't work because it expects
`argv[0] == "modprobe"` to perform modprobe's tasks.

[1] https://nixos.org/manual/nixos/stable/options.html#opt-boot.initrd.availableKernelModules

SQLAlchemy-Utils v0.36.6 package override build is failing.

This is due to a patch in the original SQLAlchemy-Utils package which
broke the build of this package override:

```bash
> applying patch /nix/store/pd6anhwbf0in3r3jhi3sbn5v2fjs0mf2-skip-database-tests.patch
> patching file conftest.py
> Hunk #1 FAILED at 61.
> Hunk #2 succeeded at 98 (offset -10 lines).
```

These SQLAlchemy package overrides were originaly added to fix
incompatibilities with Flask-Admin.

See commit 05ae01f

However with Flask-Admin >= v1.5.6, several SQLAlchemy compatibility patches were added:
* https://flask-admin.readthedocs.io/en/latest/changelog/

We can now safely remove these package overrides to make bukuserver work again.

This reverts commit 246216e.

3.9.1 does not compile due to patch collision:

       > applying patch /nix/store/sickncxw0s730j6gfrnlsi5ndgysi6la-libxml2-cmake-find-package.patch
       > patching file CMakeLists.txt
       > Hunk #1 FAILED at 42.

Fixing it is not trivial as upstream started bundling libxml2:
  NixOS#182941 (comment)

Let's revert the update for now.

Without this change it segfaults when trying to play any media:

  $ jellyfinmediaplayer
  Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
  libpng warning: iCCP: known incorrect sRGB profile
  Logging to /home/bf/.local/share/jellyfinmediaplayer/logs/jellyfinmediaplayer.log
  Cannot load libcuda.so.1
  Segmentation fault (core dumped)

The backtrace shows pipewire being at fault:

  $ coredumpctl debug
  [...]
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  [Current thread is 1 (Thread 0x7f6ffdc87640 (LWP 1360949))]
  (gdb) bt
  #0  0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #1  0x00007f711428886c in process_remote () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #2  0x00007f7114288e68 in on_remote_data () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #3  0x00007f7114310efe in loop_iterate () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/spa-0.2/support/libspa-support.so
  #4  0x00007f71266fe7f2 in do_loop () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/libpipewire-0.3.so.0
  #5  0x00007f7128b08e86 in start_thread () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6
  #6  0x00007f7128b8fce0 in clone3 () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6
  (gdb)

Standalone mpv doesn't segfault (when directly playing the underlying
media files). I don't know why.

Fixes: b97cda7 ("mpv-unwrapped: 0.34.1 -> 0.35.0")

Fixes NixOS#205141

Ref jellyfin/jellyfin-desktop#341

Without this change it segfaults when trying to play any media:

  $ jellyfinmediaplayer
  Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
  libpng warning: iCCP: known incorrect sRGB profile
  Logging to /home/bf/.local/share/jellyfinmediaplayer/logs/jellyfinmediaplayer.log
  Cannot load libcuda.so.1
  Segmentation fault (core dumped)

The backtrace shows pipewire being at fault:

  $ coredumpctl debug
  [...]
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  [Current thread is 1 (Thread 0x7f6ffdc87640 (LWP 1360949))]
  (gdb) bt
  #0  0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #1  0x00007f711428886c in process_remote () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #2  0x00007f7114288e68 in on_remote_data () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #3  0x00007f7114310efe in loop_iterate () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/spa-0.2/support/libspa-support.so
  #4  0x00007f71266fe7f2 in do_loop () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/libpipewire-0.3.so.0
  #5  0x00007f7128b08e86 in start_thread () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6
  #6  0x00007f7128b8fce0 in clone3 () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6
  (gdb)

Standalone mpv doesn't segfault (when directly playing the underlying
media files). I don't know why.

Fixes: b97cda7 ("mpv-unwrapped: 0.34.1 -> 0.35.0")

Fixes NixOS#205141

Ref jellyfin/jellyfin-desktop#341

(cherry picked from commit 3c528bc)

Previously, hashcat was unable to use CUDA at runtime, and would warn:

> Failed to initialize the NVIDIA main driver CUDA runtime library.
> Failed to initialize NVIDIA RTC library.
> * Device #1: CUDA SDK Toolkit not installed or incorrectly installed.
>              CUDA SDK Toolkit required for proper device support and utilization.
>              Falling back to OpenCL runtime.

This remedies that, at least on NixOS.

1.2.1: Bug fix release:

Single bug fix (#1) that fixes regression in `perf` tool caused by libbpf
resetting its custom catch-all `SEC()` handler on explicit
`bpf_program__set_type()` call.

Given setting custom `SEC()` handlers is rarely used and pretty
esoteric feature of libbpf, most users should not be affected.

1.2.2: One more fix:

 - Fix (#2) possible double-free in USDT-related libbpf code, which
happens when libbpf runs out of space in `__bpf_usdt_specs` map due
to having too many unique USDT specs. Running out of space can be
mitigated by bumping up `BPF_USDT_MAX_SPEC_CNT` define before including
`bpf/usdt.bpf.h` header in BPF-side code.
This will prevent the double-free as a side effect (and will make it
possible to successfully attach all requested USDTs), which is a
recommended work-around for libbpf versions prior to v1.2.2.

Link: libbpf/libbpf@e4d3827 #1
Link: libbpf/libbpf@f117080 #2

had to use clangStdenv because
/nix/store/1qa12idg59nlxjjdrw4hfyxdkhfd3nrq-clang-wrapper-11.1.0/bin/ar: CMakeFiles/ananicy_cpp_bpf_c.dir/src/bpf_program_utils.c.o: plugin needed to handle lto object
ananicy-cpp> /nix/store/1qa12idg59nlxjjdrw4hfyxdkhfd3nrq-clang-wrapper-11.1.0/bin/ranlib: libananicy_cpp_bpf_c.a(bpf_program_utils.c.o): plugin needed to handle lto object
ananicy-cpp> [100%] Linking CXX executable ananicy-cpp
ananicy-cpp> /nix/store/zsvpmlddl2i5mpzm031a99xfpn410m5b-binutils-2.40/bin/ld: /build/cchtSHrR.ltrans5.ltrans.o: in function `ProcessQueue::stop()':
ananicy-cpp> <artificial>:(.text+0x2274): undefined reference to `destroy_bpf_program'
ananicy-cpp> /nix/store/zsvpmlddl2i5mpzm031a99xfpn410m5b-binutils-2.40/bin/ld: /build/cchtSHrR.ltrans5.ltrans.o: in function `ProcessQueue::init()':
ananicy-cpp> <artificial>:(.text+0x8460): undefined reference to `initialize_bpf_program'
ananicy-cpp> /nix/store/zsvpmlddl2i5mpzm031a99xfpn410m5b-binutils-2.40/bin/ld: <artificial>:(.text+0x846c): undefined reference to `bpf_program_init_events'
ananicy-cpp> /nix/store/zsvpmlddl2i5mpzm031a99xfpn410m5b-binutils-2.40/bin/ld: <artificial>:(.text+0x8486): undefined reference to `destroy_bpf_program'
ananicy-cpp> /nix/store/zsvpmlddl2i5mpzm031a99xfpn410m5b-binutils-2.40/bin/ld: /build/cchtSHrR.ltrans5.ltrans.o: in function `std::thread::_State_impl<std::thread::_Invoker<std::tuple<ProcessQueue::start()::{lambda(std::stop_token const&)#1}, std::stop_token> > >::_M_run() [clone .lto_priv.0]':
ananicy-cpp> <artificial>:(.text+0x861d): undefined reference to `destroy_bpf_program'
ananicy-cpp> collect2: error: ld returned 1 exit status
ananicy-cpp> make[2]: *** [CMakeFiles/ananicy-cpp.dir/build.make:325: ananicy-cpp] Error 1
ananicy-cpp> make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/ananicy-cpp.dir/all] Error 2
ananicy-cpp> make: *** [Makefile:136: all] Error 2

Upstream supports php 8.0/8.1 for the 3.3.0 release. The upgrade to 8.2
caused a type mismatch in carbon.

> PHP message: Exception: Code: 0, Message: Carbon\Carbon::setLastErrors(): Argument #1 ($lastErrors) must be of type array, bool given, called in /nix/store/2prnw9qya9kaks2rwvd6fkrz0c7l5ygd-engelsystem-3.3.0/share/engelsystem/vendor/nesbot/carbon/src/Carbon/Traits/Creator.php on line 98, File: vendor/nesbot/carbon/src/Carbon/Traits/Creator.php:928

Pull in _FORTIFY_SOURCE=3 stack smashing fix. Without the change on
current `master` `rtorrent` crashes at start as:

*** buffer overflow detected ***: terminated
                                                                                        __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44      pthread_kill.c: No such file or directory.
(gdb) bt
    #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
    #1  0x00007ffff7880af3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
    #2  0x00007ffff7831c86 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #3  0x00007ffff781b8ba in __GI_abort () at abort.c:79
    #4  0x00007ffff781c5f5 in __libc_message (fmt=fmt@entry=0x7ffff7992540 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150
    #5  0x00007ffff7910679 in __GI___fortify_fail (msg=msg@entry=0x7ffff79924e6 "buffer overflow detected") at fortify_fail.c:24
    #6  0x00007ffff790eea4 in __GI___chk_fail () at chk_fail.c:28
    #7  0x00007ffff790ea85 in ___snprintf_chk (s=<optimized out>, maxlen=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at snprintf_chk.c:29
    #8  0x0000000000472acf in utils::Lockfile::try_lock() ()
    #9  0x000000000044b524 in core::DownloadStore::enable(bool) ()
    #10 0x00000000004b1f7b in Control::initialize() ()
    #11 0x000000000043000b in main ()

duckdb 0.9.0 without git deepcopy and hash version.

Without the change `amdgpu-pro` tried to build `libffi-3.3` with patches
for `libffi-3.4` and failed as:

    patching file include/ffi_common.h
    Hunk #1 succeeded at 103 with fuzz 2 (offset -25 lines).
    can't find file to patch at input line 36

THe change uses `libffi_3_3` instead.

Closes: NixOS#279955

Since ba83271 the build fails with

    applying patch /nix/store/46rxbbvl2l3mrxb50y9rzy7ahgx0lraj-d741901dddd731895346636c0d3556c6fa51fbe6.patch
    patching file tests/hazmat/primitives/test_aead.py
    Hunk #1 FAILED at 56.
    Hunk #2 FAILED at 197.
    Hunk #3 FAILED at 378.
    Hunk #4 FAILED at 525.
    Hunk #5 FAILED at 700.
    Hunk #6 FAILED at 844.
    6 out of 6 hunks FAILED -- saving rejects to file tests/hazmat/primitives/test_aead.py.rej

Without the change `unnethack` startup crashes as:

    (gdb) bt
    #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
    #1  0x00007f734250c0e3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
    #2  0x00007f73424bce06 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #3  0x00007f73424a58f5 in __GI_abort () at abort.c:79
    #4  0x00007f73424a67a1 in __libc_message (fmt=fmt@entry=0x7f734261e2f8 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150
    #5  0x00007f734259b1d9 in __GI___fortify_fail (msg=msg@entry=0x7f734261e2df "buffer overflow detected") at fortify_fail.c:24
    #6  0x00007f734259ab94 in __GI___chk_fail () at chk_fail.c:28
    #7  0x00000000005b2ac5 in strcpy (__src=0x7ffe68838b00 "Shall I pick a character's race, role, gender and alignment for you? [YNTQ] (y)",
        __dest=0x7ffe68838990 "\001") at /nix/store/B0S2LKF593R3585038WS4JD3LYLF2WDX-glibc-2.38-44-dev/include/bits/string_fortified.h:79
    #8  curses_break_str (str=str@entry=0x7ffe68838b00 "Shall I pick a character's race, role, gender and alignment for you? [YNTQ] (y)", width=width@entry=163,
        line_num=line_num@entry=1) at ../win/curses/cursmisc.c:275
    #9  0x00000000005b3f51 in curses_character_input_dialog (prompt=prompt@entry=0x7ffe68838cf0 "Shall I pick a character's race, role, gender and alignment for you?",
        choices=choices@entry=0x7ffe68838d70 "YNTQ", def=def@entry=121) at ../win/curses/cursdial.c:211
    #10 0x00000000005b9ca0 in curses_choose_character () at ../win/curses/cursinit.c:556
    #11 0x0000000000404eb1 in main (argc=<optimized out>, argv=<optimized out>) at ./../sys/unix/unixmain.c:309

which corresponds to `gcc` warning:

    ../win/curses/cursmisc.c: In function 'curses_break_str':
    ../win/curses/cursmisc.c:275:5: warning: '__builtin___strcpy_chk' writing one too many bytes into a region of a size that depends on 'strlen' [-Wstringop-overflow=]
      275 |     strcpy(substr, str);
          |     ^

I did not find a single small upstream change that fixes it. Let's
disable `fortify3` until next release.

Closes: NixOS#292113

This adds some extremely helpful and popular encoders in by default:
* openjpeg
* celt
* libwebp
* libaom

On the `master` branch, closure size for ffmpeg-headless went up 18.5 MiB.
```
$ nix store diff-closures nixpkgs#ffmpeg-headless^bin .#ffmpeg-headless^bin
celt: ∅ → 0.11.3, +168.4 KiB
ffmpeg-headless: +70.0 KiB
giflib: ∅ → 5.2.2, +398.7 KiB
lcms2: ∅ → 2.16, +466.2 KiB
lerc: ∅ → 4.0.0, +840.2 KiB
libaom: ∅ → 3.9.0, +8047.8 KiB
libdeflate: ∅ → 1.20, +427.0 KiB
libtiff: ∅ → 4.6.0, +655.9 KiB
libvmaf: ∅ → 3.0.0, +2665.0 KiB
libwebp: ∅ → 1.4.0, +2559.7 KiB
openjpeg: ∅ → 2.5.2, +1525.1 KiB
zstd: ∅ → 1.5.6, +1158.0 KiB

$ nvd diff $(nix build nixpkgs#ffmpeg-headless^bin --print-out-paths --no-link) $(nix build .#ffmpeg-headless^bin --print-out-paths --no-link)
<<< /nix/store/4n60lnj3zkjpasd4c56bzhpx2m8lc1sx-ffmpeg-headless-6.1.1-bin
>>> /nix/store/884f487w5hac6rs94jq6hq5zqkxdv666-ffmpeg-headless-6.1.1-bin
Added packages:
[A.]  #1  celt        0.11.3
[A.]  #2  giflib      5.2.2
[A.]  #3  lcms2       2.16
[A.]  #4  lerc        4.0.0
[A.]  #5  libaom      3.9.0
[A.]  #6  libdeflate  1.20
[A.]  #7  libtiff     4.6.0
[A.]  #8  libvmaf     3.0.0
[A.]  #9  libwebp     1.4.0 x2
[A.]  #10  openjpeg    2.5.2
[A.]  #11  zstd        1.5.6
Closure size: 66 -> 78 (15 paths added, 3 paths removed, delta +12, disk usage +18.5MiB).
```

Strongly inspired by the forgejo counterpart[1], for the following
reasons:

* The feature is broken with the current module and crashes on
  authentication with the following stacktrace (with a PAM service
  `gitea` added):

      server # Stack trace of thread 1008:
      server # #0  0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
      server # #1  0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
      server # #2  0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
      server # #3  0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
      server # #4  0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
      server # #5  0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
      server # #6  0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
      server # #7  0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
      server # #8  0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
      server # ELF object binary architecture: AMD x86-64
      server #
      server # [   42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
      server # [   42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost=  user=snenskek

  It only worked after turning off multiple sandbox settings and adding
  `shadow` as supplementary group to `gitea.service`.

  I'm not willing to maintain additional multiple sandbox settings for
  different features, especially given that it was probably not used for
  quite a long time:

  * There was no PR or bugreport about sandboxing issues related to
    PAM.

  * Ever since the module exists, it used the user `gitea`, i.e. it had
    never read-access to `/etc/shadow`.

* Upstream has it disabled by default[2].

If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.

[1] 07641a9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module

[Vidstab][1] is an useful ffmpeg video stabilization filter.

Both [Debian][2] and [Archlinux][3] enable it on default ffmpeg build,
we should also enable it on default ffmpeg in nixpkgs.

On the `master` branch, closure size for ffmpeg-headless went up 182.9KiB.
```
$ nix store diff-closures nixpkgs#ffmpeg-headless^bin .#ffmpeg-headless^bin
ffmpeg-headless: +18.1 KiB
vid.stab-unstable: ∅ → 2022-05-30, +164.8 KiB

$ nvd diff $(nix build nixpkgs#ffmpeg-headless^bin --print-out-paths --no-link) $(nix build .#ffmpeg-headless^bin --print-out-paths --no-link)
<<< /nix/store/kwihalx7ryh51ghcp8f1hhy8skbdh8w9-ffmpeg-headless-6.1.2-bin
>>> /nix/store/ps62y85p9jgjbf2x9s97199mpqnd0ggz-ffmpeg-headless-6.1.2-bin
Added packages:
[A.]  #1  vid.stab-unstable  2022-05-30
Closure size: 78 -> 79 (4 paths added, 3 paths removed, delta +1, disk usage +182.9KiB).
```

[1]: http://public.hronopik.de/vid.stab/
[2]: https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/7%256.1.1-5/debian/control#L158
[3]: https://gitlab.archlinux.org/archlinux/packaging/packages/ffmpeg/-/blob/2-6.1.1-7/PKGBUILD?ref_type=tags#L73

The first assumption[1] we had was that the `aarch64-unknown-none`
target was missing from rustc and that this was the cause for the
regression.

However, it turns out that the relevant code from `rustc` wasn't used
anyways because the Makefile does `--sysroot /dev/null`[2] which prevents
rustc from using its own libcore. So luckily we don't have to patch the
Rust bootstrap to get aarch64-linux back working[3].

In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I
decided to not bother since none of those are longterm versions.

So all that's left here is to enable Rust for aarch64-linux because it
clearly works[5].

[1] NixOS#315121 (comment)
[2] https://lore.kernel.org/all/[email protected]/
[3] Of course I only realized this _after_ I spent some time hacking a rustc
    patch together 🙃
[4] This broke with

        error[E0463]: can't find crate for `core`
          |
          = note: the `aarch64-unknown-none` target may not be installed
          = help: consider downloading the target with `rustup target add aarch64-unknown-none`
          = help: consider building the standard library from source with `cargo build -Zbuild-std`

[5] While the build is fine, the VM tests are still panicking, but
    that's also the case for `kernel-generic` because of a 9p
    regression:

        switch_root: can't execute '/nix/store/zv87gw0yxfsslq0mcc35a99k54da9a4z-nixos-system-machine-test/init': Exec format error
        [    1.734997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
        [    1.736002] CPU: 0 UID: 0 PID: 1 Comm: switch_root Not tainted 6.12.0-rc1 #1-NixOS
        [...]

    Reported as https://lore.kernel.org/all/[email protected]/T/#u

Added bolt-launcher, an alternative launcher for Runescape 3 / Old
School Runescape.

https://github.com/Adamcake/Bolt/releases/tag/0.9.0

bolt-launcher: add plugin loader for rs3

Building the app with luajit, which allows for Runescape 3 plugin
loading.

bolt-launcher: add runescape 3 dependencies

Added Runescape 3 dependencies inside the buildFHSEnv, so that it can be
used by the binary (downloaded from the internet by bolt-launcher
itself, hence why the fhs env is needed here).

bolt-launcher: fix dependency issues

Added libbolt-plugin.so into $out/lib, which allows the program to use
the Runescape 3 plugin loader. Also updated the mainProgram as well as
runScript so that the program can be ran from nix run instead of just
being able to be ran manually.

Add feature flags for RS3 and HDOSAndRuneLite as well as .desktop and icon file support (#1)

* Add enable flags for RS3 and HDOSAndRuneLite

* Add .desktop and icon

* Fix formatting w/ nixfmt

* Remove enableHDOSAndRuneLite feature flag

* Fix formatting

Co-authored-by: Thomas King <[email protected]>

Driving NixOS#237216 forward.

nixosTests.cryptpad started failing recently.

Investigating the issue shows that seccomp has become problematic during
the init phase, (e.g. this can be reproduced by removing the customize
directory in /var/lib/cryptpad):

machine # [   10.774365] systemd-coredump[864]: Process 756 (node) of user 65513 dumped core.
machine #
machine # Module libgcc_s.so.1 without build-id.
machine # Module libstdc++.so.6 without build-id.
machine # Module libicudata.so.74 without build-id.
machine # Module libicuuc.so.74 without build-id.
machine # Module libicui18n.so.74 without build-id.
machine # Module libz.so.1 without build-id.
machine # Module node without build-id.
machine # Stack trace of thread 756:
machine # #0  0x00007ff951974dcb fchown (libc.so.6 + 0x107dcb)
machine # #1  0x00007ff95490d0c0 uv__fs_copyfile (libuv.so.1 + 0x150c0)
machine # #2  0x00007ff95490d89a uv__fs_work (libuv.so.1 + 0x1589a)
machine # #3  0x00007ff954910c76 uv_fs_copyfile (libuv.so.1 + 0x18c76)
machine # #4  0x0000000000eb8a39 _ZN4node2fsL8CopyFileERKN2v820FunctionCallbackInfoINS1_5ValueEEE (node + 0xab8a39)
machine # #5  0x0000000001cda5e2 Builtins_CallApiCallbackGeneric (node + 0x18da5e2)
[...]
machine # [   10.877468] cryptpad[685]: /nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/bin/cryptpad: line 3:   756 Bad system call         (core dumped) "/nix/store/fkyp1bm5gll9adnfcj92snyym524mdrj-nodejs-22.11.0/bin/node" "/nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/lib/node_modules/cryptpad/scripts/build.js"

nodejs 20.18 rightly did not require chown when the source and
destination are the same owner (heck, the script does not run as
root so even if it is not blocked there is no way it'd work with a
different owner...)

For now just allow chown calls again, this is not worth wasting more
time.

Fixes NixOS#370717

This test crashes the python interpreter in libx265_encode_stream:

```
 #0  0x00007feefe2a7a7e in free () from /nix/store/81mi7m3k3wsiz9rrrg636sx21psj20hc-glibc-2.40-66/lib/libc.so.6
 No symbol table info available.
 #1  0x00007fee98059295 in av_free (ptr=<optimized out>) at libavutil/mem.c:243
 No locals.
 #2  0x00007fee98059352 in av_freep (arg=<optimized out>) at libavutil/mem.c:253
        val = <optimized out>
 #3  0x00007fee997a4713 in libx265_encode_frame (avctx=<optimized out>, pkt=<optimized out>, pic=<optimized out>,
    got_packet=0x7ffe35c7e3f4) at libavcodec/libx265.c:821
    [...]
 #4  0x00007fee99526ff6 in ff_encode_encode_cb (avctx=avctx@entry=0x16d1f00, avpkt=avpkt@entry=0x16ad440, frame=0x16f5e80, got_packet=got_packet@entry=0x7ffe35c7e3f4) at libavcodec/encode.c:254
        codec = 0x7fee9a25e5c0 <ff_libx265_encoder>
 [...]
```

Prior to this the `dev` output was also propagated, when it's not
actually used

```console
$ nix-store --query --references /nix/store/ppw0flx4dbksxsnr84hq1gz4k0s0hpcq-nixos-rebuild-ng-0.0.0
/nix/store/11ciq72n4fdv8rw6wgjgasfv4mjs1jrw-bash-5.2p37
/nix/store/26yi95240650jxp5dj78xzch70i1kzlz-python3-3.12.9
/nix/store/xxh7mivp64xmzyw5wir2c2xbhy6cjzjd-nix-2.24.12
/nix/store/8jai5cxdfzgj9nsz4i26fh9sx5zsgilz-nix-2.24.12-dev
/nix/store/ppw0flx4dbksxsnr84hq1gz4k0s0hpcq-nixos-rebuild-ng-0.0.0
```

```console
$ nix why-depends --all --precise /nix/store/ppw0flx4dbksxsnr84hq1gz4k0s0hpcq-nixos-rebuild-ng-0.0.0 /nix/store/8jai5cxdfzgj9nsz4i26fh9sx5zsgilz-nix-2.24.12-dev
/nix/store/ppw0flx4dbksxsnr84hq1gz4k0s0hpcq-nixos-rebuild-ng-0.0.0
└───nix-support/propagated-build-inputs: …/nix/store/8jai5cxdfzgj9nsz4i26fh9sx5zsgilz-nix-2.24.12-dev /nix/store/26yi…
    → /nix/store/8jai5cxdfzgj9nsz4i26fh9sx5zsgilz-nix-2.24.12-dev
```

```console
$ nvd diff /nix/store/ppw0flx4dbksxsnr84hq1gz4k0s0hpcq-nixos-rebuild-ng-0.0.0 /nix/store/fqm81bhggzkqh7033np2z0jr8c0qrpbw-nixos-rebuild-ng-0.0.0
<<< /nix/store/ppw0flx4dbksxsnr84hq1gz4k0s0hpcq-nixos-rebuild-ng-0.0.0
>>> /nix/store/fqm81bhggzkqh7033np2z0jr8c0qrpbw-nixos-rebuild-ng-0.0.0
Version changes:
[C.]  #1  boehm-gc  8.2.8, 8.2.8-dev -> 8.2.8
[C*]  #2  nix       2.24.12, 2.24.12-dev, 2.24.12-man -> 2.24.12, 2.24.12-man
Removed packages:
[R.]  #1  nlohmann_json  3.11.3
Closure size: 66 -> 63 (1 paths added, 4 paths removed, delta -3, disk usage -1.9MiB).
```

Fix eval failure #1

fluent-bit 3.2.7, 3.2.8 and 3.2.9 are segfaulting when
used in combination with the systemd input. Lets
revert to 3.2.6 for now.

Upstream bug: fluent/fluent-bit#10139

Note that fluent-bit-3.2.7 fixes two high CVEs which we are now
reintroducing. However they are only exploitable if you are
using the OpenTelemetry input or the Prometheus Remote Write input.

OpenTelemetry input: [CVE-2024-50609](https://nvd.nist.gov/vuln/detail/CVE-2024-50609)
Prometheus Remote Write input: [CVE-2024-50608](https://nvd.nist.gov/vuln/detail/CVE-2024-50608)

The problem is as follows:

3.2.7 started vendoring a copy of `libzstd` in tree and statically
linking against it. Also, the fluent-bit binary exports the symbols
of static libraries it links against.

This is a problem because `libzstd` gets `dlopen()`ed by `libsystemd`
when enumerating the journal (as journal logs are zstd compressed). and `libzstd` in Nixpkgs is built
with `-DZSTD_LEGACY_SUPPORT=0` which causes `struct ZSTD_DCtx` to be 16
bytes smaller than without this flag https://github.com/facebook/zstd/blob/dev/lib/decompress/zstd_decompress_internal.h#L183-L187

`libsystemd` calls [`sym_ZSTD_createDCtx()`](https://github.com/systemd/systemd/blob/1e79a2923364b65fc9f347884dd5b9b2087f6e32/src/basic/compress.c#L480)
which calls the function pointer returned by `dlsym()` which is calling into
the `libzstd` that comes with `nixpkgs` and thus allocates a struct that is 16 bytes smaller.

Later then `sym_ZSTD_freeDCtx()` is called. However because fluent-bit
has `zstd` in its global symbol table, any functions that `sym_ZSTD_freeDCtx()`
calls will be calls to the functions in the vendored fluent-bit version of the library
which expects the larger struct. This then causes enough heap corruption to cause
a segfault.

E.g. the subsequent calls to `ZSTD_clearDict(dctx)` and `ZSTD_customFree(dctx->inBuff)`
in https://github.com/facebook/zstd/blob/dev/lib/decompress/zstd_decompress.c#L324
will be working on a struct that is 16 bytes smaller than the one that was allocated
by `libsystemd` and will cause a segfault at some point and thus are probably modifying
pieces of memory that they shouldn't

	(gdb) bt
	#0  0x00007f10e7e9916c in __pthread_kill_implementation () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#1  0x00007f10e7e40e86 in raise () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#2  0x00007f10e7e2893a in abort () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#3  0x000000000046a938 in flb_signal_handler ()
	#4  <signal handler called>
	#5  0x00007f10e7ea42b7 in unlink_chunk.isra () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#6  0x00007f10e7ea45cd in _int_free_create_chunk () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#7  0x00007f10e7ea5a1c in _int_free_merge_chunk () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#8  0x00007f10e7ea5dc9 in _int_free () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#9  0x00007f10e7ea8613 in free () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#10 0x00007f10e80ad3b5 in ZSTD_freeDCtx () from /nix/store/wy0slah6yvchgra8nhp6vgrqa6ay72cq-zstd-1.5.6/lib/libzstd.so.1
	#11 0x00007f10e8c90f6b in decompress_blob_zstd () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0
	#12 0x00007f10e8bf0efe in journal_file_data_payload () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0
	#13 0x00007f10e8c00f74 in sd_journal_enumerate_data () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0
	#14 0x00000000004eae2f in in_systemd_collect ()
	#15 0x00000000004eb5a0 in in_systemd_collect_archive ()
	#16 0x000000000047aa18 in flb_input_collector_fd ()
	#17 0x0000000000495223 in flb_engine_start ()
	#18 0x000000000046f304 in flb_lib_worker ()
	#19 0x00007f10e7e972e3 in start_thread () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#20 0x00007f10e7f1b2fc in __clone3 () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6

Reverts 7310ab3
Reverts 4fbc6cf

[kaos branding] Fix broken link

On my systems there is a path in the fonts list that looks like
/nix/store/<hash>-<font>.ttf. The previous code assumed that every font path
contains at least one more slash which isn't the case here.

The code matched on the / after the $out path of the derivation:

/nix/store/<hash>-<name>/share/X11/fonts/...
                        ^

That slash only exists if the font lives in a subdirectory, which
isn't strictly required. In my case I've a few font files that are
located at /nix/store/<hash>-<name>.ttf and are assembled into a
folder as symlinks. (See example below)

Any attempt at calling realpath(3) on them (potentially recursively)
will result in the single file entry in the store being returned.

Whenever that font is being loaded flatpak segfaulted like so:

```
(gdb) bt
#0  0x00005583b3673763 in get_nix_closure ()
#1  0x00005583b3673711 in get_nix_closure ()
#2  0x00005583b36737dc in add_nix_store_symlink_targets ()
#3  0x00005583b36749a8 in add_font_path_args ()
#4  0x00005583b367b3f4 in flatpak_run_app ()
#5  0x00005583b35e4f08 in flatpak_builtin_run ()
#6  0x00005583b35a5970 in main ()
(gdb) x/5i $rip
=> 0x5583b3673763 <get_nix_closure+307>:	movb   $0x0,(%rax)
   0x5583b3673766 <get_nix_closure+310>:	call   0x5583b35a46a0 <g_hash_table_add@plt>
   0x5583b367376b <get_nix_closure+315>:	jmp    0x5583b3673699 <get_nix_closure+105>
   0x5583b3673770 <get_nix_closure+320>:	xor    %edi,%edi
   0x5583b3673772 <get_nix_closure+322>:	lea    0x30475(%rip),%rsi        # 0x5583b36a3bee
(gdb) x/s $rsi
0x5583e92d2180:	"/nix/store/<hash>-A.ttf"
(gdb) print $rax
$1 = 0
```

RAX pointing to 0 here corresponds to the pointer `p` in the source
code. So the code attempted to dereference a null pointer as no further
slash (the return value of strchr(3)) could be found.

The modification in this commit ensures that we check for `p != 0` so
we don't run into this situation again.

Adding the path to the closure will still be done, even if no further
slash can be found, as that still points to a valid store path.

----

Nix code for custom fonts:

```nix
let
  files = [
    ./A.ttf
    ./B.ttf
  ];
in
runCommandNoCC "custom-fonts" {} ''
  mkdir -p $out/share/fonts/truetype
  cd $out/share/fonts/truetype
  ${ lib.concatStringsSep "\n" (map (file: "ln -s ${file} ${baseNameOf file}") files)}
''
```