Siduction Forum

Siduction Forum => Upgrade Warnings (DE / EN) => Topic started by: agaida on 2011/01/06, 15:36:58

Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/06, 15:36:58
Aus gegebenen Anlass eine kleine Update-Warnung: 2.6.37-0-slh baut momentan noch nicht die Kernel-Module (fglrx.ko). Wer also auf die proprietäten Treiber angewiesen ist, sollte mit dem Upgrade noch ein wenig warten oder aber auf jeden Fall einen .36 in der Hinterhand haben.

Ohne Schrauberei ist nur ein Fallback auf 2.6.32-5 möglich, da die Header für 2.6.37-rc7 nicht installieren. Linux-kbuild-2.6.37 fehlt. Wer sich das erstellen kann, hat natürlich die Möglichkeit eines Fallbacks auf 2.6.37-rc7. Dafür bauen die Kernelmodule auch. Zur Verfügung stellen kann ich mein kbuild noch nicht offiziell, da wirklich mit der ganz heissen Nadel zusammengemöllert.
Title: kernel 2.6.37 slh und proprietäre ati-treiber
Post by: reddark on 2011/01/06, 16:03:55
Kann ich bestätigen. FGLRX geht bei mir auch nicht.
Hab glücklicherweise noch den 36er-kernel ;)
Title: kernel 2.6.37 slh und proprietäre ati-treiber
Post by: hsp on 2011/01/06, 16:23:40
Das ist immer so das fglrx dem Kernel hinterhinkt. Neuer Kernel und mit fglrx ist erst mal essig. Wär ja ein Ding wenn das mal auf anhieb klappen würde.
Nvidia hat das deutlich besser im Griff.

...
Title: kernel 2.6.37 slh und proprietäre ati-treiber
Post by: devil on 2011/01/06, 22:19:31
aptosid als distribution mit wenig manpower muss sich auf ein stück vom kuchen konzentrieren. wir bekennen uns klar dazu, freie software zu bevorzugen. so konnte man z.b. sehr früh ath5k/ath9k als auch OpenFWWF treiber finden. das kommt natürlich auch debian zugute wenn wir früh testen. allerdings fällt dafür der proprietäre kram etwas hinten runter. wir können (und wollen) halt nicht alles machen.

greetz
devil
Title: kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/07, 13:49:51
Dank towo's Tipp hat sich das Thema erledigt. config_bkl=y und Kernel von slh neu bauen und die Welt ist fast in Ordnung (auf jeden Fall bis zum nächsten Kernel).
Title: kernel 2.6.37 slh und proprietäre ati-treiber
Post by: reddark on 2011/01/07, 14:04:08
@agaida: Haste nicht Lust ein kleines Aptosid-Repro einzurichten und deinen angepassten Kernel der Weltbevölkerung zur verfügung zu stellen? Oder weinigstens für mich *grins*
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/07, 14:14:11
Wenn man mir langsam und deutlich erklärt, wie man das am besten macht, tue ich das. Wozu hat man einen Server in Berlin. Da würde das raufpassen.

Edit: Genau vor so was wollte ich mich drücken. Einfach mal nichts tun, kein Schrauben, nichts aus Quellen bauen.  :lol:
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: reddark on 2011/01/07, 14:22:43
Quote
Genau vor so was wollte ich mich drücken. Einfach mal nichts tun, kein Schrauben, nichts aus Quellen bauen.

*grins* Was hab ich wohl mit meiner Frage an dich zu vermeiden versucht .... ;)
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/07, 14:28:42
Eigentlich soll das auch nicht der Weg sein. Normalerweise gehört das in den orginalen Sourcen gefixt, wenn es denn als Bug akzeptiert wird. Der Kernel ist sonst top und eigentlich nicht meine Baustelle.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: towo on 2011/01/07, 14:33:37
Das gehört von AMD gefixt, nicht seitens des Kernels.
BKL ist uralter Mist und hätte schon vor Jahren aus dem Kernel gehört.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/07, 14:44:46
Entschuldigung wenn ich das ein wenig pragmatischer sehe, ich brauche jetzt eine funktionierende Lösung. Ich bin für Neuerungen immer offen.

