AppImage Updates?

[KenLidd]

Will we be receiving any updates for the 2.10.25 development version. The weekly updates stopped on Jun 10th - over 3 weeks ago? Hope you are well and just taking a breather!

[chromer030]

Last build stuck on 2021/06/10 ! Why ? , no any update anymore ? (GIMP_AppImage-git-2.10.25-20210610-withplugins-x86_64.AppImage)

[mttbernardini]

I suspect the problem is that Travis CI has been discontinued (on the travis-ci.org domain) since June 15th, hence the last build is the one that you both mentioned.

I don't know if there's much we can fix by making a PR, @aferrero2707 I think you need to manually migrate to travis-ci.com. The existing config should work without any modification, let us know if you are still into this and thank you for your time!

[DrMcCoy]

Just to give my 2¢, as someone who did the migration to travis-ci.com in January, the migration is a pain. Well, not the migraton itself, but what it means: you now need to regularily, manually request credits to continue to use use the CI pipeline. Every minute the pipeline runs eats a certain number of credits.

They also take a long time (in the realm of several months!) to act on the request for more credits.

For my projects, which take a while to build and I had configured to run a few configurations, this made it all completely unworkable. The credits they gave me were gone in 10 builds, and then I sat dry for months at a time. Especially galling when I burned through the rebuilds because I was debugging Travis CI breakages.

I consider Travis CI to be dead for most FLOSS projects now. The exception might be high profile ones that have enough pull to negotiate either unlimited (if they do that) or a regular automatic refresh.

I heard some people migrated to GitHub Actions instead. I don't really know how those work in details, but they might be an option for this project, maybe?

[mttbernardini]

@DrMcCoy that's sad... I also considered gh actions, but thought that maybe from a time-allocation perspective migrating Travis could have been the quickest (just migrate, nothing else to reconfigure) for the owner of the repo. But if it turns out to be a pain, I might as well try to migrate the config to gh actions and send a PR.

[ivan-hc]

Hi, I'm working on a GIMP version built from PPA using GH actions (I'm not much good in build apps from source), so I hope this will be a good start for an official release.

My repository: https://github.com/ivan-hc/GIMP-appimage

[secretmango]

@ivan-hc This is great!

The astonishing thing is that this Appimage is so damn fast. Lava render takes 5s on my laptop, using the Flatpak it takes 10(!!) seconds. This is totally crazy, same hardware, I dont get it. Saw it in TechHuts video a while ago, pretty crazy.

Well compiled software seems to rock. The JuNest Appimage is exactly as slow as the Flatpak. Maybe its a new GIMP release making it that slow?

But the JuNest Appimage is also way bigger, may be bloated.

[ivan-hc]

Ma l'immagine dell'app JuNest è anche molto più grande, potrebbe essere gonfia.

the AppImages with flag "junest" are something I call "ArchImages", i.e. Arch Linux into an Appimage https://github.com/ivan-hc/ArchImage

I have also built GIMP from PPA, but I do not trust Ubuntu/PPAs anymore due to third-party nature of PPAs that does not guarantees continuity. On the contrary, Arch Linux is enpowered from a big community and it is one of the best GNU/Linux distributions, rolling-release, so all packages are always updated to the last version.

EDIT: @firefoxlover check the experimental-junest releases at https://github.com/ivan-hc/GIMP-appimage/releases, I've also built a basic GIMP (without python or plugins) of about 90 MB. An ArchImage includes all the files of a basic Arch Linux container to work... all you have to do after the creation is to remove all the unneeded files into it (for example, GIMP starts as a 500-600 MB AppImage, by including only python and some plugins and removing other things it become 200, for now... I had to spend hours to check what was needed to keep GIMP work without break the AppImage/ArchImage).

[secretmango]

@ivan-hc haha did you translate my comment to french italian?

Yes I know and agree Arch is a good package source, especially for Appimages.

I am just wondering why both the Flatpak and your package are so way slower than this project, which poorly is discontinued.

Like, I did the Lava render and it took 5 seconds with this version, 10 seconds with both others.

I trust your packaging, was just wondering what the cause for that may be

[mttbernardini]

@ivan-hc haha did you translate my comment to french?

It's Italian 👀

[ivan-hc]

I am just wondering why both the Flatpak and your package are so way slower than this project, which poorly is discontinued.

I think it is because they use both a runtime (yes, maybe JuNest/Arch Linux can be considered a runtime in this case). The project of @aferrero2707 is built from source instead, this is why it is faster. That's it.

[secretmango]

Interesting, but what means "compiled from source"? Isnt the Arch one also compiled from source, with latest Arch dependencies?

Are the libraries deduplicated, instead of using my (Fedora 38) ones?

I dont get how this can have such a huge improvement, if it was simply compiled for x86_64 and runs on generalized Hardware

[ivan-hc]

@firefoxlover normally an AppImage must be compiled at least on the old and still supported Ubuntu LTS (now it is 18.04), due to GLIBC compatibility.

A container, instead, can work everywhere, and JuNest (see https://github.com/fsquillace/junest) requires at least a kernel 2.6 on the host.

My project, I named ArchImage (at https://github.com/ivan-hc/ArchImage) merges the two things, so you can really run the app on any GNU/Linux distribution.

I've built several AppImages this way, for a complete list see https://github.com/ivan-hc#my-appimage-packages