Author Topic: [DE] [gelöst] Repo up (Read 12226 times)

agaida · « **on:** 2011/01/12, 10:34:26 »

Nach den kleinen Startschwierigkeiten mit 2.6.37 habe ich das Ding mal mit eingeschaltetem BKL selbst gebaut. Infos zum Repo gibts unter http://alfgaida.de , das Repo selbst liegt unter http://debian.alfgaida.de .

Wer nicht selbst bauen möchte, ist herzlich eingeladen, bei genügend Mut diesen Kernel zu benutzen. Es ist mein erster und hält sich bis auf die BKL-Zeile an den von slh. Die restlichen Änderungen sind nichts funktionales, eigentlich ein paar Schritte zurück, anfangs kam reprepro (oder meine Wenigkeit) nicht mit den Formaten für die Pakete klar.

Schnell genug sollte das eigentlich sein, das Repo ist mit 10M angebunden.

Das das Ganze noch leicht experimentell ist, hatte ich bereits erwähnt, der Kernel war jetzt nur der Punkt, an dem ich das Thema Repository vorgezogen habe, da ich das eigentlich für die anderen dort liegenden Pakete brauchte.

Wer selbst bauen möchte, für den könnte das .37 linux-kbuild interessant sein.

towo · « **Reply #1 on:** 2011/01/12, 10:45:34 »

Nur mal ein paar Hinweise:

1. Das Meta-Paket so zu nennen, wie das offizielle Paket, ist keine tolle Idee.
2. linux-kbuild wird gar nicht gebraucht, wenn man das Buildframework von slh benutzt.

agaida · « **Reply #2 on:** 2011/01/12, 11:05:47 »

1. Das Metapaket werde ich ändern, kein Problem. Die ganze Aktion steht deshalb unter experimentell, weil sie experimentell ist. Ich bin erst einmal froh, dass für mich das Thema vom Tisch ist. Fürs erste nehme ich einfach mal das Metapaket aus dem Repo.
2. Nicht alle Kernel benutzen das Buildframework von slh. Das ist aber natürlich klasse und erledigt auch die Frage, ob man zum bauen noch Scripte braucht auf recht geniale Weise. Manchmal hat man aber auch andere Sachen zu bauen, bei denen die Kernel-Header recht hilfreich sind. Die haben dummerweise als Abhängigkeit ein linux-kbuild. Ob an dieser Stelle auch ein dummy-Paket gereicht hätte: k.A. Siehe auch den Grund für diese Aktion: Catalyst.
3. Da es eine Anleitung für das kbuild im debian Wiki gibt, habe ich es erst einmal danach gebaut. Kein Mensch muss es einsetzen, aber ich finde es zumindest für mich hilfreich, so was fertig im Zugriff zu haben.

towo · « **Reply #3 on:** 2011/01/12, 11:11:41 »

Quote

2. Nicht alle Kernel benutzen das Buildframework von slh. Das ist aber natürlich klasse und erledigt auch die Frage, ob man zum bauen noch Scripte braucht auf recht geniale Weise. Manchmal hat man aber auch andere Sachen zu bauen, bei denen die Kernel-Header recht hilfreich sind. Die haben dummerweise als Abhängigkeit.

??
Auch wenn man das Framework von slh benutzt entstehen Kernel-Header, welche keine Abhängigkeiten zu linux-kbuild haben.

agaida · « **Reply #4 on:** 2011/01/12, 12:01:15 »

Die Kernel-Header, die mit slhs Framework gebaut wurden, haben die Abhängigkeit zum linux-kbuild-2.6.37 nicht.

Mal ganz ehrlich, was soll das - ich will eigentlich nicht den Gernot Hassknecht geben, aber

Für debian-Kernel, die nicht slh heissen, brauche ich ein linux-kbuild. Ausnahme: Kernel, die auf slh basieren. Dass sich meine Begeisterung über die ein oder andere Entscheidung, die slh getroffen hat, in recht eng dimensionierten Grenzen bewegt, habe ich wohl deutlich zum Ausdruck gebracht. Das hat aber nichts mit der Qualität der Arbeit an sich, sondern einzig und allein mit dem Verzicht auf BKL zu tun.

Kernel, die im experimental hängen, sind ohne linux-kbuild für mich wertlos, ich kann nicht mal die Header dazu installieren. In meinem Fall heisst das: Kein Catalyst. Auch dazu habe ich meine ganz persönliche Meinung.

Code: [Select]


agaida@aptosid:~$ apt-rdepends linux-headers-2.6.37-trunk-all
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Statusinformationen werden eingelesen... Fertig
linux-headers-2.6.37-trunk-all
  Hängt ab von: linux-headers-2.6.37-trunk-all-amd64 (= 2.6.37-1~experimental.1)
linux-headers-2.6.37-trunk-all-amd64
  Hängt ab von: linux-headers-2.6.37-trunk-amd64 (= 2.6.37-1~experimental.1)
linux-headers-2.6.37-trunk-amd64
  Hängt ab von: gcc-4.4
  Hängt ab von: linux-headers-2.6.37-trunk-common (= 2.6.37-1~experimental.1)
  Hängt ab von: linux-kbuild-2.6.37

Ich gebe ja zu, dass ich ein wenig halsstarrig bin, aber das hat einen Vorteil, mein Zeug funktioniert so, wie ich das haben will. Ich habe nicht vor, mir vorschreiben zu lassen, welche Hardware und welche Treiber ich zu benutzen habe. Wenn ich dann durch Tests dazu gebracht werden kann, meine Meinung zu ändern, ist das in Ordnung. Ich muss aber die Chance haben, mir meine Meinung zu bilden. Das absolutistische Ausschließen bestimmter Optionen mit dem Hinweis, dass das jetzt einfach so sei, dient nicht dazu, meine Laune in irgendeiner Weise zu verbessern. Dazu bin ich dann doch zu eigenständig.

