Package Changes Through 1ec93aa

There are 7 changes which include @tauri-apps/cli with patch, tauri-cli with minor, @tauri-apps/api with minor, tauri-runtime-wry with patch, tauri-bundler with patch, tauri with minor, tauri-utils with minor

Add another change file through the GitHub UI by following this link.

Read about change files or the docs at github.com/jbolda/covector

@FabianLars You should not be using that AppRun, it causes more problems than it solves.

code

It just sets a bunch of env variables and then checks the .desktop file to get the name of the binary to launch.

The problem is that it sets the env variables even when they are not needed, and it also sets LD_LIBRARY_PATH which isn't needed either and causes a lot of problems to child processes.

Because of that upstream abandoned the idea of an universal AppRun, the only projects that still try to do it are go-appimage (which has a bunch of issues related to its AppRun settings variables it should not be setting) and the other is sharun which does have the logic to know when and where to set the variables instead of just hardcoding everything.

I don't care. I won't touch the old appimage bundler anymore. Every time we've tried so something broke.

I don't care. I won't touch the old appimage bundler anymore. Every time we've tried so something broke.

The old appimage bundler is broken already. Any appimage with this AppRun will cause child processes to try the bundled libs and fail as result, not to mention all the other opengl and whitescreen issues.

If I were you I would have dropped that all together, those appimages are broken.

You also already know what the solution is (and if you aren't convinced already, even CPU-X is now using sharun, which CPU-X is developed by the same person that made linuxdeploy-gtk).

Hi @FabianLars , I'm the one that opened this AppImage/AppImageKit#1395

The reason for the change is that the appimagetool in question is obsolete and produces AppImage packages that still depend on FUSE2.

Renaming these files with the obsolete- suffix served as a reminder to those of you who wrote the CI years ago and haven't updated it, and thus to let you know that something has changed and that you should update your programs.

libfuse2 is obsolete and insecure, and most distros are removing it or have already removed it from the base installation (see Fedora and Ubuntu).

The new appimagetool allows you to remove that dependency. You don't need to specify any runtime downloads (it's included) or options other than those you were already using.

Were you aware of this message? 👇

Please switch to the new version at
https://github.com/AppImage/appimagetool/releases/tag/continuous

...it is on all releases of the AppImage/AppImageKit

Maintaining the dependency on libfuse2 is therefore not only a security risk (it has been unmaintained since January 2019 https://github.com/libfuse/libfuse/releases/tag/fuse-2.9.9) but counterintuitive, as users of many distros are forced to install it.

@ivan-hc this isn't about appimagetool but AppRun.c that also got marked as obsolete (and for good reason).

I don't know what appimagetool tauri is using, hopefully it is not the same nightmare that happened at electron builder where the runtime is a very old version that was directly uploaded as a binary blob to the repo and even the maintainer doesn't know how that came there lol.

Thank you for a quick fix, @FabianLars!

Sorry for the newbie question, but I've upgraded my dependencies in my package.json as well as added tauri-cli and tauri-bundler to my Cargo.toml, but it still gives me the 404 error while downloading the AppImage binary.

Am I doing something wrong?

[build-dependencies]
tauri-build = { version = "2.3.1", features = [] }
tauri-cli = "2.7.0"
tauri-bundler = "2.5.1"

[dependencies]
tauri = { version = "2.6.2", features = [] }
tauri-plugin-opener = "2.4.0"
tauri-plugin-fs = { version = "2.4.0", features = ["watch"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
ring = "0.17"
base64 = "0.22"
dirs = "6.0"
rsa = "0.9.8"
rand = "0.9.1"
reqwest = { version = "0.12.22", features = ["json"] }
url = "2.5.4"
flate2 = "1.0"
tauri-plugin-process = "2"
tauri-plugin-sql = { version = "2", features = ["sqlite"] }
tauri-plugin-deep-link = "2.0.0"
tauri-plugin-single-instance = { version = "2.0.0", features = ["deep-link"] }

[target.'cfg(not(any(target_os = "android", target_os = "ios")))'.dependencies]
tauri-plugin-updater = "2"

@rickpastoor ci failed while i was sleeping. it's running now to publish @tauri-apps/cli (may take a while). you can remove tauri-cli and tauri-bundler from your cargo.toml file.

Oh! Brilliant. Thank you for getting back and your work on Tauri, it's an amazing project.

The old appimage bundler is broken already

Exactly. That's why i won't touch it so the small rest that's still somewhat working doesn't fall apart and why i was working on a new bundler (as you know).

If I were you I would have dropped that all together, those appimages are broken.

You're talking with the guy that begged the team for years to drop oob appimage support as a whole 🫠

You also already know what the solution is (and if you aren't convinced already, even CPU-X is now using sharun, which CPU-X is developed by the same person that made linuxdeploy-gtk).

If i wouldn't be convinced that sharun is the only reasonable choice in appimage land i wouldn't have started working on the PR (thanks again for your involvement in sharun and that pr).

Were you aware of this message? 👇

Yep, i was. It didn't change that my motivation to work on our appimage bundler was less than zero (still is). That's why i said that it's my bad in the pr description.

I don't know what appimagetool tauri is using, hopefully it is not the same nightmare that happened at electron builder where the runtime is a very old version that was directly uploaded as a binary blob to the repo and even the maintainer doesn't know how that came there lol.

Probably better if i don't answer that then 😂 (we're using a super old linuxdeploy version and whatever it uses internally because newer ones didn't work)

Hi, it is not clear to me but are the generated AppImages now free from dependency on libfuse2?

no, nothing changed.

@FabianLars did the release go through correctly? I see one of the tests failed on main

yes. the failed test is a cache issue that succeeded before (and is also completely irrelevant for the cli issues)

@FabianLars My bad, I thought you were done with sharun after what happened that wayland was still broken on nvidia due to ubuntu24 not providing gbm lol

Hi, it is not clear to me but are the generated AppImages now free from dependency on libfuse2?

Nope but you can still repackage it using the newer appimagetool or the uruntime. See example

My bad, I thought you were done with sharun after what happened that wayland was still broken on nvidia due to ubuntu24 not providing gbm lol

well yeah that kinda sucks but there's no better alternative 🤷

Nope but you can still repackage it using the newer appimagetool or the uruntime. See example

Oh nice thx @Samueru-sama, I will check that!