veprbl
commented
3 years ago Just want to mention that Qt 5.15 builds on Hydra right now, it's only qt515.qtwebengine that is not trivial to get running with 10.12 SDK.
Open toonn opened 3 years ago
veprbl
commented
3 years ago Just want to mention that Qt 5.15 builds on Hydra right now, it's only qt515.qtwebengine that is not trivial to get running with 10.12 SDK.
tricktron
commented
3 years ago Building with sandbox true seems to be broken on Big Sur https://github.com/NixOS/nix/issues/4658
toonn
commented
3 years ago 
emilazy
commented
3 years ago Another factor in this decision are the Hydra build machines. There are currently 9 Intel Mac Minis, NixOS/nixos-foundation#5, and 6 Apple Silicon Mac Minis, #95903. All but the oldest support the latest version of macOS. All of them support 10.15 Catalina.
I believe M1 Macs support only Big Sur.
happysalada
commented
3 years ago Another minor thing that is broken because of this is zig see PR (it's probably not a priority but just adding it here for consideration)
Regarding Apple SDK Personally I would vote for the functional approach that you mentioned. Packaging every version of the sdk and letting every package define the minimum version they require. The only problem I see with that approach would be potentially for Big Sur users, if they need to override every package they install to define the sdk they need, it could quickly get tedious. I think the main thing that will decide this is, do we know what the impact on the hydra builds this would have? Would this be possible or is it something that would not get feasible past a certain number of package?
nixos-discourse
commented
3 years ago This issue has been mentioned on NixOS Discourse. There might be relevant details there:
clord
commented
3 years ago I hit an issue on an m1 and my intel BigSur machine relating to dylibs not found. I commented with my findings on the issue for this here: https://github.com/NixOS/nixpkgs/issues/80177
tricktron
commented
3 years ago Does anybody know what broke darwin.network_cmds, see Issue https://github.com/NixOS/nixpkgs/issues/118195?
This is needed for this pr https://github.com/NixOS/nixpkgs/pull/106465 and possibly related to https://github.com/NixOS/nixpkgs/issues/119866.
ipetkov
commented
3 years ago Copying my earlier comment I think 54c7a0f42287f63c2db8086a8ad46ac981364378 is the culprit. Looks like there's already a PR to fix this: #121527
nixos-discourse
commented
2 years ago This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/missing-go-1-17-on-x86-64-darwin/15032/3
CMCDragonkai
commented
2 years ago It would be nice if there was a quick explainer of how to potentially integrate Nix into a MacOS VM that is acting as the CI runner. Mac OS runners are appearing in gitlab and github and more. However the current installer script requires sudo, and there's no information about how to make it completely unattended (unless I go into the script and look at the code).
https://docs.gitlab.com/ee/ci/runners/saas/macos/environment.html
CMCDragonkai
commented
2 years ago The nixpkgs manual itself has an ios section, but there's no equivalent section to building GUI apps. The ios section says that it has to "symlink" to the natively installed XCode. It would be nice to explain this in more detail.
MichaelVoelkel
commented
1 year ago This is from May, any updates? I tried to nix-shell -p qt6.qtbase and got that it is not supported for darwin-aarch64. With export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1, I got that package valgrind-3.19.0 is even broken. I stopped there. I would love to switch to Nix (would also love to shift our company into that direction) but this is prohibitive :/ Maybe some way to build it manually? (found almost nothing about this via Google)
arximboldi
commented
1 year ago @MichaelVoelkel I created a ticket to track that one specifically: https://github.com/NixOS/nixpkgs/issues/188938
Status of macOS support in Nixpkgs
Most of this information is based on the Nix :heart: macOS Open Collective wishlist and the Darwin maintainer tracking project.
Apple SDK update
Current stdenv uses Apple SDK version 10.12. This means binaries built by Nix and cached in the official binary cache run on all versions of macOS since 10.12. Updating the version of the Apple SDK used in the darwin stdenv means dropping support for any Apple hardware that cannot be upgraded to the corresponding version of macOS.
Issue #101229 makes it clear that updating the SDK is becoming a pressing concern. Some important packages require a version newer than the oldest supported by Apple, like CPython #105038 and Qt WebEngine 5.15 (Qt 5.12 will be EOL in December 2021 so we want to move to Qt 5.15), both requiring 10.15. In issue #86299 the required version is 10.13.
Some work has already been done to ease the transition to a newer SDK. Basing stdenv on Text API, which is unavoidable as of 11.0 Big Sur, in #98541. And making it possible/easy to update packages in apple_source_releases individually, in #108590.
Another factor in this decision are the Hydra build machines. There are currently 9 Intel Mac Minis, NixOS/nixos-foundation#5, and 6 Apple Silicon Mac Minis, #95903. All but the oldest support the latest version of macOS. The oldest Mini supports up to 10.15 Catalina. (OfBorg has recently gotten much needed expansion of hardware to help maintainers verify Darwin fixes. There's five extra Darwin builders NixOS/nixos-org-configurations#179.)
What is the way forward? Do we package every SDK version and then default to the oldest supported but make it possible for packages to specify the minimum version they require? Do we focus on source releases instead, to limit the reliance on the SDK?
:white_check_mark: Installation tutorial
Due to changes in Catalina which locked down the filesystem root, mounting it read-only, installation has gotten less straightforward. It currently requires a separate non-encrypted APFS volume, as of NixOS/nix#3212.
I will go through the installation process and write up a detailed tutorial to minimize friction for new users. Including setting up nix-darwin and home-manager. This will probably simply repeat information that's already out there in various blog posts but in more detail, potentially going over alternatives. I have a draft in a Gist. Installation's actually a fairly simple process so the uninstalling information is the biggest contribution.
Is there other documentation that is known to be missing or in need of improvement?
:white_check_mark: Bootstrappable stdenv on Big Sur
With the Text API stdenv builds on Big Sur are possible but during the bootstrap it still requires linking to an actual libSystem. This means the stdenv was only usable on Big Sur as long as a bootstrap was generated on Catalina or earlier. This issue is described in #104580 but should be fixed by #107013.
:white_check_mark: Apple Silicon Support
The next big hurdle is support for the new Apple Silicon (aarch64) CPU architecture. Several M1 Mac Minis are already available for CI, #95903.
Work towards this has been merged in #105026, with accompanying Hydra jobset for detailed progress on which and how many packages build succesfully. The merge happened in time to make it into the 21.05 release! 🎉
Sandbox support
While NixOS sandboxing works well on Linux, on macOS it has been plagued by problems for a long time, NixOS/nix#1821. Among other things the limitations of macOS's sandboxing framework as compared to Linux make it difficult to achieve the same degree of sandboxing. Recently confirmed broken in NixOS/nix#4658. Currently only one blocker is identified for this, namely NixOS/nix#4119, the sandbox files that are generated have too many rules, splitting them up and importing seems like a potential fix.
Is perfect the enemy of good enough here? Can we gradually introduce sandboxing on macOS, incrementally tightening down on the simplest measure to take next? Or do we need a thorough design from the ground up, which may result in a different approach to sandboxing from NixOS?
Runnable NixOS tests
Making it possible to interactively run NixOS VMs on macOS has an unexpected advantage, #108984. Linux runners on CI providers like Circle CI and GitHub Actions cannot use KVM so NixOS tests are slow to run. Their macOS runners otoh do have access to macOS's KVM alternative, so running NixOS test VMs on macOS CI runners could provide a nice speedup. There is now a working prototype by @r2r-dev. Qemu is starting to rely on newer SDK versions which could mean this gets blocked on x86_64 Darwin until we can bump the SDK to 10.14.
:white_check_mark: Installer improvements
Current work to enable the installer to encrypt the Nix store volume if FileVault is enabled is complete, merged in NixOS/nix#4289. This PR and changes that have been previously merged will probably fix zsh-specific compatibility issues that have cropped up.
@abathur also mentioned it might be possible to have the installer check a user's shell rc files for things that may cause issues, the use of absolute paths posed a problem for someone during install. And that these changes will make an uninstaller feasible. The changes include detecting and fixing problems with volume state, think permissions or whether the volume is encrypted if FileVault is enabled (potentially after installing Nix). This goes most of the way towards making the installer idempotent and an uninstaller would mostly deal with the same things.
An apt summary of the work in this PR by abathur, "The goal is to remove any macOS-specific asterisks on the install step for Nix." Uninstallation and reinstallation should be easy, the former should lower the barrier to trying out nix and the latter allows for people to start over, taking away the stress of getting everything right the first time.
Nix 2.4 has been released and includes the work by abathur.
Are there other missing features or problems with the installation procedure?
Uninstall and Reinstall
Supporting re-running the installer and being able to easily remove Nix would be a large quality of life improvement for new users who may be hesitant to give Nix a shot because they don't want to mess up their system or because an earlier installation attempt went awry. This discourse thread has more details.
Support headless setups (VMs/EC2)
Some users have run into problems with headless setups, like in well documented issue NixOS/nix#4640. The only workaround so far involves getting a remote desktop session going and granting FDA permissions to
/bin/sh, which the Nix daemon inherits, through the GUI and giving the account that needs to mount the Nix Store APFS volume a SecureToken.Ruby across Darwin versions
NixOS/Nixpkgs#160103 highlights a problem with the current infrastructure for Ruby. The platform identifier ends up in the interpreter binary and causes it to refuse to run after a system update. Ruby should be rebuilt when this happens, as if the system it runs on is an input to the expression.
CC @NixOS/darwin-maintainers
Last updated: 2021-12-07