Hallo zusammen, Tao Puh meinte am Freitag, den 05.08.2011 um 17:33 Uhr wegen:Nach KDM ist vor KDM

Ich vermute mal, dass man die hal-Fehlermeldungen ignorieren kann, aber was ist mit der Zeile:

nur aus der Erinnerung, noch unter OS 11.3 und KDE 4.5.4 hatte ich die von Dir beschriebenen oder ähnliche Symptome, weil die Repos von kde durcheinander geraten waren. Wenn Du in letzter Zeit neue Repos eingebunden hast, könnte eine Überprüfung evtl. lohnenswert sein. -- Beste Grüße Christian Schade, das Audacious gerade nichts spielt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Tao te Puh schrieb:

Am 05.08.2011 15:58, schrieb Tao te Puh:

...

Hallo,

seit vorgestern und einem "zypper up", habe ich (in 11.4 + Tumbleweed) folgendes Verhalten beim Anmelden in KDM: Nach der Eingabe meines Passwortes, schaltet der Bildschirm um (flackert kurz) und anschließend lande ich wieder in KDM beim Anmeldebildschirm.

Das gleich Verhalten habe ich, wenn ich den Anmeldedienst wechsle, also z.B. auf XDM.

Wenn ich aber KDM in Richtung Text-Konsolen-Modus verlasse und mich auf der Konsole einlogge, kann ich KDE mit einem startx zünden und ganz normal arbeiten - KDE als solches, scheint also nicht beschädigt zu sein.

Leider weiß ich nicht wirklich, wie KDM so werkelt, deshalb weiß ich auch nicht, wo/wie man dem Verhalten auf de Schliche kommt.

In messages werden lediglich folgende 3 Zeile protokolliert:

Aug 5 02:44:50 mahatma acpid: 1 client rule loaded Aug 5 02:45:07 mahatma checkproc: checkproc: can not get session id for process 2816! Aug 5 02:45:07 mahatma acpid: 1 client rule loaded

und in Xorg.0.log wurden auch nur [II]-Zeilen geschrieben.

Ansonsten, wie geschrieben, weiß ich nicht wo man noch nach gucken kann.

Nachtrag: Durch die Mail von Werner, bin ich auf das Logfile kdm.log aufmerksam geworden. Dort wird bei mir protokolliert:

---------------------------------------------------------------------- /etc/X11/xdm/Xstartup: Zeile 30: /usr/bin/hal-find-by-property: Datei oder Verzeichnis nicht gefunden

X.Org X Server 1.9.3 Release Date: 2010-12-13 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux mahatma 3.0.0-39-default #1 SMP Fri Jul 29 11:07:30 UTC 2011 (004c6e2) i686 Kernel command line: root=/dev/disk/by-id/ata-HTS541080G9AT00_MPB4LAX6HT9RAM-part3 resume=/dev/disk/by-id/ata-HTS541080G9AT00_MPB4LAX6HT9RAM-part2 splash=verbose quiet vga=0x317 Build Date: 07 June 2011 04:32:16AM

Current version of pixman: 0.20.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug 5 17:21:44 2011 (==) Using config directory: "/etc/X11/xorg.conf.d" (EE) Failed to load module "fglrx" (module does not exist, 0) (II) [KMS] Kernel modesetting enabled. /etc/X11/xdm/Xsetup: Zeile 114: /usr/bin/hal-find-by-property: Datei oder Verzeichnis nicht gefunden ----------------------------------------------------------------------

Ich vermute mal, dass man die hal-Fehlermeldungen ignorieren kann, aber was ist mit der Zeile:

(EE) Failed to load module "fglrx" (module does not exist, 0)

Das Modul hat, soweit ich weiß, was mit ATI-Karten zu tun, aber brauche ich das überhaupt (startx auf der Konsole, funktioniert ja auch ohne dieses Modul) und wenn ja, warum auf einmal?

Genau meine Fehlermeldung, die habe ich gerade noch einmal auf meinem Laptop nachvollzogen. Mit 4755 für /usr/bin/Xorg funktioniert startx von der Konsole und es sieht so aus, als wenn KDE 4.7 einwandfrei funktioniert. Mit freundlichem Gruß Karl Brandt . -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Tao te Puh schrieb:

Am 05.08.2011 19:05, schrieb Karl Brandt:

...

Tao te Puh schrieb:

...

Am 05.08.2011 15:58, schrieb Tao te Puh:

...

Hallo,

seit vorgestern und einem "zypper up", habe ich (in 11.4 + Tumbleweed) folgendes Verhalten beim Anmelden in KDM: Nach der Eingabe meines Passwortes, schaltet der Bildschirm um (flackert kurz) und anschließend lande ich wieder in KDM beim Anmeldebildschirm.

[ . . . ]

...

Ansonsten, wie geschrieben, weiß ich nicht wo man noch nach gucken kann.

Wenn Du Dich im System anmeldest mit "wie vorher" dann mußt Du beim Booten links unten das kleine Fenster öffnen und feststellen, daß nichts markiert ist. Setze den Punkt auf KDE und alles ist wieder "wie vorher" Ernst -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Tao te Puh schrieb:

Am 05.08.2011 20:15, schrieb Ernst Scott:

...

Tao te Puh schrieb:

...

Am 05.08.2011 19:05, schrieb Karl Brandt:

...

Tao te Puh schrieb:

...

Am 05.08.2011 15:58, schrieb Tao te Puh:

...

Hallo,

seit vorgestern und einem "zypper up", habe ich (in 11.4 + Tumbleweed) folgendes Verhalten beim Anmelden in KDM: Nach der Eingabe meines Passwortes, schaltet der Bildschirm um (flackert kurz) und anschließend lande ich wieder in KDM beim Anmeldebildschirm.

[ . . . ]

...

Ansonsten, wie geschrieben, weiß ich nicht wo man noch nach gucken kann.

Wenn Du Dich im System anmeldest mit "wie vorher" dann mußt Du beim Booten links unten das kleine Fenster öffnen und feststellen, daß nichts markiert ist. Setze den Punkt auf KDE und alles ist wieder "wie vorher"

