| 10 Jan 2025 |
 K900 | Complicated | 16:04:17 |
 Greg Hellings | The more native it stays, the less someone who builds with it needs to ship to users | 16:04:26 |
 emily | indeed | 16:04:35 |
| emily | I think libffi = darwin.libffi is right | 16:04:40 |
| emily | because upstream libffi just did not take some aarch64-darwin stuff | 16:04:49 |
| emily | and packages expect it | 16:04:53 |
| emily | but for ICU I'm not so sure | 16:04:56 |
| emily | bigger API surface, more version-to-version variation, less required by most stuff | 16:05:10 |
| emily | not true, we build Apple's ICU from source | 16:05:32 |
| emily | so it's still /nix/store | 16:05:35 |
| Greg Hellings | Ah. So much for that savings | 16:06:09 |
 Randy Eckenrode | Darwin ICU as default also fixes some Bun issues with npm. | 16:10:59 |
| Greg Hellings | RIP my home computers while I build all of the packages that depend on ICfu | 16:13:50 |
| Greg Hellings | Well that was a fat finger typo, but lol | 16:14:05 |
| K900 | Yeah don't even try that | 16:14:13 |
| Greg Hellings | Too late, I'm 9 minutes into the build | 16:14:25 |
| Greg Hellings | 100,000 to go | 16:14:30 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
if ICU version is going to drift from what Apple tracks we should maybe reconsider coupling darwin.ICU to it. cc Randy Eckenrode I assume Apple will update to ICU76 for the next major release. I don’t know whether they do updates mid-cycle or not. It’s at least not like before where we were way behind what Apple ships. We’re only a month or so behind due to source release delays. | 16:27:56 |
| emily | yeah | 16:29:35 |
| emily | I'm okay sticking with this for now | 16:29:39 |
| emily | but if we run into packages needing special handling on Darwin or breaking because of the ICU version drift I think we should consider flipping back | 16:29:55 |
| emily | you can expect to wait probably over a week for this fwiw. we have staging for a reason | 16:30:19 |
| Greg Hellings | Here's the PR: https://github.com/NixOS/nixpkgs/pull/372692 | 16:31:34 |
| emily | what may be a better idea is to build a selection of packages that directly depend on icu | 16:36:31 |
| emily | for that you will want to make sure your PR's base is the merge-base of master and staging | 16:36:35 |
| emily | to avoid rebuilding for other staging changes | 16:36:39 |
| emily | oh my god why do we have that many ICU versions? we should kill most of those off | 16:37:16 |
| Greg Hellings | So in my branch do something like:
git checkou upstream/master
git merge upstream/staging
<apply change>
?
| 16:39:05 |
| emily | no, rebase on top of $(git merge-base upstream/master upstream/staging) | 16:39:22 |
| emily | CONTRIBUTING.md has an example, I forget the exact incantation because with Jujutsu it's just jj rebase -d fork_point(master, staging)'` :p | 16:39:42 |
