Reprise du message précédent :
que tu as choisi l'option preemptible kernel

hein ? mais eu j'ai rien mis de particulier
 
j'ai juste utilisé make-kpkg pour tester...

Bon effectivement, j'ai ça dans le noyau, ça a du etre ajouté par le 2.6.14.2 alors.
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y

non ca date d'un moment deja l'intégration du preempt dans le kernel  Ca permet plus de réactivité dans une utilisation desktop

 
Bam!
 
http://article.gmane.org/gmane.linux.kernel/347644

gni ?

A vrai dire j'ai également compilé un 2.6.14 maison récemment et des choses ont été modifiées à ce niveau. Jusqu'alors on pouvait activer/désactiver l'option PREEMPT point barre, mais à présent on a le choix entre 3 modes de réactivité au niveau du kernel : un mode server (clé CONFIG_PREEMPT_NONE), un mode desktop (clé CONFIG_PREEMPT_VOLUNTARY) et enfin un mode embeded desktop (clé CONFIG_PREEMPT) ; perso j'ai opté pour le mode desktop (semi-preemptible).

Une ou deux question à part ça en ce qui concerne Sid :
 
1) j'ai remarqué que /etc/modules n'est à présent plus utilisé ; je l'utilisais jusqu'ici pour charger 2-3 modules qui ne figurent pas dans /etc/modules.conf et pour lequel je n'ai pas d'alias (je pense aux modules USB précisément : ohci-hcd et usbhid). C'était une solution qui m'arrangeait dans la mesure où je n'avais pas besoin d'utiliser cette horreur d'hotplug qui charge près de 60 modules qui me sont inutiles... Et vous qu'est-ce que vous utilisez pour gérer ces modules ?
 
