AppImage
Update synthv1
synthv1_jack: error while loading shared libraries: libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory
synthv1_jack: error while loading shared libraries: libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory
please re-trigger the checks: libxkbcommon-x11.so.0 is now explicitly included in the OBS build.
Still giving the same error: synthv1_jack: error while loading shared libraries: libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory. Strange. Let me know if you want me to look into it deeper.
Strange. Let me know if you want me to look into it deeper. the issue got a workaround now: previous the upstream build was linking to custom qt6-static that indirectly depends on those libxkbcommon*.so ...
I guess the appimagetool or build-pkg2appimage (as from OBS) couldn't read those indirect dependencies at all; the OBS build as been made to link to libqt5-shared and now should work right.
please re-trigger the checks once again. thanks
Thank you. This test now also says
ERROR: Could not find a single window on screen :-(
I don't know why this happens, as I can't see an error message on the command line. Possibly this is some issue with the test itself. More investigation needed.
Thank you. This test now also says
ERROR: Could not find a single window on screen :-(
I don't know why this happens, as I can't see an error message on the command line. Possibly this is some issue with the test itself. More investigation needed.
yes, i believe it's in the test itself: it's trying to grab a screenshot and no window appears--most often because it doesn't even start on time because no JACK service is up and running?--besides I believe it tries to grab a screenshot because earlier it doesn't find an appdata/metainfo file: maybe because it's looking for an (old spec) *.appdata.xml file when now it is *.metainfo.xml alright.
Indeed no jack server is running on the test system. Would you know how to run a minimal jack server that is sufficient for getting your apps running but doesn't need an actual sound card?
Indeed no jack server is running on the test system. Would you know how to run a minimal jack server that is sufficient for getting your apps running but doesn't need an actual sound card?
jackd -d dummy &
but
I'd rather fix the screenshot requirement via grabbing or test whether a window exists: it's not reliable as the initial window maybe too bland to matter :) please fix the appstream issue first: the *.metainfo.xml file provides the official screenshot anyway and that probably would be better suited than waiting for a fake window to appear anyhow.
Yes, the way this works: Every AppImage must pass the test, as part of which a screenshot is taken. If the AppStream data contains a screenshot, then that screenshot is used afterwards for the "product detail page". That, however, does not remove the need for the test to pass, which requires a screenshot to be taken. Which is intentional.
So, if your applications would display a message box saying "You need to be running jackd to run this application", then I guess we could take a screenshot of that, the test would be satisfied, and as a result the applications could be added to the catalog, where the "nice" screenshots from AppStream would be shown instead of the error message.
Does this make sense?
Semi-OT: Is there the slightest chance of your programs to also support ALSA one day? I am sure your software is great but JACK is the antithesis of "plug and play" for me (and I am not alone). It always seems to need some manual configuration first before it does anything.
all of my qstuff rely on JACK and there are no plans to make them to ALSA only, which defeats the inter-operability concept into "egoistic-toys" and not a real pro-audio component; the ALSA option is desirable for "monolithic-DAWs", that don't talk to anything else but the hardware sound-devices only (thus ALSA is OK), where everything and the kitchen-sink is managed under their own umbrella; for that matter, Qtractor is not, never will be such a beast, sorry :)
exceptions are Qsampler, QmidiCtl and QXGEdit which are not tied to JACK whatsoever; and as it seems they are suffering from the same "no-window appears" issues as bad... please consider to take the check-test only for runtime-linkage startup errors and not to take any screenshots or rely on some x11 system to be working headless properly; it clearly isn't working at all. thanks anyway
UPDATE: wait a minute! I think I found the culprit: it seems that the screenshot check is being invoked with ./BeingTested.AppImage --help ? that probably explains why no window ever appears: it's asking to show the command line options: all of the qstuff, without exception, prints out the --help info to stdout and then bail out immediately!
Thanks for your explanation. I understand. Maybe one day I will "click" with JACK, so far it hasn't happened.
Qsampler, QmidiCtl end QXGEdit which are not tied to JACK whatsoever; and as it seems they are suffering from the same "no-window appears" issues as bad.
I will have to investigate this deeper. Sorry for the trouble. At the moment I don't understand why this is happening.
I will have to investigate this deeper. Sorry for the trouble. At the moment I don't understand why this is happening.
maybe my last comment rings some bells?
You say Qsampler, QmidiCtl and QXGEdit don't need JACK. Strangely I get no clear error message from the headless test, but also no window. I have never seen this before (for GUI applications). Right now the presence of a window is required for the test to pass, because one part of the test is me looking at the automatically taken screenshot to see that it's not just a blank window (you'd be surprised how often you get that, e.g., with Electron-based apps when not allowed to access the internet).
My current hypothesis is that Qsampler, QmidiCtl and QXGEdit don't like being sandboxed with Firejail (which is what the test is doing in oder to deny the application under test internet access, in order to see how applications react to this).
That should only affects command line tools (which have Terminal=true set in their desktop file)... for graphical applications, this line should not even be used. Unless I made a mistake.
That should only affects command line tools (which have
Terminal=trueset in their desktop file)... for graphical applications, this line should not even be used. Unless I made a mistake.
well, I don't see anywhere TERMINAL is ever assigned, let alone to "false"... but I'm probably not looking thoroughly ;)
https://github.com/AppImage/appimage.github.io/blob/d45d02d6c4e4214b998b4f15477be7106cd4f286/code/worker.sh#L208-L210
ohkay. sorry my bad. I'm out of ideas :(
one thing is for sure, i've tested all the .AppImages on ubuntu 18.04, 20.04 and openSUSE TW ofc, and they all show a window alright :)
On a "throwaway system" (e.g., Live ISO or VM), one could do what the test does and see how it is going:
# "Install" Firejail
# The simplest and most straightforward way to get the most recent version
# of Firejail running on a less than recent OS; don't do this at home kids
FILE=$(wget -q "http://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/" -O - | grep musl-1 | head -n 1 | cut -d '"' -f 2)
wget -c "http://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/$FILE"
FILE=$(wget -q "http://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/" -O - | grep firejail-0 | head -n 1 | cut -d '"' -f 2)
wget -c "http://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/$FILE"
sudo tar xf musl-*.apk -C / 2>/dev/null
sudo tar xf firejail-*.apk -C / 2>/dev/null
sudo chown root:root /usr/bin/firejail ; sudo chmod u+s /usr/bin/firejail # suid
firejail --quiet --noprofile --net=none --appimage ./Your.AppImage &
# Get a list of open windows
xwininfo -tree -root | grep 0x | grep '": ("' | sed -e 's/^[[:space:]]*//'
# Count the windows on screen
NUMBER_OF_WINDOWS=$(xwininfo -tree -root | grep 0x | grep '": ("' | sed -e 's/^[[:space:]]*//' | wc -l)
echo "NUMBER_OF_WINDOWS: $NUMBER_OF_WINDOWS"
if [ $(($NUMBER_OF_WINDOWS)) -lt 1 ] ; then
echo "ERROR: Could not find a single window on screen :-("
exit 1
fi
On a "throwaway system" (e.g., Live ISO or VM), one could do what the test does and see how it is going:
And... just did it on an plain kubuntu18.04 (qemu/kvm) and it did work all the way (even though jackd was not up and running at the time whatsoever): the window appeared alright!
firejail --quiet --noprofile --net=none --appimage ./synthv1-jack-latest.x86_64.AppImage &
...
xwininfo -tree -root | grep 0x | grep '": ("' | sed -e 's/^[[:space:]]*//'
...
0x3600006 "synthv1": ("synthv1_jack" "synthv1") 1136x502+0+0 +304+364
...
NUMBER_OF_WINDOWS=$(xwininfo -tree -root | grep 0x | grep '": ("' | sed -e 's/^[[:space:]]*//' | wc -l)
echo "NUMBER_OF_WINDOWS: $NUMBER_OF_WINDOWS"
NUMBER_OF_WINDOWS: 18
Not yet I am afraid. My suspicion is that there is some dependency that the headless test system doesn't fulfill but I don't know yet what it might be. My blind guess would be that it has something to do with JACK, but that's just a gut feeling because I can never get that thing to work on first try.
as said once or twice earlier, you don't really need jackd(bus) to be up and running for the window to come up and show :) there must be something else... also, qsampler doesn't link nor bind to JACK whatsoever and it seems to suffer from the same ordeals cf. https://github.com/AppImage/appimage.github.io/pull/2866
ps. besides, last check/test was done 9 days ago? not really a recent status is it?