Conversation
While at it added trivial updater plumbing.
apacheHttpd: 2.4.51 -> 2.4.52
While at it added trivial updater plumbing.
Fix builds broken by libportal update
Originally enabled in 950261b ('darwin: fix gtk+3 dependencies') since then many dependencies may have been changed to rely on Cocoa only. Let's try disabling it by default to avoid the mesa dependency on darwin, we can always enable on a case-by-case basis for apps that really use X11.
…arch64 libpulseaudio: fix aarch64-darwin build
python3Packages.pycryptodome: 3.11.0 -> 3.12.0, python3Packages.pycryptodomex: 3.11.0 -> 3.12.0
openblas: 0.3.18 -> 0.3.19
Starting with LLVM 8, clang does no longer use llvm-config to detect the LLVM installation: llvm/llvm-project@e4faa5c7986b7 Consequently, there is no point passing LLVM_CONFIG_PATH (in fact the variable is unused currently).
ffmpeg: enable libzimg
the CVE description is currently suggesting AcademySoftwareFoundation/openexr@db217f2 as the fix, but it is wrong checked this patch does silence valgrind's complaints with reproducer file https://oss-fuzz.com/download?testcase_id=5275682339422208
the CVE description is currently suggesting AcademySoftwareFoundation/openexr@db217f2 as the fix, but it is wrong checked this patch does silence valgrind's complaints with reproducer file https://oss-fuzz.com/download?testcase_id=5275682339422208
[staging] llvmPackages_*.clang: stop passing LLVM_CONFIG_PATH unnecessarily
`configd` is aliased to `apple-sdk.frameworks.SystemConfiguration` in apple-sdk-11.0, which is the default on aarch64-darwin, but it does not include all of the headers. This package introduces the missing headers, which are needed to build `libresolv`. A subsequent commit will fix libresolv to build on aarch64-darwin.
|
aarch64-darwin is still a disaster; on a quick glance because of
|
The meson_0_60 attribute was removed because meson was migrated to 0.60.
|
Other than that I can't see any large problems. The smallish remains are often python stuff, usually with I expect we'll want to wait a bit for aarch64-darwin to progress, too. |
targetPlatform refers to the platform the program being compiled will produce binaries for, which only makes sense for things like compilers, not cryptsetup. The correct platform to look at to check static support is hostPlatform, which refers to the architecture the program being compiled will run on.
Probably not worth picking up, since python-unstable is already queued for the next staging-next run. |
jonringer
left a comment
jonringer
left a comment
There was a problem hiding this comment.
LGTM
There's excess hydra capacity, start another! :)
|
@veprbl We are coordinating staging cycles in #staging:nixos.org on matrix, if you want to join. https://matrix.to/#/#staging:nixos.org If you don't have a matrix account yet there is an open instance at https://nixos.dev/ for members of the NixOS org on GitHub. |
|
@mweinelt Thank you for the invitation. I did not know there was a dedicated channel devoted to staging. I would be new to matrix, will have to look into setting up an account. |
|
#156750 will be a moderate size rebuild for x86_64-linux. going to merge both |
|
And further excess Hydra capacity will be utilized by 21.11: #156696 |
agreed |
20 participants
constitutents: https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
jobset: https://hydra.nixos.org/jobset/nixpkgs/staging-next
Previous staging-next: #152145