| 27 May 2021 |
abathur | treating sudo as a ~builtin is on the table, but
- I don't think it is a given that every system will have sudo (and it is roughly not-the-resholve-way to let a script through without erroring when dependencies are missing)
- unless I invent a new "type" of resolution context for sudo, treating it as a builtin has some edge-case impacts on resolving arguments to sudo (anything that matches the name of a builtin will get treated as a builtin instead of an external); I haven't entertained this too deeply and TBH I'm not even that sure what the independent versions of commands that match up with builtins look like
| 02:02:55 |
abathur | I'm still pretty unsure about the true solution, but re: kicking the can--I'm starting to lean towards putting in a hard check and error for sudo when NIX_BUILD_TOP is in the environment that points users to an issue | 02:07:48 |
abathur | but technically there are a number of other things I should be treating the same way | 02:08:15 |
emily | well, you can't ever use a sudo "other" than the system's one | 02:37:31 |
emily | since any customization of it to be another nix package would be non-suid | 02:37:38 |
emily | and need wrapping (which can only happen through some sort of admin-approved system config) | 02:37:46 |
emily | so I don't see where else you could find it but PATH or unportable NixOS-specific/macOS-specific paths | 02:37:59 |
emily | but yeah I don't think it should be treated as a builtin per se, but just something explicitly marked to be late-bound and not rewritten | 02:38:19 |
abathur | not sure if this is hair-splitting in this context, but resholve is doing a kind of PATH search (at build/resolve time)--it's just forcing the user to explicitly specify that PATH so that everything is explicit and not implicit | 02:43:29 |
abathur | so maybe another way of framing the problem is that Nix doesn't have a ~grammar for expressing that dependency, and resholve is at Nix's mercy inside the build sandbox | 02:44:27 |
abathur | but at least at the CLI level, it's valid (if ~missing the point?) to do something like resholve --inputs "$PATH" ... | 02:49:04 |
abathur | it isn't implemented yet, but I have considered supporting specifying each executable abspath, since it would support specifying /usr/bin/sudo without having to specify /usr/bin | 02:52:25 |
abathur | though there's still the question of resholve not being able to verify that the file exists through the sandbox | 02:59:34 |
| edwlan joined the room. | 03:20:40 |
edwlan | I'm currently building with a checkout of nixpkgs from GitHub on the branch staging-next.
$ nix-build --argstr system aarch64-darwin -I nixpkgs=$PWD -A emacs
...
checking AppKit/AppKit.h usability... no
checking AppKit/AppKit.h presence... yes
configure: WARNING: AppKit/AppKit.h: present but cannot be compiled
configure: WARNING: AppKit/AppKit.h: check for missing prerequisite headers?
configure: WARNING: AppKit/AppKit.h: see the Autoconf documentation
configure: WARNING: AppKit/AppKit.h: section "Present But Cannot Be Compiled"
configure: WARNING: AppKit/AppKit.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-gnu-emacs@gnu.org ##
configure: WARNING: ## ------------------------------------ ##
checking for AppKit/AppKit.h... no
configure: error: The include files (AppKit/AppKit.h etc) that
are required for a Nextstep build are missing or cannot be compiled.
Either fix this, or re-configure with the option '--without-ns'.
| 03:21:56 |
edwlan | * I'm currently building with a checkout of nixpkgs from GitHub on the branch staging-next. I realize this is "unsupported", but are there any pointers to getting this working?
$ nix-build --argstr system aarch64-darwin -I nixpkgs=$PWD -A emacs
...
checking AppKit/AppKit.h usability... no
checking AppKit/AppKit.h presence... yes
configure: WARNING: AppKit/AppKit.h: present but cannot be compiled
configure: WARNING: AppKit/AppKit.h: check for missing prerequisite headers?
configure: WARNING: AppKit/AppKit.h: see the Autoconf documentation
configure: WARNING: AppKit/AppKit.h: section "Present But Cannot Be Compiled"
configure: WARNING: AppKit/AppKit.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-gnu-emacs@gnu.org ##
configure: WARNING: ## ------------------------------------ ##
checking for AppKit/AppKit.h... no
configure: error: The include files (AppKit/AppKit.h etc) that
are required for a Nextstep build are missing or cannot be compiled.
Either fix this, or re-configure with the option '--without-ns'.
| 03:22:20 |
Sandro | In reply to @edwlan:m.edw.ai
I'm currently building with a checkout of nixpkgs from GitHub on the branch staging-next. I realize this is "unsupported", but are there any pointers to getting this working?
$ nix-build --argstr system aarch64-darwin -I nixpkgs=$PWD -A emacs
...
checking AppKit/AppKit.h usability... no
checking AppKit/AppKit.h presence... yes
configure: WARNING: AppKit/AppKit.h: present but cannot be compiled
configure: WARNING: AppKit/AppKit.h: check for missing prerequisite headers?
configure: WARNING: AppKit/AppKit.h: see the Autoconf documentation
configure: WARNING: AppKit/AppKit.h: section "Present But Cannot Be Compiled"
configure: WARNING: AppKit/AppKit.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-gnu-emacs@gnu.org ##
configure: WARNING: ## ------------------------------------ ##
checking for AppKit/AppKit.h... no
configure: error: The include files (AppKit/AppKit.h etc) that
are required for a Nextstep build are missing or cannot be compiled.
Either fix this, or re-configure with the option '--without-ns'.
missing darwin.sdk.app_frameworks.AppKit IIRC | 03:22:32 |
edwlan | (sorry M1, is additional relevant context) | 03:22:47 |
edwlan | Thanks Sandro: | 03:22:54 |
Sandro | In reply to @edwlan:m.edw.ai
I'm currently building with a checkout of nixpkgs from GitHub on the branch staging-next. I realize this is "unsupported", but are there any pointers to getting this working?
$ nix-build --argstr system aarch64-darwin -I nixpkgs=$PWD -A emacs
...
checking AppKit/AppKit.h usability... no
checking AppKit/AppKit.h presence... yes
configure: WARNING: AppKit/AppKit.h: present but cannot be compiled
configure: WARNING: AppKit/AppKit.h: check for missing prerequisite headers?
configure: WARNING: AppKit/AppKit.h: see the Autoconf documentation
configure: WARNING: AppKit/AppKit.h: section "Present But Cannot Be Compiled"
configure: WARNING: AppKit/AppKit.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-gnu-emacs@gnu.org ##
configure: WARNING: ## ------------------------------------ ##
checking for AppKit/AppKit.h... no
configure: error: The include files (AppKit/AppKit.h etc) that
are required for a Nextstep build are missing or cannot be compiled.
Either fix this, or re-configure with the option '--without-ns'.
* missing darwin.apple_sdk.frameworks.AppKit IIRC | 03:23:24 |
Sandro | correct the name | 03:23:30 |
edwlan | Just add that as a buildInput? | 03:23:37 |
Sandro | maybe. Didn't test | 03:23:47 |
edwlan | I can poke around, thanks for the hint | 03:24:40 |
| fiddlerwoaroof joined the room. | 04:15:24 |
edwlan | So, it looks to me like that's already being passed into the emacs derivation correctly. | 04:19:16 |
edwlan | https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L23190-L23199 | 04:20:08 |
edwlan | * https://github.com/NixOS/nixpkgs/blob/staging-next/pkgs/top-level/all-packages.nix#L23190-L23199 | 04:20:21 |
thefloweringash | I started looking at emacs on m1, it needs at least this: https://github.com/thefloweringash/nixpkgs/commit/01f995a5bcbe9bd414e19abc2c570a7cb73c9af1 | 04:33:16 |
thefloweringash | I didn't look at appkit yet, but I wouldn't be surprised if the problem was in the framework structure | 04:34:09 |