<vcunat>
the current state of Darwin build slaves on Hydra is poor
<vcunat>
it runs like seven jobs at once, only
<vcunat>
This way the Darwin queue is growing persistently.
<vcunat>
It seems a bottleneck that Hydra administration is so trust-sensitive.
<vcunat>
But there's probably no easy way around that.
<LnL>
yeah, the darwin stable idea started with the idea that we have enough build capacity now
<vcunat>
as we have separate nixos-channels, the only bottle-necking I see is in staging where one may be unsure (a) if the changes make a mass breakage on Darwin, and (b) whether to merge to staging without most Darwin binaries ready
<vcunat>
Fortunately, staging changes typically don't hurry, and pre-testing them on the Linux platform usually gives a lot confidence (depending on the type of the changes).
<LnL>
my point is that if we're not at full capacity the 17.09 job gets priority so staging/master start lagging behind
<vcunat>
Yes, that happened a week or two ago.
<vcunat>
We technically *can* reverse the priorities.
<vcunat>
(Instead of cancelling 17.09-darwin.)
<vcunat>
14 jobs running now, so hopefully I mostly looked at some of the worst moments.
<gchristensen>
I just kicked off a GC on the macs
<gchristensen>
we need to cron that
<LnL>
that's not nice, but we could do that for now until the issues are resolved
<vcunat>
right, some fast cron that checks free space and fires GC if under some threshold (and not running already)
<gchristensen>
something decent like that could even just be a while loop + sleep + screen and I could do that this morning
<vcunat>
<3
<vcunat>
And Linux boxes do have some auto-GC?
<gchristensen>
yeah, the standard nixos module for auto gc
<gchristensen>
which I think is a cron ;)
<vcunat>
nix.gc.automatic
<vcunat>
We need NixOS services for more platforms :-D
<LnL>
there's a nix.gc module for nix-darwin :)
<vcunat>
gchristensen: ^^
<LnL>
you could also just build that and copy/load it manually
<gchristensen>
yeah I'm ready too merge that in to be honest
<LnL>
if you don't want to switch over entirely
<gchristensen>
LnL: can you do that for me and send it over?
<LnL>
sure
<gchristensen>
I've got a bit of a busy morning for the next bit
<gchristensen>
so ... I'll be mostly AFK for a bit
<gchristensen>
hmmm I think I should wait on this until the current GC is done
<gchristensen>
LnL: does that need a </plist> at the end?
<LnL>
probably, maybe I didn't copy everything
<gchristensen>
how much free space should we shoot for
<gchristensen>
they have 900GB disks
<gchristensen>
how about 200G
<vcunat>
+0
<vcunat>
+1 :-)
<LnL>
I have no idea how much space they can fill up in a couple of hours
<gchristensen>
I just spent like 20 minutes writing a bash script to fetch / verify / run a bash script which fetches / verifies / places a file... and then realized I could just do it in nix and be done.
<gchristensen>
stupid. :P
<vcunat>
:-D
<vcunat>
after years of using nix(os) one may find oneself so powerless on a system without nix
<vcunat>
it's just addictive
<gchristensen>
no kidding
<gchristensen>
amazing how good life can be when you have tools that work
<niksnut>
speaking of macs, we're going to have to find a new home for them soon since this office is closing
<gchristensen>
:o
<LnL>
oh
<gchristensen>
LnL: how can I tell if this is working?
<LnL>
launchctl list should ld show 0 if it ran successfully once
<LnL>
niksnut: btw. did you see my comment about the sandobx/pre-build-hook?
<niksnut>
no
<gchristensen>
it shows `91 0 org....` does that seem right lnl?
<Dezgeg>
from the hydra build log to me it looks like CFLAGS=-O2 -g -I/nix/store/v1y7sdp8jd8kpg4sa5ca614bvmw05lk3-glibc-2.25-arm-unknown-linux-gnueabihf-arm-unknown-linux-gnueabihf-dev/include in makeFlags
<Sonarpulse>
Dezgeg: that makes sense
<Sonarpulse>
it's a build != host == target build
<Sonarpulse>
so host and target are arm
<Sonarpulse>
it's just this build one the arm stuff is leaking in when it should be x86
<Dezgeg>
are you sure that's not passed to the build gcc?
<Sonarpulse>
Dezgeg: I doubt it, cause I see a problem CXXFLAGS_FOR_BUILD
<Sonarpulse>
and gcc worked fine
<Sonarpulse>
just g++ failed
<Dezgeg>
that starts with CXXFLAGS_FOR_BUILD=-O2 -g -I/nix/store/vrr9maj9lqj2xwndlx3kh07vhnc111i2-glibc-2.25-dev/include which is correct
<Dezgeg>
which does not appear at all in the failing command line
<Sonarpulse>
oh sorry you are right
<Sonarpulse>
Dezgeg: actually there might be a _FOR_HOST
<Dezgeg>
is CXXFLAGS_FOR_BUILD something that's actually used by gcc?
<orivej>
Sonarpulse: yes, I'm trying to understand your reasoning, so far I don't see why merging old commits into master is more convenient than tegging them
<Sonarpulse>
orivej: oh those are *new* merge commits
<Sonarpulse>
they don't currently exist
<Sonarpulse>
they are me forward porting my gcc fix
<Sonarpulse>
through various conflicting gcc changes
<gchristensen>
preferably with that handleEvalIssue patch :)
<orivej>
Sonarpulse: hm, and why do you need these changes applied prior to old commits? to see at what point between the base and the head of the PR they broke something?
<Sonarpulse>
orivej: yeah the first old commit is a known good state
<Sonarpulse>
the last one
<Sonarpulse>
to validate that these changes indeed are entirely safe
<Sonarpulse>
the second merge commit has issues that my next PR will hopefully fix
<Sonarpulse>
but I need that PR to depend on this one
<Sonarpulse>
I don't want to throw away my testing commits
<vcunat>
gchristensen: I don't think it will bit-rot quickly
<Sonarpulse>
but rather commit them
<Sonarpulse>
so I can reference them later
<Sonarpulse>
sort of a "history proof of correctness"
<vcunat>
I had to fix one small conflict in a few hours, but that was probably just bad luck (and it took under a minute anyway)
<gchristensen>
oh
<gchristensen>
well
<gchristensen>
I guess maybe I'm excited to do it :P
<vcunat>
well, the high-churn changes can actually be merged fast
<vcunat>
what I'm not very certain yet is how to do the check-meta.nix change