Skip to content
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

Merged
merged 4 commits into from
Mar 23, 2021
Merged

flake: nixos -> nixos-unstable #192

merged 4 commits into from
Mar 23, 2021

Conversation

nrdxp
Copy link
Collaborator

@nrdxp nrdxp commented Mar 16, 2021

20.09 is getting stale as we move toward a new release so track unstable for now.

@Pacman99
Copy link
Member

Is it possible to drop the patched-nixpkgs now? That would allow for proper multi-arch checks.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 16, 2021

failed derivations caused by:

test/tests/check/store/dg0fqn0xc0fxk4cr46mlbqry0gzvy2nw-dummy.drv':
             specified: sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
                got:    sha256-0qhPS4tlCTfsj3PNi+LHSt1akRumTfJ0WO2CKdqASiY=
make: *** [mk/lib.mk:106: tests/check.sh.test] Error 102
make: *** Waiting for unfinished jobs....
ran test tests/fetchGit.sh... [PASS]

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.

@blaggacao
Copy link
Contributor

I've seen that a few days ago. 😄

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 16, 2021

bors try

bors bot added a commit that referenced this pull request Mar 16, 2021
@bors
Copy link
Contributor

bors bot commented Mar 16, 2021

try

Build failed:

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

Update

As a workaround, I'm currently building NIX_PATH= cachix watch-exec nrdxp nix-build nix/ci.nix, and will attempt to circumvent the problem by having hercules pull the successful derivations. We'll see if it works.

I tried adding doCheck = false to the nixFlakes overlay, but the tests are still being run and still causing a failure. A bit confused as to how to address this. Any ideas anyone?

Even more disturbingly, I cannot reproduce the error locally.

@Pacman99
Copy link
Member

Pacman99 commented Mar 17, 2021

I'm getting this error while running `nix flake check` on this branch
error: builder for '/nix/store/63hfh6if3s0bp66vp2j6zimblv8ylhim-nix-2.4pre20210316_66fa1c7.drv' failed with exit code 2;
       last 10 log lines:
       >     rootCA (post)> + xargs nix copy --to file:///build/nix-test/tests/ca/substitute/binary_cache --no-require-sigs
       >     rootCA (post)> warning: you don't have Internet access; disabling some network-dependent features
       >     rootCA (post)> error (ignored): error: cannot unlink '/build/nix-test/tests/ca/substitute/binary_cache/nar/115r2bh5nm997p0g2a11ccpafx3rvb8ghvpf96zw6pl7zgzyla1x.nar.xz.tmp.20739': No such file or directory
       >     rootCA (post)> error: renaming '/build/nix-test/tests/ca/substitute/binary_cache/nar/115r2bh5nm997p0g2a11ccpafx3rvb8ghvpf96zw6pl7zgzyla1x.nar.xz.tmp.20739' to '/build/nix-test/tests/ca/substitute/binary_cache/nar/115r2bh5nm997p0g2a11ccpafx3rvb8ghvpf96zw6pl7zgzyla1x.nar.xz': No such file or directory
       >     error: program '../push-to-store.sh' failed with exit code 123
       > make: *** [mk/lib.mk:106: tests/ca/substitute.sh.test] Error 1
       > make: *** Waiting for unfinished jobs....
       > ran test tests/ca/build.sh... [PASS]
       > ran test tests/fetchMercurial.sh... [PASS]
       > ran test tests/flakes.sh... [PASS]
       For full logs, run 'nix log /nix/store/63hfh6if3s0bp66vp2j6zimblv8ylhim-nix-2.4pre20210316_66fa1c7.drv'.
error: 1 dependencies of derivation '/nix/store/z81ikz6qrazigmlrg2x8gj0wk1anw45s-devos-lib-tests.drv' failed to build
error: build of '/nix/store/11ga69pc8bh3km0ghiw9pryyaffa5xkd-jsonschema-deploy-system.drv', '/nix/store/6kdbkw2mf3a58l7f32wl3kg84jvvpbdx-deploy-rs-check-activate.drv', '/nix/store/dsv3dj0hc9qnh51b4wmm3q4sn7l2zaq6-vm-test-run-profiles.drv', '/nix/store/z81ikz6qrazigmlrg2x8gj0wk1anw45s-devos-lib-tests.drv' failed

Full log: https://termbin.com/wurt

@Pacman99
Copy link
Member

I wonder if its because of this:
sed -i 's/experimental-features .*/& ca-derivations ca-references/' /build/nix-test/tests/ca/substitute/etc/nix.conf
I'm not sure what it means, but if the test was meant to be done with specific nix.conf lines that are overriden by your patch it might fail.

@Pacman99
Copy link
Member

Also I don't understand the point of your custom patch? Whats wrong with just adding the experimental features in nix.conf?

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

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 /etc/nix.conf.

