AMD Catalyst 12.4 (fglrx 8.961) wurde veröffentlicht. Das Skript makerpm-amd-12.4.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4 und 12.1.

Das Packaging Skript brauche ich diesmal nicht extra zu pflegen. Die Kernel-Patches wegen den Compilerfehler habe ich bereits für diesen Monat in den AMD Installer eingepflegt. Im nächsten AMD Catalyst werden wir diese Patches nicht mehr brauchen. Da die Patches im fglrx Quellcode von AMD für die kommende Version enthalten sein wird.

Kleine Vorwarnung auf stürmische Zeiten:
AMD plant die Grafikchips R6xx/R7xx nicht mehr im Hauptzweig zu führen. Die Grafikkarten der Serie Radeon HD 2000, 3000 und 4000 sind betroffen (Phoronix hat darüber berichtet). Die letzte unterstützte Version wird voraussichtlich AMD Catalyst 12.7 sein. Jedoch hat AMD eingelenkt und lagert diesen in einen seperaten Zweig aus, um es dort weiterzupflegen. Es bedeutet, dass keine neuen Feature mehr hinzukommen, sondern nur Bugs gefixt werden. openSUSE 11.4 und 12.1 wird weiterhin unterstützt und gepflegt. Die Chancen stehen gut, dass der Treiber bis dahin auch auf einem X-Server 1.12 laufen wird. Die kommende openSUSE Version 12.2 im Juli wird noch auf den X-Server 1.10 aufsetzen, so dass der Treiber theoretisch auch auf dieser openSUSE Version laufen kann. Hierzu werde ich ein seperates makerpm-amd-Skript erstellen, dass diesen Legacy Treiber weiterhin wie gewohnt auf openSUSE 11.4 und 12.1 (ggfs. 12.2) zu installieren und werde auch die nötigen Kernel-Patches versorgen. AMD ist der Meinung, dass die genannten Chipsätze bereits umfangreich vom freien Radeon-Treiber unterstützt wird.

Es wird also Zeit eine neue Grafikkarte zu ordern, um weiterhin die Beta-Treiber vom AMD Catalyst auf openSUSE zu testen. Eine neue Grafikkarte war ohnehin schon letzten Oktober geplant. So werde ich endlich eure Hardware-Spende für die neue Grafikkarte einlösen.

Downloads:

• Skript: makerpm-amd-12.4.sh
• SHA1: makerpm-amd-12.4.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-12.4.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-12.4.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-amd-12.4.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

AMD Catalyst 12.3 (fglrx 8.951) wurde veröffentlicht. Das Skript makerpm-amd-12.3.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4 und 12.1.

Das Packaging Skript habe ich wegen einem Kompilierungsfehler beim Bau eines fglrx Kernelmodul unter dem Kernel 3.2.8+ und dem Kernel 3.3+ aktualisiert. Auf Grund des sehr knappen Zeitfenster konnten die Patches leider nicht mehr in AMD Catalyst 12.3 einfliessen. Erst im kommenden AMD Catalyst 12.4 werden die Patches von mir für openSUSE verfügbar sein und ab AMD Catalyst 12.5 werden diese auch offiziell für alle anderen Distributionen enthalten sein. Ja, mit dem makerpm-amd-Skript kann ich für euch sehr einfach, bequem und schnell fehlende Patches oder sinnvolle Erweiterungen via Packaging Skript Update nachliefern, wo ihr sonst Monate warten müsst.

Downloads:

• Skript: makerpm-amd-12.3.sh
• SHA1: makerpm-amd-12.3.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-12.3.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-12.3.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-amd-12.3.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

AMD Catalyst 12.2 (fglrx 8.950) wurde veröffentlicht. Das Skript makerpm-amd-12.2.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4 und 12.1.

[UPDATE 25.03.2012]
Das nächste Update vom Skript behebt einen weiteren Kompilierungsfehler beim Bauen eines fglrx-Kernelmoduls auf einem Kernel 3.3 und höher.
Im Wortlaut:

error: 'struct thread_struct' has no member named 'has_fpu'

Linus Torvalds hat es geschafft zum Leidwesen aller Kernel-Nutzer die betreffende Stelle im Git-Repo von Linus Torvalds innerhalb von wenigen Tagen für Kernel 3.3+ nochmal umzubauen, so dass der vorhergehende Patch (wegen TS_USEDFPU) vom 09.03.2012 erneut kaputt gegangen ist. Da sage ich doch mal, herzlichen Glückwunsch. Da braucht man sich nicht zu wundern, dass der Quellcode eines Kernelmoduls von Dritten irgendwann unleserlich wird, weil man versucht die gleiche Funktion für alle (halbwegs aktuellen und vor allem betreuten) Kernelversionen abzudecken.
[/UPDATE 25.03.2012]

[UPDATE 09.03.2012]
Das Packaging Skript wie auch das makerpm-amd-Skript wurden aktualisiert. Es behebt einen Kompilierungsfehler vom fglrx Kernelmodul auf einem 32bit System, weil ab Kernel 3.2.9 und höher die Konstante TS_USEDFPU entfernt und die Funktion dahinter umgeschrieben wurde. Ich habe über den genannten Fehler im Netz recherchiert und eine Information der Kerneländerung im Git-Repo von Linus Torvalds gefunden. Daraus habe ich einen Patch entwickelt und diesen auch an die AMD-Entwickler zwecks Prüfung geschickt. AMD hat sich das Patch angeschaut und hat ihn als akzeptabel eingestuft und nimmt ihn mit meiner Erlaubnis in den fglrx Quellcode auf. Vielen Dank an dieser Stelle nochmal an Rudolfo Patella für den Hinweis auf diese Problematik.
[/UPDATE 09.03.2012]

AMD hat diesmal etwas verspätet den Treiber veröffentlicht. Der Grund lag einzig daran, dass AMD die Treiber-Version 8.94 wegen möglicher Treiber-Probleme mit einigen Grafikkarten übersprungen hat. Außerdem habe ich das Packaging Skript aktualisiert, weil AMD leider meine Änderung nicht in ihren AMD Installer reingepackt hatte. (Vergessen? Kein Zeit? Wer weiß… Zumal die geschlossene AMD Mailingliste auch ausgefallen war. ) Es betrifft einmal den atieventsd.sh Init-Skript. Dort wurde für den Start des Skriptes im Runlevel 3 angegeben und zugleich das XDM (X Window Manager) vorausgesetzt, was IMHO keinen Sinn macht. Andererseits ist das Powermode-Skript (ati-powermode.sh) endgültig rausgeflogen. Da der Treiber bereits den Suspend-Modus unterstützt und kein Hilfsskript mehr benötigt.

Der Treiber unterstützt jetzt auch AMD Radeon HD 7950, HD 7970, HD 7990.

Downloads:

• Skript: makerpm-amd-12.2.sh
• SHA1: makerpm-amd-12.2.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-ati-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-12.2.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-12.2.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-amd-12.2.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

Am 31.01.2012 hat Adobe im Adobe-Labs die 5. Beta-Version (11.2.202.197) des Flash Players für 32-bit wie auch 64-bit Systeme veröffentlicht.

Laut der Release Notes wurden nur Fehler behoben und schließt auch einige Sicherheitslücken, die derzeit ausgenutzt werden. Sofern man eine frühere Beta-Version installiert hat, so wird empfohlen, diese Beta-Version zügig einzuspielen. Außerdem hat Adobe angekündigt, dass dies die letzte Beta vor dem Release ist.

Wer noch einen Fehler oder Ungereimtheiten in der aktuellen Beta des Flash Player gefunden hat, so möchte ich den Bugtracker von Adobe empfehlen.

Die Installation des neuesten Flash Player auf openSUSE:

Hinweis: Die Installation wird in der Konsole mit root-Rechten durchgeführt. Hierzu wird der Flash Player und das zugehörige Packaging Skript heruntergeladen. Daraus wird ein RPM-Paket gebaut und auf Wunsch installiert. Es ist wichtig, dass entweder die Installations-DVD oder das OSS-Repo von openSUSE verfügbar ist, weil ggfs. noch benötigte Pakete (update-desktop-files, fdupes, patch und ggfs. kde4-filesystems) installiert werden.

Downloads:

• makerpm-flash-11.2-beta5.sh
• makerpm-flash-11.2-beta5.sh.sha1

1. Das Skript makerpm-flash-11.2-beta5.sh wie auch die Prüfsummendatei herunterladen:

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.2-beta5.sh

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.2-beta5.sh.sha1

2. Die Prüfsumme vom heruntergeladenen Skript prüfen:

   sha1sum -c makerpm-flash-11.2-beta5.sh.sha1

   Idealerweise sollte folgende Ausgabe erscheinen, andernfalls ist das Skript defekt und sollte ersetzt werden:

   makerpm-flash-11.2-beta5.sh: OK

3. Das Skript ausführbar machen:

   chmod 755 makerpm-flash-11.2-beta5.sh

4. Nun gibt es 3 Möglichkeiten die Pakete zu erstellen und zu installieren:
   1. Auf einem reinen KDE-System:

      ./makerpm-flash-11.2-beta5.sh -i kde

   2. Auf einem reinen GNOME- bzw. GTK-System:

      ./makerpm-flash-11.2-beta5.sh -i gnome

   3. Sowohl auf einem KDE-System wie auch auf einem GNOME-System:

      ./makerpm-flash-11.2-beta5.sh -i all

      oder einfach nur

      ./makerpm-flash-11.2-beta5.sh -i

   Dann entspannt zurück lehnen und warten bis die Installation abgeschlossen ist. Das Skript ist wie gewohnt gesprächig und die jeweilige Aktion kann verfolgt werden.

5. Rechner neustarten und Flash Player 11.2 Beta 5 testen.

Feedbacks sind immer willkommen.

Have a lot of fun!

Der Plan: Alle binären Dateien in /bin, /sbin /lib und /lib64 nach /usr verschieben. Aus Gründen der Kompatiblität werden noch symbolische Links zu den binären Dateien angelegt. Angeschoben wurde diese Idee vom Fedora-Projekt. Bei Fedora ist bereits der Umzug voll im Gange. Greg Kroah-Hartman (greg k-h) hat diesen Vorschlag einfach mal in die Mailingliste openSUSE Factory gestellt und wird zur Zeit heiß diskutiert.

Warum macht man das? Die Verzeichnisse /bin, /sbin, /lib und /lib64 waren damals wichtig, wo noch Festplattenspeicher sehr knapp waren. Die Tools und die Bibliotheken standen auf dem System immer zur Verfügung, während man das Verzeichnis /usr aus Platzgründen auf einer anderen Festplatte ausgelagert hatte. Falls das System die Festplatte/Partition für /usr nicht mounten konnte, so hat man noch ein funktionsfähiges System. Außerdem hat man immer noch die Werkzeuge zur Verfügung, um das System zu reparieren.

Würden wir die Trennung weiterhin beibehalten, so muss ich sagen, dass das heutige Linux-System (aus der Sicht von damals) mehr kaputt als ganz ist. Eine Shellanweisung macht es sogar deutlich, wie abhängig wir heute schon vom /usr Verzeichnis sind.

for i in `find /bin /sbin /lib* -type f -executable`; do ldd ${i} 2>/dev/null | grep usr > /dev/null && echo ${i}; done

Auf einem openSUSE 12.1 (64-bit) sieht so aus:

