OS 15, gimp startet ohne GUI
Hallo Liste, hat das vielleicht noch jemand beobachtet? Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten: Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen. Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar". Sehr seltsam... Hat jemand von Euch eine Idee dazu? Grüße, Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Norbert,
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Ich habe hier nur die Neuinstallation. Upgrades mache ich nicht. Unter Leap 15 startet bei mir Gimp ganz normal - hier mit der KDE-Benutzeroberfläche. Gruß Robert -- Homepage: http://robert.familiegrosskopf.de LibreOffice Community: http://robert.familiegrosskopf.de/map_3
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Hallo Norbert, bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput). Schicke ich mit CTRL z und bg das Programm in den background erhalte ich: ~> ps ax | grep -i gimp 16573 pts/1 Sl 0:00 /usr/bin/gimp 16587 pts/1 R+ 0:00 grep --color=auto -i gimp gleiches geschieht durch den graphischen Start via KDE. Installiert ist Gimp aus den Standard openSuSE Repo: ~> zypper se -si gimp Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository ---+--------------------------+-------+------------------+-------- +----------------------- i+ | GimpResourcesThumbnailer | Paket | 2.1.2-1.99 | x86_64 | (Systempakete) i+ | gimp | Paket | 2.8.22-lp150.3.8 | x86_64 | Haupt- Repository (OSS) i+ | gimp-fourier | Paket | 0.4.1-2.1 | x86_64 | (Systempakete) i+ | gimp-help | Paket | 2.8.2-lp150.1.4 | noarch | Haupt- Repository (OSS) i+ | gimp-help-de | Paket | 2.8.2-lp150.1.4 | noarch | Haupt- Repository (OSS) i+ | gimp-lang | Paket | 2.8.22-lp150.3.8 | noarch | Haupt- Repository (OSS) i+ | gimp-plugin-aa | Paket | 2.8.22-lp150.3.8 | x86_64 | Haupt- Repository (OSS) i+ | gimp-plugin-dds | Paket | 3.0.1-lp150.1.3 | x86_64 | Haupt- Repository (OSS) i+ | gimp-plugin-dds-doc | Paket | 3.0.1-lp150.1.3 | x86_64 | Haupt- Repository (OSS) i+ | gimp-plugin-lqr | Paket | 0.7.2-lp150.1.3 | x86_64 | Haupt- Repository (OSS) i+ | gimp-plugin-lqr-lang | Paket | 0.7.2-lp150.1.3 | noarch | Haupt- Repository (OSS) i+ | gimp-plugins-python | Paket | 2.8.22-lp150.3.8 | x86_64 | Haupt- Repository (OSS) i+ | gimp-ufraw | Paket | 0.22-lp150.1.12 | x86_64 | Haupt- Repository (OSS) i+ | libgimp-2_0-0 | Paket | 2.8.22-lp150.3.8 | x86_64 | Haupt- Repository (OSS) i+ | libgimpui-2_0-0 | Paket | 2.8.22-lp150.3.8 | x86_64 | Haupt- Repository (OSS) Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert und andere Am Sonntag, 7. Oktober 2018, 19:36:55 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Hallo Norbert,
bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput). Ist wohl so gedacht! hmahr> man gimp hmahr> gimp --verbose INIT: gimp_load_config Parsing '/home/pmahr/.gimp-2.8/unitrc' Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/pmahr/.gimp-2.8/gimprc' gimp_composite: verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis etc. ...
Starte ich gimp alleine bekomme ich eine Warnung, die ich nicht schön finde: hmahr> gimp (gimp:3494): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' hmahr> Viele Grüße Hugo Mahr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 8. Oktober 2018, 12:30:12 CEST schrieb Hugo:
Hallo Herbert und andere
Am Sonntag, 7. Oktober 2018, 19:36:55 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Hallo Norbert,
bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput).
Ist wohl so gedacht! hmahr> man gimp hmahr> gimp --verbose INIT: gimp_load_config Parsing '/home/pmahr/.gimp-2.8/unitrc' Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/pmahr/.gimp-2.8/gimprc' gimp_composite: verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis etc. ...
Starte ich gimp alleine bekomme ich eine Warnung, die ich nicht schön finde: hmahr> gimp
(gimp:3494): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' hmahr>
Viele Grüße Hugo Mahr
also gimp --verbose läuft gar nicht, keine Rückgabe auf der Konsole. ~> gimp -v GNU Image Manipulation Program Version 2.8.22 git-describe: GIMP_2_8_20-60-ge39a4e1203 verwendet GEGL Version 0.3.34 (gebaut gegen Version 0.3.34) verwendet GLib Version 2.54.3 (gebaut gegen Version 2.54.3) verwendet GdkPixbuf Version 2.36.10 (gebaut gegen Version 2.36.10) verwendet GTK+ Version 2.24.32 (gebaut gegen Version 2.24.32) verwendet Pango Version 1.40.13 (gebaut gegen Version 1.40.13) verwendet Fontconfig Version 2.12.6 (gebaut gegen Version 2.12.6) verwendet Cairo Version 1.15.10 (gebaut gegen Version 1.15.10) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, Am Montag, 8. Oktober 2018, 20:22:17 CEST schrieb Herbert Albert:
Am Montag, 8. Oktober 2018, 12:30:12 CEST schrieb Hugo:
Hallo Herbert und andere
Am Sonntag, 7. Oktober 2018, 19:36:55 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Hallo Norbert,
bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput).
Ist wohl so gedacht! hmahr> man gimp hmahr> gimp --verbose INIT: gimp_load_config Parsing '/home/pmahr/.gimp-2.8/unitrc' Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/pmahr/.gimp-2.8/gimprc' gimp_composite: verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis etc. ...
Starte ich gimp alleine bekomme ich eine Warnung, die ich nicht schön finde: hmahr> gimp
(gimp:3494): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' hmahr>
Viele Grüße
Hugo Mahr
also gimp --verbose läuft gar nicht, keine Rückgabe auf der Konsole. ~> gimp -v GNU Image Manipulation Program Version 2.8.22 git-describe: GIMP_2_8_20-60-ge39a4e1203
verwendet GEGL Version 0.3.34 (gebaut gegen Version 0.3.34) verwendet GLib Version 2.54.3 (gebaut gegen Version 2.54.3) verwendet GdkPixbuf Version 2.36.10 (gebaut gegen Version 2.36.10) verwendet GTK+ Version 2.24.32 (gebaut gegen Version 2.24.32) verwendet Pango Version 1.40.13 (gebaut gegen Version 1.40.13) verwendet Fontconfig Version 2.12.6 (gebaut gegen Version 2.12.6) verwendet Cairo Version 1.15.10 (gebaut gegen Version 1.15.10)
gimp -v ergibt hier dasselbe. Aber das ist NICHT verbose sondern gibt die Versionsinformation zurück. https://wiki.gimp.org/index.php/Users:Tips#On_Linux, Überschrift 'Getting and posting the output of gimp --verbose' schreibt '2 Enter gimp --verbose --console-messages'. Das gibt - bei mir - ca. 115 Zeilen aus, bevor im GUI eine Eingabe kommt. Vielleicht hilft das ja. Ich hoffe, daß man hier sieht, wo gimp hängen bleibt. Geht das wirklich nicht, wäre es interessant, das Warum zu untersuchen. Gruß Hugo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.18 09:57 schrieb Hugo:
Hallo Herbert, Am Montag, 8. Oktober 2018, 20:22:17 CEST schrieb Herbert Albert:
Am Montag, 8. Oktober 2018, 12:30:12 CEST schrieb Hugo:
Hallo Herbert und andere
Am Sonntag, 7. Oktober 2018, 19:36:55 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert Hallo Norbert,
bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput). Ist wohl so gedacht! hmahr> man gimp hmahr> gimp --verbose INIT: gimp_load_config Parsing '/home/pmahr/.gimp-2.8/unitrc' Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/pmahr/.gimp-2.8/gimprc' gimp_composite: verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis etc. ...
Starte ich gimp alleine bekomme ich eine Warnung, die ich nicht schön finde: hmahr> gimp
(gimp:3494): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' hmahr>
Viele Grüße
Hugo Mahr also gimp --verbose läuft gar nicht, keine Rückgabe auf der Konsole. ~> gimp -v GNU Image Manipulation Program Version 2.8.22 git-describe: GIMP_2_8_20-60-ge39a4e1203
verwendet GEGL Version 0.3.34 (gebaut gegen Version 0.3.34) verwendet GLib Version 2.54.3 (gebaut gegen Version 2.54.3) verwendet GdkPixbuf Version 2.36.10 (gebaut gegen Version 2.36.10) verwendet GTK+ Version 2.24.32 (gebaut gegen Version 2.24.32) verwendet Pango Version 1.40.13 (gebaut gegen Version 1.40.13) verwendet Fontconfig Version 2.12.6 (gebaut gegen Version 2.12.6) verwendet Cairo Version 1.15.10 (gebaut gegen Version 1.15.10) gimp -v ergibt hier dasselbe. Aber das ist NICHT verbose sondern gibt die Versionsinformation zurück. https://wiki.gimp.org/index.php/Users:Tips#On_Linux, Überschrift 'Getting and posting the output of gimp --verbose' schreibt '2 Enter gimp --verbose --console-messages'. Das gibt - bei mir - ca. 115 Zeilen aus, bevor im GUI eine Eingabe kommt.
Vielleicht hilft das ja. Ich hoffe, daß man hier sieht, wo gimp hängen bleibt. Geht das wirklich nicht, wäre es interessant, das Warum zu untersuchen.
Gruß Hugo
Ich habe dieses Phänomen ein wenig weiter beobachtet. 1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren") 2. Beobachtung: wenn man "lange genug" gimp nicht startet (z.B. über Nacht) geht es danach genau 1x wieder Für mich riechen diese 2 Beobachtungen danach, dass nach dem 1. Lauf irgendetwas im Memory zurück bleibt, dass Gimp beim Start abfrägt. Wenn diesese irgendetwas zufällig noch im Speicher residiert, hängt gimp bei den darauffolgenden Startversuchen. Ist dieses irgendetwas jedoch zwischenzeitlich rausgeflogen,startet gimp wieder problemlos. Ich habe gimp versuchsweise mal in strace laufen lassen. Die letzten Zeilen im trace bis gimp hängt sind: --------------------------------------------------------------------- clone(child_stack=0x7fce36fe0830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce36fe19d0, tls=0x7fce36fe1700, child_tidptr=0x7fce36fe19d0) = 14765 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fce35fe0000 mprotect(0x7fce35fe1000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 clone(child_stack=0x7fce367df830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce367e09d0, tls=0x7fce367e0700, child_tidptr=0x7fce367e09d0) = 14766 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fce350af000 mprotect(0x7fce350b0000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 clone(child_stack=0x7fce358ae830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce358af9d0, tls=0x7fce358af700, child_tidptr=0x7fce358af9d0) = 14767 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fce348ae000 mprotect(0x7fce348af000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 clone(child_stack=0x7fce350ad830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce350ae9d0, tls=0x7fce350ae700, child_tidptr=0x7fce350ae9d0) = 14768 munmap(0x7fce3f4ef000, 252723) = 0 futex(0x7fce50783908, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7fce387e49d0, FUTEX_WAIT, 14762, NULL) = 0 futex(0x7fce367e09d0, FUTEX_WAIT, 14766, NULL --------------------------------------------------------------------- gimp wartet offensichtlich im futex() call "ewig" ..... Vielelicht liest ja hier ein linux-programmierer mit Erfahrung mit Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 13:50:37 CEST schrieb Norbert Zawodsky: Hallo Norbert [...]
Ich habe dieses Phänomen ein wenig weiter beobachtet.
1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren")
das mit dem Zwangsupdate per Yast habe ich probiert, einfach alle installierten gimp Pakte auf "unbedingt aktualisieren" gesetzt, ohne Wirkung. Kann jetzt noch versuchen alles zu deinstallieren und dann neu zu installieren. Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 18:32:01 CEST schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 13:50:37 CEST schrieb Norbert Zawodsky:
Hallo Norbert
[...]
Ich habe dieses Phänomen ein wenig weiter beobachtet.
1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren")
das mit dem Zwangsupdate per Yast habe ich probiert, einfach alle installierten gimp Pakte auf "unbedingt aktualisieren" gesetzt, ohne Wirkung.
Kann jetzt noch versuchen alles zu deinstallieren und dann neu zu installieren.
Herbert habe nun per Yast alles was mit gimp zu tun hat deinstalliert Yast beendet, neu aufgerufen und wieder installiert. Dazwischen nicht gebootet. Hat nichts gebracht, gimp startet nicht. Wird gimp via KDE Startmenü aufgerufen, erscheint kurz der hüpfende Cursor und in der Fensterleist wird schon mal Platz gemacht, das fällt aber wieder ins sich zusammen. Der Prozess ist aber in der Prozesstabelle vorhanden (10336 ? Sl 0:00 /usr/bin/ gimp-2.8). muss ich also händisch killen.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.18 19:16 schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 18:32:01 CEST schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 13:50:37 CEST schrieb Norbert Zawodsky:
Hallo Norbert
[...]
Ich habe dieses Phänomen ein wenig weiter beobachtet.
1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren") das mit dem Zwangsupdate per Yast habe ich probiert, einfach alle installierten gimp Pakte auf "unbedingt aktualisieren" gesetzt, ohne Wirkung.
Kann jetzt noch versuchen alles zu deinstallieren und dann neu zu installieren.
Herbert habe nun per Yast alles was mit gimp zu tun hat deinstalliert Yast beendet, neu aufgerufen und wieder installiert. Dazwischen nicht gebootet. Hat nichts gebracht, gimp startet nicht. Wird gimp via KDE Startmenü aufgerufen, erscheint kurz der hüpfende Cursor und in der Fensterleist wird schon mal Platz gemacht, das fällt aber wieder ins sich zusammen. Der Prozess ist aber in der Prozesstabelle vorhanden (10336 ? Sl 0:00 /usr/bin/ gimp-2.8). muss ich also händisch killen.
Es könnte eventuell auch im Programm eine "race condition" auftreten. Ich habe jetzt ein paar mal probiert gimp zu starten. Jedesmal das oben beschriebene Verhalten, Prozess scheint "waiting" in der Prozessliste auf. Dann habe ich es aus Interesse wieder unter strace probiert, und diesmal startete es. Irgend eine Art von "timing-problem", vielleicht kombiniert mit "Resten im Speicher". Aber meiner Meinung nach definitiv ein Programmfehler. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 19:43:38 CEST schrieb Norbert Zawodsky:
Am 09.10.18 19:16 schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 18:32:01 CEST schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 13:50:37 CEST schrieb Norbert Zawodsky:
Hallo Norbert
[...]
Ich habe dieses Phänomen ein wenig weiter beobachtet.
1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren")
das mit dem Zwangsupdate per Yast habe ich probiert, einfach alle installierten gimp Pakte auf "unbedingt aktualisieren" gesetzt, ohne Wirkung.
Kann jetzt noch versuchen alles zu deinstallieren und dann neu zu installieren.
Herbert
habe nun per Yast alles was mit gimp zu tun hat deinstalliert Yast beendet, neu aufgerufen und wieder installiert. Dazwischen nicht gebootet. Hat nichts gebracht, gimp startet nicht. Wird gimp via KDE Startmenü aufgerufen, erscheint kurz der hüpfende Cursor und in der Fensterleist wird schon mal Platz gemacht, das fällt aber wieder ins sich zusammen. Der Prozess ist aber in der Prozesstabelle vorhanden (10336 ? Sl 0:00 /usr/bin/ gimp-2.8). muss ich also händisch killen.
Es könnte eventuell auch im Programm eine "race condition" auftreten. Ich habe jetzt ein paar mal probiert gimp zu starten. Jedesmal das oben beschriebene Verhalten, Prozess scheint "waiting" in der Prozessliste auf. Dann habe ich es aus Interesse wieder unter strace probiert, und diesmal startete es.
Irgend eine Art von "timing-problem", vielleicht kombiniert mit "Resten im Speicher".
Aber meiner Meinung nach definitiv ein Programmfehler.
gibst du bei strace gimp noch etwas an? Wenn ich das ausführe wird mir massenhaft die Konsole vollgeschrieben, aber gimp startet nicht. Am Ende steht futex(0x7f3e001ae9d0, FUTEX_WAIT, 16111, NULL -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.18 20:36 schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 19:43:38 CEST schrieb Norbert Zawodsky:
Am 09.10.18 19:16 schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 18:32:01 CEST schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 13:50:37 CEST schrieb Norbert Zawodsky:
Hallo Norbert
[...]
Ich habe dieses Phänomen ein wenig weiter beobachtet.
1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren") das mit dem Zwangsupdate per Yast habe ich probiert, einfach alle installierten gimp Pakte auf "unbedingt aktualisieren" gesetzt, ohne Wirkung.
Kann jetzt noch versuchen alles zu deinstallieren und dann neu zu installieren.
Herbert habe nun per Yast alles was mit gimp zu tun hat deinstalliert Yast beendet, neu aufgerufen und wieder installiert. Dazwischen nicht gebootet. Hat nichts gebracht, gimp startet nicht. Wird gimp via KDE Startmenü aufgerufen, erscheint kurz der hüpfende Cursor und in der Fensterleist wird schon mal Platz gemacht, das fällt aber wieder ins sich zusammen. Der Prozess ist aber in der Prozesstabelle vorhanden (10336 ? Sl 0:00 /usr/bin/ gimp-2.8). muss ich also händisch killen. Es könnte eventuell auch im Programm eine "race condition" auftreten. Ich habe jetzt ein paar mal probiert gimp zu starten. Jedesmal das oben beschriebene Verhalten, Prozess scheint "waiting" in der Prozessliste auf. Dann habe ich es aus Interesse wieder unter strace probiert, und diesmal startete es.
Irgend eine Art von "timing-problem", vielleicht kombiniert mit "Resten im Speicher".
Aber meiner Meinung nach definitiv ein Programmfehler. gibst du bei strace gimp noch etwas an? Wenn ich das ausführe wird mir massenhaft die Konsole vollgeschrieben, aber gimp startet nicht. Am Ende steht futex(0x7f3e001ae9d0, FUTEX_WAIT, 16111, NULL
Ja??? Siehe einer meiner letzten posts von heute ... Dort schrieb ich "... gimp wartet 'ewig' im futex call ...." Das Ganze ist vermutlich ein timing-problem, race-condition, wasauchimmer. Für Programmierer extrem schwer festzumachen. Denn kaum ändert man etwas an der Umgebung (mit/ohne debugger, mit/ohne strace,...) tritt es vielleicht nicht mehr auf, vielleicht aber doch, vielleicht auch nur manchmal... Ich weiß es noch aus meiner programmier Tätigkeit. Derartige Fehler sind der blanke Horror... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 09:57:28 CEST schrieb Hugo:
Hallo Herbert,
Am Montag, 8. Oktober 2018, 20:22:17 CEST schrieb Herbert Albert:
Am Montag, 8. Oktober 2018, 12:30:12 CEST schrieb Hugo:
Hallo Herbert und andere
Am Sonntag, 7. Oktober 2018, 19:36:55 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Hallo Norbert,
bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput).
Ist wohl so gedacht! hmahr> man gimp hmahr> gimp --verbose INIT: gimp_load_config Parsing '/home/pmahr/.gimp-2.8/unitrc' Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/pmahr/.gimp-2.8/gimprc' gimp_composite: verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis etc. ...
Starte ich gimp alleine bekomme ich eine Warnung, die ich nicht schön finde: hmahr> gimp
(gimp:3494): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' hmahr>
Viele Grüße
Hugo Mahr
also gimp --verbose läuft gar nicht, keine Rückgabe auf der Konsole. ~> gimp -v GNU Image Manipulation Program Version 2.8.22 git-describe: GIMP_2_8_20-60-ge39a4e1203
verwendet GEGL Version 0.3.34 (gebaut gegen Version 0.3.34) verwendet GLib Version 2.54.3 (gebaut gegen Version 2.54.3) verwendet GdkPixbuf Version 2.36.10 (gebaut gegen Version 2.36.10) verwendet GTK+ Version 2.24.32 (gebaut gegen Version 2.24.32) verwendet Pango Version 1.40.13 (gebaut gegen Version 1.40.13) verwendet Fontconfig Version 2.12.6 (gebaut gegen Version 2.12.6) verwendet Cairo Version 1.15.10 (gebaut gegen Version 1.15.10)
gimp -v ergibt hier dasselbe. Aber das ist NICHT verbose sondern gibt die Versionsinformation zurück. https://wiki.gimp.org/index.php/Users:Tips#On_Linux, Überschrift 'Getting and posting the output of gimp --verbose' schreibt '2 Enter gimp --verbose --console-messages'. Das gibt - bei mir - ca. 115 Zeilen aus, bevor im GUI eine Eingabe kommt.
Vielleicht hilft das ja. Ich hoffe, daß man hier sieht, wo gimp hängen bleibt. Geht das wirklich nicht, wäre es interessant, das Warum zu untersuchen.
Gruß Hugo Hallo Hugo,
war mir schon bewusst, dass es ein Unterschied zwischen -v und --verbose gibt. Nur bekomme ich auf der Konsole auch mit gimp --verbose --console-messages keinen Output und habe deshalb meine Versionen geplottet. Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf. -- Maik Wagner www.linuxandlanguages.com -----Original-Nachricht----- Hat jemand von Euch eine Idee dazu? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo, hab hier leap 15.0 und gimp 2.10 Fehler tritt hier auch nicht auf. Frank p.s. alle updates installiert d.o. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.10.18 um 22:11 schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o.
Hallo, hab auch unter tumbleweed mit xfe Desktop probiert, keine Probleme. Gruß Hugo Egon Maurer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.10.18 um 22:43 schrieb Hugo Egon Maurer:
Am 07.10.18 um 22:11 schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o.
Hallo,
hab auch unter tumbleweed mit xfe Desktop probiert, keine Probleme.
Gruß
Hugo Egon Maurer
Hallo, ich noch mal, probier mit einem neuen User, oder das/die home Gimp Verzeichnis(e) aus Deinem Benutzerordner umzubenennen. Gruß und einen guten Start in die Woche Hugo Egon Maurer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 7. Oktober 2018, 22:49:57 CEST schrieb Hugo Egon Maurer:
Am 07.10.18 um 22:43 schrieb Hugo Egon Maurer:
Am 07.10.18 um 22:11 schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o.
Hallo,
hab auch unter tumbleweed mit xfe Desktop probiert, keine Probleme.
Gruß
Hugo Egon Maurer
Hallo, ich noch mal,
probier mit einem neuen User, oder das/die home Gimp Verzeichnis(e) aus Deinem Benutzerordner umzubenennen.
Gruß und einen guten Start in die Woche
Hugo Egon Maurer
Bei mir im Home liegen mittlerweile .gimp-2.2 .gimp-2.4 .gimp-2.6 .gimp-2.8 Das Umbennen von .gimp-2.8 ist keine Lösung. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 7. Oktober 2018, 22:11:43 CEST schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o. gimp 2.10 ist aber nicht der Standard für leap 15. Im Haupt-Repository (OSS) ist 2.8.22-lp150.3.8.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 8. Oktober 2018, 20:36:27 CEST schrieb Herbert Albert:
gimp 2.10 ist aber nicht der Standard für leap 15. Im Haupt-Repository (OSS) ist 2.8.22-lp150.3.8.
Hallo, Herbert, vll. mit einem zypper patch 'reingekommen schönnnn Abend Frank -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 8. Oktober 2018, 20:36:27 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 22:11:43 CEST schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o. gimp 2.10 ist aber nicht der Standard für leap 15. Im Haupt-Repository (OSS) ist 2.8.22-lp150.3.8.
Auch hier: Science Repo aktiv? zypper lr -d zypper se -si libopenblas Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 8. Oktober 2018, 22:13:58 CEST schrieb Stephan Hemeier:
Am Montag, 8. Oktober 2018, 20:36:27 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 22:11:43 CEST schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o.
gimp 2.10 ist aber nicht der Standard für leap 15. Im Haupt-Repository (OSS) ist 2.8.22-lp150.3.8.
Auch hier: Science Repo aktiv? zypper lr -d
zypper se -si libopenblas
Stephan Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen?
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 18:33:13 CEST schrieb Herbert Albert:
Am Montag, 8. Oktober 2018, 22:13:58 CEST schrieb Stephan Hemeier:
Am Montag, 8. Oktober 2018, 20:36:27 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 22:11:43 CEST schrieb eilfh:
Am Sonntag, 7. Oktober 2018, 19:41:33 CEST schrieb Maik Wagner:
Habe das mal unter "Tumbleweed" nachvollzogen. Dort treten die Probleme nicht auf.
Hallo,
hab hier leap 15.0 und gimp 2.10
Fehler tritt hier auch nicht auf.
Frank
p.s. alle updates installiert d.o.
gimp 2.10 ist aber nicht der Standard für leap 15. Im Haupt-Repository (OSS) ist 2.8.22-lp150.3.8.
Auch hier: Science Repo aktiv? zypper lr -d
zypper se -si libopenblas
Stephan Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen?
Nicht wirklich.... So ein Problem hatte ich auch einmal mit einer von mir gebauten lib......... Und das mit libopenblas war aus einem Bugreport....... Aber ihr macht das schon........ Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen?
Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren. Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer. 1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&boring=yes ' -- MfG Richi
Am Dienstag, 9. Oktober 2018, 19:50:14 CEST schrieb Richard Kraut:
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen?
Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren.
Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer.
1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&boring=y es ' das mit dem "einfach" ist nicht so einfach.
Bei mir ist installiert: :~> zypper se -si openblas Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository ---+----------------------------+-------+------------------+-------- +----------------------------------------------------------- i+ | libopenblas_pthreads-devel | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | libopenblas_pthreads0 | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | openblas-devel | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | openblas-devel-headers | Paket | 0.3.2-lp150.54.1 | noarch | Software for Scientists and Engineers (openSUSE_Leap_15.0) libopenblas_pthreads-devel lässt sich mit openblas-devel und octave-devel in Abhängigkeit löschen. Bei libopenblas_pthreads0 sieht das anders aus. Würde ich das mit Yast löschen, würden eine Unmenge von Pakten mit deinstalliert. Das reicht aber nicht um gimp zu starten, es läuft noch nicht. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 20:31:25 CEST schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 19:50:14 CEST schrieb Richard Kraut:
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen?
Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren.
Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer.
1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&boring=y es ' das mit dem "einfach" ist nicht so einfach.
Bei mir ist installiert: :~> zypper se -si openblas Repository-Daten werden geladen... Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository ---+----------------------------+-------+------------------+-------- +----------------------------------------------------------- i+ | libopenblas_pthreads-devel | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | libopenblas_pthreads0 | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | openblas-devel | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | openblas-devel-headers | Paket | 0.3.2-lp150.54.1 | noarch | Software for Scientists and Engineers (openSUSE_Leap_15.0)
libopenblas_pthreads-devel lässt sich mit openblas-devel und octave-devel in Abhängigkeit löschen. Bei libopenblas_pthreads0 sieht das anders aus. Würde ich das mit Yast löschen, würden eine Unmenge von Pakten mit deinstalliert.
Das reicht aber nicht um gimp zu starten, es läuft noch nicht.
Und wie ich gefragt habe: Aus dem Science Repo???? Mal darüber nachgedacht, libopenblas_pthreads0 auf das OSS Repo umzustellen?????????????????? Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 20:38:37 CEST schrieb Stephan Hemeier:
Am Dienstag, 9. Oktober 2018, 20:31:25 CEST schrieb Herbert Albert:
Am Dienstag, 9. Oktober 2018, 19:50:14 CEST schrieb Richard Kraut:
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen?
Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren.
Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer.
1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&bori ng=y es '
das mit dem "einfach" ist nicht so einfach.
Bei mir ist installiert: :~> zypper se -si openblas
Repository-Daten werden geladen... Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository ---+----------------------------+-------+------------------+-------- +----------------------------------------------------------- i+ | libopenblas_pthreads-devel | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | libopenblas_pthreads0 | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | openblas-devel | Paket | 0.3.2-lp150.54.1 | x86_64 | Software for Scientists and Engineers (openSUSE_Leap_15.0) i+ | openblas-devel-headers | Paket | 0.3.2-lp150.54.1 | noarch | Software for Scientists and Engineers (openSUSE_Leap_15.0)
libopenblas_pthreads-devel lässt sich mit openblas-devel und octave-devel in Abhängigkeit löschen. Bei libopenblas_pthreads0 sieht das anders aus. Würde ich das mit Yast löschen, würden eine Unmenge von Pakten mit deinstalliert.
Das reicht aber nicht um gimp zu starten, es läuft noch nicht.
Und wie ich gefragt habe: Aus dem Science Repo????
Mal darüber nachgedacht, libopenblas_pthreads0 auf das OSS Repo umzustellen??????????????????
Stephan stimmt, das ist mir entgangen, das openblas aus dem Science Repo stammt. Nach dem umstellen läuft gimp wieder. Welche Auswirkung das auf Programme aus dem Science Repo hat, kann ich nicht sagen.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.18 19:50 schrieb Richard Kraut:
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen? Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren.
Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer.
1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&boring=yes '
"einfach deinstallieren" ??? Was ist mit den anderen 46 Abhängigkeiten, die von libopenblas abhängig sind ? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 21:35:56 CEST schrieb Norbert Zawodsky:
Am 09.10.18 19:50 schrieb Richard Kraut:
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen? Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren.
Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer.
1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&boring=yes '
"einfach deinstallieren" ???
Was ist mit den anderen 46 Abhängigkeiten, die von libopenblas abhängig sind ?
Und auch hier: zypper se -si libopenblas Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.18 21:42 schrieb Stephan Hemeier:
Am Dienstag, 9. Oktober 2018, 21:35:56 CEST schrieb Norbert Zawodsky:
Am 09.10.18 19:50 schrieb Richard Kraut:
Am Dienstag, den 09.10.2018, 18:33 +0200 schrieb Herbert Albert:
Führt das nicht an der Diskussion vorbei? Sollte nicht das gimp, welches im Hauptrepo ist laufen? Das Problem liegt nicht an Gimp, sondern an der Bibliothek libopenblas. Einfach die Lib deinstallieren und es sollte wieder funktionieren.
Selbiges Problem ist bspw. auch Debian bekannt und wird dort im Bugtracker unter der Nummer #904544 geführt [1]. Die Ursache scheint aber am Upstream von openblas selbst zu liegen und nicht am Paketbauer/betreuer.
1: ' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23904544&trim=no&boring=yes '
"einfach deinstallieren" ???
Was ist mit den anderen 46 Abhängigkeiten, die von libopenblas abhängig sind ?
Und auch hier: zypper se -si libopenblas
Stephan
Wie in einem der zahlreichen posts vorhin erwähnt... Ich habe die libopenblas nun von jener aus dem sience-repo wieder auf die aus dem oss.-repo downgedatet. Seither ist das Problem verschwunden! gimp startet immer brav. ("immer" == ca. 5x in Folge probiert) Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, den 09.10.2018, 21:35 +0200 schrieb Norbert Zawodsky:
"einfach deinstallieren" ???
Was ist mit den anderen 46 Abhängigkeiten, die von libopenblas abhängig sind ?
Wie bereits geschrieben, handelte es sich bei dem von mir erwähnten System um eine Debian-Installation. Hier wurden in Folge der Deinstallation von libopenblas lediglich die folgenden Pakete auf Grund der Abhängigkeiten deinstalliert: libopenblas-base libopenblas-dev bio-eagle libyade molds python-yade python3-brainstorm yade Das sind keine 46. Bei den verbliebenen zwei Rechnern mit openSUSE Leap 42.3 gibt es besagtes Problem nicht. Hier, sowie in der VM mit Leap 15, ist auch nur das Hauptrepo, das Nonfree-Repo und das Repo von Packman aktiv. Das vermeidet Probleme. Zugegeben nicht alle, aber viele. -- MfG Richi
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Graphics Repo aktiv? zypper lr -d zypper se -si libopenblas Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 7. Oktober 2018, 23:04:23 CEST schrieb Stephan Hemeier:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert
Graphics Repo aktiv? zypper lr -d
zypper se -si libopenblas
Stephan
oops, war das Science Repo...... Aber egal, die Befehle werden es zeigen. Bugreport ist hier: https://lists.opensuse.org/opensuse-factory/2018-08/msg00280.html Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (9)
-
eilfh -
Herbert Albert -
Hugo -
Hugo Egon Maurer -
Maik Wagner -
Norbert Zawodsky -
Richard Kraut -
Robert Großkopf -
Stephan Hemeier