Beiträge von TheFan1968

Nun. Durch das Editieren der Datei /usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/metadata.desktop kann man immerhin erreichen, das bis zu einem Update des Pakets pk-updates wieder alles hübsch schweigt.

Dazu ist aus

X-Plasma-NotificationArea=true

ganz schlicht

X-Plasma-NotificationArea=false

zu machen.

Zudem habe ich das Paket in Yast geschützt, so dass ich mir kein unbeabsichtigtes Eigentor schieße, wenn ich meine Updates, wie üblich, einmal im Monat "per Hand" mache...

Für's Erste ist mir das auch genug.
Allerdings werde ich trotzdem noch weiter nachforschen, wo Plasma diese Dienste startet, denn das wäre sicherlich die bessere Stelle zum Abschalten.
Und weiterhin werde ich mal den KDE-Entwicklern auf die Pelle rücken.
Kann ja nun nicht sein, dass das Ding nicht mal eine geänderte Konfiguration abspeichert...

Sorry für das Doppelposting, ich hab nicht aufgepasst... *schäm*

Nun...zumindest lässt sich das Plasmoid zum Schweigen bringen indem man die Datei
/usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/metadata.desktop
editiert und dort aus

X-Plasma-NotificationArea=true

einfach

X-Plasma-NotificationArea=false

macht.

Das ist aber nur ein Lösung, die bis zum nächsten Update reicht, bei dem pk-updates neu eingespielt wird.

Ich setze jetzt einfach mal noch in der schon weiter oben genannten Datei main.xml auch mal die gewünschten Optionen und gucke mir mal nach einem Neustart an, was da passiert...

Zitat von Sauerland

Deinstalliere:
plasma5-pk-updates und plasma5-pk-updates-lang

Wo die Daten dafür abgelegt werden, kann ich dir nicht sagen..........

Das war doch jetzt echt hilfreich...

Ich habe immer nach apper oder packagekit gesucht, auf diesen Paketnamen bin ich gar nicht gekommen...

Unter dem Pfad /usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/config existiert die Datei main.xml, die schon gut nach dem Krachmacher aussieht:

<?xml version="1.0" encoding="UTF-8"?>
<kcfg xmlns="http://www.kde.org/standards/kcfg/1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.kde.org/standards/kcfg/1.0
      http://www.kde.org/standards/kcfg/1.0/kcfg.xsd" >
  <kcfgfile name=""/>


  <group name="General">
    <entry name="daily" type="Bool">
      <default>true</default>
    </entry>
    <entry name="weekly" type="Bool">
      <default>false</default>
    </entry>
    <entry name="monthly" type="Bool">
      <default>false</default>
    </entry>
    <entry name="check_on_mobile" type="Bool">
      <default>false</default>
    </entry>
    <entry name="check_on_battery" type="Bool">
      <default>false</default>
    </entry>
  </group>


</kcfg>

Mal schauen ob ich hier fündig werde...

Ich fände es toll wenn das Ding einfach geht, anstatt es zu deinstallieren...

Irgendwo muss es ja schließlich gestartet/konfiguriert sein...

Zitat von Sauerland

Rechtsklick auf das Update-Applet in dem Systemabschnitt der Kontrollleiste.

DAS wäre nun zu schön, aber "Einstellungen für Software-Updates" die sich da auftun, bieten nur zwei Optionen:
- Wann das Ding nach Updates sucht (hält sich dann aber null an die gewählte Einstellung).
- Mit welchem Kurzbefehl ich den Nervtöter sichtbar machen kann.

Irgendwer muss das Ding aber mal als Demon gestartet haben und diesen Punkt zum Deaktivieren kann ich nicht finden..

Ich vermute mal die KDE selbst wird das Ding anschalten...

Hallo zusammen!

Ich bin gerade erstaunt darüber, dass ich als durchaus erfahrener Nutzer von openSUSE keinen Weg finde, dass nervige Software-Update-Programm aus der Task-Leiste entweder abzuschalten oder zumindest dazu zu bewegen, wie in seiner Konfiguration angegeben, nur einmal im Monat zu checken und nicht alle zwei Stunden zu nerven...

