<copumpkin>
niksnut, gchristensen: would it be sensible to put a ~/.nix-channels into the installing user's home directory on multi-user macOS installs? The whole "nix-channel --update" does nothing business is pretty counterintuitive for users
<gchristensen>
yeah
<gchristensen>
I think so
<LnL>
(y)
<gchristensen>
and actually, maybe should just remove the channel from root
<copumpkin>
a system channel might be helpful for nix-darwin? LnL?
<gchristensen>
I think even then, it just confuses the issue
<LnL>
no
<copumpkin>
although it might also be confusing for users
<copumpkin>
yeah
<LnL>
also when you upgrade it'll disappear
<LnL>
so even more confusing
<copumpkin>
hah okay
<LnL>
doesn't matter where your channel comes from for nix-darwin
<LnL>
and I actually already include user channels by default there
<copumpkin>
cool :)
<niksnut>
copumpkin: that issue is moot since multiuser installs no longer work on macOS
<gchristensen>
it does as of 10.13.2! :)
<copumpkin>
10.13.2 fixes it
<copumpkin>
yeah
<clever>
did apple fix what they claimed wasnt a problem?
<gchristensen>
yeah
<niksnut>
nice
<copumpkin>
they claimed it wasn't a security problem :)
jtojnar has quit [(Remote host closed the connection)]
<copumpkin>
anyway yeah, I was going to push through my ugly-ass fix
<copumpkin>
but if the OS update will just fix it I got less motivated :P
jtojnar has joined joined #nixos-dev
<niksnut>
heh, Nix now barfs on preCheck = ''export LOGNAME=${LOGNAME:-foo}'';
<copumpkin>
because it's a lambda in a string substitution?
<niksnut>
yeah
<gchristensen>
:)
jtojnar has quit [(Quit: jtojnar)]
jtojnar has joined joined #nixos-dev
<gchristensen>
LnL, niksnut: grahamcofborg has a Darwin builder running on 10.13.2 now, so we'll hopefully get real life info on if macOS HighSierra can tolerate Nix :)
<LnL>
cool mine is still on 10.11 or 10.12, don't remember
<gchristensen>
cool
<gchristensen>
oh, funny, "edolstra" hasn't been whitelisted to call grahamcofborg... I dunno if I trust that fella ...
<LnL>
heh
<ikwildrpepper>
screw that edolstra, he keeps filling up my disks with this nix thing
<ikwildrpepper>
(sorry niksnut ;)
<copumpkin>
lol
<gchristensen>
anyway, please send lots of builds through to grahamcofborg to test it out
<copumpkin>
niksnut: hmm, I guess nix-build --hash needs some help from nixpkgs
<copumpkin>
error: Specify hash for fetchurl fixed-output derivation:
<copumpkin>
oh I'm supposed to put in a bunch of zeroes, right?
<copumpkin>
niksnut: we might even have a very secret way to do bind mounts for a proper chroot in darwin :P
<copumpkin>
need to explore
<copumpkin>
if 1.12 comes out before we move on from 17.09, I'll backport this stuff to 17.09
<niksnut>
copumpkin: how?
<copumpkin>
they're called translocations
<copumpkin>
see discussion in ##nix-darwin
FRidh has quit [(Quit: Konversation terminated!)]
<Mic92>
gchristensen: where do you your bot on at the moment?
<Mic92>
*run
<gchristensen>
a few places, the coordination parts happen on the system that runs search.nix.gsc.io, the issue tagging and eval checker runs there too, the builds run on a laptop in my office, on lnl's machine somewhere, and another machine I have somewher
<gchristensen>
does that answer your question? what are you wondering?
<Mic92>
I had these funny pictures in my head, what it would look like, if I start heating your laptop with nix-builds, while you are sitting in a train or so.
<copumpkin>
I wonder...
<gchristensen>
haha
<copumpkin>
if I produce a channel as a derivation in a normal nix build and cache it on my binary cache
<gchristensen>
it is almost to the point where we could easily have more people run builders
<copumpkin>
then I could potentially use <nix/fetchurl.nix> { unpack = true } to retrieve it directly from the binary cache...
<copumpkin>
how weird would that be?
<copumpkin>
niksnut: :) :) :)
<fpletz>
that could solve the signing issue :)
* copumpkin
experiments!
<gchristensen>
is Bas on IRC?
orivej has joined joined #nixos-dev
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
Sonarpulse has joined joined #nixos-dev
pbogdan has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
vcunat has quit [(Ping timeout: 240 seconds)]
goibhniu has quit [(Ping timeout: 248 seconds)]
pbogdan has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Client Quit)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
<rycee>
Np. It's not a big change but I thought it would be good to have it in writing somewhere.
<rycee>
(looking at this I also noticed how inconsistent the option naming was in NixOS ;-) )
<fpletz>
yeah, all over the place unfortunately
<fpletz>
sometimes service configuration options are taken verbatim from config files
<fpletz>
we should try to reach some concensus there, there are also patterns like listenAddress and extraConfig we should probably mention in the docs
<bgamari>
so it's the first patch in my rebased ben-cross branch that dies with infinite recursion
<Sonarpulse>
on one hand, stdenv-topo is broken and could wait
<Sonarpulse>
on the other, the way I change findInputs in stdenv/setup in it
<bgamari>
while evaluating anonymous function at /home/ben/block-eng/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:63:15, called from undefined position:
<bgamari>
while evaluating the attribute 'stdenv.cc.bintools' at /home/ben/block-eng/nixpkgs/pkgs/stdenv/generic/default.nix:137:14:
<bgamari>
infinite recursion encountered, at undefined position
<Sonarpulse>
I think is better than what I did in cross-elegant
<bgamari>
that is the tail the error
<Sonarpulse>
bgamari: did you see my rebase of yoru branch?
<Sonarpulse>
I thought it was infinite recursion free
<bgamari>
I did
<bgamari>
perhaps I'll try to splice it in
<Sonarpulse>
it has other problems though
<Sonarpulse>
the inifite recursion issues have to do with libc
<Sonarpulse>
being from the next stage
<Sonarpulse>
being used in compilers in the previous stage
<Sonarpulse>
what do you think re this stdenv-toposort?
<Sonarpulse>
prioritize? don't prioritize?
<Sonarpulse>
I know how to rebase on top, conceptually simple though lots of broken diffs will occure
<bgamari>
I agree that it sounds like a nice solution
<Sonarpulse>
but I am not sure why it isn't working yet
<Sonarpulse>
I suppose I could be more careful still about reverse the deps of each sort
<Sonarpulse>
not just changing the order of the sorts
<Sonarpulse>
but I didn't think that would matter
vcunat has quit [(Ping timeout: 240 seconds)]
<bgamari>
that be said, I'd likely focus on the bare minimum patchset to stabilize the cross story
<bgamari>
and hone later
<Sonarpulse>
that makes sense
<Sonarpulse>
I'm about to finish the gcc sthing
<Sonarpulse>
and kick off
<bgamari>
thanks!
<bgamari>
Sonarpulse, hmm, I see what you mean about libc
<Sonarpulse>
bgamari: I did something about that in my rebase
<bgamari>
really?
<Sonarpulse>
forget what
<Sonarpulse>
but problem more bound vars
<Sonarpulse>
to avoid cc.asdfasdf
<Sonarpulse>
ah a binutils1 = ...
<bgamari>
I rebased on top of your rebase
<Sonarpulse>
cool
<Sonarpulse>
oh
<Sonarpulse>
but stil infinite?
<bgamari>
nope
<bgamari>
now it seems even building on the host is broken
<bgamari>
e.g. building perl for the host fails with
<bgamari>
./try: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
<bgamari>
during configure
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
<bgamari>
hmm
<bgamari>
alright, it looks like one of my patches is the culprit
<Sonarpulse>
bgamari: good luck
<Sonarpulse>
I'm staring too much at the diff between gcc
<Sonarpulse>
versions
<bgamari>
Sonarpulse, not quite actually
<Sonarpulse>
see all sorts of old random stuff
<bgamari>
yeah, I would like to unify them
<bgamari>
but it scares me
<bgamari>
there are minor differences
<bgamari>
and testing it would be terrible
<bgamari>
Sonarpulse, were you able to build glibc for the target with your branch?
* bgamari
is getting
<bgamari>
/tmp/nix-build-glibc-2.26-75-armv7l-unknown-linux-gnueabihf-armv7l-unknown-linux-gnueabihf.drv-0/build/libc_pic.a: error adding symbols: Archive has no index; run ranlib to add one
<bgamari>
with only your patches
<Sonarpulse>
bgamari: huh
<Sonarpulse>
I'm not sure, tbh
<Sonarpulse>
libc has some special stripping / not strippping stuff
<bgamari>
well, it looks to me like ranlib isn't getting run
<Sonarpulse>
hmm
<Sonarpulse>
often ranlib isn't needed anymore
<Sonarpulse>
IIRC
goibhniu has quit [(Remote host closed the connection)]
<bgamari>
yeah
<bgamari>
that should be true
<bgamari>
Sonarpulse, indeed it looks like one of your patches regressed
<Sonarpulse>
:O
<bgamari>
right before your patches it builds
<Sonarpulse>
which one? :)
<bgamari>
I can try to bisect
<Sonarpulse>
hopefully not across a mass rebuild!
goibhniu has joined joined #nixos-dev
<gchristensen>
nix-build ./nixpkgs -A stdenv -j0 will fail if you can't fetch the stdenv from cache, allowing you to skip it
<Sonarpulse>
gchristensen: thanks!
<gchristensen>
:)
<gchristensen>
(`git bisect run` scripts which exit 125 are considered `skip`ped)
<bgamari>
Sonarpulse, it happens while building glibc
<bgamari>
so it's pretty early
<bgamari>
Sonarpulse, binutils, gdb: Do not expose libbfd or libopcodes, and be multitarget
<bgamari>
is the first bad commit
<Sonarpulse>
bgamari: oh damn, right
<Sonarpulse>
ugh
<Sonarpulse>
bgamari: ok great
<Sonarpulse>
in that one
<Sonarpulse>
I made binutils multitarget
<Sonarpulse>
but continued to pass the "--target" flag
<Sonarpulse>
so we would get prefixing, and hopefully the right default
<Sonarpulse>
but perhaps --target doesn't affect the default target with "--enable-target=all"
<bgamari>
Sonarpulse, I'm not entirely sure I follow
<bgamari>
you think that ld is targetting the wrong platform be default?
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]