-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
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-24.05 iteration 2 - 2024-07-11 #326357
Conversation
(cherry picked from commit 067ad05)
This appears to be fixed in macOS 14.5, but the source release is not yet available. (cherry picked from commit edfc324)
(cherry picked from commit 598fca7)
(cherry picked from commit 28a49fe)
Previously, we would set GHC_PACKAGE_PATH after configure, the reasons being that 1. Setup.hs configure forbids this from being set since it can make a build fail that would otherwise succeed (since it influences how GHC behaves when invoked by Cabal). 2. Setting GHC_PACKAGE_PATH being set is sound in our case, since we set it precisely to the packages available to Cabal at configure time, so there should be no room for a mismatch. 3. Some test suites require GHC_PACKAGE_PATH or GHC_ENVIRONMENT to be set, so they can invoke GHC(i) with build dependencies available. Cabal >= 3.12 forbids GHC_PACKAGE_PATH from being set after <haskell/cabal@d6e38041a7c778fadf8f416>. Setting GHC_ENVIRONMENT would be possible, but is cumbersome without cabal-install (which has the handy cabal exec command which takes care of that). Additionally, it is not clear if it'll remain possible to do that: <haskell/cabal#7792>. Our solution to Cabal 3.12's change is to be more targeted about setting GHC_PACKAGE_PATH: We _just_ set it for the actual test suite executable. This can be achieved by using --test-wrapper which when given is invoked by Cabal to run the test suite. Here we can set any environment variables after Cabal has already done its environment checks. As long as we don't do anything stupid, this should be unproblematic. Users can also arbitrarily influence what GHC_PACKAGE_PATH will contain using the NIX_GHC_PACKAGE_PATH_FOR_TEST environment variable. This is un(der)documented for now, since I want to keep some wiggle room for changing stuff in the coming weeks. Also it's rarely necessary to actually touch this variable. (cherry picked from commit 120f242)
After 120f242, GHC_PACKAGE_PATH isn't set implicitly in installPhase anymore. Instead we achieve the same by telling the Makefile the exact ghc command line to use. As a benefit, we can now cleanly separate build and host in this case: We used to (implicitly) reuse the host package db. Now we can explicitly request the package db also used for building Setup.hs. (cherry picked from commit 482ab92)
It is somewhat curious that it behaves differently exclusively here, but I don't think it is necessary to stop shipping a package due to floating point arithmetic error—it would be unreasonable to assume there were none… See ekmett/ad#113. (cherry picked from commit d902325)
https://github.com/pyasn1/pyasn1-modules/releases/tag/v0.4.0 pyasn1/pyasn1-modules@v0.3.0...v0.4.0 fixes #312717 backports #313613 Co-authored-by: Fabian Affolter <[email protected]> (cherry picked from commit 615b0f4)
…nmpt [Backport staging-24.05] libopenmpt: 0.7.6 -> 0.7.8
(cherry picked from commit d3b55ee)
[Backport staging-24.05] cryptsetup: 2.7.1 -> 2.7.3
(cherry picked from commit 599b8eb)
[Backport staging-24.05] llvmPackages_18: 18.1.7 -> 18.1.8
Those flags were not actually passed to GHC before, but to Setup.hs. They were introduced in #86948. The related twitch live stream uses the build of git-annex as a measurement. I get the following numbers when building git-annex with doCheck = false: - for current master: 1:40 wall clock / 340s user - without any -A64M argument: 1:40 wall clock / 340s user - with this fix: 1:13 wall clock / 280s user The idea was good, but the settings were never active. More testing revealed that this seems to work on darwin just as well, so we're removing the isLinux condition, too. (cherry picked from commit 3286300)
https://mail.gnu.org/archive/html/emacs-devel/2024-06/msg00695.html (cherry picked from commit 25bc4a5)
[Backport staging-24.05] emacs: 29.3 -> 29.4
Fixes CVE-2024-36039. Changes: https://github.com/PyMySQL/PyMySQL/releases/tag/v1.1.1 (cherry picked from commit 31cfac4)
(cherry picked from commit eb7fd13)
https://hydra.nixos.org/build/266280498/nixlog/1/tail In the test sources I see lines hinting at the moment it started failing name:endtime type:GENERALIZED_TIME value:20240711155558Z but I was unable to find a fix quickly. (cherry picked from commit f6f5b1f)
Would it be possible to pull in #327450 still ? It backports quite a few bugfixes. Currently at work around 60% of our fleet fails to boot reliably due to a systemd bug that's fixed in 255.9 and would be a shame if it would take another month before it lands. |
I'm not sure. At this point we have almost all *-linux binaries, so that would mean dropping at least 40k successful builds and redo them, I think. |
nixpkgs master is still on 255.6, so I guess it's better to wait a bit with 24.05 anyway. |
https://hydra.nixos.org/jobset/nixpkgs/staging-next-24.05
https://hydra.nixos.org/jobset/nixos/staging-next-24.05-small
Significant breakages
(will be edited based on progress)