Arch Linux User Repository

@chrisco23 Thank you for the notice! All git hashes in a fresh clone are in order and the content of the .tar.gz artifact matches 1:1 what is to be found at the 1.7.0 tag, so I'm concluding that nothing nefarious is going on. I'm assuming that codeberg regenerated the assets with different compression settings after a forgejo update (or such), which happened at least once before.

In short: I've updated the sha256hash, should work now. Thanks again!

Current faircamp 1.7.0-1 fails source validation:

faircamp-1.7.0.tar.gz ... FAILED ERROR: One or more files did not pass the validity check

Cleared ~/.cache/yay/faircamp and retried; same result. Please verify the upstream artifact and update the checksum/version as appropriate.

For the record, regarding these issues reported most recently on 2025-06-23 (by @ca_bi): I set up an arch-based docker container today which does nothing more than clone this faircamp AUR package and install it with "makepkg -si" - and didn't run into any issues. There's still a chance that something is off with the PKGBUILD of course, but at least going by a clean arch environment (and that is already a pretty good benchmark I guess) it seems to be alright.

@ca_bi I see, thanks for reporting!

If you happen to find any time to look deeper into this (anyone reading this in fact), I'd really welcome support on this one! (the less time I spend resolving packaging issues the more time I can spend developing too) :) No must of course, but it'd be greatly appreciated.

Notes: - I don't think any faircamp-specific knowledge is required to solve this (I suspect the rust/cargo manual will contain all needed info, I'd have to consult it just the same) - I think the starting (and maybe already end) point to solving this is the question "Why does this commmand in prepare() - cargo fetch --locked --target "$(rustc -vV | sed -n 's/host: //p')" - not fetch enolib-rs, instead leading to it still needing to be fetched in build()? I expect that the answer to this question contains the solution to the problem.

@simonrepp I have the same problem as @DaforLynx .

"Offline mode" says NO! (This time to enolib-rs)

I also tried to reinstall faircamp like I wrote 2025-05-07 18:46. Even with a

rm -rf ~/.cargo/

it won't work.

Only the removal of the --offline flag in .cache/yay/faircamp/PKGBUILD allowed me to install the new version of faircamp.

@DaforLynx Cool, glad it works now!

@simonrepp Though I already had removed the --offline and installed it manually, I was able to get it to reinstall through the helper by clearing the clone cache. It could also have been any of the other things I did while cleaning my system out yesterday. A classic "try installing manually first, dummy" moment. Lesson learned.

@DaforLynx Oh no that's weird. I last touched the enolib dependency half a year ago (just checked), so on that end I really couldn't say what changed in that regard. I didn't modify the PKGBUILD in any way either since 1.4.0 (asides changing the version and hash of course) ... Could you try clearing the cache or something in your AUR helper (paru?). I have a feeling this will at least fix it, although I also suspect the issue might come back. (Maybe there's something deeper about the PKGBUILD that needs a fix? I'm unfortunately not much of an expert on AUR packaging)

Offline mode causes enolib to fail loading for some reason.

error: failed to get `enolib` as a dependency of package `faircamp v1.4.2 (/home/d/.cache/paru/clone/faircamp/src/faircamp)`

Caused by:
  failed to load source for dependency `enolib`

Caused by:
  Unable to update https://codeberg.org/simonrepp/enolib-rs?tag=0.5.0#011a9309

Caused by:
  can't checkout from 'https://codeberg.org/simonrepp/enolib-rs': you are in the offline mode (--offline)

@ca_bi Excellent to hear, thanks for the quick feedback!

The dependencies should have been (and probably have been) downloaded in the prepare step, unless you manually removed the --offline flag (or didn't put it back after removing it), cargo should refuse to connect in the build step. :)

I think I'll try to bump the pkgrel number next time I do some changes like that, maybe this (the absence of it) was what prompted yay to try to do the install with an outdated cache - I only very sporadically work on AUR packaging so I'm never quite sure what the 100% correct procedures are, sorry for the bumpy ride there. :D