| 13 Apr 2026 |
 hexa | once memory pressure apparently increases | 00:28:09 |
 Randy Eckenrode | I’ve noticed that too. 😕 | 00:37:01 |
| hexa | Redacted or Malformed Event | 00:37:42 |
|  TikTorchic18 joined the room. | 01:12:12 |
|  kirillrdy joined the room. | 06:39:30 |
 axw | Are there any mdm services in nixpkgs that can be declared? So iOS devices can be managed with nix? | 08:45:32 |
 K900 | I don't think that's a thing | 08:55:07 |
 viraptor | Have you got an example of a project that needs it? I'm happy to add it | 09:17:13 |
 niklaskorz | Gram uses SVG icons: https://codeberg.org/GramEditor/gram/src/branch/main/script/mac-icon-to-car | 09:18:05 |
| niklaskorz | https://codeberg.org/GramEditor/gram/src/branch/main/crates/gram/resources/AppIcon.icon | 09:18:23 |
| niklaskorz | I can fallback to the included PNG icons but the SVG-based one they use for their official distribution does look better 😄 | 09:20:10 |
| viraptor | Just coming back to this to confirm - swift-build is used by xcodebuild normally, right? I'm seeing failures of xcbuild not understanding some of the .xcodeproj setup in swift projects and segfaulting - so we'd still have to fix that part of xcbuild? Or did you mean some clever workaround for this that already exists? | 09:34:58 |
| viraptor | No worries, I'll add the svg support | 09:38:56 |
| niklaskorz | swift-build is basically an official open source reimplementation of xcodebuild if I understood correctly | 09:48:03 |
| niklaskorz | as opposed to the inofficial reimplementation of xcbuild that facebook has abandoned years ago | 09:48:14 |
| niklaskorz | * as opposed to the inofficial reimplementation that is xcbuild, which facebook has abandoned years ago | 09:48:38 |
| niklaskorz | the swift-build README states it's used in Xcode which answers your first question I guess | 09:56:39 |
| viraptor | Ok, it does indeed do the things, I was looking in the wrong repo - it's effectively a plugin. | 10:51:20 |
| viraptor | actool is updated now, feel free to test. I'll get it in nixpkgs later | 10:52:06 |
| viraptor | Digging deeper - turns out it's not https://github.com/swiftlang/swift-build/blob/df624d19606034a214393ecab6baac937518746e/Plugins/run-xcodebuild/run-xcodebuild.swift#L45 it just calls out to xcodebuild through xcrun, so it still depends on Xcode | 11:50:25 |
| niklaskorz | indeed, looks like xcodebuild does the project parsing and then forwards the information to swift-build in the PIF format described here:
https://github.com/swiftlang/swift-build/blob/main/SwiftBuild.docc/Core/project-interchange-format.md | 12:06:59 |
| Randy Eckenrode | I have used swbuild in a derivation to (try to) build an Xcode protect. | 12:22:08 |
| Randy Eckenrode | https://github.com/swiftlang/swift-build/issues/43
That plugin appears to be for running xcodebuild with (your built) Swift Build service.
| 12:23:42 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/477520#issuecomment-3764540038 | 12:25:44 |
| Randy Eckenrode | It failed due to missing yet another proprietary tool. | 12:25:56 |
| viraptor | Thank you very much. The docs for that project are quite poor - I'm really happy you found more details already! | 12:30:20 |
| viraptor | Hmmm... It's just processing a plistxml to generate some scaffolded interfaces. "How hard could that be" feeling is growing... | 12:38:37 |
| viraptor | * | 12:39:10 |
| Randy Eckenrode | I can’t make progress on the ICU issue until I resolve the issue with linking the 26.4 SDK using ld64. | 13:32:22 |
 ankarhem | Do you know if there’s some workaround we can do locally for dotnet until it’s properly fixed? | 13:43:33 |
