-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider releasing an AppImage version of GearLever #83
Comments
Hi, I have updated the title to something more appropriate. An AppImage version of Gear Lever means that I would have to redesign the app to be able to "install itself" of the first run, and a bunch of other things. Also, I found NO examples on how to build a GTK appimage, which definitely does not make things easier |
I feel like, if this is the case, you're likely not in the target demographic that an app like this is trying to cater to. I get that you have philosophical complaints about the flatpak packaging system, but this seems to be a program made for those without those complaints. It's good to hear that you have found a preferred alternative, though! |
Hi @mijorus I've contacted you on Reddit some minutes ago about our previous conversation on creating an AppImage. I've seen that you have an AUR package, so I've worked with it using my project "Archimage", at https://github.com/ivan-hc/ArchImage This is the script I wrote for you Click here to expand
To create it using Archimage its enough to do so:
then save and run the script and be sure you have imagemagick installed on your host system. This is how the script works simplescreenrecorder-2024-06-06_02.30.44.mkv.mkv.mp4.mkv.mp4.mp4.mkv.mp4as you can see, there to work a bit on missing icons in the buttons. I've tested it using one of my Type3 AppImages and I was unable to launch it... also Gear Lever detects it as a Type2, and this is strange, the mine does not need libfuse2 to work... but I think that it was not launched because Archimage is a Arch Linux container into an AppImage, and I've not included "fuse3", so "fusermount3" was not in the package, and this is why it has not started... but the launcher was created in my applications menu, and a directory "Appimages" has been created in my $HOME directory... and my AppImage has been moved from my "AM" installation to that directory. Anyway, I've just shown a way to build AppImages with ease... the package is 90 MB. But anyone of you can do better, I'm sure. I leave you the tools, if you have questions, contact me. EDIT: I've just updated the script above enough to prevent many error messages related to missing libraries |
@MauricioLucas I understand your aversion towards Flatpaks, I fully share it, I wouldn't have created "AM" and AppMan otherwise. Thanks for choosing me. However, you need to understand that not everyone can create something from scratch using different languages. I myself only know the Shell language, which is why all my tools can only be used from the terminal. I don't have the skills to create a GUI. Likewise, @mijorus has his knack for building other things using other languages, and admittedly Flatpak provides developers with all the tools needed to build applications well... even if it's limited to what those damn runtimes offer, which they just take up space. We shouldn't blame him, on the contrary, if he wants to create AppImage packages, we need to offer him someone more experienced and help him do it. Even my solutions and tools are rudimentary, but they are already an important suggestion "to lead him on the right path". I hate Flatpak and I hate projects that are based exclusively on it, they monopolize what on Linux should be within the reach of anyone who wants to create and test packages. In this sense, his version of "gearlever" on AUR helped me to experiment and propose... as already happened with my "Bottles"... otherwise, I wouldn't even have proposed to help him. |
@ivan-hc just to clarify for everyone, the release on AUR is not mine, as you can see from the username of the publisher. |
Thanks to the .deb package @mijorus has provided at https://github.com/mijorus/gearlever/tree/test-debian-package I was able to create a .deb based version of the AppImage using https://github.com/ivan-hc/AppImaGen This is the script I've used: Click here to expand
In the script I had to extract the .deb package of gearlever manually, because it is not detected by pkg2appimage (I use it to compile the basic dependences at least). Also, the original video was 2 minutes, I had to cut some parts and speedup it to fit it under the 10MB quota allowed on github. And this is how it works: simplescreenrecorder-2024-06-07_18.01.05_edit.mkv_edit.mkv.mp4NOTE, here are some issues to solve using this method:
simplescreenrecorder-2024-06-07_18.44.21.mkv.mp4I receive this error mesage:
@probonopd @Samueru-sama I'd like you join this issue EDIT: @mijorus if you need a ready to use sample AppImage, download it from https://github.com/ivan-hc/My-workbench/releases/tag/test-gearlever , the CI process is the same for all my 60+ repositories, the ones where I build my Appimages. EDIT2: the error I get is related to a missing command |
I feel like a much needed context is missing here. If I am not mistaken, @MauricioLucas had an issue when using multiple users with I personally don't use flatpak, mostly because of these issues 1 2 3 and it really gets me that they tried to argue that it doesn't apply to them and even talked about updating the xdg spec to be exempt, but this is turning into as rant as well so sorry lol. @ivan-hc I really don't know how to turn python apps into appimages. I also haven't use pk2appimage either. I normally just use linuxdeploy + the needed plugin + Go appimagetool as this one is compatible with libfuse3. |
@Samueru-sama the key parts needed to build GearLever as an AppImage are these (for now)
while these are in the "control" file of the .deb package provided by @mijorus
EXTRA: to made it work and run, I had to add the local libraries to prevent errors with missing "libpango"
also, libunionpreload must be included
and during my process, I need to compile GearLever schemas
this is in detail what I've done in the script of my previous message. |
@Samueru-sama Nope, I've already talked with @mijorus into another issue and on Reddit, him is italian too, and I offered to help him. You know how much I fight to promote the use and creation of AppImages. EDIT: to @Samueru-sama , the fact that they have to depend on a platform like Flatpak to work, demotes AppImages to second-rate software packages, when in reality we know very well that this is not the case. I wrote a post on Reddit about it! All software packages on Linux are quickly searchable and installable via package managers, even Flatpak. The only one that didn't have a package manager was AppImage, and that's why people aim to use them via GearLever. It was created to simplify the use of AppImages, according to the purpose they were created for... and it is easy to update, precisely because it relies on a centralized repository. That's why people choose it, GearLever is a "better" AppImageLauncher, in this sense. It is useful if you want to use AppImages the way they are intended, that is, by dragging them and integrating them into the desktop, even if inserted into a USB stick, and the GearLever developer can always implement improvements by updating it via Flatpak. For users like us, however, AppImages were just missing a package manager to always update them, install them easily and list them all without people having to open the browser every time... to compete with other packaging formats. That's why I wrote "AM"/AppMan, I hope to fill this gap somehow. And I hope to add a "gearlever" package to my package manager in the future, to avoid people always having to install those damn Flatpaks. |
That "You" was at @MauricioLucas which once again is my theory as to why this issue was opened. (Given the other issue that we had at AM) |
Yes, I remember, it was very useful to deepen the discussion, where we tried to improve "AM". But please, let's not turn this issue into a chat, let's try to help the GearLever developer to create an AppImage package. Let's try to bring him back to our side. As I said in my second answer here, Flatpak offers many very attractive tools that encourage developers to create and improve "things", and that's why it grows so much. To build an AppImage, however, requires experience, and if I tagged you it's because I know how good you have become in such a short time, and I trust your skills, @Samueru-sama Let's not create an off-topic discussion. |
Hi @ivan-hc , Does it have specific modifications that are needed for this script to run? Also, why are you always referring to Debian repos, where we know they are out-of-date? Could't we use Ubuntu's? |
Yes, except that it doesn't automatically generate the AppImage file, which "appimagetool" has to do instead... it's also repackaged as "type3", so it would also work on Fedora and Ubuntu, where "libfuse2" is not installed by default .
Debian Testing (my distro) or Debian Unstable/Sid are as up to date as Arch Linux, sometimes less and sometimes more. These are the development branches for Debian Stable, where packages are tested maniacally to make the future release of Debian Stable something indestructible. https://wiki.debian.org/it/DebianTesting https://wiki.debian.org/it/DebianUnstable Ubuntu is based on Debian Unstable, while Ubuntu LTS is based on Debian Testing. However, I would prefer to use an Ubuntu LTS base, an older one in fact, to have GLIBC at an older version, compatible with newer distributions. Even @probonopd has been saying this ever since he invented AppImage. But to do this, I need at least one "reliable" PPA... I'm telling you this because I don't consider PPAs a security, nor a guarantee of continuity. This is why I invented Archimage. But classic AppImages are the only ones that are 100% compatible with the host system's hardware. |
If you need PPAs due to lack of dependency in ubuntu LTS, in that case the ideal solution would be building that dependency as well. Which yeah it complicates things a bit. |
So all we need is the more recent libadwaita and gtk4. We can also create it on debian Oldstable or Oldoldstable... but we need it t made GearLever work. I've used Debian Testing because the newer versions are not in Debian Stable. So consider my AppImage a "draft". EDIT: only "libadwaita" and "gtk4". Any other old package is OK for our work here. |
I want to correct my answer above, about "Ubuntu preference". I said that because Ubuntu has PPAs. Just for that. If we had the latest version of "libadwaita" and GTK4" for Debian oldoldstable, it would be even better! EDIT: before Debian developers stopped updating "chromium" for Debian oldstable, I was using the latter as a base for my AppImage, this is why I switched to Debian Stable. No other official .deb packages of chromium are so updated. |
Can anyone help me to create a recipe with AppimageBuilder? I tried but couldn't go very far |
I would gladly help you if you would show me where you are building using this method. I'm not familiar with AppimageBuilder. In the meantime, I call out the lead developer of that project, @azubieta |
I fail to understand why people develop applications using the latest and greatest and then are surprised when that latest and greatest is not what all users are running. Personally, as a rule of thumb, I would always develop on and for the oldest system I can expect my users to still run (e.g., the oldest still-supported long term stable distributions). The expectation being that what runs on older systems will continue to run on newer systems, but not the other way around. This is basic "backward compatibility". This being said, it is possible (although not recommended by everyone) to bundle all libraries privately (including glibc), which would make it possible to run binaries built on newer build systems on older target systems. (Similar to what Flatpak does, essentially.) |
As I do with Archimage. The only limit my project have are Nvidia drivers support, so no hardware accelleration at all, because it is an Arch Linux container into an AppImage, powered by ts internal version of Bubblewrap. I'm not that good to handle classic AppImage construction using linuxdeploy or appimage-builder, so I rely much on easier solutions, like your pkg2appimage I use in AppImaGen, but it does not includes glibc. @probonopd can you point us on your solution? It would be great to made AppImages as much standalone as possible, even by including their own glibc version. I think that it may cost few megabytes, but priority is to made them work everywhere. Really everywhere, not just the old still supported Ubuntu LTS. |
https://github.com/probonopd/go-appimage/tree/master/src/appimagetool#appimagetool |
@probonopd the appimage team should definitely improve the developer documentation. I'm finding it extremely hard to bundle this app, especially considering that I'm using gtk, which is one of the two most popular frameworks. It's not surprising that most appimages around are Electron or Tauri apps, where the developer just has to flip a switch in a configuration file to produce a bundle. Don't get me wrong, electron support alone has been crucial to increase the amount of Linux applications, but you should probably have more detailed guides like snap or flatpak have, especially for Qt and Gtk |
Making appimages of gtk apps is very easy, you just need to use the linuxdeploy-gtk plugin with linuxdeploy. Making appimages of python apps is not easy though 😅 |
Why? What's the problem |
Python apps are a mess: different versions of Python, several modules may be needed, and sometime they need modules to be compiled with PIP and that can't be easily exported into a portable package. For example, in this package I have 40 games into one AppImage and it was super easy to create, until I had to add "Kajongg" ivan-hc/KDE-games-suite-appimage#3 |
The way it works with linuxdeploy for non python apps is that it runs ldd on the binary and that tells it which libraries it needs to bundle and it has a list which libraries don't need to be included as well, it copies the libraries in the AppDir and then it automatically patches the binary to not depend on hardcoded paths and that is it. This is very simple and even projects like suyu use a deploy shell script instead of linuxdeployqt for this. If you need an extra library that didn't show up with ldd you can manually add it thru linuxdeploy or just directly setting With python apps there is the anaconda plugin and you have to set a bunch of parameters instead. I tried to use it when trying to build a puddletag appimage and it didn't work. Ivan also tested making an archimage of puddletag and it didn't work either. |
In contrast to other projects, AppImage is purely volunteer driven. So anyone is invited to improve any aspect of it.
Have you checked the Deployment tools for Python applications? Especially https://github.com/niess/python-appimage should make the job of producing an AppImage from a Python application much easier. Please avoid libadawita at all cost, as it tends to break outside of Gnome. |
I consider the absence of an AppImage version for Gear Lever and its reliance on Flatpak to be an egregious error. Please don't take offense, but as a Linux user, I strongly dislike the unnecessary clutter caused by Flatpak, Snap, and Java – they consume resources needlessly, and their background processes remain opaque to users. Flatpak and Snap seem like makeshift solutions tailored for former Windows users who migrated to Ubuntu to avoid Microsoft's system charges. The developers behind this decision are reminiscent of Canonical, which altered Debian into something unrecognizable without bothering to consult the documentation, merely patching it to mimic Windows. Although I appreciate the program, if it insists on using Flatpak, I regret to say that I'll stick to AppMan via the terminal.
The text was updated successfully, but these errors were encountered: