Seit meinem Update auf openSUSE 11.0 zeigte das openSUSE-Updater-Applet (opensuseupdater-kde) mir alle Aktualisierungen doppelt an. Grund war, dass ich versehentlich zwei Update-Repositories eingebunden hatte. Das Entfernen eines der beiden Repositories löste das Problem. Im Bild ist zu sehen, dass die Updates für Java 5 und Java 6 doppelt vorhanden sind. Da das Applet nur eine graphische Schnittstelle für zypper ist lag es nahe zu schauen, ob dieses das gleiche Verhalten aufweist.

marix@eddie:~> zypper lu
Die Daten des Repositorys 'Lokale RPMs' sind veraltet. Sie können 'zypper refresh' als Root ausführen, um die Daten zu aktualisieren.
Lese installierte Pakete...
Patches
Repository                    | Name           | Version | Kategorie | Status
------------------------------+----------------+---------+-----------+---------
openSUSE-11.0-FTP-UPDATE 11.0 | java-1_5_0-sun | 96      | security  | Benötigt
openSUSE-11.0-Updates         | java-1_5_0-sun | 96      | security  | Benötigt
openSUSE-11.0-FTP-UPDATE 11.0 | java-1_6_0-sun | 97      | security  | Benötigt
openSUSE-11.0-Updates         | java-1_6_0-sun | 97      | security  | Benötigt

Auch zypper zeigt jedes Update doppelt. Doch auch die Ursache des Problems ist zu sehen. Jede Aktualisierung ist aus zwei verschiedenen Repositories zu beziehen. Das erklärt sowohl wieso es die Updates doppelt gibt, als auch, wieso trotzdem immer korrekt aktualisiert wurde. Denn zypper hat immer nur das Update aus der ersten Quelle wirklich installiert, ähnlich wie bei Paketen die aus mehreren Quellen zu holen sind.

marix@eddie:~> zypper lr
#  | Alias                         | Name                              | Aktiviert | Auffrischen
---+-------------------------------+-----------------------------------+-----------+------------
1  | Lokale_RPMs                   | Lokale RPMs                       | Ja        | Ja
2  | suse_1                        | openSUSE-11.0-FTP-SRC-NonOSS 11.0 | Ja        | Ja
3  | Marix'_Home_Repository_1      | Marix' Home Repository            | Ja        | Ja
4  | NVIDIA_Repository             | NVIDIA Repository                 | Ja        | Ja
5  | KDE:KDE4:Factory:Desktop      | KDE:KDE4:Factory:Desktop          | Ja        | Ja
6  | openSUSE-11.0-FTP_11.0        | openSUSE-11.0-FTP 11.0            | Ja        | Ja
7  | home:thindil_1                | home:thindil                      | Ja        | Ja
8  | VideoLan_Repository           | VideoLan Repository               | Ja        | Ja
9  | 11.0                          | openSUSE-11.0-FTP-UPDATE 11.0     | Ja        | Ja
10 | openSUSE-11.0-FTP-DEBUG_11.0  | openSUSE-11.0-FTP-DEBUG 11.0      | Ja        | Ja
11 | Marix'_Sane_Repository        | Marix' Sane Repository            | Nein      | Ja
12 | openSUSE-11.0-Updates         | openSUSE-11.0-Updates             | Ja        | Ja
13 | Security_and_Privacy_1        | Security and Privacy              | Ja        | Ja
14 | home:dstoecker                | home:dstoecker                    | Nein      | Ja
15 | Packman_Repository            | Packman Repository                | Ja        | Ja
16 | openSUSE-11.0-FTP-NonOSS_11.0 | openSUSE-11.0-FTP-NonOSS 11.0     | Ja        | Ja
17 | openSUSE-DVD 11.0             | openSUSE-DVD 11.0                 | Nein      | Nein
18 | suse                          | openSUSE-11.0-FTP-SRC 11.0        | Ja        | Ja

