-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Improve gcroots check & fix CI #111
Conversation
4e435a2
to
d2b644c
Compare
d2b644c
to
c448b51
Compare
Looking into this I've found that the per-user gcroots have been essentially deprecated; something about a conflict with a non-root nix builder? The upshot does seem to be that the preference is for any manipulation of the nix gcroots be managed by nix tools or the nix daemon, which seems sensible to me. Elsewhere, I was taking a stab at doing that with |
I don’t think it matters very much, nix upstream is a mess. I’d rather just improve what is there right now and worry about it when upstream decides to break us. |
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.
Fine to proceed with this
58bd5d6
to
46989e9
Compare
And remove the weird extra 22.05 target, why was this there in the first place? Nobody knows!
Instead of only checking whether we can create the user gcroot when we actually want to create a root in it, we check once in the beginning of setting up lorri and then pass the path through, assuming it exists. This improves the error message when the necessary setup is not yet there (it’s an enironment problem which can be fixed on the first start of lorri).
Lorri needs this to create gcroots for evaluations.
On MacOS, the `std` type of st_mode is `u32`, but the libc S_IWOTH is u16, meaning we can’t really compare the two … So let’s fetch stat from libc as well.
dropping a pointer does nothing
This way it’s clearer which step fails, and it’s faster to scroll to the test output. We could(?) make every test into its own step at one point, that would be good I think. Given that we use nix for both, we could import the tests and parse their attributes from the list to generate our CI run.
46989e9
to
b890754
Compare
The one failing watcher test is annoying, I’m trying to figure out what’s going wrong there, but it’s gonna have to be a separate PR. So I’m merging this for now. |
release.nix
(seerelease.nix
for instructions)