digikam in Buster defekt - was tun?

[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.