-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
Staging next 2022-03-23 #165406
Staging next 2022-03-23 #165406
Conversation
test suite is very cpu intensive
Entire test suite can take 100+ vCPU hours
Full test suite is very CPU intensive
Obsoleted by pytest-dev/pytest#9134, which was released as part of pytest 7.0.0. It has pytest<7 pinned, and we only have the single pytest version, so it can be removed.
This reverts commit ff0ad9e.
|
This reverts commit c1ef87e. I didn't realize that it would rebuild all linux stdenvs; I certainly don't want to incur such a rebuild at this point.
This time without rebuilding stdenvs.
Dropped in 0c852e1 (syntax error). If I looked at history right, it has never been used (but indirectly through cryptsetup). I expect it's a remnant of different attempts at breaking depenency cycle which we now solve through systemdMinimal.
…overrides [staging-next] systemdStage1: Fix building with 250
Hey guys, the manual doesn't really tell me about what needs to happen or at what times staging-next gets merged into main. When can we expect this to be merged? since nixpkgs-unstable has been blocked for nine days at this point |
There are still regressions we need to take care of before this can get merged. See for example #165406 (comment). |
thanks 😅 |
This reverts commit 9adc208. Clash with update; the patch is already contained and won't apply.
i'll make a pr that inlines this in postPatch |
This fixes build in qt514 case. The usual way here is to provide patches for each qt5 version separately. No other module adds them in this generic way. The problem is when you combine the approaches; qtModule will only take the list from the module and ignore the version-specific list.
The real question is why this started failing after it has been there for three years, so you'll be creating a workaround, not a fix. |
|
There are patches available for glibc-2.34 for all OCaml versions. See the patch files added in most directories of https://github.com/ocaml/opam-repository/tree/master/packages/ocaml-base-compiler in ocaml/opam-repository@0503533. |
Thanks Théo for digging this up. Are you going to do a PR? If not, please let me know and I’ll do it ASAP. |
@vbgl No sorry, I am very short on time this week. |
See errors in these three jobs: https://hydra.nixos.org/eval/1753111#tabs-still-fail It's a bit unpleasant that a single run of each test takes almost an hour for me (half an hour on Hydra in some cases).
Let's defer fixing the rest to |
Here you can see (transitive) build regressions for the three main platforms, total about two thousand: https://hydra.nixos.org/eval/1753470#tabs-now-fail |
Seemingly, a change in this iteration is causing #167854, and I have absolutely no clue what change could be the culprit. Not sure if the correct route is to disable/patch the test for it to complete or not, I guess it depends on what change is causing this. |
This iteration seems to break Before (first line is stderr of course):
After (what you see is stderr, stdout is empty):
This breaks the |
workflow docs: https://nixos.org/manual/nixpkgs/unstable/#submitting-changes-commit-policy
constitutents: https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
jobset: https://hydra.nixos.org/jobset/nixpkgs/staging-next
Previous staging-next: #161366