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
[20.09] Staging next #102662
[20.09] Staging next #102662
Conversation
(cherry picked from commit 6afb582)
SECURITY ISSUE: Attempted to make RSA PKCS#1v1.5 decryption more constant time, to protect against Bleichenbacher vulnerabilities. Due to limitations imposed by our API, we cannot completely mitigate this vulnerability and a future release will contain a new API which is designed to be resilient to these for contexts where it is required. Credit to Hubert Kario for reporting the issue. CVE-2020-25659 (cherry picked from commit 1083cdd)
This vulnerability does not have a CVE yet. https://security-tracker.debian.org/tracker/TEMP-0000000-DD4835 https://bugs.openldap.org/show_bug.cgi?id=9370 (cherry picked from commit 307abd9)
[staging-20.09] openldap: add patch to fix unauthenticated nullptr dereference in slapd
(cherry picked from commit 859a44e)
(cherry picked from commit 81063ee)
Re-enable the Systemd remote support
To stay within hydra limit of 2^31 output size on aarch64-linux
…-limits' into staging-20.09
(cherry picked from commit 8904ce2)
A recent addition to the test suite turned out to be sensitive to DST. The main code is ok. Patch only required to make test succeed. See https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4a071afbd056282746a5bc9362e87f579a56402d (cherry picked from commit 09a59b3ba43e4b68f7cea9c5685b424c83382a6f)
A recent addition to the test suite turned out to be sensitive to DST. The main code is ok. Patch only required to make test succeed. See https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4a071afbd056282746a5bc9362e87f579a56402d (cherry picked from commit 88f84e5)
This reverts commit f7360dc. It breaks golang bootstrapping and should be update later.
Blocked on hydra build timeouts, see NixOS/hydra#830 |
pkgs/applications/networking/mailreaders/thunderbird/default.nix
Outdated
Show resolved
Hide resolved
The default timeout is 10h on Hydra currently, so this timeout setting is pointless or counterproductive. This commit seems to have been made in error #96767 (comment) This reverts commit 1733d51.
The timezone dumps have switched to a "slim" format since 2020b. This has broken various packages, including - go 1.4 (used for bootstrapping) - haskellPackages.tz - libical The "fat" format can still be generated, as this commit shows. It seems to create files that are *mostly* the slim versions with some more data attached. (cherry picked from commit d328ba1)
(cherry picked from commit 8904ce2)
[staging-20.09] shadow: 4.8 -> 4.8.1
This iteration was stuck on darwin's ghc timing out. I'm starting the next mass-rebuild iteration hoping that hydra will pick up the updated timeout duration because of the new drv. |
The new evaluation is https://hydra.nixos.org/eval/1626139 |
Here's the new evaluation https://hydra.nixos.org/eval/1626149 |
Yes, I think Hydra will just reuse the job if the output hash is the same as in the previous evaluation. What might work is to now revert that rebuild and re-eval :-) |
However, if it looks up by drv globally rather than previous job, it will still be bad.
I'm a bit tired of this whole hydra timeout exercise tbh, but I appreciate the input. |
I'm hopeful the current one will work. I don't think the change will really cost anything (rebuilding just what failed anyway). IIRC I once ran into this "issue" with a fixed-output derivation (bad download URL or something)... |
That probably only worked because the output was cached, so the old derivation didn't have to be run after you reverted to it. |
No, it was failed so it wasn't cached. And I couldn't make Hydra retry it with fixed URL, because it was rerunning with the old one due to the output hash being the same (and thus thinking it's the same derivation). EDIT: I mean, I most likely wouldn't think of such an issue if I were writing hydra... |
Could be. It doesn't save any builds though, so I wouldn't bother. Most of the builds are because of tzdata and shadow, not the darwin ghc rebuild, which seems to be quite independent. Nonetheless some packages will depend on both, so we're saving some build time by combining these changes. Also if the darwin-only comment happens to stick around, it's not so bad because it will be made irrelevant by the next release. I'd say there's not much we can do to improve things now. |
Not sure how to compare the jobsets, but I've made an attempt by searching in staging-20.09 and opening the various release jobsets. Staging stats: based on eg https://hydra.nixos.org/eval/1626407?filter=x86_64-darwin&compare=1626149&full=#tabs-still-fail Release stats: x86_64-linux: ~160 failures ConclusionSeems like a improvement. Will merge base again to check for rebuilds from release-20.09 changes. If those aren't too many, I think we can merge. |
Do we squash any commits? |
I guess there's no need to wait for aarch64, as that would probably take several more days, I'm afraid. It sounds OK to me to merge as is (without rewriting history), but I don't mind if you/someone prefer to clean it up a bit instead. |
we don't do this well even on unstable's staging/staging-next
I would say we should move forward |
If it already exists on one of the main NixOS/Nixpkgs branches (master, staging*, staging-next, release-*), I would avoid force-pushing at all. Ideally those commits and reverts should have been better tested before merging |
Thanks everyone! |
https://hydra.nixos.org/jobset/nixpkgs/staging-20.09
Motivation for this change
Things done
before merge