Outils personnels
Vous êtes ici : Accueil Linux Gentoo Utilisation d'une Gentoo - Problèmes/Solutions - FAQ 30 - Mise à jour du 25 décembre 2012
Navigation
Se connecter


Mot de passe oublié ?
 

30 - Mise à jour du 25 décembre 2012

Par Freecrazy - Dernière modification 01/01/2013 18:31

Ben oui, on peut encore croire au Père Noël et espérer une mise à jour sans problème, la dernière ne date que du 2/10/2012.

Comme d'habitude je suis le déroulé tel qu'expliqué sur la page "Mettre à Jour une Gentoo"

Bien sûr, une nouvelle version de portage est à installer.

Et là, sans surprise nous avons quelques erreurs et donc quelques commandes complémentaires à effectuer. Mais avant il y a une news qu'il peut être utile de lire.

1 - La news "2012-11-06-PYTHON_TARGETS-deployment"

Malgré l'inquiétude que me laissait entrevoir le titre (toute la gestion des ebuilds est sous Python !) ce n'est pas si terrible que cela pour ceux qui ont leur système à jour.

En effet la cible Python ne se fait plus dorénavant par la commande 'eselect python' mais par l'utilisation de l'USE PYTHON_TARGETS. Et pour ceux qui n'ont que les récentes versions de Python, à savoir Python 2.7 & 3.2 installed, il n'y a rien à faire ;-)

Pour les autres ou pour les curieux allez voir le user guide -en anglais !)

2 - Des changements d'USE

Le premier warning concerne des changements d'USE :

The following USE changes are necessary to proceed:
#required by x11-drivers/xf86-video-vmware-12.0.2-r1, required by x11-base/xorg-drivers-1.13[video_cards_vmware],\
 required by x11-base/xorg-server-1.13.0-r1[xorg], required by x11-drivers/xf86-video-glint-1.2.8
>=x11-libs/libdrm-2.4.40 libkms
#required by net-analyzer/etherape-0.9.12, required by @selected, required by @world (argument)
>=gnome-base/libgnomecanvas-2.30.3 glade
#required by gnome-base/gvfs-1.12.3[udev], required by @selected, required by @world (argument)
=virtual/udev-171 gudev
#required by x11-drivers/xf86-video-vmware-12.0.2-r1, required by x11-base/xorg-drivers-1.13[video_cards_vmware],\
 required by x11-base/xorg-server-1.13.0-r1[xorg], required by x11-drivers/xf86-video-glint-1.2.8
=media-libs/mesa-9.0 xa
#required by virtual/udev-171, required by app-admin/system-config-printer-common-1.3.11-r1,\
 required by app-admin/system-config-printer-gnome-1.3.11, required by @selected, required by @world (argument)
=sys-fs/udev-171-r9 gudev

La commande à appliquer est maintenant connue puisque nous l'avons exécutée la dernière fois (cf. "29 - Une mise à jour importante sans soucis ? (02/10/2012)"). Méthode qui est dorénavant inscrite sur la page "Mettre à Jour une Gentoo".

En résumé :

# emerge -uD world --autounmask-write
# dispatch-conf

3 - Des paquets masqués

 Mais il me reste toujours des paquets masqués comme l'indique le message :

!!! The following installed packages are masked:
- net-wireless/madwifi-ng-0.9.4.4165.20110816::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Rick Farina <zerochaos@gentoo.org> (21 Dec 2012)
# madwifi has been replaced by ath5k and ath9k in kernel
# drivers and is subject to numerous long standing bugs

- net-wireless/madwifi-ng-tools-0.9.4.4165.20110816::gentoo (masked by: package.mask)

Nous avions déjà rencontrés des difficultés avec ces paquets lors de la dernière mise à jour d'octobre (la version installée étant la 4165 et nouvelle version étant la 4180.20120502). Cette fois ils ne sont pas en conflit, mais ils sont masqués comme quoi les problèmes ne sont toujours pas réglés.

Je n'ai pas le temps de creuser. Le peu que j'ai lu (cf. ce lien par exemple) et compris : madwifi utilise l'ancien driver ath_pci, remplacé depuis par ath5 et le plus récent ath9, mais à priori ces 2 derniers drivers ne fonctionnent pas avec tous les matériels (chipset Atheros donc)

