ubuntuusers.de

Da ich gerade an ähnlicher Front auf einem neu aufgesetzten 20.04 DT gekämpft habe, kann ich etwas zu einem möglichen Workaround mitteilen. Mein Ziel war: Gimp mit Plugins/Extensions (z.B. "Darktable" als RAW Editor) und Python Support.

Das offizielle Gimp Paket habe ich gar nicht erst installiert, denn mir war schon vorher klar, dass die von Snap gebildete Sandbox ein Widerspruch zu jedem Plugin ist (außer, das Plugin wäre Teil des Snap Packages). Ähnliches war beim "Chromium" Browser zu sehen, der als Snap Paket das Zusammenspiel mit dem "KeepassXC" Password Manager verweigert. Mir ist absolut unverständlich, warum Canonical für komplexe, erweiterbare Produkte (wie Gimp) diese elende Distributionsform wählt. Kostet wahrscheinlich weniger - verhindert aber jede tiefere Nutzung wesentlicher Anwendungen. Nicht nur bei Gimp - überall. Auch bei FreeCAD, Chromium usw.

Das Python Problem scheint zuerst ähnlich banal. Unter 20.04 fehlt schlicht der typische Symlink (/usr/bin/python). Er fehlt, weil er typisch für alles < python3 war und ist (und das ist böse und oll). Statt dessen gibt es einen Symlink unter /usr/bin/python3, den aber wiederum keine etablierte Anwendung nutzt (weil sie ihn gar nicht erst sucht). Also scheitern viele python Anwendungen, wie z.B. auch die ESP32 Entwicklungsumgebung für die Arduino IDE. Um diese zum Laufen zu bringen, half ein:

sudo apt install python-is-python3

Das Paket scheint ausschließlich den fehlenden Symlink zu setzen, also /usr/bin/python → python3, aber sicher bin ich mir dabei nicht. Trotzdem macht das Paket Sinn, denn einen händisch gesetzten Symlink hätte man nach 2 Wochen vergessen. Der Paketname ist immer findbar und selbsterklärend.

Um zu verhinderm dass python2 (z.B. als Abhängigkeit für irgendwas) installiert werden kann (und damit den zuvor gesetzten Symlink manipulieren würde/könnte):

sudo apt-mark hold python2 python2-minimal python2.7 python2.7-minimal libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib

Danach klappte die IDE mit dem Plugin, und auch andere python Anwendungen wurden wieder lebendig. Es ist dennoch ein bloody-hack, der bei einem ernst zu nehmenden OS nicht erforderlich sein sollte. Snap ist genau so eine Unsitte wie AppImages, aber letztere Blockieren wenigstens nicht Plugins und Interaktion mit anderen Paketen (zumindest nicht bei Gimp).

Zurück zu Gimp: Mein erster Versuch via ppa:otto-kesselgulasch/gimp scheiterte. Zahllose Versionskonflikte - Abbruch. Da stimmt was nicht.

Der zweite war besser: Gimp als AppImage INKLUSIVE Pluglins: https://github.com/aferrero2707/gimp-appimage/releases (ich habe die Version GIMP_AppImage-git-2.10.19-20200514-withplugins-x86_64.AppImage genommen). Funktionierte auf Anhieb - jedoch mit AppImage typischem drögen Start.

Jetzt noch "Darktable". Distributionsversion kommt per Snap, und ist damit ein No-Go was Integration in Gimp anbetrifft. Zum Glück gibt es ein ppa:

ppa:ubuntuhandbook1/darktable

Die vom ppa installierte Version klinkte sich nahtlos in den Gimp "File-öffnen" Dialog ein, sobald RAW Dateien geöffnet wurden. Es läuft sowohl als Gimp-Plugin als auch autark. Die Version ist bereits frischer als die Distributionsversion, denn an "Darktable" wird emsig gearbeitet (hier hätte ich auch ohne Not das ppa gewählt). Python habe ich noch nicht getestet - weil ich schlichtweg (noch) nicht beherrsche. Vermute aber, dass es klappen wird.

