<dhess>
Ugh, something broke. Whenever I try to nix-build, I get "nix-instantiate killed by signal 11"
<dhess>
anyone here ever seen that before?
<dhess>
It's not because of an upgrade. It just started happening while I was building a few projects
<dhess>
one minute everything is fine, next minute every build starts dying with that message
<dhess>
and it's affecting *every* nix expression I try to build, not just the one I was evaluating when it happened the first time
<dhess>
I've also rebooted. Still happening.
<acowley>
So I just had something a little weird happen: I compiled a program with -fsanitize=address, and the executable came out with a link to /nix/store/***-llvm-4.0.1-lib/lib/libclang_rt.asan_osx_dynamic.dylib which doesn't exist. I used install_name_tool to replace it with llvm-4.0.1/lib/clang/4.0.1/lib/darwin/libclang_rt.asan_osx_dynamic.dylib and the executable worked.
<dhess>
never mind my problem, fixed. At least for now.
<acowley>
Does any of what I just described ring any bells for anyone?
<acowley>
I also just verified that my fixed executable catches memory errors if present, so the dylib is doing it's thing
<ldlework>
Does anyone here use home-manager helper? How do you set the mode of a file?!
<dhess>
I was quite surprised to see my nixbld users running all of those processes
<LnL>
that’s spotlight having fun with your store parhs
<LnL>
you probably want to disable that
<dhess>
does nix-darwin have any provision for that?
<dhess>
seems like the kind of thing it should do
<LnL>
no, but it’s in the hydra config
<dhess>
ahhh
<dhess>
hmm I only want to disable it for the nixbld users
<dhess>
I don't understand why it's running as those users at all. Their home directories are empty after all
<LnL>
you can disable it for /nix/store, not sure if that helps for this
<dhess>
I definitely don't want to disable Spotlight across my entire volume
<dhess>
I probably should disable it for /nix/store, it clutters up the Spotlight search results quite a bit.
<dhess>
But do you understand why it's running as nixbld1 ?
<dhess>
Is there a dscl setting to disable it per-user?
<LnL>
I’m guessing it’s a launchd agent, those start for each user
<LnL>
not sure why it happens for the build users since they can’t even have a login session
<dhess>
are you seeing this as well?
<LnL>
I’d have to check, that’s only during a build right?
<dhess>
no, it happens all the time
<dhess>
on a timer it seems, probably launchd as you suggested
<dhess>
and trustd and lsd are basically running all the time
<LnL>
oh
<dhess>
If I recall correctly I did have to create these user accounts by hand, because at the time that I installed nix-darwin, the user account stuff wasn't there yet and the one-off stuff you had in the installer didn't work on High Sierra
<dhess>
so it's possible that these accounts look like regular users to the OS in one or more ways
<dhess>
does the installer user creation work on High Sierra now?
<dhess>
cool, that seems to have worked without a hitch
<dhess>
LnL: how many build users do you create, generally?
<LnL>
something like 32, I sometimes use -j16 to speed up substitutes
<dhess>
so then, based on that warning in the installer module, looks like I should just set users.nix.nrBuildUsers = 32 in my darwin-configuration.nix and then run the installer again?
<dhess>
i.e., don't set users.nix.configureBuildUsers in the darwin-configuration.nix
<dhess>
LnL: so deleting the extra nixbld users and running the installer on my laptop and desktop worked great
<LnL>
you deleted the users but they are still part of the group
<dhess>
oh
<dhess>
hmm I didn't need to do that on the other 2 machines
<LnL>
probably because they didn't have to build anything after you deleted the user/group
<LnL>
using -j1 probably helps for this case
<LnL>
then it won't try to use more then nixbld1
<dhess>
hmm now I'm getting "error: all build users are currently in use; consider creating additional users and adding them to the ‘nixbld’ group"
<dhess>
no other builds happening on this host
<LnL>
you don't see any nixbld1 processes?/
<dhess>
no, only the daemon is running
<dhess>
as root
<LnL>
well, not sure maybe restart the daemon?
<dhess>
I rebooted, no change :(
<dhess>
I can reinstall I suppose, it's not a huge loss
periklis has joined #nix-darwin
<dhess>
LnL: so anyway, how do I create more nixbld users? I tried setting nrBuildUsers = 32 and re-running the installer, but that didn't actually create any more than the default 10
<LnL>
ah yes, you have to explicitly whitelist users that nix-darwin should manage
<dhess>
how do I do that?
<LnL>
the knownUsers option
<dhess>
do I also need to set knownGroups = [ "nixbld" ] ?
<LnL>
the installer already does that, you only need it if you want to manage it with regular activation
<LnL>
I should make it fail and finish working on the state stuff
<dhess>
so with 'users.knownUsers = [ "nixbld1" "nixbld2" ... "nixbld32" ]' and users.nix.nrBuildUsers=32 when I darwin-rebuild switch I get: Failed assertions:
<dhess>
- refusing to delete user nixbld1 in users.knownUsers, this would break nix
<dhess>
<dhess>
and if I remove nixbld1..nixbld10 it just doesn't create any new users
<LnL>
users.knownUsers = [ “foo” ]; and users.users.foo = ... belong together
<dhess>
I guess I figured these buildUsers would be somehow different since there is a separate nixbld/default.nix for them.
<dhess>
I need a users.users.nixbld1, users.users.nixbld2, ... users.users.nixbld32 to make this work?
<dhess>
with the proper IDs and all that?
<dhess>
home, shell, etc?
<LnL>
yes, but that’s what the buildUser option does for you
<LnL>
didn’t I add an option to configure the number of users
<dhess>
I set users.nix.nrBuildUsers=32 on line 36, is that what you are referring to?
<LnL>
yes
<dhess>
ok, so what am I missing then?
<LnL>
that gist looks ok
<dhess>
should I file an issue?
<LnL>
you get that error with the installer right?
<LnL>
yeah, please do
<dhess>
I get that error when I "darwin-rebuild switch"
<dhess>
let me try the installer
<LnL>
I should make it fail on unknown users anyway
<dhess>
oh the installer is working!
<dhess>
so: run the installer with that config, it works as expected -- creates the new nixbld users
<dhess>
but then after doing that, run "darwin-rebuild switch" and it complains about not deleting nixbld1
<LnL>
you should remove the user options afterwards
<dhess>
ok, it's a PITA but it is do-able
<LnL>
but that definitely sounds like a bug
<dhess>
oh but there is nixbld1 running /usr/libexec/lsd and /usr/libexec/trustd again
<LnL>
the idea is that the known options end up in your system and are used to compare impure things against the current generation
<dhess>
ahh *but* I think I never deleted nixbld1 on this machine
<LnL>
ah!
<LnL>
yeah the check only looks at nixbld1
<dhess>
you mean the knownUsers check. Yes, that is true, but what I meant is, nixbld1 is running those 2 processes again but I don't think I deleted it and created it again like I did with the other users, so that might be why it is running them
<dhess>
sorry, 2 unrelated threads going on :)
<dhess>
anyway, I will file an issue
<dhess>
re: the installer needing those knownUsers and darwin-rebuild not working with the same config
<LnL>
but that's not from source, how would I apply my patch?
* ldlework
tries to understand the conventions johnw is using
<ldlework>
installing emacs packages from nix from a wiki
<ldlework>
This could take me a week to fully understand hmm
<ldlework>
johnw your nix configuration is expansive
<ldlework>
johnw is there a sales pitch for managing your emacs packages with nix?
<johnw>
ldlework: that I like it? :)
<ldlework>
What about it do you like?
<ldlework>
I'm trying to be convinced here.
<ldlework>
One thing I worry with moving my emacs packages to nix is that my emacs configuration becomes far less sharable/exportable to other people
<ldlework>
I can't be like "here tangle this file and you can get going with emacs"
<dhess>
LnL: so, regarding those nixbld users running things like lsd and trustd, it's still happening, but it's happening a lot less. And maybe not at all on my remote builders, or at least I haven't seen it there yet
<dhess>
so that is some progress
<johnw>
ldlework: sorry, I wo'nt have time to talk until tuesday
<johnw>
i actuall yneed to leave iRC until then
<johnw>
good luck!
<ldlework>
I actually wonder if johnw based his OSX app install mechanism off mine
<ldlework>
Its much improved!
* ldlework
steals.
gridaphobe has quit []
gridaphobe has joined #nix-darwin
<ldlework>
johnw I really wish I could ask you some questions lol
<ldlework>
Like what is darwin-rebuild
<ldlework>
its invoked like binary, but it is no where
<ldlework>
LnL what do you think the reason John is using both nix-darwin and home-manager is?
<LnL>
he likes the conceptual difference, not making everything global
<ldlework>
Can you explain that a bit? What do you mean making everything global?
<ldlework>
LnL is it that nix-darwin is about maintaining system level things, and home-manager is about your home directory?
<ldlework>
I'm guessing so.
<LnL>
yeah, (almost) everything nix-darwin does applies to all users
<ldlework>
Interesting... so he uses nix-darwin to at some point set HOME_MANAGER_CONFIG which points to his home.nix which allows home-manager switch to then work
<ldlework>
Crazy
<ldlework>
My brain is going to hurt a lot tonight
<ldlework>
LnL have you and rycee ever considered a combination of efforts?
<pikajude>
hey LnL is it possible to get a system package copied into /etc rather than symlinked into /run/current-system
<pikajude>
this stupid app is following the symlink
<pikajude>
i need it to not do that
<LnL>
the config file?
<pikajude>
well
<pikajude>
uh
<pikajude>
what config file
<LnL>
or are you talking about all of /run/current-system
<pikajude>
oh, no
<pikajude>
i'm talking about a specific thing
<pikajude>
that is a directory, not a file
<pikajude>
sadly
<pikajude>
i want /run/current-system/sw/share/doc/dash to be copied to /usr/local/share/doc or something
<pikajude>
idk
<pikajude>
it needs to be copied to some directory and not symlinked
<pikajude>
so that i can add it in Dash
<dhess>
pikajude: ohhhhhh that is an interesting thought.
<dhess>
getting Dash to use the haddocks I've installed in my nix-env
<pikajude>
isn't it
<pikajude>
i wrote a function called makeHaskellDocset
<pikajude>
it's quite nice except every time i update it i have to delete the old docsets in dash and add the new ones
<pikajude>
very annoying
<dhess>
pikajude: could you do the copy in the postActivation script?
<pikajude>
hm uh
<pikajude>
okay gonna be honest i had no idea that existed
<pikajude>
yeah it's worth trying
<dhess>
that's where I do my "stateful" stuff like copying ssh keys etc.
<pikajude>
oh, genius
<pikajude>
i wish i had thought of or known about this option a long time ago
<pikajude>
but yeah, that's exactly what was needed
<dhess>
cool
<LnL>
yeah you can add custom activation stuff at some points, but ideally you shouldn't need it ofcorse
<pikajude>
nah i mean
<pikajude>
it's dash's fault that it follows symlinks anyway
<pikajude>
or it might even be macOS
<ldlework>
LnL I don't know if you've looked at John's config all that much or if you know anything about home-manager, but do you understand how he's adding his overlay packages?