raghavsood has quit [Remote host closed the connection]
alp has joined #nixos-dev
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
m1cr0man has quit [Ping timeout: 256 seconds]
FRidh has quit [Ping timeout: 272 seconds]
teto has joined #nixos-dev
<bk1603[m]>
Mic92: I tried using the package as is from nixpkgs, (I just changed the source for systemd in the default derivation,) and I still face the same issue. I might be wrong but I think the issue is with looking for the file in `/build` directory? From what I figure, meson fails to find the `generate-syscall-list.py` file altogether.
<bk1603[m]>
(Took me some time since I was trying to find the docs for patchShebags, later I just decided to go with the expression from nixpkgs.)
<Mic92>
bk1603[m]: I am pretty sure it's because the generate-syscall-list.py uses /usr/bin/env and you need patchShebangs. Because I patched this in systemd myself.
<bk1603[m]>
Oh, I see, sorry about that then, I thought changing the package would do the trick, but I have an old clone of nixpkgs it seems?
<bk1603[m]>
And thanks a lot for a link to the source! Clears out a lot of things. I'll give that a read before going further ahead with this :)
<Mic92>
bk1603[m]: what package do you want to change?
<bk1603[m]>
Oh, I did type a confusing message. What I wanted to say was, I thought changing the source for systemd in its `default.nix` in nixpkgs would help with any incorrect interpreter paths.
<bk1603[m]>
(Since I didn't know how I could use patchShebangs.)
<Mic92>
bk1603[m]: yeah, no. We don't have /usr/bin/env in our build sandbox to detect impurities.
<bk1603[m]>
Mic92: Umm, I got a bit confused reading your message. What you mean is, we don't need patchShebangs in the sandbox since we don't have `/usr/bin/env`? Or did I get this completely wrong :P
<bk1603[m]>
Not having `/usr/bin/env` would require the sandbox to use patchShebangs to have the correct paths right? Also, by impurities do you mean such interpreter paths that are from `/bin/*` or `/usr/bin/*`
<Mic92>
bk1603[m]: we need patchShebangs to change `!#/usr/bin/env python` to `!#/nix/store/*-python-*/bin/python` because of that.
<bk1603[m]>
Okay so shouldn't the `default.nix` for systemd in `<nixpkgs>` already have `patchShebangs`? If yes then why does adding an overlay change that? From what I understood using the overlay should've just changed the path?
<bk1603[m]>
Mic92: Also if I used my own fork of `<nixpkgs>` and changed the source of systemd in that fork, would I still face such an error?
<Mic92>
bk1603[m]: it does only do patchShebangs when installing packages. In systemd those script however are executed at build time.
<Mic92>
bk1603[m]: you also have this problem if you change the source.
domenkozar[m] has quit [Ping timeout: 260 seconds]
Irenes[m] has quit [Ping timeout: 260 seconds]
domenkozar[m] has joined #nixos-dev
Irenes[m] has joined #nixos-dev
kraem has joined #nixos-dev
bbigras has joined #nixos-dev
puzzlewolf has joined #nixos-dev
alp has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
__monty__ has quit [Quit: leaving]
<danderson>
Have there been significant changes in how compilation happens in unstable that weren't in 20.09? I'm trying to track down why binaries pulled from unstable segfault on my hardened 20.09 system.
<danderson>
So far both `bash` and `tailscaled` segfault on startup, which makes me suspect something changed in how binaries get compiled and that's angering the hardening options
<danderson>
culprit is the "scudo" hardened memory allocator. Disabling it lets unstable binaries run happily. I welcome theories as to why that would be :)