Diesen Bug (https://bugzilla.novell.com/show_bug.cgi?id=691358) kenne ich bereits und hatte es, da ich mich daran erinnerte, auch bereits ausprobiert - aber das hat nichts gebracht. Ich kann, über KDM, überhaupt keine Desktopumgebung starten, weder KDE, noch Xfce, LXDE ...

Hast Du vielleicht im Anmeldebildschirm der Systemeinstellungen bei Abmeldungen einen Bootmanager eingetragen? Da muß "keiner" rein Ernst -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Freitag, 5. August 2011, 17:33:56 schrieb Tao te Puh:

(EE) Failed to load module "fglrx" (module does not exist, 0)

Das Modul hat, soweit ich weiß, was mit ATI-Karten zu tun, aber brauche ich das überhaupt (startx auf der Konsole, funktioniert ja auch ohne dieses Modul) und wenn ja, warum auf einmal?

Hast Du eine Ati-Karte? Und sucht er sich die Einstellungen automatisch oder hast Du eine xorg.conf angelegt? Sven -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 05.08.2011 20:52, schrieb Tao te Puh:

Am 05.08.2011 19:50, schrieb Sven Burmeister:

...

Am Freitag, 5. August 2011, 17:33:56 schrieb Tao te Puh:

...

(EE) Failed to load module "fglrx" (module does not exist, 0)

Das Modul hat, soweit ich weiß, was mit ATI-Karten zu tun, aber brauche ich das überhaupt (startx auf der Konsole, funktioniert ja auch ohne dieses Modul) und wenn ja, warum auf einmal?

Hast Du eine Ati-Karte?

Ja, ich habe eine "ATI Mobility Radeon X700 PCIE".

...

Und sucht er sich die Einstellungen automatisch oder hast Du eine xorg.conf angelegt?

"Er" sucht selbst und verwendet den radeon-Treiber.

Ich wollte zwar mal (05/2011) selber einen proprietären Treiber installieren, musste dann aber feststellen, dass die aktuell von ATI gelieferten keine Unterstützung mehr für meine Karte hatten und die Treiber, die meine Karte unterstützen, zu alt sind um sie auf 11.4 zu installieren.

Nachtrag: Aufgrund der Frage von Sven (xorg oder Automatismus), habe ich mal die Zeile "#Driver "radeon" in der Datei /etc/X11/xorg.conf.d/50-device.conf entkommentarisiert und somit dem System wahrscheinlich das Raten erleichtert. Nun ist die Fehlermeldung "Failed to load module "fglrx"" in der Datei kdm.log zwar verschwunden, ich kann mich aber trotzdem noch nicht anmelden. -- Herzliche Grüße Tao with warm regards, Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

On Mon, August 8, 2011 10:09, ddt.magnum-opus wrote:

Der laufende Grafiktreiber ist laut /var/log/Xorg.0.log der 08/15 intel GM915, GM945 etc. Hat also mit dem ATI gar nichts zu tun.

Exakt dieser Treiber bzw diese Grafikchips verursachen SEHR VIELE Probleme... Was ist das los!? Was installiert Debian in so einem Fall? Merci, Aribert Deckers -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Tao, wie Du vielleicht auf der Policy-Debatte verfolgt hast, scheint sich das ganze um einen Fehler in der Tumbleweed-Paketstruktur zu handeln. On Mon, 08 Aug 2011 15:59:50 +0200, Tao te Puh wrote:

Am 08.08.2011 10:09, schrieb ddt.magnum-opus:

...

ist denn jetzt eine sinnvolle Antwort gefunden?

Nein, ich "leide" immer noch an dieser Problematik soll heißen, ich kann mich nicht mehr via KDM anmelden - startx auf der Konsole, funktioniert aber ähnlich wie bei Dir.

Ich habe allerdings eine ATI und es wird der stinknormale radeon-Treiber von Xorg verwendet - ich denke deshalb mal, unser Problem hat nichts mit den Grafiktreibern zu tun, denn wir können X ja prinzipiell in Betrieb nehmen, nur eben nicht via KDM.

Ob es ein Problem mit KDM ist, mag ich jedoch anzweifeln, da ich genau das gleiche Problem habe, wenn ich statt KDM z.B. XDM verwende.

Wenn startx die grafische Oberfläche hochfährt, dann ist es nicht mehr die Grafikkarte. Wenn das Problem auch mit einem XDM auftaucht, ist es nicht mehr der KDM (allein), sondern vielleicht die Art und Weise, wie die grafische Oberfläche gestartet wird.

Zusätzlich zu diesem Problem, spinnt mittlerweile auch meine Audio-Installation, so dass ich keinen Sound mehr habe.

Das würde vielleicht auf die Prozeßkommunikation zeigen. dbus?

Da ich auf dem System eigentlich nichts weiter getan habe als ein regelmäßiges, "braves" zypper up, kann ich dieses Verhalten auch nicht irgendwie anders herleiten als das es über die Updates kam.

Ich habe "11.4 + Tumbleweed".

Genau wie ich. Vorher.

Ich wollte KDM etwas mehr debuggen und habe versucht den Log-Level hoch zu setzen. Dazu habe ich in der Datei /etc/sysconfig/displaymanager einen Wert (-debug 0x1) im Parameter DISPLAYMANAGER_KDM_LOCALARGS="" gesetzt, aber das hatte nicht den gewünschten Effekt und ergibt eine Fehlermeldung (Unrecognized option: -debug) in kdm.log.

Ich weiß also auch nicht, wie ich mehr Debug-Informationen erhalten kann kdm.log bzw. xdm.erros, weisen keine besonderen Hinweise auf.

Und, X wird ja gestartet soll heißen es wird ja angefangen etwas in Xorg.0.log zu schreiben, nur eben nicht viel und nichts was auf einen Fehler schließen lässt:

Auch meine kdm.log enthielt keinerlei Anhaltspunkte. Also, garnichts ausser zwei immer wiederkehrende Blöcke, die aber auch schon ausgegeben wurden, als das System noch funktionierte. Inzwischen warf ich die Tumbleweed-Zeile aus meinen Repositories, und habe wild gedowngraded (wie heißt das eingentlich auf deutsch? "Rückportiert"?), so dass ich nicht mehr sagen kann, was alles ich auf die niedrigere Versionsnummer aktualisieren ließ. Soweit ich das gesehen habe, ist ausser dem Kernel selber, seinen unverständlichen "preloads" und Libreoffice alles auf dem alten Stand. Durch das Downgraden wurden viele Pakete nachgezogen, wo mir das angeboten wurde, habe ich den "Anbieterwechsel" gewählt. Nach einem Reboot dauerte das Anmelden am KDM sehr lange, aber es funktionierte. Ausser dem Wallet-Passwort musste ich nichts extra eingeben, als sich der Funk wieder verbinden sollte. Den Kernel ließ ich Interessehalber auf dem neuen Stand. Gerade als ich schreiben wollte, dass auch die Videodarstellung funktioniert, hat SUSEs Kaffeine mir einen Black Screen beschert. Da werde ich wohl noch einmal mit Packman sprechen müssen. Vielleicht schreibt ja einmal jemand, wenn Tumbleweed wieder funktioniert. Viele Grüße Dieter --

magnum opus GmbH Tel: 08441/ 7978 107 Eichendorffstr. 19a Fax: 08441/ 7977 114 D-85276 Pfaffenhofen/Ilm http://www.magnum-opus.de

GF: Dieter Thalmayr, Dieter Jäger RG: Neuburg / Donau · HRB 91.238 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Tao te Puh schrieb:

Am 08.08.2011 17:05, schrieb ddt.magnum-opus:

...

Hallo Tao,

wie Du vielleicht auf der Policy-Debatte verfolgt hast, scheint sich das ganze um einen Fehler in der Tumbleweed-Paketstruktur zu handeln.

On Mon, 08 Aug 2011 15:59:50 +0200, Tao te Puh wrote:

...

Am 08.08.2011 10:09, schrieb ddt.magnum-opus:

...

ist denn jetzt eine sinnvolle Antwort gefunden?

Nein, ich "leide" immer noch an dieser Problematik soll heißen, ich kann mich nicht mehr via KDM anmelden - startx auf der Konsole, funktioniert aber ähnlich wie bei Dir.

Ich habe allerdings eine ATI und es wird der stinknormale radeon-Treiber von Xorg verwendet - ich denke deshalb mal, unser Problem hat nichts mit den Grafiktreibern zu tun, denn wir können X ja prinzipiell in Betrieb nehmen, nur eben nicht via KDM.

Ob es ein Problem mit KDM ist, mag ich jedoch anzweifeln, da ich genau das gleiche Problem habe, wenn ich statt KDM z.B. XDM verwende.

Wenn startx die grafische Oberfläche hochfährt, dann ist es nicht mehr die Grafikkarte. Wenn das Problem auch mit einem XDM auftaucht, ist es nicht mehr der KDM (allein), sondern vielleicht die Art und Weise, wie die grafische Oberfläche gestartet wird.

...

Zusätzlich zu diesem Problem, spinnt mittlerweile auch meine Audio-Installation, so dass ich keinen Sound mehr habe.

Das würde vielleicht auf die Prozeßkommunikation zeigen. dbus?

...

Da ich auf dem System eigentlich nichts weiter getan habe als ein regelmäßiges, "braves" zypper up, kann ich dieses Verhalten auch nicht irgendwie anders herleiten als das es über die Updates kam.

Ich habe "11.4 + Tumbleweed".

Genau wie ich. Vorher.

...

Ich wollte KDM etwas mehr debuggen und habe versucht den Log-Level hoch zu setzen. Dazu habe ich in der Datei /etc/sysconfig/displaymanager einen Wert (-debug 0x1) im Parameter DISPLAYMANAGER_KDM_LOCALARGS="" gesetzt, aber das hatte nicht den gewünschten Effekt und ergibt eine Fehlermeldung (Unrecognized option: -debug) in kdm.log.

Ich weiß also auch nicht, wie ich mehr Debug-Informationen erhalten kann kdm.log bzw. xdm.erros, weisen keine besonderen Hinweise auf.

Und, X wird ja gestartet soll heißen es wird ja angefangen etwas in Xorg.0.log zu schreiben, nur eben nicht viel und nichts was auf einen Fehler schließen lässt:

Auch meine kdm.log enthielt keinerlei Anhaltspunkte. Also, garnichts ausser zwei immer wiederkehrende Blöcke, die aber auch schon ausgegeben wurden, als das System noch funktionierte.

Inzwischen warf ich die Tumbleweed-Zeile aus meinen Repositories, und habe wild gedowngraded (wie heißt das eingentlich auf deutsch? "Rückportiert"?), so dass ich nicht mehr sagen kann, was alles ich auf die niedrigere Versionsnummer aktualisieren ließ. Soweit ich das gesehen habe, ist ausser dem Kernel selber, seinen unverständlichen "preloads" und Libreoffice alles auf dem alten Stand. Durch das Downgraden wurden viele Pakete nachgezogen, wo mir das angeboten wurde, habe ich den "Anbieterwechsel" gewählt. Nach einem Reboot dauerte das Anmelden am KDM sehr lange, aber es funktionierte. Ausser dem Wallet-Passwort musste ich nichts extra eingeben, als sich der Funk wieder verbinden sollte. Den Kernel ließ ich Interessehalber auf dem neuen Stand. Gerade als ich schreiben wollte, dass auch die Videodarstellung funktioniert, hat SUSEs Kaffeine mir einen Black Screen beschert. Da werde ich wohl noch einmal mit Packman sprechen müssen.

Vielleicht schreibt ja einmal jemand, wenn Tumbleweed wieder funktioniert.

Gut für Dich, dass Du (wahrscheinlich) einen Weg für Dich gefunden hast - schlecht für mich, wieder einer weniger der an dem Problem mit rumpopelt ...

Mir ist da aber gerade etwas eingefallen und zwar eine Merkwürdigkeit von "zypper up" von vor einigen Tagen. Keine Ahnung ob es was bedeutet, denn ich weiß nicht einmal was es eigentlich bedeutet.

Ich habe also mein "zypper up" gezündet und nach dem üblichen Geraffel Return gedrückt als mir eine Zeile auffiel die ich noch nie zuvor gesehen habe. Die habe ich dann noch ganz schnell in die Zwischenablage geholte um sie zu dokumentieren:

---------------------------------------- Die folgenden Pakete werden die Architektur ändern: apparmor-docs i586 -> noarch apparmor-profiles i586 -> noarch ----------------------------------------

Das ganze endete dann mit :

---------------------------------------- 226 Pakete werden aktualisiert, 1 neu, 2 Architekturwechsel. Gesamtgröße des Downloads: 350,1 MiB. Nach der Operation werden zusätzlich 2,0 MiB belegt. ----------------------------------------

An dem Tag wurde auch sehr viel KDE hochgezogen, u.A. z.B. auch KDM - wobei unser Problem ja nach aktuellem Wissensstand wahrscheinlich nichts mit KDE/KDM zu tun hat.

Ich habe keine Ahnung was dieser Architekturwechsel für mich bedeutet, ob das gut oder schlecht ist, ob es was mit unserem Problem zu tun hat, ob man das wieder rückgängig machen kann und wenn ja wie ...

Hallo an alle Betroffenen, apparmor hatte ich auf Grund einiger Hinweise im Netz auch im Verdacht. Ob mit oder ohne appamor, es hat nicht geholfen. Nachdem bei mir 3 Rechner betroffen waren habe ich mich, wie bereits beschrieben, mit einem Factory-Update beholfen. Mittlerweile laufen alle Rechner wieder reibungslos. Und zwar mit KDE 4.7 und Tumbleweed. Das wundert mich zwar gewaltig und ich hätte natürlich auch gerne gewusst warum, aber das wird wohl für immer ein Rätsel bleiben. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Guido Pinkernell schrieb:

Hallo Karl

Am Montag, 8. August 2011, 18:37:09 schrieb Karl Brandt:

...

Tao te Puh schrieb:

...

Am 08.08.2011 17:05, schrieb ddt.magnum-opus:

...

Hallo Tao,

wie Du vielleicht auf der Policy-Debatte verfolgt hast, scheint sich das ganze um einen Fehler in der Tumbleweed-Paketstruktur zu handeln.

On Mon, 08 Aug 2011 15:59:50 +0200, Tao te Puh wrote:

...

Am 08.08.2011 10:09, schrieb ddt.magnum-opus:

...

ist denn jetzt eine sinnvolle Antwort gefunden?

Nein, ich "leide" immer noch an dieser Problematik soll heißen, ich kann mich nicht mehr via KDM anmelden - startx auf der Konsole, funktioniert aber ähnlich wie bei Dir.

...

Hallo an alle Betroffenen,

apparmor hatte ich auf Grund einiger Hinweise im Netz auch im Verdacht. Ob mit oder ohne appamor, es hat nicht geholfen.

Nachdem bei mir 3 Rechner betroffen waren habe ich mich, wie bereits beschrieben, mit einem Factory-Update beholfen.

Welches Factory? Das KDE Factory wohl nicht, denn das hat bei mir nicht zu einer Lösung des von Tao beschriebenen Problems geführt. (Du hattest das auch an anderer Stelle erwähnt - ich habe dort aber auch keinen Hinweis auf das spezifische Factory gefunden).

Hallo Guido, Ich habe "yast2-update-FACTORY" installiert, es steht dann auch auf der Konsole unter yast zur Verfügung. Frag mich bitte nicht warum, aber dieses "Factory" hat mich schon mehr als einmal gerettet. So, für heute ist Feierabend. Das Bier wartet. Mit freundlichem Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

HURRA ! Es läuft wieder und sogar mein Sound ist wieder da. Was ich dafür gemacht habe? 1.) All' meinen Mut zusammengenommen 2.) 5 Kotau 'gen Osten 3.) Die 3 Voodoo-Kerzen angezündet Noch was vergessen? Ach ja: "zypper dup". Nun kann ich mich wieder anmelden, egal aus welchem Anmeldedienst (KDM/XDM...) und egal in welche Desktopumgebung (KDE, Xfce...) und, wie geschrieben, mein Sound ist auch ganz plötzlich wieder da. Nun brat' mir doch einer 'nen Adebar ... was war da denn zuvor schief gelaufen? Ich schwöre, ich spiele nicht mit Reposiroties rum - ich blicke da nämlich immer noch nicht komplett durch mit den ganzen Anbietern, Prioriäten, Factories und haste nicht jesehen ... Okay, ganz selten muss man ja mal eines dazu nehmen, ich z.B. wegen ISDN/Asterisk, aber das darf ein System doch nicht so aus dem Tritt bringen. Ich weiß zwar nicht ob das was ich da jetzt gemacht habe (zypper dup) so überhaupt vernünftig ist aber ich dachte mir, bevor ich jetzt aus lauter Verzweiflung downgrade wie der Dieter, versuche ich doch zunächst mal das System in dem Stand "11.4 + Tumbleweed" wieder gerade zu ziehen. Ich war erstaunt wie viel da bei dem dup letztendlich up- und downgegraded wurde: 34 packages to upgrade, 109 to downgrade, 7 new, 1 to remove, 47 to change vendor, 1 to change arch. (Komplette Ausgabe von zypper dup, siehe ganz am Ende der Mail) Und das, obwohl ich immer brav mein "zypper up" gemacht habe. Da ist jetzt eine Menge Zeit drauf gegangen, was es letztendlich war, weiß ich immer noch nicht, ein Verunsicherung bleibt (gehe ich richtig mit dem System um?) und ob der Dropps jetzt wirklich gelutscht ist, wird sich zeigen - mal sehen wo es als nächstes klemmt. Und dann noch folgende Beobachtung : Ich habe hier ein weiteres System welches mehr oder weniger frisch ist, ebenfalls 11.4 + Tumbleweed drauf hat und auf dem ich bisher auch nur ein einziges Repo hinzugenommen habe (network:telephony:asterisk). Ansonsten habe ich auf dem System ebenfalls immer nur regelmäßig "zypper up" ausgeführt. Nun habe ich mir mal dort die Ausgabe von "zypper dup" angesehen und auch dort würde das System einiges ändern wenn ich es zünden würde: 47 Pakete werden aktualisiert, 44 werden zurück gestuft, 11 neue, 1 zu entfernen, 22 Herstellerwechsel . Wie kann das sein? Vor allem wundert mich auf diesem System, dass er einiges von Tumblewwed nach openSuSE schieben würde: Die folgenden Pakete werden den Hersteller ändern: [...] kdebase4-openSUSE obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE kdebase4-runtime-branding-openSUSE obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE kdebase4-workspace-branding-openSUSE obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE kdelibs4-branding-openSUSE obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE kdm-branding-openSUSE obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE kio_sysinfo obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE kio_sysinfo-branding-openSUSE obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE libldb0 obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE Ich habe den Eindruck, als würde openSuSE so mit der Zeit aus dem Tritt kommen. Kann es ein, dass man beim Einsatz von Tumbleweed, regelmäßig ein zypper dup machen muss? Ich habe da so eine Theorie: Was ist mit Paketen die bei der ersten Tumbleweed-Installation noch nicht in Tumblewwed waren und erst später hinzugekommen sind? Die werden ja mit einem einfachen "zypper up" nicht eingespielt, da dies mit einem Anbieterwechsel verbunden wäre. Wie auch immer, aktuell bin ich jetzt aber erst einmal zufrieden. Und hier dann noch der komplette "zypper dup" von dem Rechner der Ärger machte: mahatma:~ # zypper dup Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... Reading installed packages... Computing distribution upgrade... The following NEW packages are going to be installed: cabextract claws-mail-lang libetpan15 libfaac0 libnice10 libquicktime0 preload-kmp-default The following package is going to be REMOVED: libquicktime The following packages are going to be upgraded: aaa_base aaa_base-extras claws-mail filesystem gstreamer-0_10-libnice gstreamer-0_10-plugins-ugly iproute2 iptables libassuan0 libebml3 libedit0 libgudev-1_0-0 liblash1 libldb0 libpolkit0 libshout3 libtag-extras1 libudev0 libupower-glib1 libwavpack1 libxine1 mjpegtools mkinitrd mobile-broadband-provider-info mtpaint nfs-client polkit polkit-default-privs python-numpy remmina screen udev upower ypbind The following packages are going to be downgraded: acl akonadi-runtime amarok amarok-lang ark attr bluedevil bluedevil-lang choqok digikam digikam-lang dolphin freerdp-devel gwenview iksemel kaffeine kcalc kcharselect kcolorchooser kde4-filesystem kde4-kgreeter-plugins kde4-l10n-de kde4-l10n-de-data kde4-l10n-de-doc kdebase4 kdebase4-libkonq kdebase4-nsplugin kdebase4-runtime kdebase4-runtime-xine kdebase4-session kdebase4-workspace kdebase4-workspace-ksysguardd kdebase4-workspace-liboxygenstyle kdegames4 kdegames4-carddecks-default kdegames4-carddecks-other kdegraphics4 kdelibs4 kdelibs4-core kdemultimedia4 kdepasswd kdepimlibs4 kdialog kdm keditbookmarks kfind kgamma kgpg kio_audiocd kio_kamera kipi-plugins kipi-plugins-acquireimage kipi-plugins-lang kmag kmahjongg kmines kmix kmousetool konqueror konqueror-plugins konsole kpat kreversi kruler kscd ksnapshot ksudoku kwalletmanager kwin kwrite libGLC_lib-devel libGLC_lib2 libacl libakonadi4 libakonadiprotocolinternals1 libattr libepub0 libexiv2-10 libkcddb4 libkcompactdisc 4 libkdcraw9 libkde4 libkdecore4 libkdegames4 libkdepimlibs4 libkexiv2-9 libkipi8 libkonq5 libksane0 libksuseinstall1 libmodplug1 libqt4-sql-mysql libquazip1 libthunarx-2-0 lxmenu-data okular oxygen-icon-theme oxygen-icon-theme-large oxygen-icon-theme-scalable perl-Net-SMTP-SSL python-ReportLab python-kdebase4 sweeper thunar thunar-lang usbutils wine wine-32bit wine-gecko The following package is going to change architecture: kdebase4-session noarch -> i586 The following packages are going to change vendor: aaa_base openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed aaa_base-extras openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed amarok obs://build.opensuse.org/KDE -> openSUSE amarok-lang obs://build.opensuse.org/KDE -> openSUSE claws-mail openSUSE -> http://packman.links2linux.de filesystem openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed freerdp-devel obs://build.opensuse.org/openSUSE:Factory:Contrib -> obs://build.opensuse.org/openSUSE:11.4:Contrib gstreamer-0_10-libnice openSUSE -> http://packman.links2linux.de gstreamer-0_10-plugins-ugly http://packman.links2linux.de -> obs://build.opensuse.org/openSUSE:Tumbleweed iptables openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed libGLC_lib-devel obs://build.opensuse.org/openSUSE:Factory:Contrib -> obs://build.opensuse.org/openSUSE:11.4:Contrib libGLC_lib2 obs://build.opensuse.org/openSUSE:Factory:Contrib -> obs://build.opensuse.org/openSUSE:11.4:Contrib libassuan0 openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed libebml3 obs://build.opensuse.org/openSUSE:Tumbleweed -> http://packman.links2linux.de libedit0 openSUSE -> obs://build.opensuse.org/devel:libraries:c_c++ libgudev-1_0-0 openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed liblash1 openSUSE -> http://packman.links2linux.de libldb0 obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE libmodplug1 : openSUSE-LXDE -> http://packman.links2linux.de libpolkit0 openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed libquazip1 obs://build.opensuse.org/openSUSE:Factory:Contrib -> obs://build.opensuse.org/openSUSE:11.4:Contrib libshout3 openSUSE -> http://packman.links2linux.de libtag-extras1 openSUSE -> http://packman.links2linux.de libthunarx-2-0 obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE libudev0 openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed libupower-glib1 openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed libwavpack1 openSUSE -> http://packman.links2linux.de libxine1 openSUSE -> http://packman.links2linux.de mjpegtools openSUSE -> http://packman.links2linux.de mkinitrd openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed mobile-broadband-provider-info openSUSE -> http://packman.links2linux.de mtpaint openSUSE -> http://packman.links2linux.de nfs-client openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed perl-Net-SMTP-SSL obs://build.opensuse.org/openSUSE:Factory:Contrib -> obs://build.opensuse.org/openSUSE:11.4:Contrib polkit openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed polkit-default-privs openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed python-numpy openSUSE -> http://packman.links2linux.de remmina obs://build.opensuse.org/openSUSE:Factory:Contrib -> obs://build.opensuse.org/openSUSE:11.4:Contrib screen openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed thunar obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE thunar-lang obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE udev openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed upower openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed wine obs://build.opensuse.org/Emulators -> openSUSE wine-32bit obs://build.opensuse.org/Emulators -> openSUSE wine-gecko obs://build.opensuse.org/Emulators -> openSUSE ypbind openSUSE -> obs://build.opensuse.org/openSUSE:Tumbleweed 34 packages to upgrade, 109 to downgrade, 7 new, 1 to remove, 47 to change vendor, 1 to change arch. Overall download size: 210.2 MiB. After the operation, 4.3 MiB will be freed. Continue? [y/n/?] (y): -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 08.08.2011 22:56, schrieb Lars Müller:

