Arch Linux User Repository

@ipaqmaster: I'm also building automatically and verify with a clean build env. Obv. I can't tell how you've set up your automated build system but if you're doing caching for efficiency, there are several levels at which you could and should do it. Please note that if you're caching certain levels/layers, your builds are no longer clean and you may encounter inexplicable problems that are yours and yours only to deal with (which seems to be the case here as again, a clean environment works 100% of the time).
TL/DR; you can do caching but caching the whole tree is not a good way to go about it (caching should be separated into different levels) and issues are yours to deal with. This is sticking to both upstream instructions as exact as possible to prevent issues there.

In regards to setting up/playing with caching, at the first level you can do source caching. This is safe and with checksums, git, etc. this should just speed up the process without any issues or consequences to a (clean) build. You can always cache the source and only update/fetch changes as needed before going into the build process. This is basically agnostic to any package and should always be fine (barring any PKGBUILD that grabs/defines sources in a custom way). Look into SRCDEST (makepkg) for information on how to play with this and separating things out from your working/build dir.
Compile caching is the next level. Starting at this point things are not exactly clean anymore so it's a good practice to separate things into separate caches so you can clear this one individually without affecting your source cache if anything goes wrong. Look into using ccache. It works with both gcc and clang and integrates with makepkg (BUILDENV).
Lastly, you could do a build artifact cache, again separate from the other caches. Look into PKGDEST and SRCPKGDEST. Though if you store the resulting package, I'd say this is rather pointless so I would not bother with this.

Yes, I'm building this one automatically / periodically in Jenkins and it's the only one throwing a fuss in 200+ AUR packages.

This particular package doesn't take very long to build so maybe it can be made an exception by not utilizing a workspace but this seems very network and cpu cycle inefficient.

Large enough projects take hours to build from source and many AUR packages fetch project's from source and compile them on the local machine for a final zst for pacman to use. It would be stupid to rebuild every single common unchanged C component for these programs every single invocation no?

Are you suggesting this project is one which must be built from scratch every single time? I added -p to that mkdir line in the PKGBUILD's build function and it successfully made a new zst package every time with makepkg after deleting the most recently built zst but also worked with makepkg -f without deleting the existing zst. I'm not sure if there's something else I'm missing?

As the host didn't need to git-clone looking-glass, LGMP, PureSpice, cimgui, imgui nor rebuild any of their many pieces it's able to spit out a result more quickly and without downloading ~248.9MiB of git objects every single build attempt. That and it only took 27.6 seconds to build the package instead of 1m 9s (Fiber internet. Result would likely be even slower on a non-fiber connection)

// My bad, I always mistake -p for -v when talking about the -p mkdir flag. -p is what I tested with for the first comment and it solved everything in my case.

@ipaqmaster; it should not. You getting that error suggests that you're not building in a clean environment/chroot (e.g. https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot ). That is fine but in that case any breakage is for you to deal with.

Fwiw, adding -v is not going to change anything. You might be thinking of -p maybe? But in that case be aware that it will create parent directories and it does not fail (exit code always 0). That means if any expected dir in the path is missing, it'll fail somewhere later on with no indication this is actually where it failed (failure here would've told you the file structure is not as expected). But again, that's all for you to deal with if you choose to not build in a clean environment.

Subsequent builds fail due to line 55 in PKGBUILD.

mkdir: cannot create directory ‘client/build’: File exists
==> ERROR: A failure occurred in build().
    Aborting...

The mkdir "${b}" in PKGBUILD line 55 should have -p added.

(E: Corrected -v to -p)

Probably because the latest PKGBUILD is still the same PKGBUILD as before. I see something went wrong with the mirroring/pushing to the AUR. Different git issue i.c.w. CI pipeline (repository ownership) so the PKGBUILD was never included. I'll fix that in a bit.

I'm still unable to build after cloning the latest PKGBUILD.

Cloning into 'looking-glass-git/src/looking-glass/repos/PureSpice'...
fatal: transport 'file' not allowed
fatal: clone of '/home/nark/Downloads/looking-glass-git/src/PureSpice' into submodule path 'looking-glass-git/src/looking-glass/repos/PureSpice' failed

@gutash; it's not advisable to use internal/private git commands. There's no telling when those may change or break.

Due to CVE-2022-39253, the flag protocol.file.allow was changed to default to 'user', which disallows the use of file:// clones. The proper way to deal with this is to set the config flag to re-allow file:// clones instead. I've updated the package to explicitly provide this config flag for the submodule update commands.

A recent git update broke some -git packages using submodules. I've seen a common fix between other packages for this, so here's a patch that enables this package to properly build again:

diff --git a/PKGBUILD b/PKGBUILD
index 4506fdd..b83be57 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -7,7 +7,7 @@ pkgname=("${_pkgname}-git"
          "${_pkgname}-host-git"
          "obs-plugin-${_pkgname}-git")
 epoch=2
-pkgver=B5.r242.g35bf3091
+pkgver=B6rc1.r0.g5b6095ad
 pkgrel=1
 pkgdesc="An extremely low latency KVMFR (KVM FrameRelay) implementation for guests with VGA PCI Passthrough"
 url="https://looking-glass.io/"
@@ -41,12 +41,12 @@ prepare() {
    git config submodule.repos/LGMP.url "${srcdir}/LGMP"
    git config submodule.repos/PureSpice.url "${srcdir}/PureSpice"
    git config submodule.repos/cimgui.url "${srcdir}/cimgui"
-   git submodule update
+   git submodule--helper update

    cd "repos/cimgui"
    git submodule init
    git config submodule.imgui.url "${srcdir}/imgui"
-   git submodule update
+   git submodule--helper update
 }

 build() {

The project already did back in August. Under the default build options, it's not a new dependency for the client. It is now only additionally being used in the client's X11 displayserver component but it's not a new dependency.

Unless you've manually made changes to the PKGBUILD to change the build options to exclude anything and everything libxkbcommon, nothing changed.