| 10 Jan 2025 |
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 |
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:48 |
Greg Hellings | Hmm. This is some git arcana I have not encountered before. But I'm fairly sure I get what it's doing. | 16:42:08 |
emily | the merge base of master and staging is the "highest" commit that is present in both branches | 16:43:36 |
emily | master is periodically merged (via staging-next) into staging, but only every 6 hours, so master usually has commits not on staging (that would show up as "extra" in a staging PR if you used them as a base for your changes) | 16:43:37 |
Greg Hellings | Ooof, that's going to be a monster to rebase. I took this branch already off of staging, so it's trying to do lots of weird stuff | 16:43:50 |
emily | by using the newest master commit that's already merged into staging, you get a commit based on something that will have most stuff cached, but that cleanly merges into staging | 16:43:52 |
emily | so you can test it without mass rebuilds | 16:43:56 |
emily | probably you just gave it the wrong commit to start with | 16:44:07 |
Greg Hellings | I'm fairly sure I'm going to have mass rebuilds anyway with where ICU lives in the stack, lulz | 16:46:09 |
Greg Hellings | So the example in CONTRIBUTING.md is based on the assumption the branch is based off master. Mine isn't, mine is based directly on the staging branch already | 16:47:22 |
Greg Hellings | So trying to do that rebase onto the merge-base of the two was giving me a massive list of conflicts | 16:47:51 |
lzcunt | Hey there, regarding https://github.com/NixOS/nixpkgs/pull/370683 I think I have finally fixed the regression but it involves autoreconf-ing gcc, should I just always autoreconf or only when withoutTargetLibc? | 17:01:06 |
lzcunt | * Hey there, regarding https://github.com/NixOS/nixpkgs/pull/370683 I think I have finally fixed the regression but it involves autoreconf-ing gcc, should I just always autoreconf or only when withoutTargetLibc? Don't bother checking the PR it's not pushed yet | 17:01:43 |
emily | do you actually depend on changes in staging? | 17:10:16 |
emily | or do they just happen to be in the stack? | 17:10:19 |