On Mon, Aug 08, 2011 at 09:59:20PM +0200, Tao te Puh wrote:

http://lists.opensuse.org/opensuse-factory/2011-08/msg00133.html

http://en.opensuse.org/Tumbleweed

Und es gibt zu dist-upgrade (dup) und update (up) auch jeweils einen eigenen Abschnitt mittels man zypper.

Leider verstehe ich nicht was Du mir damit mitteilen möchtest. Die man page von zypper habe ich vor einiger Zeit recht aufmerksam gelesen - ob ich das auch alles verstanden habe, ist eine andere Sache aber eine erneute Studie, wird daran sicherlich nichts ändern. Außerdem habe ich folgende Seite echt! komplett von oben nach unten durchgearbeitet und mir mehrere Seiten Notizen gemacht: http://de.opensuse.org/Zypper/Anleitung/11.2 Und nein, ich erhebe überhaupt keine Ansprüche darauf das alles komplett verstanden und jederzeit abrufbar zu haben. Dafür ist das einfach viel zu komplex. Und natürlich habe ich auch die Seite zu Tumbleweed gelesen bevor ich in Richtung Tumbleweed "abgedüst" bin. Oder muss man die in regelmäßigen Abständen erneut lesen? Der Link auf den Thread war zwar interessant und der Mann hatte durchaus ähnliche Verständnisfragen, aber ein anderes Problem. Vermutlich willst Du mir mitteilen, dass ich den Unterschied zwischen dup und up nicht verstanden habe. Da müsstest Du aber bitte konkreter werden. Was ist an meinem Verhalten, im Folgenden historisch gelistet, falsch: - Installation 11.4 - zypper dup in Richtung Tumbleweed gemäß Anleitung aus Deinem Link - zypper up - zypper up - ... - zypper up => Ergebnis: Irgendwann konnte ich mich nicht mehr anmelden und mein Sound war im Dutt. - zypper dup System funktioniert wieder. -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 09.08.2011 00:31, schrieb Lars Müller:

