Soluce à partir des forums fedora :

En console et en root, lancer :
vim /etc/dbus-1/system.conf
Puis :
Remplacer
57,58
<allow send_requested_reply="true" send_type="method_return"/>
<allow send_requested_reply="true" send_type="error"/>
Par
<allow send_requested_reply="true"/>
Enlever :

66,67
<allow receive_requested_reply="true" receive_type="method_return"/>
<allow receive_requested_reply="true" receive_type="error"/>
Bonsoir

bizarre moi j'ai cela
[root@localhost ~]# yum update
Modules complémentaires chargés : refresh-packagekit
fedora                                                                                                        | 2.8 kB     00:00     
rpmfusion-free-updates                                                                                        | 2.7 kB     00:00     
rpmfusion-nonfree-updates                                                                                     | 2.7 kB     00:00     
rpmfusion-free                                                                                                | 2.7 kB     00:00     
adobe-linux-i386                                                                                              |  951 B     00:00     
rpmfusion-nonfree-source                                                                                      | 2.1 kB     00:00
fedora-source                                                                                                 | 2.2 kB     00:00
rpmfusion-nonfree                                                                                             | 2.7 kB     00:00
rpmfusion-free-source                                                                                         | 2.1 kB     00:00
updates                                                                                                       | 2.3 kB     00:00
updates/primary_db                                                                                            | 1.1 MB     00:08
Configuration du processus de mise à jour
Résolution des dépendances
--> Lancement de la transaction de test
---> Paquetage crontabs.noarch 0:1.10-25.fc10 marqué pour être mis à jour
---> Paquetage PackageKit-yum.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
---> Paquetage PackageKit-gstreamer-plugin.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
---> Paquetage PackageKit-udev-helper.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
---> Paquetage PackageKit-qt.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
--> Traitement de la dépendance : libpackagekit-qt.so.10()(64bit) pour le paquetage : kpackagekit
---> Paquetage pangomm.x86_64 0:2.14.1-1.fc10 marqué pour être mis à jour
---> Paquetage cjkunifonts-uming.noarch 0:0.2.20080216.1-10.fc10 marqué pour être mis à jour
---> Paquetage gnome-settings-daemon.x86_64 0:2.24.1-3.fc10 marqué pour être mis à jour
---> Paquetage PackageKit-yum-plugin.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
---> Paquetage PackageKit.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
---> Paquetage PackageKit-glib.x86_64 0:0.3.11-4.fc10 marqué pour être mis à jour
---> Paquetage transmission.x86_64 0:1.40-1.fc10 marqué pour être mis à jour
---> Paquetage gtkmm24.x86_64 0:2.14.3-1.fc10 marqué pour être mis à jour
--> Traitement de la dépendance : libpackagekit-glib.so.10()(64bit) pour le paquetage : gnome-packagekit
--> Résolution des dépendances terminée
kpackagekit-0.3.1-4.fc10.x86_64 de installed a des problèmes de dépendances
  --> Dépendance manquante : libpackagekit-qt.so.10()(64bit) est requis par le paquetage kpackagekit-0.3.1-4.fc10.x86_64 (installed)
gnome-packagekit-0.3.9-8.fc10.x86_64 de installed a des problèmes de dépendances
  --> Dépendance manquante : libpackagekit-glib.so.10()(64bit) est requis par le paquetage gnome-packagekit-0.3.9-8.fc10.x86_64 (installed)
Erreur : Dépendance manquante : libpackagekit-qt.so.10()(64bit) est requis par le paquetage kpackagekit-0.3.1-4.fc10.x86_64 (installed)
Erreur : Dépendance manquante : libpackagekit-glib.so.10()(64bit) est requis par le paquetage gnome-packagekit-0.3.9-8.fc10.x86_64 (installed)
[root@localhost ~]#
on est en train de repartir sur une RC :-?
Salut à tous!

JCS13, je suis confronté au même problème que toi!

Je précise que j'ai déjà effectué la mise à jour qui pose problème dans ce post, et que j'ai également réglé le problème de packagekit qui fonctionne très bien.

