Re: backport Imagemagick
Le Thu, Oct 25, 2001 at 10:03:51PM +0200, georges mariano écrivait: > 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... Et là je suis 100% contre, en faisant cela, on ne passe jamais aux nouvelles versions des bibliothèques, et on ne bouge pas. Un développeur doit compiler sur unstable. Et même testing c'est limite dans certains cas. Ce ne veut pas dire qu'il doit faire exprès d'emmerder les utilisateurs qui veulent recompiler sur potato ... :-) les problèmes de recompilation, tu peux difficilement les éviter ... surtout quand on a de si grands écarts (temporels et fonctionnels) entre deux versions successives de Debian. A+ -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: backport Imagemagick
On Thu, Oct 25, 2001 at 10:03:51PM +0200, georges mariano wrote: > 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... Ah ? Je vais essayer d'être plus clair alors. Ce problème n'a rien à voir avec la release, mais avec les programmes installés sur la machine. Si tu as libmagick5-dev, ça compile, sinon non. Denis
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
On 25 Oct 2001 08:53:11 +0200 [EMAIL PROTECTED] (Jérôme Marant) wrote: JM > > plantage cause qu'un fichier po tchèque je crois avait une erreur de syntaxe JM > > [évidemment 'rm le-dit-fichier.po' ... euh, y'a un rapport avec perl ?] JM > > le plus marrant c'est le nom du mainteneur debconf...) JM > JM > Qu'est ce que tu racontes ? Je raconte qu'un paquet source __grossièrement__ mal foutu est arrivé a) dans sid et b) dans woody (avec les 15 jours de décalage !?) et là je comprends pas comment on peut passer à côté de ça... et le mainteneur est un grand monsieur de chez Debian... ça me "surprend". C'est ça que je raconte... JM > > i.e suffit pas de balancer les initiales Q.A sur un site web pour s'approprier JM > > le sens véritable de ces initiales... autant pas les mettre. JM > JM > Il faudrait déjà que tu lises ce qu'il y a d'écrit sur le site web JM > avant balancer des inepties. Dans ma naïveté je pensais que des tests relativements simples et imparables étaient effectués avant de "valider" un paquet... maintenant je doute... Et l'existence d'une QA Team me semble dérisoire par rapport à ce que je constate sur certains paquets, c'est tout. Cela peut effectivement être pris comme une inepsie pour certains. JM > > NS > Qui essaye de calmer GM :) JM > > euh, t'as rien de mieux à faire ?? (de plus constructif surtout ;-) JM > > :) JM > JM > Il essaie de répondre à tes questions, estime-toi heureux. JM > Essaie au moins pour une fois de respecter les gens qui tentent de t'aider. Arghh je pensais avoir suffisamment mis de smiley (2!) pour éviter l'ambiguité mais bon... je voulais dire que Nico a sûrement des trucs plus intéressants à faire que de calmer un GM énervé (mission impossible ;-) J'espère que Nico ne l'a pas aussi mal pris... c'était pas le but, désolé. Tu dis également qu'un paquet woody est pas fait pour être recompilé sous potato. J'en déduis que tu as compris le point de départ de mes inepties! C'est justement ça que je conteste (même si ça n'énerve que moi ...) Ce qui apparemment ne te perturbe pas bcp, moi ça me choque ... D'autant plus que compte tenu de l'écart entre deux versions "stables" Debian, cela me semble une incongruité... À croire que la vie d'un utilisateur quotidient Debian n'intéresse pas franchement les têtes pensantes entre deux releases officielles. J'ai dis "utilisateur" pas "testeur/debuggeur" ... -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
Re: french : une décision à prendre
Le Thursday 25 October 2001 à 08:56:34, Nicolas SABOURET a écrit: > Je vais suivre le conseil de Denis et contacter le mainteneur de > modconf. > Je vous tiens au courant (si ça vous intéresse, bien sûr). Oui ça m'intéresse. Il y a aussi le même problème avec dpkg-reconfigure(8). $ LANG=fr_FR.ISO-8859-1 sudo dpkg-reconfigure libtowitoko2 OK, questions en français $ LANG=french sudo dpkg-reconfigure libtowitoko2 Pas OK. Questions en anglais :-( Donc je reste en LANG=fr_FR.ISO-8859-1 Désolé si le problème est déjà connu. Je ne lis debian-devel que depuis le début du mois cad après la bataille. -- Ludovic Rousseau [EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le Camembert, L.R. --
GRUB pour l'install
Salut, J'ai apporté des modifications au GRUB pour permettre de l'utiliser sur disquettes au format inhabituel (1.68, 1.74Mo par exemple) et surtout, pour le faire fonctionner sur CD, en permettant --- c'est le plus intéressant --- de créer une image de disque virtuel, qui fonctionne avec El Torito, et qui permet de s'affranchir des limites en taille des images 1.44 ou 2.88Mo. Ce qui permettrait à Debian --- ou à d'autres --- d'avoir quelque chose de plus flexible que Syslinux, autorisant des choix quasi illimités entre plusieurs combinaisons de noyau/initrd plus écrans d'aide. J'aimerais avoir des testeurs. Les patches du GRUB sont là : http://alpha.polynum.org/misc/grub-cd+extfloppy-20011021.diff.gz La doc (grub-howto à jour) est là : http://doc.polynum.org/howto/grub/grub-howto.html [en ligne] http://doc.polynum.org/howto/grub/grub-howto.html.tar.gz [le tout] et le script pour générer les disques virtuels amorçables est là : http://corpus.polynum.org/admin/mkbimage Bienvenue aux aventuriers -- Thierry Laronde (Alceste) <[EMAIL PROTECTED]> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[Fwd: Bug#114057: A proposition]
Et hop ! C'est dans la poche !!
:)
j'ai gardé le mail d'Eduard. Si vous avez d'autres applis sous Woody qui
ne marchent pas avec l'alias french, je peux leur envoyer un rapport de
bug avec le diff d'Eduard.
Prévenez-moi seulement, et je le ferai.
A+,
Nico.
--
Nicolas SABOURET
LIMSI-CNRS, BP133, 91403 Orsay, France
http://www.limsi.fr/Individu/nico--- Begin Message ---
tags 114057 +pending
quit
#include
Nicolas SABOURET wrote on Thu Oct 25, 2001 um 09:07:09AM:
> The idea we had, that would not make much work for you and that would
> satifsy all "french" (whatever it is) users is the following : simply
> test wether /etc/locale.alias exists and if it does, try to replace the
> value of LANG by its "real" value given in this file. If it does not
> exist (which is the cas at initial installation), work with LANG's value
> (whivh is fr_FR as far as I understand).
Done and commited to CVS. Wait for someone to build a package of it. If it
is not happened in 1-2 weeks make some noise.
--- modconf.origThu Oct 25 10:07:52 2001
+++ modconf Thu Oct 25 10:31:21 2001
@@ -9,6 +9,11 @@
umask 022
+# preparations, resolve the LANG alias
+if grep "^$LANG" /etc/locale.alias >/dev/null 2>&1; then
+ export LANG=$(grep "^$LANG" /etc/locale.alias| sed -e 's/.*\(.._.*\).*/\1/')
+fi
+
source_eval () {
if [ -z "$LANG" -a -z "$LC_MESSAGES" ]; then
. $ModuleHelpDir/eval_C
Gruss/Regards,
Eduard.
--
"640K ought to be enough for anybody" -Bill Gates, 1981
--- End Message ---
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
Re: NMU d'automake
En réponse à Denis Barbier <[EMAIL PROTECTED]>: > 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 ? C'est une solution qui ne me plait pas trop (même si je ne suis pas un utilisateur de automake). La solution serait plutôt de rédiger un petit HOWTO-passer-à-automake1.5 puis de garder la 1.4 en la renommant automake1.4, à l'image de ce qui avait été décidé pour autoconf 2.13 et autoconf 2.5. Par contre, je n'ai effectivement pas tous les détails techniques en main permettant de dire si ma solution est meilleure que celle de AJ. > Ç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 ? > 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. Pareil, il ne me semble pas avoir vu passer quoique ce soit. > Est-ce une attitude normale de la part d'A.T. ? J'imagine qu'il a demandé au responsable d'automake la permission de faire cela. En revanche, je ne suis pas sûr que cela rentre dans le cadre des NMU. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
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: french : une décision à prendre
jo wrote: > > Comme je l'avais déjà signalé à Nicolas, il est possible de contourner le > problème en mettant > LANG=fr_FR* > LC_ALL=french > > dans /etc/environment. > Cela correspond à ce que j'appelle la solution 1 (pas d'alias). Si tu met LANG à fr_FR*, et si french est un alias pour ce même fr_FR* (ce qui serait logique), alors ni LC_ALL ni l'alias ne servent plus à rien. Je vais suivre le conseil de Denis et contacter le mainteneur de modconf. Je vous tiens au courant (si ça vous intéresse, bien sûr). Nico. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: backport Imagemagick
georges mariano wrote: > > On Wed, 24 Oct 2001 17:53:39 +0200 Nicolas SABOURET <[EMAIL PROTECTED]> > wrote: > > NS > > N'importe quoi. > NS > Bah non. C'est normal parce que tout perl a changé ! > > Les changements de perl ont donc un lien avec : > - la valeur "vendor" qui produit une cible Makefile qui n'existe pas ? > (la valeur "site" passe ... elle) > Oui. > - ce genre d'erreur également (je garantis pas les retours à la ligne...) ?? > > dh_movefiles: debian/imagemagick//usr/share/man/man3/Image::Magick.3pm not > found Je pense que oui. > > NS > Bah ... de Woody ? Je comprends pas ta question. On peut compiler un > NS > paquet sous Woody aussi :) > Perdu ... je sais _aussi_ recompiler sur woody (trop fort!!!) > L'erreur obtenue est la première de la liste donnée [...] Je n'avais vraiment pas compris ta question (le "de Woody, c'était pour rire, et pour montrer que je n'avais pas compris). Je sais bien que tu n'es pas un newbie. Je pense que personne ici n'a cette impression !! Tu demandais : "D'où viennent les paquets binaires ?". Je n'avais pas compris de quels paquets il s'agissait. Maintenant, ce que j'ai compris, c'est que tu as aussi essayé de recompiler le truc sous Woody, et que tu as qd même des erreurs. C'est ça ? > Juste pour me convaincre/calmer : quelqu'un peut-il faire un > "apt-get source -b imagemagick" ?? ... sur une woody évidemment !! C'est ça que je n'avais pas compris. Au départ, tu étais sur Potato et j'ai du louper le passage ou tu arrêtait de backporter le monde :) echo "Backport the world" :) > [évidemment 'rm le-dit-fichier.po' ... euh, y'a un rapport avec perl ?] > le plus marrant c'est le nom du mainteneur debconf...) > Accorde au moins le droit à l'erreur aux mainteneurs... C'est vrai que celle-là est pas mal, mais un paquet testing n'est pas obligatoirement parfait ... > euh, t'as rien de mieux à faire ?? (de plus constructif surtout ;-) Je trouvais juste que la critique sur l'impossibilité de recompiler les paquets est fondée. L'exemple (utilisant perl) était mauvais, mais je crois que c'est un problème général et puisqu'on est sur devel, on devrait pouvoir en parler. Nico. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: backport Imagemagick
georges mariano <[EMAIL PROTECTED]> writes: > NS > > Parait qu'il y a une équipe assurance qualité chez Debian ?? > NS > > NS > Je ne pense pas que qa soit en cause. C'est plutôt tous les mainteneurs > NS > (nous) qui recompilons nos paquets sous Woody, créant ainsi des > NS > dépendances trop fortes. > arggg c'est marrant la dernière fois que j'ai dis ça (quasi mot pour mot) > je me suis fais incendier ...(j'exagère juste un peu...) Les paquets destinés à testing/unstable ne sont pas fait pour être backportés. Nous avons déjà assez de travail avec unstable. Si on devait mettre les versions de dépendance à la main, et compiler avec des vieilles versions de bibliothèques, on en serait encore à la libc5 et consort. > Bon ceci dit, je voulais dire que je me pose la question de savoir pourquoi > y'a des paquet qui arrivent dans woody alors qu'ils ne se recompilent > pas automatiquement ... (autre exemple ? debconf, il y a quelques temps, > plantage cause qu'un fichier po tchèque je crois avait une erreur de syntaxe > [évidemment 'rm le-dit-fichier.po' ... euh, y'a un rapport avec perl ?] > le plus marrant c'est le nom du mainteneur debconf...) Qu'est ce que tu racontes ? > i.e suffit pas de balancer les initiales Q.A sur un site web pour s'approprier > le sens véritable de ces initiales... autant pas les mettre. Il faudrait déjà que tu lises ce qu'il y a d'écrit sur le site web avant balancer des inepties. > NS > Qui essaye de calmer GM :) > euh, t'as rien de mieux à faire ?? (de plus constructif surtout ;-) > :) Il essaie de répondre à tes questions, estime-toi heureux. Essaie au moins pour une fois de respecter les gens qui tentent de t'aider. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