On Mon, Aug 08, 2011 at 11:51:46PM +0200, Tao te Puh wrote:

...

Am 08.08.2011 22:56, schrieb Lars Müller:

...

On Mon, Aug 08, 2011 at 09:59:20PM +0200, Tao te Puh wrote:

http://lists.opensuse.org/opensuse-factory/2011-08/msg00133.html

http://en.opensuse.org/Tumbleweed

Und es gibt zu dist-upgrade (dup) und update (up) auch jeweils einen eigenen Abschnitt mittels man zypper.

Leider verstehe ich nicht was Du mir damit mitteilen möchtest.

Dass der Unterschied dokumentiert ist. Die bedeutende Differenz ist:

up wechselt den Hersteller nicht wohingegen dup das macht. Unter Ansage, wie Du Sie auch gesehen und zitiert hast.

Ja, genau so hatte ich das bisher auch verstanden.

...

Die man page von zypper habe ich vor einiger Zeit recht aufmerksam gelesen - ob ich das auch alles verstanden habe, ist eine andere Sache aber eine erneute Studie, wird daran sicherlich nichts ändern.

Unter update steht: "This command will not update ..." Leider steht die positive Aussage nicht so klar bei dist-upgrade (dup). Mach bitte einen Bug auf.

Wieso, "upgrades (or even downgrades) installed packages to versions found in repositories, removes packages that are no longer in the repositories and pose a dependency problem for the upgrade, handles package splits and renames, etc." ist doch recht aussagekräftig. Der Hammer ist halt z.B., das manuell installierte Pakete, die in keinem Repo auftauchen, gelöscht werden. Da steckt ordentlich Zündstoff drin, in einem dup - deshalb hab' ich auch ordentlich Respekt vor dieser Option ...

