bzip2, zstd: Add `enableStatic` option #237563

libwebp: 1.3.0 -> 1.3.1

pypy3Packages.execnet: disable tests as they randomly crash, cleanup

The configure scripts frequently use `main` returning an implicit `int`, which causes spurious failures when CC is clang 16+. This is fixed by patching the provided macros and regenerating the scripts with autoreconfHook, though it requires some manual processing (see below). The upstream `configure.ac` is written in such a way that it requires fixups and post-processing. * Fixups are required because the original build process just cats the macros together into one file. When `aclocal` is run, it does not pick up all of them. This is worked around by catting the missing macros to a file that is picked up by autoreconfHook. * Post-processing is required to populate the version information. This is done in a subshell to avoid polluting the environment with the contents of `RELEASE`. Otherwise, the build will fail because the version C macros it expects will not be defined.

Both `_spin_lock_try` and `_spin_unlock` are private and deprecated APIs, which are not exported by any headers in the SDK. The build fails because the configure script does not define the functions before calling them, which is treated as error by clang 16. This patch replaces use of those APIs with `os_unfair_lock`, which is the recommended replacement per the deprecation messages.

In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.

swift-corelibs fails to build due to a missing header and an invalid pointer conversion. Patches are provided to fix both of these issues.

@emilazy

Switching the build system to cmake makes it easier to make changes to the build (particularly which dependencies to link). It also removes a lot of manual build steps and fixes the issue identified by @emilazy in NixOS#238791. Fixes NixOS#238791.

Upstream swift-corelibs links against icu on Linux, so it is not necessarily tied to the version of ICU provided by Apple for Darwin. swift-corelibs and qtwebkit are the only two packages that link against darwin.ICU. Switching to the nixpkgs icu will allow the Darwin-specific package to be deprecated and removed eventually.

swift-corelibs uses libcurl to implement `NSURLSession` in Foundation via the symbols exported by CF. Foundation is not build on Darwin, and these symbols are not exported by the system CoreFoundation. By not linking against libcurl, this breaks a cycle between CF and libcurl. That should allow libcurl to drop the patch disabling linking against the SystemConfiguration and restore NAT64 support. Unfortunately, the Darwin stdenv bootstrap still needs to build dependencies that use `fetchFromGitHub`. While it can drop curl from the final stdenv, it still needs to use it during the stdenv bootstrap.

@emilazy

@emilazy found a bug in NixOS#234861. Specifically, the hook is not actually applied. e2fsprogs links against darwin.CF, but since it cannot find the framework by rpath, it crashes. Since the hook should always be used, it is copied directly to `nix-support/setup-hook` instead of providing it as an attribute. This preserves dropping the hook in the cross-compilation case while providing it for everything else that needs it. To avoid further churn and due to the complexity of building the stdenv with the hook active, this change required the stdenv rework.

xmlto: fix build with clang 16

linux_6_1, linux_6_3, linux_6_4: update stable kernels

https://www.djangoproject.com/weblog/2023/jul/03/security-releases/ https://docs.djangoproject.com/en/3.2/releases/3.2.20/ Fixes: CVE-2023-36053

I don't see a reason to separate the gvc-compact patch, we are actually already maintaining our graphviz patch for a while (since openembedded-core is now simply disabling valadoc).

https://gitlab.gnome.org/GNOME/vala/-/compare/0.56.7...0.56.9

