Search Criteria
Package Details: ruby-pleaserun 0.0.32-4
Package Actions
Git Clone URL: | https://aur.archlinux.org/ruby-pleaserun.git (read-only, click to copy) |
---|---|
Package Base: | ruby-pleaserun |
Description: | pleaserun |
Upstream URL: | https://rubygems.org/gems/pleaserun |
Licenses: | Apache-2.0 |
Submitter: | jtgoguen |
Maintainer: | envolution |
Last Packager: | envolution |
Votes: | 3 |
Popularity: | 0.000000 |
First Submitted: | 2017-03-03 04:20 (UTC) |
Last Updated: | 2025-06-11 00:42 (UTC) |
Dependencies (8)
- ruby
- ruby-cabinAUR
- ruby-clampAUR
- ruby-dotenvAUR
- ruby-insistAUR
- ruby-mustache
- ruby-studAUR
- ruby-bundler (make)
Latest Comments
mkurz commented on 2025-05-17 21:55 (UTC)
Ahhh... that makes sense, I didn't look much in the PKGBUILD file. Thanks for fixing!
envolution commented on 2025-05-17 19:00 (UTC)
@mkurz it was caused by the PKGBUILD's attempt at patching the mustache dependency requirement by replacing the source gemfile with a patched gemfile. This is okay for a one-shot install, but subsequent installs would fail checksum.
I've modified the process to avoid cache file replacement so it shouldn't be an issue in rel4
Thanks for your report
mkurz commented on 2025-05-17 13:18 (UTC)
So for me the hash also didn't work. So I tried to find out what's going on and it turned out that after removing the pleaserun-0.0.32.gem from the yay cache again, tried again, like 3 or 4 times, the checksum suddenly was ok. Since I kept the already fetched gem files, I compared their contents. Turns out that the binaries are the same, but following two files differ:
So that means https://rubygems.org/ serves different gem files (at least for this package) or has an old build cached and sometimes we hit that cached file. Or maybe a proxy or cdn has the wrong files cached.
skeksis268 commented on 2021-07-07 10:42 (UTC) (edited on 2021-07-07 10:42 (UTC) by skeksis268)
Looks like hash is wrong again, maybe something changed upstream? https://rubygems.org/gems/pleaserun lists the correct sha.
RX14 commented on 2020-11-26 16:04 (UTC)
Sorry, I'm not able to really maintain this package any more, since I don't use it actively any more I can't spot issues like these. I'll disown it for a new maintainer.
ayekat commented on 2020-11-24 08:01 (UTC) (edited on 2020-11-24 08:02 (UTC) by ayekat)
I am not very familiar with Ruby Gem, but it appears that the build process actually modifies the gem file. That would explain why we are constantly getting confusing SHA256 sums.
I assume RX14 might have put the sha256sum of his local/modified .gem file in the PKGBUILD after they had already run makepkg at least once before (back in March), hence the mismatch for many users initially.
And in yahx' case, I see this:
This means the .gem file was already present the moment you tried to build there, i.e. this is a file that was already modified in a previous makepkg run. If you delete that file and rebuild (and it downloads the source again), it should work fine again.
Essentially, one cannot build this more than once in a row without deleting the source files inbetween. No idea if this is normal behaviour.
yahx commented on 2020-11-14 02:09 (UTC) (edited on 2020-11-14 02:22 (UTC) by yahx)
Seems the issue still exists (for 0.0.31-2), as @corsaw stated. My error is identical.
The sha256sum seems correct. I tried overwriting the existing key, same error. Please advise.
RX14 commented on 2020-03-18 21:19 (UTC)
Not sure what happened there, perhaps the upstream file was replaced, but the previously downloaded gem had a different hash.
Fixed.
warigan commented on 2020-03-18 21:15 (UTC) (edited on 2020-03-18 21:16 (UTC) by warigan)
It seems the sha256sum in the
PKGBUILD
is wrong. There is a different one on upstream.