| 20 Mar 2025 |
 emily | it's the manual toil | 21:25:53 |
 John Ericson | emily: the thing that got me before was making a slight tweak to a stdenv script and then rebuilding everything serially, the dream with CA derivations was you could, assuming most things will have the same result, try to rebuild everything in parallel / out of order, using their previous dependencies | 21:38:12 |
| John Ericson | long bootstrapping chains meant lots of O(n) rebuilds when I'd notice a mistake in the things I did to stdenv in some downstream package | 21:39:02 |
| John Ericson | so yes it's manual toil, but debug cycle matters | 21:39:26 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | this whole mess started when i used my unused dependency scanner on mass-rebuild packages. I truly believe there is some potential there to reduce closure size. But i am now seeing iconv is not the first candidate there | 21:46:27 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | i did find our git has a dependency on cpio that has been unnecessary for the past 9 years, for example - git release notes confirm that. However, lesson learned, i will leave iconv alone for now | 21:47:21 |
| John Ericson | Grimmauld (any/all): of course per the above you can see there isn't concensus, but I would still like to know whether it is possible to build glibc without libiconv | 21:53:10 |
| John Ericson | even if stdenv contained libiconv | 21:53:23 |
| John Ericson | it would be nice to build the more minimal thing and then bundle it | 21:53:34 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | oh i am seeing there is no consensus, i am happy you were willing to entertain my dumb unqualified ideas. I am excited to see what comes of your attempt, if you do try - but i think this is beyond me (for now). | 21:55:33 |
| emily | glibc's iconv APIs are not the same as GNU libiconv FYI | 22:20:54 |
| emily | I don't think modifying libc build systems would be a good idea. I think generating stubs of API subsets would be more reasonable. | 22:21:28 |
| emily | (since if we are doing "rearchitect all of Nixpkgs" type solutions then we need dynamic library stubs to get any real advantage out of ca-derivations anyway.) | 22:21:37 |
 Randy Eckenrode | In theory, this is a bug in Apple’s libiconv. According to comments in the source, the rewrite is intended to be compatible with GNU stuff. It’s just not in places. Good luck with submitting feedbacks though …. | 23:59:41 |
| 21 Mar 2025 |
| Randy Eckenrode | Git being a notable example. It depends on a special UTF-8 codec on Darwin to handle Unicode normalization. | 00:01:39 |
| Randy Eckenrode | I would like to fix the libiconv bugs on Darwin eventually (and try to submit at least my tests to Apple in a feedback in the hope they may also fix things in the platform), but I have no bandwidth for that right now. | 00:02:37 |
| Randy Eckenrode | Also, strictly speaking, Darwin doesn’t even really have a libc package anymore. The libc implementation comes dynamically from which SDK you’re using. The libc package is a stub with empty lib and include directories to prevent spurious warnings from breaking things. | 00:03:39 |
| 22 Mar 2025 |
|  cldrpr joined the room. | 11:46:20 |
| 23 Mar 2025 |
|  connor (he/him) (UTC-7) changed their display name from connor (he/him) (UTC-8) to connor (he/him) (UTC-7). | 18:28:15 |
| 25 Mar 2025 |
|  aleksana (force me to bed after 18:00 UTC) changed their display name from aleksana (force me to bed after 18:00 UTC) to aleksana 🏳️⚧️ (force me to bed after 18:00 UTC). | 17:00:06 |
| 26 Mar 2025 |
 Tristan Ross | Trying to get LLVM libc to build in pkgsLLVM.pkgsLLVMLibc.stdenv, aside from dropping compiler-rt and libunwind because those fail, this is also a problem:
