Re: solution : disk IDE 137 gigas : mixe woody/testing
Le dimanche 13 juillet 2003, Léopold BAILLY a écrit... bonjour, Un de mes profs de maths insistait souvent sur le caractère esthétique des bonnes solutions. Je trouve le 100% empaqueté, particulièrement esthétique, ce qui me fait croire que c'est une bonne solution. Humm ! Si bon = esthétique a-t-on réflexivité ? -- Jean-Michel N'oubliez pas la faq: http://savannah.nongnu.org/download/debfr-faq/html
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le lun 14/07/2003 à 12:33, jean-michel OLTRA a écrit : Le dimanche 13 juillet 2003, Léopold BAILLY a écrit... bonjour, Un de mes profs de maths insistait souvent sur le caractère esthétique des bonnes solutions. Je trouve le 100% empaqueté, particulièrement esthétique, ce qui me fait croire que c'est une bonne solution. Humm ! Si bon = esthétique a-t-on réflexivité ? C'est ce que je pense, mais ça tiens plus de l'intime conviction que de la logique. Disons que c'est un principe qui ne m'a jamais trahi. Léo.
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le samedi 12 juillet 2003, Léopold BAILLY a écrit... bonjour, Donc, je le répète : si tu compiles le paquet toi-même, la dépendance sur la libc disparaît (plus précisément, la dépendance s'établit sur ta propre libc). Le noyau n'est lié avec rien qu'avec lui-même, si je puis m'exprimer ainsi...Tu peux compiler un noyau sur une machine à la debian puis transférer le paquet sur une autre pour l'installer, pour peu que les options de compilation soient adéquates à la machine réceptrice. -- Jean-Michel N'oubliez pas la faq: http://savannah.nongnu.org/download/debfr-faq/html
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le dim 13/07/2003 à 11:50, jean-michel OLTRA a écrit : Le samedi 12 juillet 2003, Léopold BAILLY a écrit... bonjour, Donc, je le répète : si tu compiles le paquet toi-même, la dépendance sur la libc disparaît (plus précisément, la dépendance s'établit sur ta propre libc). Le noyau n'est lié avec rien qu'avec lui-même, si je puis m'exprimer ainsi...Tu peux compiler un noyau sur une machine à la debian puis transférer le paquet sur une autre pour l'installer, pour peu que les options de compilation soient adéquates à la machine réceptrice. Tout à fait, mais il ne s'agit pas de celà. C'est l'installation du paquet des sources du noyau 2.4.20 qui ramème, par un jeu de dépendances, la libc de testing. Ce qui n'est pas le cas si on recompile le paquet des sources (attention dans ce cas, compiler signifie fabriquer kernel-source-2.4.20.deb et non compiler le noyau). C'est un peu tordu mais il y a 2 niveaux de source et de compilation : paquet source de kernel-source - paquet binaire de kernel-source - paquet binaire kernel-image Léo.
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le dimanche 13 juillet 2003, Léopold BAILLY a écrit... bonjour, C'est l'installation du paquet des sources du noyau 2.4.20 qui ramème, par un jeu de dépendances, la libc de testing. Ce qui n'est pas le cas si on recompile le paquet des sources (attention dans ce cas, compiler signifie fabriquer kernel-source-2.4.20.deb et non compiler le noyau). Dans ce cas particulier pourquoi ne pas compiler directement le noyau à partir des sources officielles, c'est certainement plus simple ? -- Jean-Michel, 100% testing avec des kernel-source empaquetés... N'oubliez pas la faq: http://savannah.nongnu.org/download/debfr-faq/html
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le dim 13/07/2003 à 14:36, jean-michel OLTRA a écrit : Le dimanche 13 juillet 2003, Léopold BAILLY a écrit... bonjour, C'est l'installation du paquet des sources du noyau 2.4.20 qui ramème, par un jeu de dépendances, la libc de testing. Ce qui n'est pas le cas si on recompile le paquet des sources (attention dans ce cas, compiler signifie fabriquer kernel-source-2.4.20.deb et non compiler le noyau). Dans ce cas particulier pourquoi ne pas compiler directement le noyau à partir des sources officielles, c'est certainement plus simple ? C'est un choix. Perso, j'aime bien l'idée que tout doit être empaqueté (au nom de la Cohérence), alors je fais le max pour ça. Un de mes profs de maths insistait souvent sur le caractère esthétique des bonnes solutions. Je trouve le 100% empaqueté, particulièrement esthétique, ce qui me fait croire que c'est une bonne solution. Léo.
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le ven 11/07/2003 à 13:51, Gilles Missonnier a écrit : Salut, je ne comprends pas du tout ce que tu ecris : c'est quoi stabilite inferieure ? Soit une relation d'ordre appelée stabilité, on a : woody sarge sid - Seuls les paquets sources des distrib de stabilité inférieure -devraient être récupérés par apt. -Récupérer des paquets binaires d'une distrib de stabilité inférieure = -migrer son système vers la distrib de stabilité inférieure - -J'ai donc une mauvaise nouvelle pour toi, ton système *est* Debian -Sarge. == NON : car il faut un noyau + recent pour avoir les disk IDE 137 le probleme de la necessite de mise a jour de XFS est un probleme qui decoule de la mise a jour du kernel : il faut le patch kernel-patch-xfs_1.2pre4 qui necessite libc6_2.3.1 et libc6-dev_2.3.1 Euh, je ne vois pas le rapport. Mais dans ton cas précis, j'ai récupéré le source (apt-get source) de kernel-patch-xfs-1.3.0pre2 dans unstable et j'ai : $ grep Build-Depends debian/control Build-Depends-Indep: debhelper ( 2.0.0), dh-kpatches, bzip2 Donc, je le répète : si tu compiles le paquet toi-même, la dépendance sur la libc disparaît (plus précisément, la dépendance s'établit sur ta propre libc). Léo.
Re: solution : disk IDE 137 gigas : mixe woody/testing
Salut, je ne comprends pas du tout ce que tu ecris : c'est quoi stabilite inferieure ? - Seuls les paquets sources des distrib de stabilité inférieure -devraient être récupérés par apt. -Récupérer des paquets binaires d'une distrib de stabilité inférieure = -migrer son système vers la distrib de stabilité inférieure - -J'ai donc une mauvaise nouvelle pour toi, ton système *est* Debian -Sarge. == NON : car il faut un noyau + recent pour avoir les disk IDE 137 le probleme de la necessite de mise a jour de XFS est un probleme qui decoule de la mise a jour du kernel : il faut le patch kernel-patch-xfs_1.2pre4 qui necessite libc6_2.3.1 et libc6-dev_2.3.1 -Dans ton cas précis, je pense que -$ apt-get source kernel-patch-xfs -$ apt-get build-dep kernel-patch-xfs -$ cd kernel-patch-xfs-xxx; dpkg-buildpackage -rfakeroot -aurait suffit (en rajoutant deb-src - testing dans sources.list). - -PS2 : mon expérience est testing/unstable, il y a peut-être maintenant -trop d'écart entre stable et testing pour les backports soient faciles. == - gilles missonnier -
solution : disk IDE 137 gigas : mixe woody/testing
Bonjour, mon probleme est résolu : il s'agissait, à partir de woody 2.4.18 de pouvoir installer des disques IDE 137 gigas, ET d'avoir aussi XFS. [ le systeme est en xfs, ce qui a nécéssité une installation à partir de bf2.4 ] J'ai choisi de mélanger woody avec testing, pour les raisons suivantes : - 1 - il faut un kernel 2.4.19 mini - 2 - le patch XFS pour les kernel = 2.4.19 nécéssite kernel-patch-xfs_1.2pre4-1, et l'application de ce patch demande entre autres libc6_2.3.1 J'ai mélangé testing et stable dans /etc/apt/sourcelist : c'est peut-être une mauvaise idée ... [ un avis ?? ] Pour l'instant cela marche... le mélange woody/testing m'inquiète un peu quand je lis dans la liste debian-user : ___ For future reference, it's almost never a good idea to play with libc6 manually. If you have a package that won't install because it wants 'libc6 = 2.3.1-16' or whatever, either rebuild it from source AGAINST YOUR CURRENT LIBC6, or upgrade your entire system to sarge/sid and run it there. Or make a chroot with libc6-2.3.1-16 ___ je n'ai pas tenté d'utiliser chroot. en fin de message, je joins mon HOWTO_a_moi : il y a bien un newbie qui touvera ça pratique. merci à Frédéric Bothamy , et Carlos Carvhalo = Gilles MISSONNIER - Projet Terapix phone : [33] 01 44 32 81 36 http://terapix.iap.fr == -Tu peux aussi récupérer une archive des sources du noyau, appliquer -manuellement la dernière rustine pour XFS et utiliser kernel-package -pour créer un paquet .deb adapté (ou encore ne pas utiliser la méthode -Debian si tu ne l'aimes pas). - - -Fred == == HOWTO_a_moi_que_G --- mise a jour du noyau 2.4.18 - 2.4.20 ainsi que les patch xfs correspondants ; 1 - modifier /etc/apt/sources.list ajouter les 2 lignes : deb ftp://ftp.us.debian.org/debian/ testing main non-free contrib deb-src ftp://ftp.us.debian.org/debian/ testing main non-free contrib ___ 2 - mettre a jour sources.list apt-get update ___ 3 - installer les sources du noyau 2.4.20: apt-get install kernel-source-2.4.20 [ cela telecharge kernel-source-2.4.20_2.4.20-8_all.deb dans /var/cache/apt/archives/ + en extrait kernel-source-2.4.20.tar.bz2 dans /usr/src/ ] cd /usr/src tar -xjvf kernel-source-2.4.20.tar.bz2 ___ 4 - installer le patch xfs: apt-get install kernel-patch-xfs ATTENTION : cette etape demande la mise ajour de package : [ voir dans /var/cache/apt/archives/ ] voici les paquets suceptibles d'etre mis a jour : grep-dctrl_1.11_i386.deb kernel-patch-scripts_0.99.23_all.deb kernel-patch-xfs_1.2pre4-1_all.deb libc6-dev_2.3.1-16_i386.deb libc6_2.3.1-16_i386.deb libdb1-compat_2.1.3-7_i386.deb libncurses5-dev_5.3.20030510-2_i386.deb libncurses5_5.3.20030510-2_i386.deb locales_2.3.1-16_all.deb ncftp_2%3a3.1.3-1_i386.deb tcl8.0_8.0.5-7_i386.deb tk8.0_8.0.5-10_i386.deb cd /usr/src/kernel-source-2.4.20 ../kernel-patches/all/apply/xfs ___ 5 - compilation du noyau make mrproper make xconfig -- ATTENTION : si make xconfig ne marche pas, cette etape peut eventuellement demander une installation de wish qui necessite tk -- UTILISER le .config du noyau precedent et saugarder le nouveau .config make dep clean modules bzImage make modules_install ___ 6 - mise en place du noyau copier System.map dans /boot cp System.map /boot/System.map-2.4.20 copier arch/i386/boot/bzImage dans /boot cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20 changer les liens pour le boot rm /boot/System.map ln -s /boot/System.map-2.4.20 /boot/System.map ___ 7 - editer /etc/lilo.conf default=2_4_20 image=/boot/vmlinuz-2.4.20 label=2_4_20 read-only -- ATTENTION : il faut ensuite faire lilo pour prendre en compte le nouveau /etc/lilo.conf
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le jeu 10/07/2003 à 13:36, Gilles Missonnier a écrit : --- mise a jour du noyau 2.4.18 - 2.4.20 ainsi que les patch xfs correspondants ; 1 - modifier /etc/apt/sources.list ajouter les 2 lignes : deb ftp://ftp.us.debian.org/debian/ testing main non-free contrib deb-src ftp://ftp.us.debian.org/debian/ testing main non-free contrib ___ 2 - mettre a jour sources.list apt-get update ___ 3 - installer les sources du noyau 2.4.20: apt-get install kernel-source-2.4.20 [ cela telecharge kernel-source-2.4.20_2.4.20-8_all.deb dans /var/cache/apt/archives/ + en extrait kernel-source-2.4.20.tar.bz2 dans /usr/src/ ] cd /usr/src tar -xjvf kernel-source-2.4.20.tar.bz2 ___ 4 - installer le patch xfs: apt-get install kernel-patch-xfs ATTENTION : cette etape demande la mise ajour de package : [ voir dans /var/cache/apt/archives/ ] voici les paquets suceptibles d'etre mis a jour : grep-dctrl_1.11_i386.deb kernel-patch-scripts_0.99.23_all.deb kernel-patch-xfs_1.2pre4-1_all.deb libc6-dev_2.3.1-16_i386.deb libc6_2.3.1-16_i386.deb libdb1-compat_2.1.3-7_i386.deb libncurses5-dev_5.3.20030510-2_i386.deb libncurses5_5.3.20030510-2_i386.deb locales_2.3.1-16_all.deb ncftp_2%3a3.1.3-1_i386.deb tcl8.0_8.0.5-7_i386.deb tk8.0_8.0.5-10_i386.deb cd /usr/src/kernel-source-2.4.20 ../kernel-patches/all/apply/xfs ___ 5 - compilation du noyau make mrproper make xconfig -- ATTENTION : si make xconfig ne marche pas, cette etape peut eventuellement demander une installation de wish qui necessite tk -- UTILISER le .config du noyau precedent et saugarder le nouveau .config make dep clean modules bzImage make modules_install légère critique ici: un chtit make dep clean modules_install install ne serait-il pas plus élégant pour éviter la partie 6 ? (aussi: faut faire gaffe à recompiler également les modules qui pourrait être extérieurs à l'arbo du noyau, style alsa ou lirc because make modules_install a une légère tendance à effacer TOUS les modules issus de la même version du noyau avant ...) ___ 6 - mise en place du noyau copier System.map dans /boot cp System.map /boot/System.map-2.4.20 copier arch/i386/boot/bzImage dans /boot cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20 changer les liens pour le boot rm /boot/System.map ln -s /boot/System.map-2.4.20 /boot/System.map ___ 7 - editer /etc/lilo.conf default=2_4_20 image=/boot/vmlinuz-2.4.20 label=2_4_20 read-only -- ATTENTION : il faut ensuite faire lilo pour prendre en compte le nouveau /etc/lilo.conf Nicolas Rueff http://rueff.tuxfamily.org +33 6 77 64 44 80 -- NZ alex, tu doit taper ftp://troll/and/emulation/for/warez/sucks:10 marche toujours pas revoyez un peu vos liens, c'est pas la peine de poster des ftps qui ne marchent pas -+- Alex in GPJ: Fatal Error at h0Bx0400, please Re-Insert Brain -+- signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le jeu 10/07/2003 à 13:36, Gilles Missonnier a écrit : J'ai mélangé testing et stable dans /etc/apt/sourcelist : c'est peut-être une mauvaise idée ... [ un avis ?? ] Mon avis ? Je sors ma rengaine habituelle : Seuls les paquets sources des distrib de stabilité inférieure devraient être récupérés par apt. Récupérer des paquets binaires d'une distrib de stabilité inférieure = migrer son système vers la distrib de stabilité inférieure J'ai donc une mauvaise nouvelle pour toi, ton système *est* Debian Sarge. Dans ton cas précis, je pense que $ apt-get source kernel-patch-xfs $ apt-get build-dep kernel-patch-xfs $ cd kernel-patch-xfs-xxx; dpkg-buildpackage -rfakeroot aurait suffit (en rajoutant deb-src - testing dans sources.list). PS1 : j'ai toujours travaillé en testing et je n'ai jamais eu aucun problème. PS2 : mon expérience est testing/unstable, il y a peut-être maintenant trop d'écart entre stable et testing pour les backports soient faciles. Léo.
Re: solution : disk IDE 137 gigas : mixe woody/testing
Le jeudi 10 juillet 2003, Gilles Missonnier a écrit... bonjour, 5 - compilation du noyau make mrproper make xconfig -- ATTENTION : si make xconfig ne marche pas, cette etape peut eventuellement demander une installation de wish qui necessite tk -- UTILISER le .config du noyau precedent et saugarder le nouveau .config make dep clean modules bzImage make modules_install Dire qu'il y en a qui ont développé l'excellent kernel-package. Je compte demain soir compiler un noyau avec le patch xfs et grsecurity et j'aime mieux te dire que je ne vais pas taper tant de trucs... -- Jean-Michel N'oubliez pas la faq: http://savannah.nongnu.org/download/debfr-faq/html
