Guild icon
S3Drive
Community / support / S3Drive AppImage fails on Wayland on v1.12
Avatar
I am running S3Drive on Linux (OpenSuSE Tumbleweed) using the AppImage. v1.11 has been working fine for me. But I just updated to 1.12.8 and it's giving me an error when I try to run it. Failed to initialize GLArea: No GL implementation is available I can work around the problem by launching it with: GDK_BACKEND=x11 ./S3Drive-x86_64.AppImage I'm guessing the AppImage build is missing a library needed for this to work on Wayland.
Avatar
Thanks for your report. What's your desktop environment? Is that KDE, GNOME or perhaps Xfce? Does it run "fine enough" using the: GDK_BACKEND=x11 trick? Have you tried our Flathub release?
Avatar
We've tried on a Tumbleweed (KDE) in a VM and without any additions, AppImage starts, however libsecret fails to be initalized for some reason. This can be resolved with: sudo zypper install -y gnome-keyring though. (edited)
Avatar
Avatar
Tom
Thanks for your report. What's your desktop environment? Is that KDE, GNOME or perhaps Xfce? Does it run "fine enough" using the: GDK_BACKEND=x11 trick? Have you tried our Flathub release?
KDE. It does run fine enough with GDK_BACKEND=x11, though it's a bit annoying to run that way. I haven't tried the Flathub release in a while. (edited)
Avatar
Avatar
Tom
We've tried on a Tumbleweed (KDE) in a VM and without any additions, AppImage starts, however libsecret fails to be initalized for some reason. This can be resolved with: sudo zypper install -y gnome-keyring though. (edited)
Did you switch to Wayland? This can be done before logging in. On the login screen there is a setting you chan change to switch between X11 and Wqyland.
Avatar
That was my login screen, all I did is type my super secure password and logged in. I haven't changed any defaults. (edited)
Avatar
Avatar
Tom
That was my login screen, all I did is type my super secure password and logged in. I haven't changed any defaults. (edited)
Yeah, bottom left you can see it's using X11
11:19 AM
If you swap it to Wayland before logging in, I imagine you can replicate my issue (edited)
11:20 AM
(I'm surprised they havent switched to Wayland by default, though I imagine they will be doing this before too long.)
Avatar
Fair enough, the error appears now. I will play around and let you know if I manage to have it resolved somehow. (edited)
❤️ 1
Avatar
Thanks!
11:22 AM
I did do some googling and it appears this may be a common issue with flutter apps bundled as an AppImage. And I'm guessing S3Drive is a flutter app? I'm guessing it's missing a library when built as an AppImage but it could be a problem with Flutter itself? (edited)
11:23 AM
It's also interesting that it worked fine in v1.11. Though it's possible that's just because v.1.12 is actually being built with wayland support now, where maybe v1.11 wasn't. (edited)
Avatar
Avatar
Sarelle
I did do some googling and it appears this may be a common issue with flutter apps bundled as an AppImage. And I'm guessing S3Drive is a flutter app? I'm guessing it's missing a library when built as an AppImage but it could be a problem with Flutter itself? (edited)
Yes it is a Flutter with embedding to host OS (depending on the platform).
It's also interesting that it worked fine in v1.11.
I would need to check, but we've likely updated Flutter version in the meantime which was also in the process of switching to a different rendering engine.
with wayland support
Actually, there was a change starting with 1.12.0, that was us including: - libwayland-server0 - libwayland-cursor0 - libwayland-client0 in the AppImage. https://github.com/s3drive/app/issues/60 It sounds like it fixed issues on: Ubuntu 18.04 that user was reporting, but broke something else. I need to admit that Linux releases are pretty "funny" part of this project 🙂
(edited)
Avatar
I need to admit that Linux releases are pretty "funny" part of this project
Haha, understandable. I do appreciate the effort though! I'm a software dev myself, but I've always used Linux as my main dev environment. So I'm pretty used to this world 😄
(edited)
11:31 AM
In theory AppImage should solve most of this stuff, but it's also highly dependent on having it's image packaged "just right".
11:34 AM
More and more distributions are moving to Wayland by default, so I expect this to shake up some stuff. (Fedora isn't even shipping X11 in their next release!)
11:37 AM
As a debugging step, it may help to have the AppImage startup run ldd against the binary and dump the output. May tell you whats missing. (Assuming the library needed isn't entirely looked up at runtime)
Avatar
In such case it might actually have more sense to "not include" it in the AppImage, given it's becoming a default. I will play around and see what can be realistically done. There is a chance we unfortunately need to sacrifice older OS's like Ubuntu 18.04, for the "greater good". Having multiple AppImage releases isn't something we anticipate either. Thanks for the: ldd hints. I can't promise I'll have it resolved today or tomorrow, but I will try to get back to you soon.
Avatar
Right, so here is most recent release, but without wayland libs added: https://github.com/s3drive/appimage-app/releases/tag/1.12.8-wayland-test It seems to start fine now. I will try to invest more time into this later, but very likely those are the release settings we will be using going forwards.
Avatar
Avatar
Sarelle
(I'm surprised they havent switched to Wayland by default, though I imagine they will be doing this before too long.)
Perhaps it has something to do with Oracle VM and detecting the best settings. I didn't have 3D acceleration enabled and Wayland seem to be bit glitchy (screen artifacts), perhaps that's why it used X11 by default.
Avatar
Avatar
Tom
Right, so here is most recent release, but without wayland libs added: https://github.com/s3drive/appimage-app/releases/tag/1.12.8-wayland-test It seems to start fine now. I will try to invest more time into this later, but very likely those are the release settings we will be using going forwards.
My hero :). I'll give it a try. It's worth noting that AppImage seems to want you to depend on the "base system" libs for stuff like this. So I think not including wayland I think may be "correct". But if you do include wayland you may also have to include Mesa and etc... which will likely be quite the journey of dependancies 🙂
12:10 PM
There is a "worst case" solution you could employ as well. Forcing X11 with that environment variable. I do think X11 apps will be supported on wayland for quite a while for compatibility reasons, even if X11 itself isn't being shipped in distros. But I do think with AppImage you will find supporting older systems to be a bit problematic over time. So I dunno 🙂
Avatar
Avatar
Tom
Right, so here is most recent release, but without wayland libs added: https://github.com/s3drive/appimage-app/releases/tag/1.12.8-wayland-test It seems to start fine now. I will try to invest more time into this later, but very likely those are the release settings we will be using going forwards.
Bam, this is working for me!
Avatar
It could be worth pushing people on older systems to use flatpak? AppImage is more of a distribution format than a compatibility thing. So it still depends on your system installed libraries and etc. But flatpak does lets you dictate the runtime environment used by the app. Of course, that does mean it's by necessity more bloated. Installing an app can end up installing a bunch of redundant libraries and etc. Which is why I've been personally using apps via AppImage instead of flatpak. (And why I'm glad yall provide an AppImage!)
12:25 PM
As a side note, I did run ldd on the binary on my system with the previous v1.12 build and it didn't reveal anything helpful. (edited)
12:30 PM
Anyhow. I appreciate the effort yall spend to support my native environment! S3Drive is a great product and one I was happy to pay for! (And a heck of a lot more convenient than mucking with rclone directly, which is what I was doing before buying S3Drive. Never mind that I can't use rclone from my ipad). (edited)
❤️ 1
Exported 28 message(s)
Timezone: UTC+0