| 9 Jul 2025 |
 Sarah Clark | Sounds plausible. | 17:14:12 |
| Sarah Clark | So is there a better solution than disabling the failing test(s)? | 17:14:50 |
 emily | you can change build-dir but it risks re-exposing you to CVEs | 17:16:56 |
| emily | maybe you can convince the tests to use shorter paths | 17:17:07 |
| 11 Jul 2025 |
 Axman6 | I think I've asked this before, but asking again because I ran into it again - there's currently no way to get a Universal python via Nix right? The one that macOS ships with (and IIRC the installer from python.org) can build universal stuff when it needs to compile C bits, but the nix provided ones can't. I need to create an executable using pyinstaller, which works fine on aarch64 and x86_64 when using the system python. I had looked into using lipo to combine binaries from the two arches into one, but something conflicts when they're joined (we embed an executable inside this other executable, and I think the two copies conflict in its unpacking, or something ... this sounds a lot like malware now I think about it [and I'm not convinced it's not]) | 01:33:38 |
 Randy Eckenrode | Darwin support in nixpkgs is not really set up to do universal builds except in trivial cases (with no dependencies). | 01:37:56 |
 Zhaofeng Li |
embed an executable inside this other executable
Oof, this will be a problem if you ever want to adopt app sandboxing. Also you have tried that it passes notarization, right?
| 01:41:49 |
| Axman6 | the embedded executable is also signed, and seems to work fine | 03:29:16 |
| Zhaofeng Li | if app sandboxing is enabled, any file you drop will be quarantined and trigger gatekeeper if you execute/dlopen | 03:32:26 |
| Zhaofeng Li | dlopen'ing a signed dylib that already exists in the user's downloads folder does work though | 03:33:27 |
| Zhaofeng Li | * dlopen'ing a signed, non-quarantined dylib that already exists in the user's downloads folder does work though | 03:33:37 |
| Zhaofeng Li | but this is quickly veering into malware-like territory 🫠 | 03:33:58 |
| Zhaofeng Li | anyways, curious to know if it can pass notarization, and whether still passes if the embedded binary does not meet requirements (unsigned, does not have hardened runtime enabled, etc.) | 03:54:33 |
 szlend | I wonder if the build-dir change makes case-sensititive nix store viable on macos | 10:58:50 |
| szlend | One of the issues before the change was that you'd still be building on /tmp (case insensitive) and then move it to /nix/store (which would be case sensitive) | 11:00:21 |
| szlend | but now it's all on the same volume | 11:00:35 |
| emily | the Lix side (who the build-dir change was imported from) have been working towards that, yeah | 11:00:57 |
| emily | there's some missing pieces still | 11:01:03 |
| emily | e.g. some stuff goes into temp-dir (which Nix doesn't have IIRC) and I think some into $XDG_CACHE_HOME, so the latter would have to move if relevant and the former will need to go under /nix and be cleaned up by the daemon | 11:01:42 |
| emily | and use-case-hack needs to become per-store rather than global which is a WIP in Lix I believe | 11:01:57 |
| emily | and then it'll be possible to flip the installer default and do migration tooling | 11:02:09 |
| emily | people have run case-sensitive stores for a good while now though | 11:02:28 |
| emily | it's mostly just worked for me | 11:02:32 |
| emily | just need to set up the temporary dir and disable the case hack and deal with potentially having to manually clean up sometimes | 11:03:18 |
| szlend | fun times ahead | 11:05:58 |
| szlend | can you actually covert to a case sensitive volume without a full copy? | 11:06:17 |
| szlend | migrating this sounds quite awful :D | 11:06:37 |
| emily | nope, it will be a full copy | 11:07:36 |
| emily | post-GC though | 11:07:42 |
| Randy Eckenrode | Seems like you could create a new store volume in the same container and cp the old store. | 11:07:45 |
