Not sure if you've seen it yet @Ericson2314 but each ofborg run now comes with an evaluation performance report: https://github.com/NixOS/nixpkgs/pull/60166/checks?check_run_id=109946398 since you do some pretty core stuff, I think this report is especially relevant to you. Check it out?

not saying your changes here need rethinking due to the results, just keep it in mind and check it out when submitting changes to see how it impacts evaluation

I hope not. I chose not to make any labels or value judgement around the results of the performance report, specifically to avoid pushing people to write ugly code to make the mark go away.

For make-derivation it's pretty important to look at performance. optionalAttrs is best to avoid as much as possible here. Nix has to evaluate those checks every timne.

@grahamc thanks for the heads up! I errored on the side of smaller derivations but more //. nrOpUpdates makes me look like I made a bad choice, and per @volth's point more null is actually the cleaner code anyways, so I'll gladly remove my premature optimization.

Cool! No worries, I hadn't even looked at your PR, or the result of the performance report ;) thank you!

@volth Hmm does that mean everything all the way down is screwed up, or I just need to cherry-pick your perl fix? Perl doesn't use autoconf so I wouldn't expect build_alias and friends to work.

I thought I used your PR's base-branch. Maybe I need to use something else to get a) the right perl version, b) your and @matthewbauer's -m flags?

Also, is there a way to turn of the x86_32 hacks in Nix so I can decently repo building i686-linux?

OK I'll see why stdenv is screwed up.

x86_64 python did build correctly, so the bootstrap tools referece does seem to be an aarch32-specific (or alt-mode-specific) problem.

He can request access any time he'd like :) https://github.com/nix-community/aarch64-build-box#want-access

@grahamc I read the README and now I'm properly scared :)

What do you all think we merge this cause it's a step in the right direction?

@volth you saying this is worse than 19.03? I figured it was better, just not sufficient to fix aarch32.

I read the README and now I'm properly scared :)

Nothing to be really scared about, just a warning not to (mis)place any trust in the community box. I can highly recommend using it for stuff like this though! Hell, I've used it for non-aarch64-specific stuff as well just because of the oomph it has :)

What do you all think we merge this cause it's a step in the right direction?

I'm generally in favour. My main remaining concern is whether the *_alias env vars are actually a documented/supported interface in autotools and if they won't break behind our backs with some new autotools release. It's not a major issue though, since that's only a hypothetical situation, we can fix it by reverting this change, and I don't think it's that likely to happen.

This needs much more testing IMO

https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Canonicalizing.html this is the documentation for *_alias. It does mention the read direction, but not the write direction.

@matthewbauer That's not a very helpful comment. What sort of testing is missing in your view? It's targeted at staging, where hydra will (once the PR is merged) rebuild everything including the nixos tests. If that's not good enough for you, please be more specific about what you think we need in addition.

When building armv7l on an aarch64 machine, I'm getting

builder for '/nix/store/s4n4a9s9zg0m2v2239zfay713rwkw09q-expand-response-params.drv' failed with exit code 1; last 9 log lines:
  unpacking sources
  patching sources
  configuring
  no configure script, doing nothing
  building
  Assembler messages:
  Error: unknown architecture `armv7-a'

  Error: unrecognized option -march=armv7-a
builder for '/nix/store/9v1pkwrhfwhg6wvgr3ka9krw04caikpd-patchelf-0.9.drv' failed with exit code 77; last 10 log lines:
  checking for a thread-safe mkdir -p... /nix/store/65sxp86ypi3ca914pq069blazwq9qzr1-bootstrap-tools/bin/mkdir -p
  checking for gawk... gawk
  checking whether make sets $(MAKE)... yes
  checking whether make supports nested variables... yes
  checking for style of include used by make... GNU
  checking for gcc... gcc
  checking whether the C compiler works... no
  configure: error: in `/build/patchelf-0.9':
  configure: error: C compiler cannot create executables
  See `config.log' for more details
cannot build derivation '/nix/store/jmsghzfyy114fsxpy046jmpb1nwz52x2-bootstrap-stage3-stdenv-linux.drv': 1 dependencies couldn't be
built

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

@yorickvP's error isn't a regression AFAIK since I guess builds didn't even get that far when natively building armv7 software on aarch64. Is there anything besides the merge conflicts that prevents this from being merged?

I marked this as stale due to inactivity. → More info

Rebased #240637