<Dezgeg> I pushed more mass-rebuild stuff to staging, so another chance for someone to cancel & restart all jobs :)
<fpletz> ok, I hope this was the last one before we can merge staging into master :)
<Dezgeg> heh
<Dezgeg> we need a staging-staging
<gchristensen> or something like bors to auto-merge to staging
<gchristensen> and monitorhydra for completion, then auto-merge to master
kgz has quit [Ping timeout: 256 seconds]
kgz has joined #nixos-dev
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
contrapumpkin has joined #nixos-dev
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-dev
pie__ has quit [Ping timeout: 248 seconds]
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
pie__ has joined #nixos-dev
pie__ has quit [Ping timeout: 255 seconds]
JosW has joined #nixos-dev
pie__ has joined #nixos-dev
vdemeester_ has joined #nixos-dev
<vdemeester_> Is there a rule for "stalled" PRs ? (i.e. a PR that has no activity since a year, both in terms of commits and comments)
pie__ has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-dev
vdemeester_ has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 255 seconds]
vdemeester_ has joined #nixos-dev
adisbladis has quit [Ping timeout: 256 seconds]
ma271 has joined #nixos-dev
pie_ has joined #nixos-dev
vdemeester_ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
pie_ has quit [Read error: Connection reset by peer]
vcunat has joined #nixos-dev
vdemeest_ has joined #nixos-dev
vdemeest_ has joined #nixos-dev
vdemeest_ has quit [Changing host]
vdemeest_ is now known as vdemeester_
<globin> vdemeester_: not really, have you got a link?
<vdemeester_> @globin https://github.com/NixOS/nixpkgs/pull/12219 but overall some of the oldest PR O:)
<vdemeester_> (not all of them but some)
<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 ^_^
jtojnar has quit [Ping timeout: 260 seconds]
jtojnar has joined #nixos-dev
pie___ has joined #nixos-dev
pie__ has quit [Ping timeout: 240 seconds]