forked from NixOS/nixpkgs
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tts: get mozilla tts working #1
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mweinelt
pushed a commit
that referenced
this pull request
Dec 5, 2021
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
mweinelt
pushed a commit
that referenced
this pull request
Feb 4, 2022
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.
mweinelt
pushed a commit
that referenced
this pull request
Mar 6, 2022
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
mweinelt
pushed a commit
that referenced
this pull request
May 14, 2022
mweinelt
pushed a commit
that referenced
this pull request
Aug 23, 2022
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.
mweinelt
pushed a commit
that referenced
this pull request
Sep 28, 2022
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.
mweinelt
pushed a commit
that referenced
this pull request
Jan 2, 2023
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-media-player#341
mweinelt
pushed a commit
that referenced
this pull request
Jan 11, 2023
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-media-player#341 (cherry picked from commit 3c528bc)
mweinelt
pushed a commit
that referenced
this pull request
Jul 1, 2023
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.
mweinelt
pushed a commit
that referenced
this pull request
Jul 15, 2023
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
mweinelt
pushed a commit
that referenced
this pull request
Jul 18, 2023
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
mweinelt
added a commit
that referenced
this pull request
Jul 18, 2023
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
mweinelt
pushed a commit
that referenced
this pull request
Aug 4, 2023
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() () NixOS#11 0x000000000043000b in main ()
mweinelt
pushed a commit
that referenced
this pull request
Oct 3, 2023
duckdb 0.9.0 without git deepcopy and hash version.
mweinelt
pushed a commit
that referenced
this pull request
Feb 19, 2024
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
mweinelt
pushed a commit
that referenced
this pull request
Jul 31, 2024
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.] NixOS#11 zstd 1.5.6 Closure size: 66 -> 78 (15 paths added, 3 paths removed, delta +12, disk usage +18.5MiB). ```
mweinelt
pushed a commit
that referenced
this pull request
Aug 25, 2024
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
mweinelt
pushed a commit
that referenced
this pull request
Oct 13, 2024
[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
mweinelt
pushed a commit
that referenced
this pull request
Oct 13, 2024
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/20231031201752.1189213-1-mmaurer@google.com/ [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/D4LHHUNLG79Y.12PI0X6BEHRHW@mbosch.me/T/#u
mweinelt
pushed a commit
that referenced
this pull request
Dec 8, 2024
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 <thomas@tomking.io>
mweinelt
pushed a commit
that referenced
this pull request
Dec 16, 2024
Driving NixOS#237216 forward.
mweinelt
pushed a commit
that referenced
this pull request
Dec 16, 2024
mweinelt
pushed a commit
that referenced
this pull request
Jan 6, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.