worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
<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.
<aanderse> garbas: > curl --head https://nixos.org/
<aanderse> curl: (7) Failed to connect to nixos.org port 443: Connection refused
<aanderse> thats all i have atm
<aanderse> i just ran it again and it worked
orivej has quit [Ping timeout: 240 seconds]
<samueldr> never had that for nixos.org, but I don't go there often
<samueldr> ipv6?
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
<garbas> ae
<aanderse> i visit nixos.org often when hacking on nixos to look at options
evanjs has joined #nixos-dev
bhipple has quit [Ping timeout: 265 seconds]
bhipple has joined #nixos-dev
bhipple has quit [Ping timeout: 260 seconds]
pie_[bnc] is now known as pie
pie is now known as pie_
dongcarl has joined #nixos-dev
bhipple has joined #nixos-dev
bhipple_ has joined #nixos-dev
bhipple has quit [Ping timeout: 240 seconds]
drakonis has quit [Quit: WeeChat 2.8]
orivej has joined #nixos-dev
<samueldr> o.O
<samueldr> >> 0.000 00] LhnuP veraion 3.18.120,lineageos (nixBld@loc^@lhksp) ('cb verCion 4.9.4 (GAC) ) #2 SMP PREEMP^T SuN Apr 12 03:29:50 UT
<samueldr> something isn't right
<clever> samueldr: byte order issues, bit endian vs little endian?
<samueldr> unknown, it's the linux pstore driver
<samueldr> oops, I thought I was in -chat
bhipple_ has quit [Ping timeout: 258 seconds]
noonien has quit [Quit: Connection closed for inactivity]
init_6 has quit []
cole-h has quit [Quit: Goodbye]
misuzu has quit [Quit: leaving]
misuzu has joined #nixos-dev
__monty__ has joined #nixos-dev
misuzu has quit [Quit: leaving]
misuzu has joined #nixos-dev
misuzu has quit [Client Quit]
misuzu has joined #nixos-dev
misuzu has quit [Quit: leaving]
misuzu has joined #nixos-dev
noonien has joined #nixos-dev
<hyperfekt> what's a good place to put a very small systemd unit that enhances an upstream one?
<jtojnar> hyperfekt enhances how? you could put it to your configuration, nixos module in nixpkgs or contribute it upstream
<hyperfekt> jtojnar: realizing it maybe shouldn't be a unit. i think NixOS should be mounting the pstore by default, and have systemd-pstore enabled
<gchristensen> __monty__: can we build newer ghc's on aarch64? I didn't think we could
<__monty__> gchristensen: I don't know. It's what I assumed because of Ben's comment.
<gchristensen> which comment?
<__monty__> gchristensen: And this one by domen: https://github.com/NixOS/nixpkgs/issues/80379#issuecomment-612208490
<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
<jtojnar> how would someone even come up with `nix-env -S 0`? https://github.com/NixOS/nixpkgs/pull/66859#discussion_r407192789
<gchristensen> jerome is making some videos about NixOS and started by reading the nix-env man page I thnk
<tilpner> jtojnar: 0 stands for any invalid value. foo does the same, as do any paths that are not profiles
<jtojnar> tilpner yeah, I understand that. but why would one pass it a value that is not a profile?
<jtojnar> if it is just a typo, should not calling the command again with a corrected value fix it?
<tilpner> jtojnar: Yes, it should. But that requires understanding of what happened, and what the expected state is
<gchristensen> domenkozar[m]: do you know of a way to mark jobs broken automatically?
<domenkozar[m]> there's a script that parses hydra and lists broken jobs
<domenkozar[m]> .. somewhere :)
<gchristensen> cc jtojnar infinisil ^
<jtojnar> maintainers/scripts/hydra-eval-failures.py ?
<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?
<Emantor> Manjaro disables CONFIG_EFI_VARS.
<Emantor> Yep
<samueldr> o.O
<samueldr> can efibootmgr and similar even work that way?
<samueldr> ah, EFIVARFS seems to be something else
<Emantor> EFI_VARS_PSTORE: Depends on: EFI [=y] && EFI_VARS [=m] && PSTORE [=m]
erictapen has joined #nixos-dev
justanotheruser has joined #nixos-dev
<Emantor> Fedora also leaves EFI_VARS disabled. (had to checkout their kernel repo)
<clever> Emantor: that reminds me...
<clever> Emantor: 2nd last entry on page 3
<Emantor> write during error handling causes drive to hang?
<Emantor> Or platform compat for secure erase?
<clever> Emantor: yeah, but from the OS's perspective, the sata command just never completes, and linux waits forever for it to complete
<clever> Emantor: causing the entire machine to just hang hard
<clever> pstore and dmesg might have helped then
<Emantor> Indeed.
<clever> the system also lacks serial, so i couldnt debug it via that either
<samueldr> since there is no clear intent to disable _pstore_, only efi vars, my opinion is to continue as we do
<samueldr> especially since we're getting vacuuming
<Emantor> Yep. I'd still be in favor of disabling writing to the efi vars by default. Just in case.
<hyperfekt> Emantor: what is your concern? the efivars filling up or accidental erase?
<Emantor> UEFI implementations being broken by writing to EFI vars. And thus also the vars filling up.
<{^_^}> firing: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
drakonis has joined #nixos-dev
<hyperfekt> welp now i only need to figure out why the systemd-pstore service does absolutely nothing when started
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
bhipple has quit [Ping timeout: 240 seconds]
bhipple has joined #nixos-dev
<manveru> oh great, now crystal shards depends on shards to build... crystal is getting ever more recursive :P
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ is now known as tilpner
bhipple has quit [Ping timeout: 240 seconds]
bhipple has joined #nixos-dev
<hyperfekt> maybe i should read a systemd manual at some point instead of trial and error
<{^_^}> #85073 (by hyperfekt, 8 hours ago, open): nixos/filesystems: mount and evacuate /sys/fs/pstore using systemd-pstore
<{^_^}> firing: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
orivej has quit [Ping timeout: 265 seconds]
bhipple has quit [Ping timeout: 240 seconds]
bhipple has joined #nixos-dev
orivej has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
bhipple has quit [Ping timeout: 240 seconds]
tilpner has quit [Remote host closed the connection]
tilpner_ has joined #nixos-dev
tilpner_ is now known as tilpner
bhipple has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
__monty__ has quit [Quit: leaving]
justanotheruser has joined #nixos-dev
<edef> what determines when we migrate pkgs.protobuf?
<edef> at various points it was simply the latest version
erictapen has quit [Ping timeout: 240 seconds]
erictapen has joined #nixos-dev
<{^_^}> resolved: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
erictapen has quit [Ping timeout: 256 seconds]