french : une décision à prendre
Bonjour, J'ai une décision à prendre pour la configuration de debian en français et je voudrais votre avis. les variables de locales sont de la formes [EMAIL PROTECTED], mais (et c'est bien pratique), on peut utiliser des alias (/etc/locale.alias), comme "french [EMAIL PROTECTED]" par exemple. Malheureusement, les outils comme modconf, tasksel, etc (ceux qu'appelle dbootstrap) ne peuvent pas utiliser ce fichier (et pour cause, "locales" n'est pas encore installé). Donc pas d'alias. french -> modconf en anglais. Le problème, c'est que même après l'installation, ça ne marche pas. Alors j'ai trois solutions. 1. On n'utilise plus les alias (!?) - Ça veut dire, je remplace french par fr_FR.ce que je veux dans language-env et dans mon document. - Ça veut aussi dire que si on change juste la variante, par exemple, au lieu de changer juste l'alias, on doit tout corriger. 2. On demande aux utilisateurs d'appeler ces outils (modconf, etc) en les faisant précéder de "LANG=fr" (au pire, je me tape une série d'alias dans language-env). - C'est pas ma conception du user-friendly 3. On demande aux mainteneurs de ces paquets d'essayer d'accéder aux alias qd même. - Voir le bug que j'avais lancé : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114057&repeatmerged=yes - Pour l'aspect technique, je peux répondre qu'un simple test "est-ce que le fichier /etc/locale.alias existe", c'est pas la mort. - Pour la discussion stérile qu'il y a eu sur debian-devel, j'ai envie de répondre qu'on s'en fiche de la valeur de l'alias : chacun la change comme il veut. Mais qu'il faut qd même que les applications s'en servent, parce que justement, ça permet de ne pas tout changer à chaque fois. Voilà. Votre avis ? PS : Je me restreint à -devel maintenant que les deux listes sont séparées, mais je ne souhaite aucunement exclure les "user". Si vous pensez qu'il faudrait leur CC ce message, n'hésitez pas à le dire. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
backport Imagemagick
Bonjour, que signifie un truc du genre --with-perl-options='INSTALLDIRS=vendor' dans les options de configuration de imagemagick ??? quelle est la probabilité qu'une recompilation automatique (i.e sans rien toucher, apt-get source -b ) fonctionne avec cette valeur ?? PS : évidemment ici ça foire... surtout parce qu'à un moment dans un Makefile, il à besoin d'une cible 'install_vendor_qqchose' ... qui n'existe pas ! ben voyons! A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: backport Imagemagick
En réponse à georges mariano <[EMAIL PROTECTED]>: > Bonjour, Salut, Tu es en train de backporter "le monde" Georges ? ;-) Pourquoi ne passes-tu pas à testing plutôt que te donner tant de mal ? > que signifie un truc du genre > > --with-perl-options='INSTALLDIRS=vendor' Cette option permet d'indiquer où installer les modules. core : répertoire des modules de la distribution de Perl (/usr/lib/perl/ vendor : répertoire où doivent être installés les modules provenant de paquet (/usr/lib/perl5, /usr/share/perl5) site : répertoires où doivent être installés les modules à partir d'un tarball (/usr/local/lib/perl5, /usr/local/share/perl5) Je ne sais pas si c'est propre à Perl 5.6 ou à la nouvelle Debian Perl Policy (je penche plutôt sur la dernière hypothèse). > > dans les options de configuration de imagemagick ??? > > quelle est la probabilité qu'une recompilation automatique > (i.e sans rien toucher, apt-get source -b ) fonctionne avec cette valeur Je ne pense pas qu'il y ait de chance que ça marche tout seul comme ça, puisque de gros changements dans Perl sont intervenus. J.M.
Re: backport Imagemagick
Jérôme Marant wrote: > > > > > quelle est la probabilité qu'une recompilation automatique > > (i.e sans rien toucher, apt-get source -b ) fonctionne avec cette valeur > > Je ne pense pas qu'il y ait de chance que ça marche tout seul > comme ça, puisque de gros changements dans Perl sont intervenus. > Par expérience, je déconseille à tout le monde d'essayer de recompiler sous Potato tout paquet Woody dépendant de Perl (entre autres). Tout a bcp trop changé et je ne connais personne qui ait réussi à recompiler perl5.6 pour Potato. Nico. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: backport Imagemagick
Nicolas SABOURET wrote: > > à recompiler perl5.6 pour Potato. > Je voulais dire : à le recompiler et à le faire marcher correctement :) Nico.
Re: backport Imagemagick
Le Wed, 24 Oct 2001 15:00:37 +0200, [EMAIL PROTECTED] écrivait : > En réponse à georges mariano <[EMAIL PROTECTED]>: > > Pourquoi ne passes-tu pas à testing plutôt que te donner tant > de mal ? > Bah, la réponse est toujours la même : quand tu gères un parc de machines en production, tu ne peux pas faire n'importe quoi dessus. L'approximation et le débogage n'ont pas leur place. Dès-lors, le choix de Potato s'impose obligatoire (C'est Debian qui parle de stable...) et donc, corrolairement, le back-port pour tous les logiciels plus à jour... testing est bien pour les courageux (et les moins courageux) mais cela reste du test, ce qui la condamne en production¹. PK ¹: tu trouveras toujours des gens pour me contredire (testing stable, au moins autant que telle ou telle distribution) mais lorsque tu connais les grosses entreprises, tu ne rigoles pas avec ce genre de principe. La stabilité *est* le critère absolu dans ce genre de démarche. -- Patrice KARATCHENTZEFF STMicroelectronics Tel: 04-76-92-67-95 850, rue Jean Monnet 38926 CROLLES Cedex, France Courriel: [EMAIL PROTECTED]
Re: backport Imagemagick
> Bah, la réponse est toujours la même : quand tu gères un parc de > machines en production, tu ne peux pas faire n'importe quoi dessus. > L'approximation et le débogage n'ont pas leur place. Dès-lors, le > choix > de Potato s'impose obligatoire (C'est Debian qui parle de stable...) > et > donc, corrolairement, le back-port pour tous les logiciels plus à > jour... Je suis tout à fait d'accord sur le fait de conserver un système fiable. En revanche, "passer à testing" ne signifie pas forcément apt-get dist-upgrade ou upgrade. Il est toujours possible de mettre à jour les applications de manière incrémentale, par simple apt-get install, les unes après les autres quand on en a besoin. Avant cela, on peut toujours consulter le BTS pour voir si la version courante de l'application que l'on souhaite mettre à jour n'est pas bogguée. Je pense que l'on peut s'en tirer de cette manière et éviter des efforts inutiles. J.M.
Re: backport Imagemagick
Patrice Karatchentzeff (2001-10-24 15:44:35 +0200) : > Bah, la réponse est toujours la même : quand tu gères un parc de > machines en production, tu ne peux pas faire n'importe quoi dessus. > L'approximation et le débogage n'ont pas leur place. Dès-lors, le > choix de Potato s'impose obligatoire (C'est Debian qui parle de > stable...) et donc, corrolairement, le back-port pour tous les > logiciels plus à jour... Oui, bon, certes, mais je ne vois pas en quoi recompiler un paquet de testing pour stable le rend stable. S'il est buggué dans testing, il le sera tout autant dans stable. Et en plus, le recompiler dans stable risque d'introduire de nouveaux bugs parce que le package n'a pas été prévu pour tourner sous stable. Soit c'est des bugs cachés (par exemple une dépendance non exprimée ou mal exprimée sur une version particulière d'une bibliothèque), soit c'est pas des bugs. Genre, un package pour Woody s'attendra à trouver des fichiers à un endroit précis (parce que la Policy de Woody est ce qu'elle est) et que ces fichiers n'y seront pas en Potato (parce que la Policy n'est pas la même). Pour moi, le backport risque d'introduire plus de problèmes qu'il n'en résoudra. > testing est bien pour les courageux (et les moins courageux) mais > cela reste du test, ce qui la condamne en production¹. Et faire confiance à un système non testé, potentiellement non cohérent, c'est pour les peureux ? > ¹: tu trouveras toujours des gens pour me contredire (testing > stable, au moins autant que telle ou telle distribution) mais > lorsque tu connais les grosses entreprises, tu ne rigoles pas avec > ce genre de principe. La stabilité *est* le critère absolu dans ce > genre de démarche. Aucun problème sur ce principe. Mais je ne suis pas convaincu que Potato+backports soit tout le temps plus stable que testing. Potato tout court, stable comme un roc, OK. Mais des backports... Roland. -- Roland Mas - Ogenki desuka, yau de poêle ? - Genki desu, ture en zinc.
Re: french : une décision à prendre
On Wed, Oct 24, 2001 at 10:54:17AM +0200, Nicolas SABOURET wrote: > Bonjour, > > J'ai une décision à prendre pour la configuration de debian en français > et je voudrais votre avis. > > les variables de locales sont de la formes [EMAIL PROTECTED], mais > (et c'est bien pratique), on peut utiliser des alias > (/etc/locale.alias), comme "french [EMAIL PROTECTED]" par exemple. > > Malheureusement, les outils comme modconf, tasksel, etc (ceux qu'appelle > dbootstrap) ne peuvent pas utiliser ce fichier (et pour cause, "locales" > n'est pas encore installé). > Donc pas d'alias. french -> modconf en anglais. > Le problème, c'est que même après l'installation, ça ne marche pas. [...] La solution est donc de faire en sorte que ça marche après l'installation, non ? Toutes les autres propositions, ça ressemble à du bidouillage. Denis
Re: backport Imagemagick
Le Wed, 24 Oct 2001 16:23:01 +0200, [EMAIL PROTECTED] écrivait : > > Aucun problème sur ce principe. Mais je ne suis pas convaincu que > Potato+backports soit tout le temps plus stable que testing. Potato > tout court, stable comme un roc, OK. Mais des backports... C'est vrai pour des paquets sensibles (libc, X, etc.). Pour du tout venant (Imagemagick ici), ce n'est pas un problème. Cela reste une potato avec des paquets « utilisateurs » mis à jour. Donc, au pire, ce qui risque d'être instable sont les paquets « utilisateurs » qui ne doivent pas interférer avec le système (au sens où un seg fault paralyserait la machine). Si l'on doit changer un paquet critique, il faut *sérieusement* se pencher sur la question (passage ou non à testing (via bien sûr une mise à jour purement graduelle comme le souligne Jérôme)). PK -- Patrice KARATCHENTZEFF STMicroelectronics Tel: 04-76-92-67-95 850, rue Jean Monnet 38926 CROLLES Cedex, France Courriel: [EMAIL PROTECTED]
Re: backport Imagemagick
Patrice Karatchentzeff <[EMAIL PROTECTED]> writes: > Le Wed, 24 Oct 2001 15:00:37 +0200, [EMAIL PROTECTED] écrivait : > >> En réponse à georges mariano <[EMAIL PROTECTED]>: >> >> Pourquoi ne passes-tu pas à testing plutôt que te donner tant >> de mal ? >> > > Bah, la réponse est toujours la même : quand tu gères un parc de > machines en production, tu ne peux pas faire n'importe quoi dessus. > L'approximation et le débogage n'ont pas leur place. Dès-lors, le choix > de Potato s'impose obligatoire (C'est Debian qui parle de stable...) et > donc, corrolairement, le back-port pour tous les logiciels plus à > jour... C'est curieux comme raisonnement : je reste en Potato pour des raisons de stabilité, mais je back-porte des softs de testing - donc potentiellement instable. Donc je détruis la stabilité, et commencent alors "l'approximation et le débogage". Si on veut du stable, on reste en stable. Point. -- Julien Gilles
Re: french : une décision à prendre
Denis Barbier wrote: > > La solution est donc de faire en sorte que ça marche après l'installation, > non ? C'est bien de ça qu'on parle. Qu'à l'installation, ils utilisent autre chose, pourquoi pas. Mais il faudrait que ça marche après. > Toutes les autres propositions, ça ressemble à du bidouillage. Laquelle ne considères-tu pas comme du bidouillage ? Je rappelle : 1. Pas d'alias. Mettre fr_FR.ISO-8859-15 dans language-env et dans les instructions du doc "debian en français" 2. LANG=fr modconf 3. Demander aux mainteneurs de tester le fichier alias. Si c'est 1, pourquoi avoir un fichier /etc/locale.alias ? Et justement, les anglais et les américains vont continuer à se taper dessus parce qu'ils n'ont pas compris qu'il suffisait de changer la ligne "english" de ce fichier pour avoir l'anglais de chez eux. Si c'est 3, cela signifie contacter chaque mainteneur pour qu'il utilise le fichier alias ... (rêvons un peu, ça fait du bien). > > Denis > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: backport Imagemagick
On Wed, 24 Oct 2001 15:00:37 +0200 (MEST) Jérôme Marant <[EMAIL PROTECTED]> wrote: JM > Tu es en train de backporter "le monde" Georges ? ;-) vi... on va me surnommer Atlas ... ;-) JM > Pourquoi ne passes-tu pas à testing plutôt que te donner tant JM > de mal ? Euh, qui t'as dit que j'avais du mal ... Imagemagick c'est un paquet sur ... un peu plus de 326 ... :-) Pourquoi ?? Réponse : pourquoi pas ?? Plus sérieusement, pour le principe ! Si Debian se dit "stable" (et je demande qu'à le croire) ce doit être raisonnablement faisable... Si ça ne l'est pas alors y'a un blême ... Et le plus important : c'est inimaginable les trucs qu'on apprend en faisant ça... C'est imparable pour la "qualité" des paquets... Petit exemple : la recompile de imagemagick bloque entre autres parce que a) il exige une lib qui en définitive est optionnelle b) il oublie de demander une lib qui elle est (apparemment) indispensable c) ce problème de install_vendor d) après avoir mis la valeur "site", on va un peu plus loin... ça bloque à nouveau ... veut installer des trucs dans debian/usr/lib/perl5/... qui n'existe pas ... N'importe quoi. PS : Dans l'intervalle de nombreux messages très significatifs ... Juste deux choses (c'est un peu méchant mais bon...): 1- Le seul qui ai vraiment compris _tous_ les paramètres du problème c'est PK. 2- A part ça bcp d'approximations... ai-je dit que j'upgradais aveuglément tous ce que je backporte (plus pour le fun d'ailleur...) ? Pour me convaincre de passer en woody, précipitez-vous pour répondre à la question suivante : a) qu'on m'explique pourquoi je vais (prendre le risque non négligeable de) rendre inutilisable ma petite dizaine de machines parce que je vais pointer sur woody et que, quasi inévitablement, ça va me chambarder les serveurs X, les install perl, tout ça pour que mes "utilisateurs", qui se pointent tous les matins au boulot (détail non négligeable), utilisent la dernière version d'une appli "tout venant" reconnue stable upstream, et qui n'à que faire de la policy-à-la-mode-actuellement ? b) une de plus tiens, pour la route... si le paquet source pris dans woody recompile pas ... d'où vient le paquet binaire "correspondant" ??? Je ne vous donnerai pas la liste des paquets qui soit disant nécessitent woody et qui fonctionnent bien sur mes potato depuis longtemps. Et qui se recompile sans un problème simplement en faisant croire que je suis en Xfree4 (merci equivs) Pour conclure, faudrait peut-être se rendre compte un jour que ce qui est 'unstable' chez Debian c'est _surtout_ les décisions humaines Debian, et pas les bugs des applis, ni la recompilation du tarball (90% de la validité du package)... On en vient à ne pas pouvoir installer un paquet pour des raisons "administratives" et non techniques... Faut arréter de délirer sur vos destriers blancs étiquetés Debian (ça rime!)... Je crois pas que ce soit la faute de ImageMagick si le paquet que je récupère ne se compile pas. ça vient de me donner une idée horrible ... je remonte d'un grand... make install (i.e install à la tarball)... et ça marche !! display 5.3.8 en potato... dernière fois que je fais ça.;-) Parait qu'il y a une équipe assurance qualité chez Debian ?? Fallait pas m'énerver ... ;-) A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: backport Imagemagick
georges mariano wrote: > > Plus sérieusement, pour le principe ! Si Debian se dit "stable" (et > je demande qu'à le croire) ce doit être raisonnablement faisable... > Si ça ne l'est pas alors y'a un blême ... Oui, enfin, en 2 ans, y'en a eu des changements ... > > N'importe quoi. > Bah non. C'est normal parce que tout perl a changé ! > b) une de plus tiens, pour la route... si le paquet source pris dans > woody recompile pas ... d'où vient le paquet binaire "correspondant" Bah ... de Woody ? Je comprends pas ta question. On peut compiler un paquet sous Woody aussi :) > > Je ne vous donnerai pas la liste des paquets qui soit disant nécessitent woody > et qui fonctionnent bien sur mes potato depuis longtemps. Et qui se recompile > sans un problème simplement en faisant croire que je suis en Xfree4 (merci > equivs) > Justement, j'aimerai bien. Parce que je trouve ça grave (serious). AMHA, les mainteneurs devraient travailler en stable, sauf s'ils ont besoin de qqch de très particulier qui a nécessité de un changement complet du système (ça arrive. Les paquets utilisant perl en font partie). > ni la recompilation du tarball (90% de la validité du package)... Oui. > Parait qu'il y a une équipe assurance qualité chez Debian ?? Je ne pense pas que qa soit en cause. C'est plutôt tous les mainteneurs (nous) qui recompilons nos paquets sous Woody, créant ainsi des dépendances trop fortes. Mais attention, dans de nombreux cas, il est impossible de faire autrement. Nico. Qui essaye de calmer GM :) -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: french : une décision à prendre
On Wed, Oct 24, 2001 at 05:02:57PM +0200, Nicolas SABOURET wrote: [...] > Laquelle ne considères-tu pas comme du bidouillage ? Je rappelle : > > 1. Pas d'alias. Mettre fr_FR.ISO-8859-15 dans language-env et dans les > instructions du doc "debian en français" > 2. LANG=fr modconf > 3. Demander aux mainteneurs de tester le fichier alias. > > Si c'est 1, pourquoi avoir un fichier /etc/locale.alias ? Et justement, > les anglais et les américains vont continuer à se taper dessus parce > qu'ils n'ont pas compris qu'il suffisait de changer la ligne "english" > de ce fichier pour avoir l'anglais de chez eux. > > Si c'est 3, cela signifie contacter chaque mainteneur pour qu'il utilise > le fichier alias ... (rêvons un peu, ça fait du bien). Oui, c'est celle-là qui semble la plus normale. Qu'ils aient un mode dégradé sans locales pour l'installation, pourquoi pas, mais après il faudrait quand même utiliser les locales. Denis
Re: backport Imagemagick
On Wed, 24 Oct 2001 17:53:39 +0200 Nicolas SABOURET <[EMAIL PROTECTED]> wrote: NS > > N'importe quoi. NS > Bah non. C'est normal parce que tout perl a changé ! Les changements de perl ont donc un lien avec : - la valeur "vendor" qui produit une cible Makefile qui n'existe pas ? (la valeur "site" passe ... elle) - ce genre d'erreur également (je garantis pas les retours à la ligne...) ?? dh_movefiles: debian/imagemagick//usr/share/man/man3/Image::Magick.3pm not found (cd debian/imagemagick >/dev/null ; find usr/share/man/man3/Image::Magick.3pm ! -type d -print || true) >> debian/movelist find: usr/share/man/man3/Image::Magick.3pm: Aucun fichier ou répertoire de ce type indice : y'a pas man3 (1,4 et 5 existent par contre...) ?? NS > Bah ... de Woody ? Je comprends pas ta question. On peut compiler un NS > paquet sous Woody aussi :) Perdu ... je sais _aussi_ recompiler sur woody (trop fort!!!) L'erreur obtenue est la première de la liste donnée précédemment (prévisible)... /usr/bin/ld: cannot find -lMagick collect2: ld returned 1 exit status make[4]: *** [blib/arch/auto/Image/Magick/Magick.so] Erreur 1 => trop fort, le mainteneur... Est-ce que j'ai l'air vraiment si newbie pour ne pas croire qu'avant de flammer je fais des tests ?? [on continue de rigoler ? : - l'installation woody du binaire imagemagick installe libmagick5... (tiens ?) - la recompilation par contre s'obstine à ne pas détecter -lMagick (libmagick5) (après ldconfig itou) et pourtant libmagick5: /usr/lib/libMagick.so.5 libmagick5: /usr/lib/libMagick.la libmagick4g-lzw: /usr/X11R6/lib/libMagick.la libmagick5: /usr/lib/libMagick.so.5.0.38 libmagick4g-lzw: /usr/X11R6/lib/libMagick.so.4.0.28 libmagick4g-lzw: /usr/X11R6/lib/libMagick.so.4 conclusion : ça recompile "mieux" sous potato que sous woody ... sous potato, le problème s'est réglé en deux commandes... ] Juste pour me convaincre/calmer : quelqu'un peut-il faire un "apt-get source -b imagemagick" ?? ... sur une woody évidemment !! je croirai sur parole ... (un dpkg -l me serai utile en cas de réussite ;-) NS > > Parait qu'il y a une équipe assurance qualité chez Debian ?? NS > NS > Je ne pense pas que qa soit en cause. C'est plutôt tous les mainteneurs NS > (nous) qui recompilons nos paquets sous Woody, créant ainsi des NS > dépendances trop fortes. arggg c'est marrant la dernière fois que j'ai dis ça (quasi mot pour mot) je me suis fais incendier ...(j'exagère juste un peu...) Bon ceci dit, je voulais dire que je me pose la question de savoir pourquoi y'a des paquet qui arrivent dans woody alors qu'ils ne se recompilent pas automatiquement ... (autre exemple ? debconf, il y a quelques temps, plantage cause qu'un fichier po tchèque je crois avait une erreur de syntaxe [évidemment 'rm le-dit-fichier.po' ... euh, y'a un rapport avec perl ?] le plus marrant c'est le nom du mainteneur debconf...) i.e suffit pas de balancer les initiales Q.A sur un site web pour s'approprier le sens véritable de ces initiales... autant pas les mettre. NS > Mais attention, dans de nombreux cas, il est impossible de faire NS > autrement. ben pas si nombreux que ça je trouve (oui, tout est relatif) NS > Nico. NS > Qui essaye de calmer GM :) euh, t'as rien de mieux à faire ?? (de plus constructif surtout ;-) :) PS : pour ces "vérifications", j'ai mis des paquets woody sur mon bo portable... j'ai peur d'arréter mon serveur X maintenant... j'ai pas gagné ma journée... 18h57 ! zou, dodo. -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: french : une d�cision � prendre
Comme je l'avais déjà signalé à Nicolas, il est possible de contourner le problème en mettant LANG=fr_FR* LC_ALL=french dans /etc/environment. Malheureusement je ne l'ai testé que sur modconf qui est bien repassé en français, mais n'ai pas essayé sur tasksel et les autres outils possibles mais je présume que cela doit fonctionner. C'était une idée comme une autre - Original Message - From: Denis Barbier <[EMAIL PROTECTED]> To: Sent: Wednesday, October 24, 2001 6:44 PM Subject: Re: french : une décision à prendre > On Wed, Oct 24, 2001 at 05:02:57PM +0200, Nicolas SABOURET wrote: > [...] > > Laquelle ne considères-tu pas comme du bidouillage ? Je rappelle : > > > > 1. Pas d'alias. Mettre fr_FR.ISO-8859-15 dans language-env et dans les > > instructions du doc "debian en français" > > 2. LANG=fr modconf > > 3. Demander aux mainteneurs de tester le fichier alias. > > > > Si c'est 1, pourquoi avoir un fichier /etc/locale.alias ? Et justement, > > les anglais et les américains vont continuer à se taper dessus parce > > qu'ils n'ont pas compris qu'il suffisait de changer la ligne "english" > > de ce fichier pour avoir l'anglais de chez eux. > > > > Si c'est 3, cela signifie contacter chaque mainteneur pour qu'il utilise > > le fichier alias ... (rêvons un peu, ça fait du bien). > > Oui, c'est celle-là qui semble la plus normale. Qu'ils aient un mode > dégradé sans locales pour l'installation, pourquoi pas, mais après il > faudrait quand même utiliser les locales. > > Denis > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif
Re: backport Imagemagick
On Wed, Oct 24, 2001 at 05:24:34PM +0200, georges mariano wrote: [...] > Pour conclure, faudrait peut-être se rendre compte un jour que ce qui est > 'unstable' chez Debian c'est _surtout_ les décisions humaines Debian, > et pas les bugs des applis, ni la recompilation du tarball > (90% de la validité du package)... > On en vient à ne pas pouvoir installer un paquet pour des raisons > "administratives" et non techniques... > Faut arréter de délirer sur vos destriers blancs étiquetés Debian (ça > rime!)... > > Je crois pas que ce soit la faute de ImageMagick si le paquet que je récupère > ne se compile pas. > > ça vient de me donner une idée horrible ... je remonte d'un grand... > make install (i.e install à la tarball)... > et ça marche !! display 5.3.8 en potato... dernière fois que je fais ça.;-) > > Parait qu'il y a une équipe assurance qualité chez Debian ?? > Fallait pas m'énerver ... ;-) Au lieu de t'énerver, tu aurais pu regarder si c'est un bug connu. direction http://bugs.debian.org/imagemagick et là, ô miracle, qu'est-ce qu'on voit ? Seulement le responsable du paquet n'arrive pas à reproduire ce bug, alors ce que tu peux faire, c'est lui conseiller de refaire la compilation après avoir supprimé libmagick5-dev, ça pourrait donner une idée de la raison pour laquelle ça recompile (apparemment) bien dans certaines conditions. Denis
Re: [EMAIL PROTECTED]: Requirements for a system with translated package descriptions]
Le Tue, 23 Oct 2001 11:59:53 +0200, Martin Quinson <[EMAIL PROTECTED]> a ecrit: > Hello, > > Grisu vient enfin de mettre en ligne le document spécifiant ce que le > système de traduction des descriptions de paquets doit permettre du point de > vue de l'utilisateur. On ne parle pas de comment le faire (c'est le boulot > des développeurs dpkg), mais de ce qu'il faut faire. > > Grisu n'a pas préciser où on en cause. Je dirais si vous etes faché avec > l'anglais, ici meme, et sinon sur -i18n. On ira sur -dpkg quand on aura un > document final et qu'il faudra parler d'implementation (et encore. Si on > nous y invite). > > Les discutions sur -i18n ont été un peu minimales jusque la. Veuillez > commenter ce document pour que cette idée ne s'embourbe pas (trop/plus)... > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Bonjour, Malgré que je suive l'affaire en parfait dilettante (ce qui veut dire que je ne suis pas spécialiste du sujet, mais qu'il est possible de ce fait que je puisse avoir des idées intéressantes/nouvelles à proposer - je ne serais d'ailleurs pas le seul ici, il doit y avoir bien d'autres personnes dans ce cas), j'aimerais apporter ici ma contribution à l'affaire. J'ai auparavant jeté un léger coup d'oeil aux archives de -i18n et -devel pour "m'immerger" un peu dans cette histoire (et ce bien que mon anglais soit très approximatif). Il m'a semblé y avoir quelques bonnes idées, mais aussi beaucoup de "blablas" qui ne font beaucoup avancer les choses. Je me trompe peut-être. Bref. J'écris surtout ce message pour savoir s'il serait possible de reprendre (dans une certaine mesure) les choses sur des bases saines afin de commettre quelque chose que les habitués/aguerris de -devel pourraient transmettre ensuite à la partie anglophone. Question préalable : Est-ce possible? En supposant que la réponse soit positive, je poursuis. D'après ce que j'ai compris, il s'agit donc de traduire les descriptions de paquet ; j'ai bon là? (la "chose" dans debian/control, vrai?). Bien. La première chose qu'il me semble bon de définir c'est une liste pour avoir sous les yeux le ou les buts à atteindre (encore un fois, je parts sur le principe que je n'y connais pas grand chose, et donc que je n'ai pas encore d'éléments pour amener de bonnes réponses - les plus proches de la vérité possible évidemment...). Je vais construire petit à petit une liste de questions, à qui j'espère donner au fur et à mesure des réponses. Il faudrait ensuite faire un tri, les classer, en deduire certaines choses, etc. Ainsi, pourrons-nous, je l'espère, dresser quelque chose de transmissible à -devel (ou tout autre). Essayons d'être constructifs. (si c'est pas au beau défi ça...). Cette liste va donc être _très_ incomplète. Les questions ne sont peut-être pas les bonnes, les réponses peuvent être uniques, multiples, exclusives ou non, etc. On démarre doucement La méthode vaut ce qu'elle vaut, mais elle ne me semble pas mauvaise. J'ai peut-être tout faux. Peut-être même que vous allez trouver cela totalement saugrenu. Tant pis. Au moins, j'aurais essayé. Donc (enfin...) : - Nous avons des paquets. - Nous avons des descriptions dans ces paquets. - Nous avons des langues. - Nous avons des mainteneurs. - Nous avons des traducteurs. - QU'EST CE QUE NOUS N'AVONS PAS? - (1) Les descriptions traduites. - QUE FAIRE POUR AVOIR (1)? - (2) Traduire les descriptions. - (2), QU'EST-CE QUE CELA FOURNIT? - (3) La traduction de description. - QUI EFFECTUE (3)? - (4) Le traducteur. - (5) Le mainteneur. ... - QUE DEVIENT (3)? - (6) intégrée dans le paquet (control) - (7) (autre?) ... (Oui, c'est un peu tiré par les cheveux, simpliste, inutile, etc. Suite...). Voici en dernier lieu ce qui peut-être une liste "fruit" des questions précédentes : - CE QUI DOIT ETRE FAIT PAR LES MAITENEURS - (6) intégrer les descriptions dans le paquet. - ... --> COMMENT LE FAIRE? AVEC QUOI? - ... - CE QUI DOIT ETRE FAIT PAR LES TRADUCTEURS - (2) Traduire les descriptions. - Transmettre les descriptions aux mainteneurs. - Ne pas transmettre les descriptions aux mainteneurs. - ... --> COMMENT LE FAIRE? AVEC QUOI? - ... - CE QUI DOIT ETRE FOURNIT AUX UTILISATEURS : - (1) Les descriptions traduites - La ou les description(s) de base au cas où (1) indisponible. - ... - CE QUI DOIT ËTRE FAIT SUR LES OUTILS (DPKG? AUTRES?) - Reconnaître la langue de l'utilisateur? - Reconnaître les langues de l'utilisateur? - Définir une langue de secours? Des langues? - ... C'est donc flou pour l'instant. Peut-être que ce n'est pas la bonne voie à prendre. Quelques personnes pour aider à remettre un peu d'ordre? Merci. A++ Nicolas PS : Promis, il n'y aura pas de discussion stérile... (R
