| 10 Jan 2025 |
 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 |
| emily | I think we can't autoreconf GCC in the bootstrap | 17:10:30 |
| emily | because we don't have autoconf when we first build GCC | 17:10:36 |
| emily | not sure though | 17:10:38 |
| lzcunt | oh that would be a shame | 17:11:09 |
| Greg Hellings | Depend on them? Not really. But the master branch still didn't have the darwin.ICU changes when I was working on this last night. Those were in staging | 17:32:37 |
