You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Would it be possible to build two separated versions of AppImage for X11 and Wayland? #1221
I usually switch from X11 to Wayland and from Wayland to X11. I often use @federico-terzi's Espanso. The problem is that I had to install two versions of Espanso, one designed for X11, another for Wayland.
I use Espanso-X11.AppImage when I switch to X11, and use /usr/bin/espanso compiled and built from a source without X11 when I switch to Wayland, the concern is that, I will always receive an inconvenient Espanso advice about incompatibility when I switch to a different graphic environment because of espanso.service that points to /usr/bin/espanso. I had to use espanso service start --unmanaged.
Imagine that I am switching to i3 that is an X11 window manager or to Sway that is a Wayland window manager, and writing the following code to the i3/Sway config file or on a global Bash/ZSH file):
VERIFY_ENVIRONMENT=$(echo $XDG_SESSION_TYPE)if [[ $VERIFY_ENVIRONMENT=="x11"]];then~/Apps/Espanso-X11.AppImage
espanso service start --unmanaged
else~/Apps/Espanso-Wayland.AppImage
espanso service start --unmanaged
fi
I don't know much about Wayland except that it is not 100% compatible with X11, makes screen sharing complicated, and never works with full performance on my Nvidia based systems, so forgive me if this is a stupid question, but:
Why are there two different versions of the application needed? Wayland proponents tend to claim that X11 applications can run in XWayland.
Of course the author of the Espanso AppImage could make two separate AppImages, but that is not what I'd recommend.
If there are really two different versions of the application needed, then it would be best if the author of the Espanso AppImage would put both versions into the same AppImage, add an if statement in the AppRun, and run the Wayland version of the application in case Wayland is detected to be running on the system. As a result, users could just run the AppImage and it would execute the version needed for their particular window server without the user having to deal with multiple AppImages.
Espanso built for X11 will not work on Wayland due to xclip. Wayland asks for wl-copy.
When I ran Espanso-X11.AppImage on Wayland, I received a warning about the incompatibility.
Not only Espanso, Autokey also doesn't support Wayland because of xclip.
@microsoft's VSCode can run on both X11 and Wayland without needing to build two different versions because it can detect the XDG session and switch to xclip or wl-copy.
@Mange's rofi-emoji can detect if it is X11 or Wayland, and switch to a copy variable assigned to X11 or Wayland's dependency, then it doesn't need two different versions: https://github.com/Mange/rofi-emoji
@gusbemacbe it's a little bit rude to tag people in unrelated issues. Just link to the project - it's clearer that way. Especially since autokey is neither mine nor elleria's
@gusbemacbe it's a little bit rude to tag people in unrelated issues. Just link to the project - it's clearer that way. Especially since autokey is neither mine nor elleria's
Ah, I'm sorry, I always sought to credit the people for the project authorship.
So ideally the Espanso AppImage would ship both and decide at runtime which one to use.
That's a really clever idea, I didn't realize it was possible. I'll investigate further, though IIRC, Espanso is not recommending AppImage on Wayland as it's not compatible with the required Linux capabilities (instead of asking the users for root access on Wayland, Espanso uses Linux capabilities to get the required permissions for a short initial period). As far as I remember from my tests, the way AppImage was structured didn't allow setting linux capabilities to the binary unless the user performed an extraction first
Thanks @federico-terzi. The contents of an AppImage are read-only, as an AppImage is a read-only self-mounting disk image. If the application was installed to e.g., /usr/bin where normal users have no root rights to change anything (and I assume normal users can't change Linux capabilities there either?), how would it work for Wayland there?
(Short overview, not 100% correct, but you'll get the idea.)
Capabilities can be set on files to grant unprivileged processes (i.e., processes whose uid is nonzero which applies to all non-root processes) privileged access to some kernel APIs. This way, one can avoid hacks like suid and doesn't have to run an entire process as root. Since capabilities (just like suid) are stored in the filesystem metadata, they cannot be used when mounting squashfs images as a regular user. This would open all kinds of attack vectors and thus create a huge security problem. (AppImages' squashfs images are mounted with nosuid and a few similar flags for a reason.)
There are modern alternatives to capabilities, suid etc., e.g., polkit. I've never had to work with polkit, really, though, so I'm not sure these would work for this application. I'm relatively sure I've seen AppImages use polkit before, though. See this FAQ for instance.
@federico-terzi maybe you could elaborate a bit on why Wayland needs capabilities for regular applications? You seem to have some understanding of this. Or maybe just link to other resources? I'm curious.
[Desktop Entry]
Categories = Utility;
Comment = A cross-platform text expander written in Rust
Exec = AppRun
Icon = icon
Name = Espanso
Type = Application
X-AppImage-Version = 78df1b7
I ran the command appimagetool espanso-universal/ Espanso-Test.AppImage.
I tested running it, but a small fail:
./Espanso-Test.AppImage
/tmp/.mount_EspansY2znKp/AppRun: line 8: espanso-x11: command not found
Activity
probonopd commentedon Oct 14, 2022
I don't know much about Wayland except that it is not 100% compatible with X11, makes screen sharing complicated, and never works with full performance on my Nvidia based systems, so forgive me if this is a stupid question, but:
Why are there two different versions of the application needed? Wayland proponents tend to claim that X11 applications can run in XWayland.
Of course the author of the Espanso AppImage could make two separate AppImages, but that is not what I'd recommend.
If there are really two different versions of the application needed, then it would be best if the author of the Espanso AppImage would put both versions into the same AppImage, add an
ifstatement in theAppRun, and run the Wayland version of the application in case Wayland is detected to be running on the system. As a result, users could just run the AppImage and it would execute the version needed for their particular window server without the user having to deal with multiple AppImages.gusbemacbe commentedon Oct 15, 2022
Maybe @federico-terzi can explain.
Espanso built for X11 will not work on Wayland due to
xclip. Wayland asks forwl-copy.When I ran
Espanso-X11.AppImageon Wayland, I received a warning about the incompatibility.Not only Espanso, Autokey also doesn't support Wayland because of
xclip.@microsoft's VSCode can run on both X11 and Wayland without needing to build two different versions because it can detect the XDG session and switch to
xcliporwl-copy.@Mange's
rofi-emojican detect if it is X11 or Wayland, and switch to a copy variable assigned to X11 or Wayland's dependency, then it doesn't need two different versions: https://github.com/Mange/rofi-emojiBlueDrink9 commentedon Oct 15, 2022
@gusbemacbe it's a little bit rude to tag people in unrelated issues. Just link to the project - it's clearer that way. Especially since autokey is neither mine nor elleria's
gusbemacbe commentedon Oct 15, 2022
Ah, I'm sorry, I always sought to credit the people for the project authorship.
probonopd commentedon Oct 15, 2022
I see. So ideally the Espanso AppImage would ship both and decide at runtime which one to use.
TheAssassin commentedon Oct 15, 2022
I second building some unified AppImage that supports either system. With some scripting it should be possible to make some prototype.
federico-terzi commentedon Oct 17, 2022
Hey everyone, thanks for the feedback!
That's a really clever idea, I didn't realize it was possible. I'll investigate further, though IIRC, Espanso is not recommending AppImage on Wayland as it's not compatible with the required Linux capabilities (instead of asking the users for root access on Wayland, Espanso uses Linux capabilities to get the required permissions for a short initial period). As far as I remember from my tests, the way AppImage was structured didn't allow setting linux capabilities to the binary unless the user performed an extraction first
probonopd commentedon Oct 17, 2022
Thanks @federico-terzi. The contents of an AppImage are read-only, as an AppImage is a read-only self-mounting disk image. If the application was installed to e.g.,
/usr/binwhere normal users have no root rights to change anything (and I assume normal users can't change Linux capabilities there either?), how would it work for Wayland there?TheAssassin commentedon Oct 17, 2022
(Short overview, not 100% correct, but you'll get the idea.)
Capabilities can be set on files to grant unprivileged processes (i.e., processes whose uid is nonzero which applies to all non-root processes) privileged access to some kernel APIs. This way, one can avoid hacks like
suidand doesn't have to run an entire process asroot. Since capabilities (just likesuid) are stored in the filesystem metadata, they cannot be used when mounting squashfs images as a regular user. This would open all kinds of attack vectors and thus create a huge security problem. (AppImages' squashfs images are mounted withnosuidand a few similar flags for a reason.)There are modern alternatives to capabilities, suid etc., e.g.,
polkit. I've never had to work with polkit, really, though, so I'm not sure these would work for this application. I'm relatively sure I've seen AppImages use polkit before, though. See this FAQ for instance.@federico-terzi maybe you could elaborate a bit on why Wayland needs capabilities for regular applications? You seem to have some understanding of this. Or maybe just link to other resources? I'm curious.
probonopd commentedon Oct 17, 2022
Uh, is this a Linuxism that Wayland now requires? How does this work on non-Linux POSIX systems?
TheAssassin commentedon Oct 17, 2022
I don't think this may be 100% accurate. I've been running some GUI software packaged as an AppImage on a Wayland system today...
probonopd commentedon Oct 17, 2022
...yes, it's not AppImage that requires this Linux capabilities thingy ;-)
gusbemacbe commentedon Mar 23, 2023
Hello @probonopd
I am building and testing an AppImage to make Espanso, but a small fail.
I copied Debian's Espanso's X11 and Wayland to
usr/bin/of the AppImage folder, and renaming them toespanso-x11andespanso-wayland.I wrote a pure Bash script:
I symlinked this pure Bash script to
AppRun.I updated the desktop file:
appimagetool espanso-universal/ Espanso-Test.AppImage.I tested running it, but a small fail:
probonopd commentedon Mar 25, 2023
You need to change your script so that it loads
espanso-x11from the directory it is in, rather than from the user's current working directory (cwd).In other words, your script seems to want to load
expanso-x11from./rather than from/tmp/.mount_Espans<xxxxxx>/usr/bin/.ppvnf commentedon Apr 7, 2024
any update on this?
TheAssassin commentedon Apr 7, 2024
@ppvnf your question makes no sense. Please specify.
That said, this is more of a question. Moving to discussions.