[GH-ISSUE #33] [BUG] Crashes on Bazzite Gnome #13

Closed
opened 2026-02-17 17:11:50 -05:00 by yindo · 16 comments
Owner

Originally created by @dannymate on GitHub (May 24, 2025).
Original GitHub issue: https://github.com/Drop-OSS/drop-app/issues/33

Originally assigned to: @DecDuck on GitHub.

Describe the bug
Opening the Appimage causes a black box to appear and then close.
Running the RPM in the distrobox just doesn't launch at all.

To Reproduce
Launch the AppImage on Bazzite
Crash

Expected behavior
Not Crash

Screenshots

thread 'main' panicked at /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libappindicator-sys-0.9.0/src/lib.rs:41:5:
Failed to load ayatana-appindicator3 or appindicator3 dynamic library
/lib64/libayatana-ido3-0.4.so.0: undefined symbol: g_once_init_leave_pointer
/lib64/libdbusmenu-glib.so.4: undefined symbol: g_once_init_leave_pointer
libayatana-appindicator3.so: cannot open shared object file: No such file or directory
libappindicator3.so: cannot open shared object file: No such file or directory
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Desktop (please complete the following information):

  • OS: Bazzite Gnome Nvidia
  • App Version 0.2.0
Originally created by @dannymate on GitHub (May 24, 2025). Original GitHub issue: https://github.com/Drop-OSS/drop-app/issues/33 Originally assigned to: @DecDuck on GitHub. **Describe the bug** Opening the Appimage causes a black box to appear and then close. Running the RPM in the distrobox just doesn't launch at all. **To Reproduce** Launch the AppImage on Bazzite Crash **Expected behavior** Not Crash **Screenshots** ``` thread 'main' panicked at /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libappindicator-sys-0.9.0/src/lib.rs:41:5: Failed to load ayatana-appindicator3 or appindicator3 dynamic library /lib64/libayatana-ido3-0.4.so.0: undefined symbol: g_once_init_leave_pointer /lib64/libdbusmenu-glib.so.4: undefined symbol: g_once_init_leave_pointer libayatana-appindicator3.so: cannot open shared object file: No such file or directory libappindicator3.so: cannot open shared object file: No such file or directory note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` **Desktop (please complete the following information):** - OS: Bazzite Gnome Nvidia - App Version 0.2.0
yindo closed this issue 2026-02-17 17:11:50 -05:00
Author
Owner

@quexeky commented on GitHub (May 24, 2025):

I've been able to reproduce this on my machine, so I'm guessing that it's an issue with Gnome. Most likely cause would be because this was likely built using an older set of libraries (Jan 25), and I believe that there have been a few updates to gnome's appindicator since then. I'll take a look.

@quexeky commented on GitHub (May 24, 2025): I've been able to reproduce this on my machine, so I'm guessing that it's an issue with Gnome. Most likely cause would be because this was likely built using an older set of libraries (Jan 25), and I believe that there have been a few updates to gnome's appindicator since then. I'll take a look.
Author
Owner

@quexeky commented on GitHub (May 24, 2025):

@DecDuck I'm planning on making a new release for this - should it be v0.2.1-beta, or something else? Just looking at the semantics of it (have tested the actual appimage, so that's all good)

@quexeky commented on GitHub (May 24, 2025): @DecDuck I'm planning on making a new release for this - should it be v0.2.1-beta, or something else? Just looking at the semantics of it (have tested the actual appimage, so that's all good)
Author
Owner

@DecDuck commented on GitHub (May 24, 2025):

v0.2.1-beta should be fine. If you want to backport the CI Release script to that version you can get GitHub to build all the different versions for you. You just update the version in the tauri configs, and then run the CI workflow, and it creates a release + uploads artifacts for you.

@DecDuck commented on GitHub (May 24, 2025): v0.2.1-beta should be fine. If you want to backport the CI Release script to that version you can get GitHub to build all the different versions for you. You just update the version in the tauri configs, and then run the CI workflow, and it creates a release + uploads artifacts for you.
Author
Owner

@quexeky commented on GitHub (May 24, 2025):

I've gotten v0.2.1, but it seems that the GitHub appimage specifically isn't working - works when compiled locally, but not with GitHub actions

@quexeky commented on GitHub (May 24, 2025): I've gotten v0.2.1, but it seems that the GitHub appimage specifically isn't working - works when compiled locally, but not with GitHub actions
Author
Owner

@DecDuck commented on GitHub (May 24, 2025):

It builds on Ubuntu 22.04, which won't have the latest version.

Unfortunately Linux compatibility is an absolute nightmare 90% of time, which is what Flatpak was created to solve. Currently the best solutions is either for @quexeky to upload the verison they built, and hope the system library line up (Arch Linux vs Bazzite), or you compile it yourself.

@DecDuck commented on GitHub (May 24, 2025): It builds on Ubuntu 22.04, which won't have the latest version. Unfortunately Linux compatibility is an absolute nightmare 90% of time, which is what Flatpak was created to solve. Currently the best solutions is either for @quexeky to upload the verison they built, and hope the system library line up (Arch Linux vs Bazzite), or you compile it yourself.
Author
Owner

@quexeky commented on GitHub (May 24, 2025):

Check: https://github.com/Drop-OSS/drop-app/releases/tag/dev-v0.2.1-beta for the AppImage.

Should work in theory - ran on the v0.2.0-beta release with the command: NO_STRIP=true yarn tauri build, because of an issue with libavif dependencies

@quexeky commented on GitHub (May 24, 2025): Check: https://github.com/Drop-OSS/drop-app/releases/tag/dev-v0.2.1-beta for the AppImage. Should work in theory - ran on the v0.2.0-beta release with the command: `NO_STRIP=true yarn tauri build`, because of an issue with libavif dependencies
Author
Owner

@dannymate commented on GitHub (May 25, 2025):

Check: https://github.com/Drop-OSS/drop-app/releases/tag/dev-v0.2.1-beta for the AppImage.

Should work in theory - ran on the v0.2.0-beta release with the command: NO_STRIP=true yarn tauri build, because of an issue with libavif dependencies

This release does load. Having issues logging in to my server. It doesn't open my browser and the token (Inspect > Storage > drop-token) doesn't work.

I can make another issue if need but my instance has a bunch of 404 errors on most routes, is this expected?

[Vue Router warn]: No match found for location with path "/library"
[Vue Router warn]: No match found for location with path "/community"
[Vue Router warn]: No match found for location with path "/news"
@dannymate commented on GitHub (May 25, 2025): > Check: https://github.com/Drop-OSS/drop-app/releases/tag/dev-v0.2.1-beta for the AppImage. > > Should work in theory - ran on the v0.2.0-beta release with the command: `NO_STRIP=true yarn tauri build`, because of an issue with libavif dependencies This release does load. Having issues logging in to my server. It doesn't open my browser and the token (Inspect > Storage > drop-token) doesn't work. I can make another issue if need but my instance has a bunch of 404 errors on most routes, is this expected? ``` [Vue Router warn]: No match found for location with path "/library" [Vue Router warn]: No match found for location with path "/community" [Vue Router warn]: No match found for location with path "/news" ```
Author
Owner

@DecDuck commented on GitHub (May 25, 2025):

The token for manual sign in isn't the one in your browser storage. After authorising, there should be a drop down on the same page called "Having trouble?".

Edit: that is expected, except for the library path. Can you access your library on the web UI? Can you also check the image tag you're using for the server?

@DecDuck commented on GitHub (May 25, 2025): The token for manual sign in isn't the one in your browser storage. After authorising, there should be a drop down on the same page called "Having trouble?". Edit: that is expected, except for the library path. Can you access your library on the web UI? Can you also check the image tag you're using for the server?
Author
Owner

@dannymate commented on GitHub (May 25, 2025):

I click Sign in with browser, then nothing happens and I get the circle spinning, then the Having Trouble? bit shows up. There's no code, my browser wasn't opened either. All I get in terminal is this:

(drop-app:227876): libayatana-appindicator-WARNING **: 22:00:13.496: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code.

Though that's not relevant to the sign in issue.

Tag: v0.2.0-beta
I can't access library, I'm getting 404. This is library on the homepage not the one in the Admin Dashboard to be clear.

