I don’t know why my app, redrose, as a snap uploaded last week, worked fine and now doesn’t start anymore:
Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.
xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
Erreur de segmentation (core dumped)
when running with strace, i get:
[pid 39872] newfstatat(AT_FDCWD, "/snap/redrose/23/gnome-platform/usr/share/X11/xkb", 0x7ffd60981360, 0) = -1 ENOENT (No such file or directory)
I tried to make, then, a new snap with xkb-data included but this doesn’t work either.
I don’t know the magic of snaps, but my snap (this exact one) used to work last week!
Any help please ? in the mean time if I remove the snap from the store (channel edge), how can I make people downgrade to the previous snap which is on the beta channel (known to work, based on core20) ?
You can force a downgrade by just re-promoting the older revision to the current latest/stable, there’s nothing saying they have to be in ascending order.
I’m guessing what’s happened here is that the Gnome 46 runtime has shipped with include files for X11 when it shouldn’t have. I’m assuming that these have since been removed as they’re waste space and ergo performance in most snaps. Ideally the content snaps wouldn’t change this “drastically” but in the context of most snaps, it’s not particularly drastic, more functionality that shouldn’t have been there in the first place.
The easiest thing to do would be to stage those headers yourself, and then either set env vars so that the headers in your own snap and searched for, or use a snap layout to symlink /usr/include/ to $SNAP/usr/include, personally I cheat and do the second the one time I’ve needed to.
It is however interesting that your snap seems to depend on its build environment for its runtime environment, I’ve only met one other snap that had such an explicit dependency like that and I publish it. I’m sure there probably are others, but, this is super weird to just see happen in the wild.
Thank you for your reply. Why /usr/include should have to be bound while the not found directory is /usr/share/X11/xkb (from xkb-data) ? Maybe a typo ?
That’s a typo yes, I saw the word INCLUDE folder and assumed/typo’d the most common one. But in effect, it’s just putting those files in $SNAP so that you alone are responsible for them being there. That way they don’t disappear unexpectedly in the future.
How you actually do that would be either with stage-packages or copying from the build snap into the prime folder, which would depend upon ABI compatibility of that package. Being X11, I’m assuming it doesn’t get updated much anymore so the stage-packages is simpler and what I’d go for first.
(I’m assuming the contents of those folders are C++ Header/source files).
Thank you for your help. gnome-platform has libxkbcommon, but…
Here is an strace which shows gnome-platform is missing xkb-data stuff.
Note that the Error message is misleading since /usr/share/X11/xkb is actually not accessed.
However, gnome-platform/usr/share/X11/xkb is, and is missing.
newfstatat(AT_FDCWD, "/home/ben/snap/redrose/x1/.config/xkb", 0x7ffe479b7a50, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
newfstatat(AT_FDCWD, "/home/ben/snap/redrose/x1/.xkb", 0x7ffe479b7a50, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
newfstatat(AT_FDCWD, "/etc/xkb", 0x7ffe479b7a50, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
newfstatat(AT_FDCWD, "/snap/redrose/x1/gnome-platform/usr/share/X11/xkb", 0x7ffe479b7a50, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
write(2, "xkbcommon: ERROR: ", 18xkbcommon: ERROR: ) = 18
write(2, "failed to add default include pa"..., 54failed to add default include path /usr/share/X11/xkb
write(2, "qt.qpa.wayland: failed to create"..., 45qt.qpa.wayland: failed to create xkb context