Version ist openSUSE Leap mit KDE, der Verursacher ist offenbar packagekitd.

Kann mir jemand da in die Spur helfen?

Vielen Dank!

Der Fehler beginnt hier offensichtlich schon nach der Instalation des Betriebssystems:
Wenn man ein Linux installiert hat, lädt man in 95% der Fälle nicht einfach irgendwo was runter und installiert es, sondern nutzt die vorhandenen Software-Repositories.

Die Schwierigkeit bei openSUSE und dem nvidia-Treiber ist, dass es im Normalfall gar keine Schwierigkeit ist:
Nach der Installation des Betriebssystems fährt man das System einfach hoch und ruft die Systemverwaltung auf und fügt das passende nvidia-Repository hinzu...

Die einzelnen Schritte dafür habe ich in meinem Blog beschrieben und auch wenn da openSUSE 13.1 davor steht, ist das auch heute noch so gültig.
Den Blog-Artikel findet ihr hier:
http://fachinformatrix.blogspo…rafiktreiber-fur-131.html

Das passende openSUSE-Repository für nvidia-Treiber ist auch online zu finden:
https://de.opensuse.org/Paket_…4re_NVIDIA-Grafik-Treiber

Wer unbedingt den Treiber aus dem Internet installieren will, findet hier eine Anleitung:
http://fachinformatrix.blogspo…ed-und-ewig-grut-der.html
Wichtig dabei ist vor allem der Zeitpunkt, zu dem man die Konsole benutzt, man darf sich nämlich nicht erst anmelden und dann auf die Konsole wechseln.
Die Installation muss bei Runlevel 3 erfolgen und nicht bei 5, also dem vollständig hochgefahrenen System.
Nachteil: Man muss das nach jedem Kernel-Update wiederholen.

Beide Bildschirme funktionieren bei mir absolut einwandfrei.
Alledings ist der zweit Bildschirm immer angeschlossen und war also auch bereits bei der Installation mit angeschlossen.

Den nouveau-Treiber fasse ich allerdings auch auf Grund früherer Erfahrungen schlicht erst gar nicht an, es wird immer der proprietäre Nvidia-Treiber benutzt.
Das führt allgemein zu weniger Problemen.

Die Oberfläche verhält sich nach einigen Updates nun einigermaßen stabil, aber es gibt noch immer zuviele Ausfälle.

Warum z.B. der Klick auf einen Link in Chrome zum Einfrieren der gesamten KDE führt (vor ein paar Minuten), bleibt mir schleierhaft.

Mein System läüft seit Jahren ohne besondere Systemveränderungen unter den verschiedenen openSUSE-Versionen, zuletzt auch unter 13.2 ... völlig stabil.

Bis dann eben Leap kam:
Das ist eindeutig die buggiest KDE seit langem!

Ich bemerke Freezes manchnmal einfach so zwischendurch (KDE hakt, bleibt stehen, geht dann wieder weiter) und Total-Freezes (spontan und reproduzierbar)

Bei den reproduzierbaren Fehlern, scheint sich das System insgesamt nicht mal einig zu sein, was denn nun genau funktioniert und was nicht.

Reproduzierbare Freezes erzeuge ich mit dem Start einer Windows-Exe (HeidiSQL) mit wine.
System hängt dann total nach ein paar Aktionen.
Lustig daran ist: Der Aufruf mit wine gelingt nicht nach jeder Neuanmeldung, sondern nur nach jeder dritten. Das ist unterirdisch.

Installiert ist der proprietäre Treiber von Nvidia.

Nein.Hardwareschäden liegen definitiv nicht vor.
Habe das System vor der Installation gründlich getestet und ein parallel installiertes Windows10 macht momentan glatt mehr Spaß bei der Arbeit als das openSUSE-System und läüft total pannenfrei.

Auch gerade heute noch hatte ich mehrere Freezes.

Zudem funktioniert mein geliebtes OpenTTD nicht, wenn man es aus den Repos nimmt... die geben sich momentan echt Mühe mich zu vergniesgnatzen..