Provide an AppImage

[probonopd]

On page 37 of https://conf.kde.org/system/attachments/94/original/TimotheeGiet-GCompris-Akademy2017.pdf it says

Help creating an appimage

[probonopd]

Started work at https://github.com/probonopd/GCompris-qt/blob/patch-1/.travis.yml
Build log at https://travis-ci.org/probonopd/GCompris-qt

[probonopd]

Is a GitHub push -> Travis CI -> GitHub Releases workflow acceptable?

[probonopd]

Still running into compilation issues, https://travis-ci.org/probonopd/GCompris-qt/builds/. Any help appreciated.

[probonopd]

Update: Compilation is working now, AppImage gets built.

Build log:
https://travis-ci.org/probonopd/GCompris-qt

Remaining issue:
plugins/imageformats/libqsvg.so does not get deployed, caused by probonopd/linuxdeployqt#82.

[probonopd]

Applying a workaround, https://transfer.sh/azDIU/GCompris-git.1f109eb-x86_64.AppImage is available for testing now. Seems to be working on openSUSE LEAP 42.2.

[petitlapin]

Hi,
I have some issue with gstreamer on a fresh ubuntu install: Inconsistency detected by ld.so: dl-tls.c: 74: _dl_next_tls_modid: Assertion `result <= GL(dl_tls_max_dtv_idx) + 1' failed!
Full log at: https://pastebin.com/gXQiSH0S

[probonopd]

Thanks @petitlapin, interesting. Seems to be glibc related. More investigation is needed. Don't remember having seen this before.

Seems to have to do with

External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.

According to https://bbs.archlinux.org/viewtopic.php?id=8626,

This is a bug in glibc NPTL and gets triggered by libs that use TLS (Thread local storage) and load a lib via dlopen() calls that fail with unresolved symbols or library dependencies.

So we need to find the cause of the GStremer issues and fix them.

[petitlapin]

Hi,

sorry for delay.

I tested it on my daily machine with archlinux and on a KaOS virtual machine. The application runs but there are no sound:
(GCompris-git.1f109eb-x86_64.AppImage:2337): GStreamer-CRITICAL **: gst_element_add_pad: assertion 'GST_IS_PAD (pad)' failed
(GCompris-git.1f109eb-x86_64.AppImage:2337): GStreamer-CRITICAL **: gst_object_unref: assertion 'object != NULL' failed
Also the translations are not built and shipped, to have them we need to add a few steps in the install:

• cmake .. -DCMAKE_INSTALL_PREFIX=/usr
• make getSvnTranslations
• cmake .. -DCMAKE_INSTALL_PREFIX=/usr (it needs to be run again so cmake knows about translations, we haven't found a solution to not having to not run cmake again)
• make BuildTranslations
• make -j$(nproc)
  ... (as before)

[probonopd]

Thanks @petitlapin. Could you send a Pull Request please?

[probonopd]

So possibly we need to bundle a private copy of gstreamer and its plugins. This may be some work.

[azubieta]

I've send a MR on invent that adds a recipe for building GCompris AppImages using appimage-builder.

Please check: https://invent.kde.org/education/gcompris/-/merge_requests/38

[probonopd]

AppImage for testing: https://invent.kde.org/alexislo/gcompris/-/jobs/65555/artifacts/raw/build/GCompris--x86_64.AppImage (expires in one week)

[Animtim]

Thanks! I just answered on the MR on invent...

[Animtim]

and... still some issues, when launching the test appimage here, it crashes directly:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

[probonopd]

@Animtim which system are you on? Can you run it with strace?

[Animtim]

Oh, actually "false alarm"... it's a known issue of mageia 7 (I need to unset QT_PLUGIN_PATH before running appimages with a different Qt version than system one... see https://bugs.mageia.org/show_bug.cgi?id=25038 ).

So, indeed it launches, and I could compare with our standalone package version.

-The appimage takes around twice more time to launch (~15s for the appimage, ~7sec for our standalone package)
-The appimage seems to be less "fluid": when clicking on an animal of the main menu categories selector, with our package it's instantly switching to it, while with the appimage it takes ~2s to react). I'm not sure what can be the cause for this delay.

Anyway, good to see progress on the topic :)

[probonopd]

@azubieta is it possible to unset QT_PLUGIN_PATH in .env?

The appimage takes around twice more time to launch (~15s for the appimage, ~7sec for our standalone package)

Could this be due to path overlay code?

The appimage seems to be less "fluid": when clicking on an animal of the main menu categories selector, with our package it's instantly switching to it, while with the appimage it takes ~2s to react).

Maybe somehow related to GPU accleration?

[Animtim]

The appimage takes around twice more time to launch (~15s for the appimage, ~7sec for our standalone package)

Could this be due to path overlay code?

Not sure... maybe simply due to the fact that appimage (170.9 Mio) has "duplicates" libraries to load, while our standalone package (72Mio tar.xz) uses a few system libraries... Or, is appimage compressed somehow? (that would also require a little extra time to uncompress before loading?)

The appimage seems to be less "fluid": when clicking on an animal of the main menu categories selector, with our package it's instantly switching to it, while with the appimage it takes ~2s to react).

Maybe somehow related to GPU accleration?

It feels indeed like an issue of GPU acceleration not working optimally with this appimage.

[probonopd]

Is appimage compressed somehow?

Yes. To see the difference, you can run --appimage-extract it and then run the extracted contents with ./squashfs-root/AppRun.

[probonopd]

It feels indeed like an issue of GPU acceleration not working optimally with this appimage.

@azubieta can you reproduce this?

[Animtim]

Is appimage compressed somehow?

Yes. To see the difference, you can run --appimage-extract it and then run the extracted contents with ./squashfs-root/AppRun.

Right, after extracting it is a little faster (~10s).

[probonopd]

What kind of hardware are you running on (type of disk/SSD, CPU class)?

[Animtim]

SSD drive, i5 cpu and internal GPU (HD 4000).

[azubieta]

It feels indeed like an issue of GPU acceleration not working optimally with this appimage.

@azubieta can you reproduce this?

What I can notice is a bit of lag while loading the resources. The animation is smooth once it begins.

[azubieta]

@azubieta is it possible to unset QT_PLUGIN_PATH in .env?

Yes.

Could this be due to path overlay code?

Maybe, let's test it.

[probonopd]

Hi @azubieta did you have a chance to look into the performance topic yet? Thanks a lot.

[Animtim]

About the performance topic (slow categories selection), we noticed it was (at least partly) related to some changes in our code that made loading activity categories slower. Then @petitlapin made some changes to optimize this part so it should be better, would be good to have a new appimage generated to test with latest changes.

[azubieta]

I have made a MR on https://invent.kde.org/education/gcompris/-/merge_requests/38
but it's block due limitations of the infrastructure. I'll be sending a new one on Github soon.

[probonopd]

What happened to the AppImage builds on https://invent.kde.org/alexislo/gcompris?

Reference:
AppImage/appimage.github.io#2330