-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Compile glibc without -fstack-protector. #1
Conversation
At least until NixOS full supports -fstack-protector it's better to turn it off at the moment, as previous successful builds didn't include it either.
What would be required for NixOS to fully support -fstack-protector? |
https://wiki.ubuntu.com/GccSsp - but that was dated 2006, and for example the kernel now fully supports it. |
No one that I know of. If you think you could put something together go for it. |
I assume that since this is a Glibc change, it should go into the stdenv branch? |
BTW, what is actually gained by disabling stack protection in Glibc? Sure, we don't turn it on in other packages, but does that affect stack protection in Glibc functions? |
Yeah, the stdenv concern is why I suggested we look into using stack protection more completely. No idea whether stack protection needs to be in all packages to be useful in any. |
Well, the original reason for disabling SSP was because of these build failures: |
Is there anything that's harmed by keeping this as it is for now? Since this will require a stdenv rebuild we'd have to put this into a stdenv-updates branch at first anyway, but if it's not a big deal maybe this can wait until a more compelling reason for stdenv-updates arises? Anyway, we can't merge this into master so I'm closing. If it's important to have this fixed soon, please open a PR against the stdenv-updates branch. |
@edolstra Ok, having looked into this we have a strange problem. Building glibc as part of stdenv works fine (i.e. nix-build -A glibc), but building the same glibc with the final stdenv instead of the bootstrap fails (i.e. nix-build -A glibc213). So there's definitely an issue. Should I open a stdenv-updates branch? |
Glibc 2.14 also produces a build failure in Hydra, so we need to apply the same fix here, too.
It's already open, see https://github.com/NixOS/nixpkgs/commits/stdenv-updates |
Add xserver integration of i3 WM.
The bsddb module is apparently not compatible with db5 (or db48), so switch back to db44. Fixes the following build error: $ nix-build -A python26.modules these derivations will be built: /nix/store/5zcqmpa4iby0aa342psjph0byiyikm6h-python-bsddb-2.6.8.drv building path(s) `/nix/store/qpsjyx7nmxhm9zq40674wr67dx8w6ycl-python-bsddb-2.6.8' building /nix/store/qpsjyx7nmxhm9zq40674wr67dx8w6ycl-python-bsddb-2.6.8 unpacking sources unpacking source archive /nix/store/2qwc1kd8allnaljm1z360lv9jsf8cfqy-Python-2.6.8.tar.bz2 source root is Python-2.6.8 patching sources applying patch /nix/store/cfk04ans56xql9l6waqhqzzd60g9rzxi-search-path.patch patching file setup.py Hunk #1 succeeded at 424 (offset 145 lines). applying patch /nix/store/dxscwf37hgq0xafs54h0c8xx47vg6d5g-nix-store-mtime.patch patching file Python/import.c Hunk #1 succeeded at 747 (offset -4 lines). configuring building running build_ext INFO: Can't locate Tcl/Tk libs and/or headers Traceback (most recent call last): File "./setup.py", line 2037, in <module> main() File "./setup.py", line 2032, in main 'Lib/smtpd.py'] File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/core.py", line 152, in setup dist.run_commands() File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/dist.py", line 975, in run_commands self.run_command(cmd) File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/command/build_ext.py", line 340, in run self.build_extensions() File "./setup.py", line 249, in build_extensions longest = max([len(e.name) for e in self.extensions]) ValueError: max() arg is an empty sequence builder for `/nix/store/5zcqmpa4iby0aa342psjph0byiyikm6h-python-bsddb-2.6.8.drv' failed with exit code 1 error: build of `/nix/store/5zcqmpa4iby0aa342psjph0byiyikm6h-python-bsddb-2.6.8.drv' failed
fix some packages that won't build in the darwin-clang-stdenv
The sed expression actually caused an error on hydra: ``` sed: -e expression NixOS#1, char 18: Invalid collation character ``` It seems to build fine without it however.
The sed expression actually caused an error on hydra: ``` sed: -e expression NixOS#1, char 18: Invalid collation character ``` It seems to build fine without it however.
This hopefully fixes intermittent test failures like http://hydra.nixos.org/build/29962437 router# [ 240.128835] INFO: task mke2fs:99 blocked for more than 120 seconds. router# [ 240.130135] Not tainted 3.18.25 NixOS#1-NixOS router# [ 240.131110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. assuming that these are caused by high load on the host. (cherry picked from commit 6d02d7e)
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] #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]>
At least until NixOS fully supports -fstack-protector it's better to turn it off
at the moment, as previous successful builds didn't include it either.