hamishmack has joined #nix-darwin
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
nD5Xjz_ has joined #nix-darwin
nD5Xjz has joined #nix-darwin
nD5Xjz_ has quit [Ping timeout: 245 seconds]
nD5Xjz_ has joined #nix-darwin
nD5Xjz has quit [Ping timeout: 240 seconds]
nD5Xjz_ has quit [Ping timeout: 244 seconds]
<copumpkin> with some further really puzzling hackery, I think the CF actually works now
<disasm> been playing with hydra to test and verify my osx systems have no build failures before upgrading to 18.09. My system built fine, but my custom haskell stuff around nix-darwin failed to compile with iconv errors. I came across this thread, where someone at the bottom mentioned they had issues with nix 2.1. Just wondering if anyone knows of any work-arounds.
<disasm> helps if I link the thread, lol https://github.com/haskell/haskell-ide-engine/issues/744
<{^_^}> haskell/haskell-ide-engine#744 (by AesaKamar, 4 weeks ago, open): `iconv` linker errors on OSX
<disasm> tools are here, although I doubt there's anything that needs changed in the code: https://github.com/disassembler/network/tree/master/nix-darwin-tools
<LnL> and adding libiconv doesn't work?
nD5Xjz has joined #nix-darwin
nD5Xjz has quit [Ping timeout: 272 seconds]
nD5Xjz has joined #nix-darwin
nD5Xjz has quit [Ping timeout: 245 seconds]
nD5Xjz has joined #nix-darwin
nD5Xjz has quit [Ping timeout: 252 seconds]
<copumpkin> every time I interact with this bootstrapping dance I want to rewrite it from scratch :P
<copumpkin> and I never do
nD5Xjz has joined #nix-darwin
<disasm> LnL: adding that now to buildInputs
<disasm> well, that was an easy fix, thanks LnL!
jtojnar has quit [Remote host closed the connection]
nD5Xjz has quit [Ping timeout: 246 seconds]
nD5Xjz has joined #nix-darwin
jtojnar has joined #nix-darwin
philr has joined #nix-darwin
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nix-darwin
philr has quit [Ping timeout: 252 seconds]
<copumpkin> LnL: almost wrangled it into the bootstrap :)
<copumpkin> turns out the build I pushed by default includes debug symbols which stumped me for a while why it was retaining references to the bootstrap tools
<copumpkin> but that's now gone, and I'm building stage3 now
<copumpkin> this will make me so happy if it works
<copumpkin> we'll finally be able to bump the SDK version, get rid of the weird cf-private thing, etc.
<copumpkin> (I think cf-private can go, but maybe not)
<LnL> nice!!
<copumpkin> crossing fingers :)
<copumpkin> still stuff to patch for stage4
<copumpkin> but making progress
<LnL> that has started to become a problem with a bunch of projects
<copumpkin> cool
<copumpkin> or not, but maybe we can make it cool
<LnL> is there anything we can do to test our CF or do we just run a wip jobset and assume the builds cover enough?
<copumpkin> I've done some manual tests but yeah I think a wip jobset is our best bet
<copumpkin> amsuingly about that libxml2 thing
<copumpkin> it's now part of the bootstrap anyway thanks to the new CF
<LnL> the one with or without python?
<copumpkin> oh probably without, although I haven't paid special attention to it
<copumpkin> I'll look more carefully later
<copumpkin> actually maybe with
<copumpkin> since only stage3 has the one without right now
<LnL> that's not good, the python used in the stdenv is a very minimal one
<copumpkin> yup
<LnL> that one shouldn't leak out at runtime
<copumpkin> yeah
<copumpkin> will figure it out and clean it up once I get the basic thing working
<copumpkin> not gonna merge immediately :)
<LnL> yeah, just binging it up so you know
<copumpkin> yup will definitely pay close attention to that
<LnL> oh btw, I made a graph to track the stdenv build closure
<copumpkin> nice! where?
<LnL> we have like double of linux :/
<copumpkin> yup :)
<copumpkin> we'll clean it up
<LnL> should probably make a pr for that
<LnL> oh, it increased recently
<copumpkin> stage4 built :D
<LnL> how do you usually figure out what stage stuff comes from when working on the stdenv?
<LnL> what I did the last few times is annotate names of overrides with the bootstrap stage
<copumpkin> judicious use of stdenv.__bootPackages.X until I find the one that matches :)
<copumpkin> not very systematic
<copumpkin> whoa, final stdenv is building now, llvm and so on
<copumpkin> so unless some build fails for a weird reason, and unless I've screwed up my requisites, we're almost there
<copumpkin> didn't end up taking that long it seems (unless this jinxes it)
<copumpkin> I actually spent most of the middle of the day on pokemon go raids :P
<LnL> you can always edit the requisites temporarily, it doesn't cause rebuilds IIRC
<copumpkin> with any luck I won't need to :)
<copumpkin> anyway, another couple of hours to do LLVM+clang and we'll know