mirror of
https://github.com/Drop-OSS/drop-app.git
synced 2026-07-21 17:05:32 -04:00
[GH-ISSUE #33] [BUG] Crashes on Bazzite Gnome #13
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Desktop (please complete the following information):
@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):
@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)
@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.
@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
@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.
@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@dannymate commented on GitHub (May 25, 2025):
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?
@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?
@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:
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.
@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)
@dannymate commented on GitHub (May 25, 2025):
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"@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.
@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.
@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
@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.
@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.
[BUG] Crashes on Bazzite Gnometo [GH-ISSUE #33] [BUG] Crashes on Bazzite Gnome