<copumpkin> you know you're in for a good time when your commit messages start with [Nasty sketch]: https://github.com/NixOS/nix/pull/1617
<gchristensen> lol...
<disasm> copumpkin: it's a hack, but I like it :)
<gchristensen> copumpkin: I saw something good about sending SIGSTOP to processes before SIGKILL
<copumpkin> oh yeah
<copumpkin> well I think he suggested spamming it with -1
<copumpkin> which would be nice if -1 didn't possibly crash the system
<copumpkin> if we could do that it would be good
<copumpkin> I see
<copumpkin> I still can't do the -1 thing
<copumpkin> well, I could, with some risk
<copumpkin> we found that -1 didn't kill the system as reliably if not with SIGKILL
<copumpkin> russian roulette with a 100-bullet revolver :D
<gchristensen> I mean
<gchristensen> yeah
<gchristensen> what I meant was doing the loop with sigstop then sigkill on individual processes
<copumpkin> yup
<copumpkin> well, if I could kill(-1, SIGSTOP) with that russian roulette
<disasm> I know off topic, beating a dead horse... but I can't believe apple isn't taking this more seriously...
<gchristensen> same :P
<copumpkin> then that would save me from having to loop :)
<gchristensen> erm
<gchristensen> yeah
<gchristensen> I'm not sure I'm being clear in my idea, but this: https://gist.github.com/grahamc/e26529b4f1142572319812ff3e768e9d
<copumpkin> yeah I get it now :)
<copumpkin> would I need to cont then?
<gchristensen> no, SIGKILL deschedules the process with no opportunity for the process to do anything, so it doesn't need to cont
<copumpkin> that's what I thought, but the systemd example uses cont :O
* gchristensen goes looking
<copumpkin> author doesn't seem to mention it after the beginning though
* copumpkin shrugs
<Dezgeg> that one is not necessarily using SIGKILL
<copumpkin> oh :)
<copumpkin> doh
<gchristensen> oohh
<gchristensen> they're broadcasting any signal, that is why they need a cont
<copumpkin> yup
<copumpkin> all is clear now!
<copumpkin> I'll amend PR
<copumpkin> gchristensen: pushed :)
<gchristensen> cool
<copumpkin> thanks, TIL :D
<Dezgeg> theoretically the query + kill approach is vulnerable to killing random stuff if pid reuse happens between the query and kill, but shouldn't happen in practice (famous last words)
<copumpkin> :D
<gchristensen> hmm
<gchristensen> could we look up the pid owner? :)
<gchristensen> after the sigstop
<copumpkin> it'll always have a chance to change owner between check and signal won't it?
<gchristensen> not after sigstop
<copumpkin> hmm I guess if it was dying it'll stop dying until we're done
<copumpkin> wait, if it died between the list and our sigstop
<copumpkin> oh I see, never mind
<copumpkin> anyway, my train internet is completely unresponsive now
<gchristensen> it rapidly becomes more complicated, but ... :P
<copumpkin> so this might have to wait until later
<gchristensen> good luck copumpkin
<copumpkin> can you leave me a comment on the PR
<copumpkin> so I don't forget
<gchristensen> yep
<copumpkin> thanks
<Dezgeg> well that just ends up sending SIGSTOP to the random process in case of unlucky reuse
<copumpkin> yeah, which we could then SIGCONT as an apology
<gchristensen> what is a little extra SIGCONT between friendss
<Dezgeg> not nice if it was already SIGSTOP'ped ;)
<copumpkin> dammit :P
<gchristensen> Dezgeg!
<copumpkin> stop thinking through all the corner cases
<gchristensen> stop poking holes in our plans
<copumpkin> still better than an OS crash :)
<Dezgeg> on Linux you can hold open a /proc/<pid> file and it doesn't get reused, IIRC
<gchristensen> we can't atomically do that :(
<copumpkin> also, no /proc
<Dezgeg> you can re-check from /proc that the uid didn't change ;)
<gchristensen> that is why I want to sigstop it
<gchristensen> so we can atomically check-and-kill
<Dezgeg> that would be atomic on Linux without SIGSTOP
<copumpkin> I wonder if
<copumpkin> we could make our while loop only SIGSTOP
<copumpkin> and then once everything is known to be stopped
<copumpkin> only then do we kill whatever is there
<gchristensen> oh man
<gchristensen> rax is discontinuing their OSS hosting plan
<copumpkin> so we're losing our hydra boxen?
<gchristensen> I can't say for sure, but probably?
<gchristensen> except they will just send us a bill, not shut us down
<copumpkin> that seems unfriendly
<copumpkin> unless they're very loud about it
<gchristensen> I'm hearing this second hand btw, w.r.t. ReadTheDocs having to move
<gchristensen> copumpkin: have we tried asking the apple developer people how to handle this?
<copumpkin> I've never even spoken to them, nope
<gchristensen> coh
<gchristensen> hmm maybe worth a try, but I don't feel confident
<copumpkin> their radar interface is pretty unfriendly
<copumpkin> not sure how else to contact them
<copumpkin> maybe darwin-dev?
<gchristensen> they recommended Developer Technical Support, devevloper.apple.com/contact/
<gchristensen> ... but the right URL.
<copumpkin> oh well, I emailed darwin dev
<copumpkin> I don't think there are any people unless you're paying for a support plan
<copumpkin> on that url
<gchristensen> aye
WilliButz has quit [(Ping timeout: 258 seconds)]
mbrgm has quit [(Ping timeout: 252 seconds)]
WilliButz has joined joined #nixos-dev
mbrgm has joined joined #nixos-dev
JosW has joined joined #nixos-dev
JosW has quit [(Quit: Konversation terminated!)]
JosW has joined joined #nixos-dev
MichaelRaskin has quit [(Quit: MichaelRaskin)]
jtojnar has quit [(Read error: Connection reset by peer)]
peti has quit [(Ping timeout: 248 seconds)]
peti has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
jtojnar has joined joined #nixos-dev
pbogdan_ has joined joined #nixos-dev
jtojnar has quit [(Read error: Connection reset by peer)]
pbogdan has quit [(Ping timeout: 248 seconds)]
pbogdan_ has quit [(Ping timeout: 260 seconds)]
pbogdan has joined joined #nixos-dev
__Sander__ has joined joined #nixos-dev
<__Sander__> hurraay!!
* __Sander__ is now finally past an important milestone in node2nix
<__Sander__> reorganizing the internal data structures :P
<niksnut> o/
<gchristensen> nice :D
<gchristensen> shlevy: so what are ADT's? :)
<gchristensen> shlevy: also, I'm sorry about Coulton :(
FRidh has joined joined #nixos-dev
jtojnar has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 248 seconds)]
FRidh has joined joined #nixos-dev
FRidh has quit [(Read error: Connection reset by peer)]
FRidh has joined joined #nixos-dev
<globin> copumpkin, Mic92, gchristensen: regarding pr rate, commit rate etc. I'm trying to build tools and graph the stats for our nixcon talk, not sure how far I'll get but you can at least expect something that we can build up on from there on :)
<gchristensen> nice
FRidh has quit [(Quit: Konversation terminated!)]
FRidh has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 240 seconds)]
jushur has quit [(Ping timeout: 246 seconds)]
jushur has joined joined #nixos-dev
jtojnar has quit [(Quit: jtojnar)]
jtojnar has joined joined #nixos-dev
FRidh has joined joined #nixos-dev
<copumpkin> o/
disasm has quit [(Quit: WeeChat 1.9.1)]
jtojnar_ has joined joined #nixos-dev
jtojnar has quit [(Read error: Connection reset by peer)]
cbarrett has joined joined #nixos-dev
disasm has joined joined #nixos-dev
jtojnar_ has quit [(Ping timeout: 240 seconds)]
jushur has quit [(Quit: The Borg joined forces with Skynet, Resistance is futile! Uploading has begun!)]
<niksnut> I'm inclined to disable hardening in Nixpkgs. Issue https://github.com/NixOS/nixpkgs/issues/18995 was marked as a blocker two releases ago, but still hasn't been fixed :-(
<gchristensen> ykes
jtojnar_ has joined joined #nixos-dev
kragniz has quit [(Quit: WeeChat 1.7)]
kragniz has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 248 seconds)]
<disasm> niksnut: is that a better solution than moving the flags before the user specified ones instead of after?
<dtzWill> long issue--is there a reason we can't disable hardening in wrappers outside of nixpkgs/stdenv?
<dtzWill> this bites me too, I find myself often doing a "export hardeningDisable=all" in my shell "just in case" lol
__Sander__ has quit [(Quit: Konversation terminated!)]
<copumpkin> globin, fpletz : in case you missed what niksnut said above, see above :)
jtojnar_ has quit [(Remote host closed the connection)]
jtojnar_ has joined joined #nixos-dev
<copumpkin> but I've always largely assumed that many of the nix build tools don't work properly outside of Nix
<copumpkin> like I'd prefer it if they did
<copumpkin> but it's been unreliable so far, even outside of the C compiler
<gchristensen> like what build tools?
<copumpkin> e.g., I can install pip but it's not always going to play nicely with my system python packages
<copumpkin> similar with ohter
<copumpkin> so my default is generally to avoid nix tools outside of nix builds
<gchristensen> huh
<copumpkin> a lot of stuff does work, I'm just saying it doesn't always seem like a primary concern :)
<copumpkin> which I'd like it to be, but we also have a limited workforce and I'd rather things work smoothly inside nix builds
<copumpkin> given limited resources :)
<copumpkin> so to cut a long story short, my vote is against reverting hardening if the only reason is to use tools outside of nix
<copumpkin> :P
jtojnar_ has quit [(Remote host closed the connection)]
jtojnar_ has joined joined #nixos-dev
jtojnar_ is now known as jtojnar
jtojnar has quit [(Remote host closed the connection)]
<niksnut> whether it's in or out of Nix doesn't matter
<niksnut> our build farm explicitly has an "unoptimized" build job for debugging purposes
<niksnut> the -O0 in that job shouldn't be silently ignored
<copumpkin> that's fair
<copumpkin> "warning: you requested hardening X but that's incompatile with your explicit -O0. If you want to shut up this warning either stop passing in -O0 or hardeningDisable = X"
<niksnut> right
<niksnut> except it shouldn't be a warning, it should be a fatal error
<copumpkin> yup
jtojnar has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 264 seconds)]
jtojnar_ has joined joined #nixos-dev
jtojnar has quit [(Ping timeout: 240 seconds)]
jtojnar_ is now known as jtojnar
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar_ has joined joined #nixos-dev
jtojnar has quit [(Ping timeout: 240 seconds)]
jtojnar_ has quit [(Remote host closed the connection)]
jtojnar_ has joined joined #nixos-dev
MichaelRaskin has joined joined #nixos-dev
phreedom has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
<shlevy> There, now no one can complain about lack of types in nix https://github.com/shlevy/nix-adt
<gchristensen> oh jesus
<shlevy> :P
<gchristensen> shlevy: you're going to nixcon right?
<shlevy> gchristensen: Nope :'( Have family coming in that weekend for my son's birthday
<gchristensen> bummer!
<shlevy> Yeah :(
<clever> gchristensen: did you see my recent module for a rescue setup?
<gchristensen> yeah!
<gchristensen> very cool :D
<clever> i was able to sucessfully open my luks rootfs from that shell, but forgot to include zfs in it
<clever> easily fixed, but also specific to my setup, so each user would need to customize it right
<clever> gchristensen: and if "nixos-rebuild" is able to write to /boot on those packet servers, your one step closer to being able to recover them
JosW has quit [(Quit: Konversation terminated!)]
zraexy has quit [(Quit: Leaving.)]
zraexy has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 240 seconds)]
mbrgm has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
mbrgm has joined joined #nixos-dev