-
-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source directory being used for theme files again, panic at runtime #769
Comments
Same for me
Cannot installa anymore |
Can you show the debug output in the console? Not sure yet if there is a cmake option to enable them without the gui. |
@alerque do you have the same problem? |
Now it seems to work. No more errors installing aur package (gittyup 1.4.0-1). I'm using paru. |
Thanks for testing |
Sorry. I cleaned up paru cache and reinstalled gittyup and now it fail to start.
Before was working because the file was present in the paru cache someway |
Having the same issue (on Manjaro Linux) I can install it but then I cannot launch it, see error below
The But it seems like the |
Building and launching works with @yochananmarqos's |
@alerque can you include ↑ these ↑ changes into PKGBUILD? |
@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. |
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 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. |
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:
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.The text was updated successfully, but these errors were encountered: