Re: paquet.diff.gz
On Fri, 19 Oct 2001 07:54:56 +0200 Patrice KARATCHENTZEFF [EMAIL PROTECTED] wrote: PK surtout pas : je précise que je veux le faire « à la main ». Je traite PK tout au cas par cas. :-) Moins je fais exactement l'inverse ... le moins possible à la main, tout en recompilation automatique (mais bon, c'est surement pas pour le même besoin) PK Debian n'assure aucune homogénéité pour ce genre de truc Je comprends pas trop ce que tu veux dire là... (j'ai pas dis qu'il n'y avait pas de problèmes ! mais je ne vois pas ceux dont tu parles...) PK et je ne veux pas voir apt me télécharger la moitié de woody pour PK mettre à jour un misérable programme. ?? j'utilise apt-get -b pour recompiler automatiquement et il est extrèmement rare qu'il récupère autre chose que le paquet en bout de commande ... !! (j'ai d'ailleur pas d'exemples de ce que tu dis ...) apt-get sur les sources ne se comporte pas du tout comme pour les binaires En parlant d'homogénéité, les divers paquets sources se décompressent tous avec des uids-gids divers et variés ... c'est pas beau ... une astuce ?? -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
pretty-print de Packages.gz
Salut a) quelqu'un connait des truc pour publier le contenu des fichiers Packages.gz de manière sympa ?? (html ?) b) au passage, comment spécifier le petit commentaire qui apparait quand on télécharge des paquets exemple : (1.0-10 Debian:2.2r3/stable) obtenue pour une souce potato Merci -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
recompilation wxwindows2.2
En recompilant, wxwindows2.2 pioché dans testing, j'ai un formidable : ./debian/rules binary dh_testdir touch docs/lgpl.txt cd wxPython \ ./setup.py build IN_CVS_TREE=1 WX_CONFIG='/oryx2/debs/sources/libwxgtk2.2/wxwindows2.2-2.2.6.1/objs_gtk_sh/wx-config --prefix=/oryx2/debs/sources/libwxgtk2.2/wxwindows2.2-2.2.6.1 --exec-prefix=/oryx2/debs/sources/libwxgtk2.2/wxwindows2.2-2.2.6.1/objs_gtk_sh' Traceback (innermost last): File ./setup.py, line 10, in ?from my_distutils import run_swig, contrib_copy_tree File ./my_distutils.py, line 125, in ?ccompiler.default_compiler['nt'] = 'my_msvc' AttributeError: default_compiler Problème : python, c'est quoi ??? ;-) PS : compilation à la main ./debian/rules binary ... message ontenu après une très longue phase compilation optimale... PS2 : truc marrant, 1er essai : apt-get source -b wxwindows2.2 boum, en 2 secondes, le-dit message... 2eme essai : debian/rule binary phase de compilation et 1 heure plus tard (j'exagère) boum, le-dit message ... A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: backport Imagemagick
On Wed, 24 Oct 2001 15:00:37 +0200 (MEST) Jérôme Marant [EMAIL PROTECTED] wrote: JMTu es en train de backporter le monde Georges ? ;-) vi... on va me surnommer Atlas ... ;-) JMPourquoi ne passes-tu pas à testing plutôt que te donner tant JMde mal ? Euh, qui t'as dit que j'avais du mal ... Imagemagick c'est un paquet sur ... un peu plus de 326 ... :-) Pourquoi ?? Réponse : pourquoi pas ?? Plus sérieusement, pour le principe ! Si Debian se dit stable (et je demande qu'à le croire) ce doit être raisonnablement faisable... Si ça ne l'est pas alors y'a un blême ... Et le plus important : c'est inimaginable les trucs qu'on apprend en faisant ça... C'est imparable pour la qualité des paquets... Petit exemple : la recompile de imagemagick bloque entre autres parce que a) il exige une lib qui en définitive est optionnelle b) il oublie de demander une lib qui elle est (apparemment) indispensable c) ce problème de install_vendor d) après avoir mis la valeur site, on va un peu plus loin... ça bloque à nouveau ... veut installer des trucs dans debian/usr/lib/perl5/... qui n'existe pas ... N'importe quoi. PS : Dans l'intervalle de nombreux messages très significatifs ... Juste deux choses (c'est un peu méchant mais bon...): 1- Le seul qui ai vraiment compris _tous_ les paramètres du problème c'est PK. 2- A part ça bcp d'approximations... ai-je dit que j'upgradais aveuglément tous ce que je backporte (plus pour le fun d'ailleur...) ? Pour me convaincre de passer en woody, précipitez-vous pour répondre à la question suivante : a) qu'on m'explique pourquoi je vais (prendre le risque non négligeable de) rendre inutilisable ma petite dizaine de machines parce que je vais pointer sur woody et que, quasi inévitablement, ça va me chambarder les serveurs X, les install perl, tout ça pour que mes utilisateurs, qui se pointent tous les matins au boulot (détail non négligeable), utilisent la dernière version d'une appli tout venant reconnue stable upstream, et qui n'à que faire de la policy-à-la-mode-actuellement ? b) une de plus tiens, pour la route... si le paquet source pris dans woody recompile pas ... d'où vient le paquet binaire correspondant ??? Je ne vous donnerai pas la liste des paquets qui soit disant nécessitent woody et qui fonctionnent bien sur mes potato depuis longtemps. Et qui se recompile sans un problème simplement en faisant croire que je suis en Xfree4 (merci equivs) Pour conclure, faudrait peut-être se rendre compte un jour que ce qui est 'unstable' chez Debian c'est _surtout_ les décisions humaines Debian, et pas les bugs des applis, ni la recompilation du tarball (90% de la validité du package)... On en vient à ne pas pouvoir installer un paquet pour des raisons administratives et non techniques... Faut arréter de délirer sur vos destriers blancs étiquetés Debian (ça rime!)... Je crois pas que ce soit la faute de ImageMagick si le paquet que je récupère ne se compile pas. ça vient de me donner une idée horrible ... je remonte d'un grand... make install (i.e install à la tarball)... et ça marche !! display 5.3.8 en potato... dernière fois que je fais ça.;-) Parait qu'il y a une équipe assurance qualité chez Debian ?? Fallait pas m'énerver ... ;-) A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: backport Imagemagick
On Wed, 24 Oct 2001 22:04:55 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: D DB Au lieu de t'énerver, tu aurais pu regarder si c'est un bug connu. DB direction http://bugs.debian.org/imagemagick et là, ô miracle, qu'est-ce DB qu'on voit ? Tout à fait d'accord avec toi, malheureusement j'étais en déplacement aujourd'hui... Bon, tu l'as fait pour moi ... ;-) DB Seulement le responsable du paquet n'arrive pas à reproduire ce bug, ben je reprendrai une suggestion faite ici (et pour laquelle je suis d'accord à 100%), un développeur devrait bosser sous potato sauf exigences spécifiques... A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: backport Imagemagick
Bon un dernier pour la route... RH d'accord à 100%), un développeur devrait bosser sous potato sauf RH exigences spécifiques... RH RH Et là je suis 100% contre, en faisant cela, on ne passe jamais aux RH nouvelles versions des bibliothèques, et on ne bouge pas. RH RH Un développeur doit compiler sur unstable. Alors faut faire de la pub basée sur l'unstabilité de Debian :) Je voudrais qu'on m'explique pourquoi le doit ?? Exemple, Le passage de samba2.0 a samba4.0, (pas de panique, c'est un exemple virtuel ;-) Si ça compile parfaitement avec la libc6 2.1, pourquoi le faire obligatoirement avec la 2.2 ?? Je vois vraiment pas l'intérêt en terme de stabilité (ça va obliger à mettre à jour plus de paquet que nécessaire donc plus de risques !) [imagemagick _exige_ libdps alors que c'est pas _nécessaire_ ...] Ce qui me mets vraiment de mauvais poil c'est un apt-get source -b qui foire parce qu'il demande les dernières libs __à la mode__ alors que derrière un debian/rules binary fonctionne (très) bien ... Tout ce que je demande c'est que les paquets pour lesquels il n'est pas __nécessaire__ de frimer ne nous __obligent__ pas à upgrader la moitié du système ... (merci de prendre en considération les __ __ qui sont pas là pour rien) Ceux qui disent que woody me semblent croire que 90% des paquets nécessitent le passage en woody, ben je suis désolé, mon backport du monde démontre (statistiquement) le contraire... En vrac, ') l'exemple fort-a-propos de /usr/share/doc, pourquoi tant de soucis pour la compatibilité descendante de fichiers de docs et, apparemment bcp moins de réflexion sur un truc comme perl ?? '') je ne me souviens pas que la moitié des applis upstream linux induisent une mise à jour radicale dans leurs dernières versions suite à des modifs perl amont. J'en déduis que le problème de transition perl est __spécifique__ Debian, et là, ça me mets très mal à l'aise... ''') pourquoi est-il si inconcevable de modifier le paquet xlib6g(-dev) actuellement dans potato, de lui rajouter les deux lignes, et régler ainsi pour une foultitude de paquets le problème de la recompilation ?? ça m'a pris 5mn chez moi (plutôt 15)... Mais si j'ai bien compris c'est une hérésie chez Debian cause que potato est dans le marbre ... J'arrète là, la liste est longue des spécificités packaging Debian qui m'échappent. Je conçois parfaitement que la politique Debian s'affine/évolue entre deux releases, mais à partir du moment ou cette même politique m'oblige à gérer mon parc à-la-windows en courant après la dernière version de tel ou tel paquet ... tout ça pour pouvoir installer la dernière version d'un logiciel qui n'a rien voir avec ces décisions je me demande où est le gain ... A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: backport Imagemagick
On Fri, 26 Oct 2001 14:36:19 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: DB On Fri, Oct 26, 2001 at 12:12:34PM +0200, georges mariano wrote: DB Dans le genre « je dis n'importe quoi », DB Oui, il y a des problèmes, Faudrait savoir... DB certains développeurs font du travail de merde, pas celui de ImageMagick donc... DB certaines décisions techniques visent à favoriser la vie des autobuilders pas celles qui tournent autour d'autoconf ou des différents organisations de perl donc... DB en se foutant des implications sur les utilisateurs, J'ai pas de bol, je tombe toutjours sur de mauvais exemples de vrais problèmes ... comment voulez-vous être crédible après ça... DB mais si ton but est que ça change, Pourquoi devrais-je avoir un but (sous-entendu dans la ligne Debian) ? Mon seul objectif, c'est d'avoir un système qui réponde à mes besoins. Mais quand on me répond que le système Debian est l'un des plus stable quitte à réinstaller la moitié de l'environnement des utilisateurs actuels pour une histoire de Debian Policy, je m'interroge. DB il faudrait essayer d'être productif et proposer des idées Personnellement, je me sens productif ici, en backportant ce dont nous avons besoins, je nous évite (enfin je crois) pas mal de problèmes de ... stabilité (cf la liste user). C'est toute mon ambition, même si elle passe par une technique que certains prennent pour impossible... DB pour qu'elles soient relayées. Ben si mes diagnostics sont étiquetés comme n'importe quoi, c'est plutôt foutu d'avance non ??? A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
un chti coup de bonne volonté...
ça me changera... quelqu'un peut-il m'indiquer dans la foultitude de doc Debian, où est spécifié/décrit le cheminement d'un paquet tout frais tout neuf, depuis son arrivée dans ... incoming? (y'a un truc avant ??) jusqu'à ce qu'il arrive dans sid/woody... c'est surtout le cheminement du paquet source qui m'intéresse ... j'ai cru entrevoir que certains paquets étaient automatiquement(?) rejetés ... jevoudrais savoir comment/pourquoi... et pis, où on trouve de la doc sur ces bête mysèrieuses appelées autobuilder ... A+ PS : je vous raconte mon dernier manque de bol ?? ;-) non ... je déconne. Il est relativement banal. -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: continuité de service ??
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... et la question n'est pas de la remettre en place, mais pourquoi l'avoir virer ?? Maintenant je vais te dire pourquoi cela a probablement été virer. A l'époque, y'avais bcp de file not found sur ce lien. Alors, mais j'extrapole, hypothèse que peu de mainteneurs Debian se souciait de remplir/fournir correctement ce fichier, d'où erreurs d'accès trop fréquentes, d'où solution facile : on vire. Question respect du travail etc etc, ça la fout mal. RH Tu vois, tu te contentes de constater sans chercher à faire suivre tes RH remarques aux personnes responsables et compétentes pour changer cela. arrêtes ... va dire ça à ceux qui depuis des mois/années se heurtent à un trou noir rien que pour mettre une signature sur la liste french ou des trucs 10 fois plus anodins... excuses moi si j'ai pas envie de perdre mon temps ... j'indiquais juste une contradiction entre un fait (vérifiable par tous) avec un discours galvaudé et bien pratique. au fait, c'est pas toi qui a reussi l'exploit de créer une nouvelle liste en deux coups de cuillere à pots ?? si la réponse est oui, alors c'est ici le meilleur endroit pour faire remonter non ?? alors décidez-vous, ou cette liste sert à qqchose, en particulier à filtrer ou faire remonter les bonnes remarques, où elle sert à rien (si au bout du compte, la réponse est : va voir stPierre là-haut, ici c'est juste pour troller...) A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: continuité de service ??
On Sun, 28 Oct 2001 19:17:28 +0100 Raphael Hertzog [EMAIL PROTECTED] wrote: RH C'est bien ca ton problème, tu considères que travailler pour RH l'amélioration de Debian, c'est perdre ton temps ... Tout dépend de qu'elle amélioration on parle ... Pour l'instant je passe mon temps à essayer de convaincre des développeurs français de bien vouloir prendre en considération certains besoins utilisateurs ... Ce qui est effectivement et visiblement une perte de temps. Ce serait une forme d'amélioration bcp plus pertinent que de corriger des pages web (__qui n'auraient pas due être amputées__) Je suis un peu comme les développeurs Debian, j'ai des ... priorités. Et si ces derniers veulent me faire avaler que leurs priorités ne collent pas avec celle d'un utilisateur, je devrais bien arriver à leur faire avaler que les miennes ne collent pas avec les leurs, non ? J'invite ces même développeurs à aller secourir sur la liste user (oui, tout en bas, dans la plèbe) le sieur Christophe Baillon qui devrait pourvoir vous parler de la continuité de service potato/woody. (message de dimanche 20h47) Y'a encore du boulot avant de livrer la woody. En ce qui concerne la fainéantise pour la signature de la liste debian-french, c'est tout simplement que c'est pas moi qui avait le projet le plus abouti (Martin Quinson de mémoire)... À partir du moment où RH avait proposer son aide, libre à Martin de suivre ou pas ... L'abscence de signature ne me dérange pas trop, mais, dans mon égoïsme viscéral, j'ai essayer de faire avancer le problème d'un pote (probablement absent à ce moment là), c'est tout. Mais bon tout ça nous égare... A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
backport perl5.6
Re-moi, bon, étudions la bête... Pour l'instant j'arrive jusq'à l'obtention des paquets .deb potato pour perl5.6... (faut arréter le nis, sinon un test perl échoue...) Donc, jusqu'ici tout va bien et, comme prévu, pas d'incompatibilité technique, la recompilation des sources upstream et la construction des paquets se passe nickel i.e perl5.6 upstream n'est pas allergique à un environnement potato. Bon, maintenant, apt-get -s install perl, et là 72 paquets à virer dont certains paquets fondamentaux... Question : La difficulté du backport de perl provient donc de la définition actuelle des dépendances. Je fais l'hypothèse que perl5.6 provide (au moins) les même fonctionnalités que le perl actuel potato. Quelqu'un a déjà potasser le problème ?? Si je peux pas changer les deps spécifiées dans potato, peut-être celles de woody ?? A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: Utilisation des alias @debian.org
On Tue, 30 Oct 2001 09:50:52 +0100 (MET) Jérôme Marant [EMAIL PROTECTED] wrote: JM Bonjour, Salut, JMJe conseille (demande) à tous les membres du projet Debian JMde ne jamais utiliser leur alias @debian.org sur les listes JMde diffusion quelles qu'elles soient Même pas les listes Debian ? JMet pour de la correspondance JMprivée qui sortirait du cadre du projet Debian. JMEn effet, il faut avoir conscience que tout ce que peut dire JMchacun de nous n'engage que lui et l'utilisation de l'alias JMpeut potentiellement nuire au projet (ceci valable pour tous JMles projets) de part les propos qu'il tient. Je comprends bien le souci affiché (moi-même je suis concerné non pas par @debian.org mais par le @inrets.fr) mais un truc me tracasse : * je suppose que tu as un cas , un exemple en tête non ?? (c'est pas le genre de mail qu'on pense envoyer le matin en se levant sur un coup de tête ;-) juste pour fixer les idées? * ensuite, c'est bien joli toutes les technicités mutt/emacs/autres, mais je vois pas trop ce que cela change, une idée géniale ou une bourde exprimée par Jérôme Marant restera exprimée par lui-même quoi que tu fasse... Je ne comprends pas bien en quoi la technique informatique peux te permettre de te dédoubler (au moins!) en fonction de tes besoins... Le fait d'envoyer un mail avec @debian.org n'est pas équivalent à utiliser du papier à entête Debian (s'il en existe?). Il me semble qu'encore récemment (jurisprudence) le courrir électronique a été considéré comme courrier privé (i.e sans entête) Juste une réflexion ... Mais concrètement que crois tu que cela change ce que tu demandes ? Quel impact négatif redoutes-tu ? (si je veux en savoir plus sur Jerome Marant, google me dira tout !? et je ferai ensuite tous les rapprochements utiles (ou non, mais ça c'est mon problème d'interprétation/extrapolation pas le tien! i.e quoi que tu fasse, tu n'y peux rien ...) Ceci dit, je ne conteste pas le côté pratique de certains outils ;-) Mais il me semble que ce que tu cherches à obtenir par cette policy n'est en définitive qu'une illusion relativement dangereuse car trompeuse... Sans poser la question de l'équité : ceux qui n'ont pas la possibilité technique de se dédoubler sont-ils condamnés à n'avoir qu'une seule activité ? A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: [hs] cron(?) de compilation
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789* On Fri, 02 Nov 2001 15:14:21 +0100 Roland Mas [EMAIL PROTECTED] wrote: RM [Remarques sur la forme : RM Dans les en-têtes de mes messages, il y a Mail-Copies-To: never. ben désolé, cet entête est pas affiché par défaut, pouvais pas deviner... RM veut dire que je demande à ne pas recevoir une copie privée des c'est bien compréhensible... RM que tu configures ton lecteur de mail pour qu'il en tienne compte. j'ai peur que ce soit pas possible (transmettre une demande aux auteurs de Sylpheed ?? ou attendre un manuel sylpheed complet...) [je viens de cocher tout ce qui a un rapport avec le wrapping... ce sera sans doute activé pour mon prochain mail... et puis je viens de faire un test vers moi-même, et j'ai pas d'effets génants !? (j'affiche sur 80 cols)] RM D'autre part, ta manière de citer en coupant les lignes est un peu RM ennuyeuse. Si tu pouvais configurer le bazar pour corriger ça, ce RM serait cool aussi.] ben c'est pas _ma_ manière, c'est celle de sylpheed... again, désolé. j'essaye bien de trouver une technique work-around mais bon ... RM l'heure dite. Ou alors tu rebootes tous les matins à neuf heures RM moins cinq. C'est toi qui vois. arggg, c'est tout vu !! RMMême si le programme ah hoc est constitué d'une seule ligne de RM shell? mmm, c'est négociable ;-) fais voir ... PS : oui du prosélytisme !! que tous ceux qui me lisent, utilisent gnus !! :-)) A+ 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789* -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
installation emacs et /etc/emacs/site-start.el
Bonjour à tous, Je constate la chose suivante : l'installation (la réussite de) d'un paquet relatif emacs par ex jde, tdtd, speedbar dépend du contenu de /etc/emacs/site-start.el Plus précisément, soit un /etc/emacs/site-start.el correctement défini i.e le lancement d'emacs ne pose aucun problème et les modes souhaités sont automatiquement activés (auctex, rftex, hilit) Je m'aperçois maintenant que ce fichier empèche maintenant une installation correcte (ex mise a jour) de paquets relatifs emacs. Il y a une erreur style le serveur X n'est pas activé lors de la recompilation des .el en .elc au moment de l'installation. dpkg échoue, et je suis coincé. Ce que je comprends pas c'est pourquoi un site-start.el opérationel du point de vue utilisateur emacs peut poser des problèmes du point de vue installation/dpkg ? J'ai l'impression (je suis pas expert x/emacs et de loin) que cela à un rapport avec l'initialisation des modes +/- liés à X alors que je n'utilise que emacs et non pas xemacs, Pourquoi l'installation d'un paquet relatif emacs est concernée par le contenu de /etc/emacs/site-start.el ?? Merci -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: Abime de perplexité...
On Wed, 14 Nov 2001 14:42:53 +0100 Raphael Hertzog [EMAIL PROTECTED] wrote: Perso je dirais que ce n'est pas acceptable tel quel. En effet, le paquet compile sans problème sur une sid ... (testé ici) et c'est l'essentiel. Maintenant s'il veut que ca compile sur autre chose aussi, hmm, il ne faut pas oublier que cette autre chose n'est pas exotique, c'est un autre chose où l'upstream compile déjà! autre formulation : je domaine de recompilation Debian doit s'étendre et pas simplement se décaler... (c'est mon point de vue) Mais un bug report sans patch ne sert à rien, parce que le paquet compile là où il doit compiler. j'ai fait une petite erreur, parmis les tests que j'ai fait, il y a la recompilation d'un paquet de woody sur une woody ... (bash-2.5-8 et non pas 10) donc, la question reste posée. A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: To be minimalist or not :-)
bonjour à tous, Bien que le sujet puisse être le même, il ne s'agit pas ici de la même préoccupation que Patrice, tout au plus une variante. En backportant gconf, je comprends ceci : - la compile debian demande libdb3-dev pour construire le paquet - la compile upstream ne le demande pas - en regardant la phase de configuration, il s'avère que db3.h est détecté ou non, ce qui déclenche l'ajout ou non de la compilation du backend db3 Il semble donc que - pour upstream, ce backend soit facultatif - pour le mainteneur, ce backend soit apparemment utile... Ne connaissant pas trop ni gconf ni db3, quelqu'un peut-il me donner quelques éléments pour déterminer quelle voie est la bonne ? (j'imagine que la réponse n'est pas booléenne) La question analogue à celle de PK pourrait se reformuler ici : Comment décider que dans Debian telle fonctionnalité _doit_ enrichir un soft ? (avec la conséquence d'un effet cascade sur les mises à jour) Merci -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
rpm et deb
Bonjour a tous, après avoir fourni un rpm fabriqué à partir d'un deb à une personne pour le tester, celle-ci m'informe que lors d'un essai pour enlever le paquet rpm il a le message suivant rmdir of / failed: Device or resource busy effectivement, cela peut s'expliquer par le fait que le fichier .files du paquet debian commence par /. puis classiquement /usr/bin /usr/bin/toto ... d'où vient ce /. ??? je vois pas trop à quoi il sert ? A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: STOP ! [Re: Pour GM]
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 je peux pas tester ça avant ... le 6 ?? -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: STOP ! [Re: Pour GM]
On Fri, 30 Nov 2001 12:34:15 +0100 [EMAIL PROTECTED] (Denis Barbier) wrote: 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. on est (au moins) deux ... toute la discussion réside dans la difficulté de a) faire remonter une modif en amont (par ce qu'on s'interdit de toucher à certains fichier à déterminer, [imaginons que lintian râle sur ces cas là] b) sans bloquer indéfiniment la possibilité de faire un paquet en attendant que ça bouge... 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). Il est probable que se donner des contraintes supplémentaires induisent une adaptation de certains points. Pas d'omlette ... Mais, l'important est ici que tous les paramètres du problème se trouvent localisés dans le debian/rules (y compris la connaissance de la valeur DH_COMPAT [s'il y avait besoin]) Et le mainteneur Debian a tout pouvoir à _cet_ endroit. -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
decryptage
Bonsoir, avant de partir je voulais faire une petite mise a jour documentaire je tape : apt-get -s install task-debian-devel debian-policy lintian secpolicy packaging-manual et je lis debian-policy: Conflicts: packaging-manual but 3.2.1.0 is to be installed bon, je vois bien qu'il y a conflit mais je tranche comment et pour qui ?? Merci -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: recompilation graphviz
On Mon, 17 Dec 2001 16:08:26 +0100 Nicolas SABOURET [EMAIL PROTECTED] wrote: Même sous une woody ? T'as vérifié ? Dans ce cas, je pencherai pour un bug, mais il me semble assez surprenant ... oui, c'est bien pour ça que je m'interroge, c'est trop gros... bien vu, effectivement sous woody, y'a des .so.0.0.0 ... gulps ? Nico. -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: recompilation graphviz
On 17 Dec 2001 23:28:23 +0100 Julien BLACHE [EMAIL PROTECTED] wrote: Ta version d'automake/autoconf/libtool. ben c'est sur une bonne vieille patate apt-get -s remove automake libtool autoconf The following packages will be REMOVED: autoconf automake libtool 0 packages upgraded, 0 newly installed, 3 to remove and 49 not upgraded. Remv automake (1.4-8 Debian:2.2r4/stable) Remv autoconf (2.13-20 Debian:2.2r4/stable) Remv libtool (1.3.3-9.1 Debian:2.2r4/stable) ? strange ... -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: recompilation graphviz
On Tue, 18 Dec 2001 11:12:12 +0100 [EMAIL PROTECTED] (Denis Barbier) wrote: D'autant plus étrange que sur une bonne vieille patate avec les mêmes versions des softs, j'ai ça pendant le configure: c'est donc que cela dépend d'autre chose ... ;-) bon en remontant les dépendances, je tombe sur binutils qui, sur cette machine, est un backport. Je suis donc revenu en arrière et apparemment : ./configure | grep shared checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes c'est donc mieux... il faudrait maintenant déterminer d'où vient le glitch lors du backport de binutils ... ça progresse, c'est déjà ça, PS : oui, définir ce qu'est une bonne vieille patate est délicat/relatif sur une machine qui recompile ;-) merci. -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
[BRUIT] a l'intention de Christian Marillat
Bonjour à tous, ceci est un message perso pour Christian Marillat (vous allez comprendre pourquoi je poste ici...) Nous discutions au sujet d'un rapport de bug or je viens de recevoir des messages d'erreur du type : === From: [EMAIL PROTECTED] Subject:Check_Subject Date: Wed, 19 Dec 2001 13:39:58 +0100 Our spam filter rejected this transaction. === Je ne trouve pas d'autre adresse que [EMAIL PROTECTED], je tente donc de le joindre par un autre canal... pour lui signaler ce problème d'anti-spam. Avec mes excuses pour le bruit A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
repertoire de construction des .deb
(re)Bonjour à tous, Voilà, pour affiner ma technique de backport, j'ai besoin de créer les .deb ailleurs que dans le répertoire père des sources (i.e dans un répertoire pré-calculé) (en fait je vais re-créer des paquets woody _et_ potato dans le même système de fichier, je voudrais éviter de les mélanger ;-) Dans toutes la floppée des outils qui interviennent lors de la construction des paquets, y'en aurait-il un à qui je peux lui faire comprendre ça ?? Merci -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: Pb de backport
On Thu, 20 Dec 2001 11:30:14 +0100 [EMAIL PROTECTED] (Denis Barbier) wrote: Debconf dépend de fonctionnalités apparues avec Perl 5.6 ok. Le problème quand on backporte, c'est qu'une fois qu'on a installé perl5.6 pour une bonne raison (pour un paquet x), il est difficile de détecter ensuite une sur-dépendance sur ce paquet puisqu'il est installé ... ;-) [en toute rigueur, il faudrait perpétuellement installé/désinstallé en fonction de chaque paquet backporté !!] Est-ce que tu confirmes qu'il faut recompiler les modules Perl qu'on utilise ? Je n'ai pas compris ta réponse. et si j'ai pas compris la question ? :-) En fait la réponse dépend de la raison pour laquelle tu fais du backport. En ce qui me concerne, je souhaite recompiler tout paquet debian qui entre dans mon sous-réseau, les machines concernées s'alimentent ensuite sur une source interne. Ceci conduit donc naturellement à backporter les paquets (les machines sont potato initialement). Dans ce cas, tout est backporté... i.e sauf exception, aucune machine ne récupère directement un paquet _binaire_ woody. C'est le cas extrémiste. Une autre attitude consiste à jongler sur les sources (et options de apt) pour pointer sur le bon paquet (potato ou woody) au grés du besoin. En ce sens, il est possible de backporté la base perl mais de récupérer ensuite sur woody d'autres modules perl. Ici, je me repose sur la cohérence des dépendances Debian en place. 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... PS : en gros les machines Debian pointent en binaire sur des sources potato/stable (debian, ximian, xfree ...) et en deb-src pour le reste... quand un apt-get install coince, on avise ... PS2 : dans l'intervalle debconf s'est recompilé _automatiquement_ sur ma machine woody, on va pouvoir commencer à étudier son cas ... ;-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Pb de backport
On Thu, 20 Dec 2001 15:14:37 +0100 MEI Sébastien [EMAIL PROTECTED] wrote: D'accord, mais il y a t'il un moyen simple de le faire ??? Sans avoir à triffouiller pendant 2h dans les sources. Parce que j'ai commencer à chercher mais je n'ai pas trouvé comment désamorcé le debconf :( Je suis dessus et j'ai bon espoir... ;-) en fait les problèmes que je rencontre actuellement sont dus à d'autres paquets dont debconf dépend... mais là c'est plus du backport, c'est de la spéléo ... !! A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: De l'interet de debconf (was: Pb de backport)
On 21 Dec 2001 15:59:53 +0100
[EMAIL PROTECTED] (Jérôme Marant) wrote:
Tu peux demander à debconf de ne pas te poser de questions.
Dans ce cas là, les fichiers de configuration auront des
valeurs par défaut. C'est tout.
ok, mais pourquoi ne pas aller plus loin, et avoir la possibilité
__d'annuler__ l'existence de debconf pour une machine donnée ?
Est-ce (bien?) l'idée du fichier suivant ??
[more /etc/apt/apt.conf.d/70debconf
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
]
Si on imagine une échelle des systèmes avec le critère de la capacité
de réglage, ça va du tout à la main (à l'extrème Linux From Scratch)
au tout par l'install système (type Macintosh, Windows). Avec un
outil comme debconf, Debian peut se déplacer sur cette échelle. C'est
bien. Mais Debian doit préserver la liberté de l'utilisateur et en
particulier celle de __ne pas utiliser__ un outil/une fonctionnalité.
Il ne suffit pas que l'utilisattion de cet outil soit invisible mais
il faut également que l'existence même de l'outil ne soit pas un
obstacle à ce que veux faire l'utilisateur. De ce point de vue, la
politique de dépendance autour de debconf me semble trop forte... et
(envisager de) rendre debconf obligatoire me semble incongru.
Je ne trouve pas d'autres exemple d'outils (linux) ayant le status que
l'on souhaite donner à debconf ... (mais je connais pas tout!!)
Sinon, rien à dire sur l'utilisation graduelle de debconf en soit...
PS : j'ai pas encore pris mon café, aucune idée si ce que je dis
est possible...
Je t'ai largement laissé le temps de prendre ton café là. :-)
c'est fait (et plus d'une fois ;-)
--
mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06
INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59
BP 317 -- 59666 Villeneuve d'Ascq
http://www3.inrets.fr/estas/mariano
Re: Linux Expo
si vous avez des suggestions envtuellements. oui, joindre à cet appel le minimum d'informations permettant au lecteur de se positionner dans un espace à quatres dimensions (la localisation géographique et la localisation temporelle) et, in fine, de déterminer si cela est compatible avec son emploi du temps ... donc pas tres compliqué ;) j'allais le dire ;-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Linux Expo
On Mon, 24 Dec 2001 14:29:51 +0100 (CET) Frederic [EMAIL PROTECTED] wrote: en kel langue pour kil comprenne ? change rien ça devrait faire l'affaire... :) -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: De l'interet de debconf (was: Pb de backport)
c'est marrant, je remonte juste d'un petit café ;-) (sans jeu de mots) On 27 Dec 2001 14:16:01 +0100 [EMAIL PROTECTED] (Jérôme Marant) wrote: J'ai compris cela depuis le début mais tu n'as toujours pas expliqué pourquoi tu veux te débarrasser de debconf sachant que ce programme occupe peu de place sur les système et peut être désactivé. ce n'est pas le programme en soit qui me gène, c'est les dépendances qui vont avec... Mais je ne vois pas en quoi avoir debconf sur ton système, même désactivé, te dérange. [en temps normal, ça ne me dérange pas ...] Pour la raison suivante : - le fonctionnement de Linux est fondamentalement basé sur la juxtaposition d'applis (ça communique ensuite par des pipes, des ports, des sockets, on s'en moque) - cette organisation est préservée dans les systèmes de packages je peux enlever un système d'impression et le remplacer par un autre, un serveur web par un autre etc etc - en particulier, __en cas de pépin__, je peux changer une roue sans démonter de manière préventive le carburateur (c'est une image...) bon, l'un de mes soucis en tant qu'admin (bénévole ;-) c'est la stabilité de mon système. Imaginons un pépin avec au hasard fileutils, (pépin d'upgrade, d'erreur de manip, on s'en moque). Evidemment je choisi fileutile parce que debconf en depend. Et bien, la moindre manip de maintenance qui remettrait en cause l'install de debconf sur cette machine, me conduit à quasiment tout désinstaller ... Debconf est une sorte de poutre qui traverse tout mon système et le rend quasi-monolitique en cas de pépin mal placé (et par application de la loi de Murphy...) J'aimerai bien avoir des exemples pour juger si debconf est réellement un obstacle . debconf n'est pas un obstacle. C'est un outil certes intéressant mais qu'il convient de replacer dans son contexte. Avant debconf, un système linux est un formidable meccano, cela doit le rester avec debconf. Debconf doit/peut être une pièce du puzzle et non pas le cadre qui recolle tout ensemble. Ce serait dommage. On doit _pouvoir_ retirer la carte debconf sans que le reste du chateau s'écroule. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: De l'interet de debconf
On Fri, 28 Dec 2001 13:36:44 +0100 Laurence Colombet [EMAIL PROTECTED] wrote: Georges Mariano a écrit: Si j'ai bien compris, le gros problème n'est pas la nécessité de debconf en soi, c'est le fait que les paquets en dépendent explicitement? Parce que, par exemple, essaye de te passer d'apt (ou de perl!) sur une Debian... oui, effectivement, on ne mets pas en général de dépendance sur ça ... (c'est indiqué dans la policy d'ailleurs) Je pense que debconf doit être vu de la même manière: un outil indispensable pour gérer les paquets (mais pas une dépendance explicite des paquets eux-mêmes, je te l'accorde). Maintenant, contrairement à apt, il est peut-être dispensable? Ça, je ne sais pas. Moi je sais que non :-) [j'ai m'impression que tu as oublié un pas non ??] Bref, debconf n'est évidemment pas indispensable au sens où une appli n'a pas besoin de lui pour être configurée (à part une appli [debian?] basée sur debconf évidemment) Pour compléter, j'ai lu hier soir par hasard quelques lignes sur la gestion des types mimes dans les paquets Debian et : * on y trouve le même aspect transversal (des applications diverses ont besoins de types mime) * la même préoccupation d'orthogonalité par rapport aux dépendances, il est dit qu'aucune dépendance ne doit être mise sur ce paquet, il faut juste tester dans les scripts d'install de paquet, l'existence de l'exécutable update-mime-type (je crois). On a donc bien un service transversal (un outil) sans avoir l'effet chateau de carte. C'est tout ce que j'espère pour debconf. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Cahier de doléances pour Debian, version
On Fri, 25 Jan 2002 10:04:02 +0100 Nicolas SABOURET [EMAIL PROTECTED] wrote: N'en déplaise à je-sais-plus-qui-l'a-dit (si ça se trouve, c'est sur-user), mais les admin que je connais ne recompilent pas les paquets. Ils font confiance à Debian parce qu'ils n'ont pas que ça a foutre. ce devait être moi (en fait, j'abondais un message précédent) [soyons honnète, je ne recompile pas _tout_] a) Je voudrais indiquer qu'il ne __s'agit pas__ d'une question de confiance lorsqu'on recompile des paquets Debian. Pour moi recompiler un paquet Debian est équivalent à recompiler un tarball dont je sais qu'il s'intégrera parfaitement dans mon système. Ce n'est pas de la défiance. b) 'apt-get source -b paquet' devrait être équivalent à 'apt-get install paquet' (sauf la question de temps bien sûr). Je parle de théorie i.e la robustesse du système de paquets doit être amenée au niveau nécessaire pour ce faire. Pour conclure, je ne recommande pas/plus la Debian comme étant hyper-stable (cela __ne peut__-être affirmer de manière absolue) mais je la recommande pour (le confort de) son système de paquets et son organisation générale. Permet moi de te corriger sur ce point, George : une Debian stable sans paquet rétroportés, si. C'est vachement plus stable que les autres. J'en ai eu la confirmation de bcp d'utilisateurs-admin. Mais tu as des softs vieux de 2 ans ... :( Evidemment, mais dans mon esprit, quand on parle de distrib linux stable ça veut dire à jour autant que possible, je ne parle pas de la stabilité de potato. C'est bien le seul laurier stable sur lequel on peut se reposer actuellement. Quand un client/utilisateur demande une distrib stable c'est évidemment pas pour avoir un truc gravé sur CD depuis deux ans... Donc, je réponds Debian, mais attention ... A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Debian goes international ?
On Tue, 29 Jan 2002 10:00:54 +0100 Martin Quinson [EMAIL PROTECTED] wrote: Par exemple il a été proposé dernièrement d'enlever l'obligation pour debian/rules d'être un fichier Makefile. Je suis assez d'accord avec cette approche : du moment que ca rend les mêmes services, on devrait pouvoir faire comme on veut. ?? le problème c'est que le du moment que ça rend les même services ne veut pas dire grand chose en l'occurrence plus précisèment chacun y mets ce qu'il veut ... L'intérêt du rules/Makefile est qu'il est difficile de trouver plus souple comme moyen d'exprimer un enchainement d'actions (make a été pensé pour ça...) et faire un paquet c'est une cuisine à base d'enchainement d'actions (chacune pouvant être quelconque [dh_*, appel du shell, d'une appli...]) Remplacer par autre chose (au hasard du perl ou tout autre interprétreur) serait stupide. J'aimerai bien voir les arguments avancés ou les solutions de remplacement envisagés... STP Martin, où as-tu vu ce genre de truc? pointeur... PS2 : s'il n'y a pas au moins un élément central commun dans le mécanisme d'empaquetage la _communauté_ des mainteneurs va exploser en petite communauté(tribus) chacune spécialisées dans sa petite méthode qui va bien ... A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Ou mettre les packages independants de l'architecture dans un repository ?
On Mon, 18 Feb 2002 20:25:09 +0100 Raphael Hertzog [EMAIL PROTECTED] wrote: Vous n'avez pas besoin de respecter une telle structure pour mettre des paquets à disposition ... il suffit de tout mettre dans un répertoire, d'y rajouter un fichier Packages.gz et d'utiliser un entrée de ce genre dans apt : deb http://www.floc.net/debian ./ petite suggestion quand on débute, y aller progressivement et passer par l'étape intermédiaire d'une source fichier de syntaxe : deb file:chemin vers le Pakages.gz ./ [et en plus ça va plus vite pour l'install de paquet en local] quand ça marche, passer à une deb http: si nécessaire (pour accès de l'extèrieur) avec le programme apt-ftparchive (paquet apt-utils). tiens, connais pas. C'est quoi la différence avec un bon vieux dpkg-scanpackages ?? Dans la foulée, même ordre de question, comment faire pour construire un Sources.gz (par ex avec dpkg-scansources ;-). Simplifions la question : existe-t-il un bref howto pour ce genre de manip ? (j'ai pas envie de lire les man de tous les dpkg-*...) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
debian et egcs 1.1
Salut, un collègue a le problème suivant : * un produit commercial (on le nomme pas, IlogViews 4.0) préconise d'utiliser (sous Linux) egcs 1.1 pour utiliser leurs librairies de développement * sur le site debian, les seuls mots explicitement relatif à egcs sont (old egcs version) (gulps ??) q1 : qu'en est-il de la relation entre gcc et egcs ? q2 : comment je traduis tout ça en termes Debian ? A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
recompilation : un grand classique
Bonjour à tous, AS : je poste sur debian-devel-french et debian-user-french, car ce message comporte à la fois une question technique mais également une indication que le problème de la compilation multi-archi ne peut se résumé à être pour ou contre comme certains voudraient le faire croire, et que donc la question n'est pas simple... tout dépend de la machine que l'on utilise. Bon, Explorant en tâche de fond la recompilation de sylpheed-claws, j'en arrive à traiter gettext (je vous passe le chemin pour en arriver là...) Je suis sur potato. Bon, apt-get source -b gettext dpkg-checkbuilddeps: Unmet build dependencies: libc6-dev (= 2.2) | libc0.2-dev (= 2.2) | libc6.1-dev (= 2.2) y a du 2.2 partout ... pas bon pour potato (2.1)... Donc, le paquet gettext n'est pas prévu pour être recompilé potato, et c'est bien dommage vu l'importance que peut avoir gettext... Sauf que, si je lance le configure (amont/upstream), il ne vérifie que : checking whether we are using the GNU C Library 2.1 or newer J'ai un peu cherché dans les bugs, je trouve que deux trucs dans le changelog * une note Added libc6.1-dev (= 2.2) to Build-Depends for alpha and ia64 * une note sur une compilation IA64, mais plus une optimisation qu'un bug quelqu'un connaitrait-il une raison pour ne pas pouvoir utiliser gettext/avec libc6 2.1 sous Debian (i386) ? La recompilation, avec 2.1, se passe apparemment bien, on obtient donc : ii gettext 0.10.40-1 ii gettext-base 0.10.40-1 ii ldso 1.9.11-9 ii libc6 2.1.3-19 Si je résume (et si j'ai bien compris) : * la dépendance sur 2.2 est __justifiée__ par les compilations sur IA64 et alpha (mais pas prévue par amont) * mais dans le même temps, cela rends la tâche délicate sur potato i386 (2.1) (mais prévue en amont) Bref, comment -tout- faire proprement ? A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: [BREVET LOGICIEL] Questionnaire : quel acteur du libre etes vous
On Fri, 08 Mar 2002 13:16:41 +0100 Nicolas SABOURET [EMAIL PROTECTED] wrote: Plusieurs problèmes se posent alors, parmis lesquels : - le terme free software fait peur aux industriels, en particulier à cause de l'ambiguité entre libre et gratuit (free en anglais). Pas vraiment, ne nous faisons pas d'illusions, s'il y des gens bien placés pour connaitre cette subtilité c'est eux !! ;-) La première chose que fait un industriel (sérieux) c'est de transmettre la licence à son service juridique... Plus prosaïquement, ce qui leur fait peur, c'est la perception qu'ils ont (erronée ou pas c'est une autre histoire!) de a) la non-stabilité du support associé aux logiciels libres b) la confusion engendrée par le nombre de versions différentes en circulation - la GPL oblige qqun qui souhaite reprendre du free software à le livrer à son tour sous GPL La GPL impose effectivement cette obligation en cas de redistribution du produit dérivé. C'est implicitement le cas pour les industriels du soft, donc ta formulation couvre en gros ce qui nous intéresse. Mais un industriel peut parfaitement se développer un produit interne à base de GPL sans aucun problème. J'espère ne pas avoir dit de bêtises, Trop ? non :-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: rétroportage de wmaker 0.80
On Thu, 28 Mar 2002 18:22:01 +0100 [EMAIL PROTECTED] (Denis Barbier) wrote: 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. Je confirme, après avoir eu le même pépin (but 'touch ltconfig' ;-), après avoir remis les version stricte potato (CD) des outils concernés, ça se passe mieux... Le hic, c'est que si j'ai upgradé le triplet (autoconf/automake/libtool) c'est parce que d'autres paquets l'exigent ...(contexte = backport dans un chroot potato-strict au départ, et je n'installe plus que ce qui est exigé par une compil) = partie remise A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
On Wed, 18 Sep 2002 22:37:21 +0200 Georges Khaznadar [EMAIL PROTECTED] wrote: (Sébastien, il est probable que tu nous lis, alors ne le prends pas mal;c) On voit vraiment pas pourquoi ... J'ai l'impression que quelques étudiants ont caressé le fantasme d'une étude qu'ils pourraient faire totalement sur documents, sans sortir de leur fauteuil, grâce à la magie du réseau internet. Peut-être une simple volonté de prendre le recul nécessaire à ce genre d'étude, une sorte d'impartialité et d'indépendance de point de vue ?? Tout le monde sait que les analystes les plus fins et les plus objectifs du monde du libre font nécessairement partie du monde du libre, comment pourrait-il en être autrement ?? ». Or il semble que les membres de la tribu sociologiste aient des aptitudes utiles, telles que lire et comprendre de l'anglais technique. Reste plus qu'à espérer que leurs aptitudes ne vont pas jusqu'à déceler les limites étroites du relationnel entretenu par les membres (certains!) de ces tribus avec le monde extèrieur (non-libre par définition)... Sébastien avait été intéressé par la possibilité de contribuer par des localisations. Donnant donnant ? Tout à fait d'accord. Libre et gratuit, ok. Mais y'a des limites quand même!! Ayant eu également l'honneur (au cas où le mot de plaisir ne serait plus compris par certaines sociétés sauvages) de discuter avec Seb, il me semble avoir déceler une curiosité sincère envers une certaine communauté. Devant son souhait d'élargir son échantillonnage, je lui ai suggéré de rencontrer d'autres personnes. Je regrette déjà mon conseil. Seb, désolé. A+ Petit exercice (facile) de sociologie appliquée : Quelle peut bien être la motivation d'un message aussi offensant, sur une liste dont ce n'est pas franchement la préoccupation principale, de la part d'un membre récemment adoubé. Sans doute le besoin irrépressible d'être reconnu par ses pairs comme partageant les mêmes valeurs? C'est pas un peu ... primitif ? PS : ah oui, surtout ne pas le prendre mal, hein ;-) Cordialement, Re-Georges -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Unidentified subject!
désolé pour le délai... problème de mail ... On Fri, 20 Sep 2002 17:21:48 +0200 Raphael Hertzog [EMAIL PROTECTED] wrote: je n'ai pas trouvé que le message de Georges Khaznadar ait été insultant envers quiconque ... Ah? tu n'as pas trouvé, ok. Mais as-tu seulement demandé au principal intéressé ?? Moi, si. Et, effectivement, le ton du message l'a ...surpris. [à ta décharge : tu ne pouvais pas savoir de qui il s'agissait exactement] le fait est qu'on peut difficilement faire plus transparent que Debian et qu'il n'est pas difficile de se plonger dedans pour voir comment cela se passe. Ça n'a (presque) rien à voir. Ce n'est pas le thème principale de l'étude de Seb. [à ta déchare : tu ne pouvais pas connaitre le sujet exact des entretiens] coordination puisque j'ai djà répondu à 4 questionnaires provenant de chez eux donc certains se recoupaient quelque peu. Euh..., t'es sûr qu'il s'agit de la même origine ?? Si j'étais toi je vérifierai ... ;-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: RESUMLE : questions de policy
Oui, il n'y a pas grand intérêt à supprimer des utilisateurs/groupes existants. ET déclarés comme étant inutiles ... Ce qui les fait tomber dans le grand sac des choses devenues inutiles dans un système et que **toutes** les docs relatives à la sécurité décrètent comme devant être éliminées. Non pas qu'un truc inutile est nécessairement et automatiquement dangereux mais surtout parce qu'il est certain qu'un élément éliminé n'introduira pas de trou de sécurité. Au contraire on peut imaginer un certain nombre de problèmes si on les supprime : en supprimant le groupe on libère un gid qui peut être attribué à un autre groupe si un autre paquet crée un groupe à la volée, imaginons ensuite qu'on veuille restaurer quelques fichiers du paquet à partir d'une sauvegarde antérieure et bien les infos user/group ne colleront pas... On peut également imaginer qu'en dehors de Debian il est possible de faire les choses proprement également... Je sais, c'est difficile à croire. On peut en effet systématiquement supprimer les uid/gid **inutiles** en respect du principe de sécurité ci-dessus. Et avoir l'idée géniale de laisser tourner le compteur des uids/gid... pour ne pas effectivement se marcher sur les pieds ultèrieurement. Si on affine l'analyse, on peut discerner deux type d'uid/gid : ceux qui sont générés par un besoin système/applicatif et les autres (les users humains) En ce qui concerne les premiers, il me semble que les numéros sont attribués de manière relativement standard (à quelques polémiques près), et donc le risque de collision est réduit et ne dépend pas de l'admin local. En ce qui concerne les seconds, sauf erreur, lors de la création le compteur est correctement incrémenté (le système ne recherche pas un id inutilisé à partir de 0). Là encore, le risque de collision est minime.(Faut le faire à la main pour avoir cette collision) Juste pour ne pas oublier la moitié des éléments de la discussion ... PS : pour être complet, le sujet initial que j'avais soulevé ne traitait que des uid applicatifs. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
imlib1 / imlib2 : compilation de paquet
Salut, je suis devant un paquet qui se compile apparemment bien avec le contexte suivant : dpkg -l | grep imlib ii gdk-imlib-dev 1.9.14-11 ii gdk-imlib2 1.9.14-11 ii imlib-base 1.9.14-11 néanmoins, quand je veux l'installer (en repassant par une source apt locale), sur la même machine, j'obtiens : Depends: gdk-imlib1-dev (= 1.9.14-8) Bon, si je comprends bien le debian/control d'origine, cette dépendance est cablée dedans ..., gdk-imlib1-dev (= 1.9.14-8), Pourtant j'ai l'impression en naviguant dans la doc du mainteneur que l'on pourrait sortir cette dépendance et la faire calculer par les dh_* (shlibs). En effet, un grep dans les *.substvars (issus de la recompilation) ne me donne que du imlib2 (et pas imlib1) Comment je m'y prends pour intégrer ça (les dépendances calculées à la volée) proprement dans le control (à la place de la dépendance cablée) ? Est-ce la bonne méthode ? Merci -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
pour info
Bonsoir les users, bonsoir les devels, Ce petit message juste pour informer les debian-user-french, qu'en ce moment même certaines personnes bien pensantes se sont mis en tête de discuter de la régulation de cette liste i.e de filtrer/trier ce qui est intéressant de ce qui ne l'est pas. Ce qui est remarquable c'est que ces personnes ne sont même pas nécessairement inscrites sur cette liste. Ce qui est **affligeant** c'est que cela se passe sur une autre liste debian !! C'est bien la première fois que je vois une liste moribonde discuter de la régulation d'une liste trop vivante. Allez faire un tour du côté des archives de ce mois pour debian-devel-french, j'ai comme l'impression que certaines illusions sociales vont tomber... Il y des jours où Debian rime avec affligeant/consternant/ etc... PS : Dans le même temps, je tiens à saluer le message de Dominique Marin qui sauve l'honneur de Debian (encore qu'il n'est sans doute pas développeur Debian), et je pèse mes mots... PS2 : et j'attends de pied ferme, le devel qui n'apprécierait pas le fait que je replace le débat à l'endroit où il doit avoir lieu (i.e. sur user-french et pas sur une île déserte). Si le débat a un sens, ce dont je doute. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Séparer debian-user-french
On Sat, 8 Mar 2003 16:32:45 -0500 Jean-Michel Kelbert [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] n'est pas séparé que je sache. C'est bien pour ça que je n'y ai pas été abonné plus de 3 jours ! D'ailleurs une telle mesure pourrait très bien s'appliquer à debian-user! excellente idée. Chiche? Mais tu poste (d'abord) la suggestion sur debian-devel, hein ? ... ...qu'on rigole un peu au passage :-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Séparer debian-user-french
On Mon, 10 Mar 2003 09:30:42 +0100 Thomas Labourdette [EMAIL PROTECTED] wrote: Avec des liens vers les documents utils aux débutants et l'envoyer automatiquement à chaque nouvel abonné. Ben oui, d'autres idées du même style ont été évoquées dans le passé mais elles partagent la caractéristique que leur implémentation **propre** nécessite une intervention au niveau de la gestion de la liste. Or, en dépit des multiples tentatives de personnes au fait des méandres bureaucratique Debian, aucune n'a eu de résultat. Alors au lieu de taper vers la «debian d'en-bas» serait peut-être bien aussi d'utiliser correctement le système «d'en haut» (i.e la messagerie). Et si ce débat avait pour conséquence que quelques @debian.org aboutissent enfin à un résultat sur ce plan, je serais le premier à applaudir. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: pour info
On Mon, 10 Mar 2003 11:17:03 +0100 Laurence Colombet [EMAIL PROTECTED] wrote: Répondre à un débutant, ça prend du temps, parfois on en a marre et on a envie de se changer les idées, mais c'est valorisant. Mais répondre à un neuneu? Ce n'est que du bruit et de la perte de temps. Tout le monde est d'accord sur ce point (il me semble) alors passons aux faits : Combien de *véritables* neuneus se sont manifestés sur cette liste depuis ... le 1er janvier 2003 ? (deux, trois ?) et combien de débutants ? (des dizaines probablement) J'aimerai bien avoir des chiffres tangibles car la dernière fois qu'on nous a fait le coups, c'était pour y voir clair entre les thèmes devel et user, la séparation s'est faite. ok. Chacun peut observer le résultat : le trafic de devel est léger. (sauf quand on y parle de duf ;-) Quel est le véritable gain ? A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: debian/ et upstream
Tous ça pour dire que même entre fichiers .deb il peut y avoir des problèmes si ils ne font pas parti de la même distribution, homogène et suivant des règles communes. Ben c'est quand même prévisible, non ? du temps où j'utilisais du Ximian, ça marchait bien. Évidemmment, je _savais_ qu'en faisant des mixtures je prenais des risques... et donc, à un moment donné j'ai fais la bascule. Point. Et même si l'upstream avait inclu un debian/ rien ne dit que Debian et/ou Ximian ne le modifiront pas en fonction de règles différentes. Euh, dans mon esprit, en supposant qu'upstream fasse correctement les choses (c'est souvent le cas non ?;-), je supposais qu'a priori le debian/ était celui de la debian oficielle, éventuellement maintenu par le DD officiel... Et je suppose qu'il ne serait pas difficile de trouver un exemple où le paquet fait par upstream serait plus correct que celui fait par un DD... ;-) Mais bon tous ça c'est des suppositions et quasiment des procès d'intention (bonnes ou mauvaises), ça n'explique toujours pas en quoi _techniquement_ (i.e objectivement == sans *pré*juger la qualité du résultat) ce serait un problème... Que certains utilisent cela à mauvais escient, c'est une fatalité (on peut obtenir les mêmes bétises à partir d'un apt-get source !) En cas de divergence entre upstream et debian, où est le problème ? actuellement un DD récupère les sources et y place son debian/, pourquoi cela serait soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? A+ -- mailto:[EMAIL PROTECTED] debfr-faq http://savannah.nongnu.org/download/debfr-faq/html/
Re: debian/ et upstream
Selon Sven Luther [EMAIL PROTECTED]: soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? Ca pollue le .diff.gz et rend les choses plus difficile pour le mainteneur. hmm, oui, tiens... à quel moment le diff.gz entre-t-il dans la danse ? il n'est généré qu'à la construction du paquet n'est-ce pas ? (inutile de le stocker?) Si upstream souhaite maintenir un repertoire debian, il faut souvent mieux qu'il le maintienne directement sous un autre nom (deb par exemple) que le mainteneur peut utiliser ou pas. i.e le nom est indifférent donc ... (tiens, est-ce paramétrable dans les outils ?) Ou encore, on peut arriver a une situation ou upstream devienne co-mainteneur du package, et que le mainteneur deviennent son sponsor. oui, c'est un scenario sain (et préférable évidemment). Mais nous sommes bien d'accord(?), c'est pas une difficulté technique... A+ -- mailto:[EMAIL PROTECTED] debfr-faq http://savannah.nongnu.org/download/debfr-faq/html/
Abime de perplexité...
Bonjour à tous, Je vous fait le film au ralenti. Soit un paquet A. Je souhaite l'installer après recompilation donc : apt-get source -b A (les sources sont pris dans sid) processus de recompilation enclenché phase de configuration ok compilation , 1ère ligne erreur ! : make[1]: *** Pas de règle pour fabriquer la cible `error.c', nécessaire pour `.build'. Arrêt. là où c'est plus perplexant... c'est qu'avec tout paquet source est fournie une archive des sources upstream d'origine... ...par curiosité, je lance les classiques ./configure ; make (pas make install), et ô surprise ça marche impeccablement! [je recompile même (au préalable pour vérification) une libreadline4 indiquée dans les dépendances, au cas où... (je sais vu l'erreur, c'est ridicule mais bon, on sait jamais)] Ce genre de manip à une furieuse tendance à faire surgir en moi une foultitude de questions, mais allons à l'essentiel: il me semble que le mainteneur du paquet a probablement modifier un peu plus que ce qu'il aurait du, vu que la compile upstream fonctionne sur ma machine alors que, dans le même temps, je ne peux plus reconstruire le paquet Debian (ou alors il me manque une marche...) indice : dans le diff fourni, il est visible que le configure.in, le aclocal.m4 ont été modifiés (entre autres)... ok. Mais justement, pourquoi ? (puisque sans modif ça passe [chez moi]...) (ah, l'erreur est identique aue ce soit sur une woody ou une potato) 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... Autre formulation : comment s'exprime le bug à envoyer pour ce package ?? PS : je poste également sur debian-user cette question plutôt devel, pour avoirune réponse plus ... intuitive ;-) A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: Abime de perplexité...
On Wed, 14 Nov 2001 14:07:54 +0100 Nicolas SABOURET [EMAIL PROTECTED] wrote: Package: bash Version: 2.05-10 ... However, when using the upstream source given in .orig.tar.gz, I don't encounter any problem (either or woody or potato) using ./configure;make Oui, c'est une solution... mais j'appelle pas ça un rapport de bug pertinent. Comment dire, ça doit pas être très satisfaisant côté développeur comme info ... Pour moi un bug se défini par rapport à un comportement attendu ou une norme à respecter (charte). Si je devais formuler le comportement attendu ici ce serait qqchose comme : tout paquet Debian fourni avec des sources originaux, pour lesquels les phases de configuration et compilation sont fonctionnelles doit lui-même présenter des phases de configuration et compilation fonctionnelles (évidemment sous réserves du respect des dépendances spécifiées). NB : la phase de mise en paquet n'est pas concernée. La question que je me pose est : est-ce que cette formulation est correcte ? (et _donc_ je suis fondé à poster un bug tel que proposé par Nicolas, sans plus d'analyse) ou a contrario, dans quels cas cette formulation n'est elle pas valide ? (et là ...) Corollaire : est-ce que ce genre de règle est édicté quelquepart ? je ne parle pas des règles pour les paquets entre eux mais de règles qui relient les fonctionnalités des applis upstream et les fonctionalités des paquets livrés aux clients, euh, je voulais dire utilisateurs ? A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