/bin/systemd-notify
/bin/systemctl
/bin/rpm
/sbin/install-info
/lib/systemd/systemd-stdout-syslog-bridge
/lib/systemd/systemd-uaccess
/lib/systemd/systemd-shutdownd
/lib/systemd/systemd-readahead-collect
/lib/systemd/systemd-initctl
/lib/systemd/systemd-readahead-replay
/lib/systemd/systemd-kmsg-syslogd
/lib/udev/iphone-set-info
/lib/udev/udisks-part-id
/lib/udev/ipod-set-info
/lib/udev/mtp-probe
/lib/udev/udisks-probe-sas-expander
/lib/udev/udisks-dm-export
/lib/udev/udev-acl
/lib/udev/udev-configure-printer
/lib/udev/udisks-probe-ata-smart
/lib/libnss_wins.so.2
/lib64/libgudev-1.0.so.0.1.0
/lib64/security/pam_systemd.so
/lib64/security/pam_pwcheck.so
/lib64/security/pam_smbpass.so
/lib64/security/pam_userdb.so
/lib64/security/pam_cracklib.so
/lib64/security/pam_ck_connector.so
/lib64/libnss_wins.so.2

Auch auf einer älteren openSUSE 11.4 (64-bit) sieht es nicht besser aus:

/bin/rpm
/sbin/install-info
/lib/udev/udisks-probe-ata-smart
/lib/udev/mobile-action-modeswitch
/lib/udev/hid2hci
/lib/udev/udisks-part-id
/lib/udev/udev-configure-printer
/lib/libnss_wins.so.2
/lib64/libnss_wins.so.2
/lib64/security/pam_cracklib.so
/lib64/security/pam_ck_connector.so
/lib64/security/pam_pwcheck.so
/lib64/security/pam_userdb.so

Sogar andere Distributionen sind betroffen: I’m interesting in, how much different Linux distributions are broken.

Das würde bedeuten, dass diese Tools bzw. Bibliotheken bei einem fehlenden /usr Verzeichnis nicht mehr funktionieren.

Wie ist es heute? Mittlerweile haben wir mehr als ausreichende Festplattenkapazität und können gleich ein komplettes Linux-System auf die Platte ziehen oder sogar mehrere Linux-Systeme. Sollte das Linux-System einmal ausfallen, haben wir immer noch unsere Rettungs-CDs, Sicherheitskopien oder sogar ein zweites Linux-System auf der Festplatte, um das System wiederherzustellen. Daher wird dieses Argument als Rettungssystem nicht mehr ziehen.

Was sind eigentlich die Vorteile? Theoretisch können mehrere Linux-System das Verzeichnis /usr teilen, so hat man 2 Fliegen mit einer Klappe geschlagen. Man senkt nicht nur den Wartungsaufwand, sondern auch den benötigten Speicherplatz. Man kann so auch viel leichter einen Snapshot vom /usr Verzeichnis erstellen.

Gibt es irgendwelche Nachteile? Bisher sind keine gravierenden Nachteile bekannt. Es gibt aber einige kleinere Nachteile. Beim Bau der Pakete sind noch die alten Installationspfade /bin, /sbin, /lib und /lib64 enthalten und müssen entsprechend gepatcht werden. Sobald die Verzeichnisse /bin, /sbin, /lib und /lib64 in naher Zukunft endgültig entfernt werden, kann es passieren das einige schlampig geschriebenen Skripten oder proprietäre Programme nicht mehr funktionieren. Die andere Seite der Medaille ist, dass es evtl. zu einem Bruch bei der FHS (Filesystem Hierarchy Standard) und bei der LSB (Linux Standard Base) kommt, die den Standard der Dateisystemordnung sowie den Ort für die binären Dateien vorschreibt. Hier müsste die Linux Foundation die FHS/LSB-Spezifikation abändern, sonst ist die Zertifizierung in Gefahr, was für die kommerziellen Linux-Systeme wie z.B. die “SUSE Linux Enterprise” Produkte und auch “Red Hat Enterprise Linux” Produkte hart treffen könnte.

Fazit: Meiner Meinung nach ist der Umzug der binären Dateien längst überfällig. Somit schneiden wir endlich alte Zöpfe ab, die in heutiger Zeit mehr störend als nützlich empfunden wird. Man kann sich viel mehr darauf verlassen, dass die binären Dateien genau da sind, wo sie eigentlich hingehören. Auch die einfachere Wartung über mehrere Linux-Systeme hinweg, sollte man berücksichtigen.

Weitere Informationen und Diskussionen zu diesem Thema:
http://en.opensuse.org/UsrMerge
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
http://0pointer.de/blog/projects/the-usr-merge.html
https://fedoraproject.org/wiki/Features/UsrMove
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155547
http://thread.gmane.org/gmane.linux.debian.devel.general/165785
http://thread.gmane.org/gmane.linux.gentoo.devel/72128
http://harald.fedorapeople.org/downloads/usrmove/

Das erste Kernel-Update für openSUSE 12.1 ist draußen und behebt unzählige Fehler und schließt einige Sicherheitslecks. Es beinhaltet zugleich alle 9 Patchlevel-Versionen vom Upstream, dass noch viele weitere Fehler behebt. Besonders fällt im nachfolgenden ChangeLog aus der RPM auf, dass eine ganze Reihe von Patches zum Dateisystem btrfs enthalten sind.

Das Kernel-Update kann über YaST2 oder per zypper eingespielt werden:

zypper up

Die offizielle Ankündigung zum Kernel-Update werde ich an dieser Stelle nachreichen.

Ein Auszug der Changelog aus der RPM:

