Build Error (Arch Linux - current aur version)

[ftaiolivista]

QWARN  : TestTreeView::conflictedAndStagedFile() This plugin does not support propagateSizeHints()
PASS   : TestTreeView::conflictedAndStagedFile()
PASS   : TestTreeView::cleanupTestCase()
Totals: 6 passed, 1 failed, 0 skipped, 0 blacklisted, 1670ms
********* Finished testing of TestTreeView *********

      Start 18: Submodule
18/26 Test #18: Submodule ........................   Passed    2.09 sec
      Start 19: referencelist
19/26 Test #19: referencelist ....................   Passed    1.02 sec
      Start 20: amend
20/26 Test #20: amend ............................   Passed    0.59 sec
      Start 21: SshConfig
21/26 Test #21: SshConfig ........................   Passed    0.07 sec
      Start 22: store
22/26 Test #22: store ............................   Passed    0.05 sec
      Start 23: fileContextMenu
23/26 Test #23: fileContextMenu ..................   Passed    3.20 sec
      Start 24: Setting
24/26 Test #24: Setting ..........................   Passed    0.06 sec
      Start 25: commitMessageTemplate
25/26 Test #25: commitMessageTemplate ............   Passed    0.07 sec
      Start 26: commitEditor
26/26 Test #26: commitEditor .....................   Passed    0.09 sec

96% tests passed, 1 tests failed out of 26

Label Time Summary:
NO_WIN32_OFFSCREEN    =   4.83 sec*proc (4 tests)

Total Test time (real) =  29.84 sec

The following tests FAILED:
         17 - TreeView (Failed)
Errors while running CTest
FAILED: test/CMakeFiles/check /home/vista/dev/gittyup/src/build/test/CMakeFiles/check
cd /home/vista/dev/gittyup/src/build/test && /usr/bin/ctest --force-new-ctest-process --output-on-failure --timeout 300
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
    Aborting..

[Murmele]

Hi, thank you for the report. Can you share more logs?

[ftaiolivista]

full build log here

[alerque]

Something doesn't look right to me. First you have a typo in the title, this is evidently about Arch Linux not ARC linux (which is something different).

Second, the title says "current git version" but the log file you posted is from building the AUR recipe for the stable 1.3.0 release.

Third, I just built both the gittyup stable package and gittyup-git in clean chroots and both built successfully. The latter one has some issues with it's pkgver() function and ends up mislabeling the version when it is done, but it does build.

Since clean CHROOT builds with just the speced dependencies works properly the issue with checks is probably a conflict with something extra or some unsupported version of something on your host system.

I highly recommend you switch to building AUR packages in chroots. There is tooling available to automate the process so it is very easy. You'll run into lots of AUR builds that are invalid because they are missing dependencies, but you'll also get much more reliable builds from ones that are correct because the build is isolated to the correct environment and when they do work you'll have a higher confidence that they will work as expected, that the built packages can be installed on other systems, etc.

[ftaiolivista]

Thank you. I understand, I will try with clean chroot. But just to let you know I have many other AUR packages that I regularly update without any error.

[alerque]

Looking more closely at your logs, you are using paru's build cache, and the cache is dirty: it has artifacts from previous versions and test runs. The test is failing because it is finding remnants of output from previous releases. If you clear the paru build cache location I bet you can build outside of a chroot as well.

This is arguably a bug in this projects test suite as it should do it's own cleanup in the tests directory and not be reliant on a clean starting position for test runs, but it is also very hard to cope with artifacts from previous releases. No project should be expected to do that, a clean build tree is expected for building tagged versions.

Suggestions about building using chroots still apply. Paru even has an option to do this automatically.

Arch packages in specific are NOT supposed to clear the build tree as part of the packaging because we want to be able to restart builds where they left off when working on the packaging. The expectation is that the user will cleanup after old version builds but is allowed to rebuild the current version in a dirty tree if they want/need to.

[ftaiolivista]

I have totally removed ~/.cache/paru and rebuilded but got the same error

[zimudec]

I use manjaro, with yay. I deleted ~/.cache/yay/gittyup, tried again and got the exact same build problem.

Error in test 17

[alerque]

Then we're back to this: something on your systems that is not a dependency is confusing the test suite. First it would be interesting no know if the build works if you --skip-checks when building. Beyond that somebody has to start guessing: most likely something this project has vendored (there are lots of libs vendored here) is being used by the build but not the test suite and an equivalent system version is being used in tests. That's educated speculation knowing that it builds and passes tests in a chroot with only the specified dependencies.

