Call for testing: Official AppImage #21
Comments
|
I'm here, for any doubt |
|
Thanks. What you do to not get any iso-codes or app icon errors? I see that your AppImage output is pretty clean:
Do you use some build-time config or path in apprun? Our WIP AppImage, however, displays errors regarding iso-codes and app icon:
|
|
Mine is not a normal AppImage, it is what I call Archimage, i.e. an Archlinux container into an AppImage, so it come with all it needs to work from the inbuilt arch Linux container. My workflow depends on the status of the Arch Linux/AUR package, and what you shown is gimp-git, and the AUR package has issues latelly. If you see my latest workflows run, I'm unable to update the daily build because they have an issue about a missing module for Meson.
About errors, you should check this old AppRun I was using with previous deb-based AppImages: https://github.com/ivan-hc/GIMP-appimage/blob/main/AppRun I think you should use these on yours: and maybe I don't use them anymore in my Archimages. All of them have the same, being this a container. All the ones based on JuNest, Arch Linux (Archimage) on this list https://github.com/ivan-hc#my-appimage-packages |
|
Thanks |
|
About the meson error, this is because we added a new gimp-data submodule. This needs to be initialized before building. |
thanks, so should I add other dependences or should I wait that the PKGBUIL is fixed? |
|
however, the way you want build the Appimage is better than mine, mine is a container, so it can't do things such as open a URL in the browser (for now) |
Until the downstreamers take some action onto PKGBUILD, you can do: |
|
I think I'll wait until the upstream packager will patch this PKGBUILD, I often receive warnings about failed workflow run with both gimp-git and gimp-devel (the latter less, seems that the mantainer is more active than the other, also ChaoticAUR uses gimp-devel for its gimp-git package... and this is wrong, in my opinion). |
|
once you're at good point, I suggest to repack the AppImage using this version of appimagetool https://github.com/probonopd/go-appimage/releases/tag/continuous I use it for all my AppImages. Advantages:
Usage: where gimp.AppDir is the appdir (I guess) of your extracted AppImage |
|
Thanks 🤝. I'm already using it |
|
Hi, I've downloaded the latest release and got stuck at this:
|
|
By running it with LD_DEBUG=libs this is the last part of the long log |
|
Are you sure that isn't libgvfs that is causing the stuckness? We have another tester who noticed the lack of libxapp but this wasn't causing stuckness. |
|
I can only report what I see, I've googled a bit and found that also Inkscape had a similar issue, due to the old Ubuntu build whith which was built their AppImage. I use Debian Testing, and "libxapp-gtk3-module" and "libxapp1" are installed on the host. Also gvfs-libs/backend/common/daemon/fuse are installed. |
|
I'm trying to tweak your AppRun in several ways since I reported this issue, same message, no way. May you need to add libgvfsdbus or something? Are you missing an LD_PRELOAD variable to export? I'm trying also the dirtiest tricks without success. I also tried to add libunionpreload or tried to share hosts libraries or including PYTHONHOME as a variable... the only thing I can't do is to use the command |
|
UPDATE: I replaced your AppRun with mine and worked it is the same I linked above, but with gimp 2.99 in /usr/bin instead of gimp simplescreenrecorder-2024-04-04_22.17.33.mkv.mp4 |
|
The only issue I had at first start was this
|
|
NOTE: I've also launched it "isolated" (command |
|
OK, it was my fault... I had another gimp version installed and the AppImage was taken advantage of it using the if condition at the end of my AppRun nope, it really does not work |
|
Thanks for noticing the lack of gio (+gvfs). I updated the AppImage. The latest pipeline now contain gio. Also, includes the xapp module. Also, the first problems that I commented here (not finding iso-codes and appicon) were solved. |
|
About the config folder problem, I would suggest to take a look at the latest comment in the MR, this can be helpful to better understand if it is the same problem: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440#note_2073893 |
Thanks, I know that the issue is related to /etc into the AppImage (I had this too the early days, when I worked with deb packages to build GIMP). However, I started this new artifact and the issue is still the same: before I tried to include the gvfs-related .deb packages from Debian, but I was stuck until "libgvfsdbus.so" (and the xapp* module). Also, I noticed that the latest times I had to shut down the PC I had "A Start Job run..." issue that delayed my PC... and an amount od CPU usage... finally I discovered that it was gimp-scriptfu that also eats 70-80% of my CPU. |
|
@ivan-hc The latest commit probably fixed the gvfs warning. But some systems are complaining about "xdg-run/gvfs". See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440#note_2075698 |
|
Just tried the last build and still does not work for me, it stucks, this is the normal output: and this is the last part using LD_DEBUG=libs the output is too long to find the exact missing library. |
|
My Archimages have only 2 flaws: they have no hardware acceleration and they can't call other applications (for example, they can't open the browser). The last of these two flaws would also be easy to fix, you would need to find the directories on the host connected to XDG to open applications outside the container. I remember some time ago, with a normal installation of JuNest on Debian, I was able to open other apps installed on the host with Pamac, the graphical frontend of PacMan/YAY. Only the graphics acceleration would remain to be fixed, but unfortunately I'm alone, and the JuNest developer doesn't seem very convinced in wanting to implement these features, also if there are already similar projects that can do that, for example Conty, WINE AppImage and Distrobox. I tell you this because Archimages are very simple to compile and have much greater compatibility with the old GNU/Linux distributions, you just need to have at least the 2.6 kernel, which no one uses anymore. I notice a certain difficulty in trying to compile the Appimage you are trying to create, and in general AppImages are very difficult to create, between environment variables to guess and other mechanisms that instead, using a container, work out of the box. Since I invented Archimage I have packaged "the impossible", so to speak (GIMP Stable/Dev/GIT, VLC Stable/GIT, MPV, OBS Studio... even Bottles). It's not a perfect project, but one that needs perfecting, which, I repeat, is difficult when you're alone. |
|
@ivan-hc Your latest stacktrace is very informative. I probably willn't know what to do with it, but depending on how the thing goes some GIMP core dev can take a look to finalize the AppImage. We're not alone :-), at least in GIMP repo. About the way I choose to make the AppImage: an official package in the GIMP repo needs to follow certain rules (they are listed in the MR description and I personally like them). Anyway, I have a compromisse in only shipping the AppImage if:
But if it can't be deployed with our Debian runner, I'm fine in giving up. |
|
Don't give up, there are several ways to package AppImages, trust me. Just because the creator of AppImage dictated a method, doesn't mean it's the only way forward. I didn't follow a conventional path, and you see how many AppImages I created. PS: in this moment I've tried to launch the browser from my AppImge of GIMP and worked. The internal container needed three libraries from JuNest/Arch Linux ( |
@brunolopesdsilv Sorry, there was some confusion here (I often use Google Translate). By "being alone" I was referring to me. My packaging method has only me as an assiduous researcher, and only recently someone else participated in the experiments, but nothing significant. Yet there are many users who use Archimage (for personal use, I guess) https://github.com/ivan-hc/ArchImage I'm not criticizing your method, it would mean criticizing everyone's, when in fact almost all AppImages, including the ones I use, are made like this, the way you're trying to do it: the classic Appimage's construction. I'm just saying that my project is one more OPTION, which I think is worth exploring. Just another option, nothing else. If I published it on Github it was to share it with everyone and have it analyzed by those who are more expert than me, and especially from you! I also wrote this tool for you, hoping to see these days, that are now! When you finally have contacted me! You say you use Debian as a basis for working on the compatibility of the older and still supported Ubuntu LTS and modern Fedora (for compatibility with GLIBC), I'm using a portable Arch Linux container (with its own GLIBC) and it should work too with distributions dating back more than 10 years. But the biggest difference is that the AppImage I produced is something I DO NOT INTEND TO KEEP. It is upstream's job to create an official one, until then I can only try to imitate you, but I will never reach your efficiency. I don't care if everything works in my unofficial AppImage or not, but if I made it (and people appreciated it, it's my most successful AppImage) it's because THIS IS A GIFT THAT I WANT TO GIVE TO YOU, GIMP TEAM, FOR ALL THE AMAZING WORK YOU HAVE DONE SO FAR! I want you to take care of my creature. I entrust it to you. And if it works more than it should now, I'm happy about that, it will mean there's a lot less work to do. I wanted to push you to create one, and the fact that you and I are talking, here, in my repository, is a huge win! For me and for all users who want an official GIMP AppImage. I won't stay in software development forever, I don't have the basics, nor a qualification, nor the skills, nor sufficient knowledge to do these things. I have always only worked in supermarkets, at the food counter. What you see here is just a pastime for me, as I am unemployed. I am honored to have been contacted by you, it was exactly what I wanted: an official AppImage! Made by you! And as an amateur packager I realized how difficult it is to maintain them, and I am a private citizen, I am not part of your Team or any other project. I'm not a developer, I'm just someone who wanted to propose an idea to you. And reading "But if it can't be deployed with our Debian runner, I'm fine in giving up"... this really hurts me. It means that I fought in vain to convince you to adopt the AppImage format. I'm not at all good at compiling from source, if you see my AppImages they are all very simple to create. I'm rooting for you and I hope you succeed in your endeavor... but please, if you don't succeed, consider other ways. "All roads lead to Rome", right? Don't abandon a goal just because a tree blocks your path, try to go around. PS: Sorry if I'm so talkative, I really care about the work you are doing, but out of my tools, I don't really know how to help you. |
|
@ivan-hc I didn't mean to express ingratitude with my last sentence, sorry. In short, what I'm saying is that if the packaging format, after all attempts, doesn't allow us to package in our preferred "development-oriented distro", that's a bad sign and I'm not willing to go much further. We could choose another distro or use your scripts, but this doesn't have parity of integration, simplicity and stability. We've seen this story before in our repos (e.g. JHBuild, Jenkins, macOS in part) and it would probably repeat itself again if afferrero's AppImage or yours were somehow merged. I will not develop this last sentence technically to avoid sounding like criticism. As I am also unemployed and my programming knowledge is very basic (I am a lawyer), I would particularly prefer the format to "dictate" how to make the AppImage rather than this current brainstorming (linuxdeployqt, appimagetool, go-appimagetool, recipes, etc.). I'm making an MS Store version (which will probably be merged this week) and the experience is being well balanced: the tools are dictated by MS (makepri, makeappx and signtool) but they work after all and leave me free to make relatively simple scripts without using Visual Studio . I must emphasize that, despite the shortcomings the format has, I understand that this is due to historical reasons (it was the first sandbox-like format) and I do not intend to "fight against" the status quo just to say that GIMP have an AppImage. This is due not only to my principles and the quick history of GIMP building that I explained above but also to the fact that some projects did this, were left without a maintainer and the AppImage was (shamefully) discontinued. I hope I don't have to give up, I still have some things to test. In the worst case, the AppImage will only be for internal use in daily builds, so you can propose your scripts for an official AppImage. |
Forget linuxdeploy, it is what I was using when I made that comment because I had issue with go-appimage. AppImage made with linuxdeploy depend on the host libraries and aren't that portable as result, it even still uses the old appimage runtime which is not static and has a dependency to libfuse2, I'm sorry I didn't make that clear when I commented again.
The issue is that the gimp plugins are binaries that gimp itself launches. What happens is that gimp itself was called by the dynamic linker in the appimage, so gimp is going to use that to find its libraries. but the subsequent binaries launched by gimp won't, this causes them to try to use the dynamic linker of the host. One hacky way to sort of force those plugins to at least use the libraries of the appimage is to set So the right solution is to use the dynamic linker again when gimp calls the plugins, which sharun can do and I did here. |
@Samueru-sama I tested the latest artifact (https://gitlab.gnome.org/GNOME/gimp/-/jobs/4502344) and the appimage runned just fine in Ubuntu 24.04 (VM). Side note: for my surprise, even the C plug-ins worked with the host C library preloading, but that is probably just a miraculous coincidence. It should not work. |
No, what I meant was that I wanted to respond on gitlab because someone shared an appimage on gitlab made from the ubuntu debs. that appimage while it works pretty much anywhere, it uses a namespace to work, which is a problem since that is disabled on 24.04 by default, hence I said "I don't know why I can't log into gitlab so I will respond here." before. Your appimage with go-appimage does not depend on userns, neither would one using sharun.
It still doesn't work here, since the plugins are trying to use the dynamic linker of my pc. This can sort of be fixed without sharun by patching a relative interpreter in the plugins, I just did it here so you can check: All you have to do is cd into the AppDir and run: And then add this to the
And finally stop preloading libc and call the interpreter instead, that is the last line is like this: And now the appimage works on my system, and even on alpine linux which has no glibc:
|
|
However patching a relative interpreter has its downsides, for one GIMP displays the current working directory as a location in the open image window:
So now I have that squashfs-root dir there, so the ideal solution is using sharun, which now probono is also considering here. |
|
@Samueru-sama Thanks. I tested and your solution solved problems with C plug-ins: https://gitlab.gnome.org/GNOME/gimp/-/jobs/4506100/artifacts/file/build/linux/appimage/_Output/GIMP-3.0.0-RC1+git-x86_64.AppImage .py, .scm and .vala plug-ins, however, are not working because something is calling host |
That's because you are exporting Just delete
You don't have to define
|
|
@Samueru-sama Your screenshot displays the same error as mine (with the exception of env) and I guess that you can't run Python plug-ins. I removed LD_LIBRARY_PATH and --library-path and, as I suspected, didn't work. I highly doubt that this is due to libraries. What I see is GIMP calling host env to find the interpreter. |
It's not the same error then 😄 I don't know what the stack smashing error means though.
You can call the host With this said, I know sharun sets |
|
Try doing this: It reduced the amount of errors I get now:
Also I don't think you need to be setting |
|
@Samueru-sama Seting the interpreter in bin/ executables definitively fixes the issue. At least python and C plug-ins work so we will probably have an official appimage in RC2 and onwards, which can be even more improved with sharun.
Yeah, I just ship it otherwise we get annoyed by warnings when opening GTK inspector (which we can't do right now because RC1 acts like a stable version so the "Debug > Inspect GTK" menu doesn't exist) |
The only thing sharun will improve is avoid the need of changing the current working directory (the Btw you don't need to be passing Also do not use Instead use this appimagetool, it has compatible arguements and the only difference is that you need to install |
|
Maybe I spoke too soon about releasing things. Seting the interpreter in all binaries with the code below fixes all errors about usr/bin/env and glibc and every plug-in works: bin_array=($(find "$USR_DIR/bin" "$USR_DIR/$LIB_DIR" -type f -exec head -c 4 {} \; -exec echo " {}" \; | grep ^.ELF))
for bin in "${bin_array[@]}"; do
if [[ ! "$bin" =~ 'ELF' ]] && [[ ! "$bin" =~ 'ld-linux' ]]; then
patchelf --set-interpreter "./usr/lib64/ld-linux-x86-64.so.2" "$bin" >/dev/null 2>&1 || continue
fi
doneBut GIMP takes 10-15 minutes to start, and after the program started every plug-in takes 10s to open when you call them in menus. There is: https://gitlab.gnome.org/GNOME/gimp/-/jobs/4513015/artifacts/file/build/linux/appimage/_Output/GIMP-3.0.0-RC1+git-x86_64.AppImage Maybe this is due to the polluted RUNPATH that go-appimage creates. To be investigated. We can't release with GIMP official appimage in these conditions. |
Make sure that for loop isn't trying to patch libraries, also I think it is better to just check where it went wrong, looks like the binaries that were missing were the binaries in the Also part of the reason the appimage is slow starting up is because you are using the old appimagetool from appimagekit, check these out and let me know if they are faster, they are on my PC but the original appimage with the old runtime doesn't take 15 minutes to start and more like 1 minute though while switching to the static runtime and zstd compression cuts that down to 20 seconds and 8 seconds if I use a surprise that I have here: Using static AppImage runtime with zstd compression Let me know how fast this one is The later uses a different runtime that supports dwarfs, which is massively faster than squashfs.
Patchelf also sometimes breaks binaries/elfs, the usage of patchelf can be avoided all together by using sharun, |
|
@Samueru-sama You are right. After I made the comment I changed to edge appimagetool and was testing how plug-ins work in many distros. The performance is acceptable and we have no crashes anymore. There are the results: Manjaro: 100% WORKING ✅ Fedora: 100% WORKING ✅ Mageia: 100% WORKING ✅ Ubuntu (24.04): WORKING ✅ (but apparently using system Python) These GTK modules warnings still annoys me because I am bundling them right as far I know bu they are inoffensive. Gentoo, NixOS and Ubuntu 14.04-18.04 not working due to the well know fusemount error ❌. |
|
@Samueru-sama By the way what is your GNOME Gitlab username? I would like to ping you in the upcoming MR |
This is likely because
And Gentoo because on gentoo The alternative runtime from here should not have those issues btw, and it is even faster than the one you just switched to.
samueru |
|
@brunvonlope Also btw I think you are in contact with the inkscape dev, you should tell them to also update the appimagetool, inkscape uses go-appimage and deploys all the libs but switches to the old appimagetool due to appstream issues, and that has that performance impact and also prevents the appimage from working on more distros. |
@Samueru-sama What is "command"? Also, this var is set outside the appimage or in the AppRun file?
Unfortunately not 🙁. My time is too spare that I devote my open source efforts entirely to upstream gimp |
It has to be set outside the appimage though, you can just run edit: If you asked what For the change to be permanent, the user would need to define it in their
Oh no problem then. |
|
Update, the issue that needed However looking at the code it seems that they are still reading the fusermount binary before launching, which means it may still not work on gentoo, but it should work out of the box on Nix and the old distros. |
|
I still need to test on Ubuntu 16.04. At least on Alpine with just gnome installed, that fix made no difference. |
wait you are saying that on alpine you still needed to set |
|
I never set that var because I am testing the appimage like a "end user" would use it, All that being said, maybe I misunderstood the purpose of the fix. They mass closed a lot of issues but in one of them was discussed searching for fudemount in more paths. This wasn't done in the MR? |
You should not have to set it anymore, since the issue should have been fixed by that recent PR. I assume you remade the appimage in the last 5 hours right (since that's when the updated runtime was released). The original issue was that the runtime was hardcoded to look for Before that fix, if
Now it does search for fusermount in |
Unfortunately not. I have done a build 2 hpurs ago. Anyway, does not hurt retriggering a new pipeline. Let's see how it ends. |
SPOILER: ends well ;) |
|
If it turns out it doesn't work and Also if it doesn't work, can you check with this other runtime? |
|
Alpine, nixOS and Ubuntu 16.04 all succeeded on finding libfuse after the fix ✅. Yay. nixOS, however, did not ended opening GIMP due to GVFS error, somewhat reported by @ivan-hc in #21 (comment):
|
For some reason the gio modules of Nix are called by the appimage and are also trying to use the libraries of the AppImage and you get that glibc error. You are already exporting Also if you are shipping the the video drivers you may need to bundle EDIT: FIxed typo, |
Hi, @ivan-hc. We are trying to build an official AppImage upstream: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440 😃
Help is appreciated regarding some little bugs.
The text was updated successfully, but these errors were encountered: