ccemux: mark broken (download fails hash validation)#272193
Conversation
| sourceProvenance = with sourceTypes; [ binaryBytecode ]; | ||
| license = licenses.mit; | ||
| maintainers = with maintainers; [ CrazedProgrammer viluon ]; | ||
| broken = true; # download of CCEmuX-cct.jar fails hash validation |
There was a problem hiding this comment.
Since I don't use this software I am not qualified to decide if that's safe.
Usually the best course here is to mark the package as broken and if nobody steps up, let the package get garbage-collected. If somebody does step up to audit the mysteriously-changed binary jarfile, and wants to take the reputational risk upon themselves, more power to them!
There was a problem hiding this comment.
maybe @viluon can have a look ( last committer ), otherwise I agree with your assessment
There was a problem hiding this comment.
I agree with @amjoseph-nixpkgs . My nitpick is to open a tracking issue and reference it. So discussions of fixing that package happens in that issue. And add the day the breakage is being reported.
There was a problem hiding this comment.
Upstream doesn't do version control on binaries AFAIK. The maintainer will have to be on top of version bumps to avoid this issue from happening. I don't use Nix, so I don't know if this is an option (probably isn't), but it may also be necessary to skip checking hashes to avoid breakages between updates.
Disregard this, I've been corrected.
There was a problem hiding this comment.
Nah, see CCEmuX/CCEmuX#167. Thanks @kirillrdy for the mention.
|
Per @SquidDev's response, it should be safe to just update the hash, although the package will remain flaky. I agree that a full Nix build would be better, maybe the original packager @CrazedProgrammer has tried this in the past? I've had little luck with Gradle builds in Nix myself, but maybe this is a simple enough project that it could work. |
This package's FOD fails hash validation.