<gchristensen>
andi-: I deployed the Nix deadlock fix to Ike
<andi->
gchristensen: \o/
<andi->
now we just have to figure out why sometimes (on the same machines) chromium is able to compile for >10h and most of the time it just times out and blocks the channel bump..
<niksnut>
maybe we should just remove chromium from the channel? it's always slowing down the channel
<gchristensen>
I'm really confused by why it can build in a short time under some circumstances, but then gets hung up on Hydra
<andi->
I am tempted to say yes.. Then again there are a lot of users depending on it and those will end up complaining about the (incomplete; from their perspective) bump :)
<andi->
nixos-18.09-with-chromium as new channel? ;)
<gchristensen>
x.x
<gchristensen>
we could mark the epyc machine to only build big-parallel jobs and set the max-jobs to 1, and cores to 48
<andi->
I wouldn't say only big-parallel since there isn't that many jobs that would run there then.
<andi->
I guess the problem is that we have other machines that are (and should be able to) handling big-parallel jobs so it doesn't become a SPoF
<gchristensen>
we could set the max-jobs to 2 and cores to 24 and by luck of the draw it'll get hard jobs
<gchristensen>
hydra could learn about "strongly-preferred-features" :)
<andi->
another nice feature would be able to have "bigger" jobs, e.g one job that weights 2,4,8,... jobs but then we would also need different core allocation code and adjusted hydra?
<manveru>
should we maybe remove "NixOS is a relatively young Linux distribution" from the about page?
<gchristensen>
definitely
<manveru>
i guess compared to yggdrasil everything's young, but still :)
<Mic92>
Yeah, the `Status` section needs an status update.
<fpletz>
mic92: yeah, also with networkd the ip allocation for containers can be dynamic (though I haven't tried that yet)
<fpletz>
mic92: also, I should probably open a PR with my WIP networking changes soon, nearly finished but some feedback before the talk would probably be nice
<Mic92>
fpletz: feel free to include me and andi-
<fpletz>
which reminds me, the wireguard module should also be ported to support networkd
<fpletz>
thanks for adding wireguard support to networkd, mic92 :)
<gchristensen>
nice!
<Mic92>
fpletz: there is a open pull request for this but the tricky part is to support wireguard keys from files outside the nix store.
<Mic92>
Maybe we should create those files at runtime before networkd starts.
<fpletz>
and andi- added vrf support to networkd - been using it for a while now on my laptop so no regular program uses any uplink interface other than my vpn :)
<fpletz>
oh, really? nice, will look that up first
<andi->
fpletz: wow, I have to tell you the story how that was merged once I had a few beers... Its terrifying ;)
<andi->
Tldr: maybe not systemd ;)
<dhess>
So the Hydra is building haskellPackages on aarch64 now, but because of the single-job workaround that's needed for this, the GHC build is timing out: https://hydra.nixos.org/build/82539913/nixlog/1/tail
<fpletz>
the biggest fnord for me was that the manpage mentioned the wrong name for the table option :P
<dhess>
Any way to get the timeout bumped up for aarch64 builds so that we can get a working GHC?
<fpletz>
andi-: you will be at nixcon, right? %)
<gchristensen>
dhess: ghc: slow with 1 core, slow with 96 cores ... :)
<dhess>
heheheh
<andi->
fpletz: yes
<dhess>
samueldr: re: your comment earlier about tracking GHC builds in Hydra, I'm sorry I missed your question from earlier. I forgot that ZNC has me idling in this channel.
<dhess>
Anyway, as you can see, I'm already on it :)
<samueldr>
dhess: :D it was mostly in jest, but with hope that you could check
<dhess>
gchristensen: BTW GHC 8.4.3 finishes in "just" 9 hours on the community builder
<dhess>
so that's actually progress, as bad as it may otherwise seem
<gchristensen>
the community builder is much more powerful
<dhess>
samueldr: yeah it's in my interest to get this working, so I'll stay on it at least until it's building regularly
<gchristensen>
a far better machine
<dhess>
gchristensen: just curious, why did you add the old community builder to the Hydra pool and make the new one available to the community, rather than the other way 'round?
<dhess>
For the better parallelism on the old one?
<gchristensen>
two reasons: the community builder can do armv7l, and so we have 2x the same machine
<dhess>
ohhh right, the arm thing. Though I would argue that if/when armv7l is working on that thing, it would be good to have armv7l in the binary cache as well!
<gchristensen>
armv7l is working on it, but it won't be added to hydra
<dhess>
Anyway, not complaining, just curious
<dhess>
gchristensen: how come?
<gchristensen>
it isn't worth adding, I think, because we can't get a replacement armv7l machine if this one fails. so we could do a lot of work to make it build, have it fail the next day, and throw away all that work
<dhess>
well I'll just fight one battle at a time and stick to getting aarch64 GHC building on the official Hydra for now :)
<gchristensen>
I'd rather offer it up as a sort of "no promises" community builder
jtojnar has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
Ericson2314 has joined #nixos-dev
ckauhaus has quit [Quit: WeeChat 2.0]
orivej has joined #nixos-dev
<bgamari>
Is anyone familiar with the Nix sandboxing implementation?
<bgamari>
It seems to be breaking domain name resolution
<bgamari>
looking at the implementation it appears to fiddle with NSS
<bgamari>
in particular preloadNSS
<andi->
bgamari: you are trying to do network within the sandbox?
<bgamari>
andi-, well, it seems that curl is
<bgamari>
andi-, all invocations of nixos-rebuild as root seem to fail
<bgamari>
with domain name resolution issues
<bgamari>
on my box
<bgamari>
disabling sandboxing seems to help
<andi->
bgamari: what derivation did cause the failure?
<andi->
or do you have anything more (a paste somehwere)?