-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uclibc: Bump and clean #40268
uclibc: Bump and clean #40268
Conversation
Failure on aarch64-linux (full log) Attempted: uclibc The following builds were skipped because they don't evaluate on aarch64-linux: xbursttools Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: uclibc The following builds were skipped because they don't evaluate on aarch64-linux: xbursttools Partial log (click to expand)
|
Failure on x86_64-darwin (full log) Attempted: xbursttools The following builds were skipped because they don't evaluate on x86_64-darwin: uclibc Partial log (click to expand)
|
Failure on x86_64-darwin (full log) Attempted: xbursttools The following builds were skipped because they don't evaluate on x86_64-darwin: uclibc Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: uclibc, xbursttools Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: uclibc, xbursttools Partial log (click to expand)
|
Um, will this now mean we will now start to expect a ton of per-package patches to fix compilation on uclibc? Why do we need both uclibc and musl anyway? And given that @edolstra previously explicitly requested an RFC for these sort of things (like the musl support athttps://github.com/NixOS/rfcs/pull/23) why is this now just going straight in? |
We already had it. It was just bitrotted, and so I cleaned it up because it was making other refactors harder, and I frankly I was tired at looking at the old code. If you are someone else want's to remove uclibc altogether, I have no problem with that.
What do you mean? Even if I did plan to actually support uclibc (not merely make it presentable for someone else to maintain or remove), the MUSL people (of which I am not one) have, in line with there promise, not dumped musl-only patches everywhere so I would hold myself to the same standard. Does the MUSL work not look that way to you? |
If something has bitrotted to the point of not even building anymore, and nobody has noticed it, then the right thing is to remove it. Again, d0e25d8 almost 2 years ago dropped all of the mips builds because they had been already long broken then. xbursttools should have already been removed back then.
As of current |
That is great precedent. I especially wouldn't mind getting rid of xburstutils as importing nixpkgs from all-packages.nix (which it does) is very bad.
Actually through things like #37056 the hope is at least the patches could be unconditional. And again, if you want to just remove uclibc, I have no problem with that. In fact, it's nice that since it was cleaned up before removal, if anyone wants (and can justify) adding it back, there's a good starting point to work from. |
Motivation for this change
Well it does builds on
x86_64
, but nobody would use it there anyways.Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)