-
Notifications
You must be signed in to change notification settings - Fork 108
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
flake: nixos -> nixos-unstable #192
Conversation
Is it possible to drop the patched-nixpkgs now? That would allow for proper multi-arch checks. |
failed derivations caused by:
which causes pretty much everything else to fail, since this is the only failing test, perhaps disabling tests on nixFlakes would be easiest solution. I'm gonna see if a subsequent patch will resolve it, but I suspect the patch will cause the hash to diverge again. |
I've seen that a few days ago. 😄 |
bors try |
tryBuild failed: |
UpdateAs a workaround, I'm currently building I tried adding Even more disturbingly, I cannot reproduce the error locally. |
I'm getting this error while running `nix flake check` on this branch
Full log: https://termbin.com/wurt |
I wonder if its because of this: |
Also I don't understand the point of your custom patch? Whats wrong with just adding the experimental features in nix.conf? |
I understand how you feel. The main motivation was to avoid junk in the ci logs. I was wondering if there was a way to override global nix.conf with a user level nix.conf to remove the experimental-features line, accomplishing the same thing, but I don't think that ability exists, from what I could gather. I may just have to remove it for now and deal with the junk. Although, now that I think about it. Perhaps we could run hercules in a container with a different |
Got it, I assumed it had something to do with the ci, that makes sense. Thanks for clarifying. It is rather annoying to rebuild nix, but I understand if it helps with maintenance in any way. |
I had originally assumed their would be a way to set log level in nix.conf. Unless my grepping skills are lacking, I couldn't find one. |
I think dropping the custom patch might be the best way to move this forward. regular nixUnstable builds ok. |
I am attempting to get that together right now, but it reintroduced an old issue. I'd rather not resort to a shell script wrapper for nix, but it looks like that'll have to suffice, unless numtide/devshell#106 |
interestingly, removing the patch didn't even resolve the build failures, so something else must still be going on. Nothing I've tried has any affect. I'll probably have to file an issue upstream on this as perhaps the difference in the client and daemon is just too great. Even when trying to keep the agent on a stable release channel, it doesn't want to build any derivations from this update. |
How come nix2.4 is still being rebuilt? Shouldn't it be pulled from the cache now if there are no custom patches? It seems to have built correctly in hydra: https://hydra.nixos.org/job/nixpkgs/trunk/nixUnstable.x86_64-linux and it gets pulled from the cache with |
If I pull nixUnstable from the nixos flake by dropping the nix overlay in extern, |
Well I took your advice but ci is still failing as before. |
I can't reproduce locally this time either. nix flake check now passes for me on this branch.. |
What happens if you update everything(including daemon) to nixUnstable like before? perhaps the previous issue you had with the ci was also because of the custom patch. |
bors try |
tryBuild failed: |
bors try |
YAY!! I'm glad it worked. So this means the cli will be unstable while the nix daemon will be stable right? I think thats something we can work with. |
Only problem is that the there is no easy way to actually accomplish this without modifying the daemon version of the entire system.
I think the first option has a better chance of getting into upstream as is probably a more elegant solution. Allowing nix-daemon and cli to match for users, while in the container nix-daemon and cli also match but to a different version. Downside is, modifying the module could be difficult and the PR merge time consuming. The feature freeze for the next release hasn't happened yet, so it is possible we could make it by next release. Second option would probably mean we have to maintain a patched nixpkgs directly as I doubt upstream would want to go for it. Not really ideal. Third option could be good, but I'm not sure. I think we would have to set up a website manually to view the CI results. I really like hercules so far and would prefer to keep using it if possible. /cc @blaggacao @Pacman99 |
I would actually be in favor of option 3 (hydra). We might just expect better interoperability guarantees during transition. And there is also the flake "native" top level Another example: https://github.com/NixOS/nix/blob/master/flake.nix#L260-L432 Maybe we can solicit support in the form of a community hydra instance from the NixOS infrastructure team? We might even be able to slightly shape/lobby hydra in the light of our use cases. |
I do really like hercules and you've put a lot of great work into setting it up. So I'm not sure either about switching to hydra. But I also don't know a lot about how either work, so I don't think I can really give a good argument for either side. Also could github actions be used with this: https://github.com/numtide/nix-flakes-installer? I would like to avoid patching nixpkgs as that slows down evaluation a lot. And I'm not sure either change will be accepted upstream, as its more of a workaround than an actual solution.
I thought this was included in hydra? Also this update doesn't have to happen soon, theres really no rush. Staying at 20.09 is not terrible. We can also try to debug the issues with nixUnstable and report upstream, as a fully working nixUnstable would be the optimal solution. |
Since the CI is still a WIP, could we just rely on |
That sounds great to me. I'll just have to try and resolve the merge conflicts. The only major issue was that CI is actually my main dev machine, as it's the beefiest machine I have access to ATM. I just was trying to make sure I could keep up as a user. But I've pretty much worked around it, by just patching nixStable as |
I would prefer to get this merged first. If anything this is the blocker for one of my PR's(home-manager). And I doubt dealing with merge conflicts from this would be that bad. I was looking at hydra, and it doesn't seem that hard to setup at all. There is a nixos module too and I believe the web interface is a part of hydra and it has github integration. We could open an issue here for sorting out CI and consider that a separate concern from upgrading devos. And until then rely on local runs of |
Also make sure to update the lock file as part of this PR, otherwise the
|
9ff8c03
to
1762463
Compare
20.09 is getting stale as we move toward a new release so track unstable for now.
dd326bf
to
7370144
Compare
I originally wanted to use the nix flake to allow users to take advantage of the latest changes. Just so happened that nixpkgs was recently updated with a new version around the same time, and this just adds complexity for no real gain.
I cleaned up the commit history quite a bit, since much of it was irrelevant and me just trying to fix CI. I also made sure narHashes are fixed as mentioned above. My only last question would be if we should update nixos-unstable since I started this PR about a week ago, but my vote would be no, since I've already built all the community package and uploaded them to cache. I believe it is ready for final review @Pacman99 @blaggacao Since I am manually patching my dev machine. CI and BORS should continue to work as normal even after this is merged. |
same here, a week difference in nixpkgs is really not much. And end users can update if they wish. |
# from the override flake would build the test-vm from an unstable os | ||
# different than the one our systems are running. Instead simply patch nixpkgs | ||
# to include the updated version. This can be removed in the next release | ||
patchedNixpkgs = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought removing this would fix multi-arch checks, but it looks like it still fails to evaluate x86-darwin. I think its because of passing system to the make-test-python function. Not really relevant to this PR, but tests could use a bit of reworking to improve multi-arch support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may not be a huge deal as darwin is currently disabled in ci for similar reasons. I'd like to invest in a decent mac at some point and run a separate CI runner on it to build these packages. For now we should probably filter it out of checks as we do with CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This passes nix flake check on my system and the changes look great.
bors r+ |
Build succeeded: |
20.09 is getting stale as we move toward a new release so track unstable for now.