staging-next-24.05 iteration 2 - 2024-07-11 #326357
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(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 <mail@fabian-affolter.ch> (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)
vcunat
requested review from
sternenseemann,
maralorn and
ncfavier
as code owners
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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)