<dtz>
summary: removing curl handles from multi while multiplex/pipelining is enabled ..... is known to be badness
<dtz>
not sure how we can best work around that :(
<dtz>
FWIW at least in my setup, problem started occurring with recent bump to curl 7.60, things seem to work w/7.59 and such. Dunno if we're "getting away" with our usage or if there's something else going on, but seemed worth mentioning....
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
jtojnar_ has joined #nixos-dev
ckauhaus has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
goibhniu1 is now known as goibhniu
Lisanna has joined #nixos-dev
aminechikhaoui has joined #nixos-dev
bgamari has quit [Ping timeout: 276 seconds]
bgamari has joined #nixos-dev
<srhb>
Did something change wrt sandboxing on Hydra recently? perlPackages.DBDPg suddenly fails tests with sandboxing on (which seems reasonable) but didn't before, as far as I can see...
<FRidh>
orivej: that we can do, yes, if you're confident it won't break more :)
peti has quit [Quit: WeeChat 1.8]
<orivej>
I am :)
<FRidh>
ok
peti has joined #nixos-dev
* LnL
mumbles something about rebuilds on master
<gchristensen>
LnL: Darwin brokeN?
<gchristensen>
I have a small amount of hardware here that I do some compatibility testing7 on -- periodically taking a release / master and doing a deploy to it.
<gchristensen>
I wonder if we should explore formalizing something like this as part of the release process?
<LnL>
I fixed a bunch of stuff but that's not my main concern
<LnL>
when staging was merged ghc/rust where broken on linux
<LnL>
so firefox and the manual didn't build and there was still a very large queue
<gchristensen>
oh I see
<LnL>
I think we should try the stabilisation workflow proposed in rfcs#26
<andi->
gchristensen: i would appreciate formalizing it. That probably takes both formal criteria (what to test, when, how critical something is,..) and tooling "formalization" as in "how" to test
<gchristensen>
definitely
<gchristensen>
dang, the ghc builds were aborted 1hr in
ixxie has joined #nixos-dev
Sonarpulse has joined #nixos-dev
<gchristensen>
I'm seeing several hydra builds fail with "Aborted: unexpected end-of-file", what does this mean?
aminechikhaoui has quit [Quit: leaving]
aminechikhaoui has joined #nixos-dev
<LnL>
means the nix-store --serve --write process died
<LnL>
or the ssh connection died at a weird point
aminechikhaoui has quit [Read error: Connection reset by peer]
MichaelRaskin has joined #nixos-dev
aminechikhaoui has joined #nixos-dev
aminechikhaoui has quit [Read error: Connection reset by peer]
aminechikhaoui has joined #nixos-dev
aminechikhaoui has quit [Read error: Connection reset by peer]
aminechikhaoui has joined #nixos-dev
aminechikhaoui has quit [Read error: Connection reset by peer]
Lisanna has joined #nixos-dev
aminechikhaoui has joined #nixos-dev
aminechikhaoui has quit [Read error: Connection reset by peer]
aminechikhaoui has joined #nixos-dev
aminechikhaoui has quit [Read error: Connection reset by peer]
aminechikhaoui has joined #nixos-dev
<aristid>
i see hydra has a rustc build
<aristid>
but i'm not sure if it's fixed
<aristid>
MichaelRaskin: i suspect the problem was that i am building with 16 threads
<aristid>
MichaelRaskin: because i consistently got errors
Lisanna has quit [Quit: Lisanna]
<aristid>
how can i locally rebuild a path that i already have in my store?
<MichaelRaskin>
I think it is --check
<MichaelRaskin>
nix-build '<nixpkgs>' -A rustc --check
<LnL>
yeah, check forces a rebuild and compares the resulting paths
<MichaelRaskin>
Technically, it verifies if the output is bit-for-bit stable, but in the process you will also observe if the build is even succesful
<MichaelRaskin>
I only did 8 threads…
<LnL>
yeah, so for rust that will complain but you can just ignore that
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<thoughtpolice>
gchristensen: Normally a couple hours, at minimum, for a release build. If the machines are under load and it doesn't have a lot of cores -- probably longer. (GHC's build doesn't scale perfectly either, anyway)
<aristid>
MichaelRaskin: thanks, using --check now
<aristid>
wait, can it be that --check does not use remote builders?
<gchristensen>
thanks, thoughtpolice ! :D
<MichaelRaskin>
I wonder how many days after The Staging Merge my multi-staged rebuild will converge…
Sonarpulse has quit [Ping timeout: 256 seconds]
<MichaelRaskin>
(Of course, since then even Firefox has been bumped)
<MichaelRaskin>
(By a reverse dependency, I mean)
capisce has joined #nixos-dev
aszlig_ has joined #nixos-dev
page_ has joined #nixos-dev
Willi_Butz has joined #nixos-dev
<aristid>
"Your branch is behind 'origin/master' by 26672 commits, and can be fast-forwarded."
<aristid>
:D
MichaelRaskin has quit [*.net *.split]
capisce_ has quit [*.net *.split]
jcrben has quit [*.net *.split]
page has quit [*.net *.split]
LnL has quit [*.net *.split]
aszlig has quit [*.net *.split]
WilliButz has quit [*.net *.split]
tv has quit [*.net *.split]
jcrben has joined #nixos-dev
ixxie_ has joined #nixos-dev
Sonarpulse has joined #nixos-dev
<aristid>
ALRIGHTY, now --checking rustc directly on my 16 core server
ixxie has quit [Ping timeout: 240 seconds]
tv has joined #nixos-dev
ixxie_ has quit [Ping timeout: 240 seconds]
LnL has joined #nixos-dev
<gchristensen>
I'm going to be very disappointed if these ghc builds bail out or fail
<LnL>
xd
<aristid>
ok, so nix-build pkgs.rustc --check FAILS
<aristid>
in the usual way
<aristid>
segmentation fault
<aristid>
in llvm
<gchristensen>
"receiving outputs" oooo
Lisanna has joined #nixos-dev
MichaelRaskin has joined #nixos-dev
<MichaelRaskin>
Hm. Are libreoffice-still and libreoffice-fresh the same thing now? How was this even achieved?
<MichaelRaskin>
How exactly does Git merge go _that_ wrong.
FRidh has quit [Quit: Konversation terminated!]
<aristid>
MichaelRaskin: rustc --check building failed on my server (with segfault), i'm trying on my laptop right now (with 4 threads on 2 cores), to see if that "fixes" it
page_ is now known as page
<copumpkin>
is it bad to modify a .narinfo in place? it isn't hashed anywhere is it?
<copumpkin>
its name is the hash of the derivation in the nar
<LnL>
nix caches that pretty aggressively
<MichaelRaskin>
It is definitely cached by Nix client
<niksnut>
copumpkin: no it's not hashed
ckauhaus has quit [Quit: Leaving.]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
<clever>
copumpkin: what do you want to modify in the file?
* aristid
mumbles something about the -O2 that nixpkgs gcc force-adds by default
<aristid>
is there a way to set a maximum parallelism for a package, other than 1 of course?
obadz- has joined #nixos-dev
obadz has quit [Ping timeout: 248 seconds]
obadz- is now known as obadz
<MichaelRaskin>
Does that imply what I think it implies?
<aristid>
MichaelRaskin: well, it's still building. but it seems to get much farther on my laptop than the server.
<aristid>
(rustc)
<MichaelRaskin>
8 threads OK, 16 threads no OK…
<MichaelRaskin>
So, a fully threaded build on a 96-core ARM server should just always fail horribly? I wonder if it would fail faster there
<LnL>
last time I looked at the rustc build it wasn't very parallel
<MichaelRaskin>
So you'd bet it is more about CPU features?
<LnL>
it got better with 1.25 IIRC but that update also made the build way longer :/
<LnL>
my last build was 2h52
<MichaelRaskin>
We need rustcache
<LnL>
killing the vendored llvm build or atleast moving it to a separate drv would probably help a lot