Problème d'install FEDORA tout Core toutes versions

moi · 2007-02-01 10:32:08

Je reformule différemment ma question précédente...

J’installe GLPI version 0.68.1 ou 0.68.3 (même problème avec les deux versions) sur une FEDORA core 4 ou core 6 (même problème aussi avec les deux versions du système).

Dans tous les cas de figure, les données ne sont pas correctement encodées dans la base de données…

Sachant que je n’utilise que des installations les plus standards et simples possible, par exemple : la version de mysql est celle fournis par FEDORA. Je sais que pour les puristes ce n’est pas bien, mais j’ai 150 PC une dizaine de serveurs à gérer, je n’ai pas trop le temps de faire dans la finesse…

Sachant également que j’utilise dans les mêmes conditions d’autres applications comme GRR, DotProject, PHPNuke, Etc… Sans les mêmes problèmes

Alors, même si je suis persuadé que ce n’est pas un problème GLPI, je souhaiterais juste connaître les pré-requis nécessaire au bon fonctionnement de GLPI. Tout au moins en ce qui concerne la base de données.

Par exemple est ce que le rpm mysql fournis par fedora est approprié ou non. Si non comment doit-on compiler spécifiquement mysql pour faire fonctionner GLPI.

Il y a-t-il d’autres utilisateurs de GLPI sur FEDORA ? Si oui pouvez vous me dire quelle version de mysql utilisez vous ? Comment avez-vous compilé mysql ?

Si FEDORA n’est pas du tout approprié pour GLPI, quelqu’un peut-il me conseiller à propos d’une autre distrib ?

Sous windows/LAMP est-ce que ça fonctionne mieux ?

En gros et pour résumer : LINUX ou WINDOWS, FEDORA ou PAS et si oui comment ?

Voilà, merci à tous, par avance de votre aide.

MoYo · 2007-02-01 10:45:23

Vous trouverez toutes les infos par ici : http://glpi-project.org/wiki/doku.php?i … auxdistrib

moi · 2007-02-01 11:22:27

Merci pour l'info, pour être plus prècis j'ai déjà été voir là : http://glpi-project.org/wiki/doku.php?i … pifedora6. et là http://glpi-project.org/wiki/doku.php?id=fr:glpifedora4 puisque j'ai les deux versions.

Dans ces deux pages, il n'est pas fait mention de configurations particulières concernant l'encodage.
De plus, L'installation de mysql est très basic 'yum' : donc paquetages fournis par la distrib. c'est très exactement ce que je fais toujours, histoire de simplifier, même si pour les puristes linuxiens c'est très mal...

Donc en résumé cette manière de faire ne fonctionne pas, en tout cas pour Fedora.

Je ne suis tout de même pas le seul à avoir ce problème, ou alors tout le monde à fait du spécifique au niveau de la config de mysql concernant l'encodage.

Le problème peut-il venir du fait que j'ai installé Fedora en français et pas en anglais ? Je sais que les puristes préconise l'install de linux en anglais exclusivement.

Quelqu'un d'autre que moi utilise-t-il Fedora ? et dans ce cas un peu de feedback serait vraiment bien venu

Je précise que c'est un vrais problème, par exemple : faisant partie d'un grand groupe industriel internationnal, on me demande très régulièrement des états détaillés de nos immobilisations, états qui n'existe, forcement pas dans GLPI. Je dois donc impérativement pouvoir faire des extractions de ma base de données sous Excel ou pdf ou n'importe quoi d'autre, sauf qu'il faut que se soit humainement lisible.

GLPI n'est pas encore en prod chez nous, toujours en phase de test, et jusqu'à maintenant tout les indicateurs étaient plutôt encourageants, mais là, ce problème est vraiment bloquant.

Merci par avance

MoYo · 2007-02-01 11:51:05

et vous faites vos extraction avec ?
les données dans la DB sont en UTF8.

moi · 2007-02-01 12:46:53

Pour commencer, MERCI de bien vouloir m'aider

Je fais les extractions avec le client Mysql développé par Mysql sous windows (graphique) ou Linux (ligne de commande) ou par PHPmyadmin.

Si je suis très exactement les 2 procédures du Wiki concernant fedora 4 et 6, les bases ne sont pas créé en UTF8 mais en 'latin1_swedish_ci'. C'est l'encodage par défaut du serveur Mysql sous fedora lorsque l'on install le rpm par yum depuis le dépot officiel de fedora. Et je confirme que lorsque j'installe GLPI la base est créée en 'latin1_swedish_ci'.

Ceci dit j’ai tenté cela :

Je repart de zéro :

Je supprime complètement la base GLPI.

Je modifie le fichier /etc/my.cnf pour y rajouter ces lignes :

[mysqld]
default-character-set=utf8
init-connect=SET NAMES utf8

et

[client]
default-character-set=utf8

Je redémarre mysqld (of course !)
Ce qui donne maintenant dans les variable de mysqld :

character set client  utf8  utf8  
character set connection  utf8  utf8  
character set database  utf8  utf8  
character set results  utf8  utf8  
character set server  utf8  utf8  
character set system  utf8  utf8  
character sets dir  /usr/share/mysql/charsets/  /usr/share/mysql/charsets/  
collation connection  utf8_general_ci  utf8_general_ci  
collation database  utf8_general_ci  utf8_general_ci  
collation server  utf8_general_ci  utf8_general_ci

Je refais une nouvelle base GLPI vide en m'assurant que c'est bien en UTF8...

Je réinstalle la version 0.68.3, l'install me reconstruit les tables, je m'assure que tout est en UTF8

   Champ  Type Interclassement Attributs Null Défaut Extra Action 
   ID  int(11)     Non    auto_increment              
   name  varchar(200) utf8_general_ci   Oui  NULL                
   date_mod  datetime     Non  0000-00-00 00:00:00                
   contact  varchar(200) utf8_general_ci   Oui  NULL                
   contact_num  varchar(200) utf8_general_ci   Oui  NULL                
   tech_num  int(11)     Non  0                
   comments  text utf8_general_ci   Oui  NULL                
   serial  varchar(200) utf8_general_ci   Oui  NULL                
   otherserial  varchar(200) utf8_general_ci   Oui  NULL                
   location  int(11)     Non  0                
   type  int(11)     Non  0                
   model  int(11)     Oui  NULL                
   brand  varchar(200) utf8_general_ci   Oui  NULL                
   FK_glpi_enterprise  int(11)     Non  0                
   is_global  enum('0', '1') utf8_general_ci   Non  0                
   deleted  enum('Y', 'N') utf8_general_ci   Non  N                
   is_template  enum('0', '1') utf8_general_ci   Non  0                
   tplname  varchar(255) utf8_general_ci   Oui  NULL                
   notes  longtext utf8_general_ci   Oui  NULL                
   FK_users  int(11)     Oui  NULL                
   FK_groups  int(11)     Oui  NULL                
 Tout cocher  /  Tout décocher     Pour la sélection :

Donc là normalement je suis en droit d'avoir quelques espoirs non ?

Ben non ... :
Première connection, avant même de toucher à quoi que se soit je saisie un périphérique :
Dans nom je rentre : 'périphérique à partir d'un modèle' et si je fais une requête dans phpmyadmin ou dans le client mysql de linux (en local) ou le client sous windows j'ai toujours ça : ''pÃ©riphÃ©rique Ã partir d'un modÃ¨le''. Alors que dans l'interface j'ai 'périphérique à partir d'un modèle' :

[root@orion ~]# mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 41 to server version: 4.1.20

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use glpi
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select name from glpi_peripherals;
+-----------------------------------------------+
| name                                          |
+-----------------------------------------------+
|                                               |
| pÃÂ©riphÃÂ©rique ÃÂ  partir d'un modÃÂ¨le         |
+-----------------------------------------------+
2 rows in set (0.00 sec)

mysql>

Je ne comprend pas, il n'y a rien de spécial dans mon serveur, tout est installé le plus basiquement possible, uniquement yum avec les repos officiels de Fedora.
je ne fais pas de configurations système compliquées que du basique (adresse IP fixe, authentification winbind, samba http mysql simplement lancés sans config)...

MoYo · 2007-02-01 13:27:10

les données sont stockées en UTF8 que le moteur soit en latin1 ou UTF8 ne change rien.
Cela fonctionne tres bien en latin1.

Ne touchr pas à votre install mysql ni a la DB glpi et cela devrait fonctionner.

l'affichage pÃ©riphÃ©rique Ã partir d'un modÃ¨le est normal c'est la donnée brute.
Pour la voir correctement il faut que l'outil de visu soit compatible UTF8.
GLPI définit en dur le charset utilisé par le navigateur mais d'autres applis quelles soient PHP ou non ne le font pas forcement;

moi · 2007-02-01 14:21:03

Merci pour ta réactivité.

En refaisant beaucoup d'autre tests, j'en conclu que comme tu le dit : le format de la base données n'a rien avoir avec mon problème.

En fait c'est bien un problème de client linux ou windows...
la seule façon de faire une requête est éffectivement de préciser au client quel encodage il doit utiliser.

Le problème maintenant :

Après moult tests il n'y a qu'avec un terminal (sous linux) ou une session SSH avec PUTTY/Windows qui me premettent de relire 'normalement' mes données. Les navigateurs HTTP se foutant royalement que je leur précise UTF-8 ....!

Quelqu'un connaitrait-il un client sous windows qui permet de faire une requête SQL en paramètrant cette requête en UTF-8. Car c'est impossible avec celui de Mysql (Mysql query browser) que ce soit sous linux ou windows.

Sinon cela veut dire que je ne pourras jamais exploiter les données de GLPI hors de GLPI.

HELP ..!

MoYo · 2007-02-01 15:26:49

je crois que la conf de phpmyadmin permet de forcer l'encodage utilisé.

moi · 2007-02-01 18:21:08

Effectivement, par defaut c'est en Fraçais-french-(utf-8), ainsi que Interclassement pour la connexion MySQL qui est en utf8_general_ci.

mon navigateur est bien en utf8 aussi, que ce soit IE7 ou Firefox

Mais ça ne fonctionne pas

Concernant le Query Browser de Mysql, par défaut il est sencé discuter en UTF8 (vu sur le site Mysql), mais là encore cà ne fonctionne toujours pas !

Sinon J'ai trouvé des règlages à faire au niveau du driver ODBC fournis par Mysql :
En effet j'ai un autre browser/query sql : SQL-View.
Il faudrait mettre SET NAMES latin1, utf8 ou autre chose... dans l'onglet 'Connect Options' Champ 'Initial Statement' des paramètres du driver. (Vu dans le forum de Mysql...)

Mais ça ne fonctionne toujours pas :

La valeur du champ dans GLPI est : ' Brevet France N°93/0 '

Dans PHPmyadmin je vois : 'Brevet France NÂ°93/0'

Avec le Driver ODBC de Mysql et SQL-View :
Si je met le Statement à utf8, j'ai cela : 'Brevet France NÃ‚Â°93/0' --> on dirait que c'est un double encodage
Si je met à latin1 : 'Brevet France NÂ°93/0' --> c'est comme PHPmyadmin
Si je met cp1251 : 'Brevet France N?°93/0' --> Et là c'est nimp !

Dans le Mysql query browser qui est censé parler naturellement en utf8 j'ai : 'Brevet France NÂ°93/0' -> comme si c'était du Latin1 (voir + haut)

Pour reprendre un peu l'historique :
J'ai un serveur qui est configuré comme cela par défaut :

character set client utf8 
(Valeur globale) latin1 
character set connection latin1 
character set database latin1 
character set filesystem binary 
character set results utf8 
(Valeur globale) latin1 
character set server latin1 
character set system utf8 
character sets dir /usr/share/mysql/charsets/ 
collation connection latin1_general_ci 
(Valeur globale) latin1_swedish_ci 
collation database latin1_swedish_ci 
collation server latin1_swedish_ci 
completion type

Ma base de données, est en 'latin1_swedish_ci' on peut le voir au niveau de toutes les tables ainsi que de certains champs tel que 'NAME' dans la table 'glpi_peripherals'...

Mes client : je ne sait pas exactement dans quelles langues ils parlent réellement, mais si on prend l'exemple des navigateurs HTTP, ou l'option encodage UTF8 est bien cochée, on peut supposer qu'ils parlent en UTF8.

Donc là je n'ai plus trop d'idées...
Suis-je le seul sur cette planete a avoir eu l'idée saugrenue de lire les données de GLPI ailleur que dans GLPI ???

En tout cas j'en pert mon Latin ...

moi · 2007-02-12 12:24:25

Pas de réponse ???

En fait j’ai retravaillé sur le sujet est j’ai découvert ceci :

J’ai travaillé sur le fichier /etc/my.cnf :

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
max_allowed_packet=16M
default-character-set=utf8
#default-character-set=latin1

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
#default-character-set=utf8
default-character-set=latin1

J’ai modifié alternativement les options ‘default-character-set’ des sections [mysqld] et [client]. (Voir les 2 dernières lignes des 2 sections ci-dessus)

La seul façon de lire correctement les données de GLPI depuis le client text (ligne de commande) sous Linux (sur le serveur lui même) est de mettre l’option ‘default-character-set=’ en latin1 dans la section [client] ou alors de ne rien préciser. Par contre je peux mettre ce que je veux dans la section [mysqld] ça ne change rien aux réponses de mysql à mes requêtes.

Cela veut-il dire que les données sont codées en latin1, malgré ce que pensent les développeurs de GLPI ?

Si c’est le cas cela ne me dérange pas, par contre dans ce cas, quelqu’un pourrait-il me dire comment préciser au client ‘query browser’ de mysql qu’il doit communiquer en latin1 avec mon serveur ? que ce soit sur le poste windows ou le serveur linux, je n’arrive pas à dire à ‘query browser’ de dialoguer en latin1.

MoYo · 2007-02-12 12:43:03

les developpeurs de GLPI ne pensent pas...

moi · 2007-02-12 14:20:18

Je ne sais quoi répondre...

en gros il faut 15 minutes de travail pour reproduire ce que je viens de dire plus haut...
J'avais comme vague espoir que quelqu'un, et éventuellement un développeur reproduise cette petite expérience, pour me dire si il avait les mêmes résultats, ou non et dans le cas contraire, m'aider à paramétrer mysql pour que ça fonctionne...

Pour info : Je suis allé sur le forum de Mysql où j'ai posé les mêmes questions. Et personne ne comprend, d'autant que je n'est pas ces problèmes d'encodage avec mes autres applications ...

Autre info : j'ai tout fait pareil sur un serveur Windows et c'est le même résultat : les caractères accentués ne sont lisible que dans l'interfdace de GLPI ou en précisant au client mysql latin1...

Maintenant et pour finir je suis désolé si je dérange, sinon fo juste me demander de partir gentillement :-)

JMD · 2007-02-12 14:25:59

Vous dérangez pas, simplement on est débordé, fatigué, la version 0.7 prends du retard et on a un travail à coté du projet GLPI...

Donc on ne dit pas que votre pb n'est pas intéressant mais on a pas eu le temps de s'y pencher et ça ne figure pas parmis nos taches ayant la mention "urgent".

Nous en sommes désolés.

moi · 2007-02-12 15:23:21

J'avais bien compris que vous n'attendiez pas sur moi pour avoir du travail et j'en suis heureux pour vous.

Et croyez moi je suis sincérement désolé d'avoir pu vous laisser croire le contraire.

Je précise donc que dans ce forum, d'autres personnes que les développeurs peuvent me répondre s'il le souhaite (par exemple suis je seul à vouloir lire les données de GLPI ailleur que dans GLPI, sinon comment font-ils...).

Et il ne s'agit pas de Fedora, je re-précise que c'est tout pareil sous windows :
Pour l'exemple : je viens d'installer sous VISTA (j'avais que ça sous la main), EASYPHP 1.8, Le query browser de mysql et GLPI 0.68.3 en moins d'une demi heure (Aucune config, pas de réseau... Bref tout brut de scan ..!) : résultat identique.

JMD · 2007-02-12 20:56:36

Pas de soucis de mon coté, j'avais bien compris vos intentions

En ce qui concerne les retours, peut-être faudrait-il modifier le titre de votre sujet (qui laisse à penser que cela ne concerne que l'installation d'une Fédora) pour avoir des retours d'autres utilisateurs.

chacawaca · 2007-02-12 23:36:08

j'ai pris le temps de faire le test avec le package de xampp et effectivement je n'arrive pas a lire les données de la bd correctement avec phpmyadmin, si je trouve la solution je vous fais signe.

chacawaca · 2007-02-13 00:06:53

je reviens avec une solution temporaire. Je n'ai pas trouver avec phpmyadmin comment avoir les données correctement, mais avec openoffice base, tu te connecte en odbc sur la bd, tu change dans le menu edition/base de données/propriété, l'onglet paramètres supplémentaires, tu set a utf8. apres les données sont vue correctement dans le logiciel.

moi · 2007-02-13 11:35:41

Merci de vos réponses à tous les deux

Concernant le post, je suis d’accord sur le titre, faut dire qu'au départ je pensais que c'était surement lié à ma distribution. c'est par la suite, en faisant des tests sur d'autres environnements/OS que je me suis aperçus que ce problème était général.

Merci chacawaca pour ton post, dés que j'ai un moment je fais le test, même si ce n'est pas exactement la solution que j'espérais, Cela pourra certainement m'aider à comprendre pourquoi j'ai ce problème, en attendant mieux.

moi · 2007-02-14 11:25:21

Je confirme que ça fonctionne en utilisant open office base, mais je n'ai pas encore trouvé de fonction pour exporter vers un document 'type' excel ou autres formats (slk par exemple) permettant une intégration avec d'autre fichiers ou dans une autre base (format tabulé ou n'importe quoi d'autre)...

chacawaca · 2007-02-14 19:41:25

jvais te donner un petit truc pour sa, tu ouvre ton base, tu change lencodage comme on a dit plus tot, ensuite tu ouvre ton calc, affichage/source de données
dans le nouveau menu tu click sur nouvelle base de données et tu peux aller copier coller les données de ta bd ou des requetes que tu a fait dans ton base.

gibi · 2007-02-14 23:21:32

Question: quelle version de phpmyadmin utilises-tu?
J'avais trouvé ça un jour mais j'ai perdu le lien donc je vous copie mon dokuwiki perso sur le sujet:
(je n'ai pas eu le temps de tester)
phpmyadmin

J’ai ajouté 2 lignes dans les fichiers dbi contenus dans le répertoire librairies/dbi/

Voici les lignes pour chaque fichier : dans mysql.dbi.lib.php :
[code ]

mysql_query("SET SESSION CHARACTER_SET_RESULTS =latin1;",$link); mysql_query("SET SESSION CHARACTER_SET_CLIENT =latin1;",$link);
[/code ]
Après PMA_DBI_postConnect($link, $is_controluser); et avant return $link; Dans la fonction PMA_DBI_connect

Au même endroit, dans le fichier mysqli.dbi.lib.php :
[code ]
mysqli_query($link, "SET SESSION CHARACTER_SET_RESULTS =latin1;"); mysqli_query($link, "SET SESSION CHARACTER_SET_CLIENT =latin1;");
[/code ]
Il s’agit en fait d’éviter au client mysql de faire une double conversion vers l’utf-8.

Voici le code complet des deux pages maintenant pour la fonction à modifier :
[code ]
function PMA_DBI_connect($user, $password, $is_controluser = FALSE) { global $cfg, $php_errormsg; $server_port = (empty($cfg['Server']['port'])) ? '' : ':' . $cfg['Server']['port']; if (strtolower($cfg['Server']['connect_type']) == 'tcp') { $cfg['Server']['socket'] = ''; } $server_socket = (empty($cfg['Server']['socket'])) ? '' : ':' . $cfg['Server']['socket']; if (PMA_PHP_INT_VERSION >= 40300 && PMA_MYSQL_CLIENT_API >= 32349) { $client_flags = $cfg['Server']['compress'] && defined('MYSQL_CLIENT_COMPRESS') ? MYSQL_CLIENT_COMPRESS : 0; // always use CLIENT_LOCAL_FILES as defined in mysql_com.h // for the case where the client library was not compiled // with --enable-local-infile $client_flags |= 128; } if (empty($client_flags)) { $connect_func = 'mysql_' . ($cfg['PersistentConnections'] ? 'p' : '') . 'connect'; $link = @$connect_func($cfg['Server']['host'] . $server_port . $server_socket, $user, $password); } else { if ($cfg['PersistentConnections']) { $link = @mysql_pconnect($cfg['Server']['host'] . $server_port . $server_socket, $user, $password, $client_flags); } else { $link = @mysql_connect($cfg['Server']['host'] . $server_port . $server_socket, $user, $password, FALSE, $client_flags); } } if (empty($link)) { PMA_auth_fails(); } // end if PMA_DBI_postConnect($link, $is_controluser); mysql_query("SET SESSION CHARACTER_SET_RESULTS =latin1;",$link); mysql_query("SET SESSION CHARACTER_SET_CLIENT =latin1;",$link); return $link; }
[/code ]

et

[code ]
function PMA_DBI_connect($user, $password, $is_controluser = FALSE) { global $cfg, $php_errormsg; $server_port = (empty($cfg['Server']['port'])) ? FALSE : (int) $cfg['Server']['port']; if (strtolower($cfg['Server']['connect_type']) == 'tcp') { $cfg['Server']['socket'] = ''; } // NULL enables connection to the default socket $server_socket = (empty($cfg['Server']['socket'])) ? null : $cfg['Server']['socket']; $link = mysqli_init(); mysqli_options($link, MYSQLI_OPT_LOCAL_INFILE, TRUE); $client_flags = $cfg['Server']['compress'] && defined('MYSQLI_CLIENT_COMPRESS') ? MYSQLI_CLIENT_COMPRESS : 0; $return_value = @mysqli_real_connect($link, $cfg['Server']['host'], $user, $password, FALSE, $server_port, $server_socket, $client_flags); if ($return_value == FALSE) { PMA_auth_fails(); } // end if PMA_DBI_postConnect($link, $is_controluser); mysqli_query($link, "SET SESSION CHARACTER_SET_RESULTS =latin1;"); mysqli_query($link, "SET SESSION CHARACTER_SET_CLIENT =latin1;"); return $link; }
[/code ]

Last edited by gibi (2007-02-14 23:28:56)

moi · 2007-02-15 16:17:34

COOL ..! ;-)

Merci chacawaca pour le conseil sur calc

J'avais essayé avec le menu données/pilote de données mais c'était trop galère et ça plantait en plus !

Maintenant je peut faire des exports propres sous Excel pour mes patrons du groupe.

Concernant le tutos sur phpmyadmin, je te remerci gibi, mais je ne préfere pas y toucher parceque j'ai plusieurs autres applications qui tournent sur ce serveur et qui fonctionnent très bien comme ça.

J'avais surtout besoin de trouver une solution pour sortir des états personalisés et 'propres' des données de glpi.

A l'occasion ce serait sympas que les dev. se penche sur le sujet, parce que quand même... c'est la seul application qui fait ça. j'ai réinstallé toutes mes applis sur un serveur windows, j'ai donc les mêmes appli sur win et sur linux et toutes fonctionnent correctement (concernant l'encodage) sur les deux environnements sauf GLPI. Il doit surement y avoir un petit quelque chose à faire

En tout cas merci à tous pour votre aide et encore bravo pour les dev. pour cette application que nous allons probablement adopter dans ma "boite" si le reste des tests se passent bien

SuniNewGlpiuser · 2007-02-15 16:41:36

j'utilise glpi 0.68.2 avec ocs Ver. 4020 sur une fedora core 4
j'ai mysql-4.1.11-2 et php-5.0.4-10.5 j'ai installé aussi phpMyAdmin 2.9.1.1.
Tout fonctionne bien sauf le plugin archire !

Forum GLPI-Project

Announcement

#1 2007-02-01 10:32:08

Problème d'install FEDORA tout Core toutes versions

#2 2007-02-01 10:45:23

Re: Problème d'install FEDORA tout Core toutes versions

#3 2007-02-01 11:22:27

Re: Problème d'install FEDORA tout Core toutes versions

#4 2007-02-01 11:51:05

Re: Problème d'install FEDORA tout Core toutes versions

#5 2007-02-01 12:46:53

Re: Problème d'install FEDORA tout Core toutes versions

#6 2007-02-01 13:27:10

Re: Problème d'install FEDORA tout Core toutes versions

#7 2007-02-01 14:21:03

Re: Problème d'install FEDORA tout Core toutes versions

#8 2007-02-01 15:26:49

Re: Problème d'install FEDORA tout Core toutes versions

#9 2007-02-01 18:21:08

Re: Problème d'install FEDORA tout Core toutes versions

#10 2007-02-12 12:24:25

Re: Problème d'install FEDORA tout Core toutes versions

#11 2007-02-12 12:43:03

Re: Problème d'install FEDORA tout Core toutes versions

#12 2007-02-12 14:20:18

Re: Problème d'install FEDORA tout Core toutes versions

#13 2007-02-12 14:25:59

Re: Problème d'install FEDORA tout Core toutes versions

#14 2007-02-12 15:23:21

Re: Problème d'install FEDORA tout Core toutes versions

#15 2007-02-12 20:56:36

Re: Problème d'install FEDORA tout Core toutes versions

#16 2007-02-12 23:36:08

Re: Problème d'install FEDORA tout Core toutes versions

#17 2007-02-13 00:06:53

Re: Problème d'install FEDORA tout Core toutes versions

#18 2007-02-13 11:35:41

Re: Problème d'install FEDORA tout Core toutes versions

#19 2007-02-14 11:25:21

Re: Problème d'install FEDORA tout Core toutes versions

#20 2007-02-14 19:41:25

Re: Problème d'install FEDORA tout Core toutes versions

#21 2007-02-14 23:21:32

Re: Problème d'install FEDORA tout Core toutes versions

#22 2007-02-15 16:17:34

Re: Problème d'install FEDORA tout Core toutes versions

#23 2007-02-15 16:41:36

Re: Problème d'install FEDORA tout Core toutes versions

Board footer