[DE] kup, bup - wo sind die Einstellmöglichkeiten in Plasma 6

[paco]

Seit der Neuinstallation auf der Basis des Images vom 26.12.2024 fehlt hier die Möglichkeit, die automatischen Backups mittels kup zu konfigurieren, z. B. in den KDE-Systemeinstellungen.

Die Backups selbst laufen wohl aufgrund alter Einstellungen nach wie vor.

Kann das wirklich nur noch "zu Fuß" z. B. in der Datei .config/kuprc eingestellt werden?

[der_bud]

Hab' hier gerade kein Siduction parat, auf einem Arch mit KDE/Plasma 6 ist ohne spezielle Nachinstallation eines kcm$foo der Eintrag "Sicherungen" vorhanden: in den Systemeinstellungen, links im Baum ganz unten als letztes im  Abschnitt "System".
Ansonsten mal händisch probieren, im Terminal 'kcmshell6 kcm_kup' aufrufen.

[paco]

@ der_bud: Danke für Deine Bemühungen.

In den Systemeinstellungen findet sich dieser Eintrag leider nicht und auch kein annähernd ähnlich klingender.
Und Dein Tip bestätigt leider nur das Problem:

Code: [Select]

$ kcmshell6 kcm_kup
kf.kcmutils: Could not find KCM with given Id "kcm_kup"
kf.coreaddons: "Could not find plugin kcm_kup"
kf.coreaddons: "Could not find plugin kcm_kup"

Hilft das weiter?

Code: [Select]

# dpkg -L kup-backup | grep kcm
/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_kup.so
/usr/share/kservices5/kcm_kup.desktop


Code: [Select]

# find / -iname kcm_kup*
/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_kup.so
/usr/share/kservices5/kcm_kup.desktop

Fehlt da nur ein Link oder ist da noch ein anderer Wurm drin?

Das Löschen von kup_backup und dessen Neuinstallation hat leider auch nicht geholfen.

[devil]

Da fehlt anscheinend das kcm-modul für Backups in den Systemeinstellungen. Ist das vorhanden, dann gibt es den Unterpunkt 'Sicherungen' Das kcm mit dem Namen kcm_kup scheint derzeit in Debian nicht verfügbar zu sein, wie der Befehl

Code: [Select]

kcmshell6 --list zeigt. Bei Ubuntu gibt es das Modul allerdings, also liegt es nicht an Plasma 6. Ich versuche mal zu ergründen, woran es liegt.

[der_bud]

Hm, auf 'nem Siduction System liegen die Dateien für kc,_kup unter

/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_kup.so
/usr/share/kservices5/kcm_kup.desktop

Also Pfade für qt5/kf5. Darauf greift kcmshell6 nicht zu, kcmshell5 ist nicht (mehr?) parallel installiert, vor einiger Zeit im Übergang war mal beides da. Siehe auch Bugreport bei Debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091413 "Switch kup-backup to use Qt 6 / Kf 6"

[paco]

kcm_cup ist in der ISO vom 26.12. tatsächlich leider nicht enthalten!
@devil: Danke fürs "Nachbohren"

[devil]

Laut KDE-Entwickler kann das noch ein wenig dauern. Wenn du schnell was brauchst, kann ich die Duplicati empfehlen. Das sichert mir nachts mehrere TB an Media-Daten aus Unraid.

[paco]

Duplicati schau ich mir mal an.

Zum Glück hat es aber keine Eile weil die Backups mit der "geretteten" alten Konfiguration wohl noch wie gehabt erstellt werden.

Danke und viele Grüße aus dem schwarzen Süden ;-) nach Brandenburg

[Teriarch]

For the impatient:

Code: [Select]

