Désolé, j'ai écrit ce texte pour les groupes anglos et je n'ai pas le
goût de traduire. S'il y a un volontaire, pas de problème.
GP
-------------
Recently, I discoved I couldn't have swaret to check gpg signatures.
So, I wrote on the swaret forum to see what kind of help I could get.
Here's the discussion with a moderator and, then, with the administrator:
Whole thread available at:
http://swaret.sourceforge.net/index.php?name=PNphpBB2&file=viewtopic&t=69
-----------------------------------
Posted: Sep 21, 2004 - 02:19 PM
I use swaret 1.6.2-1 and tried to get swaret to check the gpg signature.
"swaret --gpg -i" either on a CD or a mirror retourned "DONE", no
problem.
But when I try to update, I get "CORRUPTED" on all files. Anything I'm
missing?
Otherwise, swaret is great... and, for once, the documentation has
been written by somebody with some writing capabilities.
Mr Cottyn contributed more to Slackware than anybody else. Many people
have adopted Slackware because of him and I, for one, would certainly
have moved to another distro if it hadn't been for swaret.
When the /feud/ began, his project was to make Slackware even more
powerful by offering network upgrades.
It's been a long time since we've heard from him and I'm truly worried.
Gilles Pelletier
La Masse Critique
http://www.enter-net.com/~gpelleti
-----------------------------
The moderator, a certain lennard, suggested that I download the key,
then import it with the command:
swaret --gpg -i gpg-key
I did comply but I couldn't figure what difference it would make
since, as I explained in my message, I had no problem importing the
key directly. And, indeed, I still got the same error message afterwards.
lennard then answered:
"Try to remove your /var/swaret directory. (in case of some
caching-thingies and all)
After that update your Swaret, (and update the GPG-KEY again, as
described before) and try an upgrade."
-------------------------
Getting frustrated by this nonsense, I answered:
"Thanks for your "caching-thingies" suggestion, but I don't remember
Cottyn playing caching-thingies.
Just as the preceding, this advice is no advice."
-------------------------
The LinuxSneaker, the administrator, then moved in:
"I think what he was trying to say was in case there was some stale
lock files, but I don't think that would effect the gpg and md5
situation.
I am rewriting the download function, and I will have these assumptions:
md5 is used to check completeness
gpg is used to check security
------------------------------
"md5 is used to check completeness" ??? What the hell is this? Of
course, if a file is incomplete, the md5sum, won't check OK.
But what's all this "assumptions" mumbo-jumbo about? No assumptions
are needed. You plainly need to have md5sum check md5sum and gpg check
signatures. That's it, that's all.
As surely as one and one is two, this kind of nonsense indicates that
Luc Cottyn is not around. The people who are now running the site
are exactly the kind that apparently first got Cottyn infuriated. I
certainly wouldn't be caught dead downloading anything from
swaret.sourceforge.net at the present time, not even from sourceforge,
for that matter.
Sourceforge, where a lot of noise was made around nullities such as
slapt-get, is apparently satisfied with this new state of affairs.
They're glad they got rid of Cottyn, the guy who was apparently so
stupid as to insult people all over the place without even attempting
to hide his IP address.
Patrick Volkerding removed swaret from Slackware 10 without a shade of
a comment. The rumor was Luc Cottyn was labeled "irresponsible". An
"irresponsible" had produced an upgrade tool eons ahead of PV's own
pkgtool.
Just as if I hadn't noticed anything wrong in LinuxSneaker's answer, I
asked one again about Cottyn:
"Thank you for your answer, LinuxSneaker.
As you've noticed, my question was twofold. The second part was
concerning Luc Cottyn.
Is he still participating to the project? Where can he be reached?
What about his project concerning network upgrades?"
-------------------------
I posted my question on Sept. 28 in the morning. As of Oct 2nd, 23h, I
got no answer. Who is Cottyn, where is Cottyn, this guy who was about
to provide Slackware with a network upgrade tool when the /feud/
began, nobody knows, nobody worries. Cottyn was an irresponsible.
Dans le fichier français, au sujet de GPG, on retrouve: T<E9>l<E9>chargement du fichier de Signature GPG pour %X..." MSG_VGPGSIG="V<E9>rification de la Signature GPG '%X'..." MSG_GPGCHECK_PAT="Controle de Signature GPG pour Patch %X..." MSG_GPGCHECK_PAC="Controle de Signature GPG pour Package %X..."
Oui mais ça concerne le parmétrage de langue de swaret, qui se base sur son fichier de conf pour ça, et pas sur les variables d'environnement standard comme $LANG et $LC_ALL, qui elles ont un effet sur le comportement de GNUpg par contre...
Donc, la possibilité de vérifier les signatures avec GPG a été envisagée pour d'autres langies que l'anglais. En plus, le problème que tu exposes devrait se présenter avec toutes les langues, sauf l'anglais.
Mais c'est le cas, n'en doute pas. Toutes les langues pour lesquelles GNUpg a des messages traduits, en tout cas.
Et tu penses vraiment que si Luc Cottyn était LinuxSneaker, au lieu de se lancer dans des «assumptions», il n'aurait pas trouvé la solution au problème bien avant toi?
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai proposé une solution (plutôt un hack, mais sans doute fonctionnel), à eux de l'implémenter en espérant qu'ils réagissent à mon post...
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Tue, 05 Oct 2004 15:01:39 -0400, GP a écrit :
Dans le fichier français, au sujet de GPG, on retrouve:
T<E9>l<E9>chargement du fichier de Signature GPG pour %X..."
MSG_VGPGSIG="V<E9>rification de la Signature GPG '%X'..."
MSG_GPGCHECK_PAT="Controle de Signature GPG pour Patch %X..."
MSG_GPGCHECK_PAC="Controle de Signature GPG pour Package %X..."
Oui mais ça concerne le parmétrage de langue de swaret, qui se base sur
son fichier de conf pour ça, et pas sur les variables d'environnement
standard comme $LANG et $LC_ALL, qui elles ont un effet sur le
comportement de GNUpg par contre...
Donc, la possibilité de vérifier les signatures avec GPG a été
envisagée pour d'autres langies que l'anglais. En plus, le problème
que tu exposes devrait se présenter avec toutes les langues, sauf
l'anglais.
Mais c'est le cas, n'en doute pas. Toutes les langues pour lesquelles
GNUpg a des messages traduits, en tout cas.
Et tu penses vraiment que si Luc Cottyn était LinuxSneaker, au lieu de
se lancer dans des «assumptions», il n'aurait pas trouvé la solution
au problème bien avant toi?
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai
proposé une solution (plutôt un hack, mais sans doute fonctionnel), à
eux de l'implémenter en espérant qu'ils réagissent à mon post...
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Dans le fichier français, au sujet de GPG, on retrouve: T<E9>l<E9>chargement du fichier de Signature GPG pour %X..." MSG_VGPGSIG="V<E9>rification de la Signature GPG '%X'..." MSG_GPGCHECK_PAT="Controle de Signature GPG pour Patch %X..." MSG_GPGCHECK_PAC="Controle de Signature GPG pour Package %X..."
Oui mais ça concerne le parmétrage de langue de swaret, qui se base sur son fichier de conf pour ça, et pas sur les variables d'environnement standard comme $LANG et $LC_ALL, qui elles ont un effet sur le comportement de GNUpg par contre...
Donc, la possibilité de vérifier les signatures avec GPG a été envisagée pour d'autres langies que l'anglais. En plus, le problème que tu exposes devrait se présenter avec toutes les langues, sauf l'anglais.
Mais c'est le cas, n'en doute pas. Toutes les langues pour lesquelles GNUpg a des messages traduits, en tout cas.
Et tu penses vraiment que si Luc Cottyn était LinuxSneaker, au lieu de se lancer dans des «assumptions», il n'aurait pas trouvé la solution au problème bien avant toi?
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai proposé une solution (plutôt un hack, mais sans doute fonctionnel), à eux de l'implémenter en espérant qu'ils réagissent à mon post...
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Emmanuel Florac
Le Tue, 05 Oct 2004 15:42:29 +0000, Pablo Saratxaga a écrit :
Non. LANG est de toutes les variables relatives à l'internationalisation celle qui a la plus faible priorité; il suffit qu'une autre soie definie pour que LANG n'aie aucun effet.
BOn,bon, enfin en tout cas on a saisi l'idée générale...
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Tue, 05 Oct 2004 15:42:29 +0000, Pablo Saratxaga a écrit :
Non.
LANG est de toutes les variables relatives à l'internationalisation
celle qui a la plus faible priorité; il suffit qu'une autre soie definie
pour que LANG n'aie aucun effet.
BOn,bon, enfin en tout cas on a saisi l'idée générale...
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Tue, 05 Oct 2004 15:42:29 +0000, Pablo Saratxaga a écrit :
Non. LANG est de toutes les variables relatives à l'internationalisation celle qui a la plus faible priorité; il suffit qu'une autre soie definie pour que LANG n'aie aucun effet.
BOn,bon, enfin en tout cas on a saisi l'idée générale...
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
GP
Emmanuel Florac wrote:
Dans le fichier français, au sujet de GPG, on retrouve: T<E9>l<E9>chargement du fichier de Signature GPG pour %X..." MSG_VGPGSIG="V<E9>rification de la Signature GPG '%X'..." MSG_GPGCHECK_PAT="Controle de Signature GPG pour Patch %X..." MSG_GPGCHECK_PAC="Controle de Signature GPG pour Package %X..."
Oui mais ça concerne le parmétrage de langue de swaret, qui se base sur son fichier de conf pour ça, et pas sur les variables d'environnement standard comme $LANG et $LC_ALL, qui elles ont un effet sur le comportement de GNUpg par contre...
Je comprends bien cela. Ce que je veux dire, c'est que Cottyn prenait les traductions à coeur et qu'il était en contact avec des gens qui auraient dû normalement lui faire observer le problème.
En fait, une des choses notées au changelog de 1.6.2-1, si je me souviens bien, est une contribution pour apporter un fix à la vérification des signatures gpg. Seulement, tout s'est arrêté là.
Donc, la possibilité de vérifier les signatures avec GPG a été envisagée pour d'autres langies que l'anglais. En plus, le problème que tu exposes devrait se présenter avec toutes les langues, sauf l'anglais.
Mais c'est le cas, n'en doute pas. Toutes les langues pour lesquelles GNUpg a des messages traduits, en tout cas.
Et tu penses vraiment que si Luc Cottyn était LinuxSneaker, au lieu de se lancer dans des «assumptions», il n'aurait pas trouvé la solution au problème bien avant toi?
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai proposé une solution (plutôt un hack, mais sans doute fonctionnel), à eux de l'implémenter en espérant qu'ils réagissent à mon post...
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/, évidemment, introduit des back-doors.
Quant à moi, la réponse qu'il m'a faite témoigne de ce que LinuxSneaker, le nouveau grand patron, n'a pas les compétences requises pour s'occuper de swaret. Dommage que Cottyn ait été un tel irresponsable et que tout le monde se foute d'où il est passé...
Veux-tu cosigner mon message original si je l'envoie à PV?
GP
Emmanuel Florac wrote:
Dans le fichier français, au sujet de GPG, on retrouve:
T<E9>l<E9>chargement du fichier de Signature GPG pour %X..."
MSG_VGPGSIG="V<E9>rification de la Signature GPG '%X'..."
MSG_GPGCHECK_PAT="Controle de Signature GPG pour Patch %X..."
MSG_GPGCHECK_PAC="Controle de Signature GPG pour Package %X..."
Oui mais ça concerne le parmétrage de langue de swaret, qui se base sur
son fichier de conf pour ça, et pas sur les variables d'environnement
standard comme $LANG et $LC_ALL, qui elles ont un effet sur le
comportement de GNUpg par contre...
Je comprends bien cela. Ce que je veux dire, c'est que Cottyn prenait
les traductions à coeur et qu'il était en contact avec des gens qui
auraient dû normalement lui faire observer le problème.
En fait, une des choses notées au changelog de 1.6.2-1, si je me
souviens bien, est une contribution pour apporter un fix à la
vérification des signatures gpg. Seulement, tout s'est arrêté là.
Donc, la possibilité de vérifier les signatures avec GPG a été
envisagée pour d'autres langies que l'anglais. En plus, le problème
que tu exposes devrait se présenter avec toutes les langues, sauf
l'anglais.
Mais c'est le cas, n'en doute pas. Toutes les langues pour lesquelles
GNUpg a des messages traduits, en tout cas.
Et tu penses vraiment que si Luc Cottyn était LinuxSneaker, au lieu de
se lancer dans des «assumptions», il n'aurait pas trouvé la solution
au problème bien avant toi?
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai
proposé une solution (plutôt un hack, mais sans doute fonctionnel), à
eux de l'implémenter en espérant qu'ils réagissent à mon post...
Et tu vas relire toutes les 7000 lignes de code pour voir si ces
idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/,
évidemment, introduit des back-doors.
Quant à moi, la réponse qu'il m'a faite témoigne de ce que
LinuxSneaker, le nouveau grand patron, n'a pas les compétences
requises pour s'occuper de swaret. Dommage que Cottyn ait été un tel
irresponsable et que tout le monde se foute d'où il est passé...
Veux-tu cosigner mon message original si je l'envoie à PV?
Dans le fichier français, au sujet de GPG, on retrouve: T<E9>l<E9>chargement du fichier de Signature GPG pour %X..." MSG_VGPGSIG="V<E9>rification de la Signature GPG '%X'..." MSG_GPGCHECK_PAT="Controle de Signature GPG pour Patch %X..." MSG_GPGCHECK_PAC="Controle de Signature GPG pour Package %X..."
Oui mais ça concerne le parmétrage de langue de swaret, qui se base sur son fichier de conf pour ça, et pas sur les variables d'environnement standard comme $LANG et $LC_ALL, qui elles ont un effet sur le comportement de GNUpg par contre...
Je comprends bien cela. Ce que je veux dire, c'est que Cottyn prenait les traductions à coeur et qu'il était en contact avec des gens qui auraient dû normalement lui faire observer le problème.
En fait, une des choses notées au changelog de 1.6.2-1, si je me souviens bien, est une contribution pour apporter un fix à la vérification des signatures gpg. Seulement, tout s'est arrêté là.
Donc, la possibilité de vérifier les signatures avec GPG a été envisagée pour d'autres langies que l'anglais. En plus, le problème que tu exposes devrait se présenter avec toutes les langues, sauf l'anglais.
Mais c'est le cas, n'en doute pas. Toutes les langues pour lesquelles GNUpg a des messages traduits, en tout cas.
Et tu penses vraiment que si Luc Cottyn était LinuxSneaker, au lieu de se lancer dans des «assumptions», il n'aurait pas trouvé la solution au problème bien avant toi?
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai proposé une solution (plutôt un hack, mais sans doute fonctionnel), à eux de l'implémenter en espérant qu'ils réagissent à mon post...
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/, évidemment, introduit des back-doors.
Quant à moi, la réponse qu'il m'a faite témoigne de ce que LinuxSneaker, le nouveau grand patron, n'a pas les compétences requises pour s'occuper de swaret. Dommage que Cottyn ait été un tel irresponsable et que tout le monde se foute d'où il est passé...
Veux-tu cosigner mon message original si je l'envoie à PV?
GP
Jérémy JUST
On Tue, 05 Oct 2004 18:41:35 -0400 GP wrote:
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/, évidemment, introduit des back-doors.
Slackware, ça se réduit donc à une lutte entre un certain Cottyn et les forces du Mal? Pas de pot que les forces du Mal aient colonisé le monde entier et séquestré Cottyn...
Dommage que Cottyn ait été un tel irresponsable
D'un autre côté, seul contre tous, il ne pouvait pas faire grande chose.
et que tout le monde se foute d'où il est passé...
Normal: le Monde a été assimilé par les forces du Mal.
Au fait: vu de loin, le hack d'Emmanuel semble facile à implémenter grossièrement (quitte à écrire un simple wrapper en shell autour de de swaret). Alors si tu crains tant que quelqu'un ne détourne ton outil fétiche, il te suffit de rester à la même version et de te retrousser un rien les manches.
Avec un peu plus de courage, tu pourrais même forker le développement swaret, au lieu de dénoncer une coalition maléfique imaginaire.
-- Jérémy JUST
On Tue, 05 Oct 2004 18:41:35 -0400
GP <gilpel@inverse.nretla.org> wrote:
Et tu vas relire toutes les 7000 lignes de code pour voir si ces
idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/,
évidemment, introduit des back-doors.
Slackware, ça se réduit donc à une lutte entre un certain Cottyn et
les forces du Mal?
Pas de pot que les forces du Mal aient colonisé le monde entier et
séquestré Cottyn...
Dommage que Cottyn ait été un tel irresponsable
D'un autre côté, seul contre tous, il ne pouvait pas faire grande
chose.
et que tout le monde se foute d'où il est passé...
Normal: le Monde a été assimilé par les forces du Mal.
Au fait: vu de loin, le hack d'Emmanuel semble facile à implémenter
grossièrement (quitte à écrire un simple wrapper en shell autour de de
swaret). Alors si tu crains tant que quelqu'un ne détourne ton outil
fétiche, il te suffit de rester à la même version et de te retrousser un
rien les manches.
Avec un peu plus de courage, tu pourrais même forker le développement
swaret, au lieu de dénoncer une coalition maléfique imaginaire.
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/, évidemment, introduit des back-doors.
Slackware, ça se réduit donc à une lutte entre un certain Cottyn et les forces du Mal? Pas de pot que les forces du Mal aient colonisé le monde entier et séquestré Cottyn...
Dommage que Cottyn ait été un tel irresponsable
D'un autre côté, seul contre tous, il ne pouvait pas faire grande chose.
et que tout le monde se foute d'où il est passé...
Normal: le Monde a été assimilé par les forces du Mal.
Au fait: vu de loin, le hack d'Emmanuel semble facile à implémenter grossièrement (quitte à écrire un simple wrapper en shell autour de de swaret). Alors si tu crains tant que quelqu'un ne détourne ton outil fétiche, il te suffit de rester à la même version et de te retrousser un rien les manches.
Avec un peu plus de courage, tu pourrais même forker le développement swaret, au lieu de dénoncer une coalition maléfique imaginaire.
-- Jérémy JUST
Pablo Saratxaga
Kaixo! Li Tue, 05 Oct 2004 00:55:56 +0200, Emmanuel Florac scrijheut:
EF> J'ai essayé avec autre chose mais malheureusement, no luck... Hélas il EF> est difficile de débugger swaret parce qu'il n'y a pas de moyen simple de EF> récupérer les messages de gpg et autres...
Il pourrait faire comme mutt, utiliser gettext sur le domaine de gpg:
set pgp_good_sign="`gettext -d gnupg -s 'Good signature from "' | tr -d '"'`"
càd que "pgp_good_sign" sera 'Good signature from ' en anglais, et "Bonne signature de " en français, etc.
Bien sûr, il faut connaître la chaîne en anglais (mais c'est de toutes façons necessair, non?).
L'astuce consiste donc en ne pas prendre la chaîne "xxxxxx" en dur, mais à prendre "`gettext -d gnupg -s 'xxxxxx'`" à la place, c'est à dire à prendre la traduction de 'xxxxxx' utilisée par gpg.
autre solution c'est de forcer la langue avec LANGUAGE quand on invoque gpg, mais alors on perds la localisation; le choix de l'une ou l'autre façon depends de à qui sont destinées les chaînes; si c'est rien qu'en usage interne sans jamais être vues par l'utilisateur, alors autant utiliser la 2nde option; mais si le resultat de gpg est affiché, alors la 1ere est mieux.
-- Ki ça vos våye bén, Pablo Saratxaga
Les hommes qui disent que les femmes sont frigides sont de mauvaises langues. Sacha Guitry
Kaixo!
Li Tue, 05 Oct 2004 00:55:56 +0200,
Emmanuel Florac <eflorac@imaginet.fr> scrijheut:
EF> J'ai essayé avec autre chose mais malheureusement, no luck... Hélas il
EF> est difficile de débugger swaret parce qu'il n'y a pas de moyen simple de
EF> récupérer les messages de gpg et autres...
Il pourrait faire comme mutt, utiliser gettext sur le domaine de gpg:
set pgp_good_sign="`gettext -d gnupg -s 'Good signature from "' | tr -d '"'`"
càd que "pgp_good_sign" sera 'Good signature from ' en anglais,
et "Bonne signature de " en français, etc.
Bien sûr, il faut connaître la chaîne en anglais (mais c'est de toutes
façons necessair, non?).
L'astuce consiste donc en ne pas prendre la chaîne "xxxxxx" en dur,
mais à prendre "`gettext -d gnupg -s 'xxxxxx'`" à la place, c'est à dire
à prendre la traduction de 'xxxxxx' utilisée par gpg.
autre solution c'est de forcer la langue avec LANGUAGE quand on
invoque gpg, mais alors on perds la localisation; le choix de l'une
ou l'autre façon depends de à qui sont destinées les chaînes;
si c'est rien qu'en usage interne sans jamais être vues par
l'utilisateur, alors autant utiliser la 2nde option; mais si le resultat
de gpg est affiché, alors la 1ere est mieux.
--
Ki ça vos våye bén,
Pablo Saratxaga
Les hommes qui disent que les femmes sont frigides
sont de mauvaises langues. Sacha Guitry
Kaixo! Li Tue, 05 Oct 2004 00:55:56 +0200, Emmanuel Florac scrijheut:
EF> J'ai essayé avec autre chose mais malheureusement, no luck... Hélas il EF> est difficile de débugger swaret parce qu'il n'y a pas de moyen simple de EF> récupérer les messages de gpg et autres...
Il pourrait faire comme mutt, utiliser gettext sur le domaine de gpg:
set pgp_good_sign="`gettext -d gnupg -s 'Good signature from "' | tr -d '"'`"
càd que "pgp_good_sign" sera 'Good signature from ' en anglais, et "Bonne signature de " en français, etc.
Bien sûr, il faut connaître la chaîne en anglais (mais c'est de toutes façons necessair, non?).
L'astuce consiste donc en ne pas prendre la chaîne "xxxxxx" en dur, mais à prendre "`gettext -d gnupg -s 'xxxxxx'`" à la place, c'est à dire à prendre la traduction de 'xxxxxx' utilisée par gpg.
autre solution c'est de forcer la langue avec LANGUAGE quand on invoque gpg, mais alors on perds la localisation; le choix de l'une ou l'autre façon depends de à qui sont destinées les chaînes; si c'est rien qu'en usage interne sans jamais être vues par l'utilisateur, alors autant utiliser la 2nde option; mais si le resultat de gpg est affiché, alors la 1ere est mieux.
-- Ki ça vos våye bén, Pablo Saratxaga
Les hommes qui disent que les femmes sont frigides sont de mauvaises langues. Sacha Guitry
Nicolas George
Pablo Saratxaga , dans le message <cjvf44$, a écrit :
autre solution c'est de forcer la langue avec LANGUAGE quand on invoque gpg
LC_MESSAGES, en fait.
Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait pertinent.
Pablo Saratxaga , dans le message <cjvf44$rb2@chanae.alphanet.ch>, a
écrit :
autre solution c'est de forcer la langue avec LANGUAGE quand on
invoque gpg
LC_MESSAGES, en fait.
Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce
qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait
pertinent.
Pablo Saratxaga , dans le message <cjvf44$, a écrit :
autre solution c'est de forcer la langue avec LANGUAGE quand on invoque gpg
LC_MESSAGES, en fait.
Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait pertinent.
Emmanuel Florac
Le Wed, 06 Oct 2004 00:43:48 +0000, Pablo Saratxaga a écrit :
L'astuce consiste donc en ne pas prendre la chaîne "xxxxxx" en dur, mais à prendre "`gettext -d gnupg -s 'xxxxxx'`" à la place, c'est à dire à prendre la traduction de 'xxxxxx' utilisée par gpg.
j'ai rien compris :) kezaco gettext ?
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Wed, 06 Oct 2004 00:43:48 +0000, Pablo Saratxaga a écrit :
L'astuce consiste donc en ne pas prendre la chaîne "xxxxxx" en dur, mais
à prendre "`gettext -d gnupg -s 'xxxxxx'`" à la place, c'est à dire à
prendre la traduction de 'xxxxxx' utilisée par gpg.
j'ai rien compris :) kezaco gettext ?
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Wed, 06 Oct 2004 00:43:48 +0000, Pablo Saratxaga a écrit :
L'astuce consiste donc en ne pas prendre la chaîne "xxxxxx" en dur, mais à prendre "`gettext -d gnupg -s 'xxxxxx'`" à la place, c'est à dire à prendre la traduction de 'xxxxxx' utilisée par gpg.
j'ai rien compris :) kezaco gettext ?
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Emmanuel Florac
Le Wed, 06 Oct 2004 10:05:54 +0000, Nicolas George a écrit :
Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait pertinent.
Ah bon? pourtant j'ai remarque que ce genre de probleme est recurrent avec gpg et se manifeste dans les librairies perl qui utilisent avec gpg, etc. De ce que j'en ai compris gpg est quasi impossible a scripter et comme il n'y a pas de librairie gpg officielle pour une raison mysterieuse, c'est la poisse.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Le Wed, 06 Oct 2004 10:05:54 +0000, Nicolas George a écrit :
Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser
ce qu'écrit gpg alors que ce dernier retourne un code de sortie tout à
fait pertinent.
Ah bon? pourtant j'ai remarque que ce genre de probleme est recurrent avec
gpg et se manifeste dans les librairies perl qui utilisent avec gpg, etc.
De ce que j'en ai compris gpg est quasi impossible a scripter et comme il
n'y a pas de librairie gpg officielle pour une raison mysterieuse, c'est
la poisse.
--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.
Le Wed, 06 Oct 2004 10:05:54 +0000, Nicolas George a écrit :
Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait pertinent.
Ah bon? pourtant j'ai remarque que ce genre de probleme est recurrent avec gpg et se manifeste dans les librairies perl qui utilisent avec gpg, etc. De ce que j'en ai compris gpg est quasi impossible a scripter et comme il n'y a pas de librairie gpg officielle pour une raison mysterieuse, c'est la poisse.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Emmanuel Florac
Le Tue, 05 Oct 2004 18:41:35 -0400, GP a écrit :
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai proposé une solution (plutôt un hack, mais sans doute fonctionnel), à eux de l'implémenter en espérant qu'ils réagissent à mon post...
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/, évidemment, introduit des back-doors.
Oh, je relirai certainement le code par curiosité avant d'installer la 1.7.
Veux-tu cosigner mon message original si je l'envoie à PV?
Quel en est le contenu exactement?
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Tue, 05 Oct 2004 18:41:35 -0400, GP a écrit :
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai
proposé une solution (plutôt un hack, mais sans doute fonctionnel), à
eux de l'implémenter en espérant qu'ils réagissent à mon post...
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots
n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/,
évidemment, introduit des back-doors.
Oh, je relirai certainement le code par curiosité avant d'installer la
1.7.
Veux-tu cosigner mon message original si je l'envoie à PV?
Quel en est le contenu exactement?
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
C'est possible. Va savoir? En tout cas j'ai trouvé le problème, j'ai proposé une solution (plutôt un hack, mais sans doute fonctionnel), à eux de l'implémenter en espérant qu'ils réagissent à mon post...
Et tu vas relire toutes les 7000 lignes de code pour voir si ces idiots n'ont pas tout bousillé, s'ils n'ont pas, /par inadvertance/, évidemment, introduit des back-doors.
Oh, je relirai certainement le code par curiosité avant d'installer la 1.7.
Veux-tu cosigner mon message original si je l'envoie à PV?
Quel en est le contenu exactement?
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Nicolas George
Emmanuel Florac , dans le message , a écrit :
Ah bon? pourtant j'ai remarque que ce genre de probleme est recurrent avec gpg et se manifeste dans les librairies perl qui utilisent avec gpg, etc. De ce que j'en ai compris gpg est quasi impossible a scripter et comme il n'y a pas de librairie gpg officielle pour une raison mysterieuse, c'est la poisse.
Ben moi, ce que je vois, c'est que gpg --verify se termine avec un code 0 si la signature est bonne, un code 1 si la signature est mauvaise, et un code 2 si la signature n'a pas pu être vérifiée, et que quand on a besoin d'une sortie machine-readable, il y a l'option --with-colons prévu pour.
Après, si les gus qui écrivent swaret ou les modules perl ne savent pas lire le man ou n'ont pas compris ce qu'était la valeur de retour d'un processus, ce n'est pas la faute des auteurs de gpg.
Emmanuel Florac , dans le message
<pan.2004.10.06.14.29.55.576946@imaginet.fr>, a écrit :
Ah bon? pourtant j'ai remarque que ce genre de probleme est recurrent avec
gpg et se manifeste dans les librairies perl qui utilisent avec gpg, etc.
De ce que j'en ai compris gpg est quasi impossible a scripter et comme il
n'y a pas de librairie gpg officielle pour une raison mysterieuse, c'est
la poisse.
Ben moi, ce que je vois, c'est que gpg --verify se termine avec un code 0 si
la signature est bonne, un code 1 si la signature est mauvaise, et un code 2
si la signature n'a pas pu être vérifiée, et que quand on a besoin d'une
sortie machine-readable, il y a l'option --with-colons prévu pour.
Après, si les gus qui écrivent swaret ou les modules perl ne savent pas lire
le man ou n'ont pas compris ce qu'était la valeur de retour d'un processus,
ce n'est pas la faute des auteurs de gpg.
Ah bon? pourtant j'ai remarque que ce genre de probleme est recurrent avec gpg et se manifeste dans les librairies perl qui utilisent avec gpg, etc. De ce que j'en ai compris gpg est quasi impossible a scripter et comme il n'y a pas de librairie gpg officielle pour une raison mysterieuse, c'est la poisse.
Ben moi, ce que je vois, c'est que gpg --verify se termine avec un code 0 si la signature est bonne, un code 1 si la signature est mauvaise, et un code 2 si la signature n'a pas pu être vérifiée, et que quand on a besoin d'une sortie machine-readable, il y a l'option --with-colons prévu pour.
Après, si les gus qui écrivent swaret ou les modules perl ne savent pas lire le man ou n'ont pas compris ce qu'était la valeur de retour d'un processus, ce n'est pas la faute des auteurs de gpg.