FAILED: libc/src/math/generic/CMakeFiles/libc.src.math.generic.issignalingl.dir/issignalingl.cpp.o
/nix/store/rsdq8qwhg80fnmkv1frwdplzqjbrlx68-aarch64-unknown-linux-llvm-clang-wrapper-21.0.0-unstable-2025-03-16/bin/aarch64-unknown-linux-llvm-clang++ -DLIBC_NAMESPACE=__llvm_
libc_21_0_0_git -I/build/libc-src-21.0.0-unstable-2025-03-16/libc -isystem /build/libc-src-21.0.0-unstable-2025-03-16/runtimes/build/libc/include -Werror=date-time -Werror=ung
uarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexc
ept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wno-comment -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -std=gnu++17 -DLIBC
_QSORT_IMPL=LIBC_QSORT_QUICK_SORT -DLIBC_ADD_NULL_CHECKS -fpie -ffreestanding -DLIBC_FULL_BUILD -nostdlibinc -idirafter=/usr/include -ffixed-point -fno-builtin -fno-exceptions
-fno-lax-vector-conversions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -ftrivial-auto-var-init=pattern -fno-omit-frame-pointer -Wall -Wextra -Werror -Wconve
rsion -Wno-sign-conversion -Wdeprecated -Wno-c99-extensions -Wno-gnu-imaginary-constant -Wno-pedantic -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi -Wnewline-eof -Wnonpo
rtable-system-include-path -Wstrict-prototypes -Wthread-safety -Wglobal-constructors -DLIBC_COPT_PUBLIC_PACKAGING -MD -MT libc/src/math/generic/CMakeFiles/libc.src.math.generi
c.issignalingl.dir/issignalingl.cpp.o -MF libc/src/math/generic/CMakeFiles/libc.src.math.generic.issignalingl.dir/issignalingl.cpp.o.d -o libc/src/math/generic/CMakeFiles/libc
.src.math.generic.issignalingl.dir/issignalingl.cpp.o -c /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/math/generic/issignalingl.cpp
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/math/generic/issignalingl.cpp:10:
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/FPUtil/BasicOperations.h:12:
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/FPUtil/FEnvImpl.h:24:
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/FPUtil/aarch64/FEnvImpl.h:25:
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/FPUtil/FPBits.h:21:
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/libc_assert.h:25:
In file included from /build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/OSUtil/io.h:19:
/build/libc-src-21.0.0-unstable-2025-03-16/libc/src/__support/OSUtil/linux/io.h:16:10: fatal error: 'sys/syscall.h' file not found
16 | #include <sys/syscall.h> // For syscall numbers.
| ^~~~~~~~~~~~~~~
I checked the linux headers derivation being used and it doesn't have a sys dir in the include dir.
| 01:45:27 |
 Alyssa Ross | Stuff in sys is usually from libc | 08:44:29 |
| Tristan Ross | Yeah, I've raised this as an issue with the rest of the LLVM libc team | 14:46:54 |
| Tristan Ross | Do we have any blocking changes for 25.05? I know some nice-to-haves.
- https://github.com/NixOS/nixpkgs/pull/391695
- https://github.com/NixOS/nixpkgs/pull/365057
| 16:21:34 |
| 27 Mar 2025 |
| Alyssa Ross | Not aware of any blockers. | 08:37:54 |
| 28 Mar 2025 |
| aleksana (force me to bed after 18:00 UTC) | https://github.com/NixOS/nixpkgs/issues/393496
unclear documentation on setup hooks | 08:14:59 |
|  jappie joined the room. | 15:47:48 |
| 30 Mar 2025 |
 Alexandros Liarokapis | hi all. I am doing a lot of cross-compiling for thumb7-none-eabi* targets.
I had a custom stdenv setup with the arm multi-arch arm-none-eabi toolchain.
That required doing a manual nixpkgs.lib.init instantiation with the /pkgs/stdenv/cross function and custom binutils wrapping. | 10:42:34 |
| Alexandros Liarokapis | This is obviously not a good thing | 10:42:46 |
| Alexandros Liarokapis | It's been more than a year since setting this up and was wondering if I can get clean cross-compilation using clang cross stdenv or similar. | 10:43:36 |
