qyliss^work has quit [Quit: bye]
qyliss has quit [Quit: bye]
qyliss has joined #nix-darwin
qyliss^work has joined #nix-darwin
hamishmack has joined #nix-darwin
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
periklis has joined #nix-darwin
<johnw> when using /bin/bash (on a newly installed machine), does anyone know how to get a non-interactive ssh login to source /etc/bashrc? Add "source /etc/bashrc" to ~/.bashrc is having no effect...
<johnw> ssh hermes 'echo $PATH' ==> /usr/bin:/bin:/usr/sbin:/sbin
<johnw>
<wildsebastian> Hi, is it possible to use package overlays in a nix shell without putting the overlay folder in $HOME/.config/nixpkgs/overlays but to configure it via darwin-configuration? I tried in darwin-configuration to set nixpkgs.overlays = [ (import ./overlays/haskell.nix) ]; but that did not work within a haskell project using nix-shell.
<johnw> how did it "not work"?
<wildsebastian> When direnv called nix-shell it always executed the cron package tests, but in my overlay I added dontCheck for cron. https://github.com/wildsebastian/nix-config/blob/master/overlays/haskell.nix
<johnw> add some uses of builtins.trace, to confirm your theory that it isn't being accessed
<wildsebastian> Thank you, I will try that. Regarding your question, have you tried putting source /etc/bashrc to .profile? That usually works for me.
<LnL> wildsebastian: nixpkgs.overlays is only for nixos/nix-darwin user builds look at ~/.config/nixpkgs/overlays
<johnw> no, that doesn't change anything
<johnw> I've tried .bashrc, .profile, .bash_login, .bash_profile
<LnL> same problem again?
<johnw> this time with bash
<LnL> bash is the login shell now right
<johnw> it's strange to me that I can't modify the environment that SSH sees on login
<johnw> hmm
<johnw> if I directly put something .bashrc, like export PATH=<...>, then it takes effect
<johnw> but "source /etc/bashrc" doesn't change the environment
<johnw> anyway, that should be enough
<LnL> yeah, not sure
<LnL> ls -la #=> lrwxr-xr-x 1 root staff 11 Feb 17 15:34 .bashrc -> /etc/bashrc
<wildsebastian> @LnL Thank you. That is what I am doing right now, I was just wondering if there is a way around that.
<LnL> ssh mac -- echo '$0' #=> bash
<johnw> ok, nix copy is working well enough now
<johnw> just seeking to avoid rebuilding 40 GB worth of store contents :)
<LnL> ssh mac1 -- nix-store --help
<LnL> that's all I did AFAIK
<johnw> how do I work around this: cannot add path '/nix/store/...' because it lacks a valid signature?
<johnw> I don't care if it lacks a signature
<LnL> a trusted user can pass --no-check-sigs
<johnw> excellent
<LnL> I have keys setup, but that's a bit more configuration ofcorse
<johnw> yes, that did it
<johnw> this in /etc/nix/nix.conf:
<johnw> trusted-users = johnw @admin
<johnw> allowed-users = *
<johnw> and --no-check-sigs on the sending side
<LnL> I mean secret-key-files and trusted-public-keys on the other side
<johnw> thanks, LnL
<johnw> the amount of time it takes to get a new machine going is always getting smaller, bit by bit
<johnw> I just need to compile a list of all these tricks
abathur has joined #nix-darwin
<LnL> nice, but you have packages that depend on xcode somehow?
<abathur> is there an existing way to squelch underlying compile messaging during the install process? I tried --no-build-output hoping it would pass through but that doesn't seem to work
<johnw> LnL: oh, is that no longer needed?
<johnw> I usually install it anyway, to make use of tools like Instruments
<johnw> but I didn't realize it was optional these days!
<LnL> yeah, it has been optional since copumpkin overhauled the darwin stdenv :)
<LnL> but once in a while a build sneaks in that fails on hydra build works locally if xcode is accessible
<LnL> btw, I fixed almost all of the sandboxing problems I know about, if you're willing to give that another shot
<johnw> kk
<johnw> LnL: it doesn't work for me
<johnw> LnL: I tried building my "hnix" project, and it fails with:
<johnw> ghc: can't find a package database at /Users/johnw/.cabal/store/ghc-8.6.3/package.db
<johnw> why would it even be trying to do this?
<LnL> hmm
<LnL> that shouldn't even know you username/homedir so maybe ./. copies in things created by a manual cabal build?
<johnw> ah, maybe so!
<johnw> there is indeed a ".ghc...." in there
<johnw> so effectively, sandboxing has just found a bug in my build recipe!
<johnw> oops, this is bad:
<johnw> Assertion failed: (diff <= INSTR_JUMP_NE_MAX_LENGTH), function push_jne_instr, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/Sandbox/Sandbox-765.70.1/src/compiler/patterns/serialize.c, line 186.
<LnL> if it's always a full clone try builtins.fetchGit ./. that filters out most things correctly by default
<johnw> with submodules?
<LnL> ah maybe not
<johnw> that's ok, I think the recipe pulls them in directly
<johnw> I think I was getting that sandboxing assertion before too
<johnw> it prevents me from building my darwin environment with sandboxing on
<LnL> not sure about the assertion tho, where does that come from?
<johnw> me running:
<johnw> NIX_PATH=darwin-config=/Users/johnw/src/nix/config/darwin.nix:home-manager=/Users/johnw/src/nix/home-manager:darwin=/Users/johnw/src/nix/darwin:nixpkgs=/Users/johnw/src/nix/nixpkgs:ssh-config-file=/Users/johnw/.ssh/config:ssh-auth-sock=/Users/johnw/.config/gnupg/S.gpg-agent.ssh:localconfig=/Users/johnw/src/nix/config/vulcan.nix nix build -f . --keep-going \
<johnw> --argstr version 20190319_105735
<johnw> this way, I can build all dependencies in one shot, before running darwin-rebuild switch
<johnw> I like the pretty "nix build" status :)
<{^_^}> nix#2311 (by mroi, 34 weeks ago, open): sandboxed builds with many sandbox rules fail on Darwin
<LnL> does building your system itself work or does that also hit the limit?
<johnw> i'll have to try later
<LnL> what's the status of hnix btw, anything new that I don't know about yet?
<johnw> we're getting ever-closer to evaluating all of nixpkgs
<johnw> there's a new hnix-store project, that hnix now depends on
<johnw> there's been significantly internal refactoring to allow for extensible value representations and custom laziness strategies
<LnL> oh, you found more "bugs" when trying to evaluate nixpkgs?
<johnw> oh yes
<johnw> tiny little corner cases
<johnw> like the fact that functions aren't comparable, unless you're comparing two attr sets whose values are thunks-that-yield-functions, in which case they are
<johnw> seems that C++ Nix does a pointer equality test in the latter case
<johnw> which meant we needed thunk identities, but now we want them to be order-of-evaluation independent too
<johnw> my biggest use of hnix right now is to debug Nix expressions that I'm writing
<johnw> the information it yields around evaluation errors is _significantly_ better
<johnw> and it's almost a full drop-in replacement for nix-instantiate, just slower
<johnw> just the output from -v3 is enough to make you a believer; add --values and --thunks onto that, and it gets crazy :)
<johnw> since hnix remembers the "evaluation context" of every values involved in an expression
<johnw> recursively
<johnw> it's even too much information to show you; but people are working on Web UIs that will allow for intelligent drilling down into the information
<LnL> yeah, I also used it to debug something a while back
<johnw> others are using it for custom tooling, like domenkozar
<johnw> and shlevy and mightybyte and ryantrinkle
<johnw> we had an "hnix hackathon" in NYC three weeks ago, very productive
<copumpkin> hiya :)
<johnw> hi copumpkin!
<copumpkin> I'm still alive!
<copumpkin> sort of :)
<johnw> yay
<LnL> o/
<copumpkin> what's new?
<LnL> what have you been upto?
<johnw> LnL is solving the world's problems, one Mac at a time
<copumpkin> figuring out where my life will be! my girlfriend is finishing her residency in a couple of months and has been interviewing, and I'm switching jobs too, and then we're moving across the country to WA
<copumpkin> so lots of change :)
<copumpkin> need to find a place to live, then move all our stuff
<LnL> oh wow
<copumpkin> joining the Amazon behemoth :P
<copumpkin> will hold off a bit before trying to infect them with Nix probably
<copumpkin> >_>
<LnL> haha
<gchristensen> congratulations, copumpkin :D
<johnw> Amazix
<johnw> yes, congrats!
<abathur> nice!
periklis has quit [Remote host closed the connection]
<copumpkin> thanks :)
hamishmack has joined #nix-darwin
<abathur> mehhhh
<abathur> while trying to figure out what bespoke edit a past version of myself shamefully failed to commit or at least document, I noticed something that looks redundant
<abathur> I think the stock /etc/bashrc ends on `[ -r "/etc/bashrc_$TERM_PROGRAM" ] && . "/etc/bashrc_$TERM_PROGRAM"`
<abathur> and the generated /etc/static/bashrc also has the same on line 3
<abathur> and the installer appends `if test -e /etc/static/bashrc; then . /etc/static/bashrc; fi` to the stock bashrc as well, so they'd both be sourcing the stock /etc/bashrc_Apple_Terminal (well, in stock Terminal.app at least)
<LnL> yeah, I usually replace those entirely but didn't feel comfortable with doing that automatically
<abathur> I guess thee impact is minimal, been a while since I looked at bashrc_Apple_Terminal but most of it is guuarded from re-exec
<abathur> not a terribly rigorous test but I guess the impact is just around 20ms so not a huge deal
abathur has quit [Ping timeout: 250 seconds]
abathur has joined #nix-darwin
abathur has quit [Ping timeout: 250 seconds]