@dannymate commented on GitHub (May 25, 2025): I click Sign in with browser, then nothing happens and I get the circle spinning, then the Having Trouble? bit shows up. There's no code, my browser wasn't opened either. All I get in terminal is this: ``` (drop-app:227876): libayatana-appindicator-WARNING **: 22:00:13.496: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code. ```` Though that's not relevant to the sign in issue. Tag: v0.2.0-beta I can't access library, I'm getting 404. This is library on the homepage not the one in the Admin Dashboard to be clear.
Author
Owner

@DecDuck commented on GitHub (May 25, 2025):

If is there no "opening url..." line, can you run it again with "RUST_LOG=debug"?

And nevermind about library, I got confused because it's one of the first things we implemented for v0.3.0 (unreleased atm)

@DecDuck commented on GitHub (May 25, 2025): If is there no "opening url..." line, can you run it again with "RUST_LOG=debug"? And nevermind about library, I got confused because it's one of the first things we implemented for v0.3.0 (unreleased atm)
Author
Owner

@dannymate commented on GitHub (May 25, 2025):

2025-05-25T22:47:38.633978327+01:00 | DEBUG | src/lib.rs:131 - checking if database is set up
2025-05-25T22:47:38.634014157+01:00 | DEBUG | src/database/db.rs:154 - creating data directory at "/var/home/dannymate/.local/share/drop"
2025-05-25T22:47:38.634108584+01:00 | DEBUG | src/lib.rs:143 - database is set up
2025-05-25T22:47:38.634126813+01:00 | INFO | src/lib.rs:176 - detected games missing: []
2025-05-25T22:47:38.634143017+01:00 | DEBUG | src/lib.rs:189 - finished setup!
2025-05-25T22:47:38.634169627+01:00 | DEBUG | src/lib.rs:269 - initialized drop client
2025-05-25T22:47:38.662388486+01:00 | DEBUG | src/lib.rs:276 - registered all pre-defined deep links

(drop-app:300664): libayatana-appindicator-WARNING **: 22:47:38.937: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code.
2025-05-25T22:47:46.447534113+01:00 | DEBUG | /home/quexeky/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/reqwest-0.12.9/src/connect.rs:500 - starting new connection: https://<my_url>/
2025-05-25T22:47:46.463017078+01:00 | DEBUG | src/remote/auth.rs:180 - opening web browser to continue authentication
2025-05-25T22:47:46.506563360+01:00 | DEBUG | /home/quexeky/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/webbrowser-1.0.3/src/common.rs:61 - background spawn: "/usr/bin/flatpak" "run" "--branch=stable" "--arch=x86_64" "--command=launch-script.sh" "--file-forwarding" "app.zen_browser.zen" "@@u" "https://<my_url>/client/4189e435-c608-49d3-a932-376f9048979a/callback" "@@"

I did manage to get it to do the process manually by just using the URL in the logs and then pasting the code from that page into the appimage window. So that's a positive.

Edit: For anyone in the future you need to run:
env RUST_LOG=debug "path-to.appimage"

@dannymate commented on GitHub (May 25, 2025): ``` 2025-05-25T22:47:38.633978327+01:00 | DEBUG | src/lib.rs:131 - checking if database is set up 2025-05-25T22:47:38.634014157+01:00 | DEBUG | src/database/db.rs:154 - creating data directory at "/var/home/dannymate/.local/share/drop" 2025-05-25T22:47:38.634108584+01:00 | DEBUG | src/lib.rs:143 - database is set up 2025-05-25T22:47:38.634126813+01:00 | INFO | src/lib.rs:176 - detected games missing: [] 2025-05-25T22:47:38.634143017+01:00 | DEBUG | src/lib.rs:189 - finished setup! 2025-05-25T22:47:38.634169627+01:00 | DEBUG | src/lib.rs:269 - initialized drop client 2025-05-25T22:47:38.662388486+01:00 | DEBUG | src/lib.rs:276 - registered all pre-defined deep links (drop-app:300664): libayatana-appindicator-WARNING **: 22:47:38.937: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code. 2025-05-25T22:47:46.447534113+01:00 | DEBUG | /home/quexeky/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/reqwest-0.12.9/src/connect.rs:500 - starting new connection: https://<my_url>/ 2025-05-25T22:47:46.463017078+01:00 | DEBUG | src/remote/auth.rs:180 - opening web browser to continue authentication 2025-05-25T22:47:46.506563360+01:00 | DEBUG | /home/quexeky/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/webbrowser-1.0.3/src/common.rs:61 - background spawn: "/usr/bin/flatpak" "run" "--branch=stable" "--arch=x86_64" "--command=launch-script.sh" "--file-forwarding" "app.zen_browser.zen" "@@u" "https://<my_url>/client/4189e435-c608-49d3-a932-376f9048979a/callback" "@@" ``` I did manage to get it to do the process manually by just using the URL in the logs and then pasting the code from that page into the appimage window. So that's a positive. Edit: For anyone in the future you need to run: `env RUST_LOG=debug "path-to.appimage"`
Author
Owner

@DecDuck commented on GitHub (May 25, 2025):