Vielleicht hilft's ja jemand in ähnlicher Problematik.

Zu Ubuntu 20.04:

GUI und Standard-Features: ein Gedicht, 100 Punkte

Anwendungen: Katastrophale User Experience. Die für mich schlechteste seit 16 Jahren Ubuntu. Snap ist die Hölle. Zig breaking changes in einer LTS Version. Das habe ich so noch nicht erleben müssen.

Hastalavista, Thomas

Flatpak!, die nutzen keine Sandbox.

Außerdem Arch und Flatpak Nutzer.

Du könntest es natürlich auch ganz "Hacky" mit einem Bash Script außerhalb der Snap machen,...

Ja natürlich könnte man, aber ich kann das nicht weil ich von diesen Dingen keine Ahnung habe. Es dreht sich dabei nicht um GIMP sondern um Marble. Ich weiß nicht wo die auf welcher distro ihre Kacheln stapeln und was die so an OS Kommandos unterstützen.

Ja danke tskv für den umfangreichen Beitrag, so nimmt das Thema doch noch Fahrt auf. Auch wenn ich nicht alles verstanden habe so doch dies:

Mir ist absolut unverständlich, warum Canonical für komplexe, erweiterbare Produkte (wie Gimp) diese elende Distributionsform wählt. Kostet wahrscheinlich weniger - verhindert aber jede tiefere Nutzung wesentlicher Anwendungen. Nicht nur bei Gimp - überall. Auch bei FreeCAD, Chromium usw.

Um diese zum Laufen zu bringen, half ein: sudo apt install python-is-python3

Damit hatte ich auch experimentiert, aber ohne Erfolg

Snap ist die Hölle.

Ich begreife nicht, warum Ubuntu das so nach oben drückt. Snap mag für manche Leute mit besonderen Bedürfnissen ganz sinnvoll sein, aber in einer Standardinstallation hat es nichts zu suchen.