2) le fichier /etc/network/options va être apparemment abandonné à terme (indiqué lors du boot) puisque la config des options réseau au niveau du noyau semble vouloir être faite depuis /etc/sysctl.conf ; jusque là rien de dérangeant mais alors je me demande pourquoi le réseau ne fonctionne plus du tout (plus d'interfaces, même pas de boucle locale) si on met en commentaire le contenu de ce fichier ?

 
Par defaut, c'est le full preempt
 

 
euh /etc/modules semble encore fonctionné chez moi. Qu'est-ce qui te fait dire qu'il n'est plus utilisé ?

Facile, hier j'ai démarré ma machine tout fonctionnait encore sans problème ; dans la soirée j'ai rapidement fait une mise à jour de Sid et ce matin au redémarrage je me rend compte que les modules que j'ai spécifié dans /etc/modules ne sont précisément plus chargés...

De plus j'ai aussi un message erreur à la con qui se répète pas mal de fois lors du boot "grep  error while loading shared library : libcpre3.so" (ou quelque chose dans le genre) qui n'apparaissait pas avant les mises à jour d'hier ; je ne sais pas si c'est lié.
 
apt-listbugs ne m'a rien signalé comme bug critique ou grave, donc...

Ton binaire grep doit etre lié à la lib pcre, qui ne doit pas etre dispo a ce moment du boot (/usr/lib/libpcre.so)
 
Si tu fais un ldd /bin/grep la dependance à la libpcre apparait-elle ?
 
A priori c'est pas super bon signe quand même

Bug connu : http://bugs.debian.org/cgi-bin/bug [...] bug=338700

udev fonctionne bien je trouve (je sais pas comment, j'ai jamais rien compris à qui faisait quoi entre udev, hotplug, dbus, hal...), et depuis qu'hotplug n'est plus utilisé il n'essaye plus de loader 36 fois les mêmes modules au boot

personne n'a de sources apt pour kde3.5, ya la rc1 qui vient de sortir et j'ai la flemme de compiler

http://pkg-kde.alioth.debian.org/

MERCI !!!!!!!!!
 

T'as bien lu le http://pkg-kde.alioth.debian.org/3 [...] README.txt j'espere

bon bien je coupe mon apt-get dist-upgrade ............
 
je vais attendre, merci quand meme

j'utilise udev pour ma part et il ne charge pas de modules inutiles puisque je les ai viré du noyo    
ceci dit certains modules ne sont toujours pas chargés automatiquement (psmouse par exemple) et j'utilise toujours ce fichier pour ça (et ça marche chez moi)
 

moi j'ai viré le fichier et ça continue de marcher (j'ai pas fait plus de test mais j'ai bien vérifié que les valeurs dans /proc sont bonnes)
 
 
EDIT
oups, j'aurais du lire la suite    
saleté de grep !  

 

 
 
EDIT

bon décidément il faut que j'apprenne à lire la suite    

Oki, merci pour ces précisions utiles ; remarque le bug est connu... maintenant (c'est daté du 12 nov 2005 à 01:02).
Hier quand j'ai fait la mise à jour hélas non résultat ça a un peu foutu la merde (bon heureusement on a toujours la main sur la console).

Bah je n'utilise pas encore udev chez moi... j'ai peut-être tort remarque
 
A l'époque où udev à fait son apparition il était lié à hotplug ce qui était merdique à mon goût, enfin bon c'est une autre histoire, de plus certains utilisateurs ayant passé à udev rencontraient des problèmes avec la création de certains blocs de périphériques ou de droit d'accès aux blocs de périphériques créés par udev ; faut dire qu'entre temps ces problèmes ont peut-être été réglés ?
 
Ca tourne correctement chez vous ? Si udev est intéressant je vais peut-être finir par le mettre en place... ya des manips' ou astuces particulières à savoir (au niveau noyal y a un truc précis à faire ?) ou un simple aptitude install udev suffit pour que tout tourne au poil ?

Nan mais ils mettent en garde, ca veut pas dire que c'est tout cassé, il faut juste que l'un de vous deux se lance et l'autre saura

temporairement tu peux peut etre copier la libpcre.so dans /lib ?

yep mais ce n'est plus la peine ; le bug (qui vient de grep) a apparemment été fixé (-c'est marqué fixed sur le bug report Debian, résolu dans la version 2.5.1.ds2-4 de grep ; faut dire que la sévérité était quand même marquée en critical).
 
Normalement un dist-upgrade de Sid ne devrait donc à présent résoudre le bug avec grep et ne plus poser problème  (du moins à ce niveau ), mais pour l'instant je n'ai pas encore essayé.

 
hmm, moi pour être franc j'ai jamais eu trop de problème mais là ça marche vraiment bien chez moi
par contre il semblerait que certains aient eu des problèmes quand hotplug a été jeté. Je ne sais pas si c'est réglé maintenant.
note que j'utilise dbus+hal+pmount sous kde, donc tout se passe de manière transparente quand je branche un nouveau periph (vivement kde 3.5 qui améliore encore la gestion des périph)

Pour dbus et hal, je les ai également, ils ont été installés automatiquement bien que je n'utilise ni l'environnement Gnome, ni l'environnement KDE ; certains paquets doivent donc en avoir besoin sans que je sache exactement lesquels et pourquoi (je n'ai pas cherché à savoir précisément leur fonction sur mon système faut dire).
 
Pour pmount, je gère le montage de mes périph amovibles à "l'ancienne" (comprendre à la main donc ), mais cela est principalement dû au fait que je n'utilise qu'un périph amovible (le lecteur/graveur dvd/cd) et je ne m'en sers pas systématiquement, pour ne pas dire occasionnellement.

 
C'est bon, tout est parfaitement rentré dans l'ordre   Comme je le pensais un aptitude update && aptitude dist-upgrade à mis à jour la version de grep et à résolu du coup tout mes problèmes précédents  

Je reviens à la charge avec les mises à jour sous Sid    
 
 
Lors des mises à jour les paquets libc6 et locales sont marqués comme contenant les mêmes bogues graves ou critiques (pour la libc6 : bogues NIS, atd, GLibC, PAM, pour locales : bogues des scripts post-install ), et ce depuis un bon moment (sur le BTS certains d'entre eux sont ouverts apparement depuis près de 2~3 mois).
 
 
Perso j'ai maintenu à une version antérieure la libc6 et locales (la version 2.3.5-6 pour être précis sachant que les bogues concernent les version 2.3.5-7 et 2.3.5-8 pour les deux paquets), comme il s'agit de paquets sensibles (d'ailleurs j'ai aussi vu que coreutils était récemment affecté par de sérieux bogues) je me demande comment ceux qui sont sous Sid ici ont gérés ce deux paquets en particulier jusqu'ici ?  
 
Vous les avez malgré tout mis à jour en passant outre les rapports de bogues indiqués par apt-listbugs ou êtes-vous aussi resté à une version antérieure ?  

amd64, tout à fond (comprendre, dernières versions dispo )

j'ai installé kde 3.5 avec les sources ci dessus, il n'y a aucun probleme majeur, ca marche plutot bien

Et pas le moindre prob ?  
 
Nan parce que la dernière fois que j'ai pas tenu compte de rapports de bogues critiques j'ai eu quelques emmerdes (bon c'est résolu mais c'est toujours mieux de les éviter quand c'est possible)  

aucun probleme, peut etre un konqueror qui a planté  une fois, je trouve kde un peu plus rapide a defaut d'une veritable revolution, ya une nouvelle version de kopete fort sympathique, la gestion des periphs usb est niquelle.
 
aucun probleme de dependance,, c'est passé comme une letrre a la poste

Ou comme papa dans ma...    (ok je sort)

Tiens un truc sympa que j'ai découvert par hasard en surfant sur le web ce soir,
 
- la liste des nouveaux paquets ajoutés récemment (au cours des 7 derniers jours) à l'archive unstable (section main) :
  ---> http://packages.debian.org/unstable/newpkg_main
 
 
A noter que c'est également dispo via RSS, voilà qui est pratique.  

Bah, quand ils ont changés d'ABI après la sortie de Sarge, j'en ai un peu chié
Mais bon, tu vas faire un tour dans le BTS, tu rapportes quelques bugs si il faut, et voilà
 
Au final, à part pendant deux ou trois semaines ou quelques applis ne s'installaient plus (problèmes de dépendances sur d'anciennes versions), ça m'a pas plus gêné que ça
 
Le plus "chiant" en fait là, c'est que des paquets n'existe pas encore pour amd64, alors qu'en i386 ils fonctionnent bien (rosegarden4 et oo2 pour ma part)

 
c'est répugnant  

est-ce quelqu'un a reussi a installer GRUB sur un raid 100% hard ?? (l'installeur ne vois qu'un disque virtuel)
C'est dans le cas d'un serveur HP Proliant, avec une carte utilisant le module cciss (de mémoire).
l'astuce utilisée pour réussir mon install a été de mettre LILO sur la partition / , mais bon, j'aurais préféré GRUB ...
Il y a un MBR dans ce cas la ?
On peut installer grub ailleur que sur le mbr  ?
 
Autre question, lors de mon install, sur mon volume, j'ai crée deux partition primaire: swap et /
Si je veux créer d'aures partitions, qu'estce qui est recommander en général ?? / en primaire, et tout le reste en secondaire? tout en primaire ??
Je dois avouer que j'ai toujours galérer pour partitionner un disque, et j'ai toujours fait ca a l'arrache, mais la, je peux pas trop me le permettre ...

T'as le droit à 4 partitions primaires max par disque. Perso, j'ai déjà eu un problème de partitionnement avec des partitions secondaires donc je les évites tant que possible.
Après j'ai jamais fait de raid...
 
Sinon autre sujet : initramfs-tools pas powa !!! Depuis la sortie du 2.6.14, j'ai réussi une fois à booter un noyau compilé maison en ayant édité moi même le script mkinitramfs, sinon ca déconne toujours, même depuis la mise à jour il y a peu. La j'ai installé yaird qui fait le même boulot, et yaird, çay bien ça marche