The PR's base branch is set to staging, but 5 commits from the master branch are included. Make sure you know the right base branch for your changes, then:

• If the changes should go to the master branch, change the base branch to master
• If the changes should go to the staging branch, rebase your PR onto the merge base with the staging branch:

  # git rebase --onto $(git merge-base upstream/staging HEAD) $(git merge-base upstream/master HEAD)
  git rebase --onto 6c76fd5f512e3225ecff578ded7cbe74347253cc 2c8c54ac2176d8201d8c97b23d8c0d06b303e704
  git push --force-with-lease

Github messed up the rebasing on staging. I hope I did it correctly manually. Sorry for the extra pings.

NOTE: I checked the "built" box above. Haven't built these on op of staging though. They did work on master.

With 1001-2500 you really should keep targeting staging. This is roughly 4.5k rebuilds spread out over 4 targets.

Never thought about that. The actual number of rebuilds is 2*linux+2*darwin... Also because there's 3 python module updates this PR tanks a whole lot more rebuilds...

guess because the rebuild count comes from the vim plugins which isn't deemed as heavy for hydra?

IIRC vim plugins aren't built by hydra, and they're unlikely to be transitive dependencies of anything that is. So as far as hydra is concerned, a vim plugins update is close to zero rebuilds.

So anything still blocking this? AFAICT 0.25.6 is still the latest version of TS, so that should be fine.

So anything still blocking this? AFAICT 0.25.6 is still the latest version of TS, so that should be fine.

@mrcjkb any objection to merging this?

So anything still blocking this? AFAICT 0.25.6 is still the latest version of TS, so that should be fine.

@mrcjkb any objection to merging this?

Nope, no objections on my end

Bisect says b0ca5ddc9916f66d40648f20757ed7f56b33d501 tree-sitter: 0.25.4 -> 0.25.6 broke hash checks in staging as:

$ nix build nixpkgs/staging#tree-sitter -L
...
tree-sitter> Fetching https://crates.io/api/v1/crates/yoke-derive/0.7.5/download -> tarballs/yoke-derive-0.7.5.tar.gz
error: hash mismatch in fixed-output derivation '/nix/store/dxyarsk54pxzjfkv2wwbmcng4zz2yy41-tree-sitter-0.25.6-vendor-staging.drv':
         specified: sha256-/KCvLsbb6DullLpRoSYbxtSsm/TMc6o0Y/QmK6BN748=
            got:    sha256-sGh16M7cbT5ct1sT2FcUUoIQFcoOftTuQ0aSCjtkTEs=

Ouch, I might've done the conflict resolution wrong:

• I started this PR off of master (bad idea...)
• I then rebased to staging
• I saw 3 cargoHash values in the conflict markers and chose the wrong one, you can see in the diff of this PR that it was left unchanged.

My bad. I'm sorry for messing up. Fixing it right now. Might take a while because I want to reproduce the build and make sure I'm correct this time.

python3Packages.tree-sitter still remains broken on the current staging-next branch #422427

ValueError: Incompatible Language version 15. Must be between 13 and 14

I think it's outdated and they haven't released an update yet: https://github.com/tree-sitter/py-tree-sitter/releases

So I guess that package should get meta.broken = true;... Or we could set it to an unstable version somewhere after this PR

A report estimates the number of jobs blocked by this as ~850 so far, so this might be quite a significant breakage.

Because of a minor version bump, or because tree-sitter reverse dependencies aren't up-to-date with TS 0.25 yet? I don't suspect reverting helps here. I'm sorry if this PR is a nuisance to you, just wanted to update a package...