Arch Linux User Repository

You're over-complicating this when all I'm requesting is that you apply this harmless 2-byte -p fix to the PKGBUILD file. I don't need a lesson on build caching here, you don't need to worry about our local build environment as it's making hundreds of flawless packages (Including this one! after applying a mkdir -p patch) without having to recompile hours and hours of work through each run (Strictly where applicable).

The single issue I'm having here is that your PKGBUILD's mkdir line in the build() function stops the entire build process if it sees a directory it already created in an earlier run. This is an inexcusable reason to halt an entire build over. If you want a clean build you can wipe a workspace yourself or invoke make clean otherwise it's a waste of resources to obliterate other hard work (Particularly the dependencies of this project which take a moment and infrequently change). I can't communicate this any clearer our build server is excperiencing NO issues nor re-build issues with this AUR package except when your PKGBUILD halts the build because of mkdir throwing a fatal error over a non-fatal directory's existence before it can even start compiling.

Subsequent builds of both the latest commit and older commits (Potentially with new local patches and hotfixes for example) work entirely fine with -p added to mkdir in this PKGBUILD. You heard correctly - no issue with subsequent builds in a workspace it previously used. Not in the slightest. Yes, if something went wrong it would be on me locally to handle that build failure in its persistent workspace, not you as the AUR package maintainer.

Not only does reusing the workspace save pulling 250MiB of submodules from github every single time the package gets built (Which could be many times a day if the looking-glass project team are busy!) but it also saves recompiling all these unchanged dependencies every single time this package gets an update. Not only does this also cut build times by more than half and spares the network traffic of initializing the submodules from scratch every build which would also be beneficial for metered and low-bandwidth connections not having to pull that 250MiB every single run. Let alone potentially getting rate limited by github with enough back to back builds. In subsequent runs even git knows to update the submodules rather than pull them entirely from scratch which would be a total waste.

This is the only package failing subsequent builds in our pipelines of which the single lone root cause is the mkdir in PKGBUILD here throwing exit code(1) when it sees a directory it already created. You're suggesting we discard the build environment every single time downloading 250MB of dependency projects and wasting cpu cycles recompiling them with each new looking-glass commit? The PKGBUILD shouldn't be the single point of failure in a re-build by getting upset over the existence of a folder it created in a previous run.

To work around this PKGBUILD problem we've had to move the job to its own separate pipeline where sed -i 's/mkdir "/mkdir -p "/g' PKGBUILD is called before building. It would be really nice if it could join the other 200+ packages in our build pipeline.

There's not much else to say here - our build environments for all packages are sound including this one - PKGBUILD in its current state halts everything over non-fatal directory presence without locally tweaking it to not do that. Please add -p to PKGBUILD's mkdir command so it doesn't crash and burn on subsequent runs anymore 🙇

@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() {