<Enzime>
I'm not sure where it expects NSArray from
<Enzime>
I think from Cocoa
<Enzime>
[0mIn file included from ../test.m:3:
<Enzime>
In file included from /nix/store/rc0878089n7pnkx0q5syksc8k7n71anz-apple-framework-Cocoa/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
<Enzime>
In file included from /nix/store/9pv7cvisrizjrr23fl6pkjaq19c1n08b-apple-framework-Foundation/Library/Frameworks/Foundation.framework/Headers/Foundation.h:151:
<LnL>
hmm, well it's finding the headers because of what I linked earlier but something is going wrong when linking
<LnL>
adding NIX_DEBUG=1 might give some insight
<Enzime>
NIX_DEBUG=1 doesn't do anything
<Enzime>
there's a really complex configure system here that calls everything super quietly and pipes stdout/stderr to a file
<LnL>
it should print out the full arguments passed to clang, etc.
<Enzime>
ah I was mistaken, NIX_DEBUG=1 wasn't being exported properly previously
<Enzime>
note the `-F/nix/store/rxh5nqb7npw4q7h21v546z3dacbnr7kq-apple-framework-CoreFoundation/Library/Frameworks` is at the end (also appears 2 other times)
<Enzime>
leads to 'CoreFoundation/CFAttributedString.h' file not found
<LnL>
yes, but only for duplicates
<Enzime>
LnL: what do you mean?
wavewave has quit [Quit: Connection closed for inactivity]
<LnL>
all apple-framework-CoreFoundation? there's probably also an CF-osx-10.10.5 in there
<Enzime>
LnL: yeah there are a few CF-osx's in there
<Enzime>
is it whichever appears first out of CoreFoundation vs CF-osx
<Enzime>
which gets searched for <CoreFoundation/CFAttributedString.h>
<LnL>
yeah so that's the one without CFAttributedString
<LnL>
you can ignore the duplicates, that's a different problem but you want CoreFoundation first
<Enzime>
LnL: ah so that explains why when I put CoreFoundation first it works
<LnL>
here are some examples where I had to do some trickery to use the impure version
<Enzime>
LnL: yeah that's what I'm currently doing
<Enzime>
LnL: btw, how accurate is the frameworks.nix
<Enzime>
Cocoa is missing both Foundation and CoreData
<LnL>
no idea
<Enzime>
when I check <Cocoa/Cocoa.h> those are the 3 (w/ AppKit) includes
<Enzime>
LnL: did not realize the order of buildInputs -> clang flags
<Enzime>
just changed it so CoreFoundation is before Cocoa in buildInputs
<Enzime>
and that fixes the <CoreFoundation/CFAttributedString.h> not being found :)
<LnL>
hmm, that's enough?
<Enzime>
LnL: I think it's similar to the cf-private changes in the past
<Enzime>
LnL: yep
erickomoto has joined #nix-darwin
erickomoto has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
erickomoto has joined #nix-darwin
erickomoto has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stepcut has joined #nix-darwin
stepcut has quit [Remote host closed the connection]
erickomoto has joined #nix-darwin
<manveru>
LnL: is it normal that the `nix-env -iA` output consists mostly of crappy curl download progress?
<LnL>
nix2 client with nix1 daemon?
<manveru>
hmm
<manveru>
gotta upgrade the system...
<LnL>
my project handles all that for you :)
<manveru>
yeah :)
<manveru>
i just noticed i had a fucked up channel name
<manveru>
so i didn't get updates in ages
<manveru>
tbh i haven't touched the macbook in months either
<manveru>
but i'm gonna give a presentation on tuesday about nix at work, and everyone's using macs :P
<manveru>
so i thought i better make sure my examples work...
<LnL>
good idea :D
<manveru>
problem is that i'm using nix-darwin in multi-user mode, and they'll install via --no-daemon (so i have an easier time debugging shit)
<manveru>
so... i'm not sure it'll actually work
<manveru>
short of just giving them some .nix files to evaluate and avoiding `nix-env` if possible
<LnL>
that's not really a problem
<LnL>
excep for some subtitle stuff like restarting the nix-daemon when changing nix.conf
jtojnar has quit [Read error: Connection reset by peer]
<manveru>
maybe i should just tell them to use nix-darwin instead?
<LnL>
but nix-darwin should take care of most of those and you don't have to worry about it for users
<manveru>
seems like a much saner option
<manveru>
just that they need nix to install nix-darwin :)
<manveru>
and i have no clean system to test with
<LnL>
the most annoying thing with single user is stuff like python, that blindly writes pyc files to the store even tho the paths are marked read-only
<manveru>
yeah...
<manveru>
well, i'll have a chance to try it on another machine tomorrow
<manveru>
and in the worst case i built a CI that builds stuff for them, so they only write the expressions and get the outputs...
<LnL>
but if you want to go the nix-darwin route, let me know how that goes and if you ran into any issues
<manveru>
aye
<LnL>
I decided against it since at the moment most users basically only use substitutes
<manveru>
it says now that some /nis/store/<hash>-master.tar.gz lacks signature on `nix-channel --update`
<manveru>
that seems to be the nix-darwin tarball
<LnL>
and there are also linux users with not necessarily systemd
<LnL>
manveru: that also looks like nix1 -> nix2
<manveru>
any idea how to fix that?
<LnL>
err other way around
<LnL>
use the same nix version as the daemon to update the channels
<manveru>
hmm
erickomoto has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
erickomoto has joined #nix-darwin
<manveru>
i killed the daemon
<manveru>
probably not a good idea
<LnL>
it doesn't restart?
<LnL>
if that's the case then the daemon is not managed by nix-darwin
<manveru>
no, it worked now
<manveru>
got back to 1.11, now i can fix everything :)
<LnL>
heh, well nix-darwin won't touch the existing service if you don't set services.nix-daemon.enable = true;
<manveru>
i did
<LnL>
since it might be a single user install, etc.
<manveru>
but i also had nixUnstable in systemPackages and nix.package = nixUnstable
<manveru>
so i'm not sure how this happened
<LnL>
hmm, that shouldn't be a problem since the client and daemon continues to be in sync
<LnL>
(except for IFD while activating)
<manveru>
trying to upgrade to unstable again
<manveru>
darwin-rebuild says it reloaded the daemon
<manveru>
just complains about the signed-binary-caches setting... not sure why that's still in nix.conf
<manveru>
it isn't
<manveru>
so where does that come from?
<LnL>
that's normal once while upgrading from 1 to 2
<manveru>
alright :)
<LnL>
same happened with nixos 17.09 -> 18.03
<manveru>
all green now
<manveru>
thanks man
<LnL>
but something like nixPath = [ "nixpkgs=https://nixos.org/channels/nixpkgs-unstable" ]; does cause problems while upgrading
<manveru>
yeah
<manveru>
i removed all those too
<manveru>
i think that was needed once?
<LnL>
because the sanity checks I added run with inconsistent versions
<LnL>
no, that's if you don't want to use nix-channel for some reason
<manveru>
is the remote builder story better these days?
<manveru>
like that xhyve thingy
<LnL>
that reminds me, maybe I could fix that with --option tarball-ttl :infinity:?
<manveru>
that sounds reasonable
<manveru>
does tarball-ttl also work for fetchGit?
<LnL>
it might, I forgot if that's true
<LnL>
but if so I could avoid refetching impure stuff from NIX_PATH while still running the sanity checks to make sure the values actually make sense
<manveru>
cool, command-not-found also seems to work well now
<manveru>
so NIX_AUTO_RUN=1 also :D
<LnL>
huh, that also works?
<manveru>
jup
<LnL>
lol
<LnL>
I had no idea
<manveru>
now... let's see if home-manager works too
<LnL>
it's basically a single line module that just enables the nix-index implementation :)
<manveru>
yeah
<manveru>
but it's super useful
<manveru>
damn, macos has no /etc/hostname :|
<manveru>
is there a reason default nix on nixpkgs-18.03-darwin is still 1.11?
<manveru>
like nix-repl still uses that
<gchristensen>
use `nix repl`
<manveru>
that just uses `nix-repl`
<manveru>
`nix version` is `2.1pre6148_a4aac7f`
<manveru>
so strange...
<manveru>
the `nix` executable is also a shell script...
<manveru>
wtf
<LnL>
nix-repl is 1.11 only
<manveru>
for some reason, when i run `nix`, it runs /run/current-system/sw/bin, which is nix 1.11, even though ~/.nix-profile/bin is before it in $PATH
<manveru>
but after i executed the .nix-profile one directly, it seems like the lookup changed
<LnL>
rehash?
<manveru>
that's something i haven't heard in a decade or so :)
<LnL>
I'm pretty sure if you run `nix` with PATH resolving it to eg. /run/current-system/sw/nix and nix-env -i nix afterwards your current shell use the one from your user profile
<LnL>
until you start a new shell or rehash, at which point bash drops the PATH lookup cache and finds the new one
<manveru>
but this is zsh
<manveru>
oh well
<LnL>
bash, zsh doesn't matter AFAIK pretty sure they all cache that
<manveru>
i'm just sad that 2.1 isn't the default version yet
jtojnar has joined #nix-darwin
erickomoto has quit [Ping timeout: 265 seconds]
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]