reddark · « **Reply #5 on:** 2011/01/12, 12:01:33 »

Danke für deine Mühe, aber ich muss dir leider mitteilen, das bei mir FGLRX trotzallem nicht geht. Module bauen wird abgebrochen ;(

agaida · « **Reply #6 on:** 2011/01/12, 12:03:04 »

fglrx-source? apt-get build-dep fglrx-driver?

reddark · « **Reply #7 on:** 2011/01/12, 12:17:44 »

hmm :?:

Quote

# apt-get build-dep fglrx-driver
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
libqt4-dev : Hängt ab von: libqt4-dbus (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-qt3support (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-xml (= 4:4.6.3-4) aber 4:4.7.1-2 soll installiert werden
Hängt ab von: libqtcore4 (= 4:4.6.3-4) aber 4:4.7.1-2 soll installiert werden
Hängt ab von: libqtgui4 (= 4:4.6.3-4) aber 4:4.7.1-2 soll installiert werden
Hängt ab von: libqt4-network (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-svg (= 4:4.6.3-4) aber 4:4.7.1-2 soll installiert werden
Hängt ab von: libqt4-webkit (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-sql (= 4:4.6.3-4) aber 4:4.7.1-2 soll installiert werden
Hängt ab von: libqt4-script (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-scripttools (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-xmlpatterns (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-designer (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-help (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-assistant (= 4:4.6.3-4) soll aber nicht installiert werden
Hängt ab von: libqt4-test (= 4:4.6.3-4) aber 4:4.7.1-2 soll installiert werden
Hängt ab von: libqt4-multimedia (= 4:4.6.3-4) soll aber nicht installiert werden
E: Bauabhängigkeiten für fglrx-driver konnten nicht erfüllt werden.

towo · « **Reply #8 on:** 2011/01/12, 12:20:46 »

apt-get build-dep fglrx-driver is absoluter Unsinn!

apt-get install fglrx-source
m-a -t build fglrx-source

Da sieht man dann auch, wo es hakt.

reddark · « **Reply #9 on:** 2011/01/12, 12:22:23 »

Quote

# m-a -t build fglrx-source
Extracting the package tarball, /usr/src/fglrx.tar.bz2, please wait...
/usr/bin/make -f debian/rules clean
make[1]: Entering directory `/usr/src/modules/fglrx'
dh_testroot
rm -f configure-stamp
rm -f fglrx.ko fglrx.mod.c *.o libfglrx_ip.a
rm -f .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
rm -rf patch
dh_clean
dh_clean: cannot read debian/control: Datei oder Verzeichnis nicht gefunden

make[1]: *** [clean] Fehler 2
make[1]: Leaving directory `/usr/src/modules/fglrx'
make: *** [kdist_clean] Fehler 2
/usr/bin/make -f debian/rules binary_modules
make[1]: Entering directory `/usr/src/modules/fglrx'
if [ -f /usr/src/modules/fglrx/debian/control.template ]; then \
cat /usr/src/modules/fglrx/debian/control.template > /usr/src/modules/fglrx/debian/control; \
fi
dh_testdir
touch configure-stamp
dh_testdir
/usr/bin/make -C /usr/src/linux SUBDIRS=/usr/src/modules/fglrx modules
make[2]: Entering directory `/usr/src/linux-headers-2.6.37-0.gc.3-aptosid-amd64'
CC [M] /usr/src/modules/fglrx/firegl_public.o
/usr/src/modules/fglrx/firegl_public.c:417: warning: initialization from incompatible pointer type
/usr/src/modules/fglrx/firegl_public.c: In function ‘KAS_Mutex_Initialize’:
/usr/src/modules/fglrx/firegl_public.c:5120: error: implicit declaration of function ‘init_MUTEX’
make[3]: *** [/usr/src/modules/fglrx/firegl_public.o] Fehler 1
make[2]: *** [_module_/usr/src/modules/fglrx] Fehler 2
make[2]: Leaving directory `/usr/src/linux-headers-2.6.37-0.gc.3-aptosid-amd64'
make[1]: *** [build] Fehler 2
make[1]: Leaving directory `/usr/src/modules/fglrx'
make: *** [kdist_image] Fehler 2
BUILD FAILED!
See /var/cache/modass/fglrx-source.buildlog.2.6.37-0.gc.3-aptosid-amd64.1294831304 for details.
Bauvorgang fehlgeschlagen. Zum Weitermachen Return drücken...

towo · « **Reply #10 on:** 2011/01/12, 12:26:35 »

Tja, fglrx ist eben nicht 2.6.37 ready.
Btw, welche fglrx-Version ist das?

http://www.phoronix.com/forums/showthread.php?t=26981

reddark · « **Reply #11 on:** 2011/01/12, 12:28:54 »

die aus experimental ...

edit: im patchen bin ich noch nicht so fit - dann warte ich lieber bis fglrx wieder ready ist

towo · « **Reply #12 on:** 2011/01/12, 12:36:31 »

Naja, 11-01 soll mit 2.6.37 support kommen, dann gehts vermutlich sogar ohne BKL.

reddark · « **Reply #13 on:** 2011/01/12, 12:38:02 »

Jut, danke für die info und hilfe.
Schon ne ahnung wann das kommen soll?

towo · « **Reply #14 on:** 2011/01/12, 12:47:49 »

Nein, aber gewöhnlich kommen die Treiber immer gegen Ende eines Monats raus.