digikam in Buster defekt - was tun?

[spiralnebelverdreher]

Hallo zusammen,
nach dem Upgrade auf Buster habe ich Probleme mit digikam, die leider so schwerwiegend sind, dass der interne Bild-Editor öfters nicht mehr arbeitet und auch weitere Probleme bestehen. Das Problem ist seitens digikam gefixed und ich will nun die derzeit stabile Version 6.4 von digikam (bspw. aus debian testing) nutzen.
Wenn ich recht sehe, kann ich dies durch Apt Pinning erreichen, durch Selbstkompilieren oder als AppImage. Backports scheint es dazu keine zu geben. Welchen Weg würde ihr mir raten unter den Randbedingungen: Älterer Rechner mit XFCE-Desktop (KDE-Teile habe ich nur wegen digikam), möglichst viel debian stable erhalten, unerwartete Versionsänderungen von digikam sollen vermieden werden und performant soll es auch laufen, da die Bilderzahl inzwischen sehr groß ist (Probleme bei AppImage zu erwarten?)?

Vielen Dank

spiralnebelverdreher

Code: Alles auswählen

CPU: Dual Core Intel Core2 Duo E8400 (-MCP-) 
speed/min/max: 2000/2000/3000 MHz Kernel: 4.19.0-9-amd64 x86_64 Up: 1h 57m 
Mem: 1578.5/7977.4 MiB (19.8%) Storage: 3.40 TiB (4.5% used) Procs: 194 
Shell: bash 5.0.3 inxi: 3.0.32 

[Blackbox]

Mit reportbug einen Bugreport zu erstellen, wäre zu einfach?
Du würdest damit sicherlich auch anderen Nutzern helfen.

[spiralnebelverdreher]

Mit reportbug einen Bugreport zu erstellen, wäre zu einfach?
Du würdest damit sicherlich auch anderen Nutzern helfen.