Néanmois, une soudaine mise à jour ce soir d'un petit nombre de paquets me mets en échec avec cette erreur liée à libpackagekit-glib.so, ça fait bien longtemps que je n'avais pas vu "une erreur de dépendance"...

bref je pense que ce paquet doit se trouver ailleurs, car le yum search correspondant ne me retourne aucun résultat.
Bonjour,
J'ai la même erreur en graphique et par le yum....
dans le même cas que florentf

merci d'avance
J'ai le même problème avec une fedora 10 32 bits

A la commande:
 su - -c 'yum update'
Réponse:
--> Résolution des dépendances terminée
gnome-packagekit-0.3.9-8.fc10.i386 de installed a des problèmes de dépendances
  --> Dépendance manquante : libpackagekit-glib.so.10 est requis par le paquetage gnome-packagekit-0.3.9-8.fc10.i386 (installed)
Erreur : Dépendance manquante : libpackagekit-glib.so.10 est requis par le paquetage gnome-packagekit-0.3.9-8.fc10.i386 (installed)
Et cela me bloque l'update.
http://rpm.pbone.net/ me trouve bien le paquetage manquant mais ce site est il fiable? Par habitude je n'installe que mes paquetages par yum depuis des dépôts référencés.



Nicolas C.
Heu...
66,67
<allow receive_requested_reply="true" receive_type="method_return"/>
<allow receive_requested_reply="true" receive_type="error"/>
Inutile de les enlever, elles sont dans un commentaire XML... par contre chez moi ça ne change rien...
Metal3d wrote:Heu...
66,67
<allow receive_requested_reply="true" receive_type="method_return"/>
<allow receive_requested_reply="true" receive_type="error"/>
Inutile de les enlever, elles sont dans un commentaire XML... par contre chez moi ça ne change rien...
Au temps pour moi, c'est certainement la mise à jour qui a mis en commentaire les lignes puisque je vois aussi l'autorisation apparaitre ligne 59... Donc la mise à jour n'a rien corrigé chez moi, peut-être relancer Gnome alors...
Bonjour,

Je débute sous Linux, et ce problème survient si comme moi vous avez mis à jour votre système Fedora 10 par mégarde en cliquant sur mettre à jour lorsque le système vous le demande. Après la lecture de quelques postes sur ce même forum, il semblerait qu'il faille attendre patiemment la prochaine mise à jour pour que le problème disparaisse, celui ci serait lié à un problème de dépendances, en attendant que certains packages expérimentaux soient validés et classés comme stable. En attendant, je ne peux plus installer ou désinstaller de logiciels à l'aide du gestionnaire prévu à cet effet. J'aimerai savoir si la méthode que vous citez ci-dessus est sans danger du point de vue de la sécurité de mon ordinateur.

Amicalement,

tinux
Je suis débutant, je vais te dire ce que je sais :

yum search motclé <----- chercher un paquet par rapport à sa description
yum list motclé <----- chercher un paquet par rapport à son nom (joker autorisé)
yum install paquet <------- explicite, non ? (jocker autorisé, il peut t'en installer plusieurs et gère les dépendances tout seul)
yum remove paquet <----- comme install, mais pour éffacer 😉

A noter qu'il faut être en root pour executer ces commandes.
Tu devras te fendre d'un "sudo".

Sinon, je ne peux que te recommander de lire cette doc : Tuto yum
Excellent, facile à prendre en main, merci !
Pb résolu. Merci à l'équipe de fedora pour sa réactivité. Pour ceux qui restent bloqués, taper dans un terminal su puis le mot de passe root, puis "yum clean all" et enfin "yum update". Mais je suppose qu'il y a une méthode plus fine ?
titub wrote:...
A noter qu'il faut être en root pour executer ces commandes.
Tu devras te fendre d'un "sudo".
...
Salut,

c'est plus un :
su -
(su Espace tiret)
Non, je pensais à sudo :
sudo yum install tibididzouit
Il te demandera ton pass (de l'utilisateurs actuel) et la commande sera éxecuter en root.

Il faut pour cela que l'utilisateur courant soit présent dans /etc/sudoers
Le fichier est documenter sous forme de commentaires.

Edit : je viens de lire ton nombre de post. D'en déduire ton ancienneté. Et d'exploser de rire en pensant au conseil que je viens de donner à un habitué. Mes excuses 🙂 Juste pour le coté comique de la situation, je ne vais pas supprimer mon post.
Non, c'est très bien, je croyais que la commande su voulait dire sudo :roll:
Par contre quand j'utilise su sans le tiret ça marche très bien.
Dans le man su, il est marqué que mettre le tiret revient à lancer un "login shell".
C'est quoi un login shell ? Si je mets pas le tiret, c'est grave docteur ?

tinux
titub wrote:Edit : je viens de lire ton nombre de post. D'en déduire ton ancienneté. Et d'exploser de rire en pensant au conseil que je viens de donner à un habitué. Mes excuses 🙂 Juste pour le coté comique de la situation, je ne vais pas supprimer mon post.
Non, tu n'as pas à t'excuser et le nombre de posts ne veut rien dire du tout.
Comme je suis de nature curieuse je peux t'assurer que si je devais relire tous mes posts j'en ressortirai beaucoup plus de questions que de solutions 😉

Et on en apprend tous les jours, de n'importe qui.

L'informatique contenant tellement de domaines divers et variés que personne ne peut ou oserait se vanter de tout savoir.
Chacun sait ce qu'il sait MAIS pas plus 🙂

L'important, surtout ici dans un forum de distribution Libre est de s'entraider, et c'est tout ce qui compte pour moi 😉

Il y a quelques jours j'ai lu un post de Pmarion qui disait en gros "C'est pas grave ça permet de réviser Gnome"...et voilà tout est dit !
On accumule des choses et de temps en temps il faut revoir les bases, ça permet de rester humble.

Moralité : le compteur ne nous rajeunit pas ...:hammer: et il prouve qu'on se pose des questions... 😉

PS : je n'utilise jamais sudo ! ah si de temps en temps mais ailleurs 🙂
la différence entre un login shell et un shell normal est que le démarrage d'un login shell provoque l'exécution des commandes contenues dans le fichier .bash_profile alors que le lancement d'un shell ordinaire provoque l'exécution des commandes contenues dans le fichier .bashrc. Habituellement l'une des commandes contenues dans .bash_profile provoque à son tour l'exécution des commandes contenues dans .bashrc. Par conséquent le tiret après su provoque l'exécution d'un certain nombre de commandes situées dans .bash_profile. A toi de voir le contenu de ce fichier.
nb. Les deux fichiers précités se trouvent dans le répertoire personnel de l'utilisateur. Après un su sans paramètre, ce répertoire est /root. Les fichiers dont le nom commence par un point ne sont pas affichés par ls. Pour les faire apparaître, donner à ls l'option -a
Did wrote:PS : je n'utilise jamais sudo ! ah si de temps en temps mais ailleurs 🙂
Parait qu'il faut au maximum éviter de bosser en root. Du coup, j'me dis que niveau sécurité (pour éviter les boulettes du aux fausses manip'), il est peut être plus intéressant d'utiliser sudo que su, mais si il est évident que c'est plus contraignant.

Mon point de vue est peut-être erroné, je ne demande qu'à me faire corriger (aucun sous entendu sexuel).
pour le fun...;; et les béotiens de mon genre ...🙂

un petit
yum install yumex

le mode graphique c'est bien aussi !
Une fois yumex (yum exterder) installé vous aurez dans le menu Applications/outils systèmes/ tout en bas l'item Yum Extender

une fois lancé, une belle interface graphique vous permettra les mises à jours et autres opérations installations/désinstallations etc...

donc dans une console faire
su -
mot de pass root
yum install yumex

et voila.:-D
Hier j'ai fait:

yum clean all
yum check-update
yum update
reboot

et ça a réglé le problème, je peux désormais mettre à jour et installer des logiciels via l'interface graphique sans recevoir le message d'erreur.