Yeah it appears the browser handoff isn't working on Flatpak, it might need some custom flags or smth. I'll check it out later today.

@DecDuck commented on GitHub (May 25, 2025): Yeah it appears the browser handoff isn't working on Flatpak, it might need some custom flags or smth. I'll check it out later today.
Author
Owner

@dannymate commented on GitHub (May 25, 2025):

If it's more work than you expect, I definitely think the easy thing to do would be just put that URL in the GUI and call it a day for now.

Quick question: Do you intend to handle extracting zip/7z as well at any point? Or is that out of scope?
Also one bit of feedback is the setup on the WebGUI when adding a game version. There's the option for a setup.exe but some games don't have those. I assume if it's empty it doesn't run anything but it would be nice to just have a toggle to turn it off from a usability perspective.

I like what you're going for by the way. It's looking promising to my eye anyway.

@dannymate commented on GitHub (May 25, 2025): If it's more work than you expect, I definitely think the easy thing to do would be just put that URL in the GUI and call it a day for now. Quick question: Do you intend to handle extracting zip/7z as well at any point? Or is that out of scope? Also one bit of feedback is the setup on the WebGUI when adding a game version. There's the option for a setup.exe but some games don't have those. I assume if it's empty it doesn't run anything but it would be nice to just have a toggle to turn it off from a usability perspective. I like what you're going for by the way. It's looking promising to my eye anyway.
Author
Owner

@DecDuck commented on GitHub (May 25, 2025):

We'll probably implement some sort of code that you can put into the browser to authorise, like OAuth2 device mode.

As for the zip/archive question, we opted to intentionally not support it, because we're planning to add P2P downloads and storing both the archive and uncompressed version on each client's computer was uneconomical. If you're worried about bandwidth, we are planning to do some in-transit compression, likely with zstd

@DecDuck commented on GitHub (May 25, 2025): We'll probably implement some sort of code that you can put into the browser to authorise, like OAuth2 device mode. As for the zip/archive question, we opted to intentionally not support it, because we're planning to add P2P downloads and storing both the archive and uncompressed version on each client's computer was uneconomical. If you're worried about bandwidth, we are planning to do some in-transit compression, likely with zstd
Author
Owner

@dannymate commented on GitHub (May 25, 2025):

Ah, I understand that makes sense. Bandwidth isn't really a concern for me luckily. I personally don't gain much from the P2P stuff but I think it's a solid idea considering.

Normally I have my games zipped on the home server. Saving space isn't really a concern much but the problem it solves is when downloading games from the server the download tends to crawl when there's loads of tiny files. Sometimes to the point zipping the game on the server, downloading, then unzipping on the computer is quicker.

I can't think of any alternatives that make sense. Get Drop to extract the zip server side instead of client side? I can just automate that myself anyway (I already do for some stuff) without wasting Drop dev time on it.

If Drop gets to a point where it's viable for my use case then I don't mind putting in the effort to align my file structure to it.

@dannymate commented on GitHub (May 25, 2025): Ah, I understand that makes sense. Bandwidth isn't really a concern for me luckily. I personally don't gain much from the P2P stuff but I think it's a solid idea considering. Normally I have my games zipped on the home server. Saving space isn't really a concern much but the problem it solves is when downloading games from the server the download tends to crawl when there's loads of tiny files. Sometimes to the point zipping the game on the server, downloading, then unzipping on the computer is quicker. I can't think of any alternatives that make sense. Get Drop to extract the zip server side instead of client side? I can just automate that myself anyway (I already do for some stuff) without wasting Drop dev time on it. If Drop gets to a point where it's viable for my use case then I don't mind putting in the effort to align my file structure to it.
Author
Owner

@DecDuck commented on GitHub (May 25, 2025):

We're currently transferring each file individually, which does cause a considerable amount of overhead, but we're planning to support allowing clients to request multiple files in a single request.

We're also planning to allow the server to keep all the files zipped/archived, and transverse/decompress them on the fly, but it's a little complicated and we want to get it right.

@DecDuck commented on GitHub (May 25, 2025): We're currently transferring each file individually, which does cause a considerable amount of overhead, but we're planning to support allowing clients to request multiple files in a single request. We're also planning to allow the server to keep all the files zipped/archived, and transverse/decompress them on the fly, but it's a little complicated and we want to get it right.
yindo changed title from [BUG] Crashes on Bazzite Gnome to [GH-ISSUE #33] [BUG] Crashes on Bazzite Gnome 2026-06-05 14:24:20 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Drop-OSS/drop-app#13