Aber einen Schalter umzulegen, den seit dem Einbau in den Quellcode kein Mensch für den Echtbetrieb angepackt hat, kanns nicht sein. Zumal der BKL im Filesystem immer noch an ist. Das ist doch Augenwischerei,  an einer Stelle den BKL abzuschalten, wenn noch nicht mal Filesysteme und Netzwerkprotokolle ohne das Ding funktionieren. Das ist doch purer Aktionismus.

Ich nehme da die Beschreibung wörtlich: Der ist für die Leute gedacht, die an der Entfernung des BKL arbeiten. Dazu zähle ich mich nicht. Persönlich fände ich es gut, wenn das Teil der Vergangenheit angehören würde. So lange aber nicht von Linus und Co. die Freigabe gegeben wird, sehe ich keinerlei Sinn darin, jetzt übertrieben zu reagieren. Ich habe jenseits irgendwelcher Ideologie eigentlich das Ziel, mit meinem Computer zu arbeiten.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: ralul on 2011/01/07, 18:02:23
@agaida, zwei Scripte extra für Dich von mir im Forum Scripte....
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/07, 18:10:04
Ich hatte nicht zufällig erwähnt, dass das der Erstling eines debian-Kernels ist? Ich versuche ein Repo aufzusetzen. Gelesen, wie so was geht, hab ich schon mal irgendwann. Verdammt, ich will ein Aur haben, das kann auch ruhig dur heissen.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: ralul on 2011/01/07, 18:17:29
Aber wirklich der arch Link, den Du da gesetzt hattest zum Kernel bauen, ist sehr chaotisch im Vergleich zu den Gentoo Scripten :wink:
Keine Benutzung von quilt, drm Header werden wild kopiert, wahrscheinlich aus Zeiten, wo man das noch brauchte. Mich wundert, wenn ich die Strukturiertheit vergleiche gar nichts mehr bei arch....
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/09, 21:42:18
Aber es funktioniert trotz alledem. Das erstaunt mich selbst am meisten. Ich hab da wohl ein etwas unglückliches Beispiel gewählt. Und dieses Beispiel erklärt auch, warum von Paketen aus dem AUR abgeraten wird, wenn man ein stabiles System haben will.  :twisted:

Ich hatte nur keinen Bock, die Mimik selbst zu schreiben und das Abholen der Quellen hat ja geklappt. Man nimmt sich halt immer nur, was man braucht. Es lebe die Anarchie - ich will ein DUR haben.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/12, 10:45:03
@reddark: http://forum.siduction.org/index.php?topic=501

Das steht ganz bewusst unter experimentell. Auch wenn ich es nicht gern zugebe, man kann auf den BKL und auch auf den proprietätern Catalyst verzichten. Mit niedrigem Powerprofil ist der radeon momentan sparsamer als der catalyst. Über die Stabilität kann ich auch nichts negatives berichten. Bis ich den aber auf allen Installationen einsetze, teste ich den erst noch mal etwas länger aus. Vor 1-2 Monaten hatte ich mit Xorg 1.9 und radeon noch einige Probleme mit KDE, 1.7.X und radeon lief bei mir auch nicht wirklich rund, die Abflugquote von KDE hielt sich zwar in erträglichen Grenzen, war aberd deutlich höher als mit Catalyst.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/13, 10:51:16
Ich habe nun das aktuelle Release von slh, slh.4 noch einmal umgewidmet und mit BKL gebaut. Wer mutig ist und denkt, BKL wirklich zu brauchen, kann probieren. Für alle anderen, die ohne BKL leben können, gilt ganz eindeutig die Empfehlung: Nicht einsetzen, slh wird auf Dauer aktueller sein und hat in so was einige Jahre mehr Erfahrung als ich.

BTW: Seit heute gibt es auch einen von debian berichtigten fglrx im experimental. Der baut aber leider nicht gegen slh, sondern nur gegen Kernel mit BKL. http://alfgaida.de und das Repo http://debian.alfgaida.de
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: reddark on 2011/01/13, 11:46:10
Danke agaida - mit deinem neuen kernel funktioniert nun auch bei mir fglrx mit dem 37er ;)
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/13, 14:33:05
Der Dank sollte an die Jungs von Debian gehen, die haben da in ihrem Packaging ein paar Sachen geregelt, die über den schon verfügbaren Patch hinausgingen. Ich hab ja eigentlich nur eine Zeile geändert.

