Arch Linux User Repository

This doesn't play too well with AUR helpers. It always says it has an update available but then never builds because it's already up-to-date

@MITKBconnoisseur: The gnif repo is the official source and there are no build issues with any of the recent patches/commits there as far as I can tell.
If there is a problem, please provide the complications resulting from a clean build and I'll look into it.

Every time I apply GNIF's patches for his own project this just crashes and burns in an avoidable way @ipaqmaster's patch fixes it for me. Can somebody who's serious take over this package?

+1 this is very fumbly to rebuild with patches

Dont know what you mean yay is the easiest way to download aur stuff and works every time usually and updates. i had to git clone https://github.com/gnif/LookingGlass and apply my patch there but that does not package the exe so yaeh this aur.archlinux.org pkgbase has some issues.

https://aur.archlinux.org/pkgbase/looking-glass has the same problem but i did not have master commit there so not as important but https://aur.archlinux.org/packages/linux-vfio works every time

@Netboy: You are entirely correct. Same for nanosvg. I completely missed the addition of these. I'll update the sources so these can be efficiently managed/cached as well 👍

@Omar007: wayland-protocols should vendored as submodule. It's been set like that since February 2022.

@roosterteeth: I don't know the details of how yay deals with things and what it's supposed to do here but this suggests at least that it does not perform a clean build.

Since I'm not familiar with yay, I can't help you with that. Check the man-pages for options on how to have it perform clean builds or on how to clean the build environment it is using. If builds fail in general (which seems to be the case if it fails on some completely different file as well) this is even more important.
(side-note; 'stuck on a different file' is basically at the level of 'it doesn't work'. Provide exact errors/logs if you can)

I got a patch for my iGPU in /r/vfio because of a memory bug and I'm trying to apply the patch which I think works but I ran yay -aS looking-glass-git linux-vfio vfio-isolate --rebuild again gives mkdir: cannot create directory ‘host/build’: File exists. I don't understand what your all talking about below but I tried to delete the files and it is still stuck is there a fix? I already tried to delete some and https://aur.archlinux.org/packages/looking-glass as well but it's stuck on a different file

@ipaqmaster;

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'm not. Again, all of this works fine if you're caching correctly and doing the build itself clean. I build numerous packages including this one completely automatically and none have issues (barring any that don't build in a clean environment in the first place (usually dependency related) but I try to push fixes upstream for those as I encounter them).

In this case it may seem like a harmless 2-byte addition but it's not about the specific change, it's about the principle. I'm not very interested in nor do I have the time to cover and test potential use-cases outside of the standard build processes and managing compatibility for custom things that don't conform to the clean build process (incl. proper caching). If you (or anyone) can show me that anything I maintain/provide does not build in a clean environment as documented for Arch Linux (whether you cache or not, I do not care) or does not conform to upstream defaults where it should, I'll happily make corrections or changes as needed.

I don't need a lesson on build caching here, you don't need to worry about our local build environment ...

The request seems to suggest I do need to worry about it because you're here asking me to make changes to something that works fine when build in a clean environment (incl. proper caching).

(Including this one! after applying a mkdir -p patch)

Well, if that is the fix your environment needs, then keep that local modification. There's nothing stopping anyone from doing w/e they want locally. Just don't expect anything from me if you're deviating from a clean build environment.
It's not like I don't do the same occasionally but unless the problem persists with a bare and clean (re)build and provably doesn't work, it's my own problem to deal with.

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.

Again, if you're building cleanly (even with caching), it doesn't halt. It does for your specific process apparently but I don't know what that is. Look at it from the other perspective; if this fails, I know the build environment wasn't clean. Regardless of the use of caches or not if/when this happens on my side for instance, there is something I need to fix as that means I f*ed the clean build environment somehow and I can no longer give a guarantee that what I pushed to the AUR can and has indeed been cleanly build at least once.

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).

There's no need to waste anything. I'm using caches just fine without it breaking builds. I even apply custom patches here and there completely without the need to change caches or pipelines.

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.

Again, that's a problem specifically in your environment. Performing the build cleanly using caches of all sources, dependencies, etc, will work every time.

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 visibly at least. You wouldn't be the first one to msg me because they (re)build, have a package but it doesn't run, crashes, has weird behaviour, etc, and in the end it just turned out their build environment wasn't clean. I have wasted enough time on bullshit like that. Which is why I expect someone to perform a clean build as documented first before I do anything more now.

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!)

Cache your sources.

but it also saves recompiling all these unchanged dependencies every single time this package gets an update.

See ccache and it's makepkg integration.

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.

If your caching is set up properly, none of this is a factor.

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.

Not a single time I've suggested to just throw away your workspace or caches, quite the opposite! I've suggested correcting your environment to cache the correct things, splitting out your caches to optimize and selectively be able to clean specific caches (if ever needed) thus further optimizing bandwidth and CPU use and finally to use a clean build environment.

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.

So you really do want me to worry about your local build environment!

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 🙇

Please fix your local build environment so it doesn't build in a dirty environment 🙇

TL/DR; You can cache everything without a problem, just keep the build environment clean. If this is what you have to go through, you're currently doing the caching incorrectly and technically building all your packages in an unclean manner/build environment. I do not see how that needs to be my problem to deal with. It works fine if you cache properly and (re)build cleanly.

TL/DR 2; It's not about the -p flag addition, it's about the principle of adding custom things for specific end-users. Here it's maybe 'just' a -p flag but then why should I say no the the next person wanting me to do include a custom/debug make flag or a rm -rf to clean up things or something else for their environment to work?