seduction
 Language:
Welcome, Guest. Please login or register.
Did you miss your activation email?
2019/12/16, 09:18:16


Help

Author [EN] [PL] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber  (Read 8161 times)

0 Members and 1 Guest are viewing this topic.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
« Reply #30 on: 2011/01/31, 01:39:38 »
:) Die kenn ich, werde sie aber freiwillig nicht anrühren. Nachdem ich die Verwüstungen und den Müll gesehen habe, den ein oldconfig in jede neue Konfiguration mitschleppt, ist das für mich gestorben. In meinem Alter steht man auf Bequemlichkeit. Auch für Dich ein wenig Lesestoff, habe grade den .14 gebaut und in der Zwischenzeit meinen Kernel-Artikel weiter bemuckelt. Wenn Du mal ein Auge drauf werfen willst:
http://wiki.g-com.eu/index.php?title=Kernelbau_aptosid

Auf diese  Art und Weise sind die linux-gcom-kernel entstanden, bis jetzt hat's geklappt ;) Wenn die losen Enden festgezurrt sind und ich mich dazu entschlossen habe, die Polemik aus dem Geschreibsel rauszunehmen, könnte man das Ding als Anfang eine Serie ins Wiki übertragen. Folgeartikel, die mir so spontan einfallen: Aufbau einer Umgebung mit pbuilder, repo-Einrichtung mit reprepro, Bedeutung von ausgewählten Kerneloptionen, eventuell noch ein paar Werkzeuge. Halt so einiges, was bei der täglichen Arbeit anfällt, was immer wieder gern vergessen wird und deswegen dokumentiert werden sollte.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline ralul

  • User
  • Posts: 1.809
[gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
« Reply #31 on: 2011/01/31, 12:11:20 »
Ich hab mir Dein Wiki schon angeschaut und auf dem Plan daraus etwas kürzeres für unser aptosid Wiki zu machen. Kürzer und offiziöser, weil man natürlich, wenn man Deinen Stil kennt, ihn genießen kann, aber vielleicht ist es besser im aptosid Wiki neutraleren Stil zu schreiben.

Ich würde deinen Text im Aptosid Wiki strukturierter haben wollen, einfach KapitelNummern:
----
1.  Vorbedingungen
1.1 apt-get build-dep linux-image
...
2.  Setup
2.1 sed -e's/slhString/eigenString/' ... (statt diffs?)
2.2 patchen der series (Was war mit quilt?)
2.3 changelog ändern
2.4 debian/rules setup
...
3. Bauen
3.1 debuild
...
4.  Installieren
4.1 cd ..
4.2 dpkg -i linux-image
...
-----
- aus den Diffs würde ich sed Anweisungen machen.
- Eigenes Repo würde ich im Aptosid Wiki weglassen. Wer dazu fähig ist, weiss auch, dass er dann kein dpkg -i braucht.
- git würde ich weglassen, wer das will...

Vielen Dank für Deine Einblicke und Pionierarbeit! Mir selbst war immer unklar, wie die Python Scripte im slh-Kernel-Source gedacht sind!
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
« Reply #32 on: 2011/01/31, 13:51:58 »
Das mit dem Stil meinte ich ja mit noch nicht überarbeitet. In ein Wiki gehören eigentlich offizielle Texte, aber das ist mein Zettelkasten, während dreier Kernel-Bau-Sessions entstanden. Das ist der Grobentwurf eines Entwurfs, jede Hilfe ist willkommen.

Bis auf dass es funktioniert und in der Realität getestet wurde und Bestand hatte, nichts großes. Das mit den Bedingungen ist richtig. Es spricht meines Erachten nichts gegen den Einsatz von debuild für den lokalen Einsatz, aber eigentlich sollte das Teil in einer neutralen Build-Umgebung mit pBuilder erstellt werden.

Ich hab bei so etwas immer ein leichtes Zeitproblem. Die Scripte nachvollziehen und richtig einsetzen ist eigentlich das Wesentliche, ich hab auch nur 2 Tage gebraucht, bis ich damit durch war. Die Zeit hat sich gelohnt, bequemer und sicherer geht es nicht. Die Idee mit den Diff's fand ich gut, ein Diff sagt mehr als tausend Worte. Die Konfigurationen sollte man schon per Hand anpassen, mir war eigenlich nur die Darstellung +/- im Kontext wichtig.

Quilt habe ich rausgenommen, weil ich mit quilt immer von einer definierten Basis ausgehen muss. Ohne Quilt passt das besser in mein Schema mit reprepro, sprich fertiges Quellpaket nehmen, Orginalquellen wegwerfen, alles neu erstellen und gut ist gewesen. (Patches und Series kann eigentlch ganz raus, das ist wirklich für richtig Fortgeschrittene, vor allem auch das momentane Hauptkampffeld bei Änderungen. Dem begabten Amateur sei geraten, sein Zeug einfach am Ende draufzuhauen, oder noch besser, komplett die Hände draus zu halten)

Was auf jeden Fall noch Erwähnung finden sollte (imho in einem eigenen Artikel), ist der Aufbau der Konfiguration. Natürlich kann man die Konfiguration des laufenden aktuellen Kernels in make xconfig oder gconfig weiterbearbeiten. Diese würde ich dann speichern und per meld oder bcompare in slh's Konfig-Schema bringen. Hier könnte man auch mit einem wie auch immer gearteten Script zuschlagen, da müsste ich mal drüber nachdenken.

Als weiterführenden Artikel (für bequemes Arbeiten) wäre ein Verweis auf git und einige Arbeitsweisen sicherlich sinnvoll und angebracht. Im Endeffekt ist ja jede Anpassung gegen die aktuellen Quellen ein 3-way-merge, da sollte man schon die eine oder andere Zeile zu schreiben, es lohnt sich. git setze ich deswegen ein, weil es beim Basteln keine schönere Möglichkeit gibt, die Quellen sauber und fehlerfrei zu halten. Würde zwar auch so gehen, aber ist für mich dann nicht mehr nachvollziehbar. Bei so was bin ich aus Erfahrung Kontrollfreak. Git hat vor den anderen Versionskontrollen den entscheidenden Vorteil, dass es sauschnell ist.  Bei anderen Projekten setze ich die Prioritäten anders und setze auf svn.

Zum Thema Repo aufsetzen: Da es einige Varianten dafür gibt, hab ich mir diese natürlich auch angeschaut. So richtig begeistert war ich eigentlich bis jetzt von keiner, reprepro hatte aber den grandiosen Vorteil, dass es einiges an Komfort mitbringt, wenn man es verstanden hat. (Davon bin ich zwar noch relativ weit entfernt, aber was solls) Da ich bisher nie die Notwendigkeit sah, mich mit so was zu beschäftigen, war auch das wieder Grundlagenforschung für mich. Bei Ubuntu hatte und habe ich Launchpad, bei Arch ist es noch bequemer, da nimmt man das AUR für Sachen, die auch die Allgemeinheit haben soll, man kann sich ein eigenes AUR bauen oder aber auch recht einfach ein eigenes Repository pflegen.  Bei debian ist das halt nicht so verbreitet, weil relativ wenige Leute bauen.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen