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 ?

David Marec wrote on 13. Oct 2011 at 08:50:

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

La version Nvidia contrôle la version de FreeBSD (=8 ou 7). Le port surcharge ce contrôle.


Quote:

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.

C'est une suggestion de Robert Milan (Debian/kFreeBSD) pour avoir un truc user-friendly. Je pense que c'est une connerie mais bon... Tu peux faire un PR pour ça ou poster sur freebsd-usb@
Ça utilise devd pour charger les modules, faudrait regarder par là.


Quote:

La gravure ne fonctionne plus, «cdrecord» est out! et burncd aussi ...

Il y a un changement pour l'ata (CAM-ATA en 9.0) ce qui fait que ce n'est plus vu comme acd et c'est normal que burncd ne marche pas.

Pour cdrecord, j'ai vu passer des mails là dessus dans current@


Quote:

Et par chez vous ?

J'ai cassé ma soekris en la passant en 9.0/clang :)

Pour l'instant toujours en 8.2 sur mes desktops.

Salut patrick,



Quote:

C'est une suggestion de Robert Milan (Debian/kFreeBSD) pour avoir un truc user-friendly. Je pense que c'est une connerie mais bon... Tu peux faire un PR pour ça ou poster sur freebsd-usb@ Ça utilise devd pour charger les modules, faudrait regarder par là.

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:

Il y a un changement pour l'ata (CAM-ATA en 9.0) ce qui fait que ce n'est plus vu comme acd et c'est normal que burncd ne marche pas. Pour cdrecord, j'ai vu passer des mails là dessus dans current@

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
[/code]

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] Et par chez vous ?

J'ai cassé ma soekris en la passant en 9.0/clang :)

Pour l'instant toujours en 8.2 sur mes desktops.[/quote]
[/quote]

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

David Marec wrote on 13. Oct 2011 at 14:28:

Salut patrick, Bref, j'ai nettoyé les bibliothèques du mode et je suis reparti pour tout recompiler.

Enfin, non, le port misc/compat8x est là pour que tout retombe en marche assez vite.

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

[USB/HPLIP] hplip fonctionne avec un ulpt0 de chargé ...

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[/code]

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.

David Marec wrote on 13. Oct 2011 at 14:28:

Je ré-essaierai de graver plus tard.

Un petit retour pour indiquer que cdrecord fonctionne correctement.


Par contre, c'est une nouveauté:


Code (]
david:~ $ tty
/dev/ttyv4
david:~ $ echo $TERM
xterm
[/code):

Je crois que l'on peut tenter des trucs intéressants sous les terminaux virtuels avec ça. Par contre, mes scripts avec un [code] switch ($TERM)             case "xterm*":

...pour détecter si l'on était sous session X ou pas sont à revoir.
;)

Autre chose, une compilation en
[code]
make -j4[/code]
finit par geler le système, que ce soit avec CLANG ou GCC...

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

J'ai cassé ma soekris en la passant en 9.0/clang

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.

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

C'est une suggestion de Robert Milan (Debian/kFreeBSD) pour avoir un truc user-friendly. Je pense que c'est une connerie mais bon... Tu peux faire un PR pour ça ou poster sur freebsd-usb@ Ça utilise devd pour charger les modules, faudrait regarder par là.

Ouais, ben, comme tu l'as lu, c'est pas gagné.
Les seules réponses sont "utilisez devfs" et coller des droits pour tout le monde sur usb/*.
Pas terrible.

Apparemment, il y a d'autres exemples d'un devd devenu complètement inefficace.