| 4 Oct 2025 |
 dramforever | this include path is correct | 15:48:59 |
| dramforever | but it still can't find stdarg.h | 15:49:03 |
 Lun | -idirafter /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
-isystem /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/include/c++/v1
-isysroot /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
-D TARGET_OS_IPHONE=0
--stdlib=libc++
-internal-isystem /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/bin/../include/c++/v1
-internal-isystem /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include
-internal-isystem /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/lib/clang/21/include
-internal-externc-isystem /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
-internal-iframework /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
-internal-iframework /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/SubFrameworks
-internal-iframework /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks
sdk/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include ending up as idirafter and as internal-externc-isystem seems odd
| 15:58:59 |
| Lun | * -resource-dir /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/lib/clang/21
-idirafter /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
-isystem /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/include/c++/v1
-isysroot /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
-D TARGET_OS_IPHONE=0
--stdlib=libc++
-internal-isystem /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/bin/../include/c++/v1
-internal-isystem /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include
-internal-isystem /nix/store/pykdcvv5v3rv4h62gnxmqgdhimyv7y9x-bootstrap-tools/lib/clang/21/include
-internal-externc-isystem /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
-internal-iframework /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
-internal-iframework /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/SubFrameworks
-internal-iframework /nix/store/wf9x4kaaykhnq72v6xvxncp2h2sl97zw-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks
sdk/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include ending up as idirafter and as internal-externc-isystem seems odd
| 15:59:33 |
| dramforever | i give up, whoever actually knows what's going on with macos can take a look | 16:08:58 |
| Lun | --sysroot's /usr/include is implicitly added as an ExternCSystem in AddClangSystemIncludeArgs so we probably shouldn't be adding it manually as well | 16:10:23 |
| dramforever | darwin stdenvBootstrap fixes is button-ready https://github.com/NixOS/nixpkgs/pull/448523 | 20:03:54 |
| dramforever | maybe | 20:07:48 |
| dramforever | it definitely builds though | 20:08:00 |
| dramforever | Backported the qt5.qtdeclarative RegisterID thing. I made it conditional on x86_64-darwin for now to avoid rebuilds... is this normal? https://github.com/NixOS/nixpkgs/pull/448633 | 21:22:17 |
| dramforever | AFAICT, it really is the right fix for qt5 as well, and not just a patch miracle | 21:23:06 |
 Sergei Zimmerman (xokdvium) | I wonder if there's a way that we can shut Boehm up | 23:14:09 |
