Gimp 2.9 installieren

[Tspoon]

Hallo,

ich möchte auf Debian stretch gimp 2.9 installieren, kann aber die fehlenden abhängikeiten nicht installieren weil
sie nicht gefunden werden.
Muss ich da in der sources list was ändern oder liegt das an etwas anderem?

lg

[breakthewall]

Derzeit ist Gimp 2.8.22 die aktuelle Stable-Version. Dagegen ist Gimp 2.9 eine Entwickler-Version. Doch für letzteres ist ein Flatpak verfügbar, unter https://www.gimp.org/downloads, womit die regulären Abhängigkeiten quasi umgangen werden. Das ist allerdings noch neu, und könnte daher Fehler beherbergen.

[debianoli]

Dagegen ist Gimp 2.9 eine Entwickler-Version. Doch für letzteres ist ein Flatpak verfügbar, unter https://www.gimp.org/downloads, womit die regulären Abhängigkeiten quasi umgangen werden.

Danke für den Tipp mit flatpak, das löst ENDLICH das Problem mit dem Dauer-Bug bei Debian-Gimp des Absturzes beim Anwenden der Käfig-Transformation (siehe viewtopic.php?f=34&t=164715&hilit=gimp

Allerdings gibt es bei Flatpak nur die Möglichkeit, Gimp Stable zu installieren. Kann man damit auch Gimp 2.9 kompillieren? Wenn ja, wie? Denn der normale Weg wie er auch in dem alten Thread von mir steht, der klappt nicht mehr. Ich kann kein aktuelles GImp 2.9 unter Stretch kompillieren wegen fehlender Abhängigkeiten von mypaint u.a., die es vor einem halben Jahr noch nicht gab (bin beim Kompillieren allerdings auch kein ProfI).

Ansonsten gibt es noch ein AppImage der aktuellen 2.9-Entwickler-Version von Gimp. Ist allerdings keine "offizielle" Quelle, sondern ein Community-Projekt. Funktioniert sehr gut, sicherheitshalber würde ich das immer in einer Sandbox laufen lassen: https://discuss.pixls.us/t/gimp-2-9-5-appimage/1959

[smutbert]

ich hab mich zum Bauen von gimp 2.9 aus diesem PPA bedient: https://launchpad.net/~otto-kesselgulas ... /gimp-edge

Dazu habe ich zuerst einmal ganz normal in Debian die build-Dependencies von dem in Debian verfügbaren gimp installiert und dann versucht die Quellcodepakete aus diesem PPA, angefangen mit gegl und gimp zu bauen.
Das scheitert zuerst wegen fehlender Abhängigkeiten, aber wenn man so Schritt für Schritt die fehlenden Abhängigkeiten aus dem PPA als Quellcode holt, baut (zu bauen versucht) und installiert, dann erhält man schließlich irgendwann tatsächlich eine handvoll Pakete, die sich problemlos unter stretch installieren und nutzen lassen (zumindest war es so, als ich es vor ein paar Monaten probiert habe).

Leider hatte ich dann mit einigen Plugins (gmic, ufraw) Schwierigkeiten und habe das sesbst bauen wieder sein lassen.

Alternativ gibt es auch einige fertige Appimages (keine Ahnung ob oder wie gut die unter Debian laufen, aber vor allem die erste Version klingt interessant finde ich):
- 2.9.5: https://discuss.pixls.us/t/community-bu ... tware/2137
- 2.9.9: https://www.gimp-forum.net/Thread-Porta ... -for-linux


edit:
Hoppla, dasselbe Appimage hat ja Debianoli schon verlinkt.
@debianoli
In welcher Art von Sandbox würdest du das denn laufen lassen?

[debianoli]

@debianoli
In welcher Art von Sandbox würdest du das denn laufen lassen?

Ich lasse das unter einem anderen User laufen und richte mir in dessen Home einen Austausch-Ordner ein, auf den mein eigentlicher User Zugriffs-Rechte hat. Start des Programms dann per kdesudo

Code: Alles auswählen

#!/bin/bash
kdesudo -u tester -c 'programm'

Ich denke mal, das dürfte reichen.

[smutbert]

Ah, ok, danke, das hätte ich sowieso gemacht.

Bei mir ist das Fenstermanagement mit dem 2.9.5 Appimage von pixls.us allerdings etwas merkwürdig/kaputt. Irgendwie ist das Bildfenster maximiert, trotzdem oben abgeschnitten, nutzt nicht die ganze Bildschirmhöhe und das in der Beschreibung versprochene photoflow-Plugin vermisse ich auch...

Das andere appimage mit der Version 2.9.9, das ich verlinkt habe und das auch auf dem Ubuntu PPA basiert, mit dem ich einmal eigene Pakete gebaut habe, läuft dafür ganz ordentlich – zumindest sind mir dort nicht gleich beim ersten Start solche Probleme ins Auge gesprungen.

[breakthewall]

Ich lasse das unter einem anderen User laufen und richte mir in dessen Home einen Austausch-Ordner ein, auf den mein eigentlicher User Zugriffs-Rechte hat. Start des Programms dann per kdesudo

Code: Alles auswählen

#!/bin/bash
kdesudo -u tester -c 'programm'

Ich denke mal, das dürfte reichen.

Das ist etwas dürftig und hat eigentlich nichts mit Sandboxing zutun. Zumal ein Programm als Nutzer gestartet, nach wie vor auf viele sensible Systemressourcen zugreifen kann.

Probiere mal folgendes aus:

Code: Alles auswählen

apt install firejail
firejail --appimage /Pfad/zum/Appimage

Damit könntest das Appimage schonmal grundlegend isolieren, womit etliche Systemressourcen eingeschränkt werden. Bei Bedarf ist das natürlich vielfältig erweiterbar.

[debianoli]

Danke, firejail kannte ich bereits. Wäre da apparmor nicht auch sinnvoll?

Edit: firejail nutz ja libapparmor