#!/usr/bin/bash
pushd .
sudo apt-get update
mkdir /tmp/kup
mkdir /tmp/kup_tmp
cd /tmp/kup
wget http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu/pool/main/k/kup-backup/kup-backup_0.10.0-0ubuntu1~24.10~ppa1_amd64.deb
kupdeb=$(ls /tmp/kup/*.deb|sed -e 's/_0.10.0-0ubuntu1~24.10~ppa1/_0.10.0-0~b/g')
kupver=0.10.0-0~b
mv /tmp/kup/*.deb $kupdeb
dpkg-deb -x $kupdeb /tmp/kup_tmp
dpkg-deb --control $kupdeb /tmp/kup_tmp/DEBIAN
sed -i -e 's/libgit2-1.7/libgit2-1.8/g' /tmp/kup_tmp/DEBIAN/control
sed -i -e 's/Version: 0.10.0-0ubuntu1~24.10~ppa1/Version: '$kupver'/g' /tmp/kup_tmp/DEBIAN/control
dpkg-deb --root-owner-group -b /tmp/kup_tmp $kupdeb
cd /usr/lib/x86_64-linux-gnu/
sudo ln -s libgit2.so.1.8 libgit2.so.1.7
cd /tmp/kup
sudo dpkg -i $kupdeb
cd /tmp
rm -rf /tmp/kup /tmp/kup_tmp
popd
Save the code to a file, chmod 755 the file, make the current user a sudoer and execute the script.
This way you have the current 0.10.0-0 kubuntu version running on Debian's kcmshell6. If the Debian
developers decide to upgrade their outdated  0.9.1-2 version this intermediate version will be replaced.

[paco]

@Teriarch: Whow, ich bin beeindruckt. und sage laut DANKE und complimenti!

Ich habe aber keine Eile, werde ich es in einer virtuellen Maschine jedoch ausprobieren.

Gibt es einen nachvollziehbaren Grund, wieso das unter Debian noch hakt?

[Teriarch]

@paco:

> Gibt es einen nachvollziehbaren Grund, wieso das unter Debian noch hakt?

Ich nehme an, das Debian Entwicklerteam ist noch nicht dazu gekommen. Und natürlich
muss man jeder dankbar sein, die ihre unbezahlte Zeit dafür opfert, die
aktuellen Sourcen in das Paketmanagement zu integrieren und alles konsistent
zu halten ("We are standing on the shoulders of Giants").

Das Kubuntu 0.10.0-0ubuntu1~24.10~ppa1 Release ist ein Backport vom 13.11.2024,
und ich habe es vor der Anpassung auf Abhängigkeitsprobleme mit Debian unstable
überprüft (Das muss man ebenfalls automatisieren, da eine manuelle Überprüfung zu
fehleranfällig ist). Als Referenz habe ich das Shine-On Iso Image genommen. Von einer
abgesehen waren alle Abhängigkeiten erfüllt (Ansonsten ergibt es keinen Sinn weiterzumachen,
da die Konsistenzerhaltung zu aufwändig wird):

kub-backup hängt von libgit2-1.7 ab, aber auf unstable ist libgit2-1.8 installiert (Bei
Kubuntu sind sie wohl auch nicht immer auf dem neuesten Stand, ;-() mit folgender
Konsequenz:

$ ldd /usr/bin/kup-filedigger|grep git:
libgit2.so.1.7 => not found

Und wie erwartet:

$ ls -la /lib/x86_64-linux-gnu/libgit2*:
lrwxrwxrwx 1 root root      16 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8 -> libgit2.so.1.8.4
-rw-r--r-- 1 root root 1229416 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8.4

Ich ging davon aus, dass die Versionsänderung der shared Library von 2.1.7 auf 2.1.8
abwärtskompatibel zu den verwendeten APIs ist, deswegen die Einfügung des sybolischen Links:

$ sudo ln -s libgit2.so.1.8 libgit2.so.1.7

mit der Konsequenz

$ ldd /usr/bin/kup-filedigger|grep git
libgit2.so.1.7 => /lib/x86_64-linux-gnu/libgit2.so.1.7 und schließlich

$ ls -la /lib/x86_64-linux-gnu/libgit2*
lrwxrwxrwx 1 root root      14  9. Feb 00:58 /lib/x86_64-linux-gnu/libgit2.so.1.7 -> libgit2.so.1.8
lrwxrwxrwx 1 root root      16 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8 -> libgit2.so.1.8.4
-rw-r--r-- 1 root root 1229416 27. Nov 23:26 /lib/x86_64-linux-gnu/libgit2.so.1.8.4

Die Erfüllung der Abhaängigkeiten ist zwar notwendig, aber nicht hinreichend für die Funktionalität
(wg. unresolved symbols), aber die geringfügige Versionsänderung ließ mich wie gesagt zuversichtlich
sein.

Ich habe alles an einem kleinen Backup überprüft und kein unerwartetes Verhalten beobachtet. Aus
urheberrechtlichen Gründen sollte jeder das vom Skript modifizierte Paket nur privat installieren und
nicht weitergeben. Wie lange dieses Paket mit dem Paketmanagement von Debian kompatibel bleibt, kann
ich nicht sagen. Schlimmstenfalls wird es bei einem zukünftigen Update wiederr entfernt.

> [...], werde ich es in einer virtuellen Maschine jedoch ausprobieren.

Das empfehle ich auch immer. Und vor allem sollte man niemals ein executable ausführen,
dessen Verhalten man nicht übersieht (es sei denn, man erhält es von vertrauenswürdiger Quelle).

Man kann das Skript auch Zeile für Zeile auf der virt. Machine ausführen, um besser zu verstehen,
was es macht, bevor man es auf einem Produktivsystem laufen lässt.

HTH