Da war doch was vor ca. zwei Jahren
Hatte zu diesem Thema schon mal was geschrieben:
OpenSUSE Leap 15 und ext4 Dateisysteme
Ist immer noch so. Ich hab mich unter 42.2 von BTRFS verabschiedet und jetzt auf allen unseren Rechnern diese BTRFS-Timer gefunden ... dabei auch einer mit ganz frisch installiertem 15.2. Dein obiger "zypper rm..."-Befehl (ohne die beiden "lvm"-Sachen) hat das dann beseitigt.
Beim Kernelupdate in Leap 15.2 werden beim Aufräumen der alten Kernels auch die grad neu installierten Pakete "kernel-devel" und "kernel-default-devel" wieder entfernt. Danach geht dann z.B. der vmware player nicht mehr. Nachinstallieren der beiden o.g. Pakete beseitigt das Problem wieder. (Das war auch beim vorigen Kernelupdate so.)
Aus der "/var/log/zypp/history":
2020-07-16 20:38:41|install|kernel-default|5.3.18-lp152.26.2|x86_64||repo-update|60677c2dabac72cc7da15c220f6ea6b0abefc8edbd0d3bd6c0c0b0d434e1bb43|
2020-07-16 20:38:41|install|kernel-macros|5.3.18-lp152.26.2|noarch||repo-update|d01612231e283e1f1ec615c9e61a2b52f60eea996171ea1d5428d99ef5c4c3a3|
# 2020-07-16 20:38:48 kernel-devel-5.3.18-lp152.26.2.noarch.rpm installed ok
# Additional rpm output:
# Changing symlink /usr/src/linux from linux-5.3.18-lp152.20.7 to linux-5.3.18-lp152.26
#
2020-07-16 20:38:48|install|kernel-devel|5.3.18-lp152.26.2|noarch||repo-update|3cd7d987150331f77e0f36ecdb37060641a4d862d25d1ff85f09599f35ad819a|
# 2020-07-16 20:38:50 kernel-default-devel-5.3.18-lp152.26.2.x86_64.rpm installed ok
# Additional rpm output:
# Changing symlink /usr/src/linux-obj/x86_64/default from ../../linux-5.3.18-lp152.20.7-obj/x86_64/default to ../../linux-5.3.18-lp152.26-obj/x86_64/default
#
2020-07-16 20:38:50|install|kernel-default-devel|5.3.18-lp152.26.2|x86_64||repo-update|edea48238e3aac8d899c159d5fb482aa2eb714b03c436063f280afb0b2ffdff2|
2020-07-16 20:38:50|patch |openSUSE-2020-935|1|noarch|repo-update|important|security|needed|applied|
2020-07-16 20:42:27|command|root@desdemona|'/usr/bin/zypper' '-n' 'purge-kernels'|
2020-07-16 20:44:23|remove |kernel-default|4.12.14-lp151.28.52.1|x86_64|root@desdemona|
2020-07-16 20:44:41|remove |kernel-default-devel|5.3.18-lp152.20.7.1|x86_64||
2020-07-16 20:44:43|remove |kernel-default-devel|5.3.18-lp152.26.2|x86_64||
2020-07-16 20:44:53|remove |kernel-devel|5.3.18-lp152.20.7.1|noarch|root@desdemona|
2020-07-16 20:44:57|remove |kernel-devel|5.3.18-lp152.26.2|noarch|root@desdemona|Die zugehörige Konfigurationsdatei "zypp.conf" enthält m.W. keine Besonderheiten:
desdemona:~ # egrep -v '^$|^#' /etc/zypp/zypp.conf
[main]
solver.dupAllowVendorChange = false
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,latest-1,runningFalls also jemand die Kernelheader braucht, sollte er/sie auf diese Pakete achten.
Aber:
Das Programm wird nicht mehr weiterentwickelt, Nachfolger ist QMapShack:
Das möchte ich unterstreichen. Der Umstieg von QLandkarteGT auf QMapShack ist schwierig, weil sich die Arbeitsabläufe sehr geändert haben. Deshalb gibt es den Versuch, das vor sechs Jahren beendete QLandkarteGT weiter lauffähig zu halten. Das sollte man aber nur benutzen, wenn man sich schon lange an QLandkarteGT gewöhnt hat und jetzt keine Zeit hat sich umzugewöhnen.
Notfalls kommt hier wieder 15.1 oder gar ein Windows 10 parallel auf die Platte, und ich warte bis Juli, oder wann auch immer die finale 15.2 herauskommen wird.
Mit der finalen 15.2 ist es auch nicht besser geworden. Aber es gibt jetzt eine Lösung (Ich hab sie gerade beim VMWare Player benutzt):
(Vgl. https://github.com/mkubecek/vm…dules/commit/64ec3716346e)
Der 5.3er Kernel in 15.2 hat Teile aus dem 5.4er Kernel. An einer Stelle benutzt vmware diese Teile entweder auf die 5.3er- oder auf die 5.4er-Art ... er kann beides. vmware fragt nach der Kernelnummer, bekommt 5.3 gesagt und macht dann genau das Falsche. Das passiert in den Teilen, die bei jedem neuen Kernel neu compiliert werden. Man muss also nur eine Ausnahme für 15.2 in den Code schreiben und den Rest erledigt vmware selbst.
/usr/lib/vmware/modules/source/vmnet.tar irgendwo auspacken
Zeile 84 von userif.c ist
#if COMPAT_LINUX_VERSION_CHECK_LT(5, 4, 0)statt dessen kommt rein:
#if COMPAT_LINUX_VERSION_CHECK_LT(5, 4, 0) && \
!(defined(CONFIG_SUSE_VERSION) && CONFIG_SUSE_VERSION == 15 && \
defined(CONFIG_SUSE_PATCHLEVEL) && CONFIG_SUSE_PATCHLEVEL >= 2)Dann wieder einpacken und das Original ersetzen. Wenn vmware dann neu compiliert sollte es danach gehen.
Warum willst du unbedingt nur das bedingt geeignete Tool "gpg" dazu verwenden?
Du hast längst ein geeignetes Tool auf deinem Rechner.
Weil gpg eigentlich das besser geeignete Tool wäre, wenn es denn eine gpg-Signatur für die iso-Datei gäbe. Wenn jemand die iso-Datei manipuliert dann muss er nur zusätzlich die Prüfsummendatei manipulieren und alles sieht wieder gut aus. Mit einem Tool wie gpg kann man so etwas nicht machen, da man den secret key des Signierenden nicht hat. Deshalb wird gpg ja zur Absicherung der Prüfsumme eingesetzt. Es wäre aber einfacher, es direkt auf die iso loszulassen.
Die Extension ".asc" bedeutet lediglich ASCII.
Da schon lange alles via UTF-8 läuft, brauchst du sowas gar nicht.
Das hat nichts mit UTF-8 zu tun. gpg kann Dateien im Binärformat oder aus Zeichen bestehend erzeugen. Letztere enden defaultmäßig mit ".asc".
Warum diese Vorgehensweise und nicht einfach das ISO mit gpg signieren?
Die Signatur des ISOs sagt nichts darüber aus, ob das ISO irgendwelche Fehler enthält. Diese Fehler können durch den Download (99,99%) bzw. aber auch durch Manipulation entstehen.
Deswegen wird nicht das ISO signiert, sondern nur die Checksummendatei, denn wenn das ISO manipuliert wird, stimmt die Checksumme nicht mehr......
Mit der Signatur ist die Checksummendatei gegen Manipulation geschützt.
Glaub ich nicht. Genauso wie die gpg-Signatur der Checksummendatei diese gegen Manipulation schützt, würde auch eine gpg-Signatur der ISO-Datei diese gegen Manipulation schützen. Und man hätte dann keine richtigen aber irreführenden OK-Meldungen von gpg bei maniplierten ISO-Dateien.
Was die Sache nicht wirklich klarer macht
Doch. Mühsam ernährt sich das Eichhörnchen 
Kein anderes installiertes Paket hat also nach diesem Paket verlangt. Leap 15.1 hat also keinen Grund, dieses Paket anzufordern. Bist Du Dir sicher, dass die Aufforderung vom Leap 15.1 und nicht von einem der installierten Programme kommt?
(Aber am Besten stellen wir diesen Teil erstmal zurück bis das BTRFS wieder sauber ist.)
Wie krieg ich raus, um welche Software es sich handelt? Ist das Texlive?
Ziel ist es, nur mit westlichen Schriften zu arbeiten und weitere Installationsanfragen vom System zu vermeiden.
Du kannst bei den einzelnen Paketen nachsehen, welche anderen Pakete ihre Installation verlangt haben. Für texlive-padauk-fonts wäre das:
rpm -q --whatrequires texlive-padauk-fonts
Da ich "padauk" nicht habe gehe ich das mal für "romanian" durch:
rpm -q --whatrequires texlive-babel-romanian
gibt aus:
texlive-collection-langeuropean-2017.135.svn44414-lp151.8.6.1.noarch
rpm -q --whatrequires texlive-collection-langeuropean
gibt aus:
texlive-scheme-medium-2017.135.svn44177-lp151.8.6.1.noarch
rpm -q --whatrequires texlive-scheme-medium
gibt aus:
no package requires texlive-scheme-medium
Dass ich "romanian" drin habe liegt also daran, dass ich "texlive-scheme-medium" installiert habe und dadurch kommt die Sammlung europäischer Sprachen rein und dadurch rumänisch.
Vermutlich hast Du also das falsche "scheme" ... z.B. "texlive-scheme-full". Du kannst im Yast bei Software nach "texlive-scheme" suchen. Wenn Du da was änderst dann werden aber nur dann abhängige Sachen mit deinstalliert, wenn Du bei den Optionen "Bereinigen beim Löschen von Paketen" auswählst.
Das, was Du ursprünglich wolltest, geht aber auch. "kwallet deaktivieren" geht unter "Einstellungen" "Systemeinstellungen" "Benutzerkontodetails" "Passwortspeicher" und da bei "KDE-Passwortspeicher-System aktivieren" den Haken wegmachen. Das gilt dann aber generell und nicht nur fürs WLAN ... genauso wie bei der Lösung mit dem leeren kwallet-Passwort.
Der Networkmanager trägt die Passworte dann direkt im Klartext in die zuständige Datei (/etc/NetworkManager/system-connections/xxx) ein. Diese Dateien sind nur für root lesbar.
(Mit der rechten Maustaste auf dem WLAN-Symbol in der Fußleiste kannst Du auch noch Sachen wie "gilt für alle User" und "nicht automatisch benutzen" und ein paar andere Details festlegen.)
