Same, but looking at commits they seem to have changes to go dependencies -- which I guess aren't needed but probably should be used even so :).
Pointing dep2nix at this resulted in: ed41108 which probably can be picked/squashed or copied from if you like.

@dtzWill If you look at line 24, there version is used. So If I don't change the hash code for it, that's weird. It turns out in the previous update of this file, that wasn't done, even though version was changed... not quite sure why it worked with the previous hash.

At any rate, when I changed version and it's used to fetch from github, changing the hash felt like the right thing to do... Or am I missing something?

as long as the hash in fetchXXX isn't changed and the data is in cache, it won't care about other parameters. So you have to change the version, change one character in the hash so fetchXXX detects the data is not in cache, attempts to fetch it and then errors out with the correct checksum. You can then update the checksum with that one. At least that's how I do it.

@teto yup, that's exactly what I did, too.

Because deps.nix isn't part of what goes into the source hash. So always need to manually check and re-generate that manually, at least for now.

Maybe mention deps.nix near 'src' declaration for future commiters/reviewers.

Maybe mention deps.nix near 'src' declaration for future commiters/reviewers.

@DanielFabian I believe this is all that is outstanding for @teto to merge.

Maybe mention deps.nix near 'src' declaration for future commiters/reviewers.

@DanielFabian I believe this is all that is outstanding for @teto to merge.

sorry, I missed this as a PR comment, I'll do it tomorrow

@GrahamcOfBorg build browsh

tested locally looked ok. thanks !