Wenn ich es recht sehe, enthält mein Link oben einen schon existierenden Bugreport (https://bugs.debian.org/cgi-bin/bugrepo ... bug=931830).

[willy4711]

Ich glaube nicht, dass du die Version aus Testing in Stable installiert bekommst, ohne dir dein System zu zerschießen.
Sind auf den ersten Blich zu viele Abhängigkeiten.
Es gibt aber ein AppImage:
https://www.digikam.org/download/

[debianoli]

Das müsste eigentlich schon klappen mit Pinning, die Abhängigkeiten sind von den Versionsnummern auf den ersten Blick auch in Buster erfüllt.

[willy4711]

Das müsste eigentlich schon klappen mit Pinning, die Abhängigkeiten sind von den Versionsnummern auf den ersten Blick auch in Buster erfüllt.

Das gibt einen Rattenschwanz von Abhängigkeiten, abgesehen davon dass z.B. libgcc-s1 samt Abhängigkeiten nur in Testing vorhanden ist. Aber probieren geht über Studieren
Testing:

Code: Alles auswählen

apt depends digikam
digikam
  Hängt ab von: digikam-private-libs (= 4:6.4.0+dfsg-3)
  Hängt ab von: libc6 (>= 2.14)
  Hängt ab von: libgcc-s1 (>= 3.0)
  Hängt ab von: libkf5configcore5 (>= 4.97.0)
  Hängt ab von: libkf5coreaddons5 (>= 4.100.0)
  Hängt ab von: libkf5i18n5 (>= 4.97.0)
  Hängt ab von: libmagick++-6.q16-8
  Hängt ab von: libqt5core5a (>= 5.12.2)
 |Hängt ab von: libqt5gui5 (>= 5.4.0)
  Hängt ab von: libqt5gui5-gles (>= 5.4.0)
  Hängt ab von: libqt5sql5 (>= 5.4.0)
  Hängt ab von: libqt5widgets5 (>= 5.4.0)
  Hängt ab von: libstdc++6 (>= 4.1.1)
  Hängt ab von: <perl:any>
    perl
  Hängt ab von: libqt5sql5-sqlite
  Hängt ab von: libqt5sql5-mysql
  Hängt ab von: digikam-data (= 4:6.4.0+dfsg-3)

Stable

Code: Alles auswählen

apt depends digikam
digikam
  Hängt ab von: digikam-private-libs (= 4:5.9.0-1+b1)
  Hängt ab von: libc6 (>= 2.14)
  Hängt ab von: libgcc1 (>= 1:3.0)
  Hängt ab von: libkf5configcore5 (>= 4.97.0)
  Hängt ab von: libkf5coreaddons5 (>= 4.100.0)
  Hängt ab von: libkf5filemetadata3 (>= 5.1.0.1)
  Hängt ab von: libkf5i18n5 (>= 4.97.0)
  Hängt ab von: libqt5core5a (>= 5.11.0~rc1)
  Hängt ab von: libqt5gui5 (>= 5.4.0)
  Hängt ab von: libqt5sql5 (>= 5.4.0)
  Hängt ab von: libqt5widgets5 (>= 5.4.0)
  Hängt ab von: libstdc++6 (>= 4.1.1)
  Hängt ab von: <perl:any>
    perl
  Hängt ab von: libqt5sql5-sqlite
  Hängt ab von: libqt5sql5-mysql
  Hängt ab von: digikam-data (= 4:5.9.0-1)
  Hängt ab von: kipi-plugins (= 4:5.9.0-1+b1)

[kalle123]

Seltsam, digikam ist ein MUSS für mich und ich sehe die Probleme mit 5.9.0 unter Buster Xfce hier nicht.

Naja, vielleicht Glück gehabt ....

cu KH

[debianoli]

Das müsste eigentlich schon klappen mit Pinning, die Abhängigkeiten sind von den Versionsnummern auf den ersten Blick auch in Buster erfüllt.

Das gibt einen Rattenschwanz von Abhängigkeiten, abgesehen davon dass z.B. libgcc-s1 samt Abhängigkeiten nur in Testing vorhanden ist. Aber probieren geht über Studieren

Hatte das vorhin als Tipp geschrieben, da ich nur die reinen Abhängigkeiten von digikam betrachtet habe. Wie gesagt, man kann probieren, ob es bei herabgesetzten Versionsnummern der Abhängigkeiten im deb nach dem Installieren läuft.

Ansonsten wird es wegen der Abhängigkeiten schwierig, da einige Pakete unbedingt aktuellere aus dem Bereich Kompiler oder libc6 benötigen. Das ist immer sehr schlecht und sollte dringend vermieden werden. Sonst bleibt irgendwann nur noch der Upgrade auf Testing als Lösung, wenn nichts mehr geht.

Code: Alles auswählen

apt-get install digikam digikam-private-libs -t testing
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 digikam-private-libs : Hängt ab von: libopencv-objdetect4.2 (>= 4.2.0+dfsg) soll aber nicht installiert werden
 libc6-dev : Beschädigt: libgcc-8-dev (< 8.4.0-2~) aber 8.3.0-6 soll installiert werden

Code: Alles auswählen

apt install libopencv-objdetect4.2 -s
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libopencv-objdetect4.2 : Hängt ab von: libopencv-highgui4.2 (= 4.2.0+dfsg-6) soll aber nicht installiert werden
                          Hängt ab von: libopencv-ml4.2 (= 4.2.0+dfsg-6) soll aber nicht installiert werden
                          Hängt ab von: libc6 (>= 2.29) aber 2.28-10 soll installiert werden
                          Hängt ab von: libgcc-s1 (>= 3.0) soll aber nicht installiert werden
                          Hängt ab von: libopencv-calib3d4.2 (>= 4.2.0+dfsg) soll aber nicht installiert werden
                          Hängt ab von: libopencv-core4.2 (>= 4.2.0+dfsg) soll aber nicht installiert werden
                          Hängt ab von: libopencv-imgproc4.2 (>= 4.2.0+dfsg) soll aber nicht installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

[Blackbox]

Wenn ich es recht sehe, enthält mein Link oben einen schon existierenden Bugreport (https://bugs.debian.org/cgi-bin/bugrepo ... bug=931830).

Es gibt nun mehrere Möglichkeiten, mit denen ich bereits gute Erfahrungen gesammelt habe.

• Du könntest den bestehenden Bugreport mit relevanten Informationen (so wie es reportbug auch in seinem Template vorschlägt) ergänzen.
• Du könntest den Maintainer direkt anschreiben und nachfragen, warum er das Problem nicht fixt, oder eine neuere Version von digikam ausrollt.
• Vielleicht konntest du das Problem bereits durch Debugging isolieren und könntest den Maintainern wertvolle Informationen zukommen lassen, die dein Problem besser beschreiben.
• Oder du bist Entwickler und kannst einen Patch anbieten?

Möglichkeiten über Möglichkeiten ...

[willy4711]

Es gibt nun mehrere Möglichkeiten, mit denen ich bereits gute Erfahrungen gesammelt habe.

Du könntest den bestehenden Bugreport mit relevanten Informationen (so wie es Debianreportbug auch in seinem Template vorschlägt) ergänzen.
Du könntest den Maintainer direkt anschreiben und nachfragen, warum er das Problem nicht fixt, oder eine neuere Version von Debiandigikam ausrollt.
Vielleicht konntest du das Problem bereits durch Debugging isolieren und könntest den Maintainern wertvolle Informationen zukommen lassen, die dein Problem besser beschreiben.
Oder du bist Entwickler und kannst einen Patch anbieten?

Warum sollte er einen Bugreport schreiben, wenn der Fehler längst behoben ist, und die "schadhafte" Version seit 2018 in Stable rungeistert(https://tracker.debian.org/pkg/digikam)?

Aus:
https://bugs.kde.org/show_bug.cgi?id=409686#c2
Habe es mal Übersetzen lassen:

Maik Qualmann 10.07.2019 17:48:20 UTC

Dieses Problem wurde in späteren Versionen von digiKam definitiv behoben. Während der ersten Dateiscan ausgeführt wurde, wurde die Datenbank mit denselben Informationen extrem häufig in der Schleife abgefragt und blockiert. Ich schließe den Fehler.

Noch ein Hinweis: Das "neue" Debian 10 verwendet keine aktuelle Version von digiKam. Siehe auch Ihren anderen Fehler, der vor einem Jahr gemeldet wurde und längst behoben wurde.

Maik

[RobertS]

Fehler in einzelnen Paket upstream zu melden bringt leider gar nix. Debian geht oft eigene Wege, der passende Ansprechpartner ist der Debian Betreuer. Etwas verwundert bin ich aber schon daß der schon lange bekannte Fehler immer noch existiert. Das Qualitätsmanagement scheint Mängel zu haben.

Nachtrag: die 7er Version aus experimental läuft bei mir Störungsfrei.

[Blackbox]

Fehler in einzelnen Paket upstream zu melden bringt leider gar nix.

Richtig, schon gar nicht, wenn die Version wie in Debian Stable längst veraltet ist.

Debian geht oft eigene Wege, der passende Ansprechpartner ist der Debian Betreuer.

Etwas verwundert bin ich aber schon daß der schon lange bekannte Fehler immer noch existiert. Das Qualitätsmanagement scheint Mängel zu haben.

Manch ein Maintainer benötigt eine Extra-Einladung, oder hat den Bugreport schlicht übersehen?
Das kann, muss aber nicht auf ein schlechtes Fehlermanagement hinweisen.

Nachtrag: die 7er Version aus experimental läuft bei mir Störungsfrei.

Diese Information gehört an den bestehenden Bugreport geschickt, das erspart dem Maintainer etwas Zeit beim Suchen einer lauffähigen Versin, die dann in stable ausgerollt werden könnte.

Warum sollte er einen Bugreport schreiben, wenn der Fehler längst behoben ist, und die "schadhafte" Version seit 2018 in Stable rungeistert(https://tracker.debian.org/pkg/digikam)?

Nur um sicherzustellen, dass du mich auch richtig verstanden hast.
Er sollte keinen Bugreport im KDE Bugtracker erstellen, sondern mit dem Bugreport den Debian Maintainer wecken.
Da dieser Fehler bereits länger existiert, ist es möglich, dass dieser vom Maintainer übersehen wurde.
Und sag jetzt nicht, das passiert nicht, manchen einen Maintainer (ich nenne hier absichtlich keine Namen) muss man gern ein zweites, oder drittes Mal über einen Bug in seinen betreuten Paketen informieren.
Ich schreibe als Debian unstable Anwender öfter mal einen Bugreport, da lernt man die Vorlieben einzelner Maintainer recht gut kennen.

[spiralnebelverdreher]

Seltsam, digikam ist ein MUSS für mich und ich sehe die Probleme mit 5.9.0 unter Buster Xfce hier nicht.

Naja, vielleicht Glück gehabt ....

cu KH

Die Probleme sind tatsächlich nicht auf den allerersten Blick sichtbar. Ich bin darauf gestoßen, als ich munter Bilder markierte, kopierte und bearbeitete. Etwa beim vierten Bild wurde in der Bearbeitung (F4, Edit) kein Bild mehr angezeigt, die Menüleiste fehlte und nach Schließen des Edit-Fensters war in digikam plötzlich eine rechte neue Side-Bar vorhanden mit den Reitern der Bildeigenschaften (Eigenschaften, Metadaten, etc). Schließen der Anwendung und Neustart brachte keine Änderung. Am Foto selbst liegt es nicht, mit Gimp kann zum Beispiel gearbeitet werden. Seltsam fand ich auch, dass digikam laut pstree 48 Threads gestartet hatte.

Du kannst es ja mal selbst ausprobieren - ich würde das aber nur mit aktuellem Backup im Rücken wagen (alle Alben, alle DBs sowie digikamrc). Vielleicht ist dein Rechner auch performanter als meiner und kann mit der Vielzahl von Threads besser umgehen.

[spiralnebelverdreher]

Warum sollte er einen Bugreport schreiben, wenn der Fehler längst behoben ist, und die "schadhafte" Version seit 2018 in Stable rungeistert(https://tracker.debian.org/pkg/digikam)?

Nur um sicherzustellen, dass du mich auch richtig verstanden hast.
Er sollte keinen Bugreport im KDE Bugtracker erstellen, sondern mit dem Bugreport den Debian Maintainer wecken.
Da dieser Fehler bereits länger existiert, ist es möglich, dass dieser vom Maintainer übersehen wurde.
Und sag jetzt nicht, das passiert nicht, manchen einen Maintainer (ich nenne hier absichtlich keine Namen) muss man gern ein zweites, oder drittes Mal über einen Bug in seinen betreuten Paketen informieren.
Ich schreibe als Debian unstable Anwender öfter mal einen Bugreport, da lernt man die Vorlieben einzelner Maintainer recht gut kennen.

Ok, der Argumentation von Schwarzkiste kann ich prinzipiell was abgewinnen, aber ist das in meinem Fall (nutze derzeit kein unstable) zielführend im Sinne einer Änderung in stable? Ich nutze digikam schon sehr lange und hatte immer den Eindruck, dass digikam sehr schnell mit neuen Features weiter entwickelt wird, dass aber die Integration in die debian-Welt vernachlässigt wird (wird ja in dem debian bugreport deutlich thematisiert). Wer da welchen Anteil hat, wo es Holschuld und Bringschuld gibt kann ich nicht beurteilen.
Würde mein Bugreport eine wichtige technische und bis dahin unbekannte Information enthalten? Wohl kaum. Würde mein Bugreport dazu beitragen, die Awareness des Maintainers beim nächsten Übergang von Testing zu Stable erhöhen?

[RobertS]

…Würde mein Bugreport eine wichtige technische und bis dahin unbekannte Information enthalten? Wohl kaum. Würde mein Bugreport dazu beitragen, die Awareness des Maintainers beim nächsten Übergang von Testing zu Stable erhöhen?

Den Schuh muß ich mir leider auch anziehen, viel zu selten beschwer ich mich.
Das Problem ist eben, ohne Rückmeldung kann schon mal was übersehen werden.
Bisher hab ich nur einmal herausgefunden an wen ich einen Bugreport schicken muß
An reportbug bin ich auch schon gescheitert, da fehlen mit ab und an Fremdsprachenkenntnisse. Mein Paradebeispiel über das ich mich heute noch aufrege war eine lateinische Abkürzung in einer englischsprachigen Datei zum x-server.
Als Angehöriger der bildungsprekären Gruppe "der hat ja nichtmal Abitur" fühlt man sich da schon aktiv zur Tür begleitet.

[spiralnebelverdreher]

…Würde mein Bugreport eine wichtige technische und bis dahin unbekannte Information enthalten? Wohl kaum. Würde mein Bugreport dazu beitragen, die Awareness des Maintainers beim nächsten Übergang von Testing zu Stable erhöhen?

Den Schuh muß ich mir leider auch anziehen, viel zu selten beschwer ich mich.
Das Problem ist eben, ohne Rückmeldung kann schon mal was übersehen werden.
Bisher hab ich nur einmal herausgefunden an wen ich einen Bugreport schicken muß
An reportbug bin ich auch schon gescheitert, da fehlen mit ab und an Fremdsprachenkenntnisse. Mein Paradebeispiel über das ich mich heute noch aufrege war eine lateinische Abkürzung in einer englischsprachigen Datei zum x-server.
Als Angehöriger der bildungsprekären Gruppe "der hat ja nichtmal Abitur" fühlt man sich da schon aktiv zur Tür begleitet.

Es ist sehr schade, dass manchmal die Eingeweihten nur in ihrer Insider-Sprache kommunizieren und damit für Rückmeldungen der "normalen" Nutzer eine hohe Hürde aufbauen. Das schadet dem Kernanliegen selbst.
Gerade bei einem Projekt wie digikam sind die Randbedingungen schwierig: Viele Kameramodelle, unveröffentlichte Spezifikation einiger Internas, intensive Nutzung von Datenbanken und regelmäßig notwendig werdende Migrationen der Datenbanken, funktionaler Zuwachs, ... . Dieser Mischmasch ist nicht einfach zu beherrschen und gute Fehlerbeschreibungen sind hilfreich.

[Blackbox]

Diese Seite [0] ist recht hilfreich, um einen Debian Bugreport zu erstellen, hilft dir das?

[0] https://www.debian.org/Bugs/Reporting

[retabell]

und ich will nun die derzeit stabile Version 6.4 von digikam (bspw. aus debian testing) nutzen.
Wenn ich recht sehe, kann ich dies durch Apt Pinning erreichen, durch Selbstkompilieren oder als AppImage. Backports scheint es dazu keine zu geben.

zum Selbstkompilieren;
digikam_6.4.0 satisfydepends-dummy :

Depends: libexiv2-dev (>= 0.27) but it is not going to be installed
Depends: libqtav-dev (>= 1.13) but it is not going to be installed

sieht auf den ersten Blick nicht so kompliziert aus.....

qtav lässt sich so bauen
exiv2 bricht ab mit Warnung

dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libexiv2-27/DEBIAN/symbols doesn't match completely debian/libexiv2-27.symbols

in debian/rules folgende Zeile einfügen

Code: Alles auswählen

export DPKG_GENSYMBOLS_CHECK_LEVEL=0

dann baut auch exiv2

nun sollte auch digikam_6.4.0 gebaut werden können, aber...
ergibt nen Fehler bei opencv ?Bug in Debian oder Upstream digikam

also auch opencv aus bullseye
das braucht aber gdcm, das vorher bauen

dann gibt es noch einen Fehler beim bauen, das dwz aus buster hat auch nen Bug (behoben in buster)
also den aus bullseye bauen.

Zusammengefasst in folgender Reihenfolge bauen:

Code: Alles auswählen

qtav exiv2 gdcm dwz opencv digikam

Daraus ist auch ersichtlich warum der digikam Maintainer nicht so einfach ne neuere Version ausrollen kann, exiv2 braucht nen sauberen bpo
und digikam baut so auch nur gegen die neueren libs.

auf kanotix.com hab ich Pakete als bpo für amd64 und i386 hochgeladen,
falls wer Interesse hat, oder keine Lust hat selbst zu bauen.

gruss retabell

[Blackbox]

Daraus ist auch ersichtlich warum der digikam Maintainer nicht so einfach ne neuere Version ausrollen kann, exiv2 braucht nen sauberen bpo
und digikam baut so auch nur gegen die neueren libs.

Vielleicht solltest du darüber nachdenken, ein KDE Maintainer im Debian Projekt zu werden?

auf kanotix.com hab ich Pakete als bpo für amd64 und i386 hochgeladen, falls wer Interesse hat, oder keine Lust hat selbst zu bauen.

Das ist doch Community-Arbeit wie man sie sich wünscht.

Ich nutze zwar kein KDE/Plasma und auch keine Qt Anwendungen, weiß aber deine Bemühungen trotzdem zu schätzen.