| Git Clone URL: | https://aur.archlinux.org/gittyup.git (read-only, click to copy) |
|---|---|
| Package Base: | gittyup |
| Description: | Graphical Git client (GitAhead fork) |
| Upstream URL: | https://murmele.github.io/Gittyup |
| Licenses: | MIT |
| Submitter: | alerque |
| Maintainer: | alerque |
| Last Packager: | alerque |
| Votes: | 17 |
| Popularity: | 1.32 |
| First Submitted: | 2021-11-23 20:05 (UTC) |
| Last Updated: | 2024-12-20 12:52 (UTC) |
@alerque:
it's bundling a whole bunch of vendored QT libraries and other stuff internally and letting cmake install them wherever it wants on the system.
Come again? It seems you missed that my PKGBUILD removes /usr/include/ and /usr/lib/ altogether.
The last version '1.4.0-5' is working fine, even if I remove the compilation folder! I just needed to delete de 'check' session from the PKGBUILD...
I've created an issue upstream to track requirements for this build to make it to [extra]. As soon as those are met I'll make an official build for this. The project is a lot closer than it was even the last time I reviewed the status. If you want this to happen I'm sure the upstream project could use a hand with a few of the remaining details for devendoring.
Sounds like the Tests just need fixing:
Submodule: ~/.cache/yay/gittyup/src/Gittyup/src/git/Repository.cpp:159: QDir git::Repository::dir(bool) const: Assertion 'false' failed.
QDir Repository::dir(bool includeGitFolder) const {
QDir dir(git_repository_path(d->repo));
if (!includeGitFolder && dir.dirName() == ".git") {
if (!dir.cdUp()) {
assert(false); // must be done explicit, because in release build the
// assert will not be executed, so assert(dir.cdUp()) does
// not work in release build
}
}
return dir;
}
A fake repo (self?) might be an option if the Tests are attempting to run but without a reliable git to run that function on?, or temporarily commenting THIS line out. Either way, it appears to be an inconsequential line to comment out (via patch).
By the way as best I can make out the reason @yochananmarqos build "works" for some people is that it's bundling a whole bunch of vendored QT libraries and other stuff internally and letting cmake install them wherever it wants on the system. This isn't even CMAKE's problem, it is the upstream project vendoring and asking to install vendored stuff to the system directory. I don't consider that a viable way to leave this package even if it "works for me" for some of you. You are of course all welcome to use it that way, but it's against packaging guidelines in every way. I can't just let it install its own version of QT and libgit and libzip to /usr/lib!
I'm happy to take suggestions for patches that follow Arch guidelines and improve the situation, and an upstream patch that actually fixes the Lua path bugs so chroot builds work would be great too.
Package breakage (when built in a chroot) is an upstream bug. I reported it a long time ago, but it is still not fixed.
You can build without tests, but the fact that they fail means something. The package itself is broken unless you build it on your host system (not in a chroot) and keep the build directory around even after installing.
@yochananmarqos 's version downloads openssl and git sources, that's several hundred MBs of data. I see -DUSE_SYSTEM_GIT='ON' and -DUSE_SYSTEM_OPENSSL='ON' in both versions of PKGBUILD, I don't think these downloads should be necessary.
@Maaike, Maintainer hasn't learned/doesn't care, same shituation in most recent update. At this point it looks like contacting Arch to try to vote on a maintainer such as @yochananmarqos (if they're still willing) might be the best way to address this.
@Maaike, Edit: I think I added this above the cmake section of the PKGBUILD:
-D ENABLE_TESTS=OFF. You might also need to comment out the check() function entirely.
The reason for the unit tests failing should be addressed though, normally I'd not suggest skipping tests.
@OdinVex how to do that? Switch maintainers? Maybe @yochananmarqos can just maintain this package? :)
Pinned Comments
alerque commented on 2024-12-20 13:30 (UTC)
I've created an issue upstream to track requirements for this build to make it to [extra]. As soon as those are met I'll make an official build for this. The project is a lot closer than it was even the last time I reviewed the status. If you want this to happen I'm sure the upstream project could use a hand with a few of the remaining details for devendoring.