@shlevy, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra and @peti to be potential reviewers.

@shlevy, @Mic92 : I am a bit annoyed about this PR. There has been work pending on this for some time, where the biggest difficulty was that it was not recommended to silence errors.
This just ignores errors from strip. I know that strip has inconsistent return values, but strip ... 2>/dev/null || true is too radical in a build. We need to detect OOM errors and such, which is done by parsing error messages, not ignoring them.
Please see #15087 and it's follow-up #15339.

@layus It's not possible for someone to know all of the pending work going on in nixpkgs. This fixes a real need (I have been asked about this by concerned users worried that their build failed 4 separate times in the three weeks I've been at my latest job, for example) and if/when #15339 is merged it can overwrite this change.

Are there any real cases of builds that OOM that would not have been detected if it weren't for the barrage of otherwise meaningless errors from the fixup phase?

Would be nice if github showed you other PRs that your PR would introduce merge conflicts for though.

@shlevy I understand the need for this change, and I even agree with the fix, until something better can be found. I tried to merge exactly the same patch several months ago, but it was refused for the reason cited above. Hence the more complex PR.

Are there any real cases of builds that OOM that would not have been detected if it weren't for the barrage of otherwise meaningless errors from the fixup phase?

See #5447

Would be nice if github showed you other PRs that your PR would introduce merge conflicts for though.

Yes, definitely.

I know this is the wrong place to rant about the ecosystem, as you are obviously not responsible for this situation. Seeing this being (auto) accepted so easily was a bit frustrating, knowing how much time I spent in the other alternative

Anyway, thanks for the improvement. This was badly needed.