Todo items so Gittyup can be moved from the AUR to official Arch Linux repos

[alerque]

I've been hacking away on the AUR build for a few days now and I think this project has moved a lot closer to a respectable build process than it used to be. In the GitAhead days and early Gittyup days there was may too much forced vendoring and other hacks to even consider making an official Arch Linux build out of, but I think we're close now.

Here are some things I'd like to see before making the package official:

• Building on current gcc was fixed in Update zip dependency to fix GCC14 build error #759, but no release has been made that includes this. I'm cherry picking the patch to make the AUR build work, but that's not a great practice and it would be nice to have a cleaner build for official packaging.

• The libgit2 update in Libgit2update #153 needs to get finished. Currently the build is still using a fork of an old libgit2 build. To make it official I would like to see the build working with -D USE_SYSTEM_LIBGIT2=ON against the latest official libgit2 release. This is also mentioned in Build system should not assume everything is vendored and bundled #581.

• If (and I haven't researched whether this is the case or not, so if) scintillua can be split out such that it can be built as a separate shared library (or perhaps used via a LuaRocks installed module?) then that should be done. This may not be the way that library is even setup, so if not lets check this off. If it can be done I'll setup the extra library or lua package so satisfy this dependency and make that official too.

• Same for Lexilla, only this looks like a lot more obviously possible to me. It should be pretty easy to make a system package that provides liblexilla.so, we just need a -D USE_SYSTEM_LEXILLA argument and search routines to support it. This is also part of Build system should not assume everything is vendored and bundled #581.

• Optionally and somewhat tentatively, the whole kuba--/zip thing could use replacement. It looks like it can't even be built as a shared library, so vendoring it might be the only way. As such I won't make this a blocker for moving it to official repos, but linking one of the much more generic archive handling libraries that are in standard use everywhere would be appreciated.

• For bonus points to make other distros more likely to pick this up, change the CMake config to default to using system dependencies, and only set them the other way around for builds where it makes sense to vendor everything (such as Flatpack). If all the dependencies are expected from the system and the sources worked without any submodule initialization/fetches that would make it a lot easier to onboard other distros. Again I can make the current devendoring tricks happen for Arch Linux, but it would sure be preferred the other way around.

The current AUR package already has enough interest and I can take care of the rest of the details. As soon as a release is cut that checks off at least the first two items here and as many of the others as actually makes sense then I'll spin up an official build. Hopefully this issue is encouragement that things are close and perhaps inspires some outside contributors to jump on these points.

[OdinVex]

Manjaro (AUR) user here, I resorted to clone-trigger patching yours to bypass tests (-D ENABLE_TESTS=OFF and commenting out check()'s function entirely) for quite a few versions just to get a compile. Just adding for others.

[alerque]

@OdinVex There has never been a need to comment out the check function or add cmake options, you can always just build with --nocheck. In any case that is a moot point at the moment because the checks pass properly when built in a chroot. Passing checks finally is actually what prompted me to create this issue since so many other things have gotten worked out and I wasn't sure what was left before I can move ahead with official packaging.

[OdinVex]

@OdinVex There has never been a need to comment out the check function or add cmake options, you can always just build with --nocheck. In any case that is a moot point at the moment because the checks pass properly when built in a chroot. Passing checks finally is actually what prompted me to create this issue since so many other things have gotten worked out and I wasn't sure what was left before I can move ahead with official packaging.

You're assuming I've been compiling it with access to the command line calling it. The Docker I use to pre-compile packages for my systems doesn't support that but it does support running sed on content (git, etc). So yes, I've been forced to comment out check() and add that cmake define for it to work.

[alerque]

but it does support running sed on content

I'd bet dollars to donuts you can get makepkg args through somehow; every build system I've seen has some way to handle arguments and if you built your own you should be able to add this trivially. But even if not if you can run sed then just add BUILDENV+=(!check) to the top of the PKGBUILD. And I don't understand the urge to blame the packaging for doing the right thing when the issues have been a) the upstream tests didn't actually pass or b) you don't have access to Arch's standard package building options.

And again as I said tests do pass now so you shouldn't need to do anything.

[OdinVex]

but it does support running sed on content

I'd bet dollars to donuts you can get makepkg args through somehow; every build system I've seen has some way to handle arguments and if you built your own you should be able to add this trivially. But even if not if you can run sed then just add BUILDENV+=(!check) to the top of the PKGBUILD. And again as I said tests do pass now so you shouldn't need to do anything.

It's an in-house Docker solution wrote quite a few years ago on a crappy Qnap which has an even crappier "Container Station" for container management with an interface that only allows editing composes. It loops through repos, clones them, runs a pre-defined script per repo (folder-structure-based) to allow patching and just spits out an output while putting any final zsts into another folder. Bet all you want (whatever for?). Your attitude around this baffles me, especially if it's been historical (I posted once on the AUR about it) that tests were not working right and if tests have only just been fixed it's more than reasonable to conclude I could still be using legacy patching around the issue. So what's your problem? "Oh no, someone modified my pkg for themselves since it wasn't working for them?" Walking away from this discussion.