@Pacman99
Copy link
Member

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.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

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.

@Pacman99
Copy link
Member

I think dropping the custom patch might be the best way to move this forward. regular nixUnstable builds ok.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

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

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

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.

@Pacman99
Copy link
Member

Pacman99 commented Mar 17, 2021

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 nix build nixpkgs#nixUnstable

@Pacman99
Copy link
Member

Pacman99 commented Mar 17, 2021

If I pull nixUnstable from the nixos flake by dropping the nix overlay in extern, nix flake check passes for me. And it also prevents a rebuild of nix.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

Well I took your advice but ci is still failing as before.

@Pacman99
Copy link
Member

I can't reproduce locally this time either. nix flake check now passes for me on this branch..

@Pacman99
Copy link
Member

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.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

bors try

bors bot added a commit that referenced this pull request Mar 17, 2021
@bors
Copy link
Contributor

bors bot commented Mar 17, 2021

try

Build failed:

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

bors try

bors bot added a commit that referenced this pull request Mar 17, 2021
@Pacman99
Copy link
Member

Pacman99 commented Mar 17, 2021

putting hercules ci into a container where the both the cli and daemon are stable nix - @Pacman99 this seems to be the solution

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.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 17, 2021

putting hercules ci into a container where the both the cli and daemon are stable nix - @Pacman99 this seems to be the solution

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.

  1. Perhaps I should modify the default nixos-container module on nixpkgs and add this functionality as a module option and then open a PR.

  2. Alternatively we could patch nixpkgs to not add nix.package to systemPackages by default, achieving what I thought I had achieved yesterday.

  3. Use hydra in place of hercules

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

@blaggacao
Copy link
Contributor

blaggacao commented Mar 18, 2021

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 jobs attribute, which I don't fully underatand, but it smells flake-streamlined like rose water.

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.

@Pacman99
Copy link
Member

Pacman99 commented Mar 18, 2021

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.

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 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.

@Pacman99
Copy link
Member

Since the CI is still a WIP, could we just rely on nix flake check to determine if this is ready? I would say that is enough to ensure that devos will work for everyone. And we can work on setting up proper CI(hydra?) separately.
But at the same time that would break bors, so I'm not sure if we should. I believe the nix flakes installer I referenced above could be used as a temporary CI - it just runs nix flake check too. I'm not sure if github actions works with bors though.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 23, 2021

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 nix.package on my machine, and installing nixUnstable as a part of my users profile. Since this is my PR, I'll go ahead and resolve the merge conflict and merge. Of course, if merging this breaks other PR's which are ready to merge. We can hold off until they are fully merged.

@Pacman99
Copy link
Member

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 nix.package on my machine, and installing nixUnstable as a part of my users profile. Since this is my PR, I'll go ahead and resolve the merge conflict and merge. Of course, if merging this breaks other PR's which are ready to merge. We can hold off until they are fully merged.

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 nix flake check for testing - which is realistically a very good way of testing.

@Pacman99
Copy link
Member

Pacman99 commented Mar 23, 2021

Also make sure to update the lock file as part of this PR, otherwise the pkgs flake hash is outdated and that breaks the flake.
Or at least this is what I get:

error: NAR hash mismatch in input 'path:./pkgs?narHash=sha256-FifWC4SqQ92RAUgH+csfz1umRiEeRrrcpmkJMgngXXo=' (/nix/store/98li45xg2wcvgf485dv3sj4ig72p2mvm-source), expected 'sha256-FifWC4SqQ92RAUgH+csfz1umRiEeRrrcpmkJMgngXXo=', got 'sha256-XG4TOZObj2Wd8KiqnHgtlWjjMbJOIJB7+DxUFzMCXw8='
(use '--show-trace' to show detailed location information)

@nrdxp nrdxp force-pushed the update-nixos branch 2 times, most recently from 9ff8c03 to 1762463 Compare March 23, 2021 05:19
nrdxp added 2 commits March 22, 2021 23:20
20.09 is getting stale as we move toward a new release so track
unstable for now.
@nrdxp nrdxp force-pushed the update-nixos branch 3 times, most recently from dd326bf to 7370144 Compare March 23, 2021 05:28
nrdxp added 2 commits March 22, 2021 23:29
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.
@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 23, 2021

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.

@Pacman99
Copy link
Member

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.

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 =
Copy link
Member

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.

Copy link
Collaborator Author

@nrdxp nrdxp Mar 23, 2021

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.

Copy link
Member

@Pacman99 Pacman99 left a 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.

@nrdxp
Copy link
Collaborator Author

nrdxp commented Mar 23, 2021

bors r+

@bors
Copy link
Contributor

bors bot commented Mar 23, 2021

Build succeeded:

@bors bors bot merged commit c667cc5 into core Mar 23, 2021
@bors bors bot deleted the update-nixos branch March 23, 2021 06:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants