Re: Election du leader Debian
On Wed, Apr 05, 2006 at 08:52:25AM +0200, Raphael Hertzog wrote: Quel est le problème avec ftp-master ? À part pour ajouter de l'inertie dans le projet, qui n'en a pas besoin, à quoi sert un ftpmaster ? Par exemple, il faudra m'expliquer pourquoi les releases managers pour stable ont des comptes à leur rendre, et ne peuvent pas gérer la chose comme bon leur semble. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Election du leader Debian
On Tue, Apr 04, 2006 at 10:27:01AM +0200, Jérôme Marant wrote: Selon Raphael Hertzog [EMAIL PROTECTED]: Bonjour, il semble que le pourcentage de participation à l'élection du leader soit très faible cette année. Je ne saurai que vous inviter à y prendre part: bien que l'importance du DPL ne transparaisse pas toujours au grand public, il est absolument indispensable qu'on ait un bon DPL pour essayer de résoudre les problèmes internes que l'on rencontre (et j'en ai découvert un certain nombre depuis quelque temps). Comment faire pour voter blanc ? Envoyer un bulletin dont toutes les cases sont vides ? Ça dépend de ce que tu veux dire. Si tu te fiches complètement de savoir qui sera élu, tu les mets tous à égalité, et NOTA en dernier. Si tu ne veux d'aucun de ces candidats, c'est le contraire : NOTA en premier, et tous derrière. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i pouet pouet (was Re : Appel à commentaires et tralala)
On Wed, Feb 15, 2006 at 12:28:55AM +0100, Sven Luther wrote: On Tue, Feb 14, 2006 at 09:57:22PM +0100, Denis Barbier wrote: On Tue, Feb 14, 2006 at 09:56:58AM +0100, Sven Luther wrote: Le probleme c'est que personne n'est reellement motive pour bosser la dessus, et la team d-i impose une certaine barriere a l'entree (tu est pas joeyh ou quelqu'un de respecte par le core d-i, tu te fait flammer d'abord), qui bloque les contributions externes des gens qui ont pas la peau d'acier. Je n'ai jamais ressenti ce que tu décris sur la liste debian-boot. Mais vas faire un tour sur http://lists.debian.org/debian-devel-french/2006/02/author.html et fais un classement par nombre de messages. Tu arrives haut la main premier, avec deux fois plus de messages que le second. S'ils t'ignorent ou t'envoient balader, j'aurais plutôt tendance à penser que c'est parce que tu les as bien gonflé à un moment donné. C'est un peu facile comme argumentation, tu ne trouve pas. Pas du tout, cf ci-dessous. C'est dommage, parce que dans ce fil je trouve que tu as dit des choses intéressantes, mais en multipliant les interventions, tu finis par lasser. Donc, pour etre entendu, il faut se taire, c'est bon, je ne posterai plus. Et voilà, tu déformes mon propos, CQFD. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Utilisation de GIT pour g érer ses paquets Debian
Bonjour, J'aimerais apprendre à mieux connaitre GIT pour éventuellement gérer mes paquets Debian, est-ce qu'il existe une page similaire à celle qu'avait écrite Manoj pour tla ? http://arch.debian.org/arch/private/srivasta/index.xhtml Apparemment, il me manque des billes, j'ai du mal à comprendre la différence entre merge et rebase, et certainement plein d'autres choses. Par exemple, je fais des tests avec le paquet manpages-fr, et ai mis un miroir dans http://people.debian.org/~barbier/git/manpages-fr.git/ L'upstream n'a pas de dépôt CVS ou autres, simplement des tarballs. Dans le dépôt GIT, j'ai 5 têtes : 1. upstream, qui contient évidemment les sources upstream ; 2. fixes, pour les corrections qui devraient être faites en amont, et que j'envoie au traducteur upstream en espérant qu'il les intègre ; 3. debian, pour les corrections spécifiques à Debian ; 4. pagesdeman, pour tracer les traductions sur le site de Gérard Delafond ; 5. master, qui est l'équivalent du devo de Manoj, il contient le merge de toutes les branches, et j'y mets aussi le répertoire debian/ pour ne pas avoir une branche supplémentaire. Le fichier man7/iso_8859-2.7 contient des modifications différentes dans fixes et debian, qui entrent un conflit. J'ai fusionné les deux dans master, et gardé celles de debian. Quand une nouvelle version upstream apparait, je mets à jour debian et fixes avec cg-merge upstream, puis cg-merge fixes et cg-merge debian depuis master. Mais rebelote, encore conflit sur ce fichier. D'après les docs que j'ai lues, je me dis que git-rebase pourrait faire partie de la solution, mais je ne comprends pas bien la différence avec un merge. Bref, tous conseils bienvenus pour traiter ce cas, qui semble archi simple. D'autre part, les fichiers sont tous indépendants les uns des autres. Quand un nouveau tarball upstream est récupéré, est-ce qu'il vaut mieux faire un commit par fichier, ou un commit global fera aussi bien l'affaire ? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 07:32:19AM +0200, Sven Luther wrote: Le ralentissement deviens donc plus important quand la machine est lente. On a tous les 2 un facteur 100 sur le temps user, j'aurais tendance à dire que le traitement par grep est donc 100 fois plus long, mais cela peut être masqué par le temps des IO, du noyau, et autres, ce qui explique que le gain sur le temps écoulé n'est pas le même. Mais bon, je n'y connais rien en benchmark de telles commandes, commentaires bienvenus pour éclairer ma lanterne ;) Non, le choix de l'UTF-8 par défaut me semble judicieux, mais je voulais simplement souligner que ceux qui veulent rester en latin9 ne sont pas forcément des emmerdeurs accrochés à leurs habitudes, ils peuvent avoir de bonnes raisons de faire ce choix. Sur, mais il peuvent simplement decider de ne pas passer en UTF-8. Je veux dire, ils sont assez grand pour passer en mode expert et choisir latin9, non ? Bien sûr, tant qu'on ne leur met pas plus de bâtons dans les roues. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Mon, Sep 05, 2005 at 10:15:23PM +0200, Sven Luther wrote: Bon, ... $ time LC_ALL=C grep abcd /var/lib/dpkg/available /dev/null real0m0.093s user0m0.002s sys 0m0.010s $ time LC_ALL=fr_FR.UTF-8 grep abcd /var/lib/dpkg/available /dev/null real0m0.321s user0m0.260s sys 0m0.006s C'est effectivement plus lent, mais sans commune mesure avec les resultat que tu a. Tu a quoi comme machine ? Ben, une brouette. Et ce ralentissement est tellement flagrant pour moi que depuis que je suis passé en UTF-8, je mets LC_ALL=C devant tous les appels à grep dans mes paquets, le gain est appréciable. Pour un environnement graphique sur un ordinateur rapide, il y a effectivement peu de pronlèmes, ce qui justifie le passage à l'UTF-8 par défaut pour les nouvelles installations. Mais sur des ordis peu véloces ou pour des utilisateurs de la console, le choix de rester en latin9 me semble tenir la route. Ceux qui veulent vraiment ne avoir utf-8, ils peuvent toujours en faire le choix en mode expert, donc ... Non, le choix de l'UTF-8 par défaut me semble judicieux, mais je voulais simplement souligner que ceux qui veulent rester en latin9 ne sont pas forcément des emmerdeurs accrochés à leurs habitudes, ils peuvent avoir de bonnes raisons de faire ce choix. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problème : abrévi ation de la date en français
On Wed, Jul 20, 2005 at 02:09:11AM -1000, Christin LIVINE wrote: Bonjour, Il y a un problème avec l'abréviation de la date en français sous Nautilus, KDE, peut-être dans tout Debian, et dans toutes les autres distributions. En se basant sur Windows, ICU (http://www-950.ibm.com/software/globalization/icu/demo/locales/?d_=fr_=fr), CLDR (http://www.unicode.org/cldr/index.html) et Wikipedia (http://fr.wikipedia.org/wiki/Discussion_Wikip%C3%A9dia:Portail_Actualit%C3%A9s_et_%C3%A9v%C3%A8nements). Bonjour, cela ne prouve pas grand chose : ICU et CLDR utilisent les mêmes données, et sur wikipedia, dire « qu'il existe des normes pour l'abréviation des mois » est une chose, donner des références en est une autre (et de toute façon, il y a des majuscules partout à ces noms de mois, ce qui rend suspect cette assertion). J'ai trouvé http://www.oqlf.gouv.qc.ca/ressources/ti/dossiers/CCLQTI_20040720.pdf qui indique que ce qui est sur wikipedia est l'abréviation usuelle (sauf pour juillet), et ce qui est dans la glibc est un code à 3 lettres. Les 2 semblent donc légitimes, la préférence pour l'un ou l'autre va dépendre du contexte. Par exemple pour un utilitaire comme cal, avoir des noms de jour sur 4 caractères n'est vraisemblablement pas idéal. Les abréviations du mois sont (Attention à l'abscence de point pour certains) : [...] juil. juillet D'après le document ci-dessus, ça devrait être juill. août août sept. septembre oct. octobre nov. novembre déc. décembre Les abréviations du mois sont : lun. lundi mar. mardi mer. mercredi jeu. jeudi ven. vendredi sam. samedi dim. dimanche Ah non, le document donne des abréviations à 1 seule lettre, donc ça ne va pas du tout ;) La glibc est homogène, elle utilise des codes partout, et non des abréviations. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clavier français et RC3 de l'installateur (noyau 2.6)
On Thu, Apr 07, 2005 at 05:58:17PM +0200, Christian Perrier wrote: Quoting Philippe Batailler ([EMAIL PROTECTED]): J'ai fait une installation avec l'image netinst du 28 mars et j'avais bien un clavier qwerty dans la console gnome. En mode X, c'est différent et en tout cas différent du problème que je mentionne qui est avec la carte de clavier console. Le réglage du clavier graphique est en principe assuré par localization-config qui doit mettre les bonnes valeurs dans XF86Config-4. Ca, ça marche depuis longtemps en principedonc si ça ne marche pas, il faut penser à faire le rapport de bogue (mais ne pas oublier de bien préciser les circonstances). A priori ça marche, mais ça ne suffit pas pour GNOME, voir http://bugs.debian.org/301262 Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clavier français et RC3 de l'installateur (noyau 2.6)
On Thu, Apr 07, 2005 at 08:29:04PM +0200, Josselin Mouette wrote: Le jeudi 07 avril 2005 à 19:46 +0200, Denis Barbier a écrit : A priori ça marche, mais ça ne suffit pas pour GNOME, voir http://bugs.debian.org/301262 http://packages.qa.debian.org/c/control-center/news/1.html http://bugs.debian.org/296434 Super, merci pour l'info. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clavier français
On Fri, May 28, 2004 at 10:39:16AM +0200, Norbert Bottlaender-Prier wrote: mais comme le serveur en question fournit aussi des pages en langues russe, tchèque et turque p.ex., apparemment sans problème, je penche désormais à croire que le problème serait spécifique à l'encodage 8859-15, et que la solution serait plutôt à chercher du côté des outils de vérification du w3c qui mériteraient une mise à jour... donc: en avant pour les claviers *avec* euro ¤;-) http://www.debian.org/index.fr.html passe sans problème avec le validateur du w3c, or cette page est en iso-8859-15. Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Wed, Mar 10, 2004 at 04:57:47PM +0900, Mike Hommey wrote: [...] Quand bien même c'est possible d'avoir l'information sur l'encodage, ça ne suffit pas toujours. Je suis encore tombé sur un exemple à la con : les signets à paramètres de galeon (ou autre). Quand tu vas sur google.fr et que tu cherches un mot avec des accents, il se démerde avec l'encodage en envoyant le formulaire, car la page de départ contient un encodage (iso8859-1 ici). Mais quand tu veux faire une recherche en utilisant directement un signet, tu n'as pas l'information sur l'encodage dans lequel le site à l'autre bout veut ses informations. Et, corrigez-moi si je me trompe, autant HTTP précise un encodage pour ce que le serveur envoie, autant le client ne peut pas préciser en quoi son URL est encodée, et doit donc présupposer qu'elle est en utf-8. Et ma recherche sur Rémi se transforme en Rémi. Oui, c'est le truc le plus con à propos d'HTTP : la plupart des échanges entre serveur et client n'ont aucune indication de codage. Autrement dit, c'est le foutoir. On ne peut pas savoir si les champs d'un formulaire ont été remplis en UTF-8, en ISO-bidule ou en ISO-machin... Dans le cas des formulaires, ça dépend de la méthode (GET vs. POST) et est expliqué dans les specs de l'HTML, par exemple http://www.w3.org/TR/html401/interact/forms.html#h-17.13 Note. The get method restricts form data set values to ASCII characters. Only the post method (with enctype=multipart/form-data) is specified to cover the entire [ISO10646] character set. C'est pourquoi sur Google le codage est passé en argument des requêtes. Bien sûr, « on » va rétorquer qu'il suffit d'utiliser XForms à la place, qui répond au problème en imposant un codage en UTF-8 ;) http://www.w3.org/TR/2003/REC-xforms-20031014/slice11.html#serialize-urlencode Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Wed, Mar 10, 2004 at 04:37:01PM +0900, Mike Hommey wrote: Denis Barbier wrote: Quand un français parle à un japonais, ils parlent anglais. Ah non, pas du tout, efface C'est vrai, boire ou écrire, il faut choisir ;) Désolé. Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Wed, Mar 10, 2004 at 05:58:31PM +0900, Mike Hommey wrote: Denis Barbier wrote: Dans le cas des formulaires, ça dépend de la méthode (GET vs. POST) et est expliqué dans les specs de l'HTML, par exemple http://www.w3.org/TR/html401/interact/forms.html#h-17.13 Note. The get method restricts form data set values to ASCII characters. Only the post method (with enctype=multipart/form-data) is specified to cover the entire [ISO10646] character set. Oui, et comme c'est de l'ASCII, il faut utiliser une méthode de codage... en général on utilise la syntaxe %XX (XX étant un code hexa), le problème étant... qu'est-ce qu'on code dans cette syntaxe ? Non, le « form data set » représente le contenu du formulaire (les paires clé/valeur), pas l'URL. La façon dont l'URL est construite à partir du contenu du formulaire est expliquée dans http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3 Le paragraphe ci-dessus indique qu'avec la méthode GET, les clés et leurs valeurs ne peuvent contenir que de l'ASCII, et ensuite elles sont codées conformément aux règles pour le type application/x-www-form-urlencoded (remplacement des espaces par +, remplacement des caractères spéciaux, etc.). Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Sat, Mar 06, 2004 at 04:24:27PM +0100, Josselin Mouette wrote: Le ven 05/03/2004 à 12:21, Laurence Colombet a écrit : Je suis contre le fait d'imposer un kludge affreux comme l'UTF-8 à l'ensemble des utilisateurs de Debian, pour s'épargner d'avoir à supporter plusieurs encodages adaptés à la langue utilisée. (Ce qui serait pourtant beaucoup plus heureux: au lieu d'imposer à tout le monde un encodage unique mal goupillé, il vaudrait bien mieux être capable d'être multilingue...) Être multilingue ? Oh, c'est vrai, rien de plus facile. Alors prenons un exemple simple de multilinguisme : deux utilisateurs sur une machine, l'un parle français, l'autre japonais. Imaginons qu'ils travaillent ensemble, bien sûr. Déjà, ils vont vouloir s'échanger des fichiers. Si tu veux mettre les deux langues dans un fichier, à moins d'utiliser des hacks immondes, il faut un encodage unique, et pas seulement pour des fichiers texte : tu imagines un fichier HTML contenant des caractères japonais et français à la fois, utilisant uniquement les caractères d'échappement ? Oh, mais ça doit être pratique à éditer... Ils utilisent un codage unique si ça leur chante, je ne vois pas pourquoi il faut imposer le même à tout le monde. Regarde www.m17n.org par exemple pour d'autres solutions. Ensuite, ils vont vouloir stocker des fichiers sur le disque, avec des noms appropriés. Même problème, les noms des fichiers vont être apparaître tout sales à l'autre utilisateur s'ils n'utilisent pas un encodage unique sur le système de fichiers. Bon, on peut toujours faire comme le fait GNOME quand la locale n'est pas UTF-8 : on utilise un encodage unique pour les noms sur le disque, et on traduit à la volée. Je te laisse le soin de patcher le shell, les coreutils, et bien d'autres choses (genre en fait toutes les applis qui n'utilisent ni Qt ni la Glib), pour qu'ils soient capables de faire ça à la volée. Recommandation de www.openi18n.org, qui comme son nom l'indique est un organisme cherchant à promouvoir l'i18n sous toutes ses formes dans le logiciel libre : utiliser l'ASCII. Je suis sûr que j'en oublie, mais pour moi c'est très clair : un système multilingue, ça passe par unicode. Que ce soit UTF-8 ou autre chose, je m'en tape, mais sans uniformisation ce n'est pas la peine d'y songer. Unicode n'est qu'une table de caractères, c'est très bien que ça soit uniformisé, mais ça n'a aucun rapport avec le jeu de caractères de l'utilisateur. Quand tu es en latin1, tu utilises une table de conversion sur un sous-ensemble d'Unicode, donc ça devrait te plaire. Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Sat, Mar 06, 2004 at 11:56:13PM +0100, Denis Barbier wrote: [...] 2 solutions : a) imposer un codage unique b) permettre de spécifier le codage, comme pour le mail ou le web. Tu remarqueras que dans les discussions actuelles, personne ne veut entendre parler de (b), sans jamais fournir de raison valable. Alors que gettext montre depuis des années que (a) offre une solution [...] Rhh c'est évidemment (b) qu'il faut lire. Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Sun, Mar 07, 2004 at 12:19:30AM +0100, Josselin Mouette wrote: [...] Et c'est pareil pour le web : si tu veux une page avec à la fois du Français et du Japonais dessus, tu auras du mal sans utiliser utf-8. Oui, mais là où nous ne sommes pas d'accord, c'est ce qu'il faut faire quand il n'y a que du français ou que du japonais. Certains voudraient imposer l'UTF-8 dans ces cas là aussi, alors qu'on se débrouille très bien sans. Quand bien même c'est possible d'avoir l'information sur l'encodage, ça ne suffit pas toujours. Je suis encore tombé sur un exemple à la con : les signets à paramètres de galeon (ou autre). Quand tu vas sur google.fr et que tu cherches un mot avec des accents, il se démerde avec l'encodage en envoyant le formulaire, car la page de départ contient un encodage (iso8859-1 ici). Mais quand tu veux faire une recherche en utilisant directement un signet, tu n'as pas l'information sur l'encodage dans lequel le site à l'autre bout veut ses informations. Et, corrigez-moi si je me trompe, autant HTTP précise un encodage pour ce que le serveur envoie, Oui. autant le client ne peut pas préciser en quoi son URL est encodée, S'il s'agit de signets, je ne vois pas pourquoi le client ne peut pas spécifier de codage, ils sont stockés dans un fichier HTML, non ? et doit donc présupposer qu'elle est en utf-8. Et ma recherche sur Rémi se transforme en Rémi. Tu peux stocker l'URL comme R%E9mi, pas besoin d'UTF-8 pour ça. Alors oui, généraliser les méta-données sur l'encodage est une bonne chose, mais ça ne suffit pas, et c'est de toute façon inutile si tu veux un système vraiment multilingue. Faux, voir www.m17n.org Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Sun, Mar 07, 2004 at 12:00:59AM +0100, Josselin Mouette wrote: Le sam 06/03/2004 à 17:22, Denis Barbier a écrit : Ils utilisent un codage unique si ça leur chante, je ne vois pas pourquoi il faut imposer le même à tout le monde. Quitte à utiliser un codage unique, autant que ce soit le même pour tout le monde, non ? Quand un français parle à un japonais, ils parlent anglais. Est-ce que ça veut dire qu'il faut proscrire toute autre langue que l'anglais ? Recommandation de www.openi18n.org, qui comme son nom l'indique est un organisme cherchant à promouvoir l'i18n sous toutes ses formes dans le logiciel libre : utiliser l'ASCII. C'est du foutage de gueule. Ben voyons, www.openi18n.org est un repère de dinosaures rétrogrades dont le seul but est d'empêcher la promotion du multilinguisme, c'est évident. Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Fri, Mar 05, 2004 at 03:49:23PM +0100, Encolpe DEGOUTE wrote: On Fri, Mar 05, 2004 at 03:04:55PM +0100, Mathieu Roy wrote: Sebastien Bacher [EMAIL PROTECTED] wrote: Quant à tout passer en UTF-8, RedHat l'a fait, et visiblement ça n'a pas fait que des heureux, d'après ce que je peux lire ici ou là
Re: #debian-devel...@irc.debian.org et UTF-8
On Thu, Mar 04, 2004 at 09:03:27PM +0100, Roland Mas wrote: Denis Barbier, 2004-03-03 23:40:09 +0100 : [...] Tu es donc en train de nous expliquer que basculer #debian-devel-fr n'a pas vraiment d'intérêt, autant le faire sur #debian-devel ? Chiche ;) Presque. Je suis en train d'expliquer que quand je vois passer des trucs en non-ASCII sur #debian-devel, c'est de plus en plus souvent de l'UTF-8. Je pratique peu l'IRC, mais il semble me souvenir que les caractères accentués sur #d-d déchaînent souvent de vives critiques, ça a changé ? Parallèlement à ça, je suis en train d'expliquer que ça me fait mal au c*l d'entendre des États-Uniens se moquer des Français qui se regardent le nombril et ne veulent pas passer à un standard international (c'est du vécu, et t'as beau dire « C'est pas moi c'est jb » tu fais pas le malin). ISO-8859-*, ça commence par quoi ? Et les Japonais, c'est aussi par franchouillardise qu'ils se regardent le nombril ? Ça me ferait également mal d'être à la traîne, alors qu'on pourrait être les moteurs du changement. C'est pas encore le cas, mais il suffit que quelqu'un d'autre bascule avant nous et on se retrouve à la traîne. RH a plusieurs longueurs d'avance sur ce terrain, et apparemment les utilisateurs ne sont pas tous emballés ;) Typiquement, le jour où *Mirc* comprendra l'UTF-8, la plupart des pratiquants d'IRC sous Windows XP vont basculer très vite en UTF-8. Et si on n'a pas validé nos multiples clients avant, on sera à la traîne longtemps, et ça va être une très sale image qu'on va se coltiner longtemps. Ben voilà, on y arrive, il faut que nos outils gèrent mieux les différents codages de caractères. Sur ce point, on est évidemment tous d'accord. Mais je ne vois pas en quoi le fait de basculer un canal en UTF-8 va changer quoi que ce soit (à part emmerder ceux qui ont un client bogué). Denis
Re: #debian-devel...@irc.debian.org et UTF-8, variantes
On Thu, Mar 04, 2004 at 09:41:13PM +0100, Roland Mas wrote: [...] Après un sondage (rapide, je l'admets) sur #debian-devel, il apparaît que la plupart des canaux #debian-* ont basculé en encodage UTF-8, à l'exception notable de #debian-devel-fr. Après enquête un peu plus poussée, cette info est fausse. Note pour plus tard : ne pas extrapoler ce que disent trois personnes sur un canal IRC. Mea culpa. Sur les quelques 1700 canaux visibles depuis irc.debian.org, un seul a un topic contenant de l'UTF-8 (#gpul), 113 des caractères non-ASCII autres que de l'UTF-8 (les français sont loin d'être les plus représentés), le reste est en ASCII (ces canaux pouvant évidemment accepter l'UTF-8). [...] C'est ici que ça devient intéressant, et que je propose mon amendement : on bascule toujours le 20 mars à 6:49 TU, *mais* pour une durée limitée, disons d'un mois. Comme ça, pendant un mois, on bricole chacun avec son client, ses locales, ses a/e/k/x/uxterm, son screen, tout ça ; on rapporte les bugs, éventuellement avec des patches ; et fin avril on peut revenir au Latin-9 si on constate que c'est *vraiment* trop la merde. Deuxième variante : on crée un #Debian-UTF-8, et on invite tout le monde (c'est-à-dire pas uniquement les DD francophones) dessus pendant une durée limitée (ou pas). Comme ça, on pourra tester en conditions réelles. Vu le peu de temps que je passe sur IRC, mon avis importe peu, je m'adapterai ;) Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Tue, Mar 02, 2004 at 10:16:57PM +0100, Roland Mas wrote: Salut à tous, Après un sondage (rapide, je l'admets) sur #debian-devel, il apparaît que la plupart des canaux #debian-* ont basculé en encodage UTF-8, Pour les canaux anglophones, ça ne veut pas dire grand chose. Qu'en est-il des autres ? à l'exception notable de #debian-devel-fr. De manière à faciliter la coopération internationale et inter-canal je propose que nous déclarions officiellement la bascule de #debian-devel-fr vers l'encodage UTF-8 un de ces jours. Parmi les présents en ce moment même, seul jb roumègue parce que son client IRC en os de mammouth taillé au silex ne sait pas se démerder avec les encodages. Pareil, mon bitchx d'unstable a l'air de ne pas aimer l'UTF-8, il me colle un espace après chaque lettre accentuée (en fait certainement autant d'espaces que d'octets nécessaires pour coder le caractère). Denis
Re: #debian-devel...@irc.debian.org et UTF-8
On Wed, Mar 03, 2004 at 10:30:13PM +0100, Roland Mas wrote: Denis Barbier, 2004-03-03 08:20:10 +0100 : On Tue, Mar 02, 2004 at 10:16:57PM +0100, Roland Mas wrote: Salut à tous, Après un sondage (rapide, je l'admets) sur #debian-devel, il apparaît que la plupart des canaux #debian-* ont basculé en encodage UTF-8, Pour les canaux anglophones, ça ne veut pas dire grand chose. Qu'en est-il des autres ? Pour les canaux anglophones, c'est au contraire presque là que ça a le plus de sens : autant sur #debian-devel-fr on peut s'attendre à ne causer que français, autant sur #Debian-devel on trouve des gens du monde entier, qui peuvent avoir l'occasion d'émettre un truc quelconque dans leur langue n'importe quand. /away, /quit, un message d'erreur copicollé sans LANG=C, voire une quelconque discussion linguistique (#debian-devel dévie « parfois » des pures discussions techniques sur le développement de Debian :-). Tu es donc en train de nous expliquer que basculer #debian-devel-fr n'a pas vraiment d'intérêt, autant le faire sur #debian-devel ? Chiche ;) Pour les autres canaux #debian-*, en fait et après avoir regardé de manière un peu plus approfondie que juste demander sur #d-d, visiblement c'est la foire. Latin-1, Latin-2, KOI8-R, et je suis en train de demander sur #debian-japanese mais à cette heure-ci ils dorment et leur /topic est vide. Comment ça, pas un seul en UTF-8 ? Denis
Re: machine debian pour une base de données
On Sat, Jan 17, 2004 at 12:51:51PM +0100, Nicolas Bertolissio wrote: Bonjour, pour aider à suivre les traductions un hollandais a fait un joli truc en php et mysql sur une machine à lui perso. Je cherche à reproduire la chose, au debut pour le français pour voir un peu et développer. Pour cela j'ai besoin d'une base de données (il faut que je puisse la remplir en perl et lire en php). Je dois pouvoir développer ça avec db3 mais ça ne me semble pas aussi facile qu'avec sql. D'où ces quelques questions : - Existe-t-il une machine debian avec un serveur de bases de données ? MySQL ou PostgreSQL de préférence ; - Si oui, laquelle ? et - À qui dois-je demander un accès ? Il faut aussi nourrir cette base de données, c'est-à-dire (si j'ai bien compris) que les messages des listes à suivre doivent arriver sur cette machine et être analysés pour ensuite rentrer dans la base. Denis
Re: [HS] Re: Testez l'installateur Debian....
On Wed, Nov 05, 2003 at 09:56:38AM +0100, sferriol wrote: Denis Barbier wrote: On Mon, Nov 03, 2003 at 10:43:07AM +0100, sferriol wrote: [...] il faudrait mieux améliorer cdebconf, car à l'avenir je pense qu'il va remplacer debconf. Heu, franchement ça m'étonnerait, sa seule fonction est d'être utilisé dans le debian-installer, et on ne se prive pas pour rajouter des fonctionnalités qui n'existent pas dans debconf. Ah , j'ai dû mal comprendre ce que m'avait dit joey: Yes, I am hoping that cdebconf will be able to replace debconf eventually, though I don't know the timeframe. [...] Ben non, je ne savais pas qu'il pensait ça, mais je persiste quand même ;) Denis
Re: [HS] Re: Testez l'installateur Debian....
On Mon, Nov 03, 2003 at 10:43:07AM +0100, sferriol wrote: [...] il faudrait mieux améliorer cdebconf, car à l'avenir je pense qu'il va remplacer debconf. Heu, franchement ça m'étonnerait, sa seule fonction est d'être utilisé dans le debian-installer, et on ne se prive pas pour rajouter des fonctionnalités qui n'existent pas dans debconf. Mais il manque encore des fonctionnalités, et celle qui m'intéresse c'est LDAP. je commence à coder à mes heures perdues le module ldap pour cdebconf, si des personnes sont déjà dessus, prévenez moi..;) Tu perds ton temps, cdebconf ne remplacera pas debconf. Je ne dis pas qu'il ne faut pas de version C, mais juste que celle-là n'a aucune chance, il faudrait la réécrire from scratch ;) Il y a des tableaux de taille fixe, des fuites de mémoire, etc. dans tous les coins. Le design est à 1000 lieues derrière debconf (ce n'est pas la faute de Randolph Chung, mais comme il a arrêté de s'en occuper, les différents contributeurs ont ajouté leurs bouts de codes sans se préoccuper vraiment de l'architecture globale). Denis
Re: Traduction de menus et Gnome....UTF-8eries
On Sun, Sep 21, 2003 at 09:12:40AM +0200, Christian Perrier wrote:
[...]
Je précise que mes locales sont fr_FR.ISO-8859-15 (c'est dans
/etc/environment et c'est aussi ce que je choisis avec gdm, donc
GDM_LANG=fr_FR.ISO-8859-15)
T'es sûr ? Cette locale n'existe pas, tu devrais être en
[EMAIL PROTECTED]
Du coup, update-menus s'exécute avec LANG=fr_FR.ISO-8859-15.
Si, par contre, je le force à s'exécuter avec LANG=fr_FR.UTF-8, tout
va alors bienmême quand je fais afficher les menus dans un
environnement en ISO-8859-15
As-tu essayé de positionner la variable d'envireonnement G_BROKEN_FILENAMES ?
Update-menus crée des fichiers en codant le nom dans la locale en cours,
et donc tu dois positionner cette variable si tu n'es pas en UTF-8.
C'est quand même un beau bordel (ou alors un truc simple vachement mal
expliqué) tout ce fourbi. J'ai d'ailleurs beau faire des tas de
tentatives pour faire du tout UTF-8, je finis toujours par revenir au
bon vieil ISO-8859-{1|15} quand j'en ai marre de voir ou d'envoyer des
hiéroglyphes.
C'est pas logique, tu dis que ça marche mieux en UTF-8 ;)
Denis
Re: Couper un paquet en deux
On Sat, Sep 06, 2003 at 12:23:02PM +0200, Jérôme Marant wrote: Quoting Denis Barbier [EMAIL PROTECTED]: Bonjour, je souhaite couper le paquet manpages-fr en deux, manpages-fr et manpages-fr-dev. Si possible, il faudrait que le paquet actuel 1.58.0-1 soit remplacé par les 2 autres. Dans la prochaine version 1.58.0-2, je pense mettre Package: manpages-fr Suggests: manpages-fr-dev Si tu fais ça, les utilisateurs de manpages-fr vont voir des fichiers disparaitre sans comprendre. Ce n'est effectivement pas le but, je pense que je vais opter pour la solution de Raphaël. Donc, à mon avis, pour sarge, il faut mettre: Depends: manpages-fr-dev Après sarge, tu pourras remplacer le Depends par Suggests. De cette, manière, les gens n'auront pas de surprise. (C'est comme celà que les choses ont été faites pour séparer dselect du paquet dpkg). Package: manpages-fr-dev Recommends: manpages-fr Replaces: manpages-fr ( 1.58.0-2) Conflicts: manpages-fr ( 1.58.0-2) Est-ce la bonne solution ? Pourquoi Replaces: manpages-fr ( 1.58.0-2) ? En lisant la section 7.3 de la charte sur les conflits, il m'a semblé que c'est ce qu'il faut faire pour gérer ce genre de situations. Mais c'est la 1e fois que j'y suis confronté, alors je demande confirmation. Denis
Couper un paquet en deux
Bonjour, je souhaite couper le paquet manpages-fr en deux, manpages-fr et manpages-fr-dev. Si possible, il faudrait que le paquet actuel 1.58.0-1 soit remplacé par les 2 autres. Dans la prochaine version 1.58.0-2, je pense mettre Package: manpages-fr Suggests: manpages-fr-dev Package: manpages-fr-dev Recommends: manpages-fr Replaces: manpages-fr ( 1.58.0-2) Conflicts: manpages-fr ( 1.58.0-2) Est-ce la bonne solution ? Denis
Re: [HS] : coup de gueule
On Thu, Aug 14, 2003 at 09:19:14PM +0200, Raphael Hertzog wrote: [...] Sinon j'ai quand même une critique sur lancer une discussion sur -devel ... ca ne sert à rien, sauf à démarrer une flamewar. Si on veut vraiment être productif, il faut faire un contributors.debian.net sur une machine perso d'un développeur motivé par ce projet et faire un premier jet de ce que pourrait être cette infrastructure officielle qui permettra aux contributeurs non développeurs d'être reconnus. Ensuite on annonce cela sur -devel et on en discute sur une base tangible ... la discussion qui en suivra sera 100 fois plus constructive. J'en profite pour lancer une idée que je voulais formuler depuis quelques temps. Est-il possible pour les projets hébergés sur Alioth de fournir des droits d'écriture (CVS ou Subversion) pour un fichier unique ? L'idée est de permettre aux traducteurs de committer directement. Si cela se généralise, je pense que c'est un premier pas pour reconnaître ce statut de contributeur. Si c'est possible, y-a-t'il des développeurs intéressés pour la mettre en pratique ? Denis
Re: [HS sur java] Comment voir plus rapidement les nouveaux prg dans SID ?
On Thu, Aug 14, 2003 at 02:29:18PM +0200, Boulanger Jean-Louis wrote: [...] Quitte a faire le malin je suis d'accord avec mike, il faut que tu arrives a trouver au moins un truc exceptionnel se trouvant dans C++ que les imbecile de SUN ont consciemment mis hors de JAVA allez un petit efforts tu as l'air si fort . fais nous plaisir, ne nous laisse pas sur notre faimm .. Je me contrefous de savoir qui a la plus grosse, mais faisant du cul nu avec Java, j'aimerais savoir si les griefs énoncés contre Java sur http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf sont fondés et toujours d'actualité. Merci d'éclairer ma lanterne. Denis
Re: [HS] : coup de gueule... Où va Debian ?
On Wed, Aug 13, 2003 at 09:57:54PM +0200, Patrice Karatchentzeff wrote: [...] Je n'ai pas suivi le détail de l'affaire mais Walsh a à mes yeux la même stature que n'importe quel pilier du libre, genre RMS, Wall ou Torvalds. Pour ceux qui connaissent pas l'animal, il n'est ni plus ni moins que l'auteur de la DTD DocBook, un « petit » monument de la mise en page d'un document... Debian a naturellement repompé cette DTD pour offrir debiandoc - un sous-ensemble bien inférieur dont le choix initial m'échappe complètement - et tout d'un coup, on fait la fine gueule quand l'auteur demande bêtement de venir rejoindre Debian... Cela me dépasse complètement. Je vois bien pourquoi cela se passe ainsi : cf. encore ma réponse à M. Roy. Non, le problème est que tu te trompes complètement sur la finalité : on est développeur Debian pour aider, ce n'est pas une récomprense. Si Walsh ou RMS n'ont qu'une demi-heure à y consacrer par semaine, à quoi ça sert ? Si mes souvenirs sont bons, James Troup a supprimé une centaine de comptes de développeurs qui étaient devenus inactifs. Ce n'est pas une punition, simplement le fait que ça ne sert à rien de garder ces comptes inutilisés. Ce n'est pas spécifique à Debian, là ou je suis passé, les admins système font pareil, ça facilite la maintenance. Certains développeurs quittent le projet d'eux-mêmes, mais beaucoup ne s'en donnent pas la peine et sont poussés dehors. Denis
Re: [HS] : coup de gueule. Ou va Debian ?
On Wed, Aug 13, 2003 at 10:34:14PM +0200, Patrice Karatchentzeff wrote: Julien BLACHE écrivait : Benoit Friry [EMAIL PROTECTED] wrote: Il me semble que le fait d'être mainteneur Debian est couplé au fait de pouvoir voter. Ce qui me semble bien plus important que de pouvoir accéder aux ressources Debian. Il faut arrêter de faire une fixette sur le fait de pouvoir voter. Il n'y a pas d'enjeux véritables dans les votes, et une grande partie des développeurs ne votent pas. Très bien : une grande partie des DD ne font pas bien leur boulot donc ne recrutons pas davantage ! Ce que tu dis n'a aucun rapport avec la réponse de Julien. Le processus d'élection du leader est au coeur même du développement de Debian... Fantastique, tu vas donc pouvoir me dire en quoi les derniers DPL ont influé sur Debian, je ne vois pas. Denis
Re: [HS] : coup de gueule... Où va Debian ?
On Wed, Aug 13, 2003 at 09:49:57AM +0200, Sven Luther wrote: On Wed, Aug 13, 2003 at 12:24:11AM +0200, Denis Barbier wrote: On Tue, Aug 12, 2003 at 11:47:22PM +0200, Pierre Machard wrote: [...] On peut effectivement se le demander, mais il faut rester positif. Le réel problème, c'est qu'il n'y a pas de statut pour les traducteurs, [...] Pas seulement, il n'y a en fait de statut que celui de développeur. Mais les choses ne bougent que de l'intérieur, donc si les personnes qui ont un profil différent ne sont pas intégrées, ça ne risque pas de changer. Moralité : il faut se déguiser en développeur et jeter le masque une fois dans la place. Je pense que le probleme viens surtout du fait que l'adresse mail @debian.org est etroitement liee a l'obtention d'un compte sur toutes les machines, et les privileges d'upload qui vont avec. Par contre, peut-etre serait-ce le bon moment pour utiliser ce cas pour essayer d'avancer sur le point que tu cite ? Mais je n'ai aucune idée sur la façon de procéder pour avancer, à part intégrer des personnes avec un profil différent pour augmenter la masse relative de gens intéressés par la l10n ou la documentation. Et encore, si j'y croyais vraiment, je ferais partie du processus NM. En attendant, je fais de mon mieux pour corriger les problèmes qui sont signalés. Denis
Re: [HS] : coup de gueule... Où va Debian ?
On Tue, Aug 12, 2003 at 11:47:22PM +0200, Pierre Machard wrote: [...] On peut effectivement se le demander, mais il faut rester positif. Le réel problème, c'est qu'il n'y a pas de statut pour les traducteurs, [...] Pas seulement, il n'y a en fait de statut que celui de développeur. Mais les choses ne bougent que de l'intérieur, donc si les personnes qui ont un profil différent ne sont pas intégrées, ça ne risque pas de changer. Moralité : il faut se déguiser en développeur et jeter le masque une fois dans la place. Denis
Re: Debconf encore
On Tue, Jul 29, 2003 at 06:52:47AM +0200, Michel Grentzinger wrote: Le Mardi 29 Juillet 2003 00:56, Denis Barbier a écrit : D'abord, je tiens à rectifier qu'il ne s'agit pas de rssh (dont je vais demander le passage à po-debconf) mais de rootskel. [...] Dans ce cas, c'est très différent. Le paquet rootskel fait partie du debian-installer, qui a un format .udeb légèrement modifié par rapport au .deb ; tout ce qui n'est pas essentiel est supprimé pour gagner de la place, il est donc probable que l'oubli de cette dépendance soit volontaire. Oui, d'ailleurs, je n'arrive pas à passer debconf-gettextize dessus... Il me renvoie une erreur à cause des champs Default[sparc] Default[s390]... Comment faire ? Effectivement, debconf-gettextize ne marche pas avec des fichiers non standards. Une solution consiste à modifier le fichier, lancer debconf-gettextize, puis remettre le fichier d'origine en marquant à la main les champs à traduire. Il faut ensuite vérifier que cela n'interfère pas avec le mécanisme de génération utilisé. J'avais les neurones embrumés hier soir, j'aurais dû te proposer de m'en occuper. C'est maintenant fait dans le CVS. Denis
Re: templates partagés de debconf
On Mon, Jul 28, 2003 at 08:06:32AM +0200, Christian Perrier wrote: Quoting Denis Barbier ([EMAIL PROTECTED]): Je trouve cela un peu bizarre, voire crade quand même.. :-) Bien sûr, mais cela concerne vraiment très peu de fichiers. Il ne semble pas évident de fournir une solution vraiment satisfaisante, donc on se contente de celle-là pour l'instant. La première solution qui me venait à l'esprit était de mettre ces écrans dans debconf lui-même (ou dans un paquet séparé requis par debconf). Comme, nécessairement, debconf doit être présent vu qu'il est requis par tous les paquets qui l'utilisent, cela déplacerait ces écrans ailleurs et surtout à un seul endroit...ce qui éviterait d'avoir à les traduire 12 fois. Hmmm, cette histoire me rappelle quelque chose. Ah oui, c'est http://kitenet.net/pipermail/config/2002-July/000293.html Je n'ai pas relancé ensuite. Toi qui es champion de la moulinette infernale, crois-tu qu'il serait possible de récupérer la liste de tous les templates shared et des paquets qui les utilisent ? En attachement, le fichier donne le nom du template et le paquet ainsi que le fichier templates qui le contient. Sauf oubli de ma part, ce sont les seuls templates partagés. Denis shared/clobber_x-server_symlink ./main/x/xfree86/xfree86_4.2.1-9_debian_xserver-xfree86.templates.gz shared/clobber_x-server_symlink ./main/x/xfree86v3/xfree86v3_3.3.6-44_debian_xserver.templates.gz shared/console/acm/default ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/console/fonts/charset ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/console/fonts/charsize ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/console/sfm_fallbacks ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/default-x-display-manager ./main/g/gdm/gdm_2.4.1.3-2_debian_templates.gz shared/default-x-display-manager ./main/k/kdebase/kdebase_4:3.1.2-1.1_debian_kdm.templates.gz shared/default-x-display-manager ./main/w/wdm/wdm_1.22.1-2_debian_wdm.templates.gz shared/default-x-display-manager ./main/x/xfree86/xfree86_4.2.1-9_debian_xdm.templates.gz shared/default-x-server ./main/x/xfree86/xfree86_4.2.1-9_debian_xserver-xfree86.templates.gz shared/default-x-server ./main/x/xfree86v3/xfree86v3_3.3.6-44_debian_xserver.templates.gz shared/keymap/country ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/keymap/keymap ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/keymap/keymap_filename ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/keymap/layout ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/keymap/variant ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/keymap/wants_nondefault ./main/c/console-data/console-data_2002.12.04dbs-13_debian_attic_console-data.templates.gz shared/kinput2/wnn/keybindings ./main/k/kinput2/kinput2_3.1-3_debian_kinput2-canna-wnn.templates.gz shared/kinput2/wnn/keybindings ./main/k/kinput2/kinput2_3.1-3_debian_kinput2-wnn.templates.gz shared/ldapns/base-dn ./main/libn/libnss-ldap/libnss-ldap_207-1_debian_templates.gz shared/ldapns/base-dn ./main/libp/libpam-ldap/libpam-ldap_156-1_debian_templates.gz shared/ldapns/ldap-server ./main/libn/libnss-ldap/libnss-ldap_207-1_debian_templates.gz shared/ldapns/ldap-server ./main/libp/libpam-ldap/libpam-ldap_156-1_debian_templates.gz shared/ldapns/ldap_version ./main/libn/libnss-ldap/libnss-ldap_207-1_debian_templates.gz shared/ldapns/ldap_version ./main/libp/libpam-ldap/libpam-ldap_156-1_debian_templates.gz shared/mailname ./main/n/nullmailer/nullmailer_1.00RC7-17_debian_templates.gz shared/mailname ./main/s/slrn/slrn_0.9.7.4-38_debian_templates.gz shared/multiple_possible_x-servers ./main/x/xfree86/xfree86_4.2.1-9_debian_xserver-xfree86.templates.gz shared/multiple_possible_x-servers ./main/x/xfree86v3/xfree86v3_3.3.6-44_debian_xserver.templates.gz shared/news/server ./main/k/knews/knews_1.0b.1-12_debian_templates.gz shared/news/server ./main/p/post-faq/post-faq_0.10-7_debian_templates.gz shared/news/server ./main/s/slrn/slrn_0.9.7.4-38_debian_slrnpull.templates.gz shared/news/server ./main/s/slrn/slrn_0.9.7.4-38_debian_templates.gz shared/news/server ./main/t/tin/tin_1:1.5.19+20030609-2_debian_templates.gz shared/news/server ./main/u/uqwk/uqwk_2.21-6_debian_uqwk.templates.gz shared/news/server ./non-free/t/trn4/trn4_4.0-test76-4_debian_templates.gz shared/no_known_x-server ./main/x/xfree86/xfree86_4.2.1-9_debian_xserver-xfree86.templates.gz shared/no_known_x-server ./main/x/xfree86v3/xfree86v3_3.3.6-44_debian_xserver.templates.gz shared/ntp/localclock ./main/n/ntp/ntp_1:4.1.1b
Re: templates partagés de debconf
On Sun, Jul 27, 2003 at 09:38:04AM +0200, Christian Perrier wrote: Ils sont où ces templates debconf partagés (shared/) ? [...] Dupliqués dans chaque paquet. C'est le texte du dernier paquet installé qui reste, les autres sont écrasés. Denis
Re: templates partagés de debconf
On Sun, Jul 27, 2003 at 08:08:21PM +0200, Christian Perrier wrote: Quoting Denis Barbier ([EMAIL PROTECTED]): On Sun, Jul 27, 2003 at 09:38:04AM +0200, Christian Perrier wrote: Ils sont où ces templates debconf partagés (shared/) ? [...] Dupliqués dans chaque paquet. C'est le texte du dernier paquet installé qui reste, les autres sont écrasés. Et qui les coordonne ? Personne. Je trouve cela un peu bizarre, voire crade quand même.. :-) Bien sûr, mais cela concerne vraiment très peu de fichiers. Il ne semble pas évident de fournir une solution vraiment satisfaisante, donc on se contente de celle-là pour l'instant. Je les aurais bien vu dans debconf lui-même en fait. Tu sais s'il y a une raison particulière pour que cela ne soit pas le cas ? Il faudrait relire « la cathédrale et le bazar » ;) Denis
Re: quel nom pour une locale fr_geek ?
On Mon, Jul 21, 2003 at 09:55:46AM +0200, Mike Hommey wrote: On Monday 21 July 2003 01:27, Lucas Moulin wrote: On ven, jui 11 21:02 Alain Tesio [EMAIL PROTECTED] wrote : [...] Et d'abord comment on traduit geek ? Bon, je réponds longtemps après, mais je ne peux pas résister : dans le film Antitrust (je vous l'accorde, ce n'est pas un monument du 7ème art), le mot geek est traduit par cybarge. Grandiose, n'est-ce pas ? C'est d'autant plus con que le qualificatif geek n'est pas réservé à l'informatique... exemple: les trekkies (vous savez, les fous qui aiment star trek) sont des geeks... Et donc un mot qui peut avoir plusieurs sens ne doit pas être traduit. Grandiose, comme raisonnement. Denis
Re: quel nom pour une locale fr_geek ?
On Fri, Jul 11, 2003 at 07:34:22AM +0200, Cyrille Chepelov wrote: [...] naïfet, euh, quel mal y a-t-il à avoir fr_CA fournissant ici et là un simple additif/correctif à fr_FR, un peu à la manière d'en_GB (qui typiquement ne traduit que 2 à 3% de C, bien que ça ne soit pas rigoureusement correct) ? (bon, je file lire la FAQ) [...] Le problème est que tu n'as alors aucun moyen de savoir si le fichier doit être mis à jour ou non. Nous, quand on a un fichier 100%, on sait qu'il a besoin d'être mis à jour. Les en_GB.po que j'ai piochés sur http://www.debian.org/intl/l10n/po/en_GB sont souvent très vieux, mais on ne sait pas si le fichier n'a pas été mis à jour depuis longtemps, ou s'il n'en a pas besoin. Tu devrais demander aux traducteurs d'en_GB comment ils travaillent. Mais même s'ils arrivent à s'en sortir, ce que tu veux faire est plus compliqué, car eux se basent sur la v.o., alors que tu veux modifier une version traduite, ce qui doit certainement compliquer les choses. Denis
Re: quel nom pour une locale fr_geek ?
On Thu, Jul 10, 2003 at 10:27:03AM +0200, Martin Quinson wrote: On Tue, Jul 08, 2003 at 09:23:03PM +0200, Denis Barbier wrote: Mais l'initiative me semble débile, il y aura des geeks pour te demander de remplacer pilote par driver, bibliothèque par librairie, navigateur par browser, etc. M'enfin, ca me tue, ca. Pourquoi ca serait debile ? L'idee n'est ni de se mettre en concurence des traducteurs classiques, ni d'imposer ses vues, mais de faire causer jargon a sa becane ? Si y'a des gens qui le veulent et le font, pourquoi on les empecherait ? Y'a bien des gens pour traduire KDE en klingon, la langue des aliens dans Star Trek[1]. Si tu avais laissé le début du message, il aurait été difficile de me faire ce procès d'intention. Par contre, va falloir se mettre d'accord pour se repartir la tache, et que les efforts ne se marchent pas sur les lacets. Par exemple, je trouve qu'un document donne ne devrait etre traduit en [EMAIL PROTECTED] que s'il est deja traduit en fr_FR, histoire d'etre sur que les non geek ne seront jamais confrontes au jargon geek... Relis le message auquel je répondais : L'idée n'est évidemment pas de faire concurrence à fr_FR, mais juste de la compléter là où c'est vraiment trop moche Donc en clair : ne pas traduire, mais remplacer certains mots par leurs originaux. C'est une des raisons pour lesquelles je trouvais que c'est débile, tu ne peux pas monter une équipe de gens intéressés à faire la chasse aux mots blacklistés, ça va vite les lasser d'envoyer des corrections aux upstreams dès que la version française change. Il faudrait déjà que ces personnes soient d'accord sur la liste de mots à interdire, ce qui me semble improbable. Pour arriver au résultat, il est beaucoup plus simple de filtrer ces mots avec msgunfmt|msgfilter|msgfmt sur la machine, sans chercher à diffuser la version modifiée. Denis
Re: quel nom pour une locale fr_geek ?
On Tue, Jul 08, 2003 at 11:34:44AM +0200, Cyrille Chepelov wrote: [...] L'idée n'est évidemment pas de faire concurrence à fr_FR, mais juste de la compléter là où c'est vraiment trop moche (je pense à simplement la regénérer à partir de fr_FR en appliquant quelques règles sed, de type s/mél/mail/ et s/cédérom/CD-ROM/ ). [EMAIL PROTECTED] ? Tu voulais dire [EMAIL PROTECTED] Comme tu ne vas modifier que LC_MESSAGES, ce n'est je pense pas la peine d'indiquer un codage, la conversion se fera automatiquement d'après ta variable $LC_CTYPE. Et donc utilise plutôt [EMAIL PROTECTED] Mais l'initiative me semble débile, il y aura des geeks pour te demander de remplacer pilote par driver, bibliothèque par librairie, navigateur par browser, etc. Denis
Re: NMU (was : )Re: po-debconf de configure-debian)
On Thu, Jul 03, 2003 at 09:14:34AM +0200, Christian Perrier wrote: (désolé, j'aurais du changer le sujet plus tôt) Quoting Mathieu Roy ([EMAIL PROTECTED]): De toute façon, les docs à ce propos sont assez claires (pas de NMU pour des bugs mineurs, pas de NMU sans avoir contacté le mainteneur, pas de NMU sans respecter un délai). Je cherche encore où les docs sont claires sur le fait qu'il ne faut pas faire de mise à jour indépendante (NMU) pour des bogues mineurs. Voilà l'URL qu'il te faut ;) http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01996.html Denis
Re: po-debconf de configure-debian
On Wed, Jul 02, 2003 at 04:40:21PM +0200, Julien BLACHE wrote: Christian Perrier [EMAIL PROTECTED] wrote: C'est une évidence. Mais j'ai bien peur que, quoi qu'on écrive, la réaction du mainteneur à un NMU puisse être courroucée.. :-). Certains mainteneurs du moins. Surtout si c'est pour un truc aussi important que des fichiers mal nommés dans debian/po. Là je comprends que le mainteneur puisse avoir une furieuse envie d'étrangler l'auteur du NMU... Peux-tu expliquer en quoi renommer un fichier dans debian/po pose problème ? Denis
Re: Dépendance debconf dans le champ Build-Depends
On Thu, Jun 26, 2003 at 08:58:51PM +0200, Michel Grentzinger wrote: Bonjour, Bonjour, Dans le paquet source de webmin, on trouve la ligne suivante Source: webmin Section: admin Priority: optional Build-Depends-Indep: debhelper (= 3.0.0-1), debconf, perl Or pour tous les paquets que j'essaie de faire passer à po-debconf, je n'ai pas encore rencontré la dépendance debconf dans le champ « Buil-Depends ». Alors pour webmin, est-ce un bug ? Oui, il s'agit de debconf-utils. Ce problème n'est pas visible car debhelper = 3.0.9 dépend de debconf-utils. Denis
Re: debconf à tous les étages
On Tue, May 27, 2003 at 10:01:04AM +0200, sferriol wrote: bonjour, je viens de mettre à jour mes paquets debian, et il y en a un (fam ) qui m'affiche directement sur le terminal sans passer par debconf: Installation de la nouvelle version du fichier de configuration /etc/fam.conf ... [...] Quelle version ? En regardant les sources de la 2.6.10-1, je ne vois rien qui corresponde à ce que tu décri(e)s. Denis
Re: Priorité des questions debconf
On Wed, May 21, 2003 at 07:45:39AM +0200, Christian Perrier wrote: Existe-t-il quelque part des recommendations aux mainteneurs pour les priorités des questions debconf ? Je voudrais revoir celles de mon paquet geneweb (pour les diminuer) mais je voudrais auparavant vérifier si des recommendations générales existent. PS : rien vu dans debconf-doc Dans debconf-devel(7) Denis
Re: Signature de cle GPG
On Sun, May 18, 2003 at 03:54:02AM +0200, Eric Heintzmann wrote: Bonjour a tous, Je ne sais pas trop si c est le bon endroit pour poster ce message mais je n en vois pas d autre. Voila je cherche un developpeur Debian pour signer ma cle GPG. Et je cherche cet animal rare dans la region toulousaine de preference. Vous l aurez compris, il s agit pour moi de presenter ma candidature pour devenir developpeur Debian. J ai deja un paquet, un sponsor en la personne de Matthias Klose,j ai lu toutes les doc requises (et plus), il ne me manque plus qu une cle signee. Salut, j'emménage à Toulouse dans 2 semaines. Si ta clé n'est toujours pas signée, tu n'auras qu'à me contacter. Denis
Re: demandes d'infos
On Mon, May 12, 2003 at 10:02:12AM +0200, Patrice Karatchentzeff wrote: Denis Barbier écrivait : [...] Heu, d'après nm.debian.org, tu en es à la phase « Id Check ». A priori ton AM est en attente de données de ta part, non ? Déjà qu'il a été d'une lenteur fulgurante pour Pierre, si en plus il n'a pas les infos nécessaires, c'est clair que ta situation n'évoluera pas. Le père Joeye a tout en sa possession... Je ne vois pas trop ce que je peux faire de plus... Dans cette phase, tu dois envoyer ta clé GPG signée par un développeur Debian à ton AM, qui est hmh. Je ne comprends pas ce que vient faire ce Joeye (qui n'existe pas, tu parles de Martin Schulze ?) dans l'histoire. Denis
Re: demandes d'infos
On Mon, May 12, 2003 at 12:18:41PM +0200, Patrice Karatchentzeff wrote: [...] typo : c'est Joerg. Mais c'est lui ton AM ? Si oui, il faut le relancer pour savoir ce qu'il fout, et demander de l'aide s'il ne répond pas. Et pourquoi hmh est marqué comme étant ton AM sur nm.debian.org ? Denis
Re: debconf-show chaud!!
On Tue, Apr 29, 2003 at 06:01:25PM +0200, sferriol wrote: [...] Mon gros problème est de savoir quelles réponses sont spécifiques à une machine (liées au hardware) et celles qui peuvent être exportées sur LDAP comment faire C'est impossible. AMA le plus simple est que tu notes le paquet quand tu tombes sur un de ces cas particuliers, il ne doit pas y en avoir beaucoup. Denis
Re: Résumé des discussions au sujet de debconf sur debian-devel
On Sun, Apr 27, 2003 at 08:41:16AM +0200, Christian Perrier wrote: [...] Du coup, dès qu'une nouvelle langue est ajoutée, bing.toutes les traductions deviennent fuzzy. Pas nécessairement, tu peux regarder ce que j'avais fait avec languagechooser (mais les nouvelles versions ont été complètement remaniées), en utilisant __Choices au lieu de _Choices. Cette syntaxe est expliquée dans po-debconf(7), section « New master templates ». On pourrait donc peut-être imaginer une entrée spécifique dans le fichier templates que po-debconf traiterait de manière particulière : _LangChoices: Afrikaans, Bulgarian, Catalan, Chinese, Czech, Danish, Dutch, English, Esperanto, Estonian, Finnish, French, German, Hebrew, Icelandic, Italian, Latvian, Norwegian, Polish, Portuguese, Romanian, Russian, Spanish, Swedish Dans ce cas précis, quand on utiliserait debconf-updatepo, les champs Choices seraient automatiquement mis à jour A part modifier des scripts de po-debconf, cela n'imposerait qu'une chose de plus : rendre celui-ci dépendant de iso-codes L'idée est intéressante, mais le nombre de paquets concerné est très faible, je ne sais pas si ça vaut le coup d'ajouter cette dépendance. Denis
Re: Résumé des discussions au sujet de debconf sur debian-devel
On Wed, Apr 23, 2003 at 05:59:13PM +0200, Christian Perrier wrote: [...] Finalement, j'ai du mal à savoir si je fais bien ou pas d'utiliser debconf pour faire choisir la langue utilisée par défaut dans geneweb...:-) Un gros avantage de debconf, qui n'a pas été mis en avant dans la discussion, est qu'il permet la configuration dans la langue de l'utilisateur. Probablement pas depuis la façon dont je le fais...puisque je ne réinjecte pas dans la BDD debconf la valeur éventuellement modifiée par l'administrateur local et stockée dans /etc/default/geneweb, avant de faire demander à debconf la valeur souhaitée. Tu as certainement raison, regarde l'exemple dans debconf-devel(7), c'est facile à comprendre. Si ton fichier /etc/default/geneweb existe, tu le parses pour en extraire la valeur sélectionnée, que tu réinjectes dans la BDD debconf. Denis
Re: Résumé des discussions au sujet de debconf sur debian-devel
On Wed, Apr 23, 2003 at 09:32:14AM +0200, Jérôme Marant wrote: En réponse à Denis Barbier [EMAIL PROTECTED]: Bonjour, Salut, les discussions de ce week-end sur debconf ont été intéressantes, mais noyées dans un flot d'insultes (étonnant, non ?). Je me permets d'en fournir un résumé, mais je ne prétends pas avoir tout compris, donc n'hésitez pas à rectifier. Merci pour ton résumé. C'est à peu près ce que j'avais compris. De surcroît, Joey rouspète car il considère qu'il y a un abus dans l'utilisation des notes Debconf ; il considère que ces informations devraient se trouver dans le fichier README.Debian. Exact. Dans mon précédent message, j'ai oublié d'indiquer que si le paquet contient une question du genre « Manage foobar with debconf ? », il faut alors vérifier qu'il ne s'agit pas d'un abus de debconf. Personnellement, je ne vois pas vraiment la bonne et la mauvaise utilisation des notes. Dans le paquet sympa, je l'utilisais en guise d'introduction à la configuration debconf qui allait suivre. Ça me semble tout à fait légitime dans ce cas, tu fournis des explications sur la suite de la procédure. Par contre, j'ai utilisé une note dans icewm pour indiquer que l'organisation du paquet avait changé mais j'ai mis ça aussi dans le README.Debian. Je ne sais pas si je fais un abus dans ce cas-là. A ton avis ? AMA c'est exactement l'usage que dénonce Joey ;) Denis
Re: Résumé des discussions au sujet de debconf sur debian-devel
On Wed, Apr 23, 2003 at 11:41:57AM +0200, Jérôme Marant wrote: En réponse à Denis Barbier [EMAIL PROTECTED]: Par contre, j'ai utilisé une note dans icewm pour indiquer que l'organisation du paquet avait changé mais j'ai mis ça aussi dans le README.Debian. Je ne sais pas si je fais un abus dans ce cas-là. A ton avis ? AMA c'est exactement l'usage que dénonce Joey ;) J'imagine. Ceci dit, je pense que ça peut servir à éviter pas mal de bugs reports inutiles des utilisateurs [...] Mais justement, debconf n'est pas fait pour pallier à ce problème. Détourner un système de son but original pour éliminer un problème ailleurs, c'est pourtant une pratique que tu réprouves fortement d'habitude ;) Denis
Résumé des discussions au sujet de debconf sur debian-devel
Bonjour, les discussions de ce week-end sur debconf ont été intéressantes, mais noyées dans un flot d'insultes (étonnant, non ?). Je me permets d'en fournir un résumé, mais je ne prétends pas avoir tout compris, donc n'hésitez pas à rectifier. Les responsables de paquets font deux erreurs récurrentes dans l'utilisation de debconf : a) ils stockent des données permettant de générer la configuration de leur paquet dans la base de données debconf ; b) les changements faits par l'administrateur peuvent être perdus, s'il a donné carte blanche au paquet pour gérer la config à sa place, et modifié ensuite les fichiers de configuration. (a) est appelé le syndrome du « debconf is not a registry », et les raisons pour lesquelles ceci pose problème sont données par Steve Langasek dans http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01340.html La bonne façon de faire consiste, lorsque le fichier de configuration existe, à en extraire les informations utiles et remplir la base de données debconf avec ces valeurs avant de poser les questions. (b) est de façon triviale une violation de la charte, section 11.7.3. Comme dpkg pose le même genre de questions (« Voulez-vous garder votre fichier modifié ou installer celui fourni par le paquet ? »), des responsables de paquets se sont crus autorisés à faire de même avec debconf. Mais il existe une différence de taille, expliquée par Manoj Srivastava dans http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01590.html En effet, dpkg pose la question lors de chaque écrasement éventuel de fichier. Avec debconf, la question est posée une seule fois, puis les versions d'après se permettent d'écraser le fichier de configuration, sans donner la possibilité à l'utilisateur (qui a oublié deouis belle lurette qu'il a donné carte blanche au paquet pour écraser ses changements) ; ceci n'est pas acceptable. Manoj Srivastava fournit dans le paquet ucf un outil qui permet d'émuler le comportement de dpkg. Enfin, un exemple complet de fichiers config et postinst pour gérer les fichiers de configuration est fourni dans debconf-devel(7) dans la section « Advanced programing with debconf ». HTH Denis
Re: Dépendances superflues
On Thu, Apr 17, 2003 at 10:38:25PM +0200, Arnaud LACOMBE wrote: Bonour, J'envoie un message ici espérant avoir une réponse que je n'ai pas eut sur DUF; mon problème est le suivant: $ apt-cache show docbook-utils [...] Depends: lynx, sp, sgmlspl, jadetex, docbook-dsssl, perl [...] docbook2txt a besoin de lynx (et lynx|links en sid). $ apt-cache show discover [...] Depends: libc6 (= 2.2.4-4), libdiscover1, ash ^^^ [...] La réponse se trouve dans #146907, que l'on trouve facilement en cherchant ash dans les bogues archivés de discover. Denis
Re: [VAC] 14 au 19 avril sur Paris. Keysigning ?
On Tue, Apr 15, 2003 at 11:00:19AM +0200, Loic Bernable wrote: Selon Benjamin Drieu : Puisque je serais en vacances je peux y être à partir de 17h et y rester jusqu'à épuisement/trop faim/fermeture/etc. C'est déjà ouvert à 17h ? Aucune idée. Perso, je ne pourrai passer avant 19h (y'en a qui bossent ;-)). Pareil que Benj ;o) Je pense pouvoir passer vers les 19 heures. À condition bien évidemment que vous acceptiez les larves non DD ... ++ et à demain ;o) Et pour ce soir, il y a des amateurs ? Je peux passer à partir de 18 heures. Denis
Re: Charte Debian : version 3.5.9.0 cvs 1.105
On Wed, Mar 12, 2003 at 10:07:12AM +0100, Philippe Batailler wrote: Salut, Voici la dernière version de la charte Debian, 3.5.9.0. En français. On peut trouver une version ps et html sur http://www.teaser.fr/~pbatailler/ Mais un récent message sur debian-policy m'interroge. Des italiens qui avaient commencé une traduction de ce texte demandent sur debian-policy si cette traduction serait utile. La réponse semble être que c'est une perte de temps. Perte de temps ou non, pour les développeurs français ? Pour les développeurs Debian, l'intérêt semble en effet limité. Mais on peut se poser des questions sur le packaging sans être développeur Debian ni maîtriser l'anglais, donc c'est bien d'en avoir une traduction. Denis
Re: Suivi par CVS d'un paquet utilisant dbs ?
On Tue, Aug 20, 2002 at 11:48:00PM +0200, Christian Marillat wrote: [...] b) la règle énoncée en C.3 est complètement débile, puisqu'elle oblige le tarball à être désarchivé dans un répertoire package-upstream-version.orig et il ne peut donc pas s'agir du tarball original. Cela n'empeche pas que les tarballs fait pour dbs sont pourris surtout quand un paquet comme gconf2 n'utilise pas de patche. Être obligé d'aller sur un mirroir debian pour récupéré un source n'est pas acceptable. Ça, c'est un point intéressant, mais tant que le paquet source peut être traité par dpkg-source de la version unstable (c'est même pas grave si celui de stable n'y arrive pas), personne n'y trouve malheureusement rien à redire. Il vaut mieux être autobuilder que simple développeur, on a droit à plus de considération ;) Denis
Re: Suivi par CVS d'un paquet utilisant dbs ?
On Tue, Aug 20, 2002 at 07:35:32PM +0200, Christian Marillat wrote: [EMAIL PROTECTED] (Jérôme Marant) writes: Thomas Parmelan [EMAIL PROTECTED] writes: [...] Je maintiens des modifications locales d'un paquet utilisant DBS. Avec ce système, le paquet source contient le tar.gz upstream et un ensemble de patches : il me suffit d'y ajouter le mien. C'est très pratique. À mon sens, DBS n'est bien que s'il y a plusieurs tarball upstream. Et au passage dbs ne respecte pas la charte Debian. Il est impossible de construire un paquet Debian à partir du source upstream. Heu, les autobuilders y arrivent bien, je ne comprends pas ce que tu veux dire. Denis
Re: Suivi par CVS d'un paquet utilisant dbs ?
On Tue, Aug 20, 2002 at 09:57:53PM +0200, Christian Marillat wrote: [EMAIL PROTECTED] (Denis Barbier) writes: On Tue, Aug 20, 2002 at 07:35:32PM +0200, Christian Marillat wrote: [EMAIL PROTECTED] (Jérôme Marant) writes: [...] Et au passage dbs ne respecte pas la charte Debian. Il est impossible de construire un paquet Debian à partir du source upstream. Heu, les autobuilders y arrivent bien, je ne comprends pas ce que tu veux dire. Tu prends le tarball chez l'auteur (gconf 2 par exemple, j'ai rencontré le problème hier), tu untar le tarball tu applique le diff Debian et tu essayes de faire le paquet. Ça ne marche pas. Avec dbs le tarball original est dans le orig.tar.gz Debian sous forme de tarball. Si ce n'est pas bien clair ce que je dis, vas voir le paquet gconf2. Mais rien dans la policy ne dit que le .orig.tar.gz est forcément un tarball fourni par l'upstream. C'est exactement comme pour les paquets basés sur une version CVS, dont aucun tarball n'existe. La policy dit juste que cette archive contient les sources upstream non modifiées, ce qui est bien respecté. Denis
Re: [2002-07-20] Release Status Update
On Sat, Jul 20, 2002 at 08:09:16AM +1000, Anthony Towns wrote: [...] Normally I'd expect to be running through a list of people like the port maintainers or the boot-floppy hackers or the CD people here, but in a shocking turn of events, they all pretty much took care of themselves. People like Adam Di Carlo and Philip Hands can get a token mention anyway, though. Check the changelogs for the full details. Thanks, y'all. [...] Je ne suis pas sûr de comprendre ce qu'a voulu dire le gusse, quelqu'un peut me traduire sa pensée ? Il y a quelques mois, il a demandé aux développeurs des boot-floppies de continuer à travailler après la sortie de woody, pour être prêt si le nouvel installeur ne tient pas ses promesses. Il croit peut-être que ce genre d'annonce va les motiver ? Et où sont les changelogs dont il parle ? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [2002-07-20] Release Status Update
On Sat, Jul 20, 2002 at 04:52:37PM +0200, Raphael Hertzog wrote: Le Sat, Jul 20, 2002 at 04:19:56PM +0200, Denis Barbier écrivait: Normally I'd expect to be running through a list of people like the port maintainers or the boot-floppy hackers or the CD people here, but in a shocking turn of events, they all pretty much took care of themselves. People like Adam Di Carlo and Philip Hands can get a token mention anyway, though. Check the changelogs for the full details. Thanks, y'all. Je ne suis pas sûr de comprendre ce qu'a voulu dire le gusse, quelqu'un peut me traduire sa pensée ? Il y a quelques mois, il a demandé aux Je ne comprends pas ce qui te choque ... ma compréhension du truc c'est qu'il dit je devrais féliciter tout le monde en les citant mais ils se sont tous fait connaitre par eux meme donc ce n'est pas la peine. Ok, j'avais effectivement compris de travers, quelque chose comme « ils se sont occupés d'eux-mêmes [au lieu de se préoccuper de la release] ». Merci de l'explication. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [2002-07-20] Release Status Update
On Sat, Jul 20, 2002 at 04:52:37PM +0200, Raphael Hertzog wrote: [...] Explique moi comment tu interprètes son message pour te mettre dans un tel état ? J'avais les chakras tout fermés quand j'ai lu son message : étant sur irc au moment de l'annonce, j'ai eu l'impression que James Troup et les webmasters n'étaient pas prévenus, et du coup les sites web et ftp ne pouvaient pas être mis à jour correctement. D'ailleurs ftp://ftp.debian.org/debian/doc/ pointe toujours sur la patate. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Woody, Euro, fr et moi...
On Fri, Jul 19, 2002 at 09:04:36AM +0200, Patrice Karatchentzeff wrote: [...] Par contre, plus ou moins chiant, Perl n'aime pas non plus... donc debconf et compagnie : j'ai le sempiternel message d'erreur de locales non supportées par Perl et repositionnées à C par défaut. [...] Donne le message d'erreur, ainsi que le contenu de /etc/locale.gen Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Woody, Euro, fr et moi...
On Fri, Jul 19, 2002 at 06:26:41PM +0200, Patrice Karatchentzeff wrote: [...] perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = , LANG = fr_FR.ISO-8859-1 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). # cat /etc/environment [EMAIL PROTECTED] # cat /etc/locale.gen [EMAIL PROTECTED] ISO-8859-15 Je l'ai en effet obtenu via dpkg-reconfigure locales ; Dois-je utiliser plutôt UTF-8 ? Deux trucs bizarres dans le message d'erreur : - LC_CTYPE= indique que LC_CTYPE a été positionné à une valeur vide - le codage associé à LANG est ISO-8859-1 et non ISO-8859-15 Tes variables d'environnement sont donc changées par autre chose que /etc/environment (peut-être gdm, justement ? Il y a plusieurs bogues liés aux locales sur http://bugs.debian.org/gdm). Pour Perl, tu peux corriger le problème avec 'dpkg-reconfigure locales' en sélectionnant 'fr_FR ISO-8859-1'. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fichiers Packages et l10n
On Tue, Jun 18, 2002 at 09:05:35PM +0200, Martin Quinson wrote: Y'a eu du neuf sur la liste debian-dpkg à ce sujet (ie, adam et wichert en disent enfin un peu plus). Pour ceux que ca interresse, le fil de discussion commence ici : http://lists.debian.org/debian-dpkg/2002/debian-dpkg-200206/msg00069.html Ok, merci pour l'info. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fichiers Packages et l10n
[...] Je pense que tout ceci est une idée assez raisonnable. Personnellement, j'appelle ca des atomes (au sens etymologique de non secable). Et c'est une vieille idée, il me semble qu'on en trouve les premieres références sur -devel en 99. L'idée, c'est que les metapaquets font des groupes de paquets, et les atomes sont des parties de paquets installables indépendaments par dpkg. Ok, je vois ce que tu veux dire, et vais regarder dans les arcanes de dpkg si quelque chose est en cours. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rétroportage de wmaker 0.80
On Thu, Mar 28, 2002 at 11:12:52AM +0100, Patrice Karatchentzeff wrote: Salut, Je suis en train de rétroporter wmaker 0.80 et après avoir rétroporter tout ce qui me manquait, la compilation de wmaker merdoit quand même : touch patch-wmaker-stamp aclocal libtoolize --force --copy --automake automake configure.in: 20: required file `./ltconfig' not found make: *** [Makefile.in] Error 1 Je ne vois rien de la sorte dans le configure.in :-( Une idée ? Quelle version de libtool ? Avec celle de Potato (1.3.3-9.1), la commande libtoolize crée ce ltconfig. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rétroportage de wmaker 0.80
On Thu, Mar 28, 2002 at 03:15:06PM +0100, Patrice Karatchentzeff wrote: [...] Quelle version de libtool ? Avec celle de Potato (1.3.3-9.1), la commande libtoolize crée ce ltconfig. Bon, j'ai parlé trop vite : j'ai le même résultat avec le libtool de testing. Heu, et qu'est ce qui merde avec la patate ? Sur la mienne, ça semble marcher. [...] Quelque chose m'échappe... Il est possible qu'il y ait un problème de compatibilité de version automake/libtool, il me semble avoir vu des messages en ce sens sur la ML automake. Si c'est le cas, tu peux aussi upgrader automake, mais alors il faudra peut-être aussi upgrader autoconf. Bref, que du bonheur :) Si j'avais à faire ce bordel, je crois que je mettrai dans un coin les versions de libtool/automake/autoconf de potato, dans un autre celles de woody ou sid, et prendraient celles qui donnent satisfaction. Faire un mélange n'est pas vraiment conseillé. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tk et gettext
On Wed, Mar 20, 2002 at 11:28:00AM +0100, Patrice Karatchentzeff wrote:
[...]
donc quand on emploie print (la fonction de Perl), il n'y a pas de
« = ». Par contre, il n'y a rien sur un autre type de
construction. Comment i18nisons les exemples suivants :
$print = C'est pas si simple l'i18n\n
$print = gettext(C'est pas si simple l'i18n\n)
ou
$print = gettext(C'est pas si simple l'i18n).\n
et
%NoteBook =
(
connection = [COnnection, Connexion, 0],
mail = [Mail, Courriel, 1],
log= [Log,Journaux de bord, 0],
)
%NoteBook =
(
connection = [COnnection, gettext(Connexion), 0],
mail = [Mail, gettext(Courriel), 1],
log= [Log,gettext(Journaux de bord), 0],
)
et
$toto = $top - Button
(
-text= joli bouton,
-command = \{kill_button},
);
$toto = $top - Button
(
-text= gettext(joli bouton),
-command = \{kill_button},
);
Denis
Re: Tk et gettext
On Mon, Mar 18, 2002 at 02:19:04PM +0100, Patrice Karatchentzeff wrote: [...] Sauf que... le programme qui fonctionnait *avant* ne fonctionne plus *maintenant*. Il s'arrête en me disant qu'il ne trouve plus un sous-programme qui existe bien quelques lignes plus bas. Je n'ai aucune indication (avec le -w) d'un malaise de Perl sur l'i18n des fichiers. [...] Tu peux le mettre en ligne ? Denis
FS vs. OS (was Re: [BREVET LOGICIEL] Questionnaire : quel acteur du libre etes vous)
On Fri, Mar 08, 2002 at 01:55:29PM +0100, [EMAIL PROTECTED] wrote: [...] Il faut distinguer les programmes libres copyleftés (les termes de distribution du programme garantissent leur non modification) et non copyleftés (les termes de distribution peuvent évoluer sans l'aval de l'auteur ... en mal par exemple), mais les deux catégories de programmes tombent sous la définition du logiciel libre par la FSF et de l'OpenSource par l'OSI. Nicolas essaie de comprendre les différences entre Free Software et Open Source. Tu lui dis de distinguer les programmes libres copyleftés et non copyleftés, et dans le même temps que les deux catégories de programmes tombent sous la définition du logiciel libre par la FSF et de l'OpenSource par l'OSI. Alors, pourquoi faire cette distinction ? Denis
Re: [PKG] fakeroot et X
On Tue, Feb 26, 2002 at 11:25:47AM +0100, Aurelien Jarno wrote: [...] Il est requis par le fait que le script ./configure interroge un programme X avec l'option --version pour vérifier que la version du programme est bien compatible avec la librairie. Si l'affichage du numéro de version se fait dans le terminal, il est idiot de se connecter au serveur X pour rien, c'est l'application qui est mal écrite. Denis
Debian/FSF again
Marcus Brinkmann donne des informations intéressantes sur quelques démangeaisons de la FSF pour faire sa distro « pure ». C'est sur http://lists.debian.org/debian-legal/2002/debian-legal-200201/msg00301.html mais malheureusement noyé dans d'autres discussions. Je ne suis pas sûr que la discussion reste intelligente très longtemps, je n'ai pas pu m'empêcher de poster ;o) Denis
Re: Cahier de doléances pour Debian, version
On Fri, Jan 25, 2002 at 08:47:11AM +0100, Jean-Christophe Dubacq wrote: [...] Ma seule proposition: créer une unité d'internationalisation, habilitée à faire des NMU plus facilement, à la fois sur les paquets gérant cette internationalisation (par exemple j'ai soumis un gros patch pour localeconf, j'ai même fabriqué le paquet, mais il n'a pas été corrigé, et il est d'un non-pratique achevé actuellement). Salut, je vois 4 possibilités : a) Avoir un comité i18n identique au comité technique, qui pourrait imposer certaines décisions ayant trait à l'i18n quand le développeur bloque. Problème : il pourrait y avoir conflit avec les prérogatives du comité technique. b) Avoir un team i18n comme security, habilité à faire des NMU. C'est embêtant, parce que l'équipe sécurité n'intervient que sur la version stable, alors que là, les NMU se feraient sur la version unstable. c) Avoir un interlocuteur i18n désigné au sein du comité technique. Ça me semble être une bonne solution, mais je ne sais pas si c'est réalisable. d) Favoriser une nouvelle sorte de NMU, avec des règles moins strictes sur les délais, mais dont les changements ne touchent que des traductions. Cela ne concerne donc que la l10n et pas l'i18n. Dans certains cas, il me semble qu'un changement de la Constitution est nécessaire, il faut donc le préparer soigneusement. Denis
Re: Debian goes international ?
On Fri, Jan 25, 2002 at 03:07:40PM +0100, Raphael Hertzog wrote: [...] Bien sûr, la solution à ce problème est naïve, il suffit de tester la validité du fichier po avec les outils appropriés. Mais seuls les gens qui s'interessent à l10n et i18n le savent, il n'y a rien à ce sujet dans la charte (ce que les anglais noment « policy »). Il y a peut-être des efforts à faire sur la documentation du travail de traducteur et sur les outils dont il peut disposer. Mais je ne pense pas que cela ait sa place dans la Debian Policy. L'i18n est la 3e roue du carrosse, si on la prenait en compte dès le départ, le boulot des traducteurs s'en trouverait facilité. Par exemple, le projet KDE a repensé son système de documentation pour faciliter les traductions, si bien qu'ils sont champions du monde en la matière. Comme nombre de développeurs n'en ont rien à foutre, il faudra bien trouver un moyen pour leur botter le cul si on veut que l'i18n avance chez Debian. Denis
Re: Cahier de doléances pour Debian, version devel
[Raphael Hertzog blah blah blah] Salut, 1) Communication interne Pour montrer que tu veux mettre en place une meilleure communication entre développeurs, tu peux capitaliser sur le PTS. Il me semble que tu avais lancé l'idée des backup maintainers, il faudrait la relancer. Pour ceux qui n'avaient pas suivi, les backup maintainers sont des responsables « de secours », capables d'intervenir si le responsable le demande ou est indisponible. Ma vision est que chaque paquet doit avoir un nombre minimal de backup maintainers, ce nombre variant en fonction de l'importance du paquet (dépendant par exemple de sa priorité). Quand le nombre de backup maintainers descend en-dessous du seuil, le paquet est rétrogradé. Avantages : on ne devrait pas avoir de paquets importants non maintenus, les bogues devraient être corrigés plus vite, le responsable et les backup maintainers pourraient discuter de solutions techniques. Pour ce dernier point, c'est ce qui se passe sur les ML dédiées à certains paquets, et je trouve que ça marche bien. Problèmes : certains développeurs sont viscéralement contre, et ont indiqué qu'ils se porteraient backup maintainers à tout va. Ce n'est pas un problème, quand on met en place des procédures pour améliorer la communication, on ne s'adresse pas aux autistes, mais à ceux qui sont susceptibles d'en faire bon usage. Donc même si dans un premier temps certains paquets resteront à l'abandon, les développeurs qui aiment échanger des points de vue vont apprécier la procédure. 2) Communication externe Ces dernières semaines, Debian a été cité : - en bien pour le lancement de diverses projets (BSD, Med) - en mal pour des problèmes liés à la sécurité Pour ce dernier point, je n'ai pas d'avis sur la question, et demanderais naïvement à Joey son avis sur la question. Le leader devrait s'impliquer personnellement pour favoriser l'éclosion et le suivi des projets connexes, puisqu'ils donnent une bonne image de Debian. Il suffirait de quelques actions symboliques, comme faire l'annonce publique de la création du projet, pour montrer que ces projets sont une émanation de Debian. Dans le même ordre d'idée, il faudrait parler des autres distributions basées sur Debian (et même tisser des liens avec), comme Demolinux. Ce ne sont pas des projets concurrents, mais une vitrine de ce qu'on peut faire en se basant sur Debian. Denis
Re: Pb de backport
On Thu, Dec 20, 2001 at 11:36:35AM +0100, georges mariano wrote: [...] Est-ce que tu confirmes qu'il faut recompiler les modules Perl qu'on utilise ? Je n'ai pas compris ta réponse. [...] Je ne dirai donc pas il _faut_ recompiler les modules Perl. Je dirai simplement que dit apt-get -s install le-module-que-je-veux? Ensuite je décide en fonction de ma policy locale... Et les modules Perl qui étaient auparavant installés, est-ce qu'ils continuent de fonctionner ? Je pense que non, et c'est AMHA un point qu'il faut prendre en considération avant d'installer un backport de Perl sur sa machine. Il faut certainement réinstaller les modules, ainsi peut-être que certaines applications qui en dépendent. Bref, si je devais backporter un paquet qui dépend d'une version récente de debconf, je pense que je choisirai plutôt de virer la configuration via debconf et donc la dépendance, et ferai la configuration à la main. Denis
Re: STOP ! [Re: Pour GM]
On Fri, Nov 30, 2001 at 11:12:51AM +0100, georges mariano wrote: On Fri, 30 Nov 2001 10:51:46 +0100 Patrice Karatchentzeff [EMAIL PROTECTED] wrote: Je suis preneur : la synthèse ne sera que meilleure :-) Idem. J'ai toujours dis que, compte tenu de la connaissance (incomplète) que j'ai de ces autconfcie, je ne voyais pas de cas où les modifs sont nécessaires. Ce qui ne veut pas dire qu'il n'en existe pas ! Mais il faudra que je sois convaincu... (par rapport à une certaine démarche de l'utilistation Debian) J'en profite pour faire une petite digression, et revenir au cas évoqué par Denis (modif nécessaire pour localiser correctement les exemples de scigraphica). Malheureusement, techniquement je ne peux pas rejouer le truc mais dans ce genre de cas ne peut-on pas s'en sortir en plaçant le répertoire examples/ dans les fichiers qui contrôlent l'installation de docs et laisser faire l'install au bon endroit par les outils debian et virer les fichiers mal installés dans le répertoire temporaire ... i.e dans le répertoire temporaire de création du paquet une install mauvaise par le Makefile amont une install correcte par dh_installdocs (?) on vire la première on construit le paquet Oui, cette solution marche pour ce cas-là. De toute façon, tu peux toujours dire qu'il suffit de jouer avec sed après le configure pour modifier les Makefiles comme bon te semble, donc il n'existe pas de cas où le développeur n'a pas d'autre choix que modifier les Makefile.am. Mais entre corriger le problème à la source (arborescence d'installation différente pour l'upstream et Debian), et la rustine, je préfère la première solution. D'autre part, avec ta solution, le problème de numéro de version de DH_COMPAT serait plus emmerdant, puisqu'il influerait sur l'emplacement du répertoire temporaire (me semble-t'il). Denis
Re: exemple d'une cible get-orig-source
On Tue, Nov 27, 2001 at 01:26:10AM +0100, Nicolas Boos wrote: [...] Non, c'est une cible facultative. Il n'y en a qu'une description simple dans la charte, mais pas d'exemple. Il y est dit que c'est une bonne idée, d'où ma volonté d'étudier la chose en détail. Où est-ce que tu as appris/découvert l'existence d'une telle cible ? En relisant la charte (sérieusement, pas comme la première fois...). C'est bien-sûr dans la section 5.2. (et j'espère ne pas m'être trompé dans ma lecture). Voici une liste de paquets ayant cette règle dans leur fichier debian/rules : main a2ps 4.13b-11 main aleph 0.8.1-2 main am-utils 6.0.7-4 main bzip2 1.0.1-13 main cbb 0.8.1-4 main changetrack 3.6-4 main cracklib2 2.7-8.5 main csh 2003-1 main cvs2cl 2.38-1 main dbd-excel 0.05-1 main dotfile-doc 20010324-1 main finance-streamer 1.05-1 main freetds 0.52-3 main gretl 0.96-2 main gsl 1.0-1 main hesiod 3.0.2-9 main hp48cc 1.3-1 main inline-octave 0.10.cvs2007-1 main ipcheck 0.134-1 main libhdf4 4.1r4-13 main libipc-shareable-perl 0.60-2 main libpng 1.0.12-2 main math-numbercruncher 4.0-1 main mime-lite 2.117-1 main mt-st 0.6-5 main octave2.1 2.1.35-3 main ole-storage-lite 0.09-2 main quantlib 0.2.0-1 main quantlib-python 0.2.0-3 main r-recommended 1.3.1-3 main semidef-oct 2.2-1 main soap-lite 0.52-1 main spreadsheet-parseexcel 0.24.03-1 main spreadsheet-writeexcel 0.34-1 main utah-glx 0.0-cvs-20010702-2 main vipec 3.0.3-1 main vrweb 1.5-6.2 main wajig 0.2.8-2 main xwave 0.6+2-7 non-free satan 1.1.1a-2 non-free vrwave 0.9-10 Denis
Re: À lire (très court ;-)
On Tue, Nov 20, 2001 at 07:54:48PM +0100, Jérôme Marant wrote: Raphael Hertzog wrote: ... Je me demande bien ce qu'il cherche ... il veut reprendre son paquet emacs ? ;) J'ai peur que cela soit plus politique qu'autre chose ... plein de flames en perspectives. :-| Je pense aussi qu'il peut y avoir une raison politique. Cependant, il se trouve que RMS reprend la direction du projet Emacs à la place de Gert. Peut-être retourne t-il à la technique ? C'est normal, emacs est passé optional sans provoquer de lever de boucliers contre ce crime manifeste de lèse-majesté, il fallait remettre de l'ordre :o) Denis
Re: À lire (très court ;-)
On Tue, Nov 20, 2001 at 09:41:27PM +0100, Nicolas Boos wrote: Le 20 Nov 2001 21:00:30 +0100 [EMAIL PROTECTED] (Jérôme Marant) écrivait : Nicolas Boos [EMAIL PROTECTED] writes: Le 19 Nov 2001 21:42:06 +0100 [EMAIL PROTECTED] (Jérôme Marant) écrivait : L'url : http://www.debianplanet.org/debianplanet/article.php?sid=510mode=threadorder=0thold=0 Et Il manque un CC quelque part... (...) Il manque aussi des explications. Non, car je n'ai nullement l'intention de remettre de l'huile sur le feu. Et, comme a priori tu es dans cette classe du dernier tiers de la courbe de Gauss, tu ne devrais pas avoir besoin d'éclaircissements ; je pense que tout le monde avait bien saisit le sens de mon premier propos. C'est bien ici qu'on parle pour ne rien dire ? Denis, tout contrit de ne pas appartenir à l'élite dont se réclame Nicolas.
Re: À lire (très court ;-)
On Tue, Nov 20, 2001 at 11:50:22PM +0100, Nicolas Boos wrote: Le Tue, 20 Nov 2001 22:22:20 +0100 [EMAIL PROTECTED] (Denis Barbier) écrivait : [...] Non, car je n'ai nullement l'intention de remettre de l'huile sur le feu. Et, comme a priori tu es dans cette classe du dernier tiers de la courbe de Gauss, tu ne devrais pas avoir besoin d'éclaircissements ; je pense que tout le monde avait bien saisit le sens de mon premier propos. C'est bien ici qu'on parle pour ne rien dire ? Denis, tout contrit de ne pas appartenir à l'élite dont se réclame Nicolas. C'est toi qui me parles d'élite? Pourquoi, je n'en ai pas le droit ? Tes 2 messages étaient clairement élitistes, je me suis permis de te le faire remarquer. Bizarre, tu utilises contrit (adj. du vocabulaire courant bien-entendu...) ; En deux mois (j'ai vérifié...), sur ex. debian-french tu as 2 contributions, adressée à un futur?[1] développeur Debian... Je sais bien que les teen-users sont de moins en moins marrants, mais je doute fortement que ton silence contribue beaucoup à résoudre le problème... C'est un jeu où il faut mettre des mots à la place des points de suspension ? Bon je vais essayer, mais je ne suis pas très fort, si tu pouvais donner le sens caché de ces phrases, ça me ferait gagner du temps. Denis
Re: To be minimalist or not :-)
On Thu, Nov 15, 2001 at 01:16:57PM +0100, Patrice Karatchentzeff wrote: Le Thu, 15 Nov 2001 13:08:45 +0100, [EMAIL PROTECTED] écrivait : On Thu, Nov 15, 2001 at 12:35:23PM +0100, Patrice Karatchentzeff wrote: [...] En effet, lorsque l'on regarde un peu de plus près certains paquets, on s'aperçoit rapidement que les dépendances ne sont pas minimales. C'est là-dessus que je voudrai m'étendre un petit peu. [...] Je ne comprends pas ce concept de dépendance minimale, tu peux donner un exemple sur un cas concret ? Je n'ai pas d'exemple sous la main (faut que je voie cela ce soir chez moi). [...] Salut Patrice, tu en es où de tes cogitations, tu as réussi à faire un exemple sur lequel on peut discuter ? Denis
Re: À lire (très court ;-)
On Wed, Nov 21, 2001 at 01:17:25AM +0100, Nicolas Boos wrote: [...] Bizarre, tu utilises contrit (adj. du vocabulaire courant bien-entendu...) ; En deux mois (j'ai vérifié...), sur ex. debian-french tu as 2 contributions, adressée à un futur?[1] développeur Debian... Je sais bien que les teen-users sont de moins en moins marrants, mais je doute fortement que ton silence contribue beaucoup à résoudre le problème... C'est un jeu où il faut mettre des mots à la place des points de suspension ? Bon je vais essayer, mais je ne suis pas très fort, si tu pouvais donner le sens caché de ces phrases, ça me ferait gagner du temps. En général, les petits points, ça veut dire que c'est chez comme Maxwell(TM) (C) (R) ; pas besoin d'en rajouter... Ben justement, si je demande des explications, c'est qu'il me manque quelque chose pour comprendre. Mais, comme au jeu de l'humour, tu es très fort, c'est sûr (je suis plutôt un triste, il paraît), je vais arrêter les frais ici. Je suis un SALE ÉLITISTE-PÉDANT-ÉGOISTE qui-se- prend-pas-pour-de-la-merde. Il faut le savoir, c'est tout. Pfio, la prochaine fois je ferai semblant d'avoir compris. Denis
La policy et l'impossibilite de compiler les sources
Salut, afin de remplir un rapport de bug sur un paquet qui ne compile pas, j'ai cherché dans la policy la section qui dit qu'un paquet doit compiler pour être valide, mais n'ai pas trouvé. Si vous avez les yeux plus en face des trous, merci de m'indiquer la section en cause. Denis
Re: Lien symbolique debian/
On Wed, Nov 14, 2001 at 07:59:49PM +0100, Jérôme Marant wrote: [EMAIL PROTECTED] (Denis Barbier) writes: Salut, dans le paquet gprolog, le sous-répertoire debian/ est en fait un lien symbolique. La policy n'est pas claire sur le fait que ceci soit valide ou non, est-ce que ça a été déjà discuté ? J'ai déjà vu ce genre de choses, notamment dans les paquets imp et horde. Il ne me semble pas que cela pose problème. Ben si, ça m'emmerde, sinon je ne poserai pas la question ;) Après tout, l'important est que le paquet puisse être construit sans soucis. Oui, mais ça complique beaucoup de choses. Par exemple, sur packages.debian.org, ça serait bien d'avoir les changelogs, fichiers copyright et je ne sais quoi d'autre. Ce n'est pas fait parce qu'il n'existe pas de solution qui marche à tous les coups de les récupérer dans le paquet source. En ajoutant quelques contraintes, comme l'interdiction pour le répertoire debian/ d'être un lien symbolique, ainsi que pour les fichiers debian/* décrits dans la policy et qui ne sont pas prévus pour être modifiés pendant l'empaquetage, et l'interdiction pour ces fichiers d'être modifiés pendant la phase de construction du paquet, ça serait beaucoup plus simple. Ces règles sont déjà respectées par 99% des paquets, les officialiser permettrait de simplifier l'automatisation de certaines tâches. Le seul problème que je vois est si l'upstream a un répertoire debian/ qui est un lien symbolique, il faut alors le packager comme un paquet natif Debian. Denis
Re: To be minimalist or not :-)
On Thu, Nov 15, 2001 at 01:16:57PM +0100, Patrice Karatchentzeff wrote: Le Thu, 15 Nov 2001 13:08:45 +0100, [EMAIL PROTECTED] écrivait : On Thu, Nov 15, 2001 at 12:35:23PM +0100, Patrice Karatchentzeff wrote: [...] En effet, lorsque l'on regarde un peu de plus près certains paquets, on s'aperçoit rapidement que les dépendances ne sont pas minimales. C'est là-dessus que je voudrai m'étendre un petit peu. [...] Je ne comprends pas ce concept de dépendance minimale, tu peux donner un exemple sur un cas concret ? Je n'ai pas d'exemple sous la main (faut que je voie cela ce soir chez moi). J'ai remarqué que dans bien des cas, le développeur préférait garder dans les « depends » la version courante d'une bibliothèque de la version en cours de la Debian plutôt que de donner la version minimale recherchée dans le configure. C'est flagrant pour X par exemple où beaucoup de paquets de Woody demande un X = 4.0 alors que la plupart n'en ont pas besoin pour tourner. Prends un exemple et essaie de modifier le fichier debian/control en ajoutant les champs que tu proposes, je pense que tu te rendras compte que ça n'a pas beaucoup de sens. Denis
Re: To be minimalist or not :-)
On Thu, Nov 15, 2001 at 02:32:39PM +0100, Denis Barbier wrote: [...] je pense que tu te rendras compte que ça n'a pas beaucoup de sens. Hmmm, c'est pas très heureux comme tournure, je voulais dire qu'AMHA ta proposition n'a pas de sens et on devrait s'en rendre compte si on essaie de la mettre en oeuvre sur un exemple. Mais bien sûr, je peux me tromper. Denis
Re: Abime de perplexité...
On Wed, Nov 14, 2001 at 01:47:58PM +0100, georges mariano wrote: [...] Pour ceux que l'expérience intéresse, il s'agit du paquet bash (rien que ça) version (sources) 2.05-10. Toute aide pour comprendre le truc serait appréciée... Bash-2.05-10 compile sans problèmes chez moi sur une potato non trafiquée. Pour comprendre d'où vient le problème, tu peux faire dpkg-source -x bash_2.05-10.dsc cd bash-2.05 [vérifier que error.c existe] fakeroot debian/rules configure [vérifier que error.c existe] make -C build et essayer de comprendre. Denis
Lien symbolique debian/
Salut, dans le paquet gprolog, le sous-répertoire debian/ est en fait un lien symbolique. La policy n'est pas claire sur le fait que ceci soit valide ou non, est-ce que ça a été déjà discuté ? Denis
Re: forcer un buildd à re-construire
On Mon, Nov 12, 2001 at 08:31:18AM +0100, Raphael Hertzog wrote: Salut, Le Sun, Nov 11, 2001 at 11:16:36PM +0100, Ludovic Rousseau écrivait: Le démon de reconstruction a fait deux essais le 7 novembre: un à 20h32 et un autre à 20h34. Les deux essais avec la même erreur Can't find source for ifd-gempc_0.5.5-1. Le paquet a été installé par Katie dans pool/ le 7 novembre à 20h25. L'auto builder arm a été un peu trop rapide sur ce coup là ? C'est dommage puisque du coup le paquet risque de ne pas passer en testing alors que c'est bon pour les autres architectures. Dans debian/control j'ai Architecture: any et pas Architecture: all donc ça devrait quand même passer dans testing si j'ai bien compris. Ah non, cela n'a rien à voir. Architecture: all ca veut indépendant de l'architecture (genre code perl). Architecture: any ca veut dire que ca peut se compiler sur n'importe quelle architecture mais que les paquets ne sont pas interchangeables (ie un paquet compilé sur i386 ne marcherai que sur i386 et pas sur sparc ou ailleurs). Cela n'a *aucun* rapport avec l'algorithme de décision de testing. A la limite, un paquet architecture: all rentrera plus vite dans testing puisqu'il n'a pas besoin d'être recompilée. Attention, ce n'est pas une raison pour mettre Architecture: all sur un paquet qui ne fonctionne pas sur toutes les architecture... Il me semble avoir lu des discussions comme quoi pour qu'un paquet avec architecture: all entre dans testing, il faut que toutes les architectures puissent entrer dans testing. S'il n'y a pas de dépendances, tu as alors raison, mais s'il y en a, le paquet risque d'être bloqué en dehors de testing parce qu'une des dépendances n'est pas disponible dans la bonne version sur une des architectures. Ceci n'est qu'un vague souvenir de lectures de ML, corrigez-moi si je me trompe. Denis
Re: paquet debian : qlq points de détail
On Fri, Nov 02, 2001 at 05:54:09PM +0100, Raphael Hertzog wrote:
[...]
* autre curiosité, quel est l'intérêt d'un orig.tar.gz contenant un
seul fichier à savoir l'archive gzippé des sources upstream ? rapport
avec le diff ??
C'est bizarre ... mais ca doit arriver pour des logiciels binary-only
(genre netscape) où il n'y a rien à recompiler. Juste un répertoire à
détarrer dans une arboresence.
Ça a peut-être un rapport avec dbs (que je ne connais pas), disponible dans
testing et unstable.
de faire précéder tout ça par la suite (aclocal, autoheader, automake
-a, autoconf) dans la construction debian du paquet ?
Jamais. Quand ca marche pas, le mainteneur peut éventuellement les lancer
une fois juste pour mettre à jour les fichiers (dont les modifs seront
conservées dans le .diff.gz).
Pas d'accord, ça ne suffit pas s'il y a une règle de recréation des fichiers
dans le Makefile (ce qui est le défaut avec automake) parce que les timestamps
des fichiers patchés ne correspondent plus.
Voici quelques solutions en vrac pour contourner ce problème :
a) que dpkg-source mette le timestamp de tous les fichiers patchés à une
valeur commune, correspondant à la date de lancement de la commande
(c'est l'objet du rapport de bug 105750) ;
b) dans debian/rules, faire un touch des fichiers dans le bon ordre ;
c) dans debian/rules, lancer les commandes auto* lors de la compilation ;
d) ajouter AM_MAINTAINER_MODE dans le configure.{in,ac} ;
e) demander aux développeurs upstream d'Automake de changer le comportement
par défaut, et d'avoir une macro AM_DEVEL_MODE si on veut que les
fichiers soient automatiquement réécrits.
et j'en oublie sûrement.
Denis
Re: backport Imagemagick
On Sat, Oct 27, 2001 at 05:15:17PM +0200, georges mariano wrote: On Sat, 27 Oct 2001 16:12:13 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: DB DB Très bien, continue de recompiler sans te poser de questions, bon courage. sans me poser de questions, t'es gonflé de dire ça... Cette réponse avait été envoyée en privé suite à un message que tu m'as envoyé en privé. ça tombe bien, moi aussi je voulais abréger ... voici où j'en suis a) en 15mn, j'ai mon paquet woody de snmpkit-0.8, aucune difficulté à signaler... mais bon, je compile que pour ma machine ;-) [après faut une heure pour tout bien faire dans les coins ;-)] b) j'ai cassé ce paquet en 5mn !! j'ai juste fait intervenir la commande que tu me suggérais mais en utilisant les paquets debian évidemment (je vais pas tout réinstaller en tarball!!) donc avec autoconf/automake Debian, la commande que tu suggère (+ un ptit coup de libtoolize, y'avait un problème de version (!?)) ben maintenant ça compile plus... Non, je t'avais suggéré de faire cette commande avec les sources upstream, je résume - en touchant le moins possible les sources upstream, j'obtiens sans difficulté le paquet Debian - en faisant intervenir les outils autmake/autoconf Debian, ça casse tout... Avec ça, en déduire que le problème est upstream et que le mainteneur fait du bon boulot... ben moi j'y arrive pas... C'est pourtant très simple, il suffit de faire ce que je t'avais suggéré dans le mail précédent ; tu prends les sources, autoconf 2.13 et automake 1.4-p5, tout ça upstream, donc sans un poil Debian, tu fais aclocal autoheader automake -a autoconf ./configure make Si tu fais une installation from scratch, il faut aussi installer libtool, ou copier /usr/share/aclocal/libtool.m4 dans /usr/local/share/aclocal/libtool.m4 Et tu verras que ça plante, alors que tu n'as tapé aucune commande packagée par ces abrutis de Debian. À partir de là, le scénario que j'avais proposé dans le mail précédent te semblera peut-être plausible. Enfin bon, on peut toujours rêver. Denis
Re: continuité de service ??
On Sun, Oct 28, 2001 at 06:50:59PM +0100, georges mariano wrote: On Sun, 28 Oct 2001 15:58:25 +0100 Raphael Hertzog [EMAIL PROTECTED] wrote: RH Pourquoi ne pas demander à debian-www@lists.debian.org le pourquoi du RH comment et plaider pour sa remise en place ? je sais pas trop où c'est, mais avec un peu de bol, tu dois pouvoir retrouver ma tentative ... bon courage... C'est pas du courage qu'il faut, mais de l'imagination ; tu n'as envoyé aucun message à la liste debian-www depuis août 1998, les archives consultées ne permettent pas de le savoir pour avant. Qui parlait de crédibilité ? Denis
Re: backport Imagemagick
On Fri, Oct 26, 2001 at 12:12:34PM +0200, georges mariano wrote: On Fri, 26 Oct 2001 11:25:09 +0200 Roland Mas [EMAIL PROTECTED] wrote: RMLa possibilité d'upgrader un système. Si l'état initial est connu RM (la stable précédente ou celle d'avant), on peut. S'il est inconnu RM parce que le mec s'est installé des paquets rétroportés à différents RM moments, on peut pas upgrader de manière déterministe (ou alors, il RM faut prendre en compte toutes les combinaisons possibles d'upgrades RM intermédiaires). Le principe fondamental des OS modernes c'est de garder autant que possible une independance entre les couches existantes. En matiere de (re)compilation de softs ceci est assuré par les mécanismes (sophistiqués) d'éditions de liens, de chargement dynamique etc ... On peut envisager d'avoir plusieurs version d'une même librairies et jouer ensuite sur les réglages possible. Moralité : Ce premier paragraph (celui de RM!) est orthogonal à une bonne perception de ce quoi doit faire un OS moderne comme Linux/Debian... [...] Dans le genre « je dis n'importe quoi », je te ferai remarquer que pour l'instant c'est toi le vainqueur, ton diagnostic sur les problèmes rencontrés avec imagemagick était complètement délirant. Est-ce que tu comptes l'admettre un jour, ou tu vas me démontrer que c'est en fait moi qui me suis trompé ? Sur le fond, ce n'est pas la peine de répondre, puisqu'apparemment tu as ta propre définition de ce qu'est la stabilité de Debian, et ceux qui n'ont pas la même ne sont que des abrutis. Oui, il y a des problèmes, certains développeurs font du travail de merde, certaines décisions techniques visent à favoriser la vie des autobuilders en se foutant des implications sur les utilisateurs, mais si ton but est que ça change, il faudrait essayer d'être productif et proposer des idées pour qu'elles soient relayées. Denis
NMU d'automake
Salut, il semblerait qu'Anthony Towns ait fait un NMU ce week-end d'automake en splittant le paquet en 2 : la version normale d'automake redevient 1.4, et il a ajouté automake1.5 avec un conflit entre les 2 paquets. Plutôt violent comme NMU, non ? Ça pose de nouveaux problèmes aux paquets qui n'en avaient pas. Je n'ai rien vu passer sur debian-devel à ce sujet, à part un mail de lui il y a plusieurs semaines où il demandait comment le responsable compter régler le soi-disant problème. Est-ce une attitude normale de la part d'A.T. ? Denis
Re: NMU d'automake
On Thu, Oct 25, 2001 at 10:42:01AM +0200, Jérôme Marant wrote: [...] Ça pose de nouveaux problèmes aux paquets qui n'en avaient pas. Par exemple ? Aurais-tu par hasard quelques entrées de BTS à ce sujet pour pouvoir voir ce qui ne va pas ? Il y au un message sur debian-devel ce matin ou cette nuit, ça casse les dépendances avec versions. Ça va aussi casser les paquets qui ont été construits avec automake 1.5 et qui ne l'ont pas été correctement, parce que par exemple le aclocal.m4 ne sera pas régénéré alors qu'il le faudrait. Denis