Während meiner gestrigen stundenlangen Recherche zum Thema "Gimp Probleme wegen Snap" bin ich irgendwo auf eine Antwort des offiziellen Gimp/Snap-Paketbetreuers zur fehlenden Integrationsmöglichkeit gestoßen. Jemand bat darum, wenigstens essenzielle Plugins (wie z.B. G’MIC) zu ermöglichen. Die Antwort war ernüchternd: "Der eine will dies, der andere will das - dafür habe ich keine Zeit" (sinngemäß, wörtlich klang's diplomatischer/verschwurbelter).

Durch den Schwenk zu snap sehe ich eine Katastrophe kommen. Ich habe noch nie so viele externe ppa's eingebunden wie bei 20.04. Beim Chromium Browser basteln sich Anwender eine snap-freie Lösung, in dem sie das Paket aus der Debian Distribution für Ubuntu 20.04 umbiegen, bis es läuft.

Mein Gefühl: Canonical hat den Spaß am Desktop verloren.

Zum ersten mal in fast 16 Jahren habe ich über einen Schwenk zu Debian nachgedacht - und wenn dies bei 20.04.1 so weiter geht, werde ich ihn wohl vollziehen, denn da ist die Welt noch snapfrei.

tskv schrieb:

Während meiner gestrigen stundenlangen Recherche zum Thema "Gimp Probleme wegen Snap"

Also ich kann ja verstehen, dass man kein Fan von Snaps und Flatpaks ist. Aber so eine Suche sieht nach Bestätigunskultur aus.

bin ich irgendwo auf eine Antwort des offiziellen Gimp/Snap-Paketbetreuers zur fehlenden Integrationsmöglichkeit gestoßen. Jemand bat darum, wenigstens essenzielle Plugins (wie z.B. G’MIC) zu ermöglichen. Die Antwort war ernüchternd: "Der eine will dies, der andere will das - dafür habe ich keine Zeit" (sinngemäß, wörtlich klang's diplomatischer/verschwurbelter).

Hast du dafür noch einen Link ? Ich habe nur das hier gefunden. Da geht es darum, dass in der Gimp Snap eine Dependency für GMIC fehlt. Ein möglicher (zugegebenermaßen komplizierter) Workaround wird da aufgeführt. Die Konkurrenz Flatpak hat hier übrigens das selbe Problem.

Viele Plugins funktionieren, einige nicht, die müssen entweder umgeschrieben werden oder funktionieren gar nicht mehr. GIMP hätte ohne Snap und Flatpak wohl vermutlich gar keinen Plug in Support ootb. Da bräuchtest du dann wohl sowieso ne PPa für. HaJoEg hat die Beweggründe hier vorher ganz gut zusammengefasst:

Ich kann ja die Entwickler bei UBUNTU ganz gut verstehen, die wollen sich nicht mehr mit veralteter Software abgeben, und GIMP fehlen die Kapazitäten. Auf die snap Lösung werden noch manche GIMP Intensivnutzer ausweichen müssen, denn es fehlt an manchem Python Skript.

Mir Persönlich wäre auch gar nicht die Idee gekommen, dass Bild Dateien die man ein GIMP Einlädt aus dem Ordner .config kommen. Nächster Workaround der mir Spontan Einfällt. Den Ordner irgendwo hin verschieben wo er lesbar ist und dann an dem alten Ort mit einem Symlink auf diesen Verweisen. Ich verstehe allerdings durch aus, dass einem das zu viel Aufwand/Bastelei ist. Aber dann macht doch bitte einen Bug Report für euer spezifisches Problem und Meckert nicht im Textforum, so wird das nie irgendwo mit aufgenommen 😉 Es gibt z.B. keinen einzigen zu deinem KeepasXC Problem hier.

tskv schrieb:

Durch den Schwenk zu snap sehe ich eine Katastrophe kommen. Ich habe noch nie so viele externe ppa's eingebunden wie bei 20.04. Beim Chromium Browser basteln sich Anwender eine snap-freie Lösung, in dem sie das Paket aus der Debian Distribution für Ubuntu 20.04 umbiegen, bis es läuft.

Und genau auf diese Arbeit hat Canonical keinen Bock, deshalb bieten sie es als Snap an.

haveaproblem schrieb:

tskv schrieb:

Während meiner gestrigen stundenlangen Recherche zum Thema "Gimp Probleme wegen Snap"

Also ich kann ja verstehen, dass man kein Fan von Snaps und Flatpaks ist. Aber so eine Suche sieht nach Bestätigunskultur aus.

Unfug. Mir ging (und geht) es um ein sauberes Aufsetzen einer neuen Arbeitsmaschine für 3 Teilbereiche: Software-, Web- und Microcontrollerentwicklung, Leiterplattenentwicklung und 3D CAD/3D Druck sowie Bearbeitung digitaler Medien (Bild/Video/Animation). Die ersten 2 liefen zu meiner vollen Zufriedenheit auf einem Ubuntu 16.04 DT, für den letzten musste ich bislang einen Windows (7) PC mit Adobe SW vorhalten, da NIX in diesem Metier nicht wirklich mitspielt(e). Da ich diesen WIN PC nur mit großem Grundekel anschalte, habe ich mir jetzt vorgenommen, alles auf Linux zu betreiben. Viele Anwendungen sind mittlerweile erwachsen und brauchbar geworden (Gimp, Darktable, Blender, mit Abstrichen auch Kdenlive) - und jetzt, da eine Komplettmigration des Workflows denkbar geworden ist, grätscht mir die Distribution dazwischen.

bin ich irgendwo auf eine Antwort des offiziellen Gimp/Snap-Paketbetreuers zur fehlenden Integrationsmöglichkeit gestoßen. Jemand bat darum, wenigstens essenzielle Plugins (wie z.B. G’MIC) zu ermöglichen. Die Antwort war ernüchternd: "Der eine will dies, der andere will das - dafür habe ich keine Zeit" (sinngemäß, wörtlich klang's diplomatischer/verschwurbelter).

Hast du dafür noch einen Link ? Ich habe nur das hier gefunden. Da geht es darum, dass in der Gimp Snap eine Dependency für GMIC fehlt. Ein möglicher (zugegebenermaßen komplizierter) Workaround wird da aufgeführt. Die Konkurrenz Flatpak hat hier übrigens das selbe Problem.

Ich habe leider keinen Link. Ich war mit einem per Snap installierten Chromium Browser unterwegs um die Probleme von Snap zu verstehen. Diesen habe ich - samt der Chronik - am Abend deinstalliert (und durch Chrome ersetzt). Mir ist nur noch in Erinnerung, dass es ein Thread in deutsch war.

Viele Plugins funktionieren, einige nicht, die müssen entweder umgeschrieben werden oder funktionieren gar nicht mehr. GIMP hätte ohne Snap und Flatpak wohl vermutlich gar keinen Plug in Support ootb. Da bräuchtest du dann wohl sowieso ne PPa für. HaJoEg hat die Beweggründe hier vorher ganz gut zusammengefasst:

Mit der von mir beschriebenen Installationsform (Gimp AppImage inkl. Plugins + BT vom ppa) scheint bislang alles zu funktionieren. Ich konnte 2 weitere Plugins problemlos installieren. Nur Python kann ich nicht testen.

Ich kann ja die Entwickler bei UBUNTU ganz gut verstehen, die wollen sich nicht mehr mit veralteter Software abgeben, und GIMP fehlen die Kapazitäten. Auf die snap Lösung werden noch manche GIMP Intensivnutzer ausweichen müssen, denn es fehlt an manchem Python Skript.

Ich denke eher, dass Gimp Intensivnutzer die Flucht zu Debian antreten werden. Oder zu Windows und Adobe. Oder zu Gimp auf Windows - was ein Treppenwitz der Geschichte wäre ☺

Mir Persönlich wäre auch gar nicht die Idee gekommen, dass Bild Dateien die man ein GIMP Einlädt aus dem Ordner .config kommen. Nächster Workaround der mir Spontan Einfällt. Den Ordner irgendwo hin verschieben wo er lesbar ist und dann an dem alten Ort mit einem Symlink auf diesen Verweisen. Ich verstehe allerdings durch aus, dass einem das zu viel Aufwand/Bastelei ist. Aber dann macht doch bitte einen Bug Report für euer spezifisches Problem und Meckert nicht im Textforum, so wird das nie irgendwo mit aufgenommen 😉 Es gibt z.B. keinen einzigen zu deinem KeepasXC Problem hier.

Die durch Snap verursachten Probleme in Chromium sind für mich nicht bedeutend. Mein primärer Browser ist FF, bei dem die KeepassXC Integration klappt. Als Zweitbrowser nutze ich jetzt (ungerne) Chrome, bei welchem die Integration ebenfalls ootb funktioniert. Für einen brauchbaren Bug Report ist mehr Wissen über Snap erforderlich, über welches ich nicht verfüge. Zudem scheint es den Entwicklern bekannt, denn die Browserintegration von KeepassXC in Chromium scheitert mit einer klaren Ansage: "Integration bei per Snap installierten Browsern nicht möglich".

tskv schrieb:

Durch den Schwenk zu snap sehe ich eine Katastrophe kommen. Ich habe noch nie so viele externe ppa's eingebunden wie bei 20.04. Beim Chromium Browser basteln sich Anwender eine snap-freie Lösung, in dem sie das Paket aus der Debian Distribution für Ubuntu 20.04 umbiegen, bis es läuft.

Und genau auf diese Arbeit hat Canonical keinen Bock, deshalb bieten sie es als Snap an.

Natürlich verursacht ein herkömmliches Installationspaket mehr Arbeit - und Snap/Flatpack/AppImages sind auch völlig ok, wenn es um Anwendungen geht, die autark und isoliert laufen (wie z.B. Cura). Für alles, was nur mit Integration von Plugins oder 3rd Party Anwendungen Sinn macht, ist Snap ein no-go - und vernichtet die Arbeit von bislang sehr engagierten Entwicklerteams.