[stingray21]

I'm in the same boat as zimudec, but was able to install it with yay -S --mflags "--nocheck" gittyup

[AHSauge]

Then we're back to this: something on your systems that is not a dependency is confusing the test suite. First it would be interesting no know if the build works if you --skip-checks when building. Beyond that somebody has to start guessing: most likely something this project has vendored (there are lots of libs vendored here) is being used by the build but not the test suite and an equivalent system version is being used in tests. That's educated speculation knowing that it builds and passes tests in a chroot with only the specified dependencies.

I think indeed the vendoring is part of the problem here, but maybe not all of it. I'm seemingly facing the same problem on Fedora 38, and worse problems with Fedora 40. They both also have tests sporadically failing. Both utilise OpenSSL 3, which results in a linker warning since it's a dependency in Qt and I guess it sees there are clashing symbols. To fix that, Gittyup needs to be compiled and linked towards the system version of OpenSSL, not even a vendored copy of it (assuming current instructions are follows). Just out of curiosity, I tried updating the OpenSSL submodule to version 3, and compile that, but that actually breaks tooling such as cmake when run in the build folder. It's probably down to different compile or link settings, but still, a clear demonstration that it's probably easier to just rely on the system provided copy than to run down the pathway of managing it yourself.

That said, there must be more to this. Compiling against the system libraries for the ones I do have installed, still doesn't get rid of the problems. Now I've cleaned both the clone and the build directory quite a few times across two machines, and unless the test data leaks outside the build structure, there's no getting rid of the problems on an unmodified master branch. If I switch to the Qt6 branch, this particular issue disappears on Fedora 38 and all tests pass most of the time. On Fedora 40 I'm still left with sporadic failure of test 18 and always failure of test 23. I tried to see if the Qt6 branch has something that sticks out that could explain it, but aside from Qt6 itself, I don't spot anything. I'm of course not particularly familiar with the code, so that doesn't prove much.

[AHSauge]

After quite some head scratching, I think this particular issue might be tied to some Qt fun. If I run QT_QPA_PLATFORM="offscreen" ./test/TreeView I get errors similar to the log presented earlier here. If I however run ./test/TreeView (which will render Gittyup to screen), all is fine. I think the most likely suspect here is that there are behavioural changes in the offscreen plugin between Qt 5.15.2 which the build server here seems to use, and 5.15.12 and 5.15.13 which as used for Fedora 38 and 40 respectively. The log from @ftaiolivista seems to be 5.15.9

I would agree that this also could be a timing issue, but injecting 2 second delay right before the failing line doesn't help things. So unless something is pulled away too quickly, it seems less likely.

@alerque I guess the chroot setup you ran was based on Qt 5.15.2, or was it some other version?

[alerque]

It looks like the package I have around was built with Qt-5.15.9 with some Arch patches. You can always tell from an Arch package by extracting the .BUILDINFO file from the package and looking at the list of things that were installed on the builder. I think I re-tried the build a few times above when people commented and there was probably a newer Qt at those times, but I don't have the final packages or build log handy to check. The current version of Qt in Arch is 5.15.13 plus some Arch patches. If one were to re-run a chroot build now that's what it would try to build against. I don't have time to retest a build myself at the moment but all you need is devtools and pkgctl build --repo extra from the AUR package repo.

[AHSauge]

Thanks! I finally got around to spinning up an Arch VM, and it of course has GCC14 now, so I had to run https://github.com/Murmele/Gittyup/pull/759

This is pretty interesting, because I can both reliably reproduce this and not depending on what's installed. A chroot build seems to always succeed, although I must say that test 1 and 2 seem to be quite disk I/O performance sensitive. I had to move the VM from a spin disk to an SSD to get the tests to reliably pass.

Anyway, what I notice is that the binaries in the chroot are unable to run with xcb as the Qt platform plugin, and by default run with the offscreen plugin. That's not surprising since it's a limited environment, lacking any GUI display capabilities. However, the moment I remove any display capabilities from the non-chroot environment, the test passes there as well. Install for example plasma-desktop, and the same binaries fail. No rebooting nor rebuild needed. This all happens in over SSH while the VM itself is booted into multi-user text/console mode.

So with that, I'm pretty interested to hear if anyone is even able to get these tests to pass in a GUI enabled Linux environment without actually rendering the GUI (aka. run with the xcb platform plugin instead of offscreen).