Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Create SciTECO #3402

wants to merge 1 commit into from

Conversation

rhaberkorn
Copy link

No description provided.

@rhaberkorn
Copy link
Author

rhaberkorn commented Oct 17, 2024

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.

@rhaberkorn
Copy link
Author

rhaberkorn commented Oct 17, 2024

@rhaberkorn
Copy link
Author

@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?

@probonopd
Copy link
Member

probonopd commented Nov 3, 2024

Not really sure how to interpret this Unrecognized image file format:


Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Info: Added new unnamed file to ring.
Bail out! Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)

@rhaberkorn
Copy link
Author

rhaberkorn commented Nov 3, 2024

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 --appimage-extract:

rhaberkorn@thinkpad-x270:~/Downloads$ ./squashfs-root/AppRun --no-profile
Gtk-Message: 21:18:57.318: Failed to load module "gtk-vector-screenshot"
Info: Added new unnamed file to ring.

(gsciteco:38670): Gtk-WARNING **: 21:18:57.375: Could not find the icon 'text-x-generic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
        http://icon-theme.freedesktop.org/releases

(gsciteco:38670): Gtk-WARNING **: 21:18:57.375: Could not load a pixbuf from /org/gtk/libgtk/icons/24x24/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/24x24/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/24x24/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Aborted

Works fine on a real Ubuntu, though. There isn't necessarily any connection to the CI issues.
btw. the AppImage in its current form does not contain any libraries at all (except libunionpreload.so).

Perhaps we should have a look at some other Gtk App in the registry, that was built with pkg2appimage.

@rhaberkorn
Copy link
Author

Not really sure how to interpret this Unrecognized image file format:

The image file itself should be available via a built-in resource.
Adding any of the icon themes (adwaita-icon-theme(-full), hicolor-icon-theme, gnome-icon-theme) did not actually add anything into the AppImage - something is removing these files afterwards.

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

export XDG_DATA_HOME="$HOME/.local/share:/root/.local/share:/usr/local/share/:/usr/share/"
export XDG_DATA_DIRS="$HOME/.local/share:/root/.local/share:/usr/local/share/:/usr/share/"

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 union: true.

rhaberkorn added a commit to rhaberkorn/sciteco that referenced this pull request Nov 5, 2024
* 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.
@rhaberkorn
Copy link
Author

I think it could be fixed now. The binary is now fully relocatable and no longer needs union: true.
But since you only take releases by default, I will update this merge request only once SciTECO v2.1.1 is released later that month.

@rhaberkorn rhaberkorn force-pushed the patch-1 branch 2 times, most recently from 1061f6b to 15d7458 Compare November 17, 2024 22:58
@rhaberkorn
Copy link
Author

rhaberkorn commented Nov 17, 2024

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants