j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tomb=E9 sur le
probl=E8me suivant :
au lancement, erreur =E0 cause d'une valeur r=E9cup=E9r=E9e par gconf :=20
la clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise
valeur. Du coup l'appli s'arr=EAte.
Cette erreur a l'air r=E9pandue (cf google), mais pas dans le cas de
figure pr=E9sent.
Apr=E8s farfouillage (et application des m=E9thodes inefficaces de toutes
les FAQ trouv=E9es), voil=E0 ce qui a march=E9 :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur
par d=E9faut de la clef en question (fichier install=E9 par emerge)
--> aller dans gconf-edit pour mettre cette valeur l=E0 =E0 la place de l=
a
valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les
valeurs deja existantes de clefs de gconf ne sont pas =E9cras=E9es en cas
d'upgrade.=20
Or ici ca pose un probl=E8me : il faudrait =E9craser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf.
Ce truc sera bient=F4t pire que la base de registre de win311 ...)
Je ne sais pas trop o=F9 adresser ce probl=E8me:
- est-ce un manque au niveau d'emerge ?
- un d=E9tail mal fichu dans l'ebuild ?
- un bug gnomemeeting (qui n'accepte pas ce qui faut) ?
- un probl=E8me de gconf ?
votre avis ?
(j'esp=E8re avoir =E9t=E9 =E0 peu pr=E8s clair, pas gagn=E9 vue l'heure e=
t ma
journ=E9e de m.... :-) )
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel Paquet
Mon cher Pascal
J'ai eu le même problème avec samba il y a quelques temps... Tu n'a qu'à supprimé le contenu de /usr/portage/distfiles/ ainsi que de /var/tmp/portage/ et refaire un sync de portage
Ce truc fonctionne avec n'importe quel bug de fingerprint, peu importe le paquetage
$ rm /usr/portage/distfiles/*.* (ne pas mettre -rf ici pour ne pas supprimé le dossier de cvs-src juste au cas) $ rm -rf /var/tmp/portage/* $ emerge sync $ emerge gnomemeeting
La manipulation consiste à vidé les fichiers téléchargé par portage (/usr/portage/distfiles/), ce qui remet à 0 les fingerprints et à vidé ces même fichier décompressé par portage (/var/tmp/portage/) lors de la compilation afin de ne pas corrompre l'installation du paquetage
Michel Paquet Québec, Canada
Pascal Ronecker a écrit :
Salut à tous,
j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tombé sur le problème suivant : au lancement, erreur à cause d'une valeur récupérée par gconf : la clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise valeur. Du coup l'appli s'arrête.
Cette erreur a l'air répandue (cf google), mais pas dans le cas de figure présent. Après farfouillage (et application des méthodes inefficaces de toutes les FAQ trouvées), voilà ce qui a marché :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur par défaut de la clef en question (fichier installé par emerge) --> aller dans gconf-edit pour mettre cette valeur là à la place de la valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les valeurs deja existantes de clefs de gconf ne sont pas écrasées en cas d'upgrade. Or ici ca pose un problème : il faudrait écraser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf. Ce truc sera bientôt pire que la base de registre de win311 ...)
Je ne sais pas trop où adresser ce problème: - est-ce un manque au niveau d'emerge ? - un détail mal fichu dans l'ebuild ? - un bug gnomemeeting (qui n'accepte pas ce qui faut) ? - un problème de gconf ?
votre avis ?
(j'espère avoir été à peu près clair, pas gagné vue l'heure et ma journée de m.... :-) )
-- mailing list
Mon cher Pascal
J'ai eu le même problème avec samba il y a quelques temps... Tu n'a qu'à
supprimé le contenu de /usr/portage/distfiles/ ainsi que de
/var/tmp/portage/ et refaire un sync de portage
Ce truc fonctionne avec n'importe quel bug de fingerprint, peu importe
le paquetage
$ rm /usr/portage/distfiles/*.* (ne pas mettre -rf ici pour ne pas
supprimé le dossier de cvs-src juste au cas)
$ rm -rf /var/tmp/portage/*
$ emerge sync
$ emerge gnomemeeting
La manipulation consiste à vidé les fichiers téléchargé par portage
(/usr/portage/distfiles/), ce qui remet à 0 les fingerprints et à vidé
ces même fichier décompressé par portage (/var/tmp/portage/) lors de la
compilation afin de ne pas corrompre l'installation du paquetage
Michel Paquet
Québec, Canada
Pascal Ronecker a écrit :
Salut à tous,
j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tombé sur le
problème suivant :
au lancement, erreur à cause d'une valeur récupérée par gconf :
la clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise
valeur. Du coup l'appli s'arrête.
Cette erreur a l'air répandue (cf google), mais pas dans le cas de
figure présent.
Après farfouillage (et application des méthodes inefficaces de toutes
les FAQ trouvées), voilà ce qui a marché :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur
par défaut de la clef en question (fichier installé par emerge)
--> aller dans gconf-edit pour mettre cette valeur là à la place de la
valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les
valeurs deja existantes de clefs de gconf ne sont pas écrasées en cas
d'upgrade.
Or ici ca pose un problème : il faudrait écraser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf.
Ce truc sera bientôt pire que la base de registre de win311 ...)
Je ne sais pas trop où adresser ce problème:
- est-ce un manque au niveau d'emerge ?
- un détail mal fichu dans l'ebuild ?
- un bug gnomemeeting (qui n'accepte pas ce qui faut) ?
- un problème de gconf ?
votre avis ?
(j'espère avoir été à peu près clair, pas gagné vue l'heure et ma
journée de m.... :-) )
J'ai eu le même problème avec samba il y a quelques temps... Tu n'a qu'à supprimé le contenu de /usr/portage/distfiles/ ainsi que de /var/tmp/portage/ et refaire un sync de portage
Ce truc fonctionne avec n'importe quel bug de fingerprint, peu importe le paquetage
$ rm /usr/portage/distfiles/*.* (ne pas mettre -rf ici pour ne pas supprimé le dossier de cvs-src juste au cas) $ rm -rf /var/tmp/portage/* $ emerge sync $ emerge gnomemeeting
La manipulation consiste à vidé les fichiers téléchargé par portage (/usr/portage/distfiles/), ce qui remet à 0 les fingerprints et à vidé ces même fichier décompressé par portage (/var/tmp/portage/) lors de la compilation afin de ne pas corrompre l'installation du paquetage
Michel Paquet Québec, Canada
Pascal Ronecker a écrit :
Salut à tous,
j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tombé sur le problème suivant : au lancement, erreur à cause d'une valeur récupérée par gconf : la clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise valeur. Du coup l'appli s'arrête.
Cette erreur a l'air répandue (cf google), mais pas dans le cas de figure présent. Après farfouillage (et application des méthodes inefficaces de toutes les FAQ trouvées), voilà ce qui a marché :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur par défaut de la clef en question (fichier installé par emerge) --> aller dans gconf-edit pour mettre cette valeur là à la place de la valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les valeurs deja existantes de clefs de gconf ne sont pas écrasées en cas d'upgrade. Or ici ca pose un problème : il faudrait écraser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf. Ce truc sera bientôt pire que la base de registre de win311 ...)
Je ne sais pas trop où adresser ce problème: - est-ce un manque au niveau d'emerge ? - un détail mal fichu dans l'ebuild ? - un bug gnomemeeting (qui n'accepte pas ce qui faut) ? - un problème de gconf ?
votre avis ?
(j'espère avoir été à peu près clair, pas gagné vue l'heure et ma journée de m.... :-) )
-- mailing list
Michel Paquet
Ouais ben... j'ai relue le mail que Pascal a envoyé. Après la relecture, j'ai conclue que j'étais dans le champ pas à peu près et que s'que j'ai écris n'a rien à voir avec son problème... Dsl de vous avoir induit en erreur.
Michel Paquet Québec, Canada
Michel Paquet a écrit :
Mon cher Pascal
J'ai eu le même problème avec samba il y a quelques temps... Tu n'a qu'à supprimé le contenu de /usr/portage/distfiles/ ainsi que de /var/tmp/portage/ et refaire un sync de portage
Ce truc fonctionne avec n'importe quel bug de fingerprint, peu importe le paquetage
$ rm /usr/portage/distfiles/*.* (ne pas mettre -rf ici pour ne pas supprimé le dossier de cvs-src juste au cas) $ rm -rf /var/tmp/portage/* $ emerge sync $ emerge gnomemeeting
La manipulation consiste à vidé les fichiers téléchargé par portage (/usr/portage/distfiles/), ce qui remet à 0 les fingerprints et à vidé ces même fichier décompressé par portage (/var/tmp/portage/) lors de la compilation afin de ne pas corrompre l'installation du paquetage
Michel Paquet Québec, Canada
Pascal Ronecker a écrit :
Salut à tous,
j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tombé sur le problème suivant : au lancement, erreur à cause d'une valeur récupérée par gconf : la clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise valeur. Du coup l'appli s'arrête.
Cette erreur a l'air répandue (cf google), mais pas dans le cas de figure présent. Après farfouillage (et application des méthodes inefficaces de toutes les FAQ trouvées), voilà ce qui a marché :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur par défaut de la clef en question (fichier installé par emerge) --> aller dans gconf-edit pour mettre cette valeur là à la place de la valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les valeurs deja existantes de clefs de gconf ne sont pas écrasées en cas d'upgrade. Or ici ca pose un problème : il faudrait écraser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf. Ce truc sera bientôt pire que la base de registre de win311 ...)
Je ne sais pas trop où adresser ce problème: - est-ce un manque au niveau d'emerge ? - un détail mal fichu dans l'ebuild ? - un bug gnomemeeting (qui n'accepte pas ce qui faut) ? - un problème de gconf ?
votre avis ?
(j'espère avoir été à peu près clair, pas gagné vue l'heure et ma journée de m.... :-) )
-- mailing list
-- mailing list
Ouais ben... j'ai relue le mail que Pascal a envoyé. Après la relecture,
j'ai conclue que j'étais dans le champ pas à peu près et que s'que j'ai
écris n'a rien à voir avec son problème... Dsl de vous avoir induit en
erreur.
Michel Paquet
Québec, Canada
Michel Paquet a écrit :
Mon cher Pascal
J'ai eu le même problème avec samba il y a quelques temps... Tu n'a
qu'à supprimé le contenu de /usr/portage/distfiles/ ainsi que de
/var/tmp/portage/ et refaire un sync de portage
Ce truc fonctionne avec n'importe quel bug de fingerprint, peu importe
le paquetage
$ rm /usr/portage/distfiles/*.* (ne pas mettre -rf ici pour ne pas
supprimé le dossier de cvs-src juste au cas)
$ rm -rf /var/tmp/portage/*
$ emerge sync
$ emerge gnomemeeting
La manipulation consiste à vidé les fichiers téléchargé par portage
(/usr/portage/distfiles/), ce qui remet à 0 les fingerprints et à vidé
ces même fichier décompressé par portage (/var/tmp/portage/) lors de
la compilation afin de ne pas corrompre l'installation du paquetage
Michel Paquet
Québec, Canada
Pascal Ronecker a écrit :
Salut à tous,
j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tombé sur le
problème suivant :
au lancement, erreur à cause d'une valeur récupérée par gconf : la
clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise
valeur. Du coup l'appli s'arrête.
Cette erreur a l'air répandue (cf google), mais pas dans le cas de
figure présent.
Après farfouillage (et application des méthodes inefficaces de toutes
les FAQ trouvées), voilà ce qui a marché :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur
par défaut de la clef en question (fichier installé par emerge)
--> aller dans gconf-edit pour mettre cette valeur là à la place de la
valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les
valeurs deja existantes de clefs de gconf ne sont pas écrasées en cas
d'upgrade. Or ici ca pose un problème : il faudrait écraser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf.
Ce truc sera bientôt pire que la base de registre de win311 ...)
Je ne sais pas trop où adresser ce problème:
- est-ce un manque au niveau d'emerge ?
- un détail mal fichu dans l'ebuild ?
- un bug gnomemeeting (qui n'accepte pas ce qui faut) ?
- un problème de gconf ?
votre avis ?
(j'espère avoir été à peu près clair, pas gagné vue l'heure et ma
journée de m.... :-) )
Ouais ben... j'ai relue le mail que Pascal a envoyé. Après la relecture, j'ai conclue que j'étais dans le champ pas à peu près et que s'que j'ai écris n'a rien à voir avec son problème... Dsl de vous avoir induit en erreur.
Michel Paquet Québec, Canada
Michel Paquet a écrit :
Mon cher Pascal
J'ai eu le même problème avec samba il y a quelques temps... Tu n'a qu'à supprimé le contenu de /usr/portage/distfiles/ ainsi que de /var/tmp/portage/ et refaire un sync de portage
Ce truc fonctionne avec n'importe quel bug de fingerprint, peu importe le paquetage
$ rm /usr/portage/distfiles/*.* (ne pas mettre -rf ici pour ne pas supprimé le dossier de cvs-src juste au cas) $ rm -rf /var/tmp/portage/* $ emerge sync $ emerge gnomemeeting
La manipulation consiste à vidé les fichiers téléchargé par portage (/usr/portage/distfiles/), ce qui remet à 0 les fingerprints et à vidé ces même fichier décompressé par portage (/var/tmp/portage/) lors de la compilation afin de ne pas corrompre l'installation du paquetage
Michel Paquet Québec, Canada
Pascal Ronecker a écrit :
Salut à tous,
j'ai fait un uprgade de gnomemeeting (v1.0.2), et je suis tombé sur le problème suivant : au lancement, erreur à cause d'une valeur récupérée par gconf : la clef apps/gnomemeeting/general/gconf_test_age renvoie une mauvaise valeur. Du coup l'appli s'arrête.
Cette erreur a l'air répandue (cf google), mais pas dans le cas de figure présent. Après farfouillage (et application des méthodes inefficaces de toutes les FAQ trouvées), voilà ce qui a marché :
--> aller lire dans /etc/gconf/schemas/gnomemeeting.schemas la valeur par défaut de la clef en question (fichier installé par emerge) --> aller dans gconf-edit pour mettre cette valeur là à la place de la valeur existante.
En gros si je comprends bien ce qui se passe en emergeant le truc : les valeurs deja existantes de clefs de gconf ne sont pas écrasées en cas d'upgrade. Or ici ca pose un problème : il faudrait écraser cette clef.
(au passage : emerge unmerge ne supprime rien dans les clefs de gconf. Ce truc sera bientôt pire que la base de registre de win311 ...)
Je ne sais pas trop où adresser ce problème: - est-ce un manque au niveau d'emerge ? - un détail mal fichu dans l'ebuild ? - un bug gnomemeeting (qui n'accepte pas ce qui faut) ? - un problème de gconf ?
votre avis ?
(j'espère avoir été à peu près clair, pas gagné vue l'heure et ma journée de m.... :-) )
