-
-
Notifications
You must be signed in to change notification settings - Fork 557
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
Create SciTECO #3402
base: master
Are you sure you want to change the base?
Create SciTECO #3402
Conversation
It seems that my app fails since Gtk+3 is not (fully) installed into the runner. I have tested the AppImage on Ubuntu 20.04 - it should work just fine. Gtk+3 is not included in the AppImage since pkg2appimage blacklists it and many other GNOME libraries. If you don't install these packages into your test environment, that will make it pretty hard for any Gtk app to pass the tests. |
See also https://github.com/AppImageCommunity/pkg2appimage/blob/master/excludedeblist SciTECO's pkg2appimage config file is here: https://github.com/rhaberkorn/sciteco/blob/master/AppImage/gtk.yml |
@probonopd On the other hand, it does not fail because of missing libgtk but only when trying to load icons. Perhaps I just have to add adwaita-icon-theme to the AppImage? |
Not really sure how to interpret this
|
Interestingly, the error looks very similar to FreeBSD when I try to run the AppImage in an Ubuntu 20.04 root (it can actually run Linux apps). It cannot automatically mount the AppImage, so I first extract it with
Works fine on a real Ubuntu, though. There isn't necessarily any connection to the CI issues. Perhaps we should have a look at some other Gtk App in the registry, that was built with pkg2appimage. |
The image file itself should be available via a built-in resource. The PNG pixbuf loader should be in libgdk-pixbuf2.0-0, which is blacklisted by pkg2appimage. I actually got it to start in FreeBSD's Linuxulator by setting
according to this comment. Perhaps I should add a wrapper script that sets these variables, supposing it is the same phenomenon that causes your tests to fail. In doing so, I could also point SciTECO to a data directory with a relative path and get rid of |
* You can now specify `--with-scitecodatadir` as a relative path, that will be interpreted relative to the binary's location. * Win32 binaries already were relocatable, but this was a Windows-specific hack. Win32 binaries are now built with `--with-scitecodatadir=.` since everything is in a single directory. * Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`. This is not crucial for ordinary installations, but is meant for AppImage creation. * Since AppImages are now built from relocatable packages, we no longer need the unionfs-workaround from pkg2appimage. This should fix the strange root contents when autocompleting in AppImage builds. * This might also fix the appimage.github.io CI issues. I assume that because I could reproduce the issue on FreeBSD's Linuxulator in dependence of pkg2appimage's "union"-setting. See AppImage/appimage.github.io#3402 * Determining the binary location actually turned out be hard and very platform-dependant. There are now implementations for Windows (which could also read argv[0]), Linux and generic UNIX (which works on FreeBSD, but I am not sure about the others). I believe this could also be useful on Mac OS to create app bundles, but this needs to be tested - currently the Mac OS binaries are installed into fixed locations and don't use relocation.
I think it could be fixed now. The binary is now fully relocatable and no longer needs |
1061f6b
to
15d7458
Compare
Works now with the v2.1.1 GTK AppImages. There is a Curses version as well (which also passes the tests), but I presume there can only be one AppImage per entry. In this case, I would prefer the GTK version which has been picked up automatically. |
This should pick up the GTK AppImage now.
No description provided.