Since this thread is the top hit for a Google search for the gimp-python problem, I’ll post the solution that I found. Ubuntu 18.10’s gimp-python can be manually downloaded and installed into Ubuntu 20.04. One other completely missing missing package, python-gtk2, also needs downloading. All other dependencies can be installed normally from 20.04. No security problems since it’s all from Ubuntu. No forced installation to ignore missing dependencies. “Heal Selection” works, and unlike the flatpak version, GMIC QT works.
Thanks useful to know.
The security issues may come, not because of the source of the packages, which is trusted, but because those packages won’t receive updates, for instance in case vulnerabilities are found in the future.
And even if they receive updates from Ubuntu, you’ll have to manually download and update again, I think, they won’t be part of the automatic updates with this installation, I’m quite sure.
So, if strict security is to be maintained on the machine, those packages must be tracked by hand.
My workaround, on Majaro, is to use the AppImage from @Carmelo_DrRaw, and it works quite well.
Once I move to Ubuntu 20.04 on my other machine (unless I change distro altogether…) I’ll probably use the same workaround when I need the python plugins.
That is interesting to hear. Currently I’m running Mint 19.3 Cinnamon (Based on Ubuntu 18.04). So I think I’ll face similar issues with regards to Python 2 when it comes to upgrading to a Ubuntu 20.04 based distro. So I think I’ll download the Gimp appimage to save any hassles of missing python2 libs!
Thanks to everybody involved for pointing out the AppImage solution and providing the corresponding links. This worked for me on Kubuntu 20.04. as it seems that I got gurm.py running
I switched to Linux only 6 months ago, but I must say that I have had some negative experiences with snap packages yet. In these cases, installing the “real” package via ppa helped a couple of times. So I am a little reluctant and stay prepared for the next problem that will arise out of the AppImage solution. Besides, doesn’t this concept contradicts the modular approach in which single modules and libraries are updated separately/independently?
Regarding the general problem and the related discussion in this thread, I can understand both sides. It is absolutely understandable that Ubuntu dropped python 2 support with 20.04. as back-porting makes the further development harder.
But from the user’s point of view this understanding doesn’t help a bit. Because neither the plugin works, nor is its function added to the main program. In this connection I can understand billznn
Clinging to 18.04 does not seem to be a good solution because “wait till there is a fix” is not an option here as darix pointed out.
So, I traced back the author of gurm.py to some forum, but his last activity was like 5 years ago. So I highly doubt he will come up with a Python 3 version in the next couple of months, years, … okay, that is FOSS, where contributors disappear or have to reallocate their resources.
Next I tried to port the plugin myself using 2to3 and pygi-convert.sh, but failed as I am only a casual coder.
So now I have an AppImage solution and I do not even know where this comes from and how long this will be maintained.
This is not a complaint but merely my two cents about a rather general problem that imho keeps many people from using Linux/FOSS as it still leaves the taste that this is only for people who really like to tinker with their system.
So now I have an AppImage solution and I do not even know where this comes from and how long this will be maintained.
Always a worry. Even whole linux distros have gone with their owner.
The 'buntu PPA that was a mainstay is stuck on 2.10.14 even with the promise “…as long as I live this PPA will never die and the most recent packages will for ever be.” I hope he is OK and well.
The appimage is very-very good, It is now my main Gimp 2.10.20 installation.
However there are improvements to the flatpak, which you can install via the main download at gimp.org This does come with Python2 installed.
Some plugins are now provided: BIMP / resynthesizer (+python scripts) / Liquid Rescale / Gmic / Lensfun / Fourier and the Gimp help.
With the Gimp flatpak installed you might do something like
flatpak search org.gimp.GIMP.Plugin
flatpak install flathub org.gimp.GIMP.Plugin.GMic
GURM ? largely replaced by Ofnuts resources manager which is derived from GURM. Look for AddonCollectionManager (2013-05-26)
I have that installed in the appimage, works no problem
The whole set of scripts and CI configurations required for building the AppImage are kept here: GitHub - aferrero2707/gimp-appimage
The good thing is that the AppImage creation does not rely at all on private computers and user resources, and is entirely based on GitHub and TravisCI.
I am currently maintaining the packages and have the plan to keep supporting them for as long as I can. Given that all scripts are public, the work could eventually be taken over by whoever knows some bash programming and is willing to contribute…
There is also some discussion about integrating the AppImage machinery into GIMP’s official build infrastructure, but unfortunately things are progressing quite slowly, and this is entirely my fault… see discussion here: Build on official GIMP infrastructure · Issue #9 · aferrero2707/gimp-appimage · GitHub
First of all, thanks to both of you, rich and Carmelo for the good points, explanations and hints. This really helped me in many ways.
Second, I’d like to clarify that my concern about the origin of the AppImage was not so much about safety but also about sustainability/availability and also about the question who to be grateful to. In that respect, many thanks to you Carmelo for dedicating so much work and time in that matter (I read the thread about integrating the AppImage officially). I see the need of helping hands, but regarding my virtually non-existing bash skills, my hands would probably do more harm than good.
Your posts lead me to the conclusion that using the AppImage is probably the best way for me. Thanks also for pointing me in the direction of Ofnuts’ Gimp Tools. Honestly, I haven’t heard about them yet. But as I do digital art as casually as I code, it is no big surprise to me. In fact I was already hoping that there is some alternative to GURM, so I’ll give this a try.
In this connection I have two questions:
In order to get rid of the default brushes, patterns,… is it a proper way to simply delete the path to the /tmp/.mount_GIMP_A0pqhO7/... in GIMP’s preferences?
In case I mess up things, how do I restore the original state in the sense of re-install? By deleting /home/user/.config/GIMP-AppImage before starting the AppImage?
The Gimp appimage works by unpacking the program files (about half-a-GB / 9500 of them) to a hidden folder in /tmp That is .mount_GIMP_xxxxx\ and the xxxxx changes each time you start the appimage. So the folder path to the standard Gimp resources changes as required. It runs via a script so no use adding the --no-data switch, that gets ignored.
You can delete the path in Preferences → Folders. The setting does carry over. I think the only practical way to thin down a big collection of brushes is by using the filter top of the dock. Unfortunately the filter is still broken for fonts, best way is load and unload fonts with your resources manager GURM or equivalent.
There is another way and I am a bit reluctant to bring it up here. The appimage can be ‘unpacked’ and run from a directory on disk same as any other program. All the files are available. There is a security issue, you have to be happy about running outside of root. I am ok with that but it is up to the user.
You are correct about the ~/.config/GIMP_Appimage folder. Delete that and a new default one is created next time you start the appimage. Just the same as an installed Gimp. Useful to keep. The next time Gimp is updated, download the new appimage, run and it will use the existing settings.
Hello, I don’t understand the security issue. The AppImages I use are downloaded to /home/user/Downloads and I run them from there without any problems. Do I miss something here?
@rich2005
Erm, you said the appimage unpacks to /tmp. That directory is normally writable for everyone, not just root (with some special settings to limit security issues).
The unpacking shouldn’t require root privileges, and neither should the actual running of the program from the appimage, any more than running a normal install would need root privileges. Installing from a traditional repository requires root privileges, but that’s a completely different story (it needs write access to /usr).
To be precise, the AppImage gets de-compressed on-the-fly and mounted in /tmp via FUSE.
To be honest I am not aware of any security risk related to the unpacking of the AppImage. On the contrary, this allows anyone to directly inspect the contents of the package if needed… the main security concern comes from the fact that the libraries bundled in the AppImage might not be at their most recent version. The package is built on CentOS7, and mostly relies on the libraries available there.
I think the general concern regards the fact that the software is not passed through the checks of the official distro repos.
But this is always a concern when you use packages not contained in official repos, like PPAs and AppImage.
So, the distro provider has to warn that if something fishy is happening becuase you run software not checked by them, it’s on you.
As a rule, I always verify the downloads, of AppImage for instance. But you still need to trust the AppImage provider (that they don’t put anything bad in it).
Python3 isn’t all that different. Perhaps the Gimp python plugins will get rewritten, before too much longer. The opposite direction (translating python3 code to python2) would be harder.
That’s why I have put a lot of effort into creating a fully automated build process for my AppImage (including the GIMP one). All the build scripts are kept in a public git repository, and they are executed automatically by TravisCI jobs which directly deploy the final AppImage package back to github. At no point in the build process the packages go through private or untrusted computers.
So anyone can inspect and check how the AppImage is built and what goes into it…
Just to clarify my answer: I did not take your words as a criticism, but I took the opportunity to underline this important aspect!
useful to know.
Nothing for you to worry about.