phreedom has quit [(Remote host closed the connection)]
peti has joined joined #nixos-dev
phreedom has joined joined #nixos-dev
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
ma27 has quit [(Ping timeout: 255 seconds)]
ma27 has joined joined #nixos-dev
<pstn>
I've been thinking about the nixos kexec infrastructure. Before checking the repo, I thought it would be nice to have a kexec load as an optional part of the activation script, so you'd always have the kernel of the currently running profile loaded.
<LnL>
kexec is disruptive
<pstn>
There currently is an implementation with a systemd service, which could also work if you'd make sure the service restarts (and thus reloads the kernel on profile activation)
<pstn>
LnL: What do you mean by disruptive?
<pstn>
My reasoning was to make it easier, for example to do ```nixos-rebuild test && systemctl kexec```, so you wouldn't touch your grub and if something bad happens, a reboot would bring you back into your old state.
<andi->
pstn: he probably referes to all userspace applications dieing ;-)
<pstn>
Ah, got it. I never meant for the machine to automatically reboot. kexec is usually executed in two steps: Load and kexec, where Load just loads the kernel and the image into memory, the actual kexec call is executed later.
<LnL>
yeah, and other things like graphics might not unload correctly
<gchristensen>
pstn: my experience with kexec is the kernel doesn't retain any memory from the old kernel, in other words: it is effectively a fresh boot as far as the user is concerned
<gchristensen>
do you have a different experience?
<gchristensen>
are you thinking ksplice?
<pstn>
gchristensen: No, that's what it does. Like I said: i don't want to reboot on every activation, just be able to boot into a system build with test without adding anything to the bootloader.
<pstn>
So that you can do a switch and reboot properly when you made sure that everything is alright.
goibhniu has quit [(Ping timeout: 250 seconds)]
<gchristensen>
well I don't think you could get back to the old one, does it still make sense?
<pstn>
Sure you could: Just reboot. It's meant for example for remote servers where you don't have easy access to the grub shell.
<gchristensen>
oh I see!
JosW has quit [(Quit: Konversation terminated!)]
<LnL>
is there a way to safely stop processes and unmount filesystems first
<LnL>
from what I know kexec is pretty unsafe in that regard
<gchristensen>
I don't know
<gchristensen>
it is definitely unsafe
<gchristensen>
I only use it when I'm going to erase the disks anyway
<LnL>
for a reinstall that's fine since you're going to repartition anyway
<vcunat>
my script is returning 377, but that's not too different anyway
<vcunat>
perhaps it would really be better to have a higher treshold for Linux rebuilds
<pstn>
Uh, one more thing: I know hydra time is a limited resource, but could we get one wine64 binary? Many windows apps need it nowadays.
<LnL>
vcunat: about the darwin queue, did we change the priorities of nixpkgs-17.09-darwin?
<vcunat>
I _personally_ think one wine64/wow variant would be OK to build.
<vcunat>
LnL: I don't recall any change.
<vcunat>
It should have higher priority than staging, I expect.
<LnL>
we talked about swapping that a while back
<vcunat>
:-) my memory is bad
<vcunat>
LnL: if there was a consensus about that among nix+darwin users, it's easy to reduce the shares for nixpkgs-17.09-darwin
<gchristensen>
pstn: we build the entire haskell ecosystem on hydra, if we're not building wine64 it probably isn't because capacity is limited...
<LnL>
I think it's not a bad idea since that staging impacts a lot more people
<vcunat>
(I don't use darwin; I just watch for big regressions before merging staging)
<vcunat>
LnL: I now see the logs about this from Dec 06, but there wasn't anyone else participating.
<vcunat>
It would probably be good to get an ACK from some other(s).
<LnL>
agreed
<gchristensen>
I don't think there is much rhyme or reason to the priorities, and the way it is designed all the priorities become increasingly out of balance as things go :P
<pstn>
gchristensen: I think it isn't built because it's not a package definition but accessed by adding a overwrite to the normal wine package, but AFAIK that just needs some one time manual setting, right?
<gchristensen>
right, needs adding to all-packages.nix
<vcunat>
Discussions I've seen were only against 64-bit-capable wine as the default wine, as it's really huge and many (most?) use cases are fine with 32-bit.
<gchristensen>
huge in what dimension, and we could have it not be default, but available
<vcunat>
huge closure size
<gchristensen>
ouch
<gchristensen>
still, though, huge enough to not build it?
<vcunat>
I do believe we *can* afford to build one 64-bit-capable variant on Hydra.
<vcunat>
(for linux)
<gchristensen>
cool, let's do that
<vcunat>
I just don't know which variant to choose :-)
<pstn>
I suggest full because then everybody is covered.
<gchristensen>
yeah, but if we can get stats off the builders directly we can setup better monitoring and compare different hardware classes for example