...

Außerdem habe ich folgende Seite echt! komplett von oben nach unten durchgearbeitet und mir mehrere Seiten Notizen gemacht:

http://de.opensuse.org/Zypper/Anleitung/11.2

Und nein, ich erhebe überhaupt keine Ansprüche darauf das alles komplett verstanden und jederzeit abrufbar zu haben. Dafür ist das einfach viel zu komplex.

Und natürlich habe ich auch die Seite zu Tumbleweed gelesen bevor ich in Richtung Tumbleweed "abgedüst" bin. Oder muss man die in regelmäßigen Abständen erneut lesen?

Der Link auf den Thread war zwar interessant und der Mann hatte durchaus ähnliche Verständnisfragen, aber ein anderes Problem.

Vermutlich willst Du mir mitteilen, dass ich den Unterschied zwischen dup und up nicht verstanden habe. Da müsstest Du aber bitte konkreter werden. Was ist an meinem Verhalten, im Folgenden historisch gelistet, falsch:

- Installation 11.4 - zypper dup in Richtung Tumbleweed gemäß Anleitung aus Deinem Link - zypper up - zypper up - ... - zypper up

=> Ergebnis: Irgendwann konnte ich mich nicht mehr anmelden und mein Sound war im Dutt.

Weil eines der _benötigten_ Pakete noch in einer alten, nicht passend aus Tumbleweed stammenden Version vorlag. Sehr, sehr vermutlich.

Aber was bedeutet das letztendlich für den Einsatz von Tumbleweed? Ein regelmäßiges zypper dup ist ja, wie oben beschrieben, nicht ohne. Wie handhabt/administriert man eine Tumbleweed-Installation korrekt? Ist das "aus dem Ruder laufen" einer Tumblewwed-Installation nicht vorprogrammiert, da man ja nur zum Zeitpunkt des Umstieg ein dup fährt und ansonsten nur up's? Von einem Paket, was nachträglich in Tumbleweed aufgenommen wird, bekommt mein System doch niemals etwas mit, da es ja ein Anbieterwechsel wäre? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Zunächst mag ich mich für Eure bisherigen Beiträge zu diesem Thema bedanken! Dennoch, was die korrekte Administration einer Tumblewwed-Installation angeht, bin ich immer noch verunsichert. Z.B. wurde in diesem Thread mehrfach auf die Textpassage: "The only supported method of repo use for Tumbleweed is to have only the main repos (Oss, Non-oss, and Update) and the Tumbleweed repo active." auf der Seite: http://en.opensuse.org/Tumbleweed verwiesen. Den Kontext in dem diese Passage steht, habe ich aber immer so interpretiert, dass diese Aussage "ausschließlich" für die Installation bzw Inbetriebnahme einer Tumblewwed-Installation (also den "dup-Moment") gilt und ich ansonsten, also im normalen Betrieb, durchaus auch andere Repositories hinzunehmen darf. Mit "normalen Betrieb" meine ich den Zeitraum, in dem ich mein System typischerweise mit einem schlichten "zypper up" auf dem Laufenden halte. Oder ist es tatsächlich so, dass ich im normalen Betrieb von Tumbleweed, keine anderen Repositories verwenden darf? Das wäre ja schrecklich und würde den Mehrwert von Tumbleweed, für mich, auf Null reduzieren. Und somit sind wir dann bei der Frage, die mich, nach wie vor, umher treibt: Wie administriere ich ein laufendes Tumbleweed? Frage: Wenn ich in einem laufenden Tumbleweed (also: normaler Betrieb eines Tumbleweed-System), regelmäßig immer "nur" mit "zypper up" aktualisiere, wie reagiert mein System dann eigentlich darauf, wenn es im Tumbleweed-Repository neuere Pakete gibt? Diese Pakete, werden ja mit einem einfach "up" nicht aktualisiert, da dies ein Anbieterwechsel wäre. Muss man diesen Umstand also manuell begegnen (pflegen), indem man bei "zypper up" immer auf die Pakete achtet, die gelistet werden unter "Die folgenden Paketaktualisierungen werden NICHT installiert."? Dort sind ja die Pakete gelistet, die nicht aktualisiert werden, weil dies ein Anbieterwechsel bedeuten würde. Aber diese Liste wird mit der Zeit recht groß und unübersichtlich - ich hatte da teilweise schon über 80 Pakete gelistet bekommen. Das ist manuell nicht zu bewerkstelligen. Wenn heute da 80 stehen und morgen 81, muss ich ja die komplette Liste auseinander klamüsern, nur um das eine neu hinzugekommene Paket zu finden um es dann anschließend zu überprüfen und gegebenenfalls manuell mit Anbieterwechsel zu installieren ... Ich habe mal gerade ein aktuelles Beispiel zu dieser Thematik auf einem Tumblewwed-System raus gesucht. Ein einfaches "zypper up" listet dort z.B.: Die folgenden Paketaktualisierungen werden NICHT installiert. ... libassuan0 ... Also u.A. ein Paket libassuan0, was zwar aktueller vorliegt, aber bei einem einfachen up, nicht aktualisiert wird. Wenn ich nun in Yast nachschaue kann ich feststellen, dass die aktuell installierte Version die Version 2.0.1-4.1 ist und aus dem Repository openSUSE-11.4-11.4-0 stammt, es aber eine aktuellere Version 2.0.2-4.1 gibt, die allerdings im Repository Tumbleweed wartet. Mit einem einfach "zypper up" würde dieses Paket also niemals aktualisiert werden und ebenso alle anderen Pakete die so nach und nach in Tumbleweed aufgenommen werden. Das ist es, was ich meinte als ich in einer meinen letzten Mails von "aus dem Ruder läuft" schrieb. Oder muss man doch regelmäßig ein "zypper dup --from Tumbleweed" machen? Das scheint mir irgendwie zu gefährlich und auch umständlich. Oder kann man openSuSE irgendwo mitteilen, dass es, falls es im Tumbleweed-Repository aktueller Pakete gibt, diese auch bei einem "zypper up" installieren soll, also auch dann, wenn das einen Anbieterwechsel bedeutet? So ähnlich muss es doch auch mit dem üblichen update-Repository funktionieren - ein normales update damit ist ja, genau genommen, auch mit einem Anbieterwechsel verbunden da die updates, in einem anderen Repository stehen. Scherzhaft gemeint: Irgendwie entwickelt sich das "Rolling Release" für mich gerade zu einem "Rolling Stone" und zwar einen, den ich manuell voran schieben muss, bergauf, versteht sich -> Sisyphos ... -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 12.08.2011 06:47, schrieb David Haller:

Hallo,

Am Fri, 12 Aug 2011, Tao te Puh schrieb:

...

Frage: Wenn ich in einem laufenden Tumbleweed (also: normaler Betrieb eines Tumbleweed-System), regelmäßig immer "nur" mit "zypper up" aktualisiere, wie reagiert mein System dann eigentlich darauf, wenn es im Tumbleweed-Repository neuere Pakete gibt?

Diese Pakete, werden ja mit einem einfach "up" nicht aktualisiert, da dies ein Anbieterwechsel wäre.

Jep (also zumindest Pakete, die bisher noch nicht aus Tumbleweed sind).

...

Muss man diesen Umstand also manuell begegnen (pflegen), indem man bei "zypper up" immer auf die Pakete achtet, die gelistet werden unter "Die folgenden Paketaktualisierungen werden NICHT installiert."?

Denke ja.

...

Oder muss man doch regelmäßig ein "zypper dup --from Tumbleweed" machen? Das scheint mir irgendwie zu gefährlich und auch umständlich.

Gefährlich sollte es nicht sein.

...

Oder kann man openSuSE irgendwo mitteilen, dass es, falls es im Tumbleweed-Repository aktueller Pakete gibt, diese auch bei einem "zypper up" installieren soll, also auch dann, wenn das einen Anbieterwechsel bedeutet?

Du könntest Tumbleweed als äquivalent zu oS11.4 definieren (in /etc/zypp/vendors.d).

==== man zypper ==== update (up) [options] [packagename] ... Update installed packages with newer versions, where possible.

This command will not update packages which would require change of package vendor unless the vendor is specified in /etc/zypp/vendors.d, [..] ====

Wie das in vendors.d aussehen muß weiß ich aber (noch) nicht.

Die Variable

solver.allowVendorChange = false

in /etc/zypp/zypp.conf solltest du IMO nicht ändern, das macht zu sehr Ärger mit anderen Repos (z.B. Videolan vs. Packman).

Disclaimer: ich verwende weder Tumbleweed noch vendors.d.

