Siduction Forum
Siduction Forum => Experimental => Topic started by: 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.
-
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.
-
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.
-
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.
-
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.
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.
-
Danke für deine Mühe, aber ich muss dir leider mitteilen, das bei mir FGLRX trotzallem nicht geht. Module bauen wird abgebrochen ;(
-
fglrx-source? apt-get build-dep fglrx-driver?
-
hmm :?:
# 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.
-
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.
-
# 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...
-
Tja, fglrx ist eben nicht 2.6.37 ready.
Btw, welche fglrx-Version ist das?
http://www.phoronix.com/forums/showthread.php?t=26981
-
die aus experimental ...
edit: im patchen bin ich noch nicht so fit - dann warte ich lieber bis fglrx wieder ready ist ;)
-
Naja, 11-01 soll mit 2.6.37 support kommen, dann gehts vermutlich sogar ohne BKL.
-
Jut, danke für die info und hilfe.
Schon ne ahnung wann das kommen soll?
-
Nein, aber gewöhnlich kommen die Treiber immer gegen Ende eines Monats raus.
-
ok ;)
-
Kernel gelöscht. Ich mach dann mal eine aptosid-Pause, bis es denn wieder funktioniert. Andere Distributionen können das ja auch ohne Probleme. Der Trend geht zum Arch im Hintergrund.
-
naja ein Arch wird einfach nicht den aktuellsten Kernel nutzen ;)
-
slh war schneller.
Linux archramme 2.6.37-ARCH #1 SMP PREEMPT Fri Jan 7 17:32:33 CET 2011 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux
==========/proc/version (22:11)==========
Linux version 2.6.37-ARCH (tobias@T-POWA-LX) (gcc version 4.5.2 (GCC) ) #1 SMP PREEMPT Fri Jan 7 17:32:33 CET 2011
==========gcc --version==========
gcc (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
==========/usr/bin/fglrxinfo==========
libGL: XF86DRIGetClientDriverName: 8.80.5 fglrx (screen 0)
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri//fglrx_dri.so
ukiDynamicMajor: found major device number 251
ukiDynamicMajor: found major device number 251
ukiOpenByBusid: Searching for BusID PCI:1:0:0
ukiOpenDevice: node name is /dev/ati/card0
ukiOpenDevice: open result is 6, (OK)
ukiOpenByBusid: ukiOpenMinor returns 6
ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 4800 Series
OpenGL version string: 3.3.10362 Compatibility Profile Context
[agaida@archramme bcompare]$ kde-config -v
Qt: 4.7.1
KDE: 4.5.95 (4.6 RC2)
kde4-config: 1.0
X.Org X Server 1.9.2
Release Date: 2010-10-30
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.35-ck x86_64
Current Operating System: Linux archramme 2.6.37-ARCH #1 SMP PREEMPT Fri Jan 7 17:32:33 CET 2011 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz26 root=/dev/disk/by-label/archlinux pci=use_crs nopat lapic nolapic_timer radeon.modeset=0
Build Date: 04 January 2011 04:52:48PM
Current version of pixman: 0.20.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Es soll wirklich niemand denken, dass ich streng rückschrittlich wäre.
-
Hi
Bin mir grade dabei deinem gcom kernel zu installieren und mir ist nicht klar was da für veränderungen gemacht wurden.
Soll heisen in der Paketbeschreibung steht nicht drin worin sich dein Kernel und der normale Aptosid und der Debian unterscheiden. Es steht bei allen 3 nur: "The Linux kernel 2.6.37 and modules for use on PCs with AMD64 or Intel 64
processors."
Nirgend wird erwähnt das der Aptosid zusätzlich gepatch wurde und das bei deinem zb der BLK Schlater wieder an ist.
Könntest du das noch in die desc haken dann bin ich und warscheinlcih auch andere nicht mehr so verwirrt/unsicher welcher kernel jetzt was tut/kann.
Danke
Manu
-
Kann man machen. Ich schreib mir ein Ticket dazu.
Ich hab eigentlich noch nie eine Kernelbeschreibung gelesen. Wenn mich interessiert, was geändert wurde (in allen Paketen, die ich bisher in der Mache hatte), lese ich das Changelog und gut is. Da steht im allgemeinen so was drin, was aktuelle Änderungen betrifft.
-
Danke :-D
Wie komme ich an ein chlog wenn der kernel noch nicht installiert ist ?
schönen tag
-
für die offiziellen aptosid-kernel: http://svn.berlios.de/svnroot/repos/fullstory/linux-aptosid-2.6/trunk/debian/changelog
greetz
devil
-
Womit wir am Thema wären: Genau an so einem Repo sitze ich grade dran. Allerdings hätte ich das gern in schnell. Hat da jemand Erfahrungen mit der Schnittstelle git/svn?
Wenn das in schnell gehen würde, könnte ich das einfach auf ein svn/trac-Hosting packen und meine Probleme mit der Geschwindigkeit von SVN wären weg. Und ich hätte ein Hosting mit trac. Ich hasse es, commits per Hand im Tracking nachzufrickeln.
Daran scheitert es momentan noch, project-locker.com bekomme ich nicht öffentlich.
EDIT: So, ein neues Hosting ist gefunden, dass auf git setzt und in dem man per commit auch den Issues bearbeiten kann. Ich hab mich dann mal angemeldet. 500M sollten ja doch eine Weile reichen. Ich habe zwar nie zuvor von codaset gehört, aber es macht einen guten Eindruck. Es scheint alles dabei zu sein, was man so braucht: blog, wiki, tracker, git - mal sehen, wie das wird. Und sie hosten OSS kolo.
-
Noch ein update. Die Quellen für den linux-gcom-kernel liegen jetzt auf github:
https://github.com/AGaida/linux-2.6-gcom/blob/master/gcom/debian/changelog
Das wird sich vermutlich auch nicht ändern, bis auf den Bugtracker ist github Spitze. Was mich aber eigentlich vielmehr interessieren würde: Was muss man eigentlich machen, damit bei eigenen Paketen
apt-get changelog paket
ein nettes Changelog ausgegeben wird? Mit den offiziellen Debian-Paketen klappt das ja vom Feinsten. So etwa gibt
apt-get changelog apt
apt (0.8.11.1) unstable; urgency=low
[ Stefan Lippers-Hollmann ]
* cmdline/apt-key:
- fix root test which prevented setting of trustdb-name
which lets gpg fail if it adds/remove keys from trusted.gpg
as it tries to open the (maybe) not existent /root/.gnupg
[ David Kalnischkies ]
* debian/apt.symbols:
- add more arch dependent symbols
-- Michael Vogt <mvo> Wed, 09 Feb 2011 17:49:59 +0100
apt (0.8.11) unstable; urgency=low
...
Da ich da bekannte Namen lese, was kann man tun, dass z.B. reprepro das auch ausgibt. Im Moment scheitert das bei mir daran, dass ich ganz stumpf kein Changelog in Reprepro habe. Das sollte man ja abstellen können - das wäre mal was richtig Feines, das Changelog aus der Revisionskontrolle rauszunehmen ist zwar möglich, kann aber nicht wirklich der Weg sein. Komfort sieht anders aus, so wie oben.
Danke für diese Umsetzung der im Artikel angekündigten Erweiterung von apt an DonKult, wenn Du das gemacht hast. Das ist klasse.