Skip to content

replibyte: don't vendor Cargo.lock file, add patch for wasm-bindgen #408913

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

TomaSajt
Copy link
Contributor

Here's an interesting situation:

As some might know, Rust 1.80 broke certain versions of the time crate, so all packages using it needed to bump the version of the time crate they used.
This package also seemed to use a broken version of the time crate so a PR was made to bump the time crate version: #356469

However, turns out the package doesn't actually depend on a broken version of the time crate:
only versions between 0.3.18 and 0.3.54 were affected, and according to the Cargo.lock inside the src, this package only uses 0.3.9 and below.

So why was it broken anyway?
It turns out, for whatever reason, in #294960, when this package was last version-bumped, the Cargo.lock wasn't copied from src, but from somewhere else, (maybe some other, newer revision, or maybe it was generated manually, idk).
And in that lockfile, the time crate used was version 0.3.36; so it was affected by the breakage.

This means we could have just used the original Cargo.lock file the whole time... Cool.

However, since then, we have reached an even newer version of Rust, which doesn't support the old version of wasm-bindgen in the actual lockfile.
But since the lockfile currently vendored just accidentally handled this issue because it already contains a more updated version of wasm-bindgen.

But once I reverted to using the lockfile from src, the wasm-bindgen issue did actually appear, so I had to keep the version bump of wasm-bindgen as a patch.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
  • NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@github-actions github-actions bot added 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-linux: 1 This PR causes 1 package to rebuild on Linux. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels May 20, 2025
@nix-owners nix-owners bot requested a review from dit7ya May 20, 2025 01:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. 10.rebuild-linux: 1 This PR causes 1 package to rebuild on Linux.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant