<globin>
vdemeester_: that's a hard one, I don't use networkmanager :/
<vdemeester_>
globin: my point was more that 2 years without activity, we could almost "auto-close" it
<vdemeester_>
(with a nice message saying that if there is still interest we could re-open or create a new one)
<globin>
vdemeester_: I'm planning to do something like that with grahamc soon, but working on something else right now regarding security advisories
<vdemeester_>
cool ;)
vdemeester_ has quit [Remote host closed the connection]
pie__ has quit [Ping timeout: 248 seconds]
vdemeest_ has joined #nixos-dev
vdemeest_ has quit [Changing host]
vdemeest_ has joined #nixos-dev
vdemeest_ has quit [Remote host closed the connection]
vdemeest_ has joined #nixos-dev
<vcunat>
Current staging jobset on Hydra is in some stuck state. I can't see any relevant stuck jobs, but nothing for the linux platforms gets built, so they don't even have stdenvs. It seems quite a waste.
vdemeest_ has quit [Ping timeout: 256 seconds]
<vcunat>
I hope restarting the queue runner would fix it.
<vcunat>
grahamc: you can't do that, right?
<vcunat>
staging-small jobs seem also waiting, so it probably is something about some of the early bootstrapping jobs getting stuck somewhere.
<niksnut>
I've restarted it
ma271 has quit [Quit: WeeChat 2.0]
<vcunat>
Great. It proceeded immediately to building the missing stuff.
<niksnut>
before the restart, /queue-runner-status showed no runnable x86_64-linux build steps
<niksnut>
clearly, there is something wrong with the runnable build step logic
vdemeest_ has joined #nixos-dev
vdemeest_ has quit [Client Quit]
pie__ has joined #nixos-dev
ma27 has joined #nixos-dev
goibhniu1 has joined #nixos-dev
pie__ has quit [Ping timeout: 256 seconds]
goibhniu has quit [Ping timeout: 256 seconds]
pie_ has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-dev
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
samueldr has quit [Read error: Connection reset by peer]
<dtz>
Oh, I hit that often. Restarting the queue-runner does the trick. Thought it was somehow specific to my setup :3.
<shlevy>
niksnut: Am I reading correctly that there's no way for the daemon to notice a disconnect in the middle of building some paths?
orivej has joined #nixos-dev
<shlevy>
I'm very confused as to how it's detecting it on Linux :D
<shlevy>
ah SIGUSR1 😱
samueldr has joined #nixos-dev
samueldr has quit [Changing host]
samueldr has joined #nixos-dev
<niksnut>
shlevy: you may want to add some debug prints to src/libutil/monitor-fd.hh
<niksnut>
to see it it's receiving POLLHUP
<shlevy>
Yeah, I found the relevant code
<shlevy>
I'm now wrestling with dtruss, which is so much worse than strace it's shocking
<gchristensen>
apparently dtrace is better than sliced bread, but I don't know. also, system integrity mode really screws up most of the debug tools
<shlevy>
Well, maybe dtrace is, but dtruss doesn't expose it well? I dunno
<niksnut>
my experience is that it's hard to get even a stack trace (even as root) because "security"
Sonarpulse has joined #nixos-dev
<copumpkin>
yeah, it's annoying
<copumpkin>
you can actually turn off SIP only for dtrace
<copumpkin>
and I usually do that
<copumpkin>
but you can't really expect most people to do that
<copumpkin>
so dtrace is pretty hobbled
<copumpkin>
in other news, dtrace is not CDDL'd anymore
<gchristensen>
what is it licensed?
<shlevy>
copumpkin: how do I do that?
<shlevy>
disable SIP for dtrace I mean
<copumpkin>
reboot into recovery mode like you would to disable SIP entirely
<copumpkin>
but instead you write `csrutil enable --without dtrace`
<copumpkin>
it'll warn you that it's an unsupported configuration
<copumpkin>
but it works fine
<LnL>
lol it does?
<copumpkin>
there are a few other --without options but those tend to be a bit more juicy for potential attack
<LnL>
didn't notice that
<LnL>
yeah, dtrace kext and something else
<copumpkin>
yeah, you can disable general debugger attaching restrictions and so on
<copumpkin>
but I don't usually find myself wanting to attach a debugger to system processes
tv has quit [Ping timeout: 260 seconds]
<shlevy>
Hmm I wonder if IT would be OK with that :D
<shlevy>
Does nix-daemon count as a system process in this case?
<gchristensen>
do it and find out? :)
<shlevy>
gchristensen: As someone who sets security guidelines for others, I try very hard to avoid that approach :D
<gchristensen>
that is a very different position
vcunat has quit [Ping timeout: 260 seconds]
tv has joined #nixos-dev
garbas has joined #nixos-dev
ma27 has quit [Ping timeout: 265 seconds]
<shlevy>
niksnut: ping
Sonarpulse has quit [Quit: Leaving]
Sonarpulse has joined #nixos-dev
Sonarpulse is now known as Ericson2314
Ericson2314 is now known as Sonarpulse
Sonarpulse has quit [Client Quit]
Sonarpulse has joined #nixos-dev
Sonarpulse has joined #nixos-dev
Sonarpulse has quit [Changing host]
Sonarpulse is now known as Ericson314
Ericson314 is now known as Ericson2314
Ericson2314 is now known as Group
Group is now known as group
group is now known as Sonarpulse
<jtojnar>
the anchors in the nixos manual are not stable?
<gchristensen>
some of them aren't
<shlevy>
We can add stable identifiers to any place we want them
<shlevy>
But there are autogenerated ones too I think
<gchristensen>
iirc there is a way to make them all stable by default, I can check in to that
<jtojnar>
that would be neat
pie_ has quit [Ping timeout: 276 seconds]
pie_ has joined #nixos-dev
Lisanna has joined #nixos-dev
JosW has quit [Quit: Konversation terminated!]
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
taktoa has quit [Remote host closed the connection]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
orivej has quit [Ping timeout: 260 seconds]
Sonarpulse has quit [Ping timeout: 248 seconds]
<dtz>
teehee can build musl-based nixUnstable on staging ^_^