In der Auflistung aller Quellen sieht man an Position 9 und 12 die beiden Update-Repositories. Zum Glück kann man mit zypper die Repositories auch über ihre Nummer identifizieren, so ist das entfernen nur wenig Tipparbeit.

marix@eddie:~> sudo zypper rr 9
Entferne Repository 'openSUSE-11.0-FTP-UPDATE 11.0' [fertig]
Repository 'openSUSE-11.0-FTP-UPDATE 11.0' wurde entfernt.

Eine anschließende Überprüfung der verfügbaren Updates zeigt, dass das Problem erfolgreich behoben wurde.

marix@eddie:~> sudo zypper refresh
Lade Metadaten von Repository 'Lokale RPMs' herunter [fertig]
Repository 'openSUSE-11.0-FTP-SRC-NonOSS 11.0' ist aktuell.
Repository 'Marix' Home Repository' ist aktuell.
Repository 'NVIDIA Repository' ist aktuell.
Repository 'KDE:KDE4:Factory:Desktop' ist aktuell.
Repository 'openSUSE-11.0-FTP 11.0' ist aktuell.
Repository 'home:thindil' ist aktuell.
Repository 'VideoLan Repository' ist aktuell.
Repository 'openSUSE-11.0-FTP-DEBUG 11.0' ist aktuell.
Repository 'openSUSE-11.0-Updates' ist aktuell.
Repository 'Security and Privacy' ist aktuell.
Repository 'Packman Repository' ist aktuell.
Repository 'openSUSE-11.0-FTP-NonOSS 11.0' ist aktuell.
Repository 'openSUSE-11.0-FTP-SRC 11.0' ist aktuell.
Alle Repositories wurden aufgefrischt.
marix@eddie:~> zypper lu
Lese installierte Pakete...
Patches
Repository            | Name           | Version | Kategorie | Status
----------------------+----------------+---------+-----------+---------
openSUSE-11.0-Updates | java-1_5_0-sun | 96      | security  | Benötigt
openSUSE-11.0-Updates | java-1_6_0-sun | 97      | security  | Benötigt

Ist man sowieso schon auf der Konsole unterwegs kann man die Updates auch gleich von dort einspielen.

marix@eddie:~> sudo zypper up
Lese installierte Pakete...
Die folgenden Pakete werden aktualisiert:
  java-1_6_0-sun java-1_6_0-sun-devel java-1_6_0-sun-alsa java-1_6_0-sun-jdbc
java-1_5_0-sun-plugin java-1_5_0-sun
Die folgenden NEUEN Patches werden installiert:
  java-1_6_0-sun java-1_5_0-sun
