Après recherche, il semble que cela corresponde aux évenements liés à l'interface graphique X, que ce soit des mouvements de souris ou les entrées au clavier.
C'est ce que je comprends de ce lien http://linux.die.net/man/4/evdev

Je pense donc qu'il ne faut pas le désinstaller 😉

un petit yum update --skipbroken donne quoi ?
Oui maintenant que tu me le dis j'aurais pas du essayer de le désinstaller...
Ya un peu de chance dans ce malheur.

"yum update --skip-broken" me donne la même erreur.
Cf. premier post
Si tu regardes dans /var/log/yum.log, tu peux voir la dernière modification faite par rapport à ce paquet ?

Et essayer de forcer la réinstallation de ce paquet pour voir si ça répare quelque chose.
yum -v -t reinstall xorg-x11-drv-ev* --skip-broken
Installroot: /
Ext Commands:

   xorg-x11-drv-ev*
Configuration du processus de suppression
Lecture de la base de données RPM locale
rpmdb time: 0.000
Configuration du groupe de paquetages
pkgsack time: 0.267
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 241, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 116, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 311, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 270, in doCommand
    return base.erasePkgs(extcmds)
  File "/usr/share/yum-cli/cli.py", line 597, in erasePkgs
    self.remove(pattern=arg)
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 2436, in remove
    (e,m,u) = self.rpmdb.matchPackageNames([kwargs['pattern']])
  File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 210, in matchPackageNames
    matched.append(self.searchPkgTuple(pkgtup)[0])
IndexError: list index out of range
Je connais pas d'autre option pour forcer
Si tu arrives à trouver le RPM correspondant, une méthode un peu sale est de faire rpm -ivh --force lefichier.rpm

Pour une installation 32 bits
http://mirrors.ircam.fr/pub/fedora/linux/releases/9/Fedora/i386/os/Packages/xorg-x11-drv-evdev-1.99.1-0.5.fc9.i386.rpm

Sinon explore ça pour trouver
http://mirrors.ircam.fr/pub/fedora/linux/releases/9/Fedora

Après ça, je n'ai plus d'idées.

Mais en lisant le message d'erreur, ça me semble plus proche d'une erreur de configuration de yum
il essaye de lire trop loin dans un tableau alors qu'il tente d'accéder à l'élément 0, je pense donc que c'est qu'il ne trouve pas le tableau
SkyR713 wrote:Si tu arrives à trouver le RPM correspondant, une méthode un peu sale est de faire rpm -ivh --force lefichier.rpm
Mon dieu... -_-

Deux erreurs la dedans:
- c'est une mise à jour, l'option -U est donc a utiliser, pas -i
- l'option --force est à proscrire définitivement !
Mais en lisant le message d'erreur, ça me semble plus proche d'une erreur de configuration de yum
il essaye de lire trop loin dans un tableau alors qu'il tente d'accéder à l'élément 0, je pense donc que c'est qu'il ne trouve pas le tableau
Moi en lisant, je pense presque comme toi, mais rien a voir avec la conf. Le tableau semble correspondre à une liste de Tuples (de quoi ? :lol:), et il essaie d'en prendre l'élément 0. S'il se prend une erreur, c'est que l'élément 0 n'existe pas, par conséquent que le tableau est vide.
Greg08 wrote:rpm --rebuilddb
Cette option n'est utile que pour RPM il me semble, car yum utilise sa propre base de données pour les metadata des RPMs installés (je crois).

@Nano-1: essaie la méthode de Grégoire, mais j'ai peu d'espoir.

Ca sent le bug de yum, tu devrais le remonter: http://bugzilla.redhat.com !
Salut Nano-1

Pour ton problème de mise à jour, je voulais savoir, dans quel mode se trouve ton SELinux ? permissif ou enforcing ?

