sci-misc/llama-cpp: Add webui and 0_pre9219

[0x000C0A71]

note: Building with webui is unsupported in live ebuilds, as building the web assets served requires npm to pull dependencies. However, the llama.cpp devs serve prebuilt web assets for all their tagged releases, which are pulled in SRC_URI

[negril]

Got your mail. We really want to support the webui in the -9999 as well. But it's trivial to do. You just need run git-r3_src_unpack again with the right env vars set. https://codeberg.org/gentoo/gentoo/src/branch/master/net-misc/sunshine/sunshine-9999.ebuild#L226-L248 is one example.

I can write it up at some point today or you do it. Ping me on irc if you need help.

[0x000C0A71]

I'm sorry for writing this here and not on IRC, my homeserver that hosts my bouncer is currently down for maintenance, and I'm not fond of spamming random IRC channels with "<> connected; <> disconnected; <> connected; ...".

If I understand that above-mentioned passage from the net-misc/sunshine ebuild correctly, the idea is to pull the npm dependencies in the fetch/unpack step, such that the npm compile can actually be done, right?

Is the idea to do the same for tagged releases, or would that destroy reproducibility because it might pull different dependency versions for the same tagged version at different times?

[negril]

I'm sorry for writing this here and not on IRC

Totally fine. Just letting you know where to reach me.

If I understand that above-mentioned passage from the net-misc/sunshine ebuild correctly, the idea is to pull the npm dependencies in the fetch/unpack step, such that the npm compile can actually be done, right?

Is the idea to do the same for tagged releases, or would that destroy reproducibility because it might pull different dependency versions for the same tagged version at different times?

No you would do that just for the -9999. Your code for the tagged releases is fine as is.
The only nitpick would be that you don't need to copy. You could move or symlink instead.

You would add a new src_unpack that does the normal git-r3_src_unpack and then set EGIT_REPO_URI to where the git repo for the ui is and run git-r3_src_unpack again. But that seems problematic, given what scripts/ui-download.cmake does. So I will need to look into that and get back to you on how we do that. Might be easier to implement it for the non tagged only for now and leave the changes for -9999 out.

[0x000C0A71]

The sources for the web assets are contained in the main llama.cpp repo. They have a 3-pronged approach to generate the final web assets as documented in their ui-assets.cmake. Probably the correct approach here is to do priority 2: build the web-assets themselves. That requires an npm build, however, which, if done by the cmake files as part of the compilation would fail, as npm tries to pull its dependencies, which is obviously impossible from within the sandbox. My approach was to sidestep that by "doing priority 3 (pulling from their bucket) myself", and as such i mirrored their downloading strategy as closely as possible.

Looking at the net-misc/sunshine example you provided, they "just do the npm dependency fetching manually in a non-sandboxed stage", which (i assume) makes the npm step skip the fetch stage of dependencies, and probably make the building succeed. Considering there is a package-lock.json, they seem to pin specific version of dependencies, so I would assume that the dependencies pulled are somewhat reproducible.

All that considered, I believe building the assets ourselves would probably be feasible for non-live builds, which I feel is "more the gentoo philosophy". Should we try to build the web-assets ourselves even for tagged version builds?

Anyway, I'll try to quickly whip something up to get the whole "pulling npm dependencies ourselves" working, and we can then still decide whether to only do that for live builds, or for all builds.

[negril]

We can fetch in src_unpack, but should only really do so for the -9999. Looking at the buckets checksums they are often the same. https://gitweb.gentoo.org/repo/gentoo.git/tree/media-gfx/blender-bin/blender-bin-9999.ebuild#n64 does something like that. We could try construct the rev ourselves and use that.

That all being said. Please amend the commit to only touch the tagged version. Then I'll review and one of us pushes to guru dev. And then we can work on the 9999.

[0x000C0A71]

Dropped the modified -9999 ebuild and changed it to use mv instead of cp

[0x000C0A71]

Had to change it to ln -s as mv doesn't work because of permissions. I'm sorry for not having caught that sooner, i forgot to enable the webui USE flag when verifying before.

[0x000C0A71]

BTW in a different branch of my fork I've created a commit that seems to work with building the webui even in live ebuilds. I have verified that it builds (and there are, as expected, npm build logs in the compile logs), but I have not tested the built package for function as I am working off my laptop at the moment which does not have the facilities to actually run llama.cpp

in that commit I have also moved the linking of the pre-downloaded assets (in case of a non-9999 build) to the src_unpack stage such that it is in the same place as the pulling of dependencies in the -9999 case.

Should I create a separate PR for that branch after this here is pulled or just merge it in here aswell?