| Sergei Zimmerman (xokdvium) | This is beyond funny :( | 23:18:02 |
| 5 Oct 2025 |
 Vladimír Čunát | 28k jobs queued in staging-next, huh. | 07:31:38 |
| Vladimír Čunát | But now it might be in a mergable state, after progressing with the rebuilds. | 07:33:20 |
 K900 | Do we know what's causing the rebuilds? | 07:46:19 |
| Vladimír Čunát | I don't think it's a problem really. Several more hours of "waiting". | 07:49:17 |
| Vladimír Čunát | We seem to be waiting more for humans. | 07:49:35 |
| Vladimír Čunát | I guess I'll cancel the trunk-combined eval. Lots of expensive jobs for Hydra (tests), and I hope we'd merge staging-next today. | 07:53:12 |
| Vladimír Čunát | nixos-unstable is on a 3 days old commit right now. Not that bad, I'd say. | 07:53:41 |
 hexa | what are the chances we'll have staging-25.05 after this? | 12:09:10 |
| K900 | pls no | 12:25:41 |
| hexa | then no valkey security fixes for nixos-25.05 | 12:27:34 |
| hexa | * then no valkey security fixes for nixos-25.05 🤷 | 12:27:39 |
| hexa | commit 2c16b1b1617a21c3e2c005a34d421a1b63864544 (mweinelt/valkey-8.1.4, valkey-8.1.4)
Author: Martin Weinelt <hexa@darmstadt.ccc.de>
Date: Sat Oct 4 22:15:11 2025 +0200
valkey: 8.1.3 -> 8.1.4
https://github.com/valkey-io/valkey/releases/tag/8.1.4
Fixes: CVE-2025-49844, CVE-2025-46817, CVE-2025-46818, CVE-2025-46819
commit 29d5e4b3a716a11b7eb401ba06af8e0fc437c9d3
Author: Martin Weinelt <hexa@darmstadt.ccc.de>
Date: Sat Oct 4 21:10:49 2025 +0200
redis: 8.0.3 -> 8.2.2
https://github.com/redis/redis/releases/tag/8.2.0
https://github.com/redis/redis/releases/tag/8.2.1
https://github.com/redis/redis/releases/tag/8.2.2
Fixes: CVE-2025-49844, CVE-2025-46817, CVE-2025-46818, CVE-2025-46819
commit 3886232a1c7e3da5415d60360dd9eff7d0641cb0
Author: Thomas Gerbet <thomas@gerbet.me>
Date: Sat Oct 4 17:39:16 2025 +0200
fetchmail_7: unstable-2022-05-26 -> 7.0.0-alpha11
Fixes CVE-2025-61962.
commit 49314339f51950017816aac9d50bdd3a5fe430f5
Author: Thomas Gerbet <thomas@gerbet.me>
Date: Sat Oct 4 17:33:23 2025 +0200
fetchmail: 6.5.1 -> 6.5.6
Fixes CVE-2025-61962.
https://sourceforge.net/p/fetchmail/git/ci/6.5.6/tree/NEWS
commit 3509c9149c8b8749d4e1e6dbc1373407e1fde3af
Author: Thomas Gerbet <thomas@gerbet.me>
Date: Sat Oct 4 15:23:15 2025 +0200
gegl: 0.4.62 -> 0.4.64
Fixes CVE-2025-10921.
Changes:
https://gitlab.gnome.org/GNOME/gegl/-/commits/GEGL_0_4_64?ref_type=tags
commit 9c768f1f9317a9394c400abb88e2adce89b73c28
Author: networkException <git@nwex.de>
Date: Thu Oct 2 20:55:46 2025 +0200
ungoogled-chromium: 140.0.7339.207-1 -> 141.0.7390.54-1
https://developer.chrome.com/blog/new-in-chrome-141
https://developer.chrome.com/release-notes/141
https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html
This update includes 21 security fixes.
CVEs:
CVE-2025-11205 CVE-2025-11206 CVE-2025-11207 CVE-2025-11208
CVE-2025-11209 CVE-2025-11210 CVE-2025-11211 CVE-2025-11212
CVE-2025-11213 CVE-2025-11215 CVE-2025-11216 CVE-2025-11219
commit 0266e36ed7ba9b55cc7eef391f998b6ea8ec8937 (mweinelt/django-5.2.7, django-5.2.7)
Author: Martin Weinelt <hexa@darmstadt.ccc.de>
Date: Thu Oct 2 17:29:56 2025 +0200
python3Packages.django_5_1: 5.1.12 -> 5.1.13
https://docs.djangoproject.com/en/5.1/releases/5.1.13/
https://www.djangoproject.com/weblog/2025/oct/01/security-releases/
Fixes: CVE-2025-59681, CVE-2025-59682
commit 4aad373382d54920a4987d85337b6cd3f52e894a
Author: Martin Weinelt <hexa@darmstadt.ccc.de>
Date: Thu Oct 2 17:26:54 2025 +0200
python3Packages.django_5_2: 5.2.6 -> 5.2.7
https://docs.djangoproject.com/en/5.2/releases/5.2.7/
https://www.djangoproject.com/weblog/2025/oct/01/security-releases/
Fixes: CVE-2025-59681, CVE-2025-59682
| 12:47:06 |
| hexa | e.g. blocking a browser update | 12:47:56 |
| hexa | * e.g. blocking a major browser update | 12:48:01 |
| Vladimír Čunát | staging-next merged | 13:33:05 |
| K900 | So are we doing 25.05 then | 13:34:14 |
| K900 | With the Redis fixes | 13:34:33 |