Je viens d'upgrader une FC7 vers une FC9....J'ai eu quelque bugs derrière ça (message d'alertes SEAlert à fond les watts !!)

J'étais en mode "permissif" et suis passé en mode "enforcing". A partir de là, dès que je fais un "yum update" j'ai le même message d'erreur que toi !!! Si je repasse en mode permissif, plus de problème pour l'update.

Si tu bascules ton mode SELinux en "permissiv", as tu encore des problèmes pour updater ???

Comme le dit Bochecha, je pense qu'il s'agit d'un joli bug de FC9 à remonter sur le site officiel de Fedora !!
davenight94 wrote:Salut Nano-1

Pour ton problème de mise à jour, je voulais savoir, dans quel mode se trouve ton SELinux ? permissif ou enforcing ?

Je viens d'upgrader une FC7 vers une FC9....J'ai eu quelque bugs derrière ça (message d'alertes SEAlert à fond les watts !!)

J'étais en mode "permissif" et suis passé en mode "enforcing". A partir de là, dès que je fais un "yum update" j'ai le même message d'erreur que toi !!! Si je repasse en mode permissif, plus de problème pour l'update.

Si tu bascules ton mode SELinux en "permissiv", as tu encore des problèmes pour updater ???

Comme le dit Bochecha, je pense qu'il s'agit d'un joli bug de FC9 à remonter sur le site officiel de Fedora !!
Non, si vos deux problèmes sont liés, cela vient du fait que vous avez fait une mise à jour pour passer d'une version de Fedora à une autre. Comme cette opération n'est ni conseillée ni même supportée, cela ne constitue plus un bug mais une erreur de manipulation de votre part.

@davenight94: regarde le dernier lien que je t'ai donné sur ton post et voit si cela règle ton problème s'il te plait, d'après les infos que tu as donné, ça me parait correspondre étrangement à ce que tu as.
Message perso à Bochecha :

Depuis que je suis passé en mode enforcing, si je veux faire un reboot j'ai le droit à un "permission denied" et quand je veux lancer SELinux management (mode graphique) j'ai une fenêtre qui me dit "erreur inconnue".

ça te parle ces erreurs ???? jpense comme toi, c'est un bon ptit bug de merde de FC9 !!!!

Solution pour rétablir l'incident (ça peut servir à d'autres) :

1) Rebooter en runlevel 1 ou rescue
Lors de l'affichage du lanceur grub, appuyer sur la touche "a" pour modifier les paramètres de démarrage puis en fin de ligne ajouter "1" ou
"rescue". Appuyer sur la touche "entrée". Linux se lance en mode 1 ou rescue.
2) Lorsque le prompt sh apparait, taper la commande suivante : "setsebool -P secure_mode_policyload=0" puis tapé la touche "entrée" et enfin
entrer la commande "reboot".

Il est franchement chiant ce bug !!!
@Nano-1: si ton problème semble bien lié a SELinux, comme le sous-entendait davenight94, regarde ce sujet: http://forums.fedora-fr.org/viewtopic.php?pid=282134#p282134

@davenight94: arrete de dire que c'est un bug ! Tu as fait une mauvaise manip qui est totalement déconseillée et tu as maintenant des problèmes (qu'au passage la communauté prend quand même le temps de résoudre). Ne parle pas de bug et montre du doigt le réel coupable: toi.
Ca a bougé ici !

Bon pour moi tous est résolut gràce à la méthode:

su -
yum clean all
yum makecache
rpm --rebuilddb
yum update

de greg08 alors merci à lui et à tous le monde

La communauté fedora est la meilleur !!!

Pour info, je n'active jamais SELinux si ca peu faire bouger le débàt
Nano-1 wrote:Ca a bougé ici !

Bon pour moi tous est résolut gràce à la méthode:

su -
yum clean all
yum makecache
rpm --rebuilddb
yum update

de greg08 alors merci à lui et à tous le monde
Tant mieux, mais moi je vois moyen pourquoi cette méthode aurait marché et pas un simple yum clean all (le makecache est forcément lancé à la première opération suivant un clean all)...
Pour info, je n'active jamais SELinux si ca peu faire bouger le débàt
Non, tu vas juste faire avancer le débat dans le sens "je désactive la sécurité et j'en suis très content"... Après, c'est toi qui voit.
Quel sécurité, j'en n'exige pas autant que toi c'est tout, merci les critiques.
Je suis informaticien alors à moins de faire chier le monde je vois pas pourquoi je brouillerais les cartes.
rpm --rebuilddb est la seule commande que je n'avais pas essayé 20fois et c'est elle qui me débloque voila !