Une petite question qui doit être simple à résoudre.
Parfois, je parcours des groupes pour lesquels on donne un
Message-ID pour faire référence à un ancien message.
Gnus sait gérer ce genre de chose seulement, j'ai un souci avec
ça.
Le problème c'est que j'ai mon propre serveur NNTP. Si le
"numéro" du message est plus grand que le plus grand numéro de
post pour un groupe donné, Gnus considère que le groupe ne
recevra pas de nouveaux messages !!
Par exemple, admettons que sur mon serveur de news j'ai pour le
groupe FCAE, un message 30 (correspondant au dernier message reçu
en feed ou autre). Maintenant si je choisi de suivre un
Message-ID et que par malheur le numéro du message est, disons
200, Gnus va considérer que les messages 31 à 199 ont déjà été
visités. Ce qui signifie en clair que tant que le numéro du
message n'est pas 201, alors je ne saurais même pas qu'il y a eu
de nouveaux messages.
Quelqu'un a-t-il déjà vu ça ? Comment le résoudre ? C'est
particulièrement énervant de penser qu'un groupe est inactif
alors même que sur d'autres lecteurs l'activité est flagrante.
Merci (j'espère avoir réussi à me faire comprendre).
A+
--
"sometimes i feel like we're making emacs better and better because we don't
know what to do with emacs once it is finished."
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sébastien Kirche
Le 4 May 2005, Xavier Maillard a formulé :
Bonsoir,
Hello,
Une petite question qui doit être simple à résoudre.
Parfois, je parcours des groupes pour lesquels on donne un Message-ID pour faire référence à un ancien message.
Gnus sait gérer ce genre de chose seulement, j'ai un souci avec ça.
Le problème c'est que j'ai mon propre serveur NNTP. Si le "numéro" du message est plus grand que le plus grand numéro de post pour un groupe donné, Gnus considère que le groupe ne recevra pas de nouveaux messages !!
Par exemple, admettons que sur mon serveur de news j'ai pour le groupe FCAE, un message 30 (correspondant au dernier message reçu en feed ou autre). Maintenant si je choisi de suivre un Message-ID et que par malheur le numéro du message est, disons 200, Gnus va considérer que les messages 31 à 199 ont déjà été visités. Ce qui signifie en clair que tant que le numéro du message n'est pas 201, alors je ne saurais même pas qu'il y a eu de nouveaux messages.
Bizarre, tu as aussi le problème si tu tentes de fetcher un article manuellement, par exemple avec M-^ dans le summary buffer ?
Quelqu'un a-t-il déjà vu ça ? Comment le résoudre ? C'est particulièrement énervant de penser qu'un groupe est inactif alors même que sur d'autres lecteurs l'activité est flagrante.
Merci (j'espère avoir réussi à me faire comprendre).
Pas sûr d'avoir bien compris ton problème, par contre j'ai un truc qui pourrait peut-être aider : quand j'essaie de fetcher un article, soit en cherchant son parent, soit avec M-^ et que l'article n'est pas trouvé sur le serveur, mon Gnus va le chercher chez Gmane, et chez Google.
Pratique quand il a expiré sur le serveur principal.
;; Lorsqu'un article n'est plus disponible dans le serveur NNTP, on utilise ;; google.com ;; Message-id : ;; This snippet comes from the info docs Gnus->Finding the Parent. (setq gnus-refer-article-method '(current (nntp "news.gmane.org") (nnweb "google" (nnweb-type google))))
Tu pourrais adapter en mettant ton FAI ou un autre serveur dans la liste...
HTH -- Sébastien Kirche
Le 4 May 2005, Xavier Maillard a formulé :
Bonsoir,
Hello,
Une petite question qui doit être simple à résoudre.
Parfois, je parcours des groupes pour lesquels on donne un
Message-ID pour faire référence à un ancien message.
Gnus sait gérer ce genre de chose seulement, j'ai un souci avec
ça.
Le problème c'est que j'ai mon propre serveur NNTP. Si le
"numéro" du message est plus grand que le plus grand numéro de
post pour un groupe donné, Gnus considère que le groupe ne
recevra pas de nouveaux messages !!
Par exemple, admettons que sur mon serveur de news j'ai pour le
groupe FCAE, un message 30 (correspondant au dernier message reçu
en feed ou autre). Maintenant si je choisi de suivre un
Message-ID et que par malheur le numéro du message est, disons
200, Gnus va considérer que les messages 31 à 199 ont déjà été
visités. Ce qui signifie en clair que tant que le numéro du
message n'est pas 201, alors je ne saurais même pas qu'il y a eu
de nouveaux messages.
Bizarre, tu as aussi le problème si tu tentes de fetcher un article
manuellement, par exemple avec M-^ dans le summary buffer ?
Quelqu'un a-t-il déjà vu ça ? Comment le résoudre ? C'est
particulièrement énervant de penser qu'un groupe est inactif
alors même que sur d'autres lecteurs l'activité est flagrante.
Merci (j'espère avoir réussi à me faire comprendre).
Pas sûr d'avoir bien compris ton problème, par contre j'ai un truc qui
pourrait peut-être aider : quand j'essaie de fetcher un article, soit en
cherchant son parent, soit avec M-^ et que l'article n'est pas trouvé
sur le serveur, mon Gnus va le chercher chez Gmane, et chez Google.
Pratique quand il a expiré sur le serveur principal.
;; Lorsqu'un article n'est plus disponible dans le serveur NNTP, on utilise
;; google.com
;; Message-id : <m3wurdqusg.fsf@fermat.mts.jhu.edu>
;; This snippet comes from the info docs Gnus->Finding the Parent.
(setq gnus-refer-article-method
'(current
(nntp "news.gmane.org")
(nnweb "google" (nnweb-type google))))
Tu pourrais adapter en mettant ton FAI ou un autre serveur dans la
liste...
Une petite question qui doit être simple à résoudre.
Parfois, je parcours des groupes pour lesquels on donne un Message-ID pour faire référence à un ancien message.
Gnus sait gérer ce genre de chose seulement, j'ai un souci avec ça.
Le problème c'est que j'ai mon propre serveur NNTP. Si le "numéro" du message est plus grand que le plus grand numéro de post pour un groupe donné, Gnus considère que le groupe ne recevra pas de nouveaux messages !!
Par exemple, admettons que sur mon serveur de news j'ai pour le groupe FCAE, un message 30 (correspondant au dernier message reçu en feed ou autre). Maintenant si je choisi de suivre un Message-ID et que par malheur le numéro du message est, disons 200, Gnus va considérer que les messages 31 à 199 ont déjà été visités. Ce qui signifie en clair que tant que le numéro du message n'est pas 201, alors je ne saurais même pas qu'il y a eu de nouveaux messages.
Bizarre, tu as aussi le problème si tu tentes de fetcher un article manuellement, par exemple avec M-^ dans le summary buffer ?
Quelqu'un a-t-il déjà vu ça ? Comment le résoudre ? C'est particulièrement énervant de penser qu'un groupe est inactif alors même que sur d'autres lecteurs l'activité est flagrante.
Merci (j'espère avoir réussi à me faire comprendre).
Pas sûr d'avoir bien compris ton problème, par contre j'ai un truc qui pourrait peut-être aider : quand j'essaie de fetcher un article, soit en cherchant son parent, soit avec M-^ et que l'article n'est pas trouvé sur le serveur, mon Gnus va le chercher chez Gmane, et chez Google.
Pratique quand il a expiré sur le serveur principal.
;; Lorsqu'un article n'est plus disponible dans le serveur NNTP, on utilise ;; google.com ;; Message-id : ;; This snippet comes from the info docs Gnus->Finding the Parent. (setq gnus-refer-article-method '(current (nntp "news.gmane.org") (nnweb "google" (nnweb-type google))))
Tu pourrais adapter en mettant ton FAI ou un autre serveur dans la liste...
HTH -- Sébastien Kirche
Xavier Maillard
On 4 May 2005, Sébastien Kirche wrote:
> Par exemple, admettons que sur mon serveur de news j'ai pour > le groupe FCAE, un message 30 (correspondant au dernier > message reçu en feed ou autre). Maintenant si je choisi de > suivre un Message-ID et que par malheur le numéro du message > est, disons 200, Gnus va considérer que les messages 31 à 199 > ont déjà été visités. Ce qui signifie en clair que tant que > le numéro du message n'est pas 201, alors je ne saurais même > pas qu'il y a eu de nouveaux messages.
Bizarre, tu as aussi le problème si tu tentes de fetcher un article manuellement, par exemple avec M-^ dans le summary buffer ?
Non.
Par contre, <RET> sur un Message-ID me retourne ce genre de chose.
Là j'ai changé de tactique et utilisé C-c ^ et voilà ce que j'obtiens dans le tampon *nntp-log* :
Donc là, le message contenait un Message-id dans le corps du post: .
Je n'ai pas constaté de dysfonctionnement mais comme tu peux le voir, le groupe en question n'était pas FCAE mais gnus.test.
Pratique quand il a expiré sur le serveur principal.
;; Lorsqu'un article n'est plus disponible dans le serveur ;; NNTP, on utilise google.com Message-id : ;; This snippet comes from ;; the info docs Gnus->Finding the Parent. (setq gnus-refer-article-method '(current (nntp "news.gmane.org") (nnweb "google" (nnweb-type google))))
Tu pourrais adapter en mettant ton FAI ou un autre serveur dans la liste...
Je connais déjà et je ne suis pas sûr du tout que le problème vienne de là :)
> Par exemple, admettons que sur mon serveur de news j'ai pour
> le groupe FCAE, un message 30 (correspondant au dernier
> message reçu en feed ou autre). Maintenant si je choisi de
> suivre un Message-ID et que par malheur le numéro du message
> est, disons 200, Gnus va considérer que les messages 31 à 199
> ont déjà été visités. Ce qui signifie en clair que tant que
> le numéro du message n'est pas 201, alors je ne saurais même
> pas qu'il y a eu de nouveaux messages.
Bizarre, tu as aussi le problème si tu tentes de fetcher un
article manuellement, par exemple avec M-^ dans le summary
buffer ?
Non.
Par contre, <RET> sur un Message-ID me retourne ce genre de
chose.
Là j'ai changé de tactique et utilisé C-c ^ et voilà ce que
j'obtiens dans le tampon *nntp-log* :
Donc là, le message contenait un Message-id dans le corps du
post: <uy8cwfxmh.fsf@fgeorges.org>.
Je n'ai pas constaté de dysfonctionnement mais comme tu peux le
voir, le groupe en question n'était pas FCAE mais gnus.test.
Pratique quand il a expiré sur le serveur principal.
;; Lorsqu'un article n'est plus disponible dans le serveur
;; NNTP, on utilise google.com Message-id :
;; <m3wurdqusg.fsf@fermat.mts.jhu.edu> This snippet comes from
;; the info docs Gnus->Finding the Parent.
(setq gnus-refer-article-method
'(current
(nntp "news.gmane.org")
(nnweb "google" (nnweb-type google))))
Tu pourrais adapter en mettant ton FAI ou un autre serveur dans
la liste...
Je connais déjà et je ne suis pas sûr du tout que le problème
vienne de là :)
> Par exemple, admettons que sur mon serveur de news j'ai pour > le groupe FCAE, un message 30 (correspondant au dernier > message reçu en feed ou autre). Maintenant si je choisi de > suivre un Message-ID et que par malheur le numéro du message > est, disons 200, Gnus va considérer que les messages 31 à 199 > ont déjà été visités. Ce qui signifie en clair que tant que > le numéro du message n'est pas 201, alors je ne saurais même > pas qu'il y a eu de nouveaux messages.
Bizarre, tu as aussi le problème si tu tentes de fetcher un article manuellement, par exemple avec M-^ dans le summary buffer ?
Non.
Par contre, <RET> sur un Message-ID me retourne ce genre de chose.
Là j'ai changé de tactique et utilisé C-c ^ et voilà ce que j'obtiens dans le tampon *nntp-log* :
Donc là, le message contenait un Message-id dans le corps du post: .
Je n'ai pas constaté de dysfonctionnement mais comme tu peux le voir, le groupe en question n'était pas FCAE mais gnus.test.
Pratique quand il a expiré sur le serveur principal.
;; Lorsqu'un article n'est plus disponible dans le serveur ;; NNTP, on utilise google.com Message-id : ;; This snippet comes from ;; the info docs Gnus->Finding the Parent. (setq gnus-refer-article-method '(current (nntp "news.gmane.org") (nnweb "google" (nnweb-type google))))
Tu pourrais adapter en mettant ton FAI ou un autre serveur dans la liste...
Je connais déjà et je ne suis pas sûr du tout que le problème vienne de là :)
Le message contient deux messages id sur lesquels tu peux tester.
Si je fais <RET> sur ça, j'ai l'impression que Gnus prend le Xref et attribue le numéro du message sur le serveur distant à ma conf ce qui fait que j'obtiens un "trou" chez moi.
Le message contient deux messages id sur lesquels tu peux tester.
Si je fais <RET> sur ça, j'ai l'impression que Gnus prend le Xref
et attribue le numéro du message sur le serveur distant à ma conf
ce qui fait que j'obtiens un "trou" chez moi.
Le message contient deux messages id sur lesquels tu peux tester.
Si je fais <RET> sur ça, j'ai l'impression que Gnus prend le Xref et attribue le numéro du message sur le serveur distant à ma conf ce qui fait que j'obtiens un "trou" chez moi.
Cependant je n'ai pas de serveur local inn ou leafnode. Mon serveur est celui de CHC.
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il devait encore être sur le serveur. Il a été chargé sans problème également.
Si je fais <RET> sur ça, j'ai l'impression que Gnus prend le Xref et attribue le numéro du message sur le serveur distant à ma conf ce qui fait que j'obtiens un "trou" chez moi.
Je ne sais pas trop. Je t'ai donné le seul truc pratique que je connaissais sur la récupération des M-ID chez Google et Gmane. Comme je n'ai jamais installé de serveur news local je n'en sais pas plus.
-- Sébastien Kirche
Le 5 mai 2005, Xavier Maillard s'est exprimé ainsi :
Voici le MID du message sur lequel je coince:
Message-ID: <u3budckcs.fsf@fgeorges.org>
Le message contient deux messages id sur lesquels tu peux tester.
Cependant je n'ai pas de serveur local inn ou leafnode. Mon serveur est
celui de CHC.
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune
peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il
devait encore être sur le serveur. Il a été chargé sans problème
également.
Si je fais <RET> sur ça, j'ai l'impression que Gnus prend le Xref
et attribue le numéro du message sur le serveur distant à ma conf
ce qui fait que j'obtiens un "trou" chez moi.
Je ne sais pas trop. Je t'ai donné le seul truc pratique que je
connaissais sur la récupération des M-ID chez Google et Gmane. Comme je
n'ai jamais installé de serveur news local je n'en sais pas plus.
Cependant je n'ai pas de serveur local inn ou leafnode. Mon serveur est celui de CHC.
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il devait encore être sur le serveur. Il a été chargé sans problème également.
Si je fais <RET> sur ça, j'ai l'impression que Gnus prend le Xref et attribue le numéro du message sur le serveur distant à ma conf ce qui fait que j'obtiens un "trou" chez moi.
Je ne sais pas trop. Je t'ai donné le seul truc pratique que je connaissais sur la récupération des M-ID chez Google et Gmane. Comme je n'ai jamais installé de serveur news local je n'en sais pas plus.
-- Sébastien Kirche
Xavier Maillard
On 5 May 2005, Sébastien Kirche wrote:
Le 5 mai 2005, Xavier Maillard s'est exprimé ainsi :
> Voici le MID du message sur lequel je coince: > > Message-ID: > > Le message contient deux messages id sur lesquels tu peux > tester.
Cependant je n'ai pas de serveur local inn ou leafnode. Mon serveur est celui de CHC.
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il devait encore être sur le serveur. Il a été chargé sans problème également.
Question bête, est-ce que le g-r-a-m doit contenir une entrée pour mon serveur local ?
Voici par exemple ce que j'utilise depuis longtemps (le google group ne fonctionne plus mais c'est pas grave):
,----[ C-h v gnus-refer-article-method RET ] | gnus-refer-article-method's value is | (current | (nntp "news.gnu-rox.org") | (nntp "news.nerim.net") | (nnweb "google" | (nnweb-type google)) | (nntp "news.gmane.org")) | | | Preferred method for fetching an article by Message-ID. | If you are reading news from the local spool (with nnspool), fetching | articles by Message-ID is painfully slow. By setting this method to an | nntp method, you might get acceptable results. | | The value of this variable must be a valid select method as discussed | in the documentation of `gnus-select-method'. | | It can also be a list of select methods, as well as the special symbol | `current', which means to use the current select method. If it is a | list, Gnus will try all the methods in the list until it finds a match. | | You can customize this variable. | | Defined in `gnus'. | | [back] `----
A la lecture de cette docstring, je n'en suis pas convaincu... Autre point litigieux: qu'est-ce donc qu'une 'valid select method' ?
Merci -- Registered Linux-User #340967 with the Linux Counter, http://counter.li.org.
On 5 May 2005, Sébastien Kirche wrote:
Le 5 mai 2005, Xavier Maillard s'est exprimé ainsi :
> Voici le MID du message sur lequel je coince:
>
> Message-ID: <u3budckcs.fsf@fgeorges.org>
>
> Le message contient deux messages id sur lesquels tu peux
> tester.
Cependant je n'ai pas de serveur local inn ou leafnode. Mon
serveur est celui de CHC.
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu
aucune peine à les retrouver, quand au plus vieux (5 janvier)
je pense qu'il devait encore être sur le serveur. Il a été
chargé sans problème également.
Question bête, est-ce que le g-r-a-m doit contenir une entrée
pour mon serveur local ?
Voici par exemple ce que j'utilise depuis longtemps (le google
group ne fonctionne plus mais c'est pas grave):
,----[ C-h v gnus-refer-article-method RET ]
| gnus-refer-article-method's value is
| (current
| (nntp "news.gnu-rox.org")
| (nntp "news.nerim.net")
| (nnweb "google"
| (nnweb-type google))
| (nntp "news.gmane.org"))
|
|
| Preferred method for fetching an article by Message-ID.
| If you are reading news from the local spool (with nnspool), fetching
| articles by Message-ID is painfully slow. By setting this method to an
| nntp method, you might get acceptable results.
|
| The value of this variable must be a valid select method as discussed
| in the documentation of `gnus-select-method'.
|
| It can also be a list of select methods, as well as the special symbol
| `current', which means to use the current select method. If it is a
| list, Gnus will try all the methods in the list until it finds a match.
|
| You can customize this variable.
|
| Defined in `gnus'.
|
| [back]
`----
A la lecture de cette docstring, je n'en suis pas
convaincu... Autre point litigieux: qu'est-ce donc qu'une 'valid
select method' ?
Merci
--
Registered Linux-User #340967 with the Linux Counter, http://counter.li.org.
Cependant je n'ai pas de serveur local inn ou leafnode. Mon serveur est celui de CHC.
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il devait encore être sur le serveur. Il a été chargé sans problème également.
Question bête, est-ce que le g-r-a-m doit contenir une entrée pour mon serveur local ?
Voici par exemple ce que j'utilise depuis longtemps (le google group ne fonctionne plus mais c'est pas grave):
,----[ C-h v gnus-refer-article-method RET ] | gnus-refer-article-method's value is | (current | (nntp "news.gnu-rox.org") | (nntp "news.nerim.net") | (nnweb "google" | (nnweb-type google)) | (nntp "news.gmane.org")) | | | Preferred method for fetching an article by Message-ID. | If you are reading news from the local spool (with nnspool), fetching | articles by Message-ID is painfully slow. By setting this method to an | nntp method, you might get acceptable results. | | The value of this variable must be a valid select method as discussed | in the documentation of `gnus-select-method'. | | It can also be a list of select methods, as well as the special symbol | `current', which means to use the current select method. If it is a | list, Gnus will try all the methods in the list until it finds a match. | | You can customize this variable. | | Defined in `gnus'. | | [back] `----
A la lecture de cette docstring, je n'en suis pas convaincu... Autre point litigieux: qu'est-ce donc qu'une 'valid select method' ?
Merci -- Registered Linux-User #340967 with the Linux Counter, http://counter.li.org.
Sébastien Kirche
Le 5 mai 2005, Xavier Maillard a dit :
Question bête, est-ce que le g-r-a-m doit contenir une entrée pour mon serveur local ?
Voici par exemple ce que j'utilise depuis longtemps (le google group ne fonctionne plus mais c'est pas grave):
,----[ C-h v gnus-refer-article-method RET ] [...] `----
A la lecture de cette docstring, je n'en suis pas convaincu... Autre point litigieux: qu'est-ce donc qu'une 'valid select method' ?
Euh, une select method qui fonctionne ? (avec les infos d'authentification, etc)
À la lecture des docstrings de gnus-refer-article-method et de gnus-select-method, je me demande si tu ne devrais pas rajouter une entrée nnspool avec ton serveur perso dans g-r-a-m.
Je suppose qu'elle y est déjà pour gnus-select-method ?
-- Sébastien Kirche
Le 5 mai 2005, Xavier Maillard a dit :
Question bête, est-ce que le g-r-a-m doit contenir une entrée
pour mon serveur local ?
Voici par exemple ce que j'utilise depuis longtemps (le google
group ne fonctionne plus mais c'est pas grave):
,----[ C-h v gnus-refer-article-method RET ]
[...]
`----
A la lecture de cette docstring, je n'en suis pas
convaincu... Autre point litigieux: qu'est-ce donc qu'une 'valid
select method' ?
Euh, une select method qui fonctionne ? (avec les infos
d'authentification, etc)
À la lecture des docstrings de gnus-refer-article-method et de
gnus-select-method, je me demande si tu ne devrais pas rajouter une
entrée nnspool avec ton serveur perso dans g-r-a-m.
Je suppose qu'elle y est déjà pour gnus-select-method ?
Question bête, est-ce que le g-r-a-m doit contenir une entrée pour mon serveur local ?
Voici par exemple ce que j'utilise depuis longtemps (le google group ne fonctionne plus mais c'est pas grave):
,----[ C-h v gnus-refer-article-method RET ] [...] `----
A la lecture de cette docstring, je n'en suis pas convaincu... Autre point litigieux: qu'est-ce donc qu'une 'valid select method' ?
Euh, une select method qui fonctionne ? (avec les infos d'authentification, etc)
À la lecture des docstrings de gnus-refer-article-method et de gnus-select-method, je me demande si tu ne devrais pas rajouter une entrée nnspool avec ton serveur perso dans g-r-a-m.
Je suppose qu'elle y est déjà pour gnus-select-method ?
-- Sébastien Kirche
Xavier Maillard
On 5 May 2005, Sébastien Kirche wrote:
Le 5 mai 2005, Xavier Maillard a dit :
> Question bête, est-ce que le g-r-a-m doit contenir une entrée > pour mon serveur local ? > > Voici par exemple ce que j'utilise depuis longtemps (le > google group ne fonctionne plus mais c'est pas grave): > > ,----[ C-h v gnus-refer-article-method RET ] > [...] > `---- > > A la lecture de cette docstring, je n'en suis pas > convaincu... Autre point litigieux: qu'est-ce donc qu'une > 'valid select method' ?
Euh, une select method qui fonctionne ? (avec les infos d'authentification, etc)
Ben justement, je ne suis pas sûr. Je pense plus à une méthode qui existe (genre nntp, nnspool, ...) plutôt qu'une select-method définit dans mon .gnus.
À la lecture des docstrings de gnus-refer-article-method et de gnus-select-method, je me demande si tu ne devrais pas rajouter une entrée nnspool avec ton serveur perso dans g-r-a-m.
Pourquoi nnspool ? nnspool c'est pour aller dans un fichier/répertoire de spool Unix. Non ? Moi le serveur NNTP est sur une autre machine et j'y accède par NNTP.
Je suppose qu'elle y est déjà pour gnus-select-method ?
Oui. Bon dans tous les cas, la première entrée suivant la 'current est de trop (voir gênante). Quoique... -- .o. | Hacker wonderland ..o | ooo |
On 5 May 2005, Sébastien Kirche wrote:
Le 5 mai 2005, Xavier Maillard a dit :
> Question bête, est-ce que le g-r-a-m doit contenir une entrée
> pour mon serveur local ?
>
> Voici par exemple ce que j'utilise depuis longtemps (le
> google group ne fonctionne plus mais c'est pas grave):
>
> ,----[ C-h v gnus-refer-article-method RET ]
> [...]
> `----
>
> A la lecture de cette docstring, je n'en suis pas
> convaincu... Autre point litigieux: qu'est-ce donc qu'une
> 'valid select method' ?
Euh, une select method qui fonctionne ? (avec les infos
d'authentification, etc)
Ben justement, je ne suis pas sûr. Je pense plus à une méthode
qui existe (genre nntp, nnspool, ...) plutôt qu'une select-method
définit dans mon .gnus.
À la lecture des docstrings de gnus-refer-article-method et de
gnus-select-method, je me demande si tu ne devrais pas rajouter
une entrée nnspool avec ton serveur perso dans g-r-a-m.
Pourquoi nnspool ? nnspool c'est pour aller dans un
fichier/répertoire de spool Unix. Non ? Moi le serveur NNTP est
sur une autre machine et j'y accède par NNTP.
Je suppose qu'elle y est déjà pour gnus-select-method ?
Oui. Bon dans tous les cas, la première entrée suivant la
'current est de trop (voir gênante). Quoique...
--
.o. | Hacker wonderland
..o |
ooo |
> Question bête, est-ce que le g-r-a-m doit contenir une entrée > pour mon serveur local ? > > Voici par exemple ce que j'utilise depuis longtemps (le > google group ne fonctionne plus mais c'est pas grave): > > ,----[ C-h v gnus-refer-article-method RET ] > [...] > `---- > > A la lecture de cette docstring, je n'en suis pas > convaincu... Autre point litigieux: qu'est-ce donc qu'une > 'valid select method' ?
Euh, une select method qui fonctionne ? (avec les infos d'authentification, etc)
Ben justement, je ne suis pas sûr. Je pense plus à une méthode qui existe (genre nntp, nnspool, ...) plutôt qu'une select-method définit dans mon .gnus.
À la lecture des docstrings de gnus-refer-article-method et de gnus-select-method, je me demande si tu ne devrais pas rajouter une entrée nnspool avec ton serveur perso dans g-r-a-m.
Pourquoi nnspool ? nnspool c'est pour aller dans un fichier/répertoire de spool Unix. Non ? Moi le serveur NNTP est sur une autre machine et j'y accède par NNTP.
Je suppose qu'elle y est déjà pour gnus-select-method ?
Oui. Bon dans tous les cas, la première entrée suivant la 'current est de trop (voir gênante). Quoique... -- .o. | Hacker wonderland ..o | ooo |
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il devait encore être sur le serveur.
Le serveur est paramétré pour conserver tout fr.* pendant 180 jours et si le spool n'est pas trop gros au mois de juin (lorsque on arrivera aux 180 jours, je pense étendre par tranches de 60 jours :))
-- CHC
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu
aucune peine à les retrouver, quand au plus vieux (5 janvier) je
pense qu'il devait encore être sur le serveur.
Le serveur est paramétré pour conserver tout fr.* pendant 180 jours et
si le spool n'est pas trop gros au mois de juin (lorsque on arrivera
aux 180 jours, je pense étendre par tranches de 60 jours :))
Sur les 3 M-ID, deux étaient marqués chez moi donc Gnus n'a eu aucune peine à les retrouver, quand au plus vieux (5 janvier) je pense qu'il devait encore être sur le serveur.
Le serveur est paramétré pour conserver tout fr.* pendant 180 jours et si le spool n'est pas trop gros au mois de juin (lorsque on arrivera aux 180 jours, je pense étendre par tranches de 60 jours :))
-- CHC
Xavier Maillard
On 5 May 2005, drkm wrote:
Xavier Maillard writes:
> Voici le MID du message sur lequel je coince:
> Message-ID:
On dirait que je te pose des problèmes !-)
Ben disons que maintenant j'évite d'activer ses buttons ne sachant pas si mon Gnus ne va pas partir en live :(
Dommage parce que c'est une fonctionnalité que j'apprécie.
-- ,--. Xavier Maillard, Reims, France ,= ,-_-. =. / ,- ) http://www.emacsfr.org/ ((_/)o o(_)) `-' `-'(. .)`-' `-. Debian, a variant of the GNU operating system. _/
On 5 May 2005, drkm wrote:
Xavier Maillard <zedek@gnu-rox.org> writes:
> Voici le MID du message sur lequel je coince:
> Message-ID: <u3budckcs.fsf@fgeorges.org>
On dirait que je te pose des problèmes !-)
Ben disons que maintenant j'évite d'activer ses buttons ne
sachant pas si mon Gnus ne va pas partir en live :(
Dommage parce que c'est une fonctionnalité que j'apprécie.
--
,--. Xavier Maillard, Reims, France ,= ,-_-. =.
/ ,- ) http://www.emacsfr.org/ ((_/)o o(_))
`-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. _/
