Staging next #97146
Staging next #97146
Conversation
This came up in #96008. Without this patch modinfo always prints the module name for builtin modules, even if an explicit --field is passed.
The default `strip` invocation tries to strip global symbols from the library, and refuses because those are indirect symbol table references.
The latter doesn't exist on Darwin (and, presumably, other targets as well). This change allows emacsGcc from emacs-overlay to attempt to build where previously, the derivation would error out.
|
I saw around 50k jobs "Cancelled by user" but I found no indication why (some other work for Hydra, newer staging-next commits, a comment somewhere), so I restarted them. Over years I've seen multiple instances of this status getting created without manual interaction, so perhaps it was one of those. |
|
I just noticed it as well, but I think it may be @jtojnar who cancelled them because of the fontconfig change that was merged after the evaluation. I started a new evaluation because of that. |
|
Ah, so I assume that new evaluation was there already (7h ago) but noone restarted the jobs shared by the two of them (until now). |
|
Right, I forgot that as well when I created a new eval. |
|
Sorry, did not notice this PR. Yeah, I cancelled the builds and triggered a new eval (mentioned on |
|
For reference, there's a handy "restart aborted" button which won't restart builds that have been attempted and failed. |
|
Darwin-stdenv does not build #95910 (comment) because of texinfo change. Proposed revert #97218. |
We apparently didn't fit anymore. I don't think this test is meant to (also) check closure size. Note: as of this commit, the test is blocked by a fontconfig problem, so I tested with that merge temporarily reverted.
It's basically a partial revert of PR #95910. I chose a temporar-ish solution, maximizing likelihood of fixing this while minimizing rebuilds. (20.09 process is being blocked)
|
I can't seem to be able to find it on Hydra but FWIW building I ran a bisect which pointed to #93560 but I don't really understand the changes (or know anything about Darwin) to know how to fix it (other than reverting those changes completely). EDIT: oops, page didn't refresh so I didn't see vcunat's comment. |
If reverting that change makes darwin build again, then that's good enough at this point. Please confirm you're able to build |
|
Yes, I reverted the change locally and |
|
Can confirm Darwin |
It builds as well with the revert. |
|
Thanks for testing. Ugly work-around reverting the PR for Darwin #97296. |
Temporary fix. We definitely do not want to have two separate implementations.
|
@FRidh It looks like we may need to apply your to change to cc-wrapper as well at least (there is a fortran wrapper too I think but not sure how important that is), currently |
|
Haskell boostrap on aarch64 is broken. I can't see any relevant change (since master where it works), and I can reproduce the segfault on the shared box. EDIT: I opened #97407 Still, I don't think we should block merge to master because of this, in our situation. |
There was a problem hiding this comment.
After a few thousand rebuilt darwin packages, I believe we're good enough to merge... at least in our dire situation.
|
The tested job succeeded on Hydra 🎉 Thanks to everyone who's helped; this staging iteration wasn't easy at all. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/marketing-team-can-we-present-nix-nixos-better/6249/106 |
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)