Vorneweg (Allgemein): Also bei mir hat die von openSuSE verwendete Begrifflichkeit "Rolling Release", ganz bestimmte Assoziationen ausgelöst. So assoziiere ich z.B. mit dem Begriff "Rolling", einen "kontinuierlichen" Vorgang und keine "Hopserei". Und so dachte ich dann auch, dass ich mit Tumbleweed ein System erhalte, was zusätzlich zum update-Repository "kontinuierlich" noch mit lecker Aktualisierungen versorgt wird und zwar solchen, die im "Factory" als "stable" deklariert wurden. Natürlich bin ich davon ausgegangen, dass diese Aktualisierungen automatisch, also im Rahmen des normalen Aktualisierungsvorganges (zypper up), vonstatten gehen. Jetzt merke ich aber, dass man mit Tumblewwed mehr oder weniger nur Snapshots aus dem Tumbleweed-Repository schießen kann und das System ansonsten, lediglich aus dem Update-Repository aktualisiert wird - was, meiner unbedeutenden Meinung nach, Fehleranfällig ist. Aber nun konkret zu Deiner Mail, David: Ich habe gar keine Datei /etc/zypp/vendors.d ? Muss man die anlegen? Wie schaut die aus - okay, Du hast ja geschrieben, dass Du das auch nicht weißt. Meinst Du, dass dies, also das manuelle Anlegen, Editieren und Pflegen der venodrs.d, der Königsweg ist den man mit einem Tumbleweed-System gehen sollte/muss, um eine automatisierte Kontinuität zu erreichen? Warum werden derartig einschneidende Notwendigkeiten, mit keinem Wort auf der Tumbleweed-Seite (http://en.opensuse.org/Tumbleweed) erwähnt? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

On Sat, Aug 13, 2011 at 12:31:54AM +0200, David Haller wrote:

Am Fri, 12 Aug 2011, Tao te Puh schrieb: [..]

...

Aber nun konkret zu Deiner Mail, David: Ich habe gar keine Datei /etc/zypp/vendors.d ? Muss man die anlegen? Wie schaut die aus - okay, Du hast ja geschrieben, dass Du das auch nicht weißt.

Meinst Du, dass dies, also das manuelle Anlegen, Editieren und Pflegen der venodrs.d, der Königsweg ist den man mit einem Tumbleweed-System gehen sollte/muss, um eine automatisierte Kontinuität zu erreichen?

Ja. Gefunden:

http://en.opensuse.org/SDB:Vendor_change_update

Also, teste mal das folgende:

mkdir /etc/zypp/vendors.d cd /etc/zypp/vendors.d cat <<'EOF' > Tumbleweed.conf [main] vendors = suse,opensuse,obs://build.opensuse.org/openSUSE:Tumbleweed EOF

Damit müßte das Tumbleweed-Repo äquivalent zum OSS/Update Repo werden und somit beim 'zypper up' auftauchen ...

...

Warum werden derartig einschneidende Notwendigkeiten, mit keinem Wort auf der Tumbleweed-Seite (http://en.opensuse.org/Tumbleweed) erwähnt?

Weil's noch niemand reingeschriebne hat und Tumbleweed ja noch recht neu ist ;)

"Und wie schreibt man da was rein?" a) http://en.opensuse.org/Tumbleweed im Browser öffnen. b) Oben rechts auf der Seite auf "login" drücken c) Und dann untef "Topics" auf "Edit" Ok, ich nehme Wetten an, obs sich was tun wird. Ich verfolge das gerade mit einer gewissen bitteren Unterhaltung auf der englischsprachigen Liste. Da gibt es viel Gelaber, aber konkret tun, auch so ganz einfache Dinge wie die Seiten des Wiki ein klein wenig verbessern, das ist viel zu viel Arbeit. Lieber zehn Mails in einen mehr oder minder nutzlosen Thread. Aber ich schweife ab. Aber es ist auch noch gefühlter Morgen. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Am 13.08.2011 17:03, schrieb David Haller:

Hallo,

Am Sat, 13 Aug 2011, Lars Müller schrieb:

...

On Sat, Aug 13, 2011 at 12:31:54AM +0200, David Haller wrote:

...

Am Fri, 12 Aug 2011, Tao te Puh schrieb: [..]

...

Aber nun konkret zu Deiner Mail, David: Ich habe gar keine Datei /etc/zypp/vendors.d ? Muss man die anlegen? Wie schaut die aus - okay, Du hast ja geschrieben, dass Du das auch nicht weißt.

Meinst Du, dass dies, also das manuelle Anlegen, Editieren und Pflegen der venodrs.d, der Königsweg ist den man mit einem Tumbleweed-System gehen sollte/muss, um eine automatisierte Kontinuität zu erreichen?

Ja. Gefunden:

http://en.opensuse.org/SDB:Vendor_change_update

Also, teste mal das folgende:

mkdir /etc/zypp/vendors.d cd /etc/zypp/vendors.d cat<<'EOF'> Tumbleweed.conf [main] vendors = suse,opensuse,obs://build.opensuse.org/openSUSE:Tumbleweed EOF

Damit müßte das Tumbleweed-Repo äquivalent zum OSS/Update Repo werden und somit beim 'zypper up' auftauchen ...

...

Warum werden derartig einschneidende Notwendigkeiten, mit keinem Wort auf der Tumbleweed-Seite (http://en.opensuse.org/Tumbleweed) erwähnt?

Weil's noch niemand reingeschriebne hat und Tumbleweed ja noch recht neu ist ;)

"Und wie schreibt man da was rein?"

a) http://en.opensuse.org/Tumbleweed im Browser öffnen. b) Oben rechts auf der Seite auf "login" drücken c) Und dann untef "Topics" auf "Edit"

Ok, ich nehme Wetten an, obs sich was tun wird. Ich verfolge das gerade mit einer gewissen bitteren Unterhaltung auf der englischsprachigen Liste. Da gibt es viel Gelaber, aber konkret tun, auch so ganz einfache Dinge wie die Seiten des Wiki ein klein wenig verbessern, das ist viel zu viel Arbeit. Lieber zehn Mails in einen mehr oder minder nutzlosen Thread. Aber ich schweife ab. Aber es ist auch noch gefühlter Morgen.

Wenn die Rückmeldung kommt, daß das so funktioniert ...

-dnh

Ich werde das definitiv testen und auch Rückmeldung erstatten. Allerdings gibt es hier gerade einen Notfall mit defekter Festplatte aufgetreten ... Vorab dennoch eine Frage: Sollte nicht auch die vendor-Zeile vendors = suse,opensuse,tumbleweed genügen, also ohne den vollen Pfad obs://build... ? Das fände ich übersichtlicher. OT: Meine neuen Lieblings-Linux-Phrasen, nach Lektüre von http://en.opensuse.org/SDB:Vendor_change_update , sind übrigens: vendor stickiness concept und vor allem packages ping-ponging -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jetzt kommt der Stein ins rollen - oder genauer, der Busch ins kullern! Ich habe den Vorschlag von David getestet und die Ergebnisse, entsprechen den Erwartungen - Danke David ! Worum ging es noch gleich? Es geht um die kontinuierliche Aktualisierung eines Tumbleweed-Systems. Wichtig ist hierbei der Begriff kontinuierlich. Nach dem bisherigen Verfahren, wird ein Tumbleweed-System einmalig mittels z.B. "zypper dup --from Tumbleweed" eingerichtet. Dabei werden alle auf dem System installierten Pakete, durch gleichnamige Pakete aus dem Tumbleweed-Repository aktualisiert - insofern sie dort vorhanden sind. Im nachfolgenden Betrieb des Systems, wird das Tumbleweed-Repository allerdings wie jedes andere Repository behandelt soll heißen, bei dem üblichen Aktualisierungsvorgang (z.B. via "Yast-Online-Update" oder "zypper up"), werden Pakete die im Tumbleweed-Repository eventuell neu hinzugekommen sind, nicht automatisch auf dem System installiert, da dies mit einem Anbieterwechsel verbunden wäre. An dieser Stelle habe ich mir gewünscht, dass das Tumbleweed-Repository ähnlich gewichtet wird und funktioniert wie das Update-Repository soll heißen, wenn dort neue Pakete hinzukommen, dann sollen sie bei einer typischen Aktualisierung ("Yast-Online-Update" oder "zypper up"), in jedem Fall auf meinem System installiert werden. Diese Funktionalität ist es, die ich mit der im Tumbleweed-Kontext propagierten Begrifflichkeit "Rolling Release" assoziiere. David hat nun einen Weg aufgezeigt, wie man diese Gleichberechtigung von update-Repository und Tumbleweed-Repository (genauer: den Anbietern) in einem System einrichten kann. Ich werde das hier noch einmal dokumentieren und dazu auch gleich ein paar von meinen Beobachtungen und Tests. Im Grunde geht es also darum, dass man dem System mitteilt, dass Aktualisierungen aus dem Tumbleweed-Repository auch dann durchgeführt werden, wenn diese Aktualisierung einen Anbieterwechsel bedeutet. Im Englischen wird diese Thematik mit "Vendor change update" betitelt und kann detailliert nachgelesen werden unter: http://en.opensuse.org/SDB:Vendor_change_update Für uns besonders interessant ist dort der Abschnitt "Allowing Vendor change in general" http://en.opensuse.org/SDB:Vendor_change_update#Allowing_Vendor_change_in_ge... Hier nun die konkrete Umsetzung in meinem Tumbleweed-System: Wir müssen eine Datei anlegen in der alle Anbieter aufgeführt sind für die wir einen automatischen Anbieterwechsel freigeben wollen. Die Position der Datei ist vorgegeben mit dem Verzeichnis /etc/zypp/vendors.d/ welches aber in der Regel nicht auf dem System vorhanden ist, deshalb: mkdir /etc/zypp/vendors.d Der Name der Datei kann frei vergeben werden. Ich wähle "Tumbleweed.conf". Wir erzeugen diese Datei und schreiben zwei Zeilen hinein: cat <<'EOF' >> /etc/zypp/vendors.d/Tumbleweed.conf [main] vendors = suse,opensuse,obs://build.opensuse.org/openSUSE:Tumbleweed EOF Eigentlich war es das schon und wir können mit dem update loslegen, dennoch einige Anmerkungen zum Syntax der "vendors-Zeile": Wir listen also drei Namen die aber nicht absolut sind, sondern als Ausdrücke behandelt werden. So kann ein hier aufgeführter Name, auf mehrere Anbieter zutreffen, siehe wie folgt: Groß/Kleinschreibung wird nicht unterschieden und verglichen wird der aufgeführte Name mit dem Anfang der Anbieternamen soll heißen der von uns aufgeführte Name "opensuse" trifft also auch die hypothetischen Anbieter "openSuSE-11.4" oder "opensuse-update". Die Namen der Anbieter, kann man ermitteln über z.B. "zypper if PAKETNAME". So liefert z.B. "zypper if kernel-desktop" ... Hersteller: obs://build.opensuse.org/openSUSE:Tumbleweed ... Während "zypper if glibc" folgendes aufzeigt: ... Hersteller: openSUSE ... BTW: Mich hat mal interessiert, wie viele unterschiedliche Anbietern sich da eigentlich auf meinem System tummeln und wie die alle heißen. Aus einem Befehl von David, habe ich mir dann folgendes zurecht gezimmert: rpm -qa --queryformat '%{vendor}\n' | sort -u Erstaunt nahm ich zur Kenntnis, dass es doch recht wenig sind. Außerdem stellte ich fest, dass ich keinen Anbieter habe, der mit "suse" beginnt, ich könnte mir das oben also sparen und die Vendor-Zeile reduzieren auf : vendors = opensuse,obs://build.opensuse.org/openSUSE:Tumbleweed Da die Gurus das aber in dem aufgeführten Dokument mit "suse" gemacht haben und ich ein Schisser bin, lasse ich das drin. Und wie ich so die bei mir vorhandenen Anbieternamen angucke und ich vermute, dass man die beim Paketbau wahrscheinlich selbst vergeben kann wird mir klar, dass ich mit dieser Lösung nicht wirklich das erreicht habe, was ich eigentlich wollte. Ich habe nämlich nur Namen von Anbietern frei gegeben und nicht Repositories. Ich verlasse mich also darauf, dass die Paketbauer die Vendor-Angabe gewissenhaft pflegen. Wenn also jemand im Packman-Repository ein Paket rein stellt, welches intern als Anbieter "openSuSE" oder aus Spaß "openSuSE-Fan" enthält, dann würde es installiert werden, auch wenn es aus einem "unerwünschten" Repository stammt ... Wie auch immer, hier noch ein paar Tests die stattfanden, nachdem ich die Datei Tumbleweed.conf angelegt habe. Dazu habe ich mir einzelne Pakete rausgesucht, die er vorher nicht mit einem allgemeinen "zypper up" updaten wollte und deshalb auflistete in der Sektion "Die folgenden Paketaktualisierungen werden NICHT installiert.". Ich habe dann einfach mal ein "zypper up" ausgeführt und geschaut, welche Pakete er nun installieren würde und welche nicht: Beispiel : libassuan0 Installiert : 2.0.1-4.1 openSUSE-11.4-11.4-0 Verfügbar : 2.0.2-4.1 Tumbleweed "zypper up" würde es jetzt updaten, so ist es gewünscht. Einem Anbieterwechsel nach Tumbleweed, wird nun zugestimmt. Beispiel : libldb0 Installiert : 0.9.7-2.6 @System Verfügbar : 0.9.7-2.17.1 repo-oss (openSUSE-11.4-Oss) "zypper up" würde es jetzt updaten, dieses Beispiel verstehe ich allerdings nicht. Was bedeutet die Anbieterangabe "@System"? Ich kann darüber keine Angabe in /etc/zypp/repos.d finden. Beispiel : nfs-client Installiert : 1.2.3-11.16.1 Aktualisierungen-für-openSUSE-11.4-11.4-0 Verfügbar : 1.2.3-27.1 Tumbleweed "zypper up" würde es jetzt updaten, so ist es gewünscht. Einem Anbieterwechsel nach Tumbleweed, wird nun zugestimmt. Beispiel : k3b Installiert : 2.0.2-6.9.1 repo-oss Verfügbar : 2.0.2-8.pm.13.3 packman.inode.at-suse "zypper up" würde es NICHT updaten, so soll es sein. Einem Anbieterwechsel wird NICHT zugestimmt. Das Konzept der klebrigen Anbieter (vendor stickiness concept), ist also nicht einfach komplett ausgehebelt und funktioniert somit noch. Beispiel : kernel-desktop Installiert : 3.0.0-38.1 @System Verfügbar : 3.0.1-40.1 Tumbleweed "zypper up" würde es NICHT updaten. Hier verstehe ich 2 Dinge nicht. Zum Einen wieder die Geschichte mit "@System" und zum Anderen, warum würde er es nicht updaten? Liegt das daran, dass es sich um einen Kernel-Update handelt? Ein explizites "zypper up kernel-desktop", hat jedenfalls funktioniert. Nochmals Dank an David ! -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 15.08.2011 07:16, schrieb Werner Flamme:

Am 15.08.2011 05:52, schrieb Tao te Puh:

...

Beispiel : libldb0 Installiert : 0.9.7-2.6 @System Verfügbar : 0.9.7-2.17.1 repo-oss (openSUSE-11.4-Oss) "zypper up" würde es jetzt updaten, dieses Beispiel verstehe ich allerdings nicht. Was bedeutet die Anbieterangabe "@System"? Ich kann darüber keine Angabe in /etc/zypp/repos.d finden.

Das bedeutet, dass das Paket mit dieser Version in Deinem System installiert ist. Es gibt diese Version allerdings in keinem Repo (mehr).

Supi, das leuchtet ein und ich habe es jetzt verstanden - gerade habe ich bei der David-Mail noch geschrieben, dass der Groschen nicht fallen will ....

Das würde Dir auch bei Verwendung von YaST(2) im Tab "Versionen" angezeigt.

Geguckt habe ich da, aber verstanden habe ich es nicht ...

...

Beispiel : k3b Installiert : 2.0.2-6.9.1 repo-oss Verfügbar : 2.0.2-8.pm.13.3 packman.inode.at-suse "zypper up" würde es NICHT updaten, so soll es sein. Einem Anbieterwechsel wird NICHT zugestimmt. Das Konzept der klebrigen Anbieter (vendor stickiness concept), ist also nicht einfach komplett ausgehebelt und funktioniert somit noch.

Ja, wieso auch nicht? Wenn Du es in /etc/zypp/zypp.conf nicht ausgeschaltet (solver.allowVendorChange = true) hast, ist das eins der wichtigsten Unterscheidungsmerkmale von "zypper up" zu "zypper dup".

Ja, ich wollte ja auch nur zeigen, dass das Konzept für Repositories ungleich Tumbleweed immer noch funktioniert und wir es nicht, bedingt durch unsere Aktion, doch irgendwie komplett ausgehebelt haben.

...

Beispiel : kernel-desktop Installiert : 3.0.0-38.1 @System Verfügbar : 3.0.1-40.1 Tumbleweed "zypper up" würde es NICHT updaten. Hier verstehe ich 2 Dinge nicht. Zum Einen wieder die Geschichte mit "@System" und zum Anderen, warum würde er es nicht updaten? Liegt das daran, dass es sich um einen Kernel-Update handelt? Ein explizites "zypper up kernel-desktop", hat jedenfalls funktioniert.

Vielleicht ist @System unterschiedlich zu Tumbleweed, so dass ein Vendor Change vorliegt? Wurde beim "zypper up kernel-desktop" ein Vendor Change angezeigt?

Nein, kein Anbieterwechsel - der installierte Kernel stammt auch aus Tumbleweed. Aber wahrscheinlich trifft Davids Vermutung zu nämlich, dass es an multiversion liegt und so wurden auch alle anderen anstehenden Kernel-Updates zurück gehalten. -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 15.08.2011 08:01, schrieb David Haller:

...

Groß/Kleinschreibung wird nicht unterschieden und verglichen wird der aufgeführte Name mit dem Anfang der Anbieternamen soll heißen der von uns aufgeführte Name "opensuse" trifft also auch die hypothetischen Anbieter "openSuSE-11.4" oder "opensuse-update".

Hab ich das überlesen, daß da nur der Anfang gematcht wird statt dem ganzen String (da muß ich nochmal nachgucken).

Ich habe das zumindest so verstanden: Libzypp makes an string comparision (like strncmp, case-insensitive) whereas the beginning of the strings are compared only.e.G. vendor "opensuse11.0" is compatible to "openSUSE".

...

Und wie ich so die bei mir vorhandenen Anbieternamen angucke und ich vermute, dass man die beim Paketbau wahrscheinlich selbst vergeben kann wird mir klar, dass ich mit dieser Lösung nicht wirklich das erreicht habe, was ich eigentlich wollte.

Jein. Prinzipiell kann man natürlich als Paketbauer den Vendor frei eintragen, aber im OBS und bei Packman wird der automatisch vergeben. Meine "home" Pakete im OBS haben z.B. wenig überraschend obs://build.opensuse.org/home:dnh und das kann ich auch nicht ändern.

Fein, so einen Mechanismus habe ich mir an dieser Stelle gewünscht.

...

Wie auch immer, hier noch ein paar Tests die stattfanden, nachdem ich die Datei Tumbleweed.conf angelegt habe. Dazu habe ich mir einzelne Pakete rausgesucht, die er vorher nicht mit einem allgemeinen "zypper up" updaten wollte und deshalb auflistete in der Sektion "Die folgenden Paketaktualisierungen werden NICHT installiert.".

Ich habe dann einfach mal ein "zypper up" ausgeführt und geschaut, welche Pakete er nun installieren würde und welche nicht:

...

Beispiel : libldb0 Installiert : 0.9.7-2.6 @System Verfügbar : 0.9.7-2.17.1 repo-oss (openSUSE-11.4-Oss) "zypper up" würde es jetzt updaten, dieses Beispiel verstehe ich allerdings nicht. Was bedeutet die Anbieterangabe "@System"? Ich kann darüber keine Angabe in /etc/zypp/repos.d finden.

@System ist das, was aktuell im System installiert ist.

Aber es steht dort ja nicht immer @System (Ich habe immer mit Yast in der Textkonsole geschaut). Oder soll das heißen, dass dieses Paket noch von der ursprünglichen (DVD-)Installation ist? Kann eigentlich nicht sein, denn beim Stöbern in Yast, meine ich auch Pakete gesehen zu haben, die in der Version etwas in der Art "@System ... vom Anbieter Tumbleweed" oder so stehen hatten. Und das Beispiel unten ist ja auch so - der installierte Kernel stammt aus Tumbleweed und soll durch einen neuen, ebenfalls aus Tumbleweed, ersetzt werden. So richtig ist der Groschen also doch noch nicht bei mir gefallen.

[..]

...

Beispiel : kernel-desktop Installiert : 3.0.0-38.1 @System Verfügbar : 3.0.1-40.1 Tumbleweed "zypper up" würde es NICHT updaten. Hier verstehe ich 2 Dinge nicht. Zum Einen wieder die Geschichte mit "@System" und zum Anderen, warum würde er es nicht updaten? Liegt das daran, dass es sich um einen Kernel-Update handelt? Ein explizites "zypper up kernel-desktop", hat jedenfalls funktioniert.

Vermutlich. Hast du "multiversion = [..,]kernel-desktop[,..]" in der /etc/zypp/zypp.conf? Dann wäre der aktuellere Kernel gerade eben kein Update mehr, das den bisherigen ersetzt, sondern würde zusätzlich zu diesem installiert. Insofern wäre das Verhalten erklärt und IMO auch korrekt...

Ja, ich habe multiversion eingestellt und das war auch gestern meine Vermutung. Schade das ich nicht konkret weiter dachte - ich hätte die Option ja mal raus nehmen und erneut testen können - aber das nächste Kernel-Update kommt bestimmt ...

Achso, willst du das selber im Wiki eintragen? Und wenn nicht, darf ich deine Beschreibung als Vorlage verwenden?

Ich traue mir das nicht zu und für den englischen Wiki schon zweimal nicht. Und natürlich darf mein Geschreibsel als Vorlage genommen werden, völlig Lizenzfrei und ohne jegliche Verpflichtung bezüglich Autorennennung etc. ... -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, Am Tue, 09 Aug 2011, Werner Flamme schrieb:

Weiter oben heißt es, dass man besser keine weiteren Repos aktiv hält (außer "the main repos (Oss, Non-oss, and Update) and the Tumbleweed repo"). Wenn man das trotzdem macht, soll man das dup auf TW beschränken. Damit es kein "globales dup" und haut keine Pakete ersatzlos raus, erkennt aber sehr wohl neue Pakete in TW und ersetzt ggf. Pakete aus anderen Repos damit.

Ich fahre hier 11.4 mit recht vielen Zusatzrepos[0] -- und aktualisiere mit Yast2 wobei ich ggfs. per Hand die passende Version im Versions-Tab raussuche. Äh, und das hier ist ne ex-11.2, die ich per 'zypper dup' (da war Yast mal nicht hilfreich, dafür zypper) auf die 11.4 gezogen habe (einfach alle 11.2 in /etc/zypp/repos.d/* ausgetauscht). Achso, wichtig ist auch, daß man die Prioritäten der Repos pflegt! HTH, -dnh n.p: L.v.Beethoven, Op. 61, 1. Satz, N. Kennedy + NDR Sinfonieorch. [0] $ ls /etc/zypp/repos.d/*.repo | wc -l 41 -- Hochwertige Dokumente muessen in der heutigen Zeit auf auf preiswerter Hardware zu Erstellen sein. Nicht jeder kann sich einen teueren Rechner fuer 100 Euro oder mehr leisten. -- Uwe Borchert in dctt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am 10. August 2011 12:02 schrieb Werner Flamme :

...

[0] $ ls /etc/zypp/repos.d/*.repo | wc -l     41

Schwanzlängenvergleich? ;-)

ls /etc/zypp/repos.d/*.repo | wc -l 63

ist im Büro, zu Hause sind's mehr ;-) Sind auch nicht alle aktiv.

Mal ne OT Frage: Warum sind es überhaupt so viele Repos ? Nicht bei euch, sondern generell, das diese so verstreut auch liegen ? Warum ist es nicht möglich, weniger repos anzubeiten, aber dafür mit mehr software ? Gruß Sebastian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, Am Wed, 10 Aug 2011, Sebastian Gödecke schrieb:

Am 10. August 2011 12:02 schrieb Werner Flamme :

...

[ich schrieb:]

...

[0] $ ls /etc/zypp/repos.d/*.repo | wc -l     41 [..] Mal ne OT Frage: Warum sind es überhaupt so viele Repos ?

Weil vieles nicht grad "stable" ist und zur Distri gehört. Und bei mir sind es z.B. allein 7xDistri (Update, Debug, Source, Online und ISO[1]), 3xKDE, 4 eigene und einiges an "devel" Kram. Für nicht-Kompilierer reichen wesentlich weniger Repos. -dnh [1] wenn man wie ich lokal Pakete baut, grad auch mit osc, dann braucht man das recht oft für -devel Pakete ;) -- "Worst case of testosterone poisoning I've ever seen." -- Lt. Cmdr. S. Ivanova, Babylon 5, 1x19 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Montag, 8. August 2011 schrieb Tao te Puh:

Die folgenden Pakete werden die Architektur ändern: apparmor-docs i586 -> noarch apparmor-profiles i586 -> noarch ----------------------------------------

Das ganze endete dann mit :

---------------------------------------- 226 Pakete werden aktualisiert, 1 neu, 2 Architekturwechsel. Gesamtgröße des Downloads: 350,1 MiB. Nach der Operation werden zusätzlich 2,0 MiB belegt. ----------------------------------------

An dem Tag wurde auch sehr viel KDE hochgezogen, u.A. z.B. auch KDM - wobei unser Problem ja nach aktuellem Wissensstand wahrscheinlich nichts mit KDE/KDM zu tun hat.

Ich habe keine Ahnung was dieser Architekturwechsel für mich bedeutet, ob das gut oder schlecht ist, ob es was mit unserem Problem zu tun hat, ob man das wieder rückgängig machen kann und wenn ja wie ... apparmor-docs und apparmor-profiles enthält Textdateien, die unabhängig von der Architektur des Prozessors sind, also für i586 und x86_64 ( und ia64 und sparc und ...) identisch." Noarch" ist genau für solche Sachen erfunden wurden. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org