@agaida, das Script, was Du suchst zum Selberbauen des Kernels:
#!/bin/bash
E=mcedit
V="2.6.37"
L="linux-$V"
U="http://www.kernel.org/pub/linux/kernel/v2.6/$L.tar.bz2"
H=~/mysrc
S=~/mysrc/slh-patches
set -x
[ -d "$S" ] || mkdir -p "$S"
cd $H || exit
[ -f "$L.tar.bz2" ] || wget "$U"
[ -f "$L.tar.bz2" ] || exit
[ -d "$L" ] || tar xjf "$L.tar.bz2"
ln -sTf "$H/$L" "$H/linux"
cd $S || exit
if [ -d debian/.svn ] ; then
cd debian || exit
svn update
else
svn co svn://svn.berlios.de/fullstory/linux-aptosid-2.6/trunk/debian/
fi
ln -sTf "$S/debian/patches" "$H/linux/patches"
# [edit]
# @E "$H/linux/patches/series" || exit
$E "$H/linux/patches/series" || exit
cd "$H/linux" || exit
make mrproper
zcat /proc/config.gz >.config
quilt push -a
make oldconfig
make menuconfig
echo " "
echo "now : "
echo "make deb-pkg"
echo "after this as root:"
echo "cd .. && dpkg -i linux-image*"
Ich habs eben so aus der Hand geschüttelt und noch nicht getestet, weil ich gerade unter Gentoo bin. Deswegen "set -x" eingeschaltet lassen und schauen wie weit es läuft!
[edit]Towos Hinweis $E statt @E - Script noch ungetestet!
Danke für die Scripte, ich hab sie noch nicht probieren können, ich hab noch ein paar kleine andere Großbaustellen.
Towo schrieb gerade (http://forum.siduction.org/index.php?msg=3887#3887)
"Kernelbau braucht solch ein Script nicht und ist im Netz zu Hauf dokumentiert"
Ich habe solch eine Doku im ansonsten hervorragenden aptosid Handbuch immer vermisst:
Wie kann ich den 2.6.36 slh Kernel nachbauen, wenn er nicht mehr im Repo vorhanden ist?
@E "$H/linux/patches/series" || exit
Wird nicht funktionieren, muß $E heissen.
Die patches lassen sich nicht ohne Weiteres auf eine vanilla Source anwenden, weil beim aptosid-kernel die .orig-source schon von unfreiem blob befreit ist.
Ein unbedarfter User wird am Editiren der series und der Kernel-Konfig scheitern, weil er nicht weiss, was er tut.
make deb-pkg was soll das werden?
Im Endeffekt hat Towo nicht ganz unrecht, es wurde in den letzten Jahren viel darüber geschrieben. Da ich mir die Konfiguration vom slh-Kernel ja notgedrungen angeschaut habe, muss ich aber gestehen, dass so was dann aber auch nicht unbedingt meinen Vorstellungen eines idealen Scriptings entspricht.
Einen towo-Kernel kann man sich ja schon längere Zeit nicht mehr laden, also fehlt mir da der Vergleich.
@towo: Wenn ein unbedarfter User anfängt, Kernel zu bauen, ist er im Erfolgsfall kein ganz so unbedarfter User mehr. Im Falle des sehr wahrscheinlichen Misserfolgs trennt sich dann die Spreu vom Weizen. Die drei Möglichkeiten sind dann Lernen, fertiges Zeug nehmen oder zurück zu Windows.
Ich würde sogar so weit gehen, dass jemand, der ohne Probleme und ohne Buchstabe für Buchstabe eine Buidumgebung aufsetzen kann, nicht mehr ganz unbedarft ist. Bevor man das richtig kann, vergeht aber einiges an Zeit. Das Wissen über Linux und Werkzeuge wird in dieser Zeit aber nicht geringer. Gimp, Scribus oder gar OO zu bauen, ist schwieriger.
QuoteWie kann ich den 2.6.36 slh Kernel nachbauen, wenn er nicht mehr im Repo vorhanden ist?
Den entspr. Branch aus dem SVN auschecken, und rules lesen und verstehen.
Quote from: "towo"Die patches lassen sich nicht ohne Weiteres auf eine vanilla Source anwenden, weil beim aptosid-kernel die .orig-source schon von unfreiem blob befreit ist.
Dafür ist im svn das Script debian/scripts/dfsg-prune. Aber ich meine, es reicht die linux/.config Option "Do not build binary blobs". Und im Grunde reichen die vanilla .3 patches, weil die meisten patches/upstream das Point-Release nur vorwegnehmen.
Quotemake deb-pkgwas soll das werden?
Wie man auch am Changelog von slh sehen kann
Quotelinux-aptosid-2.6 (2.6.36-19) unstable; urgency=low
...
- recommend use of 'make deb-pkg' to build custom kernel packages
Die Debian Entwickler haben ganze Arbeit gemacht und schon länger ein Debian spezifisches Target im linux/Makefile durchgesetzt - upstream !
Insofern kann man sich den debian/rules Teil sparen mit einem einfachen make deb-pkg - das habe ich auch schon erfolgreich ausprobiert - sagte ich nicht irgendwo, es ist einfacher als man denkt!
Am obigen kernelmake Script fehlt nur noch ein allgemeinerer Teil, mit dem man einen Patchbaum des ausgesuchten Backports auschecken kann, zb
svn co svn://svn.berlios.de/fullstory/linux-aptosid-2.6/tags/2.6.36-19/debian/
QuoteDafür ist im svn das Script debian/scripts/dfsg-prune. Aber ich meine, es reicht die linux/.config Option "Do not build binary blobs.
Nicht ganz! Dieses Script wird beim
Erzeugen der orig-Source angewendet.
Es mag ja für Dich einfach klingen, aber trotzdem kann der User mit deinem Script nicht viel anfangen!
1. Aufruf von debian/patches/series im Editor ==> der User weiss nicht, was er damit machen soll.
2. make oldconfig / make menuconfig ==> wer noch nie einen Kernel gebaut hat, kann damit absolut Nix anfangen.
Meiner Meinung nach ist dieses Script ungeignet, einen aptosid-nahen, Costum-Kernel zu bauen. Sicherlich benötigen die Wenigsten User die spezifischen Patches, welche slh benutzt, auch bei mir würde ein Stock-Vanilla-Kernel problemlos laufen.
aptosid hatte schon immer das Bestreben, neueste Entwicklungen zu berücksichtigen, BKL zu deaktivieren ist hier deshalb auch nur konsequent, zumal es, wieder einmal, nur propritären Kram betrifft, welcher damit nicht funktioniert.
Wer Kernel selber bauen will, soll das ruhig tun aber etwas verstehen, was er da macht, sollte $User schon. Wenn der Kernel durch falsche Konfiguration nicht funktioniert, ist das Geschrei dann nämlich groß und Support fast nicht möglich.
Das ist doch mal eine Aussage. Aptosid ist der Kernelentwicklung weit und konsequent voraus und der blöde User muss sehen, wo er bleibt. :lol: Find ich irgendwie ein wenig elitär, aber man muss auch Opfer bringen. Damit Dürfte Aptosid die einzige Distro sein, die auf den BKL teilweise verzichtet.
Macht aber nichts, da BKL an den entscheidenden Stellen per Script eingeschaltet wird. Oder hab ich in den vergangenen Tagen was verpasst? Nicht übelnehmen, aber auf Wunsch such ich die Stellen, die nicht proprietär sind, raus. (Duck und weg!)
Man kann BKL nicht teilweise deaktivieren.
Entweder der Kernel hat BKL oder eben nicht und im aptosid Kernel ist :
towo:Defiant> grep -i bkl config
# CONFIG_BKL is not set
Und ja, auch nicht propritäre Treiber benötig(t)en BKL, als da zum Beispiel wären, cifs, nfs und udf.
heißt das, das cifs, nfs und udf derzeit nicht mit 2.6.37 in aptosid funktionieren ? Oder war das "benötig(t)en" so zu verstehen das diese 3 bkl jetzt nicht mehr brauchen?
Quote from: "towo"Man kann BKL nicht teilweise deaktivieren.
Entweder der Kernel hat BKL oder eben nicht und im aptosid Kernel ist :
towo:Defiant> grep -i bkl config
# CONFIG_BKL is not set
Und ja, auch nicht propritäre Treiber benötig(t)en BKL, als da zum Beispiel wären, cifs, nfs und udf.
Jau, Du hast recht, hab das noch mal nachgelesen. In beidem. Aber wer benutzt schon cifs, nfs und udf (Ich geb zu udf benutze ich wirklich kaum)
Quote from: "dieres"heißt das, das cifs, nfs und udf derzeit nicht mit 2.6.37 in aptosid funktionieren ? Oder war das "benötig(t)en" so zu verstehen das diese 3 bkl jetzt nicht mehr brauchen?
cifs und udf funktioniert sicher, da ich nfs nicht einsetze, kann ich dazu nix sagen. Es gäbe aber mit Sicherheit schon Beschwerden, wenn nfs nicht funktionieren sollte.
Ich hab mir das jetzt noch nicht angeschaut, aber eine Sache, die ich nachher mal testen werde: Das Bereitstellen der nfs-Dienste. Obwohl das im Desktop-Bereich ja eher selten ist.
Nachdem ich jetzt durch das meiste von dem begriffen habe, was ich grad tue, hab ich nur noch eine entscheidende Frage: Das Paket von SLH bau vom Feinsten, Konfiguration etc ist kein Problem. das Kompilat funktioniert wie gewünscht. Nur so Kleinigkeiten wie .dsc .changes fehlen. Und wie baue ich ein Source-Paket per Hand? Irgendwie ist der Ablauf doch anders als bei debuild bei einfachen Paketen.
das .dsc ensteht, wenn man ein fröhliches dpkg-source -b sourceverzeichnis aufruft.
.changes ensteht, wenn man selbiges dsc durch den pbuilder jagt oder ein beherztes dpkg-buildpackage aus den Sourcen aufruft.
Aber auch nur dann, wenn man vorher alles richtig gemacht hat. Hab einen entscheidenden Schritt heute nacht noch machen wollen, aber schlicht vergessen. Ohne ordentliche Vorbereitung fällt dann solch ein Prozess halt auf die Nase. Es war halt ein wenig früh.