| 22 Dec 2025 |
 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 |
| Randy Eckenrode | mkSwiftPackage is a helper that sets up packages to be consumable as inputs. | 03:43:48 |
| Randy Eckenrode | It’s not currently available outside of the Swift package set. | 03:44:13 |
| Randy Eckenrode | * mkSwiftPackage is a helper that sets up package sources to be consumable as inputs. | 03:44:31 |
| Katalin 🔪 | ah no, I mean your new swift changes in general. this one is swiftpm-specific (or at least, it won't work as-is with Meson subprojects) | 03:46:01 |
| Randy Eckenrode | Swift is still unwrapped. Meson may need help finding things. | 03:46:25 |
 K900 | @emilazy:matrix.org have you tested uncursed xorg yet | 08:22:44 |
| K900 | I kinda want to merge it before people start touching it again | 08:23:14 |
