summaryrefslogtreecommitdiff
Commit message (Expand)AuthorAgeFilesLines
* mesa: simplify opencl patchorigin/llvm15-wipK9002023-01-281-41/+10
* mesa: use LLVM 15, remove global spirv-translator overrideVladimír Čunát2023-01-282-5/+9
* libclc: 14.0.6 -> 15.0.7K9002023-01-281-2/+2
* python310Packages.peaqevcore: 11.0.0 -> 11.0.4R. Ryantm2023-01-281-2/+2
* syft: 0.66.2 -> 0.68.1R. Ryantm2023-01-281-3/+3
* licensor: fix tests, this time in a longterm wayVladimír Čunát2023-01-281-8/+4
* knot-resolver: 5.5.3 -> 5.6.0•••https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.6.0 There's a security fix, though I don't consider it severe. Vladimír Čunát2023-01-281-4/+5
* treewide: convert 17 fonts to stdenvNoCC.mkDerivationWeijia Wang2023-01-2817-255/+304
* julia-mono: 0.046 -> 0.047R. Ryantm2023-01-281-2/+2
* automatic-timezoned: 1.0.57 -> 1.0.60R. Ryantm2023-01-281-3/+3
* cocogitto: 5.3.0 -> 5.3.1R. Ryantm2023-01-281-3/+3
* llvmPackages_15: expose the release information and monorepo source as overri...•••this makes it easier for users to use their own LLVM in nixpkgs Rahul Butani2023-01-281-10/+59
* llvmPackages_15.llvm: add checks for the LLVM version•••this is in preparation for the next commit which exposes the release information and monorepo source as overridable args (which makes it easier for users to use their own LLVM in nixpkgs) this commit only adds a check in the `llvm` package's postConfigure that makes sure the LLVM source provided matches the version we were given; the actual machinery (functionally just a cosmetic change; causes no rebuilds) is in the next commit Rahul Butani2023-01-281-0/+32
* llvmPackages_15: update licenses•••Context: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r1073157093 All the subprojects seem to be uniformly licensed under NCSA and the LLVM license now (with the exception of openmp which has an additional Intel license that doesn't seem to be in SPDX?); see: - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/compiler-rt/LICENSE.TXT - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/libcxx/LICENSE.TXT - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/libcxxabi/LICENSE.TXT - https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/openmp/LICENSE.TXT Rahul Butani2023-01-285-13/+1
* llvmPackages_15: misc fixes, notesRahul Butani2023-01-282-3/+3
* llvmPackages_15.openmp: add a missing darwin check dependency•••the tests still don't all pass so `doCheck` is still disabled Rahul Butani2023-01-281-0/+3
* llvmPackages_15.clang: drop the C++ std version `-DCMAKE_CXX_FLAG`•••Context: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r1085220705 Rahul Butani2023-01-281-1/+0
* llvmPackages_15.llvm: specify some deps explicitly to fix cross-compilation•••The two scenarios described within where splicing doesn't handle selecting the right package for us are observable in the following (nix repl session): ``` > np = import <nixpkgs> { system = "x86_64-linux"; crossSystem = { config = "aarch64-linux"; }; } > np.__splicedPackages.hello ? __spliced true > np.__splicedPackages.python3Packages.psutil ? __spliced true > np.__splicedPackages.python3.pkgs.psutil ? __spliced false > (np.__splicedPackages.python3.withPackages (ps: with ps; [psutil])) ? __spliced false ``` See: #211340 Rahul Butani2023-01-281-2/+10
* llvmPackages_15.llvm: disable some RISC-V ZBP tests on arm32•••see this thread for context: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r999790443 Co-authored-by: misuzu <bakalolka@gmail.com> Rahul Butani2023-01-281-0/+6
* llvmPackages_15.llvm: fix the tests on `x86_64-darwin`•••Details within but ultimately there isn't a satisfying resolution for any of the three test failures we were seeing and all three deserve further exploration. For the `sw_vers` macOS version issue in particular, it's possible to observe the nixpkgs provided `CoreFoundation` vs system `CoreFoundation` for `x86_64` and `aarch64` like so (on a host running macOS `13.0.1`): ```console $ nix-shell -p darwin.DarwinTools --system aarch64-darwin --command "sw_vers" ProductName: macOS ProductVersion: 13.0.1 BuildVersion: 22A400 $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command "sw_vers" ProductName: Mac OS X ProductVersion: 10.16 BuildVersion: 22A400 ``` Where `/System/Library/CoreServices/SystemVersion.plist` has: ```console $ cat /System/Library/CoreServices/SystemVersion.plist | grep ProductVersion -A 1 <key>ProductVersion</key> <string>13.0.1</string> ``` Further: ```console $ nix-shell -p darwin.DarwinTools --system aarch64-darwin --command 'otool -L $(which sw_vers)' /nix/store/nb2q33ak2zif49ndcpc6m823z0vhmy8y-DarwinTools-1/bin/sw_vers: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command 'otool -L $(which sw_vers)' /nix/store/88v4kjvgwl71byfpvd0baviiq7l5appc-DarwinTools-1/bin/sw_vers: @rpath/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1454.90.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) ``` For the `x86_64` `sw_vers` binary we can see rpath: ```console $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command 'otool -l $(which sw_vers)' | grep LC_RPATH -A 2 -B 1 Load command 13 cmd LC_RPATH cmdsize 120 path /nix/store/zvr4wypbgskhhw9cawfn7mmxfa75nh8f-swift-corefoundation-unstable-2018-09-14/Library/Frameworks (offset 12) ``` And we can confirm that the nixpkgs provided `CoreFoundation` is what ultimately gets loaded: ```console $ nix-shell -p darwin.DarwinTools --system x86_64-darwin --command 'DYLD_PRINT_LIBRARIES=1 sw_vers' dyld[16215]: <no uuid> /nix/store/88v4kjvgwl71byfpvd0baviiq7l5appc-DarwinTools-1/bin/sw_vers dyld[16215]: <no uuid> /nix/store/zvr4wypbgskhhw9cawfn7mmxfa75nh8f-swift-corefoundation-unstable-2018-09-14/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation dyld[16215]: <no uuid> /nix/store/xd2a4xh8kdwq0j67hzgw720npdw5hzkk-ICU-66108/lib/libicucore.A.dylib <snipped> ``` ```bash nix-diff \ $(nix path-info nixpkgs#legacyPackages.aarch64-darwin.darwin.DarwinTools --derivation) \ $(nix path-info nixpkgs#legacyPackages.x86_64-darwin.darwin.DarwinTools --derivation) ``` doesn't show any _obvious_ discrepancies Rahul Butani2023-01-281-1/+50
* llvmPackages_15.llvm: adjust a path, skip an xfail test on darwinRahul Butani2023-01-281-0/+10
* llvmPackages_15.llvm: run the tests on macOS•••there are a few parts to this: - adding darwin specific check deps - working around referencing LLVM dylibs during the checkPhase in a way that supports darwin + previously we just set `$LD_LIBRARY_PATH` and/or made some strategic symlinks + now we have LLVM's `lit` config set the appropriate env vars as needed (as is done for other LLVM subprojects) + in retrospect switching to `installCheckPhase` might have been the better move.. - patching `lit` to deal with `$DYLD_LIBRARY_PATH` being purged for new "protected" processes more details within. Rahul Butani2023-01-284-18/+180
* llvmPackages_15.llvm: add in a missing check depRahul Butani2023-01-281-2/+28
* llvmPackages_15.llvm: enable polly by default•••this comment has a more complete history: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r1064089830 in short: polly was disabled in the llvm 11 -> llvm 12 copy, mostly by accident most of the Polly install dirs patch has been upstreamed; one change remains Rahul Butani2023-01-283-92/+10
* llvmPackages_15: expand the `NIX_BUILD_CORES` arg passed to lit at configure ...•••this previously worked because, when using Make, this variable was expanded at build time Rahul Butani2023-01-281-1/+1
* llvmPackages_15: switch to using `ninja`Rahul Butani2023-01-2810-30/+26
* llvmPackages_15.lldb: fix the manpagesRahul Butani2023-01-282-5/+11
* llvmPackages_15.lldb: fix the build on `i686`•••as detailed within, adding `asm/ptrace.h` leads to `asm/ptrace-abi.h` being included which defines preprocessor symbols that clash with identifiers used in the LLVM headers (`FS` and `CS` only defined on i686) Rahul Butani2023-01-281-2/+8
* llvmPackages_15.lldb: fix `lldb` on x86_64 macOS•••See: https://github.com/NixOS/nixpkgs/pull/194634#issuecomment-1272129132 Rahul Butani2023-01-282-2/+46
* llvmPackages_15.compiler-rt: gate the `libxcrypt` dep on `plat.libc == "glibc"`•••This restores this check to what it originally was in #196909 (see: https://github.com/NixOS/nixpkgs/pull/196909#discussion_r1000536298) and lets `compiler-rt` eval successfully when trying to compile the `llvmPackages_15` set for mingw targets (i.e. a platform that *is* GNU but does *not* use glibc). --- It's not clear to me what the `haveLibc` check is doing here (platforms that seem to use glibc like `x86_64-linux` and have `plat.libc == "glibc"` have `haveLibc = false` because `stdenv.cc.libc` is `null`). Rahul Butani2023-01-281-1/+1
* llvmPackages_15.compiler-rt: update the armv7l patch•••see the discussion here for context: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r999829893 Rahul Butani2023-01-281-14/+14
* llvmPackages_15.compiler-rt: apply #186575 to `llvmPackages_15`Rahul Butani2023-01-281-6/+10
* llvmPackages_15.compiler-rt: fixes for Darwin•••this introduces a codesigning related patch that we can drop once #195107 goes through see: https://github.com/NixOS/nixpkgs/pull/194634#issuecomment-1272116014 Rahul Butani2023-01-283-34/+36
* llvmPackages_15.libcxxabi: fix cycles that arise when `stdenv` is the LLVM st...Rahul Butani2023-01-282-2/+21
* llvmPackages_15.libcxx: use clang 15 instead of the stdenv's compiler•••libc++ has switched to using `__attribute__((using_if_exists))` to handle incomplete libc implementations; see: https://github.com/llvm/llvm-project/commit/a9c9183ca42629fa83cdda297d1d30c7bc1d7c91 These essentially require a modern C++ compiler (clang gained support in LLVM 13: https://github.com/llvm/llvm-project/commit/369c64839946d89cf5697550b6feeea031b2f270, gcc appears to not have support yet: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105584). Previously this was not an issue for us (despite the transition happening around LLVM 13) but something about the changes to the libc++/libc++-abi build has made it so that on platforms with incomplete libc impls (i.e. Darwin is missing `quick_exit`/`at_quick_exit`) we error during the `libcxx-abi` build when the stdenv's (older, not supporting `using_if_exists`) compiler tries to import libc symbols that aren't present. The libc++ docs suggest we use a modern compiler to build libc++ anyways (https://releases.llvm.org/15.0.0/projects/libcxx/docs/index.html#platform-and-compiler-support) so this commit uses stdenv's containing the package set's clang to build libcxx/libcxx-abi. This is similar to how libc++ bootstrapping builds (https://releases.llvm.org/15.0.0/projects/libcxx/docs/BuildingLibcxx.html#bootstrapping-build) work. Rahul Butani2023-01-282-11/+30
* llvmPackages_15: apply #211230 to llvmPackages_15•••See the comments here for context: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r1089389188 Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com> Rahul Butani2023-01-283-8/+22
* llvmPackages_15.compiler_rt: apply #196909 to LLVM 15•••`llvmPackages_15` originates from `llvmPackages_git` which does not include this change Rahul Butani2023-01-281-2/+2
* llvmPackages_15: updates for LLVM 15•••None of the patches required any touch-up; the only change of note is: - due to changes in the libc++/libc++abi build (https://reviews.llvm.org/D120719 and https://reviews.llvm.org/D131037) we have to add an extra build option to the libc++ header only build that sidesteps bits of the libc++ build config that assume libc++-abi is present in the build: https://github.com/llvm/llvm-project/blob/4f827318e3e8ccab4ff131e06234caa827e91e4e/libcxx/src/CMakeLists.txt#L255-L256 Rather than maintaining a precise set of build options that let us dodge referencing libc++-abi variables in the libc++ header only build, we set `LIBCXX_CXX_ABI` to `none`, as suggested by @lovesegfault. More discussion about this here: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r990267037 Co-authored-by: Bernardo Meurer <bernardo@meurer.org> Rahul Butani2023-01-282-4/+4
* llvmPackages_15: apply some patches from `llvmPackages_14`, part 2•••See https://github.com/NixOS/nixpkgs/pull/194634#issue-1398202534 for details. PRs: - #211401 - #211161 - #206742 - #211687 Rahul Butani2023-01-283-7/+18
* llvmPackages_15: apply some patches from `llvmPackages_14`•••See #194634 for details. PRs: - #191372 - #190936 - #82131 - #199844 - #197674 - #184408 - #193004 Rahul Butani2023-01-288-10/+22
* llvmPackages_15: copy from `llvmPackages_git`Rahul Butani2023-01-2833-0/+2192
* s3rs: 0.4.16 -> 0.4.19R. Ryantm2023-01-281-3/+3
* xorg.libXpm: 3.5.13 -> 3.5.15•••There are mainly the security fixes: CVE-2022-46285 CVE-2022-44617 CVE-2022-4883 The new dependency adds just several kilobytes. https://www.mail-archive.com/xorg-announce@lists.x.org/msg01521.html https://www.mail-archive.com/xorg-announce@lists.x.org/msg01522.html https://www.mail-archive.com/xorg-announce@lists.x.org/msg01470.html Vladimír Čunát2023-01-283-4/+6
* mesa: 22.3.3 -> 22.3.4•••https://docs.mesa3d.org/relnotes/22.3.4.html Vladimír Čunát2023-01-281-2/+2
* Merge #212919: ubootTools: fix build by fixing -idirafter ordering•••...into staging-next Vladimír Čunát2023-01-281-0/+10
|\
| * ubootTools: fix build by fixing -idirafter ordering•••`ubootTools` build broke after https://github.com/NixOS/nixpkgs/pull/210004 where we started dropping default libc include path and switched to `-idirafter` way of specifying libc headers. Unfortunately the way it's implemented it injects -idirafter after user's flags, not before. That allows users to inject their paths before libc include paths, not after (as it would notmally happen). The change works it around for u-boot by pulling -idirafter libc flags before user's flags. Sergei Trofimovich2023-01-271-0/+10
* | Merge #213021: build-support/cc-wrapper: add libstdc++fs•••...into default library path for clang; merge into staging-next Vladimír Čunát2023-01-281-0/+5
|\ \
| * | build-support/cc-wrapper: add libstdc++fs into default library path for clang•••After https://github.com/NixOS/nixpkgs/pull/210004 `usbmuxd2` started failing to build as: usbmuxd2-unstable> .../ld: cannot find -lstdc++fs: No such file or directory usbmuxd2-unstable> clang-11: error: linker command failed with exit code 1 (use -v to see invocation) This started happening because #210004 exposed a long-standing bug in `gcc` derivation: `cc.lib` is missing `libstdc++fs` library: $ find $(nix-build --no-link -A stdenv.cc.cc.lib) | fgrep libstdc | unnix /<<NIX>>/gcc-11.3.0-lib/lib/libstdc++fs.la /<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.la /<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.so.6.0.29 /<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.so /<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.so.6 It was not moved from `cc.out` output: $ find $(nix-build --no-link -A stdenv.cc.cc) | fgrep libstdc | unnix /<<NIX>>/gcc-11.3.0/lib/libstdc++.a /<<NIX>>/gcc-11.3.0/lib/libstdc++fs.a This change adds `cc` library lookup path back to `staging-next` until `gcc` is fixed.` Sergei Trofimovich2023-01-281-0/+5
* | | Merge master into staging-nextgithub-actions[bot]2023-01-2873-827/+1039
|\ \ \
| * \ \ Merge pull request #213076 from wegank/fonts-26•••treewide: convert 26 fonts to stdenvNoCC.mkDerivationWeijia Wang2023-01-2826-391/+454
| |\ \ \
generated by cgit v1.2.3 (git 2.52.0) at 2026-08-20 02:00:43 +0000