The test-c-stack tests hang on x86_64-darwin when they are run under Rosetta 2. Disabling these tests allows the rest of the tests to run successfully on that platform. This is a similar to the issue that affected gnugrep (NixOS#236229).

The default timeout is 1500. We've been seeing consistent timeouts on builders under high load. Let's see if this helps. Link: NixOS#234754 (comment) Fixes: NixOS#240660

https://github.com/agronholm/exceptiongroup/blob/1.1.2/CHANGES.rst

diffutils: disable hanging test on x86_64-darwin

When using super.impureUseNativeOptimizations as an overlay for stdenv, libxcrypt fails building with -Werror=sign-conversion Co-authored-by: Artturin <Artturin@artturin.com>

cctools-port: fix build with clang 16 on x86_64-darwin

iproute2: 6.3.0 -> 6.4.0

; Conflicts: ; pkgs/development/libraries/nss/generic.nix - bb53634 removed the conditionals since firefox-esr-91 and nss <3.69 has been dropped a while ago. - cb37628 updated the conditionals to always partition the tests based on the nss_latest version. Chosen that since it will remain future proof.

openexr: increase test timeout

zimg: 3.0.4 -> 3.0.5

darwin.stdenv: Darwin stdenv rework

xorg.*: update to latest version

Diff: django/asgiref@refs/tags/3.6.0...3.7.2 Changelog: https://github.com/django/asgiref/blob/refs/tags/3.7.2/CHANGELOG.txt

https://gitlab.gnome.org/GNOME/libxslt/-/compare/v1.1.37...v1.1.38

https://gitlab.gnome.org/GNOME/libxml2/-/compare/2.10.4...2.11.4

itstool/itstool@2.0.6...2.0.7

db: fix build on Darwin and clang 16

configd: fix build with clang 16

python311Packages.asgiref: 3.6.0 -> 3.7.2

https://github.com/besser82/libxcrypt/blob/v4.4.36/NEWS

xterm: 382 -> 383

https://gitlab.gnome.org/GNOME/gjs/-/compare/1.76.0...1.76.2

https://gitlab.gnome.org/GNOME/glib-networking/-/compare/2.76.0...2.76.1

https://gitlab.gnome.org/GNOME/gupnp/-/compare/gupnp-1.6.3...gupnp-1.6.4

https://gitlab.gnome.org/GNOME/tracker/-/compare/3.5.1...3.5.3

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/compare/1.42.6...1.42.8

Diff: https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/compare/1.32.2...1.32.4 Changelog: https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/blob/1.32.4/NEWS

https://gitlab.gnome.org/GNOME/librsvg/-/compare/2.55.1...2.56.2

- Format the expression. - Use static repo name. - Use autoreconfHook.

stoken-dev/stoken@v0.92...v0.93

...into staging

openldap: drop unused db

libxcrypt: 4.4.35 -> 4.4.36

libgudev is needed for an optional test but it itself relies on umockdev for testing.

https://github.com/python-pillow/Pillow/blob/9.5.0/CHANGES.rst

https://github.com/sqlalchemy/sqlalchemy/releases/tag/rel_2_0_18

python310Packages.sqlalchemy: 2.0.17 -> 2.0.18

libxml2: 2.10.4 → 2.11.4

itstool: 2.0.6 → 2.0.7

python310Packages.exceptiongroup: 1.1.0 -> 1.1.2

python310Packages.django_3: 3.2.19 -> 3.2.20

cups: 2.4.5 -> 2.4.6

fluidsynth: 2.3.2 -> 2.3.3

libassuan: 2.5.5 -> 2.5.6

openresolv: 3.12.0 -> 3.13.2

https://github.com/cython/cython/blob/0.29.36/CHANGES.rst

python310Packages.Cython: 0.29.34 -> 0.29.36

p11-kit: 0.24.1 -> 0.25.0

https://gitlab.gnome.org/GNOME/libgudev/-/compare/237...238

libdc1394: 2.2.6 -> 2.2.7

ebassi/mutest@e6246c9...18a2007 - Use new version schema. - Add update script. - Use more convenient homepage.

isocodes: 4.11.0 -> 4.15.0

Diff: https://gitlab.freedesktop.org/pipewire/pipewire/-/compare/0.3.72...0.3.73 Changelog: https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/0.3.73

pipewire: 0.3.72 -> 0.3.73

python310Packages.numpy: run tests correct so that actually fail the build

`libxml2-2.11` removed `checked` bit of private API and broke `librdf_raptor2` build as: src/raptor_libxml.c:256:12: error: 'xmlEntity' {aka 'struct _xmlEntity'} has no member named 'checked' 256 | if(!ret->checked) | ^~ The change pull upstream fix.

librdf_raptor2: backport fix for `libxml2-2.11`

curl: 8.1.1 -> 8.1.2

https://github.com/ijl/orjson/releases/tag/3.9.2 ijl/orjson@3.8.11...3.9.2 Changelog: https://github.com/ijl/orjson/blob/3.9.2/CHANGELOG.md

db: make patches and autoreconfHook unconditional

python310Packages.pillow: 9.4.0 -> 9.5.0

When reporting 'gcc' bugs upstream I'm occasionally asked for the actual configure flags I used to build gcc. Before the change `gcc -v` always reported empty string: $ gcc -v ... Target: x86_64-unknown-linux-gnu Configured with: After the change `gcc -v` contains original options with slightly mangled nix store paths to avoid build-only dependency retention: $ gcc -v ... Target: x86_64-unknown-linux-gnu Configured with: ../source/configure --prefix=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gcc-14.0.0 --with-gmp-include=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gmp-6.2.1-dev/include --with-gmp-lib=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gmp-6.2.1/lib --with-mpfr-include=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-mpfr-4.2.0-dev/include --with-mpfr-lib=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-mpfr-4.2.0/lib --with-mpc=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libmpc-1.3.1 --with-native-system-header-dir=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.37-8-dev/include --with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-checking=release --enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin --disable-libcc1 --with-isl=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-isl-0.20 --disable-bootstrap --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu While a bit verbose I think it's useful to see how we build gcc.

...into staging-next

lua.withPackages only brings packages that have passthru.luaModule, which was not the case of luarocks (because it's built differently than other lua packages). We call toLuaModule on luarocks so that it is brought in a lua.withPackages call

https://gitlab.gnome.org/GNOME/glib/-/compare/2.76.3...2.76.4

https://hydra.nixos.org/build/226758408/nixlog/2/tail

cctools-llvm: match binutils targetPrefix definition

python310Packages.orjson: 3.8.11 -> 3.9.2

Clang 11 performs an optimization on x86_64 that is sensitive to the presence of debug information. This results in GCC’s bootstrap failing because it builds stage 2 with debug information and stage 3 without, and the resulting objects do not match. This patch uses the cctools assembler on LLVM 11 and x86_64-darwin while using the integrated assembler on newer versions, which matches the platform tools (Apple has uses the integrated assembler since Xcode 12).

This reverts commit b39481b.

python310Packages.requests-mock: 1.10.0 -> 1.11.0

python310Packages.pytest-timeout: remove dependency on pytest-cov

This fixes pyicu (and any other package that uses `icu-config` instead of the CMake or some other module to get the build flags). What happened here is the bootstrap disables `patchShebangs` to avoid propagating the bootstrap tools to the final stdenv (due to `sh` and `bash` being on the `PATH` from the bootstrap tools). Because of that, the `#!/bin/sh` line in `icu-config` was not updated, causing it to invoke the system bash on Darwin. While that is undesirable in its own right, when the system bash is invoked as `sh`, `echo -n` will print `-n`, resulting in the breakage see in NixOS#241951 (comment). The fix is to build bash earlier in the bootstrap while making sure it is picked up over the one in the bootstrap tools. That allows `patchShebangs` to be enabled during the bootstrap. Any package with scripts that is included in the final stdenv should now have its scripts’ shebang lines properly patched.

While trying to exclude a generated `/share/info/dir` in a package from symlinking into a profile, we also ended up excluding the Emacs info manual for `dired-x`. This change excludes only the dir file.

..into staging-next

...into staging-next, i.e. this will come to nixpkgs master earlier than the first merge of the PR in commit d58e2d5.

...into staging-next, i.e. this will come to nixpkgs master earlier than the first merge of the PR in commit 2386a5e.

darwin.rewrite-tbd: 20201114 -> unstable-2023-03-27

python310Packages.yarl: 1.8.2 -> 1.9.2

vala: 0.56.7 → 0.56.9

python310Packages.constantly: run tests

pypy3Packages.protobuf: fix build

Upstream is concatenating CMAKE_INSTALL_LIBDIR onto CMAKE_INSTALL_PREFIX to get a directory to use for the install_name on Darwin. This is not the right way of making CMAKE_INSTALL_LIBDIR absolute. The config was first set up for breakage when the CMAKE_INSTALL_LIBDIR was made relative, in order to work around the wrong concatenation. This caused the _IMPORT_PREFIX to be computed by walking up the directory tree from the config file, instead of using the absolute CMAKE_INSTALL_LIBDIR. Then outputs were introduced to the derivation and the config was moved to a different output. Now the prefix it walks up to is the wrong prefix, and the config is busted. Fix by reverting the original workaround so we have an absolute CMAKE_INSTALL_LIBDIR, and pulling a patch that fixes the bad concatenation.

...into staging-next

fixes NixOS#242394

…nfig fluidsynth: Fix CMake config

gcc: restore 'Configured with:' output on 'gcc -v' output

ragel: 47s -> 9s ragelDev: 1m51s 45s

An attempt to remove it was made in NixOS#106886, but there was a build failure. Since that failure no longer occurs, remove it now. Based on thefloweringash/nixpkgs@1904236.

libde265: 1.0.11 -> 1.0.12

Changelog: https://github.com/rubygems/rubygems/blob/v3.4.16/CHANGELOG.md

Changelog: https://github.com/rubygems/rubygems/blob/bundler-v2.4.16/bundler/CHANGELOG.md

GNOME staging updates 2023-07-05

libgudev: 237 → 238

…d x86_64-darwin ...into staging-next

Changelog: https://wiki.mercurial-scm.org/Release6.5

rustc: remove Darwin special-casing

Diff: https://gitlab.freedesktop.org/pipewire/pipewire/-/compare/0.3.73...0.3.74 Changelog: https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/0.3.74

openldap: 2.6.4 -> 2.6.5

Changelog: https://github.com/libsdl-org/SDL/releases/tag/release-2.28.1

[staging-next] SDL2: 2.28.0 -> 2.28.1

[staging-next] Pipewire 0.3.74

mercurial: 6.4.5 -> 6.5

nix-prefetch-git: add sri-hash to output

…ious disable `fortify3` hardening flag on various packages

bundler: 2.4.15 -> 2.4.16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bzip2, zstd: Add `enableStatic` option #237563

bzip2, zstd: Add `enableStatic` option #237563

Commits on Jul 2, 2023

Commits on Jul 3, 2023

Commits on Jul 4, 2023

Commits on Jul 5, 2023

Commits on Jul 6, 2023

Commits on Jul 7, 2023

Commits on Jul 8, 2023

Commits on Jul 9, 2023

Commits on Jul 10, 2023

Commits on Jul 11, 2023

Commits on Jul 12, 2023

bzip2, zstd: Add enableStatic option #237563

bzip2, zstd: Add enableStatic option #237563

Commits on Jul 2, 2023

Commits on Jul 3, 2023

Commits on Jul 4, 2023

Commits on Jul 5, 2023

Commits on Jul 6, 2023

Commits on Jul 7, 2023

Commits on Jul 8, 2023

Commits on Jul 9, 2023

Commits on Jul 10, 2023

Commits on Jul 11, 2023

Commits on Jul 12, 2023

bzip2, zstd: Add `enableStatic` option #237563

bzip2, zstd: Add `enableStatic` option #237563