| 21 Sep 2025 |
 Wolfgang Walther | That's whenever you change the base branch of a PR. It's a lot less spammy than the alternatives. | 08:43:28 |
 maralorn | It prevents the mass pings? | 08:45:39 |
| Wolfgang Walther | No, it prevents having to run CI on edited events, which happen for the base branch, but also for any PR title or description changes. If you run CI on these, but skip the jobs, the job log is spammed with a lot of skipped jobs. | 08:52:35 |
 sterni (he/him) | maralorn: will get better as builds finish. for now you can base the PRs themselves on haskell-updates which has cache | 10:37:02 |
| maralorn | Yeah, that’s what I am doing. | 10:39:37 |
| maralorn | Currently fixing HLS on 9.6 and 9.4 which is a complete nightmare. | 10:39:52 |
| sterni (he/him) | emily: if both work, is it preferrable to use python3.pkgs.xattr or darwin.xattr? I originally packaged the latter because xattr/xattr lacked some flags but seems like they merged Apple's changes back… | 14:19:57 |
 emily | hmm, I think we use darwin.file_cmds (which xattr is now an output of) for very little, e.g. we use GNU coreutils over the BSD-derived Darwin commands generally… so using whatever "everything else" uses generally seems sensible to me. OTOH, why is the other one… Python? it's a C codebase, right? | 14:23:30 |
| emily | I guess it looks like either they ported the main() to Python, or they forked from Apple when its main() was Python but Apple have since ported it to C?! | 14:24:13 |
| emily | it seems nice to avoid a runtime dependency on Python but I don't know if GHC already pulls that in | 14:24:41 |
| emily | I would say, if this is an "if Darwin, one package, else another" type thing, and the fallback case works fine, then just do that. if it's a dependency only used on Darwin, file_cmds seems more canonical. | 14:24:59 |
| emily | it looks like GHC is literally the only thing using darwin.(file_cmds.)xattr, though, and the only other thing using darwin.file_cmds is the somewhat stupendously useless darwin.mail_cmds. so if I ever get around to cleaning up some of the source releases that seem like busywork to maintain it's possible it would go away anyway. (OTOH maybe Swift Build will make them less busywork since we can reuse the upstream build systems more.) | 14:26:57 |
| emily | uh, what does GHC want an xattr(1) for, anyway? | 14:27:04 |
| sterni (he/him) | https://gitlab.haskell.org/ghc/ghc/-/commit/bf65a7c388b | 14:41:54 |
| sterni (he/him) | I never checked whether it is actually necessary, Randy set XATTR=/does-not-exist for some bindists. I just packaged the darwin one when GHC started failing because it started executing /usr/bin/xattr | 14:42:43 |
| sterni (he/him) | emily: ah it used to be a literal fork of the python one (i.e. apple distributed the original (?) tarball and an ed(1) script) http://github.com/nixos/nixpkgs/commit/283d622397539f196416657da9dc804a4ca89846 | 14:48:17 |
| sterni (he/him) | I guess now that that has changed, we it is better to use the C one | 14:48:29 |
| emily | the Nix store can't contain xattrs | 14:48:50 |
| emily | I believe it strips them automatically | 14:48:55 |
| emily | so most likely you do not need to give it anything | 14:49:01 |
| sterni (he/him) | but on write or on fixup | 14:49:14 |
| sterni (he/him) | though I guess that doesn't matter | 14:49:33 |
| emily | https://github.com/NixOS/nix/commit/d798349ede3d6eb6e92a2e4f95f6b2179407ceb9 | 14:49:35 |
| emily | uhh, #if __linux__ :) | 14:49:44 |