Die Vorarbeit von slh ist auch in keinster Weise zu unterschätzen. Vor allem sein Framework macht die Arbeit sehr einfach, wenn man da erst mal durchgestiegen ist. Die aktuelle Version seines Kernel hat ja auch wieder ein paar begrüßenswerte Änderungen gehabt. Bis auf diese eine Konfigurationszeile, mit der ich nicht ganz einverstanden bin, ist das einer der am besten vorkonfigurierten und aktuellsten Kernel, mit denen ich die Freude hatte, zu arbeiten.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: AnJo on 2011/01/27, 14:54:42
Hallo agaida,

Quote
Dank towo's Tipp hat sich das Thema erledigt. config_bkl=y und Kernel von slh neu bauen und die Welt ist fast in Ordnung (auf jeden Fall bis zum nächsten Kernel).


Ist genau das was ich brauche um vmware unter 2.5.37 zu installieren.

Gibt es hier irgendeine  Schritt-für-Schritt Anleitung.

Hatte mir schon einmal linux-aptosid-2.6_2.6.37.orig.tar.bz2 heruntergeladen, entpackt und dann im Verzeichnis ../linux-2.6.37 ein make menuconfig ausgeführt.

Dann kommt die Meldung., das die ncurses libraries fehlen und man ncurses (ncurses-devel) installieren soll.

Pakete sind aber nicht verfügbar.

Headers linux-headers-2.6.37-0.slh.7-aptosid-amd64 sind installiert.

Gruß
AnJo
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/27, 15:08:49
Ich schreibe grade einen Artikel. Das Grundgerüst ohne großen sittlichen Nährwert existiert schon. Wenn Du zufällig mit einem -4er Kernel leben kannst, dann liegt einer für amd64 hier: http://alfgaida.de/?debian-Repository

Falls es aktueller sein soll, hilft entweder Geduld oder ein beherzter Blick in das Debian-Verzeichnis der runtergeladenen Quellen. In den rules stehen eigentlich alle Sachen drin, die man braucht ;)

Da ich aber eh momentan keinen Bock habe, zu arbeiten, kann ich auch grade mal einen neuen Kernel zusammenschrauben und meinen Artikel vervollständigen. Das dauert aber naturgegeben eine Weile.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: AnJo on 2011/01/27, 20:12:31
Wow ! Danke agaida !

Unter den neuen -11er läuft vmware super :-)

Wenn ich das richtig verstehe, handelt es sich hierbei um den aktuellen slh-kernel mit config_bkl=y ?

Gruß
AnJo
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/27, 20:26:04
si. Und Towo's Rat folgend, hab ich den komplett gekapert, damit er nicht mit dem normalen Aptosid-Kernel verwechselt wird. BTW ist der Artikel durch die Aktion auf fast fertig geworden und muss nur noch Korrektur gelesen werden.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: AnJo on 2011/01/28, 20:13:18
Hallo agaida,

ich wollte mich einmal selber am Kernel-Bauen probieren.

Habe linux-aptosid-2.6_2.6.37-12.debian.tar.bz2 heruntergeladen und entpackt.

make menuconfig funktioniert auch.

BKL aktivieren unter menupunkt Kernelhacking geht auch inkl.
das Schreiben einer .config.

Weiter will ich es erst nicht versuchen.
Nicht bevor ich weiß ob das die richtigen slh Kernelsourcen sind.
Oder ist das der original Debian Kernel und es gibt irgendwo
die patches, die diesen zu einem aptosid-kernel machen?

Auch wenn es nicht zum Thema upgrade-warnungen gehört, bitte noch einmal INFO.

Danke

Gruß
AnJo
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: towo on 2011/01/28, 21:21:26
apt-get source linux-image-2.6-aptosid-$arch

Mehr braucht man nicht.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/28, 21:48:05
Ein bischen was zum Lesen davor, das hab ich mal so ins Unreine während zweier Bauläufe reingetackert. Ist noch nicht gegengelesen und eigentlich überhaupt nicht überarbeitet. Wer Fehler findet, darf sie behalten oder besser gleich entfernen. Ist schließlich ein Wiki.

