We will not remove packages that are useful on 64 bits systems such as Steam or Wine, they will be cached and usable, they will be automatically built as always.
We will not remove any package actively from nixpkgs regarding i686 before discussing more about what we want to do on the tier support of i686 and where does the community stand. Though, the sad state of affairs today is there’s very few i686 maintainers able to respond to CI breakages in time and i686 is a churn on the current build resources.
To summarize again:
The cache for i686 will be reduced and if you depend on i686 NixOS, you will end up recompiling more, consider setting up your own Hydra instance and your own cache, potentially with other fellow i686 users.
Packages necessary for usual 64 bits operation are not affected as they will be pulled transitively by Hydra for x86_64, e.g. Steam, Wine, etc.
What should I do if I want i686 back?
Please reach out here or over Matrix in the staging channel or development channel to discuss your plan on how to maintain i686.
It will take some time to land all the relevant PRs, it will take effect in unstable in the next days/weeks and starting 24.05.
I do understand this might pose challenges for some users who used NixOS because of its i686 friendliness among the rare distributions that supports it, unfortunately, things have a cost and i686 maintenance burden has always been non-trivial for the past years. We recommend starting a “focused” community cache of core packages for i686 if you are affected by this change and proposing it to the community. I believe that our primary focus in nixpkgs should be on actively used and popular architectures.
I don’t know if there was some long-winded discussion around this decision, but by reading this post and the linked github issue, it looks like you single-handedly removed the platform support with a 5 days notice.
Regardless of what your opinion on i686 is (personally I don’t mind about i686 kernels and such), this looks seriously bad because it shows that NixOS support is completely unreliable.
While, as an end user, this change doesn’t affect me at all, I agree that this should’ve been mentioned in a more publicly accessible manner with a decent notice period. The PR is in nixpkgs which, among 5000+ others, would definitely not be something that gains attraction.
I should add that i686 test failures have been basically always ignored by contributors in the past couple of years, so they didn’t seem useful or wanted.
I don’t know, it has been multiple releases that i686 has been a regular pain for contributors, when we called for help, it didn’t seem a lot of folks were there to help fix it.
The discussion is here, the support was removed for now because it cost CI and energy from people who are working to make things work, if someone come and say: hey, I really care about i686 and am willing to assemble a team to maintain it and make it work for everyone involved ; that’d be awesome, and we could discuss to reinstate it or give a meaning to “NixOS on i686” out of tree if needed.
What looks seriously bad to me, personally, is that we have been wasting money and energy on a platform that a likely very small group cares about when we could have rerouted those means towards other goals that benefit more people.
BTW, there’s no special opinion to have on i686, LWN has been covering the state of i686 and 32 bits Linux for a while: 32-Bit x86 support in Fedora [LWN.net] and more.
NixOS’s support of popular architectures (and it’s a broad popular) is there and is continuously developed.
the argument wasn’t “i686 is easy and pleasant to maintain,” nor “I wanted to maintain i686 but you’re stopping me,” nor “a lot of people still use i686,” nor “you can’t do this because no other distro is doing it,” nor “people working on Nix owe it to me to continue maintaining i686.”
it was “ouch, this is short notice.”
clarification: I care about having a binary software distribution for i686, although I currently don’t use Nix on it. carry on
