| 22 Dec 2025 |
|  @-chi:matrix.org left the room. | 21:48:15 |
 Randy Eckenrode | Not that I can think of. It hasn’t broken Nix or Nixpkgs like updates have in the past. | 21:48:50 |
 Alyssa Ross | poll usability flip-flopping every macOS release is a sort of famous example of macOS POSIX-noncompliance: https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/ | 21:49:59 |
| Alyssa Ross | * poll usability flip-flopping between macOS releases is a sort of famous example of macOS POSIX-noncompliance: https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/ | 21:50:19 |
| Alyssa Ross | it might well presently work, but the track record is not confidence-inspiring | 21:50:48 |
| Alyssa Ross | and since you couldn't tell at build time whether the built program would end up being run on a macOS with broken poll, hardcoding not to use it on macOS was the only sensible solution | 21:52:12 |
| Alyssa Ross | (assuming the complexity of detecting it at runtime isn't worth it) | 21:52:55 |
| Alyssa Ross | * | 21:53:07 |
 Ihar Hrachyshka | it won | 21:55:45 |
| Ihar Hrachyshka | * it won't help us anyway since it doesn't support device files | 21:55:58 |
| Randy Eckenrode | The later poll change appears to have been a bug. | 22:03:10 |
| Randy Eckenrode | Not sure how they passed with the bug though. 🤷🏻♂️ | 22:03:44 |
 Winter | the opposite of nobody fwiw ;) | 22:58:35 |
| Ihar Hrachyshka | checked which fds are opened by qemu. basically, for every process inside the vm, each .so (or .dll for dotnet apps) is in the list for all services. since I'm using the VMs to test changes to my biefy VMs running lots of services (like jellyfin or *arr stack), the list gets exhausted. It's probably a function of these VMs using nix store overlay and not directly copying packages into the VM image. (otherwise I'd expect qemu opening just the image file). | 23:54:21 |
| Ihar Hrachyshka | one probably wouldn't even need to run a lot of services at the same time - just start and stop different processes serially and you should be able to hit the limit eventually. because with each nix store open (even if momentary), a new fd number is allocated sequentially. eventually it will reach 1024. AFAIU the limit is on the fd number, not on the length of the array. | 23:57:29 |
| 23 Dec 2025 |
| Ihar Hrachyshka | this seems to work (setting both macros): https://github.com/booxter/nixpkgs/commit/43a6fcf215ec455b41379d6d68e2a93aff626f26
will now check if setting just -D_DARWIN_UNLIMITED_SELECT is enough. | 00:31:06 |
| Ihar Hrachyshka | (the GPollFD poll_fds[1024 * 2]; /* this is probably overkill */ comment in qemu seems to assume that they don't expect anyone to map the whole distro into VM :D) | 00:31:38 |
| Ihar Hrachyshka | * (the GPollFD poll_fds[1024 * 2]; /* this is probably overkill */ comment in qemu seems to suggest that they don't expect anyone to map the whole distro into VM :D) | 00:33:31 |
| Ihar Hrachyshka | * checked which fds are opened by qemu. basically, for every process inside the vm, each .so (or .dll for dotnet apps) is in the list for all services. since I'm using the VMs to test changes to my beafy VMs running lots of services (like jellyfin or *arr stack), the list gets exhausted. It's probably a function of these VMs using nix store overlay and not directly copying packages into the VM image. (otherwise I'd expect qemu opening just the image file). | 00:33:59 |
| Ihar Hrachyshka |
one probably wouldn't even need to run a lot of services at the same time - just start and stop different processes serially
Actually this is not true since fds are reused. one has to hold on to the fd (e.g. with a process running inside the VM).
| 00:56:00 |
| Randy Eckenrode | $ nix build -f . swiftPackages.swift-format
$ result/bin/swift-format --version
6.2.3
| 03:37:31 |
| Randy Eckenrode | That’s with the hook vendoring the packages from nixpkgs and propagating swift-corelibs-xctest automatically from swift. | 03:37:56 |
| Randy Eckenrode | {
lib,
fetchFromGitHub,
mkSwiftPackage,
swift-argument-parser,
swift-markdown,
swift-syntax,
stdenv,
swift_release,
}:
mkSwiftPackage (finalAttrs: {
pname = "swift-format";
version = swift_release;
src = fetchFromGitHub {
owner = "swiftlang";
repo = "swift-format";
tag = "swift-${finalAttrs.version}-RELEASE";
hash = "sha256-DhTtGU2B9BIyN6PyLBlg7kIs3cVyRl6Pa9G0txzta0g=";
};
postPatch =
# Fix the deployment target or compiling code using XCTest fails.
lib.optionalString stdenv.hostPlatform.isDarwin ''
substituteInPlace Package.swift \
--replace-fail '.macOS("13.0")' ".macOS(\"$MACOSX_DEPLOYMENT_TARGET\")"
'';
buildInputs = [
swift-argument-parser
swift-markdown
swift-syntax
];
})
| 03:39:01 |
 Katalin 🔪 | cool! | 03:39:21 |
| Randy Eckenrode | swift package edit lets me handle vendoring in a better way than what we were doing before. | 03:39:52 |
| Randy Eckenrode | The inputs are just source packages. With traits, I don’t think we can reliably pre-compile dependencies. | 03:40:12 |
| Randy Eckenrode | (Even if we could fool SwiftPM into using them.) | 03:40:20 |
| Randy Eckenrode | Next is splitting out Swift Syntax from the compiler, so it looks like a normal package and works with SwiftPM’s special support for providing pre-built Swift Syntax binaries. | 03:41:21 |
| Katalin 🔪 | I'll have to test this with Meson at some point too | 03:42:35 |
| Katalin 🔪 | but I assume it'll just work | 03:43:00 |