http://wiki.g-com.eu/index.php?title=Kernelbau_aptosid
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: AnJo on 2011/01/30, 21:15:41
Hallo,

ich habe es jetzt wie folgt gemacht:

apt-get source linux-image-2.6-aptosid-amd64
cd   ../linux-aptosid-2.6-2.6.37
make menuconfig
hier: Kernel hacking -->    
exit mit speichern
mit fakeroot make-kpkg --initrd kernel_image linux-image-2.6.37_2.6.37-10.00.Custom_amd64.deb erzeugt
mit fakeroot make-kpkg kernel_headers linux-headers-2.6.37_2.6.37-10.00.Custom_amd64.deb erzeugt

Mit den Parameter --append-to-version und --revision kann man noch an der Namensgebung der Pakete etwas
ändern.
Muß ich aber noch ausprobieren.
Man könnte sich dann das editieren unter ../debian/config  ersparen.

Kann es eigendlich sein, dass im 2.6.37-0.slh.12-aptosid-amd64  BKL wieder aktiviert war ??

Gruß
AnJo
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida on 2011/01/30, 23:27:48
Ich will mich nicht streiten, jeder baut sich seine Kernel, wie er will. Ich bevorzuge dabei die bequeme Variante, die definierte Ergebnisse garantiert.

Bei Deiner Variante stören mich nur ein paar Kleinigkeiten: make menuconfig ist bei diesem Kernel garantiert nicht dass, was ich will, weil da die Defaults mitkommen. Natürlich ist dann BKL gesetzt. Der Rest aber auch.

Die weiteren Befehle, die Du zum bauen benutzt, kenne ich nicht und habe auch nicht vor, sie je zu benutzen. Das mit dem make kpkg habe ich nie probiert, ich erinnere mich aber daran, dass debian ein eigenes Target hat, was ich auch nie benutzt habe.

Wenn Du meinen Wiki-Entwurf gelesen hast, dann wird aufgefallen sein, dass pro File nur ein Eintrag geändert wurde. Ich hab mir sogar die Mühe gemacht, Mediawiki anzuweisen, diese wirklich simplen Änderungen farblich hervorzuheben. Das sind die einmaligen Anpassungen, um den aptosid-Kernel einmalig erfolgreich zu kapern. Bei den nächsten Versionen wird nur noch die Nummer angepasst.

Das bisschen geänderte Quelltexte, Patches etc nachhalten erledigt ein Copy, die Kontrolle erfolgt mit bcompare und wenn man dann nach 5-10min mit der Arbeit fertig ist, sichert ein git add . und git commit die geleistete Arbeit. Der Vorgang der weiteren Konfiguration:
Code: [Select]

# debian/rules setup
# debian/rules setup
# debuild -j8
## Zigarette rauchen und Kaffee holen, also ca. 11 min warten
# cd ..
# dpkg -i *.deb
# reboot

Find ich nicht so übertrieben schwer.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: ralul on 2011/01/31, 01:17:53
@agaida, mach mal
/usr/src/linux #  make help |less
Da siehst du dann das Debian Paket Target, aber auch die ganzen config Targets:
make defconfig  (spartanisch)
make oldconfig  (holt sich aus alter .config dei Defaults)....
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: ralul on 2011/01/31, 01:23:29
Quote from: "AnJo"
fakeroot make-kpkg --initrd kernel_image linux-image-2.6.37_2.6.37-10.00.Custom_amd64.deb erzeugt
make-kpkg wird nicht mehr empfohlen laut slh Changelog, weil es ein besseres, offizielles Target für Debian im Kernel-Source selbst gibt!
Quote
Kann es eigendlich sein, dass im 2.6.37-0.slh.12-aptosid-amd64  BKL wieder aktiviert war ??
Du merkst das nicht, wenn du kein Modul benutzt, was BKL braucht...

Das mit dem BKL wegputzen im Aptosid Kernel war meiner Ansicht ein Reinheitswahn....
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida 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.
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: ralul 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!
Title: [gelöst] kernel 2.6.37 slh und proprietäre ati-treiber
Post by: agaida 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.