Von Bolle vom Berg am Sa, 26. August 2017 um 18:49 #
wie ich die neue Gimp-Version unter Linux testen kann, ohne vor unlösbaren Abhängigkeiten zu stranden? apt-get build-dep gimp schleudert mir unter debian über 400 mb auf die Festplatte, wobei der Compiler dann an fehlender lib-krackelbum aufgibt, die in der distri nicht vorkommt, deren Kompilervorgang an lib-klacklackklack scheitert, die auch nicht vorhanden ist. Spätestens da hatte ich keine Lust mehr, und den ganzen Kram wieder händisch entfernt.
Falls du übrigens den Grund dafür suchst, warum apt-get build-dep gimp die nicht installiert hat:
Das bringt die Abhängigkeiten des GIMP-Paket im Debian-Repository ins System. Selbiges ist aber GIMP 2.8.x, und da wird die libmypaint noch nicht benötigt.
Der Rest der Abhängigkeiten passt, da GIMP hier eher konservativ agiert und nicht meint, bei einer neu veröffentlichen Bibliotheksversion diese gleich voraussetzen zu müssen - und falls doch, dann weil es ursächlich am Erscheinen einer solchen Version beteiligt war.
Von Bolle vom Berg am So, 27. August 2017 um 15:51 #
Das war mir schon klar. Ich hatte nur die Hoffnung, dass die Abhängigkeiten für die 2.9er Versionen langen würden, da doch stretch noch nicht soo fürchterlich alte Bibliotheken besitzt. Würde das einbinden von backports-repositories was bringen?
Da es bisher kein libmypaint irgendwo in Debian gibt, eher nein. Allerdings kenne ich das auf Debian testing auch als problemlos baubar, keine Ahnung was bei dir mit "Jogl" fehlen sollte.
Gerade eben frisch v1.3.0 per Git geholt - autogen.sh läuft durch, configure läuft durch, make und make install ebenso - hat keine 10 Minuten gedauert.
Hast du das config.log noch irgendwo?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 27. Aug 2017 um 18:25.
Mit der libmypaint ist Vorsicht geboten und man sollte auf jeden Fall die aktuelle stabile Version 1.3 verwenden und nicht Head, da es nach der 1.3 (momentan) inkompatible Änderungen gab. Auch ist es eine gute Idee, das Zielverzeichnis für babl, gegl und gimp (bei mir ist das /usr/local/gimp), vor jedem Compilerlauf komplett zu entsorgen, damit keine alten Plugins oder Bibliotheken übrigbleiben, die ansonsten für schwer zu findende Probleme sorgen können.
Von Bolle vom Berg am So, 27. August 2017 um 15:47 #
libmypaint ließ sich nicht kompilieren, weil "Jogl" nicht vorhanden. ist. Selbstverständlich habe ich es mit der Version 1.3 versucht. Es ist halt schade, dass es so verzwickt ist, die Entwicklerversionen von gimp zu testen. Das verbesserte Farbmanagement durch gegl klingt verlockend.
Och, das ist bei mir ungefähr einmal jährlich dran - ansonsten reicht es, jeweils bis zum autogen/configure-Schritt zurückzugehen. Es wäre auch äußerst lästig, mehrmals täglich das Verzeichnis komplett zu löschen
Na ja, ich mache das per Skript, dass auch jeweils die ganzen git clean/pull, autogen, make usw. mit erledigt. Vor dem Löschen kommt alles in ein Tar und wenn am Ende nicht exit 0 rauskommt, kommt alles weg und das alte Tar wird wieder ausgepackt. Ist vielleicht nicht die schlaueste Lösung, aber funktioniert und hat mir schon manchen Ärger erspart. Allerdings mache ich das auch nur einmal in der Woche oder so…
Von Stanley Switek am So, 27. August 2017 um 21:02 #
Ich habe das gleiche Problem mit der libmypaint. (Debian Testing) (Ehrlich gesagt habe ich es schon oft probiert aber noch nie geschafft GIMP 2.9.x zu bauen.)
Laut eines Blogbeitrags auf gimp.org "GIMP 2.10 blockers and the road to 3.0" von Alexandre Prokoudine am 2.2.2017 sollte es 'soon' eine Flatpak Version von den Developer Builds geben.
Ich habe zugegebenermassen auch keine Erfahrung mit Flatpak diesen Weg aber trotzdem mal verfolgt. Auf der Flatpak Seite finde ich unter 'Applications' kein solches Flatpak und Forumsbeiträge die auf entsprechende GIMP- bzw. das benötigte 'nightly-graphics' Flatpak verweisen (offensichtlich bei Red Hat lt. whois) sind nicht erreichbar.
Wie ist also der Stand mit den Flatpacks für GIMP? Jemand auf dem Laufenden?
TL;DR Es gibt eine Anleitung, wie man ein GIMP-Flatpak bauen kann (oder konnte) und wie man diese dann verteilen könnte. Aktiv verfolgt wird das meines Wissens zur Zeit nicht.
Aus Entwicklersicht ist es Zusatzaufwand, der die ohnehin knappe Zeit für die Entwicklung von GIMP weiter einschränkt.
Es wäre hier also hilfreich, wenn sich jemand findet, der selbst Flatpaks haben will, und Wissen, Motivation und Zeit mitbringt und z.B. einfach mal ausprobiert, ob die zugehörige Konfigurationsdatei für GIMP noch funktioniert (bis auf die Aktualiserung der Versionsangaben von ein paar Abhängigkeiten sieht es so aus, als müsste sie: https://git.gnome.org/browse/gimp/tree/build/flatpak/org.gimp.GIMP.json).
Für die nachhaltige Bereitstellung von Flatpaks würde es sich dann anbieten, ein Docker-Image zu haben, in dem man diese bauen kann - das kann auf der Infrastruktur die z.B. auch www.gimp.org betreibt dann mitlaufen.
wie ich die neue Gimp-Version unter Linux testen kann, ohne vor unlösbaren Abhängigkeiten zu stranden?
apt-get build-dep gimp schleudert mir unter debian über 400 mb auf die Festplatte, wobei der Compiler dann an fehlender lib-krackelbum aufgibt, die in der distri nicht vorkommt, deren Kompilervorgang an lib-klacklackklack scheitert, die auch nicht vorhanden ist. Spätestens da hatte ich keine Lust mehr, und den ganzen Kram wieder händisch entfernt.
damit sich niemand verarscht vorkommt: es scheiterte an libmypaint.
Falls du übrigens den Grund dafür suchst, warum apt-get build-dep gimp die nicht installiert hat:
Das bringt die Abhängigkeiten des GIMP-Paket im Debian-Repository ins System. Selbiges ist aber GIMP 2.8.x, und da wird die libmypaint noch nicht benötigt.
Der Rest der Abhängigkeiten passt, da GIMP hier eher konservativ agiert und nicht meint, bei einer neu veröffentlichen Bibliotheksversion diese gleich voraussetzen zu müssen - und falls doch, dann weil es ursächlich am Erscheinen einer solchen Version beteiligt war.
Das war mir schon klar. Ich hatte nur die Hoffnung, dass die Abhängigkeiten für die 2.9er Versionen langen würden, da doch stretch noch nicht soo fürchterlich alte Bibliotheken besitzt. Würde das einbinden von backports-repositories was bringen?
Da es bisher kein libmypaint irgendwo in Debian gibt, eher nein. Allerdings kenne ich das auf Debian testing auch als problemlos baubar, keine Ahnung was bei dir mit "Jogl" fehlen sollte.
Gerade eben frisch v1.3.0 per Git geholt - autogen.sh läuft durch, configure läuft durch, make und make install ebenso - hat keine 10 Minuten gedauert.
Hast du das config.log noch irgendwo?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 27. Aug 2017 um 18:25.Die MX Linux Repositories haben 2.9.6 für Stretch, für Jessie ging es leider nicht weil eine Abhängigkeit nicht kompiliert werden kann.
Welche Abhängigkeit war das denn?
Mit der libmypaint ist Vorsicht geboten und man sollte auf jeden Fall die aktuelle stabile Version 1.3 verwenden und nicht Head, da es nach der 1.3 (momentan) inkompatible Änderungen gab.
Auch ist es eine gute Idee, das Zielverzeichnis für babl, gegl und gimp (bei mir ist das /usr/local/gimp), vor jedem Compilerlauf komplett zu entsorgen, damit keine alten Plugins oder Bibliotheken übrigbleiben, die ansonsten für schwer zu findende Probleme sorgen können.
libmypaint ließ sich nicht kompilieren, weil "Jogl" nicht vorhanden. ist. Selbstverständlich habe ich es mit der Version 1.3 versucht. Es ist halt schade, dass es so verzwickt ist, die Entwicklerversionen von gimp zu testen.
Das verbesserte Farbmanagement durch gegl klingt verlockend.
Och, das ist bei mir ungefähr einmal jährlich dran - ansonsten reicht es, jeweils bis zum autogen/configure-Schritt zurückzugehen. Es wäre auch äußerst lästig, mehrmals täglich das Verzeichnis komplett zu löschen
Na ja, ich mache das per Skript, dass auch jeweils die ganzen git clean/pull, autogen, make usw. mit erledigt. Vor dem Löschen kommt alles in ein Tar und wenn am Ende nicht exit 0 rauskommt, kommt alles weg und das alte Tar wird wieder ausgepackt. Ist vielleicht nicht die schlaueste Lösung, aber funktioniert und hat mir schon manchen Ärger erspart. Allerdings mache ich das auch nur einmal in der Woche oder so…
Ich habe das gleiche Problem mit der libmypaint. (Debian Testing)
(Ehrlich gesagt habe ich es schon oft probiert aber noch nie geschafft GIMP 2.9.x zu bauen.)
Laut eines Blogbeitrags auf gimp.org "GIMP 2.10 blockers and the road to 3.0"
von Alexandre Prokoudine am 2.2.2017 sollte es 'soon' eine Flatpak Version
von den Developer Builds geben.
Ich habe zugegebenermassen auch keine Erfahrung mit Flatpak diesen Weg aber
trotzdem mal verfolgt. Auf der Flatpak Seite finde ich unter 'Applications' kein solches Flatpak
und Forumsbeiträge die auf entsprechende GIMP- bzw. das benötigte 'nightly-graphics' Flatpak
verweisen (offensichtlich bei Red Hat lt. whois) sind nicht erreichbar.
Wie ist also der Stand mit den Flatpacks für GIMP? Jemand auf dem Laufenden?
Der aktuelle Stand ist das da:
https://git.gnome.org/browse/gimp/tree/build/flatpak/flatpak-howto.txt
TL;DR
Es gibt eine Anleitung, wie man ein GIMP-Flatpak bauen kann (oder konnte) und wie man diese dann verteilen könnte. Aktiv verfolgt wird das meines Wissens zur Zeit nicht.
Aus Entwicklersicht ist es Zusatzaufwand, der die ohnehin knappe Zeit für die Entwicklung von GIMP weiter einschränkt.
Es wäre hier also hilfreich, wenn sich jemand findet, der selbst Flatpaks haben will, und Wissen, Motivation und Zeit mitbringt und z.B. einfach mal ausprobiert, ob die zugehörige Konfigurationsdatei für GIMP noch funktioniert (bis auf die Aktualiserung der Versionsangaben von ein paar Abhängigkeiten sieht es so aus, als müsste sie: https://git.gnome.org/browse/gimp/tree/build/flatpak/org.gimp.GIMP.json).
Für die nachhaltige Bereitstellung von Flatpaks würde es sich dann anbieten, ein Docker-Image zu haben, in dem man diese bauen kann - das kann auf der Infrastruktur die z.B. auch www.gimp.org betreibt dann mitlaufen.
Ja, habe ich. Lade es hier runter und installiere "gimp-2.9.6.git.20170824" mit einem Klick:
build.opensuse.org/package/show/home%3Amrbadguy%3Agimp-unstable/gimp
Hat bei mir ca. 20 Sekunden gedauert.
gibt es auch so eine 1-Klick-Möglichkeit bei Debian?