| 6 Jul 2025 |
 Andrew | Maybe https://github.com/rust-cross/cargo-xwin can just work. Though no Nix and no native dx support. | 18:55:20 |
| 7 Jul 2025 |
 Charles ⚡️ | cargo-llvm-cov added a git dev-dependency in its latest release that isn't reflected in Cargo.lock on crates.io, breaking nixpkgs' "download the lockfile from crates.io and build against that to avoid checking the entire lockfile into nixpkgs" workflow: https://github.com/taiki-e/cargo-llvm-cov/commit/fb528c913f5b5577b6971dae9d99d70babdd42e0 | 06:49:53 |
| Charles ⚡️ | how should i deal with this | 06:49:59 |
| Charles ⚡️ | i can think of two options:
- bug the maintainer to make a new release that fixes the crates.io lockfile (crates.io allows git dependencies in dev-dependencies)
- something else
| 06:50:35 |
| Charles ⚡️ | i feel like at this point i would prefer "something else" but i'm not sure what that should/could be | 06:51:42 |
| Charles ⚡️ | since it seems like repeatable builds are really not a priority for this maintainer | 06:51:56 |
| Charles ⚡️ | * cargo-llvm-cov added a git dev-dependency in its latest release that isn't reflected in Cargo.lock on crates.io, breaking nixpkgs' "download the lockfile from crates.io and build against that to avoid checking the entire lockfile into nixpkgs" workflow: https://github.com/taiki-e/cargo-llvm-cov/commit/fb528c913f5b5577b6971dae9d99d70babdd42e0 | 06:52:51 |
| Charles ⚡️ | i guess checking in cargo.lock isn't that uncommon:
$ fd 'Cargo\.lock' | wc -l
110
| 06:55:59 |
| Charles ⚡️ | * i guess checking in cargo.lock isn't that uncommon:
$ fd '^Cargo\.lock$' | wc -l
97
| 06:56:26 |
|  Robert Rose changed their display name from Robert Rose - 🌴 04.07 to Robert Rose. | 07:58:40 |
|  wonrax joined the room. | 08:37:31 |
 Toma | There used to be a lot more but I removed most of them... Anyways:
In this case I think it is fine to eat the bullet if the lockfile is not crazy large.
But in case you really don't want to:
- Fetch the lockfile from crates-io into your local git checkout, (you may need to remove it from .gitignore first)
git add it,- run any cargo command that tries to generate the lockfile (e.g. cargo build)
- generate a patch file via
git diff
- in nixpkgs add the patch file to
cargoPatches
- profit?
At least I think this could work.
You might be better off vendoring the lockfile.
| 12:31:15 |
| Toma | * There used to be a lot more but I removed most of them... Anyways:
In this case I think it is fine to eat the bullet if the lockfile is not crazy large.
But in case you really don't want to:
- Fetch the outdated lockfile from crates-io into your local git checkout, (you may need to remove it from .gitignore first)
git add it,- run any cargo command that tries to generate the lockfile (e.g. cargo build)
- generate a patch file via
git diff
- in nixpkgs add the patch file to
cargoPatches
- profit? (if the patch is not too large)
At least I think this could work.
You might be better off vendoring the lockfile.
| 13:00:29 |
|  nbp changed their display name from nbp — PTO to nbp. | 13:11:39 |
| Charles ⚡️ | yeah i had considered that, but it seems more convoluted and annoying to maintain | 14:26:36 |
| Charles ⚡️ | i made a PR that vendors the lockfile last night (about 8 hours ago) and it's merged now, so | 14:27:07 |
| Charles ⚡️ | really wish people would just commit their lockfiles | 14:27:49 |
|  istipisti113 joined the room. | 16:32:49 |
|  @jackleightcap:matrix.org left the room. | 18:09:41 |
|  @saiko:knifepoint.net changed their display name from Katalin ⚧︎ to Katalin 🔪. | 23:28:49 |
| 9 Jul 2025 |
|  sohrobinator joined the room. | 04:00:45 |
| sohrobinator changed their display name from Sohrob Tahmasebi to sohrobinator. | 04:04:04 |
| sohrobinator changed their display name from Sohrob Tahmasebi to sohrobinator. | 04:04:04 |
| sohrobinator set a profile picture. | 04:04:35 |
|  atagen joined the room. | 07:40:33 |
| 10 Jul 2025 |
 undltd | At least for a package that contains both the code and default.nix (and flake.nix, but that shouldn't be relevant), setting cargoDepsName = pname; doesn't seem to have the effect of decoupling cargoHash from the package version, at least when the version in default.nix and Cargo.toml are the same. I.e., if I change the package version in Cargo.toml, cargo also updates the version in Cargo.lock, and cargoHash changes. I'm a bit confused by the documentation though:
>> The tarball with vendored dependencies contains a directory with the package’s name, which is normally composed of pname and version. This means that the vendored dependencies hash (cargoHash) is dependent on the package name and version. The cargoDepsName attribute can be used to use another name for the directory of vendored dependencies. For example, the hash can be made invariant to the version by setting cargoDepsName to pname: <...>
This sounds as though cargoHash wound then not depend on the package version anymore, but this is not what I see in practice.
Additionally, adding or removing cargoDepsName = pname; does not change cargoHash - but I expected it to change based on the quoted paragraph from the docs (i.e., the directory name inside the tarball should have changed). What does cargoDepsName really do? | 20:09:45 |
| undltd | The package in question: https://codeberg.org/undltd/om/src/branch/main/default.nix | 20:11:23 |
| 11 Jul 2025 |
| Toma | Oh wow, this info is outdated.
I guess this part of the docs was not updated when we removed fetchCargoTarball
With the new fetcher there is no difference in the hash, even if you use a different name/version or whatever.
(Note: cargoDepsName does not do anything currently as far as I'm aware) | 01:30:40 |
| undltd | I see, I suspected there might have been a recent change. It does seem to change the name of some intermediate derivation, but doesn't look like it affects the hash.
Do I understand correctly that cargoHash depends not only on the tarball of vendored dependencies, but also on the (hash of) Cargo.lock? | 06:18:16 |
|  sodiboo joined the room. | 07:12:29 |
