* buildBazelPackage: autodetect nix toolchain instead of Xcode on Darwin
* do not export the variables outside of Darwin
* remove unecessary parens
* move comment within the darwin check
This adds LANG aliases for each dictionary. This makes things a little
easier and expected. For instance, you get an error message from
hunspell like:
Can't open affix or dictionary files for dictionary named "en_US".
and you can resolve it by running
nix-env -iA nixpkgs.hunspellDicts.en_US
The default for logFile is /var/log/couchdb.log, and the tmpfile rules chown
${dirOf cfg.logFile}, which is just /var/log, to couchdb:couchdb.
This was found by Edes' report on IRC, which looked like
Detected unsafe path transition /var/log → /var/log/journal during canonicalization of /var/log/journal
While this bug has been present since the initial couchdb module in
62438c09f7cc811f994510550614c9265b3b1d18 by @garbas, this wasn't a
problem, because the initial module only created and chowned /var/log
if it didn't exist yet, which can't occur because this gets created in
the initial phases of NixOS startup.
However with the recent move from manual preStart chown scripts to
systemd.tmpfiles.rules in 062efe018d571b1daa9c37b8c99eb39ad47d7342 (#59389),
this chown is suddenly running unconditionally at every system
activation, therefore triggering the above error.
The only difference between these forms is the return value when
"$NIX_LISP_SKIP_CODE" is the empty string. In the original
formulation, the script would return a false exit status. In the new
formulation, it will return a true exit status.
Its useful to be able to source cl-wrapper.sh (to get the variables it
establishes), and its a bit annoying that sourcing it with
NIX_LISP_SKIP_CODE=1 results in a false exit status.
The CCL package installs a symlink named "ccl" that points at the
actual implementation executable: lx86cl64 (or lx86cl for 32 bit).
When clwrapper is used with CCL as the backing implementation, this
script fails to recognize the implementation. By resolving the
symlink, we are able to recognize which implementation we're actually
working with.
