| 22 Nov 2024 |
 magic_rb | Zfs without dedup eats memory because of ARC, the solution there is to tel zfs to keep minimum of X GB free, so that other software doesnt think its under constant memory pressure | 17:04:12 |
| magic_rb | (ARC is the zfs equivalent of the page cache on linux) | 17:04:38 |
|  Jakob Schöttl set their display name to Jakob Schöttl. | 18:10:33 |
|  BigBabyThor joined the room. | 18:47:46 |
|  @tanvir:hackliberty.org joined the room. | 20:14:30 |
| 23 Nov 2024 |
|  @earthwalker31:tchncs.de joined the room. | 09:45:24 |
 @ehrenschwan:matrix.org | Hi, I'm working on an automated update of my flake inputs and then remote switch of all my servers. I'm using a systemd service with a timer to run a script on my desktop workstation which i always leave on to update the input, test the builds using build-vm and then switching the config on the servers. I would also like to switch the config of my workstation but the switch stops the systemd service which then stops the switch, does anyone here have a similar setup and a solution to that problem? I'm thinking a cron job instead of systemd timer would maybe do it, but the wiki says it's recommended to use a systemd timer and I would prefer this for the journalctl logs. | 12:25:57 |
|  startswithbalint joined the room. | 20:48:52 |
| 24 Nov 2024 |
|  Lzebulon joined the room. | 00:41:11 |
| 25 Nov 2024 |
|  Sefodopo joined the room. | 07:12:52 |
|  Noa changed their display name from Noa Aarts to Noa. | 07:44:04 |
|  @soywod:matrix.org joined the room. | 08:54:54 |
| @soywod:matrix.org | Hi 👋
How reliable is Nix for building release binaries targeting non-Nix systems?
I try to use Nix inside my CI for building (and cross-building) release binaries. People who download such binaries are mostly non-Nix users. I'm facing issues and dilemna with both static and dynamic linking:
- Static builds improve portability, but only on Linux. On MacOS it looks like it's not possible to fully statically link, and on Windows (via cross-compilation) it's a pain to make it work.
- Dynamic builds need to be ELF-patched due to interpreter pointing to
/nix/store, but I'm not sure how reliable it is for MacOS and Windows (versus native builds). If the CI builds a dynamically-linked release for MacOS, does a non-Nix user will be able to use it properly?
| 09:06:58 |
 elikoga | https://github.com/hsjobeki/nixpkgs/blob/migrate-doc-comments/pkgs/build-support/release/debian-build.nix
https://noogle.dev/f/pkgs/releaseTools/debBuild
https://wiki.nixos.org/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkgs
This one gets you pretty far in one direction, not sure if it's the direction you want to go to | 09:11:38 |
 emily | we have static-enough linking for macOS | 09:13:43 |
| emily | libSystem will be dynamically linked, but that is true of all macOS binaries | 09:13:55 |
| emily | in general system frameworks are part of the OS and don't get statically linked | 09:14:05 |
| emily | as long as you use a deployment target corresponding to the minimum macOS version you support, pkgsStatic should work just fine (if there aren't packages it's broken with that you use) | 09:14:35 |
| emily | (current default minimum is 10.12 on x86_64-darwin and 11.0 on aarch64-darwin; in 25.05 it will be 11.3 across the board; in 25.11 it will be 14.x across the board) | 09:15:05 |
| emily | with macOS you can do relative rpaths and stuff, but generally we use absolute ones. it's possible that install_name_tool will let you patch them up enough for it to work. there's various scripts out there for copying dylibs into .app bundles and rewriting the paths appropriately; perhaps you could use one of them | 09:15:57 |
| magic_rb | @soywod:matrix.org as for windows, cross compiling to it using mingw is pretty painless. You do have to do what every windows does anyway, which is shipping a buttload of DLLs. I managed to cross compile Haskell too and disregarding the problems with GHC it was actually easy | 09:16:25 |
| @soywod:matrix.org | Thanks a lot for your answers, really helpful. So in conclusion static linking is reliable enough for deploying multi-platform releases, right? Regarding Windows I will dive a bit more, I may took a wrong direction. | 09:19:05 |
| @soywod:matrix.org | * Thanks a lot for your answers, really helpful. So in conclusion static linking is reliable enough for deploying multi-platform releases, right? Regarding Windows I will dive a bit more, I may have taken a wrong direction. | 09:21:12 |
| magic_rb | For linux its reliable enough, for windows just go with dynamic and ship the DLLs, thats what everyone does | 09:22:04 |
 flyx | I have written a blog post some time ago about cross-compiling and packaging with Nix Flakes, perhaps that's helpful for you: https://flyx.org/cross-packaging/
However this does not use Nix' cross-compiling capacities, instead it relies on Zig for providing a cross-compiling clang setup. OTOH it can build .deb packages with dynamic linking that depend on other .deb packages | 09:22:06 |
| emily | for macOS, reliable enough insofar as if something builds on pkgsStatic, and it would hypothetically work if you move all the .dylibs around and rewrite them, then it should work with pkgsStatic | 09:22:52 |
| emily | YMMV, still nominally experimental, report bugs if you find them, but it's meant to work now | 09:23:05 |
| emily | there's probably plenty of stuff that doesn't quite build with pkgsStatic currently | 09:23:40 |
| emily | and if you want to target macOS versions unsupported by Apple then that will get tricky from 25.11 | 09:23:42 |
| startswithbalint | I couldn’t quite figure it all out. I tried just building in my devenv and then using patchelf but that didn’t work for all dependencies when I tried to run it on Ubuntu without Nix for some reason. I thought about just trying with an Ubuntu container, more generally a container for every environment I need to build for. I want to also look into the solutions listed here | 09:40:30 |
