<aanderse>
since moving to netlify the nixos.org webpage appears to be down for me quite often
<aanderse>
not for long periods of time
<aanderse>
but often
<cole-h>
Maybe you visit it right when it's being deployed from a new change? :P I personally haven't noticed this (but I also don't visit nixos.org all that often, either...)
<samueldr>
cc garbas ^
<garbas>
cole-h: aanderse: netlify states deployment are atomic, now are they? :)
<cole-h>
¯\_(ツ)_/¯
init_6 has joined #nixos-dev
<cole-h>
Unfamiliar with this kind of thing. Was just something that came to mind
<garbas>
aanderse: did you try to debug why this is happening? i'm trying to see if its your setup or just generally not accesible.
<gchristensen>
"With the compiler not even building we're quite safe from such bugs ;-)"
<__monty__>
gchristensen: That was just a snarky comment though. People might end up building GHC themselves no? Because it's not cached? It'd suck if people went and wasted hours compiling a buggy compiler.
<gchristensen>
I don't read that as a snarky comment
<gchristensen>
we can't build it
<gchristensen>
maybe we can build it now, is that what domenkozar[m] was saying?
<__monty__>
Can't build it for the binary cache. Is how I read that.
<gchristensen>
our build infrastructure can't build and cache it, correct
<__monty__>
The 2GiB limit doesn't apply for people running those platforms and simply trying to install GHC.
<gchristensen>
sure
<__monty__>
So, if nothing else, I think 8.6.5 and anything under 8.8.2 should be marked broken for aarch64.
<gchristensen>
8.8.2 builds on aarch64?
<__monty__>
Debian 9 has packages for both 8.8.3 and 8.10.1 so I assume so?
<__monty__>
I don't know whether it'd build within the 2 GiB limit though.
<domenkozar[m]>
I think best would be to bump haskell to 8.8, but we missed that boat :)
<gchristensen>
I don't care about what debian does, I care about what we can put in to the cache
<gchristensen>
domenkozar[m]: I think we should, too. I don't think we should alienate the haskellusers like that for 6m
<domenkozar[m]>
I can prepare that today
<__monty__>
But even if it can't be cached I think marking as broken the bugged versions is an important step. Unless broken explicitly shouldn't be used for bugs in software only for buildability.
<__monty__>
I didn't mean to make a fuss about this btw. I have no idea whether there's even a significant aarch64 GHC userbase.
<gchristensen>
domenkozar[m]: I guess I'm wondering what the risk is. does x86/i686 get 8.8 by default, and only aarch64 doesn't?
<__monty__>
No, I think all of nixpkgs currently defaults to 8.6.5
<domenkozar[m]>
the risk is that it's last minute, but it's been tested on master
<gchristensen>
what if we marked packages broken once a week
<jtojnar>
sounds good to me
<jtojnar>
if we figure out how to do it automatically
<gchristensen>
yeah
* srk
can take a look at updating part, studied update-nix-fetchgit for a while..
<gchristensen>
jerome making a video about NixOS without actually understanding it :|
<MichaelRaskin>
Is the video going to disclose that latter fact?
<gchristensen>
I doubt it
ixxie has joined #nixos-dev
CRTified has joined #nixos-dev
abathur has joined #nixos-dev
bhipple has joined #nixos-dev
ixxie has quit [Quit: Lost terminal]
ixxie has joined #nixos-dev
bhipple has quit [Ping timeout: 264 seconds]
bhipple has joined #nixos-dev
<hyperfekt>
does anyone know how i can make part of the activation script execute after a kernel module has loaded? trying to mount /sys/fs/pstore when the pstore module is activated
abathur has quit [Ping timeout: 256 seconds]
abathur has joined #nixos-dev
<srk>
that sounds more like job for udev but even there I'm not sure if you can trigger on module loads
<hyperfekt>
hmm i didn't even think about using the device that triggers the module but there has to be one
<srk>
/dev/pstore?
<srk>
that needs to be mounted iirc
<gchristensen>
anyone know a perl?
<eyJhb>
a perl?
<eyJhb>
In DK that means something else..
<hyperfekt>
srk: hm using the device won't work, i'd have to duplicate all the in-kernel logic
<srk>
hyperfekt: what are you trying to do btw? :)
<hyperfekt>
making systemd-pstore default on nixos
* srk
looks what it does
<hyperfekt>
now i'm trying to figure out when to mount it
<srk>
/sys/fs/pstore
<srk>
(from man systemd-pstore)
<hyperfekt>
when, not where ^^
<srk>
sorry
<hyperfekt>
maybe just using fstab will work
<hyperfekt>
since i tried all the nonobvius stuff already
<samueldr>
not sure it is a good idea to make it default, as it may fill uefi variable space or do other unfun things of the sort :/
<Emantor>
Ack with samueldr, pstore for UEFI depends on your vendor EFI implementation.
<hyperfekt>
samueldr: UEFI variable store is already filled by the kernel with the current config. systemd-pstore unfills it
<hyperfekt>
at least that is my understanding
cole-h has joined #nixos-dev
<Emantor>
hyperfekt: you are right, we should set CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE.
<samueldr>
hmm
<samueldr>
then carry on, and don't let me stop you from making it more trivial to enable
<hyperfekt>
well do we have to? if we got systemd-pstore we should be okay since it vacuums the variables
<samueldr>
since it is already enabled, it should be fine, hopefully, for most
<Emantor>
Using systemd-pstore will actually write to the variables and possibly exhaust the UEFI NVRAM. Currently only Oops info is written there.
justanotheruser has quit [Ping timeout: 246 seconds]
<samueldr>
>> systemd-pstore.service is a system service that archives the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events.
<globin>
did someone cancel structured-attrs jobs and if so what was the reason?
cole-h has quit [Client Quit]
cole-h has joined #nixos-dev
<Emantor>
Ah, I see. So we would only ever archive the Oops information, sounds good to me.
<samueldr>
yes, I assumed from the name that it would write into
<samueldr>
hyperfekt: +1
<samueldr>
hyperfekt++ in fact
<{^_^}>
hyperfekt's karma got increased to 3
<Emantor>
IMO CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE should nervertheless be enabled and we should add a NixOS option to enable writing to EFI Pstore.
<Emantor>
On the other hand it doesn't affect your system to much unless it crashes constantly.
<samueldr>
what are other distros doing with that option?
<Emantor>
let me check
<globin>
gchristensen: ah is the queue-runner being restarted on purpose this often, it feels like the restarts are slowing down hydra massively.. are you sure it isn't crashing?
<samueldr>
we may want a shortcut for "This setting can be overridden using the efivars module's pstore_disable" though
<Emantor>
Debian is the same as NixOS, Arch Linux disables CONFIG_EFI_VARS.
<samueldr>
CONFIG_EFI_VARS entirely? or just pstore?