Arch Linux User Repository

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

@simonrepp thx for the tip.

I did this:

$ yay -R faircamp
$ rm -rf .cache/yay/faircamp
$ yay -S faircamp
# cleanBuild: All

The install process worked now fine without problems. (I have the feeling that updating like this is just installing without the --offline flag. ;) )

For me it looks like that the cargo package lightningcss is somehow new in this version.

Deleting the cargo-cache ~/.cargo/ also force cargo to download all required crates. ;)

For me it works now ... maybe it helps the next one with a similar problem.

@ca_bi Thanks for the report!

Could you give the install process another shot by a) doing a fresh/clean install with yay (with a clean cache, however that is done) and/or b) installing the package from scratch without yay?

The reason I'm asking is that I've previously received reports about the install not working that ultimately were connected to the AUR install tool used rather than the package itself, and given I've received feedback that the current PKGBUILD installed fine for someone else, I first want to rule out that this is again an install tool problem.

As for removing --offline: The main reason for some of the recent changes to the PKGBUILD was to allow the package to install in an offline environment (this is in fact recommended/requested by the AUR packaging guidelines), therefore removing --offline should only be a last resort if we can't find any other solutions (but I think we will! :)).