• patches.fixes/drm-radeon-kms-fix-i2c-masks.patch: Add git commit ID.
• ALSA: hda/realtek – Skip invalid digital out pins (bnc#727348)
• ALSA: hda – Add missing static ADC tables for ALC269 quirks.
• patches.fixes/hfs-fix-hfs_find_init-sb-ext_tree-null-ptr-oops.patch: hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops (CVE-2011-2203 bnc#699709)
• X86: Solve Dell Latitudes do not reboot on x86_64 more generally.
• sunrpc: wake up SOFTCONN tasks when a connection error happens (bnc#679059)
• Linux 3.1.1.
• Update config files.
• Refresh patches.fixes/scsi-dh-queuedata-accessors.
• Refresh patches.suse/staging-hv-staging-next-20110829-0327-Staging-hv-storvsc-Add-the-contents-of-hyperv_sto.patch.
• Delete patches.drivers/alsa-hda-0002-Keep-EAPD-turned-on-for-old-Conexant-chips.
• Delete patches.drivers/alsa-hda-0003-Fix-ADC-input-amp-handling-for-Cx20549.
• Delete patches.drivers/alsa-hda-0004-Add-missing-static-ADC-tables-for-ALC269-qu.
• Delete patches.drivers/alsa-hda-0005-realtek-Skip-invalid-digital-out-pins.
• Delete patches.fixes/drm-radeon-kms-fix-i2c-masks.patch.
• Delete patches.suse/staging-hv-staging-next-20111001-0058-staging-hv-fix-a-kernel-warning-in-netvsc_linkstat.patch.
• Delete patches.suse/staging-hv-staging-next-20111001-0129-Staging-hv-Add-support-for-2-TB-LUN-in-storage-dr.patch.
• Add package descriptions for ARM kernels
• Update Patch-mainline headers.
• ARM: Dont generalize the target. On ARM we can not build generic kernels that work through different generations, such as armv5 and armv7. So we better list them explicitly and not export an rpm that wouldn’t even work on the respective architecture .
• ARM: Use zImage, not vmlinux. On ARM we use the arch/arm/boot/zImage file similar to x86 to boot systems. Put that into the rpm as vmlinuz instead of the vmlinux ELF binary.
• Linux 3.1.2.
• drm/radeon/kms: fix up gpio i2c mask bits for r4xx (bnc#691052).
• ARM: create uImage, not zImage, so we can boot with u-boot
• patches.fixes/drm-radeon-kms-fix-up-gpio-i2c-mask-bits-for-r4xx.patch: Add missing git-commit.
• rpm/kernel-binary.spec.in: Do not have a separate make invocation for s390 and the rest.
• rpm/try-disable-staging-driver: Script to disable failing staging driver and restart make.
• Linux 3.1.3.
• intel_idle: Fix kvm -cpu host Null pointer enter function issue (bnc#726296)
• Build the kotd against 12.1, not Factory.
• rpm/kernel-binary.spec.in: Ignore staging failures only in vanilla only branches.
• Fix kernel-source spec to give ownership of the /usr/src/linux link to kernel-devel. kernel-source depends on kernel-devel, so this is correct.
• Linux 3.1.4.
• rpm/kernel-binary.spec.in: Make the -base package conflict with the main one.
• mm: Ensure that pfn_valid is called once per pageblock when reserving pageblocks (bnc#731261, bnc#730731)
• Import 12.1 GA kabi files.
• kabi/severities: Ignore changes to usb, nfs and some drivers for now.
• kabi: fix jiffies_to_clock_t breakage.
• Fix typo: Base package should not conflict with itself but with main package.
• Use GPL-2.0 as license tag (from http://spdx.org/licenses/) Only have one licenses line per file, the rest was just duplicated.
• rpm/kernel-binary.spec.in: Do not package the vmlinux image in the devel package.
• Adjust kernel-source.rpmlintrc for Linux 3.x
• Use versioned provides/obsoletes.
• Do not show rpmlint warnings.
• No self-obsoletions.
• Linux 3.1.5.
• Delete patches.fixes/drm-radeon-kms-fix-up-gpio-i2c-mask-bits-for-r4xx.patch.
• x86, x2apic: Enable the bios request for x2apic optout.
• Revert “USB: fix ehci alignment error”.
• kabi/severities: Check drivers/usb again
• Silence warning about dangling symlink and vdsos
• Silence missing defattr warning.
• batman-adv: Only write requested number of byte to user buffer (bnc#736149 CVE-2011-4604)
• batman-adv: bat_socket_read missing checks (bnc#736149 CVE-2011-4604)
• rpm/kernel-source.spec.in, rpm/mkspec: Fix linux tarball URL
• rpm/kernel-source.spec.in, rpm/mkspec: Fix tarball URL for -rcX and do not generate any URL for linux-next and vanilla snapshots.
• btrfs: Introduce btrfs_get_maps_dev() (bnc#672923)
• vfs: allow /proc/pid/maps to return a custom device (bnc#672923)
• Btrfs: make lzo the default compression scheme (FATE#306586)
• btrfs: add new ioctl to determine size of compressed file (FATE#306586).
• Sector Size check during Mount (bnc#724620)
• Btrfs: rewrite btrfs_trim_block_group() (FATE#306586).
• btrfs: allow cross-subvolume file clone (bnc#698540)
• Btrfs: fix leaked space in truncate (FATE#306586).
• Btrfs: fix how we do delalloc reservations and how we free reservations on error (FATE#306586).
• Btrfs: deal with enospc from dirtying inodes properly (FATE#306586).
• Btrfs: fix num_workers_starting bug and other bugs in async thread (FATE#306586).
• Btrfs: add allocator tracepoints (FATE#306586).
• Btrfs: fix btrfs_end_bio to deal with write errors to a single mirror (FATE#306586).
• Btrfs: drop spin lock when memory alloc fails (FATE#306586).
• Btrfs: check if the to-be-added device is writable (FATE#306586).
• Btrfs: try cluster but don’t advance in search list (FATE#306586).
• Btrfs: try to allocate from cluster even at LOOP_NO_EMPTY_SIZE (FATE#306586).
• Btrfs: fix meta data raid-repair merge problem (FATE#306586).
• Btrfs: skip allocation attempt from empty cluster (FATE#306586).
• Btrfs: skip block groups without enough space for a cluster (FATE#306586).
• Btrfs: start search for new cluster at the beginning (FATE#306586).
• Btrfs: reset cluster’s max_size when creating bitmap (FATE#306586).
• Btrfs: initialize new bitmaps’ list (FATE#306586).
• Btrfs: fix oops when calling statfs on readonly device (FATE#306586).
• Btrfs: Don’t error on resizing FS to same size (FATE#306586).
• Btrfs: fix deadlock on metadata reservation when evicting a inode (FATE#306586).
• btrfs scrub: handle -ENOMEM from init_ipath() (FATE#306586).
• Btrfs: remove free-space-cache.c WARN during log replay (FATE#306586).
• Btrfs: sectorsize align offsets in fiemap (FATE#306586).
• Btrfs: clear pages dirty for io and set them extent mapped (FATE#306586).
• Btrfs: wait on caching if we’re loading the free space cache (FATE#306586).
• Btrfs: prefix resize related printks with btrfs: (FATE#306586).
• btrfs: fix stat blocks accounting (FATE#306586).
• Btrfs: avoid unnecessary bitmap search for cluster setup (FATE#306586).
• Btrfs: fix to search one more bitmap for cluster setup (FATE#306586).
• btrfs: mirror_num should be int, not u64 (FATE#306586).
• btrfs: Fix up 32/64-bit compatibility for new ioctls (FATE#306586).
• Btrfs: fix barrier flushes (FATE#306586).
• Btrfs: fix tree corruption after multi-thread snapshots and inode_cache flush (FATE#306586).
• btrfs: rename the option to nospace_cache (FATE#306586).
• Btrfs: handle bio_add_page failure gracefully in scrub (FATE#306586).
• Btrfs: fix deadlock caused by the race between relocation (FATE#306586).
• Btrfs: only map pages if we know we need them when reading the space cache (FATE#306586).
• Btrfs: fix orphan backref nodes (FATE#306586).
• Btrfs: Abstract similar code for btrfs_block_rsv_add{, _noflush} (FATE#306586).
• Btrfs: fix unreleased path in btrfs_orphan_cleanup() (FATE#306586).
• Btrfs: fix no reserved space for writing out inode cache (FATE#306586).
• Btrfs: fix nocow when deleting the item (FATE#306586).
• Btrfs: tweak the delayed inode reservations again (FATE#306586).
• Btrfs: rework error handling in btrfs_mount() (FATE#306586).
• Btrfs: close devices on all error paths in open_ctree() (FATE#306586).
• Btrfs: avoid null dereference and leaks when bailing from open_ctree() (FATE#306586).
• Btrfs: fix subvol_name leak on error in btrfs_mount() (FATE#306586)
• Btrfs: fix memory leak in btrfs_parse_early_options() (FATE#306586).
• Btrfs: fix our reservations for updating an inode when completing io (FATE#306586).
• Btrfs: fix oops on NULL trans handle in btrfs_truncate (FATE#306586).
• btrfs: fix double-free ‘tree_root’ in ‘btrfs_mount()’ (FATE#306586).
• Btrfs: check for a null fs root when writing to the backup root log (FATE#306586).
• Btrfs: fix race during transaction joins (FATE#306586).
• Btrfs: fix a potential btrfs_bio leak on scrub fixups (FATE#306586).
• Btrfs: stop leaking btrfs_bios on readahead (FATE#306586).
• Btrfs: stop the readahead threads on failed mount (FATE#306586).
• Btrfs: fix extent_buffer leak in the metadata IO error handling (FATE#306586).
• Btrfs: fix the new inspection ioctls for 32 bit compat (FATE#306586).
• btrfs: integrating raid-repair and scrub-fixup-nodatasum (FATE#306586).
• btrfs: Moved repair code from inode.c to extent_io.c (FATE#306586).
• btrfs: Put mirror_num in bi_bdev (FATE#306586).
• btrfs: Do not use bio->bi_bdev after submission (FATE#306586).
• btrfs: btrfs_multi_bio replaced with btrfs_bio (FATE#306586).
• btrfs: new ioctls to do logical->inode and inode->path resolving (FATE#306586).
• btrfs scrub: add fixup code for errors on nodatasum files (FATE#306586).
• btrfs scrub: use int for mirror_num, not u64 (FATE#306586).
• btrfs: add mirror_num to extent_read_full_page (FATE#306586).
• btrfs scrub: bugfix: mirror_num off by one (FATE#306586).
• btrfs scrub: print paths of corrupted files (FATE#306586).
• btrfs scrub: added unverified_errors (FATE#306586).
• btrfs: added helper functions to iterate backrefs (FATE#306586).
• btrfs: use readahead API for scrub (FATE#306586).
• btrfs: hooks for readahead (FATE#306586).
• btrfs: initial readahead code and prototypes (FATE#306586).
• btrfs: state information for readahead (FATE#306586).
• btrfs: add READAHEAD extent buffer flag (FATE#306586).
• btrfs: add an extra wait mode to read_extent_buffer_pages (FATE#306586).
• Btrfs: fix delayed insertion reservation (FATE#306586).
• Btrfs: ClearPageError during writepage and clean_tree_block (FATE#306586).
• Btrfs: be smarter about committing the transaction in reserve_metadata_bytes (FATE#306586).
• Btrfs: make a delayed_block_rsv for the delayed item insertion (FATE#306586).
• Btrfs: add a log of past tree roots (FATE#306586).
• btrfs: separate superblock items out of fs_info (FATE#306586).
• Btrfs: use the global reserve when truncating the free space cache inode (FATE#306586).
• Btrfs: release metadata from global reserve if we have to fallback for unlink (FATE#306586).
• Btrfs: make sure to flush queued bios if write_cache_pages waits (FATE#306586).
• Btrfs: fix extent pinning bugs in the tree log (FATE#306586).
• Btrfs: make sure btrfs_remove_free_space doesn’t leak EAGAIN (FATE#306586).
• Btrfs: don’t wait as long for more batches during SSD log commit (FATE#306586).
• btrfs: ratelimit WARN_ON in use_block_rsv (FATE#306586).
• btrfs: do not allow mounting non-subvolumes via subvol option (FATE#306586).
• Btrfs: close all bdevs on mount failure (FATE#306586).
• Btrfs: fix a bug when opening seed devices (FATE#306586).
• btrfs: fix oops on failure path (FATE#306586).
• Btrfs: fix race between multi-task space allocation and caching space (FATE#306586).
• Btrfs: fix return value of btrfs_get_acl() (FATE#306586).
• Btrfs: pass the correct root to lookup_free_space_inode() (FATE#306586).
• Btrfs: do not set EXTENT_DIRTY along with EXTENT_DELALLOC (FATE#306586).
• Btrfs: fix direct-io vs nodatacow (FATE#306586).
• Btrfs: remove BUG_ON() in compress_file_range() (FATE#306586).
• Btrfs: fix array bound checking (FATE#306586).
• btrfs: return EINVAL if start > total_bytes in fitrim ioctl (FATE#306586).
• Btrfs: honor extent thresh during defragmentation (FATE#306586).
• btrfs: trivial fix, a potential memory leak in btrfs_parse_early_options() (FATE#306586).
• Btrfs: fix wrong max_to_defrag in btrfs_defrag_file() (FATE#306586).
• Btrfs: use i_size_read() in btrfs_defrag_file() (FATE#306586).
• Btrfs: fix defragmentation regression (FATE#306586).
• btrfs: fix memory leak in btrfs_defrag_file (FATE#306586).
• btrfs: check file extent backref offset underflow (FATE#306586).
• Btrfs: don’t flush the cache inode before writing it (FATE#306586).
• Btrfs: if we have a lot of pinned space, commit the transaction (FATE#306586).
• Btrfs: seperate out btrfs_block_rsv_check out into 2 different functions (FATE#306586).
• Btrfs: reserve some space for an orphan item when unlinking (FATE#306586).
• Btrfs: release trans metadata bytes before flushing delayed refs (FATE#306586).
• Btrfs: allow shrink_delalloc flush the needed reclaimed pages (FATE#306586).
• Btrfs: wait for ordered extents if we’re in trouble when shrinking delalloc (FATE#306586).
• Btrfs: don’t check bytes_pinned to determine if we should commit the transaction (FATE#306586).
• Btrfs: fix regression in re-setting a large xattr (FATE#306586).
• Btrfs: fix the amount of space reserved for unlink (FATE#306586).
• Btrfs: wait for ordered extents if we didn’t reclaim enough (FATE#306586).
• Btrfs: inline checksums into the disk free space cache (FATE#306586).
• Btrfs: take overflow into account in reserving space (FATE#306586).
• Btrfs: check the return value of filemap_write_and_wait in the space cache (FATE#306586).
• Btrfs: add a io_ctl struct and helpers for dealing with the space cache (FATE#306586).
• Btrfs: don’t skip writing out a empty block groups cache (FATE#306586).
• Btrfs: introduce mount option no_space_cache (FATE#306586).
• Btrfs: only inherit btrfs specific flags when creating files (FATE#306586).
• Btrfs: allow us to overcommit our enospc reservations (FATE#306586).
• Btrfs: break out of orphan cleanup if we can’t make progress (FATE#306586).
• Btrfs: use the global reserve as a backup for deleting inodes (FATE#306586).
• Btrfs: stop using write_one_page (FATE#306586).
• Btrfs: introduce convert_extent_bit (FATE#306586).
• Btrfs: check unused against how much space we actually want (FATE#306586).
• Btrfs: fix orphan cleanup regression (FATE#306586).
• Btrfs: use the inode’s mapping mask for allocating pages (FATE#306586).
• Btrfs: delay iput when deleting a block group (FATE#306586).
• Btrfs: make sure to unset trans->block_rsv before running delayed refs (FATE#306586).
• Btrfs: stop passing a trans handle all around the reservation code (FATE#306586).
• Btrfs: don’t get the block_rsv in btrfs_free_tree_block (FATE#306586).
• Btrfs: use the transactions block_rsv for the csum root (FATE#306586).
• Btrfs: handle enospc accounting for free space inodes (FATE#306586).
• Btrfs: put the block group cache after we commit the super (FATE#306586).
• Btrfs: set truncate block rsv’s size (FATE#306586).
• Btrfs: don’t increase the block_rsv’s size when emergency allocating space (FATE#306586).
• Btrfs: fix space leak when we fail to make an allocation (FATE#306586).
• Btrfs: fix call to btrfs_search_slot in free space cache (FATE#306586).
• Btrfs: allow callers to specify if flushing can occur for btrfs_block_rsv_check (FATE#306586).
• Btrfs: reduce the amount of space needed for truncates (FATE#306586).
• Btrfs: only reserve space in fallocate if we have to do a preallocate (FATE#306586).
• Btrfs: kill btrfs_truncate_reserve_metadata (FATE#306586).
• Btrfs: optimize how we account for space in truncate (FATE#306586).
• Btrfs: don’t try to commit in btrfs_block_rsv_check (FATE#306586).
• Btrfs: kill unused parts of block_rsv (FATE#306586).
• Btrfs: ratelimit the generation printk for the free space cache (FATE#306586).
• Btrfs: fix how we reserve space for deleting inodes (FATE#306586).
• Btrfs: use d_obtain_alias when mounting subvol/subvolid (FATE#306586).
• Btrfs: kill reserved_bytes in inode (FATE#306586).
• Btrfs: move stuff around in btrfs_inode to get better packing (FATE#306586).
• Linux 3.1.6.
• Revert “clocksource: Avoid selecting mult values that might overflow when adjusted”.
• Revert “inet: add a redirect generation id in inetpeer”.
• Delete patches.fixes/hfs-fix-hfs_find_init-sb-ext_tree-null-ptr-oops.patch.
• Delete patches.fixes/mm-Ensure-that-pfn_valid-is-called-once-per-pagebloc.patch.
• net: Add a flow_cache_flush_deferred function (bnc#737624)
• btrfs: use correct device for maps (bnc#672923).
• Delete patches.suse/0001-vfs-allow-proc-pid-maps-to-return-a-custom-device.patch.
• Delete patches.suse/0002-btrfs-Introduce-btrfs_get_maps_dev.patch.
• Linux 3.1.7.
• Update Xen patches to 3.1.7.
• patches.xen/1124-x86-undo-limit-pages.patch: x86: undo_limit_pages() must reset page count.
• patches.xen/1126-netback-invalidation-index.patch: netback: use correct index for invalidation in netbk_tx_check_mop().
• patches.xen/1134-blktap-locking.patch: blktap: fix locking (again) (bnc#724734)
• patches.xen/1135-blktap-map-once.patch: blktap: ensure mmap() is called only once per region.
• Delete patches.xen/xencons-tty_mutex.patch.
• staging: hv: hv_mouse: use KBUILD_MODNAME as drivername.
• Staging: hv: storvsc: Cleanup error handling in the probe function.
• Staging: hv: storvsc: Fix a bug in create_bounce_buffer() (bnc#724616)
• Staging: hv: storvsc: Fix checkpatch warnings.
• Staging: hv: storvsc: Fix error handling storvsc_host_reset().
• Staging: hv: storvsc: Fixup the error when processing SET_WINDOW command.
• Staging: hv: storvsc: Get rid of an unnecessary forward declaration.
• Staging: hv: storvsc: Implement per device memory pools.
• Staging: hv: storvsc: remove last usage of DPRINT_WARN.
• Staging: hv: storvsc: Support hot add of scsi disks.
• Staging: hv: storvsc: Support hot-removing of scsi devices.
• Staging: hv: storvsc: Upgrade the vmstor protocol version.
• Staging: hv: storvsc: Use mempools to allocate struct storvsc_cmd_request.
• Staging: hv: storvsc: Use the accessor function shost_priv().
• Staging: hv: storvsc: use the macro KBUILD_MODNAME.
• Staging: hv: storvsc: Use the unlocked version queuecommand.
• Staging: hv: storvsc: Cleanup storvsc_device_alloc() (bnc#724616)
• Staging: hv: storvsc: Disable clustering (bnc#724616)
• Staging: hv: storvsc: Fix a bug in copy_from_bounce_buffer() (bnc#724616)
• Staging: hv: storvsc: Fix a bug in storvsc_command_completion() (bnc#724616)
• Refresh patches.suse/staging-hv-storvsc-module-name.patch.
• Linux 3.1.8.
• Refresh patches.kabi/revert-inet-add-a-redirect-generation-id-in-inetpeer.patch.
• Delete patches.fixes/net-Add-a-flow_cache_flush_deferred-function.patch.
• Reintroduce removed blk_init_allocated_queue_node.
• ALSA: hda – Return the error from get_wcaps_type() for invalid NIDs (bnc#740118)
• Linux 3.1.9.
• kABI: struct urb fixup.
• Delete patches.fixes/reiserfs-force-inode-evictions-before-umount-to-avoid-crash.
• kABI: struct inet_peer fixup.
• Refresh patches.kabi/revert-clocksource-Avoid-selecting-mult-values-that-.patch.
• Delete patches.kabi/revert-inet-add-a-redirect-generation-id-in-inetpeer.patch.
• fsnotify: don’t BUG in fsnotify_destroy_mark() (bnc#689860)
• patches.fixes/proc-enable-writing-to-proc-pid-mem-revert.patch: proc: enable writing to /proc/pid/mem (bnc#742279 CVE-2012-0056)
• Fix auto-mic of ALC268 static quirks (bnc#742322)
• rpm/kernel-binary.spec.in: Remove the conflict between the main and base package again (bnc#743608)

Die folgenden Kernel-Changelogs sind die offiziellen Berichte zu den Änderungen von 3.1.1 bis einschließlich 3.1.9 vom Upstream kernel.org:
ChangeLog-3.1.1
ChangeLog-3.1.2
ChangeLog-3.1.3
ChangeLog-3.1.4
ChangeLog-3.1.5
ChangeLog-3.1.6
ChangeLog-3.1.7
ChangeLog-3.1.8
ChangeLog-3.1.9

Hinweis für Besitzer einer AMD-Grafikkarte, die AMD Catalyst auf ihrem openSUSE-System installiert haben:
Das fglrx-Kernelmodul muss nicht manuell gebaut werden. Dies geschieht nach einem Neustart vollautomatisch.

Weitere Informationen: openSUSE – proprietären Grafik-Treiber AMD Catalyst 12.1 als RPM installieren

Am 19.01.2012 hat Adobe im Adobe-Labs die 4. Beta-Version (11.2.202.183) des Flash Players für 32-bit wie auch 64-bit Systeme veröffentlicht.

Laut der Release Notes sind folgende Feature enthalten:

• Throttling event (new ThrottleEvent)
• Einige Bugfixes (laut dem Bugtracker von Adobe)

Wer noch einen Fehler oder Ungereimtheiten in der aktuellen Beta des Flash Player gefunden hat, so möchte ich den Bugtracker von Adobe empfehlen.

Die Installation des neuesten Flash Player auf openSUSE:

Hinweis: Die Installation wird in der Konsole mit root-Rechten durchgeführt. Hierzu wird der Flash Player und das zugehörige Packaging Skript heruntergeladen. Daraus wird ein RPM-Paket gebaut und auf Wunsch installiert.

Downloads:

• makerpm-flash-11.2-beta4.sh
• makerpm-flash-11.2-beta4.sh.sha1

1. Das Skript makerpm-flash-11.2-beta4.sh wie auch die Prüfsummendatei herunterladen:

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.2-beta4.sh

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.2-beta4.sh.sha1

2. Die Prüfsumme vom heruntergeladenen Skript prüfen:

   sha1sum -c makerpm-flash-11.2-beta4.sh.sha1

   Idealerweise sollte folgende Ausgabe erscheinen, andernfalls ist das Skript defekt und sollte ersetzt werden:

   makerpm-flash-11.2-beta4.sh: OK

3. Das Skript ausführbar machen:

   chmod 755 makerpm-flash-11.2-beta4.sh

4. Nun gibt es 3 Möglichkeiten die Pakete zu erstellen und zu installieren:
   1. Auf einem reinen KDE-System:

      ./makerpm-flash-11.2-beta4.sh -i kde

   2. Auf einem reinen GNOME- bzw. GTK-System:

      ./makerpm-flash-11.2-beta4.sh -i gnome

   3. Sowohl auf einem KDE-System wie auch auf einem GNOME-System:

      ./makerpm-flash-11.2-beta4.sh -i all

      oder einfach nur

      ./makerpm-flash-11.2-beta4.sh -i

   Dann entspannt zurück lehnen und warten bis die Installation abgeschlossen ist. Das Skript ist wie gewohnt gesprächig und die jeweilige Aktion kann verfolgt werden.

5. Rechner neustarten und Flash Player 11.2 Beta 4 testen.

Feedbacks sind immer willkommen.

Have a lot of fun!

AMD Catalyst 12.1 (fglrx 8.930) wurde veröffentlicht. Das Skript makerpm-amd-12.1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.3, 11.4 und 12.1. Hinweis: AMD hat den Installer von ati-driver-installer… in amd-driver-installer… umbenannt. Im Zuge dessen habe ich ebenfalls das Skript von makerpm-ati… in makerpm-amd… umbenannt.

Nach einem Test dieser AMD Catalyst Version ist die GNOME 3.2-Problematik (Flackern und Bildschirmrisse) endlich behoben worden. Laut AMD sollten die Notebooks mit der PowerXpress-Technologie (Intel-/AMD-Grafikkarte – discrete GPU) wieder funktionieren. Ich wäre sehr verbunden, wenn jemand diese Funktionalität für mich testen könnte und bitte um entsprechende Rückmeldung. Vielen Dank.

Zudem habe ich die Generierung des Systemreport vom Skript überarbeitet, um weitere Systeminformationen abzufragen. Ein aktualisiertes Packaging Skript habe ich beigefügt und wird separat heruntergeladen. Ab sofort können die User von Balsam Professional (ein Ableger von openSUSE) das Skript verwenden. Das makerpm-Skript hat nun die Version 5.0 erreicht und bin ziemlich stolz darauf, dass die makerpm-Skript-Reihe sich seit 2 Jahren erfolgreich bewährt hat. Vielen Dank für eure Unterstützung und mit eurer Hilfe (Feedbacks und eingereichte Systemreports) habe ich mich für euch mit AMD auseinander gesetzt, um die Fehler im Treiber beheben zu lassen. Ich bitte euch nicht aufzuhören, sondern fleißig weiterhin Fehler zu melden. Vielen Dank.

Downloads:

• Skript: makerpm-amd-12.1.sh
• SHA1: makerpm-amd-12.1.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-ati-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-12.1.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-12.1.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-amd-12.1.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

Die Entwicklung an openSUSE 12.2 hat bereits begonnen. Die jeweiligen Meilensteine wurden festgelegt und sieht wie folgt aus.

• 09.02.2012 – Milestone 1
• 03.03.2012 – Milestone 2
• 05.04.2012 – Milestone 3
• 26.04.2012 – Milestone 4
• 24.05.2012 – Beta 1
• 14.06.2012 – Release Candidate 1
• 28.06.2012 – Release Candidate 2
• 06.07.2012 – Gold Master
• 11.07.2012 – openSUSE 12.2 Final Release

Quelle: http://en.opensuse.org/openSUSE:Roadmap

Die openSUSE 12.2 Entwicklungs-CD und -DVD werden erst ab dem jeweiligen Meilenstein gebaut und veröffentlicht.
Download ab dem 09.02.2012: http://software.opensuse.org/developer/

Hilfe zum Projekt ist immer willkommen. Egal ob man in der Wiki mitarbeitet, sich am openFATE beteiligt, Pakete in unserem OBS für openSUSE bauen, in der Mailing Liste; im hauseigenen Forum oder auch im IRC Hilfestellung gibt, Fehler in openSUSE via Bugreport melden, u.v.m. Über Mitstreiter an meiner Seite würde ich mich freuen. Ein paar Voraussetzungen, wie sie in jedem Projekt gibt: ein wenig Freizeit entbehren, am Ball bleiben, sich gegenzeitig motivieren/helfen.

Eine weitere wichtige Meldung ist, dass der Support für openSUSE 11.3 am 20.01.2012 eingestellt wurde. Um weiterhin mit Updates versorgt zu werden, ist es empfohlen in nächster Zeit auf openSUSE 11.4 oder 12.1 umzusteigen.

Quelle: http://lists.opensuse.org/opensuse-announce/2012-01/msg00001.html

Am 20.12.2011 hat Adobe im Adobe-Labs die 3. Beta-Version (11.2.202.160) des Flash Players für 32-bit wie auch 64-bit Systeme veröffentlicht.

Laut der Release Notes sind folgende Feature enthalten:

• Multithreaded Video Dekodierung
• Maussperre, relative Koordinaten der Maus, rechter und mittler Mausklick-Event
• Einige Bugfixes (laut dem Bugtracker von Adobe)

Wer noch einen Fehler oder Ungereimtheiten in der aktuellen Beta des Flash Player gefunden hat, so möchte ich wärmstens den Bugtracker von Adobe empfehlen. Die Entwickler nehmen jeden eingelieferten Bugreport ernst und gehen dem gemeldeten Fehler nach.

Die Installation des neuesten Flash Player auf openSUSE:

Hinweis: Die Installation wird in der Konsole mit root-Rechten durchgeführt. Hierzu wird der Flash Player und das zugehörige Packaging Skript heruntergeladen. Daraus wird ein RPM-Paket gebaut und auf Wunsch installiert.

Downloads:

• makerpm-flash-11.2-beta3.sh
• makerpm-flash-11.2-beta3.sh.sha1

1. Das Skript makerpm-flash-11.2-beta3.sh wie auch die Prüfsummendatei herunterladen:

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.2-beta3.sh

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.2-beta3.sh.sha1

2. Die Prüfsumme vom heruntergeladenen Skript prüfen:

   sha1sum -c makerpm-flash-11.2-beta3.sh.sha1

   Idealerweise sollte folgende Ausgabe erscheinen, andernfalls ist das Skript defekt und sollte ersetzt werden:

   makerpm-flash-11.2-beta3.sh: OK

3. Das Skript ausführbar machen:

   chmod 755 makerpm-flash-11.2-beta3.sh

4. Nun gibt es 3 Möglichkeiten die Pakete zu erstellen und zu installieren:
   1. Auf einem reinen KDE-System:

      ./makerpm-flash-11.2-beta3.sh -i kde

   2. Auf einem reinen GNOME- bzw. GTK-System:

      ./makerpm-flash-11.2-beta3.sh -i gnome

   3. Sowohl auf einem KDE-System wie auch auf einem GNOME-System:

      ./makerpm-flash-11.2-beta3.sh -i all

      oder einfach nur

      ./makerpm-flash-11.2-beta3.sh -i

   Dann entspannt zurück lehnen und warten bis die Installation abgeschlossen ist. Das Skript ist wie gewohnt gesprächig und die jeweilige Aktion kann verfolgt werden.

5. Rechner neustarten und Flash Player 11.2 Beta 3 testen.

Sollte etwas mit dem Skript nicht funktionieren, dann sagt mir bitte Bescheid. Danke!

Have a lot of fun!

AMD Catalyst 11.12 (fglrx 8.920) wurde veröffentlicht. Das Skript makerpm-ati-11.12.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.3, 11.4 und 12.1

Diesmal hat AMD überpünktlich die neue AMD Catalyst Version herausgegeben. Die GNOME 3.2-Problematik (Flackern und Bildschirmrisse) ist in dieser Version noch nicht behoben worden. Beim Test von AMD Catalyst 12.1 RC1 mit GNOME 3.2 treten diese Probleme nicht mehr auf.

Beim Notebook mit der PowerXpress-Technologie (Intel-/AMD-Grafikkarte – discrete GPU) kann ich leider mangels Hardware nicht testen, ob es unter openSUSE 12.1 wieder funktioniert und nicht mehr abstürzt. Ich wäre sehr verbunden, wenn hier jemand für mich testen könnte und bitte um entsprechende Rückmeldung. AMD weiß über dieses Problem mit PowerXpress seit Mitte November Bescheid. Falls es diesbezüglich noch Probleme gibt, werde ich mir AMD nochmal vorknöpfen.

Auf Empfehlung eines Bloglesers (Stefan) habe ich den Ablauf zur Erstellung und Upload des Reports im makerpm-ati-Skript (Option -ur bzw. –uploadreport) geändert. Diesmal wird auf Rückfrage der Report angezeigt und mit einer erneuten Rückfrage wird bestätigt, ob der Report hochgeladen werden soll. Ein Dank geht an dieser Stelle an Stefan für sein wertvolles Feedback zum Skript.

Downloads:

• Skript: makerpm-ati-11.12.sh
• SHA1: makerpm-ati-11.12.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-ati-Skript

Über das makerpm-ati-Skript

Das Skript makerpm-ati-11.12.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-ati-11.12.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-11.12.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

AMD Catalyst 11.11 (fglrx 8.911) wurde veröffentlicht. Das Skript makerpm-ati-11.11.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.3, 11.4 und 12.1

Okay, das war jetzt ein langer Abend für mich gewesen. Ich habe seit gestern Abend intensiv nach dem Problem von GNOME 3.2 und der XvBA Hardware-Beschleunigung unter openSUSE 12.1 geforscht. Dabei hat ein Blog-Leser darauf aufmerksam gemacht, dass die direkte Installation vom AMD Catalyst das Problem lösen könnte. Jedoch halte ich von der direkten Installation nichts, da AMD gerne die vorhandenen Dateien verschiebt und so die Integrität der Dateien gefährdet. Aber ich musste ja irgendwo anfangen und habe das RPM-Paket und die direkte AMD-Installation verglichen. Ich konnte im Prinzip keinen Unterschiede erkennen, außer das manche Dateien in einem ganz anderen Verzeichnis installiert waren, wo sie eigentlich nix zu suchen hatten. Ich konnte mir zunächst keinen Reim machen, warum die RPM-Installation versagt hat. Bis mir eine ganz banale Geschichte eingefallen ist. Ein bestimmter Suchpfad von ld.so.conf könnte evtl. bei openSUSE 12.1 rausgeflogen sein. Ich habe meine derzeitige openSUSE 11.4 /etc/ld.so.conf mit der von openSUSE 12.1 verglichen und siehe da einige Suchpfade waren entfernt worden. Ich habe das notwendige Suchpfad zu /usr/X11R6/lib bzw. auch /usr/X11R6/lib64 in /etc/ld.so.conf.d/fglrx.conf für den fglrx-Treiber angelegt und siehe da “vainfo” sagt mir, dass alles in Ordnung ist. Jetzt kommt die spannende Frage: Ist das Problem mit GNOME 3.2 nun behoben? Die Antwort: JA!!! Also, liebe Leute, ladet euch das makerpm-ati-Skript mit dem aktualisierten Packaging Skript herunter, installiert den Treiber wie gewohnt und habt Spaß mit der neuen openSUSE 12.1 und dem AMD Catalyst Treiber.

Downloads:

• Skript: makerpm-ati-11.11.sh
• SHA1: makerpm-ati-11.11.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-ati-Skript

Über das makerpm-ati-Skript

Das Skript makerpm-ati-11.11.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-ati-11.11.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-11.11.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

Am Samstag morgens um ca. 9.00 Uhr war ich am Rheinischen Industriemuseum (Kurz: RIM) zur Veranstaltung OpenRheinRuhr in Oberhausen eingetroffen. Voll gepackt mit meinen technischem Equipment, das aus einem Netbook (openSUSE / KDE 4.7.3) und einem Tablet-PC (WeTab / openSUSE 11.4 / KDE 4.7.3 / Plasma Active One) bestand, steuerte ich unseren openSUSE-Stand an. Jan Krings und Marcel Richter hatten bereits den openSUSE-Stand aufgebaut. Jan hatte sein Notebook (openSUSE 12.1 / Goldmaster) aufgestellt und an einen größeren Monitor angeschlossen und war somit der Demo-Rechner für die Interessenten. Außerdem hatte er auch auf seinem Tablet-PC openSUSE 12.1 GM aufgespielt und diente neben meinem Tablet-PC ebenfalls als Demo-Rechner. So hatten wir insgesamt 3 Computer mit openSUSE, die man nach Herzenslust ausprobieren konnte.

Der Oberbürgermeister von Oberhausen erklärte die Messe pünktlich um 9.30 Uhr in einer Rede für “eröffnet”. Kaum waren die ersten Besucher da, wurden schon die Tablet-PCs ordentlich bedient. Ich habe schon vermutet, dass die Tablet-PCs die Aufmerksamkeit der Besucher wie auch andere Aussteller erregen. Aber das es sich doch zu einem Renner entwickelte, konnte ich selbst nicht richtig fassen. Manche wollten einfach nur wissen, wie man Linux auf einen WeTab bekam. Andere wollten wissen, ob man es komplett so kaufen kann. Ansonsten war der openSUSE-Stand gut besucht. Es gab auch Leerläufe, was ich eher den Vorträgen anrechne und die anderen Aussteller auch davon betroffen waren.

Neben uns waren auch 2 Stände, Thomas Groß von teegee / LAX und Dipl.-Ing. Stefan Schäfer / invis-Server, die ebenso ihre Produkte komplett auf einer openSUSE-Installation laufen haben. So waren wir quasi eine etwas größere openSUSE-Ecke. Stefan Schäfer kannte mich durch das makerpm-ati-Skript und hat ein großes Lob für die Arbeit des Skriptes ausgesprochen. Ich war wirklich baff. Dann sah ich unter anderem noch einige bekannte Gesichter wieder. Besonders der KDE-Junge (auf dem Foto links) war mir lustigerweise noch in Erinnerung geblieben. Er konnte die Finger von openSUSE in der letzten so wie auch in der diesjährigen Veranstaltung einfach nicht lassen.

Zum Social Event ab 18 Uhr kamen die Pizzen nacheinander in Großbestellungen herein. Der Pizza-Proxy hatte dieses Jahr besser funktioniert als im letzten Jahr (laut Aussage von Jan). Dann hat die Version 2.0 ja doch ihre Berechtigung. Der Social Event ist nur ein Treffen unter den Aussteller um den Abend ausklingen zu lassen. Um ca. 20.30 Uhr trat ich die Heimreise (ca. 30 Minuten mit dem Auto) an.

Am Sonntag waren etwas weniger Besucher auf der Ausstellung, was an und für sich normal ist. Dafür konnte man sich mit einigen Besucher auch in Ruhe unterhalten. Der nette KDE-Mensch hatte sich auch das Tablet-PC von Jan geschnappt, um mit KDE Plasma Active One herumzuspielen oder auch auf seinem KDE-Stand zu präsentieren. Mich hat es doch sehr verwundert, warum er nicht einen Tablet-PC geholt und ebenso KDE Plasma Active One installiert hat. Das konnte er mir auch nicht so richtig erklären.

Es war für mich als Aussteller eine neue und positive Erfahrung. Es hat mir Spaß gemacht und möchte gerne im nächsten Jahr auf der OpenRheinRuhr in Oberhausen wieder dabei sein. Hoffentlich auch wieder mit Jan und Marcel. Vielleicht bekommen wir auch nochmal Verstärkung. An dieser Stelle möchte ich mich auch bei den Organisatoren wie auch dessen Crew bedanken, die für einen reibungslosen Ablauf und sich auch um die Aussteller wie auch Besucher gekümmert haben. *Daumen_hoch*

Am kommenden Samstag und Sonntag (12.11.-13.11.2011) öffnet die OpenRheinRuhr ihre Pforten. Die Öffnungszeiten sind an beiden Tagen von 9.30 Uhr bis 18.00 Uhr. Der Oberbürgermeister von Oberhausen wird die Messe am Samstag morgens um 9.30 Uhr eröffnen.

Viele freiwillige Helfer sind vor Ort, um die Veranstaltung zu unterstützen und für den reibungslosen Betrieb zu sorgen. Im letzten Jahr waren es nur 42 Aussteller. Diesmal sind es 61 Aussteller (Eine Liste der Aussteller befindet sich weiter unten im Artikel).

Für neugierige Besucher, Open-Source-Begeisterte wie auch Linux-Neulinge (auch alte Linux-Hasen sind willkommen ) gibt es jede Menge Informationen zu den offenen Projekten an den jeweiligen Ständen. Es werden wieder spannende Vorträge am Samstag und Sonntag gehalten.

Natürlich gibt es auch wieder einen Pizza-Proxy. Die berühmte DDoS-Attacke auf die Pizza-Buden rund um Oberhausen. Diesmal mit einem Upgrade auf die Version 2.0, weil die Version 1.0 im letzten Jahr nicht so rund gelaufen ist. Die Pizza-Buden sind unter der Last nicht mehr mit dem Backen hinterher gekommen. Dazu gibt es auch am Samstag einen Vortrag.

Der Eintrittspreis beträgt 5,- Euro an der Tageskasse und gilt für das ganze Wochenende. Mit dieser Eintrittskarte können die Besucher auch die Dauerausstellung des Rheinischen Industriemuseums kostenlos besuchen.

Anreise: http://openrheinruhr.de/anreise.html

openSUSE hat einen eigenen Stand und das Team besteht aus:

• Jan Krings
• Marcel Richter
• Sebastian Siebert (meiner Wenigkeit… )

Wir verteilen wieder openSUSE-DVDs und stehen für Fragen zur Verfügung.

Die Liste aller Aussteller:

• AllBSD
• Arbeitskreis Vorratsdatenspeicherung
• Blender
• Bytemine
• C&L Verlag
• CaCert
• Chaosdorf
• Debian
• Deutschsprachige Anwendervereinigung TeX e.V.
• Drupal Usergroup Ruhrgebiet
• Fedora
• Forth-Gesellschaft e.V.
• Freifunk Rheinland e.V.
• FSFE
• FSP Computer & Netzwerke
• FSuB – Freie Software und Bildung e.V.
• Geany
• GONICUS GmbH
• guug – German Unix User Group
• Heinlein Support
• invis Server
• J-Worker Markus Rouenhoff
• Joomla User Group im Pott
• Kajona
• KaMUX-Projekt
• KDE
• Kernelconcepts
• LAX – linux administration exchange
• LibreOffice / The Document Foundation
• LinOTP
• Linux From Scratch
• Linux Professional Institute
• Linux-Schmie.de Michael Gisbers
• LUGOR
• LW-Systems
• Mageia
• Mandrivauser
• Matrica
• novero
• Open Source Press
• Open Source School
• OpenOffice.org
• OpenSource Service 42 Karsten Jäger
• OpenStreetMap
• openSUSE
• OTRS-Community
• Perl-Services
• PING e.V. (Private Internet Nutzer Gemeinschaft e.V.)
• PostgreSQL
• ProArchCon GmbH
• Sidux
• Skolelinux
• soIT
• Subtle
• terrashop.de
• Tine2.0 Community
• Typo3 Certification
• Ubuntu
• Univention
• Xfce
• Yate – Yet Another Telephony Engine

Das dritte Kernel-Update für openSUSE 11.4 ist draußen und bringt hauptsächlich Fehlerbereinigungen mit sich und schließt einige Sicherheitslecks. Dies wird von meiner Seite aus voraussichtlich die letzte Kernel-Update-Mitteilung für openSUSE 11.4 sein. Bei der nächsten Kernel-Update-Mitteilung wird der Fokus auf openSUSE 12.1 ausgerichtet.

Das Kernel-Update kann über YaST2 oder per zypper eingespielt werden:

zypper up

Die offizielle Ankündigung zum Kernel-Update werde ich an dieser Stelle nachreichen.

Ein Auszug der Changelog aus der RPM:

• x86, mtrr: lock stop machine during MTRR rendezvous sequence (bnc#672008)
• Delete patches.arch/mtrr_stop_machine_quick_fix.patch
• patches.fixes/validate-size-of-efi-guid-partition-entries.patch: Validate size of EFI GUID partition entries (bnc#692784, CVE-2011-1776)
• patches.xen/1098-blkfront-cdrom-ioctl-check.patch: blkfront: avoid NULL de-reference in CDROM ioctl handling.
• Refresh other Xen patches.
• USB: OHCI: fix another regression for NVIDIA controllers (bnc#682204)
• cifs: fix possible memory corruption in CIFSFindNext (bnc#714001)
• TTY: pty, fix pty counting (bnc#711203)
• Refresh patches.fixes/pty-fix-pty-counting.patch
• cifs: always do is_path_accessible check in cifs_mount (bnc#718028)
• Update patches.fixes/cifs-always-do-is_path_accessible-check-in-cifs_moun.patch (bnc#718028, CVE-2011-3363)
• patches.fixes/ksm-fix-null-pointer-dereference-in-scan_get_next_rmap_item.patch ksm: fix NULL pointer dereference in scan_get_next_rmap_item (bnc#697901, CVE-2011-2183)
• Config cleanups. CONFIG_OLPC should be enabled only for i386 non PAE
• Provide memory controller swap extension.Keep the feature disabled by default. Use swapaccount=1 kernel boot parameter for enabling it.
• patches.fixes/fuse-check-size-of-fuse_notify_inval_entry-message.patch: fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message (bnc#716901, CVE-2011-3353)
• perf: Fix software event overflow (bnc#712366, CVE-2011-2918)
• memsw: remove noswapaccount kernel parameter (bnc#719450)
• cifs: add fallback in is_path_accessible for old servers (bnc#718028)
• novfs: fix off-by-one allocation error (bnc#669378, bnc#719710)
• novfs: fix some kmalloc/kfree issues (bnc#669378, bnc#719710)
• novfs: fix some DirCache locking issues (bnc#669378, bnc#719710)
• ext4: Fix max file size and logical block counting of extent format file (bnc#706374)
• drm/radeon/kms: Fix I2C mask definitions (bnc#712023)
• Include patches.fixes/drm-radeon-kms-fix-i2c-masks.patch, forgotten in previous commit.
• ACPICA: Fix issues/fault with automatic “serialized” method support (bnc#678097)
• novfs: Unable to change password in the Novell Client for Linux (bnc#713229)
• novfs: last modification time not reliable (bnc#642896)
• novfs: unlink directory after unmap (bnc#649625)
• fs: novfs: Fix exit handlers on local_unlink (bnc#649625)
• novfs: “Unable to save Login Script” appears when trying to save a user login script (bnc#638985)
• fs: novfs: Limit check for datacopy between user and kernel space.
• novfs: Fix checking of login id (bnc#626119)
• novfs: Set the sticky bit for the novfs mountpoint (bnc#686412)
• Ecryptfs: Add mount option to check uid of device being mounted = expect uid (bnc#711539, CVE-2011-1833)

Hinweis für Besitzer einer AMD/ATI-Grafikkarte, die AMD Catalyst auf ihrem openSUSE-System installiert haben:
Man muss nicht mehr manuell ein neues fglrx-Kernelmodul bauen. Dies geschieht nach einem Neustart vollautomatisch.

Weitere Informationen: openSUSE – proprietären Grafik-Treiber ATI Catalyst 11.10 als RPM installieren

AMD Catalyst 11.10 (fglrx 8.902) wurde veröffentlicht. Das Skript makerpm-ati-11.10.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.3, 11.4 und 12.1 (experimentell).

Die Installationsanleitung mit dem makerpm-ati-Skript habe ich komplett ausgelagert und befindet sich in der Wiki von opensuse.org. Wie kommt es? Ganz einfach, Lisufa, vom deutschen Wiki-Team wie auch Blog-Kollege hatte mich gebeten, die Anleitung zu überarbeiten. In Zukunft werde ich diese Wiki-Seite pflegen und weiter ausbauen. Ich denke, dass der Platz gut gewählt ist. Die Wiki sollte bei Problemen und Fragen auch die erste zentrale Anlaufstelle werden und lädt auch zum Mitmachen ein, um die Wiki-Seite zu erweitern. Ich würde mich über Mitstreiter zur Wiki-Seite freuen. Außerdem stehe ich wie gewohnt für Hilfe zum AMD-Treiber oder auch als direkter Vermittler zwischen openSUSE User und AMD zur Seite. (Okay, jetzt muss ich noch ein openSUSE-Projekt vor dem Release von openSUSE 12.1 zu Ende entwickeln. Ich hänge da schon seit einigen Wochen daran und sollte eine Überraschung für euch werden.)

http://dewiki.opensuse.org/SDB:AMD/ATI-Grafiktreiber

Downloads:

• Skript: makerpm-ati-11.10.sh
• SHA1: makerpm-ati-11.10.sh.sha1

Installationsanleitung:
http://dewiki.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-ati-Skript

Über das makerpm-ati-Skript

Das Skript makerpm-ati-11.10.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-ati-11.10.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-11.10.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

AMD Catalyst 11.9 (fglrx 8.892) wurde veröffentlicht. Das Skript makerpm-ati-11.9.sh steht ab sofort zum Download zur Verfügung.

Wichtige Änderungen in AMD Catalyst 11.9 (eine öffentliche ChangeLog seitens AMD für den Linux-Treiber gibt es leider noch nicht):

• Es gab da bereits ein offenes Geheimnis, dass mit dieser Version nun offiziell GNOME 3 unterstützt wird.

Für AMD Catalyst 11.9 stelle ich an dieser Stelle später ein Cheat Sheet bereit.

In eigener Sache:
Ich möchte mich recht herzlich für die vielen Spenden bedanken. Die Spende wird dazu verwendet, um einen 2. Monitor und zusätzlich noch eine moderne AMD Radeon HD Grafikkarte zu erwerben. Noch habe ich nicht den idealen Monitor wie auch AMD Grafikkarte gefunden und bin daher noch auf der Suche. Wer eine Empfehlung abgeben möchte, kann es gerne über die Kommentarfunktion tun. Ich hoffe, dass ich spätestens Ende Oktober die Hardware hier habe und somit die Monitore im Dual-Head-Betrieb testen kann und euch auch auf diesem Gebiet helfen kann.

Inhaltsverzeichnis

• Einleitung
• Hilfe, es funktioniert nicht!
• RPM mit dem Skript makerpm-ati-11.9.sh bauen (empfohlen)
• RPM manuell bauen (für Fortgeschrittene)
• Troubleshooting
  1. Nach dem Booten sieht man die Konsole (Problem mit der Konfiguration des X-Servers)
  2. Nach dem Booten hat man einen schwarzen Bildschirm (Problem mit dem Kernel-Mode-Setting)
  3. Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert
  4. Arbeitsflächen-Effekte (Compositing) in KDE 4.5 lassen sich gar nicht mehr aktivieren
  5. In Firefox oder Thunderbird erscheinen schwarze Flächen
  6. Ein Wasserzeichen erscheint unten rechts
  7. Der Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt?

Einleitung

Die Anleitung funktioniert mit 11.3 und 11.4.

*** Wichtiger Hinweis zum ATI-Repo ***
Im ATI-Repo befindet sich der ältere ATI-Catalyst 11.1 (fglrx 8.812) Treiber. Es kann durchaus passieren, dass neuere Grafikkarten noch nicht unterstützt werden. Zudem werden die Treiber mit einer Verzögerung von 1-2 Monaten gebaut und veröffentlicht.

Diese Anleitung wie auch das Skript werden regelmäßig aktualisiert. Es lohnt sich daher öfter mal vorbei zu schauen oder im Feedreader zu speichern.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-11.9.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Hinweis: Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fglrx-Treiber wird mit der Installation des AMD Catalyst RPM-Paket automatisch entfernt.

Mit vorhandene fglrx-Treiber sind z.B. folgende gemeint:

• ati-fglrxG01-kmp-{default,desktop,pae,…}
• ati-fglrxG02-kmp-{default,desktop,pae,…}
• x11-video-fglrxG02

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Troubleshooting vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-ati-11.9.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-11.9.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

RPM mit dem Skript bauen

Das Skript makerpm-ati-11.9.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Downloads:

• Skript: makerpm-ati-11.9.sh
• SHA1: makerpm-ati-11.9.sh.sha1

Empfohlene Vorgehensweise:

Man benötigt hierfür die Konsole mit root-Rechten, um das Skript auszuführen.

1. Das Skript herunterladen:

   wget http://www.sebastian-siebert.de/downloads/makerpm-ati-11.9.sh

2. Die Prüfsummendatei herunterladen:

   wget http://www.sebastian-siebert.de/downloads/makerpm-ati-11.9.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

   sha1sum -c makerpm-ati-11.9.sh.sha1

   Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

   makerpm-ati-11.9.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

   chown root:root makerpm-ati-11.9.sh
   chmod 744 makerpm-ati-11.9.sh

5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert (bzw. aktualisiert).

   ./makerpm-ati-11.9.sh -i

6. Den Rechner neustarten:

   reboot

RPM manuell bauen

Da nun endlich das von mir neugeschriebene Packaging Skript im ATI-Installer enthalten ist, ist die Installation des Treibers ziemlich einfach geworden.

Folgende Entwicklungswerkzeuge bzw. -packages werden vom gebauten RPM-Paket als benötigt eingestuft und von YaST2/zypper automatisch mitinstalliert:

• gcc
• make
• patch
• kernel-devel
• kernel-source
• kernel-{default,desktop,pae}-devel
• kernel-syms

Folgende Schritte werden auf einem 32-bit wie auch 64-bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
   https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-11-9-x86.x86_64.run
   Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.
2. Den Bau des RPM-Packages anstoßen:

   sh ./ati-driver-installer-11-9-x86.x86_64.run --buildpkg SuSE/SUSE-autodetection

3. Das RPM-Package installieren:

   zypper install fglrx*8.89*.rpm

4. Den Rechner neustarten:

   reboot

Troubleshooting:

1. Nach dem Booten sieht man die Konsole (Problem mit der Konfiguration des X-Servers)
2. Nach dem Booten hat man einen schwarzen Bildschirm (Problem mit dem Kernel-Mode-Setting)
3. Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert
4. Arbeitsflächen-Effekte (Compositing) in KDE 4.5 lassen sich gar nicht mehr aktivieren
5. In Firefox oder Thunderbird erscheinen schwarze Flächen
6. Ein Wasserzeichen erscheint unten rechts
7. Der Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt?

1. Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

   einfache Variante:

   Vorher noch in den Runlevel 3 wechseln:

   init 3

   Bei einem Monitor (Single-Modus):

   ./makerpm-ati-11.9.sh -c single

   Bei zwei Monitore (Dual-Modus):

   ./makerpm-ati-11.9.sh -c dual

   Danach den Rechner neustarten.

   Fortgeschrittene Variante:

   1. X-Server-Konfiguration verschieben, falls vorhanden:

      mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

   2. Von aticonfig eine neue Konfigurationsdatei erzeugen lassen: (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

      Bei einem Monitor (Single-Modus):

      aticonfig --initial --input=/etc/X11/xorg.conf

      oder bei zwei Monitore (Dual-Modus):

      aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

2. Wenn man vor einem schwarzen Bildschirm sitzt und man weder die Konsole noch den Desktop sieht, dann liegt es höchstwahrscheinlich am neueingeführten Kernel-Mode-Setting (auch KMS genannt). Das Problem läßt sich durch Deaktivierung des KMS beheben.

   einfache Variante:

   Mit dem Skript das KMS dauerhaft deaktivieren:

   ./makerpm-ati-11.9.sh -kms no

   Fortgeschrittene Variante:

   Es gibt 2 Möglichkeiten KMS zu deaktivieren:

   • Als Bootparameter in GRUB oder LILO: nomodeset
   • KMS im Initial Ramdisk grundsätzlich deaktivieren. Der nachfolgende Befehl schaltet das KMS in der Konfiguration /etc/sysconfig/kernel auf NO_KMS_IN_INITRD=”yes” aus.

     sed -i 's/^NO_KMS_IN_INITRD=.*/NO_KMS_IN_INITRD="yes"/g' /etc/sysconfig/kernel

     Unter openSUSE Tumbleweed bzw. openSUSE Factory:

     sed -i 's/^KMS_IN_INITRD=.*/KMS_IN_INITRD="no"/g' /etc/sysconfig/kernel

     Anschließend die Initial Ramdisk neubauen lassen:

     mkinitrd

3. Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD Catalyst 11.9 fehlschlägt. Hierzu gibt es eine einfache Lösung:
   1. Im KDE-Menü auf Systemeinstellungen klicken
   2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
   3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
   4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
   5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
   6. Abschließend auf Anwenden klicken

   Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

4. Wenn das Compositing im OpenGL-Modus in KDE 4.5 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

   Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

   grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

   Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit “OpenGLIsUnsafe” für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

   sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

   Hintergrundinfo:
   Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
   Quellcode von kwincompositing
   der Diff vom Quellcode zur Revision 1079919

5. Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

   einfache Variante:

   ./makerpm-ati-11.9.sh -old2ddriver yes

   Fortgeschrittene Variante:

   aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

   Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

   einfache Variante:

   ./makerpm-ati-11.9.sh -old2ddriver no

Fortgeschrittene Variante:

aticonfig --del-pcs=DDX,ForceXAA

6. Ein Wasserzeichen erscheint unten rechts. Wie entfernt man das? Glücklicherweise habe ich ein Skript geschrieben, dass dieses Wasserzeichen entfernt.

   Download: ati-remove-water-mark.sh
   SHA1: ati-remove-water-mark.sh.sha1

   Sobald man das o.g. Skript heruntergeladen hat, führt man ihn wie folgt aus:

   su -c 'sh ./ati-remove-water-mark.sh'

   Danach den Rechner neustarten.

7. Der Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt? Hier kann man leider nur den Radeon-Treiber verwenden. Man öffnet die Konfigurationsdatei /etc/X11/xorg.conf.d/50-device.conf mit root-Rechten, um diese bearbeiten zu können. Einfach den Krunner mittels Tastenkürzel ALT+F2 öffnen und folgende Befehlszeile eingeben und abschließend mit Enter bestätigen:

   kdesu kwrite /etc/X11/xorg.conf.d/50-device.conf

   In der Zeile 4 bei Driver “radeon” nimmt man vorne die Raute weg und speichert die Datei ab. Anschließend alle Anwendungen schließen und neustarten.

   Sollte man beim Neustart einen schwarzen Bildschirm bekommen, dann muss das KMS abgeschaltet werden. Bitte einmal diesen Workaround zum Abschalten von KMS im Failsafe-Modus durchführen.

Feedbacks sind wie immer willkommen.

Im stabilen LibreOffice-Repo wurde eine neue LibreOffice Version veröffentlicht und steht zur Installation für openSUSE bereit. Die Paketbauer haben mitgeteilt, dass im Repo die Version 3.4.2 genannt wird und man sich von der Version nicht täuschen lassen sollte. In dieser Version sind bereits die Patches von 3.4.3 enthalten, so dass es eigentlich eine LibreOffice 3.4.3 ist.

Was ist neu in LibreOffice 3.4.3 bzw. überhaupt neu in 3.4?

Hierzu verweise ich gerne auf folgende Seiten, die ziemlich treffend die Neuerungen aufzählen und einige Screenshots dazu liefern:

• LibreOffice – Neue Feature und Fehlerbehebung (EN)
• LibreOffice – Release Notes (EN)
• LibreOffice – Release Notes (3.4.1)
• LibreOffice – Release Notes (3.4.2)
• LibreOffice – Release Notes (3.4.3)

Als ich die neue LibreOffice Version mit meinen vorhandenen Dokumenten getestet habe, machte es einen stabilen Eindruck. Neu hinzugekommen ist der lange geforderte Formeleditor, der für wissenschaftliche bzw. mathematische Dokumentationen sehr wichtig ist.

Im letzten Artikel habe ich von der Hardware-Videobeschleunigung mit AMD Grafikkarten und AMD Catalyst / XvBA berichtet. In LibreOffice habe ich die Hardwarebeschleunigung aktiviert und werde mit einem sehr schnellen Bildaufbau belohnt. Hier läuft es schon mal so gut, dass ich es eigentlich gar nicht abschalten möchte.

Die Hardware-Videobeschleunigung kann wie folgt nach der Installation der neueren LibreOffice-Version aktiviert werden:

1. Im Menü auf Extras / Optionen
2. Dann im linken Seitenmenü auf LibreOffice / Ansicht durchhangeln.
3. Im Bereich Grafikausgabe den Haken bei “Hardwarebeschleunigung verwenden” und “Antialiasing benutzen” setzen.
4. Dialogfenster mit Okay schließen und LibreOffice neustarten.

Installation von LibreOffice:

Hinweis: Wie immer gilt, dass die Tumbleweed-Fraktion dieses LibreOffice-Update automatisch erhält und die u.g. Installation in der Regel überflüssig ist. Außer natürlich für diejenigen, die nicht warten wollen/möchten.

Installation via YaST2:

1. YaST2 – Software installieren oder löschen starten.
2. Im Menü Konfiguration -> Repositories aufrufen.
3. Auf Hinzufügen klicken.
4. “URL angeben” wählen und auf Weiter klicken.
5. Repository-Name eingeben: LibreOffice
6. URL des LibreOffice-Repo für openSUSE 11.4 eingeben: http://download.opensuse.org/repositories/LibreOffice:/Stable/openSUSE_11.4/
7. Auf Weiter klicken.
8. Das erstellte Repository “LibreOffice” auswählen und die Priorität auf z.B. 50 ändern, um Paket-Kollisionen zu vermeiden.
9. Auf Okay klicken, um die Verwaltung der Software-Repository zu schließen. Ggfs. den GPG-Schlüssel vom Repo importieren.
10. In YaST2 dann auf Anzeigen -> Installationsquellen bzw. auf den offenen Tab Installationsquellen klicken.
11. Auf der linken Seite das “LibreOffice”-Repo auswählen.
12. Im blauen Textfeld auf Switch system packages bzw. Wechsel von Systempaketen klicken.
13. Nun oben im Menü auf Paket / Alle in dieser Liste / Aktualisieren, falls neuere Version verfügbar, um auf das aktuelle LibreOffice zu wechseln.
14. Abschließend auf Akzeptieren klicken. Sollte ein Dialogfenster bezüglich des Paketwechsel auftauchen, bitte bestätigen bzw. die Pakete auflösen.
15. Die Installation ist nun abgeschlossen. LibreOffice kann nun über das KDE-Menü gestartet werden.

Installation via zypper:

1. Das Repo von LibreOffice hinzufügen:

   zypper ar -f 'http://download.opensuse.org/repositories/LibreOffice:/Stable/openSUSE_11.4/' 'LibreOffice'

2. Die Priorität auf 50 erhöhen, um Paket-Kollisionen zu vermeiden:

   zypper mr -p 50 'LibreOffice'

3. Die Liste der Repositories aktualisieren und den GPG-Schlüssel vom LibreOffice-Repo importieren:

   zypper ref

4. Installation bzw. Upgrade durchführen.:

   zypper dup --from LibreOffice

Have a lot of fun!

Genau, man hat richtig gelesen. Die Videobeschleunigung ist jetzt mit openSUSE und AMD Catalyst auch möglich. Wer hat nicht neidisch auf die proprietären Betriebssystemen geschaut, auf der man die hochauflösenden Filme (z.B. in H.264) über die Hardware-Videobeschleunigung z.B. via DXVA ohne Ruckeln anschauen konnte. In diesem Artikel werde ich euch zeigen, wie es auch auf openSUSE funktionieren kann und berichte nun wie ich es zum Laufen bekommen habe und vor allem wie man es installiert und einrichtet.

AMD Catalyst verwendet die XvBA-Schnittstelle (X-Video Bitstream Acceleration) für die Videobeschleunigung. Diese Schnittstelle hat AMD für die hauseigenen Grafikkarten entwickelt und ist die Antwort auf die VDPAU-Schnittstelle (Video Decode and Presentation API for Unix) von NVIDIA. Das gute daran, die Schnittstellenbeschreibungen sind Open-Source.

Auf der Suche nach einer Anbindung zwischen AMDs XvBA und VA API (Video Acceleration API) bin ich auf das xvba-video Projekt gestoßen. Die Schnittstelle zwischen XvBA und VA API kann momentan die Videoformate H.264 wie auch VC-1 behandeln und an die Grafikkarte durch reichen. Es gab nur ein Problem, dass die Schnittstelle komplett auf einem Debian-System programmiert wurde und für openSUSE etwas angepasst werden musste. Dann gab es noch eine weitere Hürde, dass die VA API die XvBA-Anbindung nicht laden konnte. Wenn man hier jetzt die Videobeschleunigung im VLC Media Player aktiviert, dann stürzt VLC grandios ab. Also, musste ein Workaround in Form einer Shellvariable her, um VA API explizit die fglrx-Schnittstelle zu aktivieren:

LIBVA_DRIVER_NAME="fglrx"

In der Konsole habe ich überprüft, ob die XvBA-Schnittstelle in VA API geladen werden konnte (Dieses Tool befindet sich im Paket vaapi-tools):

vainfo

Die Ausgabe bestätigt dies:

libva: libva version 0.32.0
libva: User requested driver 'fglrx'
libva: Trying to open /usr/lib64/dri/fglrx_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.32
vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA-API - 0.8.0
vainfo: Supported profile and entrypoints
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

Mit all dieser Erfahrung habe ich (man kennt es ja nicht anders ) ein Paket namens xvba-video gebaut. Das erste Problem war, wie man das Paket für openSUSE 11.3, 11.4 und auch Tumbleweed mit jeweils für 32-bit und 64-bit Systemen baut und regelmäßig aktualisiert. Mein erste Gedanke war das Paket auf unserem openSUSE Build Service (OBS) zu bauen und hosten zu lassen. Leider benötigt das Paket einige Teile vom AMD Catalyst, um korrekt gegen XvBA von AMD zu linken. Da AMD Catalyst leider nicht Open-Source ist, darf daher dieser gewisse Teil nicht für die Öffentlichkeit verfügbar sein und könnte auf dem OBS Probleme machen.

Da fällt mir noch PackMan ein und habe Pascal Bleser (openSUSE Mitglied) vom PackMan-Team gefragt, ob er mein Paket unterstellen könnte. Er hat zugestimmt und mir ein Account zum PackMan Build Service eingerichtet. Der PackMan Build Service baut auf das openSUSE Build Service auf und lässt sich zu meiner Freude genauso bedienen. Um trotzdem den Closed-Source Teil aus lizenztechnischen Gründen nicht öffentlich verfügbar zu machen, habe ich das Paket aufgeteilt. Es wird nur zur Bauzeit geladen und gelinkt. Diese vorgehensweise halte ich momentan für sinnvoll. Da man sowieso AMD Catalyst auf dem Rechner installiert hat, ist die statische XvBA-Library identisch.

Hinweis: Um die Hardware-Videobeschleunigung via XvBA zu nutzen, muss ein recht aktueller AMD Catalyst Treiber installiert sein. Eine aktuelle Installationsanleitung zu AMD Catalyst gibt es auch in diesem Blog, bitte hierzu die Suchfunktion benutzen.

PackMan-Repo einrichten

Falls man noch kein PackMan-Repo eingerichtet hat, werde ich in diesem Abschnitt die notwendigen Schritte anleiten.

PackMan-Repo via YaST einrichten

1. Über das YaST-Kontrollzentrum “Software-Repositories” starten.
2. Unten links auf Hinzufügen klicken.
3. Als Medientyp “Community/Gemeinschafts-Repositories” auswählen und auf Weiter klicken.
4. Den Eintrag “Packman-Repository” einhaken und auf Okay klicken. Ggfs. im nächsten Dialogfenster das GPG-Schlüssel vom Repo importieren.
5. Dann in der Liste “Packman-Repository” auswählen und die Priorität auf z.B. 60 setzen. Somit werden neue Pakete bevorzugt aus diesem Repo quasi vor OSS bzw. NON-OSS wie auch das Update-Repo installiert.
6. Abschließend auf Okay klicken

PackMan-Repo via zypper einrichten

1. PackMan-Repo hinzufügen:

   zypper ar -f 'http://packman.inode.at/suse/openSUSE_11.4/' 'PackMan'

2. Priorität z.B. auf 60 ändern:

   zypper mr -p 60 'PackMan'

VideoLAN-Repo einrichten

Falls man noch kein VideoLAN-Repo eingerichtet hat, werde ich in diesem Abschnitt die notwendigen Schritte anleiten.

VideoLAN-Repo via YaST einrichten

1. Über das YaST-Kontrollzentrum “Software-Repositories” starten.
2. Unten links auf Hinzufügen klicken.
3. Als Medientyp “URL angeben” auswählen und auf Weiter klicken.
4. Den Repository-Namen eingeben: VideoLAN
5. Die URL eingeben: http://download.videolan.org/pub/videolan/vlc/SuSE/11.4/
6. Auf Weiter klicken. Ggfs. das GPG-Schlüssel vom Repo importieren.
7. Dann in der Liste “VideoLAN” auswählen und die Priorität auf z.B. 60 setzen. Somit werden neue Pakete bevorzugt aus diesem Repo quasi vor OSS bzw. NON-OSS wie auch das Update-Repo installiert.
8. Abschließend auf Okay klicken

VideoLAN-Repo via zypper einrichten

1. VideoLAN-Repo hinzufügen:

   zypper ar -f 'http://download.videolan.org/pub/videolan/vlc/SuSE/11.4/' 'VideoLAN'

2. Priorität z.B. auf 60 ändern:

   zypper mr -p 60 'VideoLAN'

Installation von xvba-video, VLC 1.2.0 (Beta) + Codecs

Jetzt kommen wir zur eigentlichen Installation von xvba-video, VLC Media Player, FFmpeg, unter anderem auch einige Codecs wie z.B. H.264, usw. Warum installiert man eigentlich das Paket FFmpeg und die Codecs vom PackMan-Repo und VLC Media Player vom VideoLAN-Repo? Der Grund ist, dass FFmpeg aus dem PackMan-Repo umfassend mit einigen Codecs ausgestattet sind und der FFmpeg vom VideoLAN eben nicht ganz so umfangreich ist. Warum installiert man nun eine Beta-Version von VLC Media Player? Die Beta vom VLC ist die einzige Version, die wirklich mit VA API und FFmpeg reibungslos funktioniert.

Via YaST installieren

1. Über das YaST-Kontrollzentrum “Software installieren oder löschen” starten.
2. Dann oben links auf Anzeigen / Installationsquellen klicken und in dieses neue Tab wechseln.
3. Auf der linken Seite das PackMan-Repo auswählen.
4. Dann den sekundären Filter auf “Suche” und den Suchmodus auf “Beginnt mit” stellen .
5. Folgende Pakete im Suchfeld eingeben und zur Installation auswählen:
   • ffmpeg
   • xvba-video

   Die notwendigen Codecs werden automatisch mit ausgewählt.

6. Auf der linken Seite wählt man nun das VideoLAN-Repo aus.
7. Folgendes Paket im Suchfeld eingeben und zur Installation auswählen:
   • vlc-beta
8. Abschließend die Installation per Klick auf Akzeptieren starten.
9. Den Computer neustarten.

Via zypper installieren

1. Die Pakete ffmpeg und xvba-video aus dem PackMan-Repo installieren:

   zypper in --from 'PackMan' ffmpeg xvba-video

2. Die Auswahl der Software mit Ja (j) bestätigen.
3. Das Pakete vlc-beta aus dem VideoLAN-Repo installieren:

   zypper in --from 'VideoLAN' vlc-beta

4. Und wieder die Auswahl der Software mit Ja (j) bestätigen.
5. Den Computer neustarten.

VLC für die Hardware-Videobeschleunigung konfigurieren

1. VLC Media Player starten
2. Dann im Menü auf Extras / Einstellungen klicken.
3. Unter links die Option “Einstellungen zeigen” auf Alle auswählen, um alle Optionen anzeigen zu lassen (Experten-Modus).
4. Danach in der Menü-Sidebar auf Input/Codecs / Videocodecs / FFmpeg durchhangeln und im Abschnitt Decoding die “Hardware Dekodierung” aktivieren.
5. Jetzt hangelt man sich unter Video / Ausgabemodule durch und das Videoausgabe-Modul “GLX Videoausgabe (XCB)” auswählen.
6. Abschließend auf Speichern klicken und den VLC Media Player neustarten.

Ein kleiner Video-Test kann Aufschluß bringen, ob die Hardware-Videobeschleunigung wirklich funktioniert.

http://www.h264info.com/clips.html

Sobald man ein Video von der o.g. Webseite gestartet hat, kann man den Prozess vom VLC Media Player im Systemmonitor beobachten. Es soll auf jeden Fall ein stabiler Wert für VLC sein (ca. 10% CPU Last anstatt 30%-40% je nach CPU) und nur sehr geringfügig schwanken.

Bitte teilt mir eure Erfahrung und Feedbacks zu diesem Thema mit. Vielen Dank.

Have a lot of fun!

Am 06.09.2011 hat Adobe im Adobe-Labs das erste Release Candidate (11.0.r1.129) des Flash Players veröffentlicht, in der sowohl für 32-bit wie auch für 64-bit Systeme verfügbar sind. Mittlerweile hat Adobe wirklich erkannt, dass der 64-bit Flash Player mehr denn je gefragt wird. An diesem Punkt hatte Adobe im letzten Flash Player 10.3 RC 1 die 64-bit Unterstützung zurückgezogen. Diesmal wird es ernst, die Hürde ist geschafft. Diese Version bringt nicht nur neue Feature mit, sondern behebt auch Sicherheitslücken, Stabilität- und Performance-Probleme sowie auch eine erhöhte Kompatibilität zu einigen Geräten (Device).

Laut der Changelog sind folgende Feature enthalten:

• Stage3D Accelerated Graphics Rendering
• H.264/AVC Software Encoding for Cameras (desktop)
• Native JSON (JavaScript Object Notation) Support
• G.711 Audio Compression for Telephony
• Garbage Collection Advice
• Cubic Bezier Curves
• Secure Random Number Generator
• Protected HTTP Dynamic Stream (HDS) and Flash Access Enhancements
• Socket Progress Events
• JPEG-XR support
• Enhanced high resolution bitmap support
• DisplayObjectContainer.removeChildren and MovieClip.isPlaying
• Native 64-bit Support
• Asynchronous Bitmap Decoding
• TLS Secure Sockets Support
• HD surround sound
• Linux Vector Printing

Eine neue Test-Runde wurde eingeläutet, womöglich ist es schon die letzte Runde. Dann wollen wir mal unsere Finger spreizen und den neuen Flash Player auf openSUSE (64-bit) installieren und testen. Natürlich habe ich ein flexibles Skript geschrieben, das die Erstellung eines RPM-Paketes bis hin zur Installation des Flash Players übernimmt.

Die Installation des neuesten Flash Player auf openSUSE:

Hinweis: Die Installation wird in der Konsole mit root-Rechten durchgeführt.

Downloads:

• makerpm-flash-11.0-rc1.sh
• makerpm-flash-11.0-rc1.sh.sha1

1. Das Skript makerpm-flash-11.0-rc1.sh wie auch die Prüfsummendatei herunterladen:

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.0-rc1.sh

   wget http://www.sebastian-siebert.de/downloads/makerpm-flash-11.0-rc1.sh.sha1

2. Die Prüfsumme vom heruntergeladenen Skript prüfen:

   sha1sum -c makerpm-flash-11.0-rc1.sh.sha1

   Idealerweise sollte folgende Ausgabe erscheinen, andernfalls ist das Skript defekt und sollte ersetzt werden:

   makerpm-flash-11.0-rc1.sh: OK

3. Das Skript ausführbar machen:

   chmod 755 makerpm-flash-11.0-rc1.sh

4. Nun gibt es 3 Möglichkeiten die Pakete zu erstellen und zu installieren:
   1. Auf einem reinen KDE-System:

      ./makerpm-flash-11.0-rc1.sh -i kde

   2. Auf einem reinen GNOME- bzw. GTK-System:

      ./makerpm-flash-11.0-rc1.sh -i gnome

   3. Sowohl auf einem KDE-System wie auch auf einem GNOME-System:

      ./makerpm-flash-11.0-rc1.sh -i all

      oder einfach nur

      ./makerpm-flash-11.0-rc1.sh -i

   Dann entspannt zurück lehnen und warten bis die Installation abgeschlossen ist. Das Skript ist ziemlich gesprächig und könnte bei manchen ein Déjà-vu-Erlebnis auslösen.

5. Rechner neustarten und Flash Player 11 RC 1 testen.

Sollte etwas mit dem Skript nicht funktionieren, dann sagt mir bitte Bescheid. Danke!

Have a lot of fun!