<LnL>
it's a bit rough, but some changes in the stdenv could make it a lot nicer
<LnL>
everything like the shellHook works like normal, only exception are the unpack/install phases
<nkpart>
Hey, this might be a silly question, but after I run a `nix-channel --update`, do I need to 're-derive' anything I've built to include any changes to the current channel?
hamishmack_ has joined #nix-darwin
hamishmack has quit [Read error: Connection reset by peer]
hamishmack_ is now known as hamishmack
<acowley>
nkpart: I think so
<acowley>
Well, not re-derive, but rebuild
philr has joined #nix-darwin
<nkpart>
acowley: as in just 'nix-build myfoo'?
<acowley>
nkpart: Yep!
pxc has quit [Ping timeout: 255 seconds]
pxc has joined #nix-darwin
hamishmack has quit [Quit: hamishmack]
the-kenny has quit [Ping timeout: 240 seconds]
the-kenny has joined #nix-darwin
<johnw>
anyone know about emacsWithPackages?
<johnw>
i cannot for the life of me get my org override to use the indicated version
zzamboni has joined #nix-darwin
zzamboni has quit [Remote host closed the connection]
<johnw>
dhess: another weird thing I've found: if I run an Emacs that uses emacsWithPackages (instead of one that uses my own custom load-path), it takes up to 30 seconds for C-x C-c to exit that Emacs
<dhess>
in my version, I use (emacsPackagesNgGen self.emacs).overrideScope. Does that make any difference?
<johnw>
if I use nix-repl, I can see that the org version is the right one
<johnw>
and if I examine my buildEnv, the explicitRequires refers to the right noe
<johnw>
but for some reason, at build time, this is simply ignored
<johnw>
I have emacs26PackagesNg = pkgs.emacsPackagesNgGen emacs26;
<johnw>
so effectively the same thing
<johnw>
even if I explicit refer to (myEmacsPackages emacs26 epkgs epkgs).org, it's still wrong
<johnw>
i think the bug might be in emacsWithPackages itself
<dhess>
<johnw> I get: chmod: changing permissions of '/private/tmp/nix-test/store':
<dhess>
Operation not permitted [14:20]
<dhess>
<johnw>
oh yes
<johnw>
just had to rm -fr
<johnw>
and then undo a local commit relating to brotli
<johnw>
and rebuild
<dhess>
so it's safe to go in the water with nixUnstable and distributed builds on macOS?
<johnw>
thanks for asking
<johnw>
yep!
<dhess>
awesome
<dhess>
I think I will try that now
<johnw>
"nix build" even works, as well as "nix-build"
<johnw>
I now prebuild darwin.system with nix build, then let darwin-rebuild use nix-build
<johnw>
just to get the sexy overview
<LnL>
I have a hydra job that builds my config :)
<johnw>
haha
<dhess>
me too :)
<dhess>
so nice to have it just autobuild on commits and then pick an evaluation that works
<johnw>
ok, the beauty of managing emacs with Nix is that I just flipped from having my entire config (408+ packages) from being based on melpa-stable to melpa-unstable: or, I can have both at once in different envs!
<dhess>
\o/
<LnL>
yeah I have an alias that does that
<johnw>
still have to figure out the slowness it incurs on exit, though
<LnL>
something like darwin-rebuild switch -I nixpkgs=$(lnl-nixpkgs)
<johnw>
profiler says it's spending half of that time in pcache, the other half in GC
<LnL>
johnw: did the shell thingy work?
<johnw>
what is the shell thingy?
<johnw>
ok, I haven't tried your new code
<johnw>
is it ready for my consumption?
<LnL>
no idea, you could try to build one of your envs and see if it works
<johnw>
true, I should do that this week
<LnL>
really don’t get all the weird stuff my-env-fun is doing
periklis has joined #nix-darwin
<periklis>
LnL: afaik you have tweeted yesterday with giligan on hydra build for macs. i'am preparing the WIP-PR. It would be very kind if you could assist on the missing symbols for template instantiations on linkage of hydra-queue-runner.cc
<johnw>
night all
<LnL>
yeah
<LnL>
could you share your diff somewhere
<LnL>
I took a quick look but ran into an issue with the pqcxx headers
<LnL>
periklis: oh, I used llvmPackages_5.stdenv for that
<dhess>
angerman: no :( I have all 3 of those in my environment as well, via a buildEnv, anyway
<angerman>
this is nix-darwin though.
<dhess>
I'm using the latest nixpkgs-unstable channel fwiw
<dhess>
angerman: I am also running nix-darwin, if that's what you mean.
<angerman>
nix-channel --list only has darwin
<angerman>
should I add nixpkgs-unstable as well?
<dhess>
yes but the nix installer sets nixpkgs for the root channel
<dhess>
angerman: sure but I suggest you also remove root's channel
<angerman>
dhess: colour me confused. What do I need to do? `sudo su -; nix-channel --list` gives me the nixpkgs channel. So should I drop the one from root, and add it to my user?
<dhess>
angerman: that is how I do it
<angerman>
Is the suspicion that the root channel is never updated, because I rarely run nix-channel --update as root?
<dhess>
and per discussion the other day in #nixos with gchristensen and LnL it sounds like that is the recommended practice
<dhess>
angerman: yes that is one of the issues
<dhess>
this way you can just nix-channel --update and darwin and nixpkgs get updated from the same account
<LnL>
I think it makes sense to switch it, just is a bit tricky not to break anything
<angerman>
I hope that won't interfere with my remote building :D
<dhess>
I do remote building with this setup
<dhess>
(well actually I use a checked-out git repo for nixpkgs rather than a channel, but I also deleted my root nixpkgs channel)
<dhess>
oh really?. what was the trick, just making sure you had a 'system' configured for all hosts/?
<angerman>
pretty much.
<dhess>
angerman: that is a good catch. You may have solved a ton of Mac NixOps users' issues with that one
<dhess>
you might want to look around on the issue tracker for the various issues that are open re: that problem and post a link to your Medium when it's ready
<angerman>
the most annoying thing was that my webhost runs xen with a provided kernel (e.g. nixOS's kernel is never run), and that caused some issues as nix was expecting to generate grub2 menu items, the host was still configured to use some legacy pvgrub setup which read grub1's menu (e.g. never saw the newer generations). Switching over to the non-legacy, meant I needed to hack nixos a little.
<dhess>
oh the container issue does look like it's at least partially related to the nixpkgs.system thing
<angerman>
but, yea I use nix-docker (thanks LnL) to build for x86_64-linux, and deploy on a xenU thing.
<dhess>
but there is some more hacking needed as well
<angerman>
I'll put it on my todo stack. But I really need to get that service deployed, and right now haskell is throwing up, which makes absolutely no sense.
<dhess>
angerman: do you have any overlays set up?
<angerman>
not that I'm aware of.
<angerman>
dhess: can I just use a nix shell with those packages?
<angerman>
what I don't understand is what the actual conflict is, both packages have hashable in the same version and hash.
<dhess>
put that in ~/.config/nixpkgs/overlays.nix
<dhess>
then nix-shell -p haskell-env
<dhess>
I haven't actually tested that, I just whipped it up based on a much more complicated one that I have, but it's more-or-less right
<angerman>
does one ever get used to the nix syntax?
<dhess>
yes
<dhess>
it's like Haskell, just takes awhile, but worth it in the end :)
<dhess>
(the syntax is not like Haskell; just the bit about taking awhile to get used to but ultimately worth it, is what I mean)
<angerman>
meh... why doex $NIX_PATH point to root?
<angerman>
that doesn't sound right does it? echo $NIX_PATH => /nix/var/nix/profiles/per-user/root/channels
<dhess>
in your user shell or in root's ?
<angerman>
user
<dhess>
mine looks like this: NIX_PATH=darwin-config=/Users/dhess/.config/nixpkgs/darwin-configuration.nix:/nix/var/nix/profiles/per-user/root/channels:/Users/dhess/.nix-defexpr/channels:nixpkgs=/Users/dhess/git/nixpkgs-channels
<angerman>
yikes, got bitten by using zsh again
<dhess>
don't worry about the darwin-config being different than the way it's configured by default, that's just a detail
<angerman>
guess that got erased when I did the darwin-rebuild switch.
<dhess>
I don't recall whether nix-darwin's default darwin-configuration.nix sets nix.nixPath or not. I don't think you should need to mess with it in general, though
<elvishjerricco>
angerman: Do you know why cabal-install and cabal2nix both have the libHShashable dylib in their lib/links dirs?
<elvishjerricco>
angerman: I recall there was a horrible hack done to work around Sierra's new limitation on command line arguments to `ld` that had to do with moving haskell libs into super directories. But I didn't think that made it into the output paths of those haskell builds
<dhess>
is it set in there? that sounds familar
<angerman>
yep
<angerman>
and not having a zshrc ... well :D
<dhess>
angerman: well in that case you shouldn't need to set it.. unless you're using zshrc I guess :)
<dhess>
zsh i mean
<angerman>
guess :p
<elvishjerricco>
angerman: Can you try using `nixpkgs.cabal2nix`/`nixpkgs.cabal-install` instead of `nixpkgs.haskellPackages.cabal2nix`/`nixpkgs.haskellPackages.cabal-install`?
<elvishjerricco>
The former should be modified with `justStaticExecutables`, which should remove the conflicting paths
<LnL>
you can see the current and default value of options with darwin-option nix.nixPath
<dhess>
oh nice
<LnL>
angerman: did you set programs.zsh.enable?
<angerman>
LnL: just did. it generated the zshenv file, I'm just not sure why it's not picked up
<LnL>
existing files won't be overwritten if they already exist
<LnL>
did you get a warning when activating?
<angerman>
yea: warning: not linking environment.etc."zprofile" because /etc/zprofile exists, skipping...
<LnL>
that's why, either move the original out of the way or add a line like if test -e /etc/static/zprofile; then . /etc/static/zprofile; fi at the end
<angerman>
something really weird is up.
<angerman>
even if i source that file, it doesn't set the NIX_PATH properly.
<LnL>
environment variables are set in zshenv
<angerman>
wow. I've added some debug statements, and it actually runs the export. Now where does it pick up the faulty NIX_PATH from?
<LnL>
oh wait, I think the installer adds a line to /etc/zshrc
<LnL>
grep nix-daemon.sh /etc/zshrc
<angerman>
yea, that's in there.
<angerman>
there we go.
<angerman>
thanks LnL, what do we need to do to drop that nix-daemon stuff?
<LnL>
I'll add a check for that
<angerman>
LnL: could this be fixed in such a way that those lines aren't even added to begin with?
<LnL>
it's the nixos.org installer that adds those
<angerman>
ahh ok
<LnL>
but I recently moved some stuff around so that a multi-user install still works if you don't have services.nix-daemon enabled
<angerman>
kk. things are working agian. Let's try installing ghc and friends again.
<LnL>
activation already complains if it finds that in profile, I could do the same for other places
<angerman>
yea, I remember that from the initial install.
<angerman>
just wasn't sure if it was regenerated or not :D
<angerman>
dhess: any idea why I might get /nix/store/j5xbmv2nbyv5bnwlz2qwlbkfk7fcsz2x-nixpkgs-18.03pre125488.9059c93b843/nixpkgs/pkgs/top-level/stage.nix:120:57, when I activate the overlay?
<dhess>
hold on let me test it real quick
<angerman>
there's a semicolon missing in line 18. but no idea where that stage issue comes from.
<dhess>
that one works for me. In the shell I get cabal2nix, cabal, and ghc
<dhess>
you can add haskell packages by name to the empty list [] in ghcWithPackages
<dhess>
if you want to make them available in the shell
<angerman>
still doesn't work for me. that's weird. I've basically written it to ~/.config/nixpkgs/overlays.nix
<dhess>
yeah
<dhess>
you get the same error as before?
<angerman>
yea
<angerman>
maybe I need to put it as a file into overlays :D
<angerman>
that looks better.
<angerman>
tricky...
<angerman>
and not very helpful error message.
<dhess>
I dunno what you mean but if it's working that's cool :)
<angerman>
dhess: all I did was `mv ~/.config/nixpkgs/overlays.nix ~/.config/nixpkgs/haskell.nix; mkdir ~/.config/nixpkgs/overlays; mv ~/.config/nixpkgs/haskell.nix ~/.config/nixpkgs/overlays`
<angerman>
dhess: the key being, that `~/.config/nixpkgs/overlays` is now folder and not a nix expression.
<dhess>
ok cool. I dunno why it wouldn't work as overlays.nix, it's supposed to, but I do like you do, a dir with multiple files in it
<dhess>
sorry, I was actually trying to simplify things a bit
<angerman>
no worries :D
<dhess>
anyway, cool. Overlays are awesome, you should use them :)
<angerman>
well. that took too much time now. I'll need to run and pick up my daughter. Might have some time to hack up the webservice for the github webhook later.
<dhess>
and bed time for me. Happy hacking!
<angerman>
if anyone is into crypto currencies... it's at ~30% off right now. Not sure if that's a dip though :D