search

tauri-apps / tauri

Build smaller, faster, and more secure desktop applications with a web frontend.
https://tauri.app
Apache License 2.0
81.79k stars 2.45k forks source link

[bug] AppImage show error on Manjaro and Debian #3715

Closed kfiven closed 2 years ago

kfiven commented 2 years ago

Describe the bug

When installing AppImage on Manjaro it shows the following errors: image

When installing on Debian 11/bullseye:

./cinny_1.8.1_amd64.AppImage
Gtk-Message: 19:54:32.651: Failed to load module "colorreload-gtk-module"
Gtk-Message: 19:54:32.652: Failed to load module "window-decorations-gtk-module"
Gtk-Message: 19:54:33.148: Failed to load module "colorreload-gtk-module"
Gtk-Message: 19:54:33.148: Failed to load module "window-decorations-gtk-module"

Reproduction

Expected behavior

AppImage should be self contained as explained in https://github.com/tauri-apps/tauri/discussions/2924#discussioncomment-1666317

Platform and versions

Operating System - Ubuntu 20.04.4 LTS
Wwebkit2gtk-4.0

Node.js environment
  Node.js - 17.6.0
  @tauri-apps/cli - 1.0.0-rc.7
  @tauri-apps/api - 1.0.0-rc.2

Global packages
  npm - 8.5.1
  pnpm - Not installed
  yarn - 1.22.17

Rust environment
  rustup 1.24.3 (ce5817a94 2021-05-31)
  rustc 1.59.0 (9d1b2106e 2022-02-23)
  cargo 1.59.0 (49d8809dc 2022-02-10)
  toolchain - stable-x86_64-unknown-linux-gnu

App directory structure
/.git
/.github
/contrib
/dist
/node_modules
/public
/src
/src-tauri

App
  tauri - 1.0.0-rc.4
  tauri-build - 1.0.0-rc.4
  tao - 0.6.4
  wry - 0.13.3
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../dist
  devPath - http://localhost:8080/
  framework - React
  bundler - Webpack

Stack trace

No response

Additional context

No response

FabianLars commented 2 years ago

Just gonna copy paste my discord message for transparency or whatever https://discord.com/channels/616186924390023171/731495028677148753/953904420813439036

The fixed issue was only about the last line of their error message. The modules mentioned in the gtk messages were not relevant at all (especially canberra lol).

Your errors are only warnings too and not critical to run the application. That said native window decorations may look wrong with the missing window-decorations module, so I'm gonna look into it anyway. Especially since we already bundle those files (at least we do that with the modules from the other issue) just need to tell GTK where to look for them (I didn't find a way last time :/ )

Can you add a list of OS + Desktop Environment you build and tested on (well you did the first one already, so it's more about the DEs here)

kfiven commented 2 years ago

I have tested and getting these errors on following:

kfiven commented 2 years ago

Will try to check on more.

FabianLars commented 2 years ago

That's enough for me, thank you.

Debian + Gnome is kinda surprising tho since the os file structure should match the Ubuntu one (therefore it should find the system one since we didn't change the "search folder")

kfiven commented 2 years ago

You meant Debian + KDE?

FabianLars commented 2 years ago

Haha nevermind I can't read, sry.

That explains it then (if it's similar to other appimage problems we had). kde sometimes just doesn't have these gtk specific files and Manjaro has a different fs structure.

naaive commented 2 years ago

naaive/orange/issues/14

FabianLars commented 2 years ago

My findings so far:

I'm not 100% sure how to proceed here. All these warnings shouldn't really affect the app (if they do, i'd appreciate screenshots). If i fix canberra the others should somewhat be fixed too but the modules need to be installed on the build system, which is not always possible (for example i didn't find the colorreload module for fedora or ubuntu). The alternative would be to ask gtk to look for system resources, but a we don't know if and where it's installed and it can cause version conflicts... ("if" and "where" shouldn't really cause issues since GTK_PATH can be a list of paths if i got that right, but we won't ever be able to cover every distro/DE this way)

tldr: If the fix won't break anything else I will fix the canberra module and will close this issue as won't fix until someone has proof that these warnings actually cause issues for them (even then, no promises since there doesn't seem to exist a perfect fix)

Edit: Okay, the canberra fix does seem to work without breaking anything on my end. Good enough for a live test if you ask me :joy: I play with the idea to abuse our release candidate version to live test the part about "ask gtk to look for system resources" too, if it works locally (gonna edit this message again after local tests)

Edit2: Adding absolute paths doesn't seem to cause any problems, i'll try to test some more distros and will merge the changes afterwards for a live test (this means that the change will be forced on all users without them needing to update anything)

kfiven commented 2 years ago

Don't know if it's related to these module errors but in the screenshot I shared in issue, Cinny Tauri app is fails to make requests to homeserver so login doesn't not work. This doesn't happen on mac and windows. I don't have linux os at hand so wasn't able to debug.

FabianLars commented 2 years ago

Okay thanks for the heads-up. I'll try to look into it when I'm back home. We had issues with the browser's built-in http stuff because of other missing files so it wouldn't surprise me if it needs another one... What's more fun than packaging apps on Linux 😂

FabianLars commented 2 years ago

Okay so i merged the change for the live test, but i'm 99% sure it doesn't break anything, because i did quite a lot of testing already.

After this change i won't "fix" any appimage warnings without proof that the app actually doesn't function properly (which it did with these warnings).

That said, i will look into the connection error tomorrow, because that one's actually breaking and seemingly similar to another glib-net problem we had some time ago). So far it seems to only happen if the app was built on ubuntu (building on fedora for example, produces a working appimage)

FabianLars commented 2 years ago

I have no idea what causes that connection error, in the devtools console it says something like "internal webkit error", which isn't really helpful, especially since doing the request manually in the devtools console works completely fine. Furthermore i was only able to reproduce this error on ubuntu, building on other distros was fine. It's also not a cross-distro compatibility problem since the appimage built on ubuntu doesn't work on that very same system either...

Since the initial reported problem is fixed i'm gonna close this issue and keep looking for solutions, but i spent so much time on that already i'm not really hopeful that there really is a (easy) solution so maybe i just have to implement flatpak support earlier than planned so we can promote that one as the main way to distrribute your app :shrug:

kfiven commented 2 years ago

Alright, btw just ftr cinny: error while loading shared libraries: libOpenGL.so.0: cannot open shared object file: No such file or directory is what I got on Ubuntu with AppImage while I was able to get app installed with .deb but no luck on http requests.

FabianLars commented 2 years ago

cinny: error while loading shared libraries: libOpenGL.so.0: cannot open shared object file: No such file or directory

Yeah that's a driver problem though, or a wsl problem, can't remember but that file is not bundled into the appimage by design (nobody does it since it depends on the gpu driver or whatever)

I was able to get app installed with .deb but no luck on http requests.

Do you mean that the http requests don't work in .deb installed apps either?

kfiven commented 2 years ago

Do you mean that the http requests don't work in .deb installed apps either?

yeah. atleast it didn't for me on Ubuntu.