addresses https://github.com/LnL7/nix-darwin/issues/1043
fix: use exec in launchd daemon config
fix: dont use a script thats in the nix store
fix: remove manual wait4path in linux-builder
fix: remove manual wait4path in karabiner elements
fix: remove manual wait4path in nix-daemon
fix: remove manual wait4path in nix-optimise
fix: remove manual wait4path in tailscaled
fix: autossh test
Revert "fix: remove manual wait4path in nix-daemon"
This reverts commit 6aec084fa5.
fix: remove bad exec
Reapply "fix: remove manual wait4path in nix-daemon"
This reverts commit c8f136ecc5.
fix: update autossh test
to reflect changes in f86e6133d9
fix: services-activate-system-changed-label-prefix test
fix: services-buildkite-agent test
fix: services-activate-system test
fix: escape ampersand
fix: services-lorri test
fix: services-nix-optimise test
fix: services-nix-gc test
refactor: use script rather than command in daemon
fix: use config.command for clarity
style: fix indentation
fix: use lib.getExe rather than directly pointing to file
revert: a87fc7bbbb
- mistaken refactor meant that service waited for nix store and not the relevant path
This is hopefully largely cosmetic, but should increase user
confidence in the safety and effectiveness of the migration, and the
Determinate Systems and Lix installer commands will also update the
`/nix/receipt.json` files to match the changes made. They cannot
properly handle the format of each other’s receipts, so we need to
detect which was used.
The condition does not match the comment, and therefore not the original
intention. It currently returns early in *any* type of Nix shell, not
just pure ones, including 'nix develop'.
Besides being unnecessary, this check prevents Nix shells from
functioning properly. For instance, it causes the initialization of the
Zsh fpath to be skipped, which is critical. The fact that the user is
unable to opt out of this behaviour makes this an ever bigger problem
since /etc/zshenv is being loaded unconditionally by Zsh.
For reference, NixOS does not perform such check, and apparently never
did.
When testing the Sequoia UID change, I discovered that @mjm
didn’t have `system.stateVersion` set; I suspect this is not too
uncommon. Let’s make it required now, like NixOS is trying to,
to improve our backwards‐compatibility story in anticipation of
starting to cut release branches.
When a script specifies the shell option "nounset" as part of the
shebang (e.g., via "#!/usr/bin/env -S zsh -u"), our initialization
scripts would produce error messages of the form:
__ETC_FOO_SOURCED: parameter not set
These messages could probably be confusing to users when running such
scripts. By providing a fall-back in the parameter expansion, we can
avoid them.
This patch does not address interactive shell start-up, where such
messages may (or may not) be less problematic.
NixOS/nixpkgs@7d84dbdf5b
Currently zshenv by default only sets fpath without exporting it. A
parent shell would also not set those variables usually as they are
shell local.
It also sources a file called set-environment but this is protected by
an environment variable called __NIX_DARWIN_SET_ENVIRONMENT_DONE. Hence
any modification done by the parent shell should persist as long as
__NIX_DARWIN_SET_ENVIRONMENT_DONE is not unset.
This behavior deviates from what we do in bashrc and breaks common
setups such as tmux/mosh or screen.
NixOS/nixpkgs@55819e6c86
Currently there are a bunch of really wacky hacks required to get
nixpkgs path correctly set up under flake configs such that `nix run
nixpkgs#hello` and `nix run -f '<nixpkgs>' hello` hit the nixpkgs that
the system was built with. In particular you have to use specialArgs or
an anonymous module, and everyone has to include this hack in their own
configs.
We can do this for users automatically.
NixOS/nixpkgs@e456032add
Co-authored-by: Antoine Cotten <hello@acotten.com>
