Source directory being used for theme files again, panic at runtime

[alerque]

Some form of the issue we saw in #167 is back for 1.4.0. Packages I built on an offline build system (Arch Linux official package builder) are throwing an error at run time:

PANIC: unprotected error in call to Lua API (cannot open /build/gittyup/src/Gittyup/conf/System.lua: No such file or directory)

This is looking for a Lua file at the path it would have been during the build process instead of looking for it where it should be installed. The file is installed at /usr/share/gittyup/Gittyup/themes/System.lua in the final package, but that location is not found and the panic happens because it only looks in where the source directory was at build time. In this case that is in a chroot on a different system and hence is not available at run time.

[ftaiolivista]

Same for me

PANIC: unprotected error in call to Lua API (cannot open /home/user/.cache/paru/clone/gittyup/src/Gittyup/conf/System.lua: No such file or directory)
[1]    108341 IOT instruction (core dumped)  gittyup

Cannot installa anymore

[Murmele]

Can you show the debug output in the console? Not sure yet if there is a cmake option to enable them without the gui.

[Murmele]

@alerque do you have the same problem?

[ftaiolivista]

Now it seems to work. No more errors installing aur package (gittyup 1.4.0-1). I'm using paru.

[Murmele]

Thanks for testing

[ftaiolivista]

Sorry. I cleaned up paru cache and reinstalled gittyup and now it fail to start.

PANIC: unprotected error in call to Lua API (cannot open /home/vista/.cache/paru/clone/gittyup/src/Gittyup/conf/System.lua: No such file or directory)
[1]    85660 IOT instruction (core dumped)  gittyup .

Before was working because the file was present in the paru cache someway

[stingray21]

Having the same issue (on Manjaro Linux)

I can install it but then I cannot launch it, see error below

PANIC: unprotected error in call to Lua API (cannot open /tmp/pamac-build-user/gittyup/src/Gittyup/conf/System.lua: No such file or directory)
[1]    53284 IOT instruction (core dumped)  gittyup

The src folder in tmp gets deleted in the "Cleaning up" step of the install. When I then manually add it back (clone it from git), I can launch the app again.

But it seems like the tmp folder should not be the place where these files should live.

[stingray21]

Building and launching works with @yochananmarqos's PKGBUILD
https://github.com/yochananmarqos/pkgbuilds/blob/master/gittyup/PKGBUILD

see:
https://aur.archlinux.org/packages/gittyup

[loziniak]

@alerque can you include ↑ these ↑ changes into PKGBUILD?

[alerque]

@stingray21 and @loziniak the changes in @yochananmarqo's PKGBUILD are not tennable for release to the AUR. You are welcome to use them yourself, but there are several things happening in there that are against Arch packaging guidelines, including installing vendored versions of QT/libgit/etc. to /usr/lib that don't belong to the package at all. It "works" for some scenarios but is not a viable fix for the AUR package.

And yes @Murmele this is still an issue, the Lua paths still end up dependency on the build-time source location, not the target install location.

[alerque]

This bug has something to do with build modes. I was able to avoid it by some combination of not requesting cmake to generate ninja files (removing -G ninja) and changing the build type from None to Release. It's possible that the latter of those things in correctly affecting this in that it is avoiding some debug mode that forces assets to be in the source directory. I don't know why or how that is happening with a fully qualified path and I don't see anything at all the source that suggests how -D CMAKE_BUILD_TYPE is being used to affect Lua include paths.

Notably not generating Ninja build scripts means there is no access to the test suite, so this isn't quite a satisfactory full work around.

Does that help identify where this is coming from? If it's a known mechanism for debug builds that might be okay, although it should probably be done with relative paths not absolute ones.

[AHSauge]

Is this still an issue? I tried to replicate this locally, but the resulting files ran just fine.

[AHSauge]

I started hitting this issue during Fedora packaging, and it all comes down to a QDir::temp() call in src/app/Theme.cpp. I've dropped the need to even create the file in #995, so this should hopefully fix this permanently.