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.
On Thu, 07 Oct 2004 10:17:15 +0200, Emmanuel Florac wrote:
Non, à partir du message anglais, retrouver le message dans la langue qu'on utilise. Ce qui revient plus ou moins au même, en fait.
Oui mais dans le cas qui nous occupe, ce dont on a besoin c'est plutôt du message en anglais, de totue façon c'est swaret qui récupère le message, l'utilisateur ne le voit même pas.
Oui mais il n'y a pas de programme qui permette la traduction inverse, et ça ne sert à rien. Je dis que ça revient au même : si les messages en anglais sont identiques, alors leur traduction est identique. S'ils sont différents, alors leur traduction l'est aussi (sauf traducteur blagueur).
Sam. -- Sam Hocevar <http://sam.zoy.org/>
Racism is so gay! How could you ever be racist?
On Thu, 07 Oct 2004 10:17:15 +0200, Emmanuel Florac wrote:
Non, à partir du message anglais, retrouver le message dans la langue
qu'on utilise. Ce qui revient plus ou moins au même, en fait.
Oui mais dans le cas qui nous occupe, ce dont on a besoin c'est plutôt du
message en anglais, de totue façon c'est swaret qui récupère le
message, l'utilisateur ne le voit même pas.
Oui mais il n'y a pas de programme qui permette la traduction
inverse, et ça ne sert à rien. Je dis que ça revient au même : si
les messages en anglais sont identiques, alors leur traduction est
identique. S'ils sont différents, alors leur traduction l'est aussi
(sauf traducteur blagueur).
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Thu, 07 Oct 2004 10:17:15 +0200, Emmanuel Florac wrote:
Non, à partir du message anglais, retrouver le message dans la langue qu'on utilise. Ce qui revient plus ou moins au même, en fait.
Oui mais dans le cas qui nous occupe, ce dont on a besoin c'est plutôt du message en anglais, de totue façon c'est swaret qui récupère le message, l'utilisateur ne le voit même pas.
Oui mais il n'y a pas de programme qui permette la traduction inverse, et ça ne sert à rien. Je dis que ça revient au même : si les messages en anglais sont identiques, alors leur traduction est identique. S'ils sont différents, alors leur traduction l'est aussi (sauf traducteur blagueur).
Sam. -- Sam Hocevar <http://sam.zoy.org/>
Racism is so gay! How could you ever be racist?
Pablo Saratxaga
Kaixo! Li Wed, 6 Oct 2004 10:05:54 +0000 (UTC), Nicolas George <nicolas$ scrijheut:
autre solution c'est de forcer la langue avec LANGUAGE quand on invoque gpg
NG> LC_MESSAGES, en fait.
non, LANGUAGE a priorité sur LC_MESSAGES, de plus LANGUAGE est la variable qui est communement utilisée; donc redefinir LC_MESSAGES n'aura dans 99% des cas pas de résultat (sauf dans le cas où on fait LC_MESSAGES=C, mais pour toute autre valeur c'est LANGUAGE qui a la priorité)
NG> Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce NG> qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait NG> pertinent.
pour reafficher le résultat autremment, par exemple.
-- Ki ça vos våye bén, Pablo Saratxaga
Drame culinaire: Un oeuf a été battu à mort à coup de fouet. Les nuls
Kaixo!
Li Wed, 6 Oct 2004 10:05:54 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> scrijheut:
autre solution c'est de forcer la langue avec LANGUAGE quand on
invoque gpg
NG> LC_MESSAGES, en fait.
non, LANGUAGE a priorité sur LC_MESSAGES, de plus LANGUAGE est la
variable qui est communement utilisée; donc redefinir LC_MESSAGES
n'aura dans 99% des cas pas de résultat (sauf dans le cas où on fait
LC_MESSAGES=C, mais pour toute autre valeur c'est LANGUAGE qui a la
priorité)
NG> Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce
NG> qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait
NG> pertinent.
pour reafficher le résultat autremment, par exemple.
--
Ki ça vos våye bén,
Pablo Saratxaga
Drame culinaire: Un oeuf a été battu à mort à coup de fouet. Les nuls
Kaixo! Li Wed, 6 Oct 2004 10:05:54 +0000 (UTC), Nicolas George <nicolas$ scrijheut:
autre solution c'est de forcer la langue avec LANGUAGE quand on invoque gpg
NG> LC_MESSAGES, en fait.
non, LANGUAGE a priorité sur LC_MESSAGES, de plus LANGUAGE est la variable qui est communement utilisée; donc redefinir LC_MESSAGES n'aura dans 99% des cas pas de résultat (sauf dans le cas où on fait LC_MESSAGES=C, mais pour toute autre valeur c'est LANGUAGE qui a la priorité)
NG> Ceci dit, on se demande un peu pourquoi ils éprouvent le besoin de parser ce NG> qu'écrit gpg alors que ce dernier retourne un code de sortie tout à fait NG> pertinent.
pour reafficher le résultat autremment, par exemple.
-- Ki ça vos våye bén, Pablo Saratxaga
Drame culinaire: Un oeuf a été battu à mort à coup de fouet. Les nuls
Pablo Saratxaga
Kaixo! Li Wed, 06 Oct 2004 16:27:44 +0200, Emmanuel Florac scrijheut:
EF> 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.
EF> j'ai rien compris :) kezaco gettext ?
gettext est: 1) une fonction de la libc qui permets de retourner la traduction d'une chaîne donnée, c'est ce qu'utilise gpg pour sa localisation; 2) gettext existe aussi en ligne de commande, ce qui permets d'avoir les traductions via la ligne de commande. On peut donc, si on connaît la chaîne en anglais de depart et le domaine de traduction (le nom du fichier *.mo avec les traductions) avoir en retour la même chaîne exactemment que celle qui sera utilisée par le programme gpg (ou tout autre utilisant gettext) dans un environnement donné.
-- Ki ça vos våye bén, Pablo Saratxaga
Il faut autant qu'on peut, obliger tout le monde : On a souvent besoin d'un plus petit que soi.
-- Jean de La Fontaine, Le Lion et le Rat
Kaixo!
Li Wed, 06 Oct 2004 16:27:44 +0200,
Emmanuel Florac <eflorac@imaginet.fr> scrijheut:
EF> 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.
EF> j'ai rien compris :) kezaco gettext ?
gettext est: 1) une fonction de la libc qui permets de retourner la
traduction d'une chaîne donnée, c'est ce qu'utilise gpg pour sa
localisation; 2) gettext existe aussi en ligne de commande, ce qui
permets d'avoir les traductions via la ligne de commande.
On peut donc, si on connaît la chaîne en anglais de depart et le domaine
de traduction (le nom du fichier *.mo avec les traductions) avoir
en retour la même chaîne exactemment que celle qui sera utilisée par
le programme gpg (ou tout autre utilisant gettext) dans un environnement
donné.
--
Ki ça vos våye bén,
Pablo Saratxaga
Il faut autant qu'on peut, obliger tout le monde :
On a souvent besoin d'un plus petit que soi.
Kaixo! Li Wed, 06 Oct 2004 16:27:44 +0200, Emmanuel Florac scrijheut:
EF> 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.
EF> j'ai rien compris :) kezaco gettext ?
gettext est: 1) une fonction de la libc qui permets de retourner la traduction d'une chaîne donnée, c'est ce qu'utilise gpg pour sa localisation; 2) gettext existe aussi en ligne de commande, ce qui permets d'avoir les traductions via la ligne de commande. On peut donc, si on connaît la chaîne en anglais de depart et le domaine de traduction (le nom du fichier *.mo avec les traductions) avoir en retour la même chaîne exactemment que celle qui sera utilisée par le programme gpg (ou tout autre utilisant gettext) dans un environnement donné.
-- Ki ça vos våye bén, Pablo Saratxaga
Il faut autant qu'on peut, obliger tout le monde : On a souvent besoin d'un plus petit que soi.
-- Jean de La Fontaine, Le Lion et le Rat
Pablo Saratxaga
Kaixo! Li Wed, 06 Oct 2004 22:16:20 +0200, Emmanuel Florac scrijheut:
EF> Ben non, j'en ai pas l'usage. J'en ai vaguement entendu parler ici et là, EF> mais l'explication de Pablo me dépasse. En gros gettext me permettrait EF> à partir de la sortie en français de gpg, de retrouver le message en EF> anglais? Comprends rien.
Non, l'inverse. A partir de la chaîne en anglais avoir la sortie en français de gpg.
Car gpg utilise lui-même gettext (en C pas en ligne de commande, bien sûr) pour avoir sa sortie en français.
-- Ki ça vos våye bén, Pablo Saratxaga
Sauve qui peut, voilà le petit vieux qui vend de la serge.
Kaixo!
Li Wed, 06 Oct 2004 22:16:20 +0200,
Emmanuel Florac <eflorac@imaginet.fr> scrijheut:
EF> Ben non, j'en ai pas l'usage. J'en ai vaguement entendu parler ici et là,
EF> mais l'explication de Pablo me dépasse. En gros gettext me permettrait
EF> à partir de la sortie en français de gpg, de retrouver le message en
EF> anglais? Comprends rien.
Non, l'inverse.
A partir de la chaîne en anglais avoir la sortie en français de gpg.
Car gpg utilise lui-même gettext (en C pas en ligne de commande, bien
sûr) pour avoir sa sortie en français.
--
Ki ça vos våye bén,
Pablo Saratxaga
Sauve qui peut, voilà le petit vieux qui vend de la serge.
Kaixo! Li Wed, 06 Oct 2004 22:16:20 +0200, Emmanuel Florac scrijheut:
EF> Ben non, j'en ai pas l'usage. J'en ai vaguement entendu parler ici et là, EF> mais l'explication de Pablo me dépasse. En gros gettext me permettrait EF> à partir de la sortie en français de gpg, de retrouver le message en EF> anglais? Comprends rien.
Non, l'inverse. A partir de la chaîne en anglais avoir la sortie en français de gpg.
Car gpg utilise lui-même gettext (en C pas en ligne de commande, bien sûr) pour avoir sa sortie en français.
-- Ki ça vos våye bén, Pablo Saratxaga
Sauve qui peut, voilà le petit vieux qui vend de la serge.
Nicolas George
Pablo Saratxaga , dans le message <ck4e1r$, a écrit :
non, LANGUAGE a priorité sur LC_MESSAGES, de plus LANGUAGE est la variable qui est communement utilisée
Non, LANGUAGE est une extension GNU d'utilité douteuse. Heureusement, les configurations raisonnables utilisent les constructions standards.
pour reafficher le résultat autremment, par exemple.
Ce n'était pas de ça qu'il était question dans ce thread. Et surtout ça ne marche pas.
Pablo Saratxaga , dans le message <ck4e1r$q1p@chanae.alphanet.ch>, a
écrit :
non, LANGUAGE a priorité sur LC_MESSAGES, de plus LANGUAGE est la
variable qui est communement utilisée
Non, LANGUAGE est une extension GNU d'utilité douteuse. Heureusement, les
configurations raisonnables utilisent les constructions standards.
pour reafficher le résultat autremment, par exemple.
Ce n'était pas de ça qu'il était question dans ce thread. Et surtout ça ne
marche pas.
