Salut la foule,

Voici un petit bilan de ma migration de la branche 8 à la branche9.

la mise à jour a été effectuée de manière transparente, en changeant seulement l' étiquette dans mon «standard.cvsup», suivi des «make buildworld && make kernel» et «mergemaster -p && make installworld && mergemaster -U» bien connus.

Seule quelques ports (tous des modules) ont du être recompilés. Bref, ça môrche pas mal.


Pas de problème majeurs au redémarrage, tout fonctionnait jusqu'à la session X.

• J'ai du (ré)installer le pilote NVIDIA à partir des ports.J'utilise habituellement directement ceux du forum
  nvidia.
• je n'ai pas vu de grandes nouveauté dans le noyau.
• j'ai commencé à faire mumuse avec le pilote «teken» pour la console, ( à compiler et tester dans «/sys/teken/» sans aller plus loin.

Réinstallation des quelques modules, issus des ports.

Et voici les quelques problèmes non résolus:

• Le pilote ulpt se charge automatiquement, même retiré du noyau.Ce qui fait que je ne peux plus imprimer directement via ugen. J'ai retiré ulpt de «/boot/modules» et lancé le script qui va gérer les droits de l'imprimante sur ugen à la main, ça ne fonctionne même plus au démarrage.
  un répertoire usb est apparu dans /etc/, qui aurait un lien qui explique ce nouveau fonctionnement ?
• Recompilation via CLANG, ça fonctionne sauf si j'utilise les commutateurs «-j»
• La gravure ne fonctionne plus, «cdrecord» est out! et burncd aussi ...
  Si quelqu'un utilise encore burncd...

Et par chez vous ?

Salut patrick,


Quote:


Je m'en étais douté, vu la structure de ce qui se trouve maintenant  dans /etc/devd.

Font chier là, avec leur «user friendy».  Tant que ça ne touchais que Xorg avec HAL, on pouvait se contenter de hausser les épaules.

Mais là.



Quote:


C'est la même erreur pour les deux.
Ceci dit, 'faut déjà être sacrément chanceux pour trouver que burncd «marche».

En fait, j'ai oublié d'effacer les anciennes lib.
Code:

 make delete-old
 make delete-old-libs
 

C'est pour ça que tous les ports fonctionnent sans avoir été reconstruits ...

Du coup, cdrecord et autres utilisaient une ancienne version de cam. Mais pas le noyau...

Bref, j'ai nettoyé les bibliothèques du mode et je suis reparti pour tout recompiler.
En fait, j'ai d'abord reconstruit sudo et Xterm...pour pouvoir continuer à glander devant ma machine.

Je ré-essaierai de graver plus tard.


Quote:

[/quote]

C'est mieux, si cette histoire d'Usb qui se charge sans rien demander continue.

patrick wrote on 13. Oct 2011 at 13:22:


Je n'ai pas terminé, mais en effet, hplip fonctionne désormais si ulpt est chargé...

J'ai encore quelques soucis pour le faire automatiquement;
[j'essaie de parametrer devfs.rules pour attribuer les bon droits d'utilisateurs;

En gros, il faut que tout ce qui se trouve sous
/deb/usb/* soit accessible en écriture par le groupe operator.

Pour l'instant, seuls les liens ugen  se sont correctement positionné en 660, je ne comprend pas encore pourquoi leurs cibles n'en ont pas fait autant.

Code:

add path 'ugen*' mode 0660 group operator 

ugen[x.y] sont des liens  sur /dev/usb/[x.y]

Curieux, /dev/usb et ugen ont bien changé de groupe, mais seul ugen a modifié ses droits d'écriture.

patrick wrote on 13. Oct 2011 at 13:22:


On a trouvé le soucis, c'est parce que llvm génère du code invalide pour les pentium (i586).

http://llvm.org/bugs/show_bug.cgi?id=11212

http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028588.html

Plus qu'à attendre le patch kivabien.