Gesamtgröße des Herunterladens: 55,5 M. Nach der Operation werden zusätzlich 21,1 M genutzt.
Fortfahren? [JA/nein]:
Herunterladen von Paket java-1_6_0-sun-1.6.0.u7-1.1.x86_64 (1/8), 21,9 M (79,6 M installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 437,3 K
Lade herunter: java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig (127,1 K/s)]
Wende Delta an: ./java-1_6_0-sun-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_5_0-sun-1.5.0_update16-1.1.i586 (2/8), 20,1 M (74,4 M installiert)
Lade herunter: java-1_5_0-sun-1.5.0_update16-1.1.i586.rpm [fertig (195,7 K/s)]
Installiere: java-1_5_0-sun-1.5.0_update16-1.1 [fertig]
Herunterladen von Paket java-1_6_0-sun-devel-1.6.0.u7-1.1.x86_64 (3/8), 13,0 M (51,9 M installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 6,2 M
Lade herunter: java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig (130,2 K/s)]
Wende Delta an: ./java-1_6_0-sun-devel-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-devel-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_6_0-sun-alsa-1.6.0.u7-1.1.x86_64 (4/8), 40,0 K (88,0 K installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 16,5 K
Lade herunter: java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Wende Delta an: ./java-1_6_0-sun-alsa-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-alsa-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_6_0-sun-jdbc-1.6.0.u7-1.1.x86_64 (5/8), 32,0 K (88,0 K installiert)
Lade Delta herunter: ./rpm/x86_64/java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm, 16,2 K
Lade herunter: java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Wende Delta an: ./java-1_6_0-sun-jdbc-1.6.0.u6_1.6.0.u7-8.1_1.1.x86_64.delta.rpm [fertig]
Installiere: java-1_6_0-sun-jdbc-1.6.0.u7-1.1 [fertig]
Herunterladen von Paket java-1_5_0-sun-plugin-1.5.0_update16-1.1.i586 (6/8), 469,0 K (1,7 M installiert)
Lade Delta herunter: ./rpm/i586/java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm, 60,7 K
Lade herunter: java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm [fertig]
Wende Delta an: ./java-1_5_0-sun-plugin-1.5.0_update15_1.5.0_update16-12.1_1.1.i586.delta.rpm [fertig]
Installiere: java-1_5_0-sun-plugin-1.5.0_update16-1.1 [fertig]

As some of you might already have noticed, we are working on a better integration of Xfce in openSUSE. The aim of the Xfce Project is to establish Xfce as well-accepted desktop environment besides GNOME and KDE. We have already started building Xfce LiveCDs with KIWI but still fail in getting yast-live to work.

Besides that we had some success in the re-design process, so this is how the upcoming Xfce in openSUSE might look like:

Miguel Cruz has provided his great CrashBit theme and designed a few new icons to improve Xfce support.

I have also finished a SLiM Display Manager theme and work on some packages for that. There is still a lot of work to be done and things to coordinate. We are going to set up a oS Xfce Mailing List soon, that all interested people should join. In the near future I am continuing to blog about the current development process, so stay tuned.

Update: The Mailinglist is now availabl.: To subscribe send an eMail to: opensuse-xfce+subscribe@opensuse.org

I have also added an upgraded screenshot showing how it would look like using the Gilouche Window decoration.

Marcus

Auf leider nicht nachvollziehbare Weise hatte ich letztens plötzlich mein YaST verloren. Dies machte sich dadurch bemerkbar, dass KDE den Versuch "Installieren von Software" zu Starten mit der Bemerkung es könne "/sbin/yast" nicht finden beendete. Zeitlich fiel das ganze mit einem KDE4-Update zusammen, allerdings war mir bei diesem kein Konflikt aufgefallen.

Zum Glück wird die Paket- und Quellenverwaltung inzwischen nicht mehr YaST-intern abgehandelt, sondern durch die libzypper, für die mit zypper auch ein Kommandozeilenwerkzeug existiert. So ließ sich YaST schnell wieder installieren.

sudo zypper install yast2

So bekam ich zwar mein YaST zurück, leider fehlte aber immer noch das Paket zum "Installieren von Software". Mit zypper war dies allerdings auch schnell gefunden.

zypper search yast

Das gesuchte Paket heißt yast2-packager, also schnell mit zypper installiert.

sudo zypper install yast2-packager

Nachdem ich endlich dazu gekommen war das Windows 2000 auf einem alten PIII 550 MHz durch openSUSE 10.3 zu ersetzen funktionierte der Rechner zwar wunderbar, allerdings weigerte er sich beharrlich sich nach dem Herunterfahren selbständig abzuschalten. Auch unter Windows hatte es damals etwas Nachdruck bei der Konfiguration der Energieverwaltung gebraucht, aber wie diesen Nachdruck unter Linux ausüben? Der Vergleich der Aufrufe des normalen und des Safemode-Systems in Grub legte schnell nahe alle Kombinationen der Parameter apm bzw. acpi = off oder on durchzuspielen. Doch alles half nichts. Der entscheidende Hinweis kam dann zufällig auf der opensuse Mailingliste. Mit der Parametrisierung apm=off und acpi=force schaltet das System sich wie gewünsch von alleine ab sobald es heruntergefahren ist. Das ganze noch mit Hilfe von Yast direkt in GRUB eingetragen und das System läuft, bzw. schaltet ab wie Butter.

Wie auf heise online berichtet ist Zattoo jetzt auch in Deutschland frei verfügbar. Leider aber nur als 32-Bit-Programm und mit einer etwas merkwürdigen Installationsanleitung.

Zum Herunterladen ist zunächst eine Registrierung notwendig. Entgegen der Aussage auf der Webseite muss man aber eigentlich noch nicht mal eine gültige Emailaddresse verwenden, da keine Aktivierungsemail verschickt wird, sondern die Addresse wirklich lediglich zur Benutzeridentifikation verwendet wird.

Die Installationsanleitung verwundert etwas, da sie unter anderem möchte, dass man XULRunner in das Zattoo-Verzeichnis installiert, obwohl dieses eigentlich bei openSUSE mitgeliefert wird. An den in der Anleitung angegebenen von Hand angelegten symbolischen Links kommt man leider nicht vorbei. Außerdem sind im RPM leider keine Abhängigkeiten gepflegt. Deshalb müssen einige Bibliotheken leider von Hand auf 32-Bit umgestellt werden.

Bevor man das Zattoo-RPM installiert sollte man zunächst sicherstellen, dass man die folgenden Libraries in 32-Bit installiert hat. Es kann sein, dass weitere Bibliotheken benötigt werden, aber diese sind mir aufgefallen. Um ein Paket in 32-Bit zu installieren muss man im YAST Packetmanagment im Reiter Version die 32-Bit Version (i586) auswählen. Ist das Paket schon installiert kann es notwendig sein das Paket auch noch von Hand auf "Aktualisieren" zu setzen.

• libgnomeui-32bit (Ok, die ist immer 32-Bit)
• gtkglext
• mozilla-xulrunner181
• faad2

Nachdem das Zattoo-RPM installiert ist müssen die symbolischen Links hinzugefügt werden. Möchte man die XULRunner-Bibliothek von openSUSE verwenden sehen die Links allerdings etwas anders aus.

sudo ln -s /usr/lib/xulrunner-1.8.1/libgtkembedmoz.so libgtkembedmoz.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libxpcom.so libxpcom.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libmozjs.so libmozjs.so.0d
sudo ln -s /usr/lib/libplds4.so libplds4.so.0d
sudo ln -s /usr/lib/libplc4.so libplc4.so.0d
sudo ln -s /usr/lib/libnspr4.so libnspr4.so.0d
sudo ln -s /usr/lib/xulrunner-1.8.1/libxul.so libxul.so.0d

Anschließen muss man noch den Linker auf die im Zattoo-Verzichnis liegenden Bibliotheken und Links hinweisen.

sudo /sbin/ldconfig /usr/lib/zattoo/

~/.Zattoo/Data/logs/zattoo.errorlog

Persönlich finde ich es auch noch praktisch das Programm als zattoo verfügbar zu machen, da zattoo_player doch etwas lang zum tippen ist und zattood ein Tab-Complete verhindert.

sudo ln -s /usr/bin/zattoo_player /usr/local/bin/zattoo

Anchließen hat man einen funktionierenden P2P-Fernseher der auf den ersten Eindruck sehr gut zu funktionieren scheint.

Auf meine OpenSUSE 10.2 Systeme hatte ich zunächst in Anwendungen wie X2, welche beim Ton noch auf OSS setzen, keinen Ton. Zum Glück lies sich das Problem am Ende durch ein einfaches Löschen der Konfiguration von KDesktop lösen. Statt Ton bekam ich bei allen Anwendungen die OSS verwenden eine Fehlermeldung, obwohl der Ton bei anderen Anwendungen ging.

/dev/dsp: Das Gerät oder die Ressource ist belegt

marix@eddie:~> lsmod | grep oss
snd_pcm_oss            71680  0
snd_mixer_oss          35840  1 snd_pcm_oss
snd_pcm               115464  4 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd                    89384  14 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer

sudo /usr/sbin/rcalsasound restart

marix@eddie:~> lsof /dev/dsp* /dev/snd/**
COMMAND    PID  USER   FD   TYPE DEVICE SIZE   NODE NAME
kdesktop 19572 marix  mem    CHR  116,4      255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix   11r   CHR  116,2      255551 /dev/snd/timer
kdesktop 19572 marix   12u   CHR  116,4      255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix   13u   CHR  116,6      255819 /dev/snd/controlC0

mv ~/.kde/share/config/kdesktoprc ~/.kde/share/config/kdesktoprc.bak

Kleines Update: Nach diesen Änderungen ist es jetzt auch möglich OSS-Programme mit aoss zu verwenden. Dies hat den Vorteil, dass man den Amarok im Hintergrund weiterlaufen kann und somit Musik und Anwendungston hat.

Seitdem ich mein KDE mithilfe der Quelle http://software.opensuse.org/KDE:/KDE3/opensuse_10.2/ aus dem SuSE-Build-Service auf 3.5.7 aktualisiert habe stürzte Arts immer beim Start ab. Ein Start des artsd in der Konsole erzeugte anschließend diese Ausgabe.

marix@eddie:/opt/kde3/lib64> artsd
unix_connect: can't connect to server (unix:/tmp/ksocket-marix/eddie.site-5e24-468ca6d0)
loading extension from '/opt/kde3/lib64/libartsmidi.so' failed: /opt/kde3/lib64/libartsmidi.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsmidi.la.
MCOP ObjectManager: can't find implementation for Arts::MidiManager.
loading extension from '/opt/kde3/lib64/libartsbuilder.so' failed: /opt/kde3/lib64/libartsbuilder.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsbuilder.la.
MCOP ObjectManager: can't find implementation for Arts::ArtsBuilderLoader.
Speicherzugriffsfehler

sudo ln -s libartsmidi.so.0 libartsmidi.so
sudo ln -s libartsbuilder.so.0 libartsbuilder.so
sudo ln -s libartsakode.so.0 libartsakode.so
sudo ln -s libarts_akode.so.0 libarts_akode.so

Schließt man einen USB-Joystick an hat openSUSE ein recht merkwürdiges Verhalten. Zumindest gilt dies für meinem Fall, bei dem ein Logitech Extreme 3D Pro an ein Asus Motherboard mit nForce 570 SLI-Chipsatz angeschlossen wird. Auf dem System läuft openSUSE 10.2 x86_64. Zum Glück lässt sich diese Problem mit wenigen Handgriffen lösen.

Zunächst scheint das System den Joystick korrekt zu erkennen, was unter anderem anhand von dmesg zu sehen ist.

marix@eddie:~> dmesg | grep Joystick
input: USB HID v1.10 Joystick [Logitech Logitech Extreme 3D Pro] on usb-0000:00:02.0-1
input: USB HID v1.10 Joystick [Logitech Logitech Extreme 3D] on usb-0000:00:02.0-4

Interessant wird die Sache sobald man versucht den Joystick zu verwenden. Started man zum Beispiel das hervorgagende D1X-Rebirth bekommt man eine wenig erfreulich Meldung.

sdl-joystick: found 0 joysticks

Error opening /dev/input/js0!
Are you sure you have joystick support in your kernel?

Die Fehlermeldung von joy2key führt zur Lösung. Um den Joystick auch unter /dev/input zu sehen muss das Kernelmodul joydev geladen werden.

eddie:~ # modprobe joydev

/sbin/modprobe joydev

Nun zur Kuriosität. Startet man YaST und installiert neue Software funktioniert der Joystick anschließend reproduzierbar auch so. In diesem Fall scheint aus irgendeinem Grund das Modul also immer geladen zu werden. Sieht fast so aus, als wären Joysticks leider nicht mehr verbreitet genug um von Anfang an berücksichtigt zu werden und wurden beim Startup einfach vergessen.