Comme cela fonctionne bien pour moi (et pour cause j'ai changé mon ancienne carte WiFi à base de chipset Atheros depuis quelques temps déjà), j'applique pour l'instant la même échappatoire qu'en octobre, à savoir :

# emerge -uD world --exclude madwifi-ng madwifi-ng-tools

 Et nous sommes partis pour 146 compilations.

Hé bien non, le Père Noël ne m'a pas fait de cadeau, puisque j'ai une compilation qui a planté.

4 - ERROR: x11-drivers/xf86-video-mach64-6.9.3 failed (compile phase)

Voici le message d'erreur que l'on peut retrouver sous /var/log/portage/elog/summary.log :

>>> Messages generated by process 19886 on 2012-12-26 07:22:50 CET for package x11-drivers/xf86-video-mach64-6.9.3:

ERROR: compile
ERROR: x11-drivers/xf86-video-mach64-6.9.3 failed (compile phase):
  emake failed

Est-ce que l'on en sait plus en regardant /var/tmp/portage/x11-drivers/xf86-video-mach64-6.9.3/temp/build.log dont voici l'extrait final (avant le message inscrit dans le summary.log.

/var/tmp/portage/x11-drivers/xf86-video-mach64-6.9.3/work/xf86-video-mach64-6.9.3/src/atiscreen.c:111:1:\
 warning: 'ATIMinBits' defined but not used
make[2]: *** [atiscreen.lo] Erreur 1
make[2]: *** Attente des tâches non terminées....
make[2] : on quitte le répertoire\
 « /var/tmp/portage/x11-drivers/xf86-video-mach64-6.9.3/work/xf86-video-mach64-6.9.3_build/src »
make[1]: *** [all-recursive] Erreur 1
make[1] : on quitte le répertoire\
 « /var/tmp/portage/x11-drivers/xf86-video-mach64-6.9.3/work/xf86-video-mach64-6.9.3_build »
make: *** [all] Erreur 2

Pas très parlant n'est-ce pas ?

Pourtant le [atiscreen.lo] rappelle quelque chose, car ce n'est pas la première fois que l'on rencontre des problèmes avec des drivers et leurs fichiers en '.lo'.

D'ailleurs en parcourant le summary.log on trouve ceci :

>>> Messages generated by process 19886 on 2012-12-26 07:12:12 CET for package x11-base/xorg-server-1.13.0-r1:

WARN: postinst
You must rebuild all drivers if upgrading from <xorg-server-1.13
because the ABI changed. If you cannot start X because
of module version mismatch errors, this is your problem.
You can generate a list of all installed packages in the x11-drivers
category using this command:
    emerge portage-utils; qlist -I -C x11-drivers/
or using sets from portage-2.2:
    emerge @x11-module-rebuild
virtual/udev was built without keymap support. This may cause input device
autoconfiguration to fail.

Sur la page Mettre à Jour une Gentoo je titrais "4 - Un grand classique les problèmes liés à Xorg : pas d'interface graphique, pas de clavier, pas de souris". A priori c'est de nouveau le cas ici, nous allons devoir re compiler tous nos drivers.

Mais avant, les messages suivants du summary.log attirent l’œil :

>>> Messages generated by process 19886 on 2012-12-26 07:18:28 CET for package x11-drivers/xf86-video-openchrome-0.3.1:

QA: install
QA Notice: Unrecognized configure options:

    configure: WARNING: unrecognized options: --enable-dri
    configure: WARNING: unrecognized options: --enable-dri
QA Notice: Unrecognized configure options:

    configure: WARNING: unrecognized options: --enable-dri
    configure: WARNING: unrecognized options: --enable-dri
LOG: postinst
Supported chipsets:
CLE266 (VT3122), KM400/P4M800 (VT3205), K8M800 (VT3204),
PM800/PM880/CN400 (VT3259), VM800/CN700/P4M800Pro (VT3314),
CX700 (VT3324), P4M890 (VT3327), K8M890 (VT3336),
P4M900/VN896 (VT3364), VX800 (VT3353), VX855 (VT3409), VX900

The driver name is 'openchrome', and this is what you need
to use in your xorg.conf (and not 'via').

See the ChangeLog and release notes for more information.

>>> Messages generated by process 19886 on 2012-12-26 07:20:44 CET for package x11-drivers/xf86-video-savage-2.3.6:

LOG: postinst
Your X server no longer supports XAA, so xf86-video-savage will fall back
to shadowFB. Enable EXA in your X.org configuration to still have some 2D
acceleration. See "man 4 savage" for details.

Il vaut mieux suivre sagement ce qui est indiqué, et modifier /etc/xorg.conf comme indiqué. Pour ma part, je n'utilise par le driver 'via' je n'ai donc pas besoin de le remplacer par 'openchrome', de même pour 'XAA' qui ne figure pas dans mon xorg.conf.evdev (sur ma vieille machine il est illusoire d'avoir des effets graphiques).

Donc il ne me reste que la mise à jour des drivers avec la commande :

# emerge portage-utils; qlist -I -C x11-drivers/

Mais une relance de ma commande '# emerge -uD world --exclude madwifi-ng madwifi-ng-tools' continue de me sortir la même erreur.

Une recherche sur Internet m'indique qu'il s'agit d'un bug qui est corrigé dans la version xf86-video-mach64-6.9.4 (Cf. bug 443952 sur bugs.gentoo.org). Pour prendre en compte cette nouvelle version il me faut l'inscrire dans '/etc/portage/package.keywords' en y ajoutant cette ligne :

=x11-drivers/xf86-video-mach64-6.9.4 ~x86

Je suis en cela ce qui est indiqué sur cette page de Gentoo sur les mélanges de branches expliquées au paragraphe 3.b. Mais c'est aussi ce que m'indiquait en retour la commande de test suivante 'emerge -pqv =x11-drivers/xf86-video-mach64-6.9.4'.

Allez on relance :

# emerge -uD world --exclude madwifi-ng madwifi-ng-tools

qui, après 48 compilations de paquets, finit cette fois sans erreur. Nous pouvons poursuivre avec 'emerge --depclean' , 'revdep-rebuild' et 'dispatch-conf' .  

Cette dernière commande n'impacte que 2 fichiers :

  • /etc/conf.d/hwclock où mon précédent  'TIMEZONE="Europe/Paris"' disparaît au profit d'un clock="UTC"
  • /etc/conf.d/keymaps où je n'ai pas vu de changement !?


Et voilà tout est OK !

Actions sur le document