Hallo Roman, Am 13.12.2010 10:01, schrieb Roman Fietze:

Immer wenn ein neuer Kernel hereinflattert baue ich mir mit oder Sebastians Script ein neues fglrx-Paket.

Schön. Sehr wahrscheinlich wird das makerpm-ati-Skript im nächsten Jahr auslaufen. (Begründung siehe unten) :-)

Nun, in der Firma, ja selbst zu Hause kommt das natuerlich auf den Repositoryserver, damit das nicht jeder fuer sich selbst machen muss.

Nun habe ich aber das Problem, dass die Versionsnummer dieses Pakets im Filenamen und im RPM immer diesselben sind, egal ob z.B. nun fuer den Kernel 2.6.31.14-0.2.1 oder den 2.6.31.14-0.4.1 baue.

Schon mal unschoen.

Nach einem createrepo und siginieren des Repos hat der YaST zudem ein Problem wenn ich das Paket manuell updaten will, der Schluessel passt irgendwie nicht zum Paket, der YaST baut wohl seinen Index nicht neu. Erst ein "zypper ref" behebt das Problem.

Schoen waere nun man koennte beim Bauen des RPMs per Switch eine Release mitgeben, also z.B. "makerpm-ati-... -r 12".

@Sebastian: das sollte nicht schwierig sein, schon gar nicht fuer dich, denn fuer die ati-10.9 sowie fuer eine spezielle Version ohne 32-Bit-Libs hast du in den Sourcen ja auch schon mal herumgepatched. Der ati-packager-helper.sh der aufgerufen wird liefert einfach immer nur duemmlich eine '1' zurueck, das koennte man leicht abaendern. Wenn du willst, kann ich mir auch selbst mal die Muehe machen und dir dann einen Diff fuer dein Script liefern.

Danke für den Vorschlag. Im Prinzip musst du nur einmal vom ATI-Installer das RPM-Paket bauen lassen. Die Kernel-Quellen werden ja erst gebaut, wenn das Paket installiert wird. Etwas anders als die ATI-Repos, in der diese bereits fertig gebaut sind). Daher ist dieser Patchlevel im Prinzip bedeutungslos. Sobald ein Kernel-Update reinkommt, muss man heute noch das Skript fglrx-kernel-build.sh nach einem Neustart erneut anstoßen. (Aber das dürfte bald der Vergangenheit angehören. Dazu später mehr) Dein Vorschlag mit dem Schalter scheitert leider schon, dass genau dieser Schalter nicht bis zum eigentlichen RPM-Packaging-Skript ./packages/SuSE/ati-packager.sh durchkommt. Als openSUSE Packaging Script Maintainer arbeite ich im Verzeichnis ./packages/SuSE/* vom ATI-Installer und habe für die Änderungen dort recht freie Hand. :-) Leider war das Git Repository durch einen Server-Umzug defekt gewesen, so dass sich das Zeitfenster (Code-Freeze) für die Änderungen am ATI-Installer 10.12 schloss und meine Änderungen erst im ATI-Installer 11.1 einfließen werden. (Wer aber demnächst das makerpm-ati-10.12.sh verwendet, bekommt gleich die unten genannten Features mitgeliefert. Da ich das Packaging-Skript austauschen werde. ;-) ) Folgende von mir eingebrachten Änderungen in den ATI-Installer dürft Ihr im Jahr 2011 erwarten wie auch schon in meinem Blog angekündigt [1]: - ./packages/SuSE/ati-packager.sh und ./packages/SuSE/fglrx.spec komplett überarbeitet - Verbose-Modus (Geschwätzigkeit) integriert, um Baufehler aufzudecken. 1 = Was machst du gerade? 2 = Erzähl mir alles. Anwendung: VERBOSE="1" ./ati-driver-installer-(version)-(arch).sh --buildpkg ... oder VERBOSE="2" ./ati-driver-installer-(version)-(arch).sh --buildpkg ... - Automatische Erkennung der laufenden openSUSE-Version: ./ati-driver-installer-(version)-(arch).sh --buildpkg SuSE/SUSE-autodetection - openSUSE 11.4 bzw. openSUSE Factory integriert und lässt sich freischalten. Beispiel: UNSUPPORTED="yes" ./ati-driver-installer-(version)-(arch).sh --buildpkg SuSE/SUSE114-AMD64 - Ein Rebuild-Init-Skript wurde von mir geschrieben. Das Init-Skript baut nach einem Kernel-Update das fglrx-Kernelmodul automatisch neu und wird standardmäßig installiert und aktiviert. Compilermeldungen werden nach /var/log/fglrx-build.log protokolliert. (Kein Ausflug mehr in die Konsole) :-) - Das Skript fglrx-kernel-build.sh wurde von mir komplett überarbeitet und kann in einer einzigen Sitzung für sämtliche installierte Kernel-Versionen oder -Flavors (desktop/default) das fglrx-Kernelmodul bauen. - RPM-Abhängigkeit zu gcc, make, patch, kernel-source, kernel-devel, kernel-default-devel und kernel-desktop-devel wurden standardmäßig aktiviert. YaST und/oder zypper sollen die genannten Abhängigkeiten automatisch bei der Installation des fglrx-RPM-Paket installieren. Bei den ganzen Feature, die ich im ATI-Installer Packaging Script implementiert habe, wird das makerpm-ati-Skript wieder sehr sehr schlank werden. Daher plane ich das makerpm-ati-Skript auslaufen zu lassen. Außer es gibt irgendwelche Einwände und eine plausible Begründung zum Erhalt des Skriptes. ;-) Falls Ihr noch Vorschläge oder Ideen habt, nur her damit. ;-) Mich würde es mal interessieren, ob der NVIDIA-Installer das übertreffen kann. :-) [1] <http://www.sebastian-siebert.de/2010/11/25/amd-hat-einen-neuen-opensuse-packaging-script-maintainer-fuer-den-ati-installer/> -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: <http://www.sebastian-siebert.de> Wichtiger Hinweis zur openSUSE Mailing Liste: <http://de.opensuse.org/OpenSUSE_Mailinglisten-Netiquette> -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org