Bug#1066724: chibicc: change upstream

[Urs Janßen]

Package: chibicc
Severity: wishlist

Dear Maintainer,

 seems no longer to be maintained,
but the fork  looks like it is
under active development.
It might be a good idea to switch the upstream source.

Bug#1054209: slrn: score.c:MAX_KEYWORD_LEN too short to filter e.g. Content-Transfer-Encoding

[Urs Janßen]

Package: slrn
Version: 1.0.3+dfsg-6+b1
Severity: normal
Tags: upstream

NOTE: the system info below is NOT correct as the report was sent from a 
different system than the bug was inspected.


-- System Information:
Debian Release: 11.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-25-amd64 (SMP w/6 CPU threads)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages slrn depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u7
ii  libcanlock33.2.2-1
ii  libslang2  2.3.2-5
ii  libssl1.1  1.1.1w-0+deb11u1
ii  libuu0 0.5.20-12

slrn recommends no packages.

Versions of packages slrn suggests:
pn  slrnpull  

Bug#1005024: tin: Hangs, disconnects reproducible on specific

[Urs Janßen]

> The article is not very useful there seem to be problems with MIME, the
> signature does not verify. I have attached a copy from the local
> newsspool.

The issue is that the part with boundary="GvXjxJ+pjyke8COw" is missing
whilst beeing announced. The attached patch from Dennis Preiser should
fix that.
diff -Nurp tin-2.6.2/src/rfc2046.c tin-2.6.2_r1/src/rfc2046.c
--- tin-2.6.2/src/rfc2046.c	2021-12-22 14:24:50.0 +0100
+++ tin-2.6.2_r1/src/rfc2046.c	2022-02-07 14:07:23.0 +0100
@@ -1237,6 +1237,7 @@ parse_multipart_article(
 		fprintf(artinfo->raw, "%s\n", line);
 	artinfo->hdr.ext->line_count++;
 }
+return tin_errno | TIN_EOF;		/* Flag EOF */
 			}
 #endif /* 0 */
 			return tin_errno;
@@ -1277,8 +1278,12 @@ parse_multipart_article(
 		int ret, old_line_count;
 
 		old_line_count = curr_part->line_count;
-		if ((ret = parse_multipart_article(infile, artinfo, curr_part, depth + 1, show_progress_meter)) != 0)
+		if ((ret = parse_multipart_article(infile, artinfo, curr_part, depth + 1, show_progress_meter)) != 0) {
+			/* Strip off EOF condition if present */
+			if (ret & TIN_EOF)
+ret ^= TIN_EOF;
 			return ret;			/* User abort or EOF reached */
+		}
 		if (part && part != artinfo->hdr.ext)
 			part->line_count += curr_part->line_count - old_line_count;
 		if (is_rfc822 && rfc822_part)

Bug#999941: tin: depends on obsolete pcre3 library

[Urs Janßen]

On Thu, Nov 18, 2021 at 01:06:32PM +0100, Marco d'Itri wrote:
> On Nov 18, Matthew Vernon  wrote:
> 
> > Many large projects that use PCRE have made the switch now (e.g. git,
> > php); it does involve some work, but we are now at the stage where
> > PCRE3 should not be used, particularly if it might ever be exposed to
> > untrusted input.
> For the records: I would love to switch, but it is not totally obvious 
> to me by looking at the configure script that tin supports pcre2.

it does not, switching to pcre2 is on the TODO list for several years now
but so far no one has touched the corresponding code and I doubt this will
happen in the near future with hardly any developpers left.

Bug#849270: tin: forced authentication (-A) broken

[Urs Janßen]

On Sat, Dec 24, 2016 at 02:56:28PM +0100, Michael Karcher wrote:
> The patches you pulled from the unreleased version 2.4.1 are known to break
> -A to force nntp authentication. A fix is available in
>   http://lists.tin.org/pipermail/tin-dev/2016-December/42.html

I belive this has been fixed upstream in tin 2.4.1 (just released).

Bug#832397: tin: fails after reconnection, losing all downloaded data

[Urs Janßen]

On Mon, Jul 25, 2016 at 03:48:57AM +0200, Vincent Lefevre wrote:
> Package: tin
> Version: 1:2.3.2-1
> Severity: important
> 
> On a large newsgroup, tin starts to download the headers, but at
> some point, there's a disconnection. And tin always fails after a
> reconnection. However, if I start tin again, the connection succeeds,
> showing the problem occurs only for a reconnection.
> 
> With "tin -D 1", here's how /tmp/NNTP looks like.
> 
> nntp_open() BEGIN
> nntp_open() news.gandi.net:119
> <<< [01:26:48.881604] 200 groups.gandi.net Papercut server ready (posting 
> allowed)
> nntp_open() groups.gandi.net Papercut server ready (posting allowed)
[...]
> >>> [01:26:50.929886] LIST
> <<< [01:26:51.136585] 215 list of newsgroups follows
> nntp_command(LIST) OK
> <<< [01:26:51.136650] gandi.en.api 166 1 y
[...]
> <<< [01:26:51.136861] gandi.fr.domaine 8478 1 y
[...]
> nntp_command(LISTGROUP gandi.fr.domaine)
> >>> [01:26:54.579698] LISTGROUP gandi.fr.domaine
> <<< [01:26:54.935979] 211 8317 1 8478 gandi.fr.domaine Article numbers follow 
> (multiline)
> nntp_command(LISTGROUP gandi.fr.domaine) OK
> setup_hard_base(LISTGROUP gandi.fr.domaine)
> nntp_command(XOVER 1-8478)
> >>> [01:26:54.980474] XOVER 1-8478
> <<< [01:27:06.850014] 224 Overview information follows
> nntp_command(XOVER 1-8478) OK

the XOVER response from the server is empty, thus tin tries XHDR XREF

> nntp_command(XHDR XREF 1-8478)
> >>> [01:27:06.850150] XHDR XREF 1-8478
> <<< [01:27:06.860971] 501 command syntax error (or un-implemented option)
> nntp_command(XHDR XREF 1-8478) NOT_OK

which fails so it uses HEAD (damned slow) instead

> nntp_command(HEAD 1)
> >>> [01:27:06.861101] HEAD 1
> <<< [01:27:06.920651] 221 1 <45ca0f06$0$22737$afc38...@groups.gandi.net> 
> article retrieved - head follows
> nntp_command(HEAD 1) OK
> nntp_command(HEAD 2)
> >>> [01:27:06.920916] HEAD 2
> <<< [01:27:06.980840] 221 2 <45ca0f7a$0$22731$afc38...@groups.gandi.net> 
> article retrieved - head follows
> nntp_command(HEAD 2) OK
[...]
> >>> [01:31:51.906590] HEAD 4702
> <<< [01:31:51.967943] 221 4702 
> <95d6f1cc7df4d5dac6dd6736fc53e...@groups.gandi.net> article retrieved - head 
> follows
> nntp_command(HEAD 4702) OK
> nntp_command(HEAD 4703)
> >>> [01:31:51.968080] HEAD 4703

and here the connection is closed by the server for whatever reason

(verified manually via:
~ > telnet groups.gandi.net 119
Trying 217.70.184.33...
Connected to groups.gandi.net.
Escape character is '^]'.
200 groups.gandi.net Papercut server ready (posting allowed)
GROUP gandi.fr.domaine
211 8317 1 8478 gandi.fr.domaine group selected
head 4703
Connection closed by foreign host.

so tin reconnects and retires the last HEAD again:

> >>> [01:31:56.123696] GROUP gandi.fr.domaine
> <<< [01:31:56.252672] 211 8317 1 8478 gandi.fr.domaine group selected
> 
> >>> [01:31:56.252717] HEAD 4703

till it reaches its reconnection limit, and then quits with (undocumented)
NNTP_ERROR_EXIT (3)

> And then tin quits with no error messages, and exit status 3, which is

there should have been a "NNTP connection error. Exiting..."
message (shown for 2 seconds but then [n]curses is switched off ...).
I've added a log message to the NNTP-log when started with -D 1 now:
"reconnect(3) limit 2 reached, giving up".

> If I restart tin and retry on the same newsgroup, it starts again
> to download the headers from 1! Thus it is impossible to read this
> newsgroup.

you can use "-G positive_number" to download only the last n articles
(i.e. tin -G 2500 -g groups.gandi.net) - but with that buggy server there is
currently no way to read all articles (except 4703).

HTH,
urs
-- 
"Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;)" - Linus

Bug#700464: tin: [PATCH] wrap lines between words (word wrap)

[Urs Janßen]

On Tue, Feb 12, 2013 at 09:45:37PM +, Tilmann Hentze wrote:
 Dear Maintainer,
 tin should wrap lines between and not within words, except when a single word
 is longer than a line. The attached patch probably does this.

this breaks the article display with news_headers_to_display in effect


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700464: tin: [PATCH] wrap lines between words (word wrap)

[Urs Janßen]

On Wed, Feb 13, 2013 at 06:41:57PM +, Tilmann Hentze wrote:
 Quoting Urs Janßen on 2013-02-13 09:00:20 (+0100):
  this breaks the article display with news_headers_to_display in effect
 The patch below should address this problem.

but doesn't respect verbatim handling and may break long quoted lines right
after the quote char leaving a single quote char in one line and the
contents in a second without indicating that the line is quoted ...

I will not include any of these half-baked patches upstream and even if you
address all of the (and there are more than the mentioned ones) problems,
such a change should be made configurable by the user with the default to
the _current_ behaviour.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671170: tin: Enable command line option -D by recompiling with -DDEBUG

[Urs Janßen]

On Wed, May 02, 2012 at 11:44:52AM +0200, Marco d'Itri wrote:
 On May 02, Jari Aalto jari.aa...@cante.net wrote:
 
  Option not enabled. Recompile with -DDEBUG.
 Maybe there is a reason if this is not the default.
 Did you investigate which side effects this causes, especially related 
 to performances?

as using -D has some security issues:

| SECURITY
|When tin is started in debug mode (’’-D n’’) it will create world 
read‐
|able  files  in  $TMPDIR  which  may contain the users NNTP password in
|cleartext. On multiuser-systems $TMPDIR should be set to a  safe loca‐
|tion before starting tin in debug mode (e.g.  TMPDIR=$HOME tin -D 1).

the default is to disable -D at compile time. If tin wouldn't use $TMPDIR
but i.e.  ${TIN_HOMEDIR:-$HOME} or the like as default localtion this
wouldn't be an issue, unfortunately $TMPDIR (or even hardcoded /tmp) was
choosen about 20 years ago and I don't like to change the well known
location of files...

When tin is compiled with -DDEBUG // --enable-debug but -D n isn't given
at startup there should be no noticible drawbacks; all the debugging code is
guarded by

#ifdef DEBUG
 if (debug  DEBUG_LEVEL) {
/* ... */
 }
#endif

HTH,
urs



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652648: tin tries to authenticate when CAPABILITIES gives 500

[Urs Janßen]

On Mon, Dec 19, 2011 at 03:38:30PM +, Ian Jackson wrote:
 Package: tin
 Version: 1:1.9.6~20100522-1
 
 My news server does not implement CAPABILITIES.  This results in tin
 asking the user for a username and password.  This is wrong; it should
 try MODE READER and if that is also not understood it should carry on
 without asking for authentication unless it gets 480.

This is fixed in tin 2.0.0

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652642: tin tries AUTHINFO USER before AUTHINFO GENERIC

[Urs Janßen]

On Mon, Dec 19, 2011 at 03:23:43PM +, Ian Jackson wrote:
 When it tries to do this authentication, it prompts the user for a
 username and password and then uses AUTHINFO USER.  However, I have
 NNTPAUTH set and my server uses AUTHINFO GENERIC.  So tin should, if
 it wants to authenticate, do AUTHINFO GENERIC.

AUTHINFO GENERIC was removed from tin (starting with 1.9.5) as it's
deprecated by RFC 4643.

-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#204254: tin quits without postponing the article when the connection to the server fails

[Urs Janßen]

JFTR, the follwoing patch to fix this will be in the next unstable
release (1.9.6).

=== modified file 'include/proto.h'
--- include/proto.h 2010-09-12 21:11:20 +
+++ include/proto.h 2010-09-26 11:59:32 +
@@ -473,6 +473,7 @@
 #endif /* !HAVE_VSNPRINTF */
 
 /* post.c */
+extern char *backup_article_name(const char *the_article);
 extern char *checknadd_headers(const char *infile, struct t_group *group);
 extern int count_postponed_articles(void);
 extern int mail_to_author(const char *group, int respnum, t_bool copy_text, 
t_bool with_headers, t_bool raw_data);

=== modified file 'src/nntplib.c'
--- src/nntplib.c   2010-09-12 21:11:20 +
+++ src/nntplib.c   2010-09-26 14:11:32 +
@@ -829,8 +829,15 @@
 * Exit tin if the user says no to reconnect. The exit code stops tin 
from trying
 * to disconnect again - the connection is already dead
 */
-   if (!tinrc.auto_reconnect  prompt_yn(_(txt_reconnect_to_news_server), 
TRUE) != 1)
+   if (!tinrc.auto_reconnect  prompt_yn(_(txt_reconnect_to_news_server), 
TRUE) != 1) {
+   if (!strncmp(POST, last_put, 4)) {
+   unlink(backup_article_name(article_name));
+   rename_file(article_name, dead_article);
+   if (tinrc.keep_dead_articles)
+   append_file(dead_articles, dead_article);
+   }
tin_done(NNTP_ERROR_EXIT);  /* user said no to 
reconnect */
+   }
 
/*
 * reset signal_context
@@ -862,8 +869,15 @@
return 0;
}
 
-   if (--retry == 0)   /* No more 
tries? */
+   if (--retry == 0) { /* No more 
tries? */
+   if (!strncmp(POST, buf, 4)) {
+   unlink(backup_article_name(article_name));
+   rename_file(article_name, dead_article);
+   if (tinrc.keep_dead_articles)
+   append_file(dead_articles, dead_article);
+   } 
tin_done(NNTP_ERROR_EXIT);
+   }
 
return retry;
 }

=== modified file 'src/post.c'
--- src/post.c  2010-09-11 16:08:21 +
+++ src/post.c  2010-09-26 11:58:59 +
@@ -129,7 +129,6 @@
 static FILE *create_mail_headers(char *filename, size_t filename_len, const 
char *suffix, const char *to, const char *subject, struct t_header *extra_hdrs);
 static char **build_nglist(char *ngs_list, int *ngcnt);
 static char **split_address_list(const char *addresses, unsigned int *cnt);
-static char *backup_article_name(const char *the_article);
 static int add_mail_quote(FILE *fp, int respnum);
 static int check_article_to_be_posted(const char *the_article, int art_type, 
struct t_group **group, t_bool art_unchanged);
 static int mail_loop(const char *filename, t_function func, char *subject, 
const char *groupname, const char *prompt, FILE *articlefp);
@@ -295,7 +294,7 @@
  * submit_news_file adds headers, does q-p conversion etc
  * TODO: why not use BACKUP_FILE_EXT like in misc.c?
  */
-static char *
+char *
 backup_article_name(
const char *the_article)
 {



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#597427: tin: Suggests removed package metamail

[Urs Janßen]

On Sun, Sep 19, 2010 at 06:16:45PM +0200, Marco d'Itri wrote:
  metamail was removed from unstable
  http://packages.qa.debian.org/m/metamail/news/20091217T215210Z.html
  and will not be part of squeeze however tin still suggests it.
 It's not like there is a replacement...

tin has a built in mime-parser (metamail_prog in tinrc set to empty)
and comes with metamutt, a metamail replacement which relies on mutt (in
the tools dir). the built in mime-parser usualy suffices.

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#416690: tin: UTF-8 problems

[Urs Janßen]

The mentioned bug is fixed in 1:1.9.6~20100401-1, there were a few more
related problems found after the last snapshot (countig bytes instead of
chars in multibyte env.; truncating strings in the middle of a multibyte
sequence) which have been fixed upstream, but the code is not yet released.
Anyway, #416690 is fixed in 1:1.9.6~20100401-1.

urs




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#541472: tin: mark selected articles as (un)read

[Urs Janßen]

This bug is fixed upstream in the 1.9.5er release

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557528: tin: feed_articles() segfaults on spurious SIGPIPE

[Urs Janßen]

This bug is fixed upstream in the 1.9.5er release

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534747: tin: no timeout on NNTP connection

[Urs Janßen]

This bug is fixed upstream in the 1.9.5er release




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#541472: tin: mark selected articles as (un)read

[Urs Janßen]

On Fri, Aug 14, 2009 at 07:11:29PM +0200, Marco d'Itri wrote:
 On Aug 14, Frédéric Brière fbri...@fbriere.net wrote:
 
  Here's a patch for something I've always missed in tin: the ability to
  mark selected articles as read/unread.  This patch maps these commands
  to ^X (read) and ^Y (unread), which were pretty much the only remaining
  free keys at this point.
 How is this different from z?

it works on feeds (i.e. tagged arts or hot arts), for hot arts '^X' is
the same as the following 3 cmd executed in order:
'@' - revers hot arts
'X' - mark all !hot arts read
'@' - revers hot arts OR '~' undo all selections

there is no '^Y' equivalent as there (usualy) is no such think as a read hot
article.

currently the is no functionallity to mark read/unread tagged arts.

The idea behind this patch is good, there are a few minor issues:
- the keys do not work in the thread-level
- the keys are not documented on the internal help page
- the keys are not documented in the manpage
- instead of having new keys for the functionallity one might add this
  functionallity to 'K'/'Z' (if no hot or tagged arts are available, 'K'/'Z'
  could work the way they do now, if there are tagged and/or hot arts
  we could prompt 'mark t=thread, h=hot, p=pattern, T=tagged articles
  (un)read' like it's done for 's'ave. I'm unsure if the is a good idea.

urs




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#541472: tin: mark selected articles as (un)read

[Urs Janßen]

On Fri, Aug 14, 2009 at 03:21:16PM -0400, Frédéric Brière wrote:
 On Fri, Aug 14, 2009 at 08:48:09PM +0200, Urs Janßen wrote:
  'X' - mark all !hot arts read
 Isn't 'X' merely a display command?

'X' marks all not hot unread articles read. it's the same as auto_select in
attributes and usefull in high traffic groups where you are only interrested
in the hot articles (i.e. a group which covers various topics but you are
only interrested in a subset. sometimes it's more easy to mark that subset
as hot and (auto) 'X' out the rest than to setup a kill-filter for all topic
you're not interrested in).




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#231070: tin: Left arrow causes article discard in Check Prepared Article page

[Urs Janßen]

this has been fixed upsteam on 2009-03-06 and thus is fixed in
unstable 1:1.9.5~20090720-1

urs




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#526646: tin crashes if server doesn't support either CAPABILITIES or MODE READER

[Urs Janßen]

On Sat, May 02, 2009 at 04:34:01PM +0300, Antti-Juhani Kaijanaho wrote:
 Package: tin
 Version: 1:1.9.4-1
 Severity: minor
 
 If tin receives 500 for both CAPABILITIES and MODE READER, it loops trying
 both and eventually crashes.
 
 The cause of the crash seems to be on line 1148 of src/nntplib.c, where
 the check_extensions function is called recursively if both CAPABILITIES and
 MODE READER fail, eventually exhausting the stack space.  The comment says 
 that
 this is for a second attempt, but there is no check that we aren't already in
 the second (or the five hundreth) attempt.
 
 (Minor because this was uncovered in testing an incomplete server - I do not
 know how widespread servers that trigger this are in the wild.  However, I do
 not believe a client should crash however broken the server is.)

this is already fixed upstream in the lastest snapshot

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525917: tin incorrectly reports posting is not allowed

[Urs Janßen]

On Mon, Apr 27, 2009 at 04:55:29PM -0400, Dennis Boone wrote:
 Subject: tin incorrectly reports posting is not allowed
 Package: tin
 Version: 1:1.9.4-1
 Severity: normal
 
 *** Please type your report below this line ***
 After authenticating to giganews, tin reports:
 
   *** Posting not allowed ***
 
 Followup and Write then refuse to allow posting.  If I allow the

this is due giganews not announcing reader, mode-reader or post (and till
two weeks ago not even which auth methods are available) _before_
autheticating. this has been discussed in news.software.readers and IMHO is
a missinterpretation of RFC 3977 on the giganews side, but I have fixed tins
source to try auth if only auth is advertized (this is what giganews now
sends). IOW there is a workaround in the next snapshot/minor release even if
this giganews fault. (giganews violates the RFC on some other points too,
i.e.. decrementing the low watermark or exceeding the 2^31-1 articlenumber
limit).

 connection to time out and then enter a group, tin reconnects, and
 is subsequently willing to post.
 
 Looking at network traces, gn lists these capabilities:
 
   VERSION 2
   READER
   POST
   LIST OVERVIEW.FMT ACTIVE ACTIVE.TIMES NEWSGROUPS
   XFEATURE 1
   XFEATURE-COMPRESS GZIP TERMINATOR
   XFEATURE-METADATA BYTES
   XFEATURES 1

this is after authetication (which happens on reconnect). 

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#520444: several memleaks in libcanlock2, untested patch included

[Urs Janßen]

Package: libcanlock2
Version: 2b-4
Severity: minor
Tags: patch

below is a _untested_ patch which should fix several memleaks in
libcanlock2, please review carefully befor applying.

diff -Nur include/canlock.h include/canlock.h
--- include/canlock.h   2008-12-11 20:31:24.0 +0100
+++ include/canlock.h   2009-03-19 21:29:49.975475417 +0100
@@ -4,5 +4,5 @@
const unsigned char *message, size_t msglen);
 int sha_verify(const char *key, const char *lock);
 
-char *lock_strip_alpha(const char *key, char *type);
-char *lock_strip(const char *key, char *type);
+char *lock_strip_alpha(char *key, char *type);
+char *lock_strip(char *key, char *type);
diff -Nur src/canlock.c src/canlock.c
--- src/canlock.c   2008-12-11 20:31:24.0 +0100
+++ src/canlock.c   2009-03-19 21:30:23.540492221 +0100
@@ -47,9 +47,9 @@
  * type is set to the lock type, else zero on failure.
  */
 char *
-lock_strip_alpha(const char *key, char *type)
+lock_strip_alpha(char *key, char *type)
 {
-char *ret;
+char *ret, *p = key;
 int offset;
 do {
   *type = tolower(*key);
@@ -59,19 +59,20 @@
 
 *type = '\0';
 key++;
+free(p);
 ret = strdup (key);
 /* Strip the Clue-string, no longer part of the lastest
  * draft but could still be present */
 offset = 0;
 while (ret[offset]  ret[offset] != ':')
-   offset++;
+   offset++;
 ret[offset] = '\0';
 return ret;
 }
 
 
 char *
-lock_strip(const char *key, char *type)
+lock_strip(char *key, char *type)
 {
 return lock_strip_alpha(key, type);
 }
@@ -129,10 +130,15 @@
 sha_key(secret, seclen, message, msglen), junk);
 if (!cankey)
 return NULL;
-if (sha_init(hash_ctx))
+if (sha_init(hash_ctx)) {
+   free(cankey);
 return NULL;
-if (sha_update(hash_ctx, cankey, strlen((char *) cankey)))
+   }
+if (sha_update(hash_ctx, cankey, strlen((char *) cankey))) {
+   free(cankey);
 return NULL;
+   }
+   free(cankey);
 if (sha_digest(hash_ctx, hmacbuff))
 return NULL;
 locksize = base64_encode(hmacbuff, SHA_DIGESTSIZE, canlock);
diff -Nur src/hmac_sha1.c src/hmac_sha1.c
--- src/hmac_sha1.c 2008-12-11 20:31:24.0 +0100
+++ src/hmac_sha1.c 2009-03-19 20:24:11.979149316 +0100
@@ -95,10 +95,15 @@
 
 memcpy(step2[SHA_DATASIZE], T, Tlen);
 
-if (sha_init(hash_ctx))
+if (sha_init(hash_ctx)) {
+   free(step2);
 return NULL;
-if (sha_update(hash_ctx, step2, SHA_DATASIZE + Tlen))
+   }
+if (sha_update(hash_ctx, step2, SHA_DATASIZE + Tlen)) {
+   free(step2);
 return NULL;
+   }
+   free(step2);
 if (sha_digest(hash_ctx, step4))
 return NULL;
 
@@ -108,12 +113,18 @@
 if (!hmac_out)
 return NULL;
 
-if (sha_init(hash_ctx))
+if (sha_init(hash_ctx)) {
+   free(hmac_out);
 return NULL;
-if (sha_update(hash_ctx, step5, SHA_DATASIZE + SHA_DIGESTSIZE))
-return NULL;
-if (sha_digest(hash_ctx, hmac_out))
+   }
+if (sha_update(hash_ctx, step5, SHA_DATASIZE + SHA_DIGESTSIZE)) {
+   free(hmac_out);
+return NULL;
+   }
+if (sha_digest(hash_ctx, hmac_out)) {
+   free(hmac_out);
 return NULL;
+   }
 
 return hmac_out;
 }




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#252780: tin: Article not correctly displayed when the article charset differs from the local one

[Urs Janßen]

The mentioned bug should have been fixed several releases ago.
I can't reproduce it with either the etch or the lenny/sid-package - I
didn't check the sarge package.

urs




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301020: tin: freeze after catchup

[Urs Janßen]

Package: tin
fixed-upstream

this bug has been fixed upstream in the 1.9.3 (20080506) release in the 
following
way:

1) rewrote the overview.fmt/overview parser so it can use Xref:-fields
   even if they are not announced the the overview.fmt
2) use a single XHDR XREF low-high instead of high-low times XHDR XREF num
   if no Xref:-field is found in XOVER output (reduces traffic and sppeds up
   things).




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#323449: tin hanged with: Can't retrieve active

[Urs Janßen]

this has been fixed in tin = 1.8.2

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#395101: Source package contains non-free IETF RFC/I-D's

[Urs Janßen]

JFYI: I've removed them from the upstream source

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#374462: by Msg-ID option in kill/autoselect menu inserts msgid not msgid_only in .tin/filter

[Urs Janßen]

On Mon, Jun 19, 2006 at 05:14:49PM +0200, Torsten Jerzembeck wrote:
 Package: tin
 Version: 1:1.8.2-1
 Severity: minor
 
 In order to add new entries to the .tin/filter file, tin offers a menu
 screen with several options. One of these options is to enter free form
 text and to choose between some common options where tin should apply
 this text.
 
 However, if one selects the option Apply pattern to: Message-ID: line,
 tin creates a scoring rule with the keyword msgid, which matches the
 contents of the Message-ID _and_ the References header. In my opinion
 the rule created should use the msgid_only keyword.

quick and dirty fix:

--- filter.c2006-02-15 19:44:37.0 +0100
+++ filter.c2006-06-19 18:32:11.384235114 +0200
@@ -1165,8 +1165,9 @@
case FILTER_SUBJ_CASE_SENSITIVE:
case FILTER_FROM_CASE_SENSITIVE:
case FILTER_MSGID:
-   case FILTER_MSGID_LAST:
-   case FILTER_MSGID_ONLY:
+   rule.counter = FILTER_MSGID_ONLY;
+/* case FILTER_MSGID_LAST:
+   case FILTER_MSGID_ONLY: */
/* rule.icase is FALSE already, no assignment 
necessary */
break;
 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#174527: tin: broken multi-byte character set entries

[Urs Janßen]

the multibyte problems in getline.c should have been fixed in
tin = 1.7.6

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#347422: tin: buffer overflow in maildir check

[Urs Janßen]

On Tue, Jan 10, 2006 at 10:53:00AM -0500, Chung-chieh Shan wrote:
 Package: tin
 Version: 1:1.8.0-1
 Severity: important
 Tags: patch
 
 Hello,
 
 If the user's mailbox is a Maildir directory, then mail_check() in
 misc.c allocates one too few byte to store the name of the new
 subdirectory of the Maildir directory, because joinpath() assumes that
 the given file name (in this case, MAILDIR_NEW) does not begin with
 a slash.  The following patch removes the slash at the beginning of
 MAILDIR_NEW and makes tin start for me again.
 
 --- tin-1.8.0.orig/src/misc.c.orig
 +++ tin-1.8.0/src/misc.c
 @@ -912,7 +912,7 @@
   *
   * TODO: why not cache the mailbox_name?
   */
 -#define MAILDIR_NEW  /new
 +#define MAILDIR_NEW  new
  t_bool
  mail_check(
   void)
 
 Thanks,
   Ken

thanks, I've applied your fix upstream

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#323449: tin hanged with: Can't retrieve active

[Urs Janßen]

On Tue, Aug 16, 2005 at 10:42:11PM +0200, Miernik wrote:
 Package: tin
 Version: 1:1.7.10+20050815-1
 Severity: normal
 
 I am running tin as rtin with a local newsserver (noffle), and today
 rtin was running as usual, I have 51 groups in my .newsrc, and I was
 away from the computer. When I came back, I see rtin hanged, no reaction
 to any keys, and displaing in the last line of the screen:
 
 Can't retrieve active

sounds like noffle died or closed the link without a propper feedback to the
client - as the client can not recognize if the server has closed the
connection (if it doesn't give any feedback) till some kind of timeout will
occur it sits there and wait's for data (e.g. the active file). this is a
server error, not a client one, but the client could have a timeout to
detect it (tin doesn't have such a timout anymore, it was removed during
some rewrite of the (network)reading code a few years ago).

 Looks like it's stuck on connection to local newsserver. But it is like
 that since half an hour at least, it should time out or something. There

as mentioned above it's the servers fault if it shut's down the connection
without telling the client,.but the client should have some kind of
timeout to catch the (rare) case that the server fails to tell the client
that it had closed the connection. tin once had such a fature but it got
lost dring the rewrite of read.c. if anyone is willing to fix this look for
NNTP_READ_TIMEOUT.

news.arcor.de (dumb cluster setup) has the 'same' prolem, long ideling
clients are timed out on the server side but the server fails to tell this
the client ...

 is not much I can do besides killing it.

ps xauww | awk '/[t]in/{print $2}' | kill -1

sould be 'safe' (newsrc should be written out propper).

 Finally I did:
 
 jaworz:~$ sudo killall noffle
 jaworz:~$ sudo killall noffle
 jaworz:~$ sudo killall -9 noffle
 jaworz:~$ sudo killall -9 noffle
 noffle: no process killed
 jaworz:~$
 
 And then rtin did quit too.

as it noticed that the connection was closed when the server finally died

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301020: tin: freeze after catchup

[Urs Janßen]

On Wed, Mar 23, 2005 at 12:19:29PM +0100, Vincent Lefevre wrote:
 If I do a tin -ag mozilla, then enter the group
 netscape.public.mozilla.calendar, I can read it, but when I do a
 catchup from the group index (c [Enter]), tin freezes. I can type
 Ctrl-\, but unfortunately, the core doesn't give much information:

afer compiling tin with -DDEBUG and calling it with -D 1 it shows
that tin doesn't feeze but is damned slow (the XHDR XREF fallback
code doesn't look very optimal, but as it usualy shouldn't be needed
at all that's ok). if you don't like that feature you can recompile
with --disable-xhdr-xref. on 'normal' configured servers this is no
disadvantage, but on servers which do not have the Xref:full in thier
overviews tin isn't able to mark crossposted articles as read when
one of them is read.
local overview caching might also help to sped up things on such
servers (didn't test that).

tin-dev: it might be a good idea to use XHDR XREF - instead of
single XHDR XREF num to speed up things (or at least do it in some
chunks XHDR XREF n-m XHDR XREF m+1 - p ... or stream the querys)
anyone willing to look at this?

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301020: tin: freeze after catchup

[Urs Janßen]

On Thu, Mar 24, 2005 at 06:47:27PM +0100, Vincent Lefevre wrote:
 On 2005-03-24 16:12:38 +0100, Urs Janßen wrote:
  afer compiling tin with -DDEBUG and calling it with -D 1 it shows
  that tin doesn't feeze but is damned slow (the XHDR XREF fallback
  code doesn't look very optimal, but as it usualy shouldn't be needed
  at all that's ok).
 
 What do you mean by slow?

takes several minutes (I didn't do a timing but it was something like
half an hour for that group on that server).

 I did a top, and tin was taking 0% CPU time.
 Or was it doing transfers with the server?

tin is sending NNTP commands and receving the related answers - you
should see network traffic, but it doesn't cost (much) cpu.

  if you don't like that feature you can recompile with
  --disable-xhdr-xref. on 'normal' configured servers this is no
  disadvantage, but on servers which do not have the Xref:full in
  thier overviews tin isn't able to mark crossposted articles as read
  when one of them is read.
 
 I don't understand. When doing a catchup, tin shouldn't mark the
 crossposted versions as read since they haven't been read. This

of course it should, that's what x-post are for (if you read it in
one group you don't have to read it again in another group) - that's
the way all newsreaders handle crossposts and that's the way tin ever
handled crossposts.

 is particularly important when an article is crossposted to a
 low-bandwidth group and a high-bandwidth group (or a group on a
 less important topic). In the latter one, I don't have the time
 to read everything, so that I often do a catchup there without
 checking in details first. Or there could be an option concerning
 the catchup behavior.

feel free top implement it (or just do it as well all do it, read the
low traffic grouos before catching up the high traffic groups).

urs



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301020: tin: freeze after catchup

[Urs Janßen]

On Thu, Mar 24, 2005 at 07:18:01PM +0100, Vincent Lefevre wrote:
  (or just do it as well all do it, read the low traffic grouos before
  catching up the high traffic groups).
 Note that this is subject to a race condition.

only if you 'resync' (manually or automatically) against the servers
active file. 

urs



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301020: tin: freeze after catchup

[Urs Janßen]

On Wed, Mar 23, 2005 at 12:19:29PM +0100, Vincent Lefevre wrote:
 Package: tin
 Version: 1:1.7.8+20050314-1
 Severity: normal
 
 My .tin/newsrctable contains:
 
 news.mozilla.org.newsrc-mozilla mozilla
 
 If I do a tin -ag mozilla, then enter the group
 netscape.public.mozilla.calendar, I can read it, but when I do a
 catchup from the group index (c [Enter]), tin freezes. I can type
 Ctrl-\, but unfortunately, the core doesn't give much information:

it's realted to not having xref infos in the overview file and thus
tin is trying to use XHDR XREF instead,

| Your server does not have Xref: in its XOVER information.
| Tin will try to use XHDR XREF instead (slows down things a bit).

it hangs somewhere here:

#8  0x40169d6f in fgets () from /lib/libc.so.6
#9  0x08072930 in get_server (string=0x81ef918 ., size=1022) at nntplib.c:916
#10 0x0808239d in tin_read (buffer=0x81ef918 ., len=1022, fp=0x270f, 
header=0) at read.c:228
#11 0x08082510 in tin_fgets (fp=0x270f, header=0) at read.c:357
#12 0x08072fbb in get_only_respcode (message=0x0, mlen=0) at nntplib.c:1422
#13 0x08073086 in get_respcode (message=0x0, mlen=0) at nntplib.c:1490
#14 0x08073184 in nntp_command (command=0xbfffea20 XHDR XREF 44, 
success=221, message=0x0, mlen=0) at nntplib.c:1553
#15 0x08091497 in read_xref_header (art=0x405dbb30) at xref.c:129
#16 0x08091586 in art_mark_xref_read (art=0x405dbb30) at xref.c:178

the 'same' error might occur on that server if using a filter entry
(against crossposts):

#8  0x40169d6f in fgets () from /lib/libc.so.6
#9  0x08072930 in get_server (string=0x81f4460 ., size=1022) at
nntplib.c:916
#10 0x0808239d in tin_read (buffer=0x81f4460 ., len=1022,
fp=0x270f, 
header=0) at read.c:228
#11 0x08082510 in tin_fgets (fp=0x270f, header=0) at read.c:357
#12 0x08072fbb in get_only_respcode (message=0x0, mlen=0) at
nntplib.c:1422
#13 0x08073086 in get_respcode (message=0x0, mlen=0) at
nntplib.c:1490
#14 0x08073184 in nntp_command (command=0xbfffe9ec XHDR XREF 704, 
success=221, message=0x0, mlen=0) at nntplib.c:1553
#15 0x08091497 in read_xref_header (art=0x405e11c8) at xref.c:129
#16 0x08091586 in art_mark_xref_read (art=0x405e11c8) at xref.c:178

currently I have no idea what is going wrong and I don't know when
I'll find the time to look at this.

urs



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#294802: tin: line-wrap in German filter menu

[Urs Janßen]

On Fri, Feb 11, 2005 at 07:02:50PM +0100, Christian Garbs wrote:
 In the German filter menu (scoring for articles) the item
 Wähle Msg-Id has four values:
 
  * Nur
  * Nein
  * Voll
  * Letzte
 
 Letzte is too long and always wrapped around to the next line,
 regardless of screen width.  It looks to me like 5 characters are
 reserved for the option but 6 are needed.

quick and dirty fix: in filter.c:filter_menu() increase len by 3
(estonian values are even longer), e.g.:
len = cCOLS - 33;
instead of
len = cCOLS - 30;

right thing would be some dynamic space calculation depening on the
length of the longest translated value...

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#293978: tin does not work with news.mozilla.org (freeze at the beginning)

[Urs Janßen]

On Mon, Feb 07, 2005 at 04:49:21PM +0100, Urs Janßen wrote:
   LIST EXTENSION isn't specified by an RFC and it looks like that it
   will never be officially implemented (CAPABILITIES might be it's
   replacement). so officiall we can't blame the netscape server, but
   usualy INN is regarded as reference implementation so I'd say that
   expecting an 202 answer is the right thing and the server is
   'buggy'. there is still tins problem with unexpected multiline
   responses and getting out of sync...
  OK. However, in the absence of a specification by an RFC, tin should
  support the Netscape answer.
 there is a draft wich 'defines' the responsecode:
 draft-ietf-nntpext-base-24.txt, section 5.3
 
 | 5.3  LIST EXTENSIONS
 | 5.3.1  Usage
 |This command is optional.
 |Syntax
 |   LIST EXTENSIONS
 |Responses
 |   202   Extension list follows (multiline)
 |   402   Server has no extensions
 
 but as mentioned above the command might be replaced with the new
 CAPABILITIES command which might have a different returncode (looks
 like it will be 101 for success as stated in
 draft-ietf-nntpext-authinfo-06.txt and
 draft-ietf-nntpext-streaming-03.txt).

and in the upcomming draft-ietf-nntpext-base-25.txt draft which is not
yet released, but a preview is available at
http://www.davros.org/nntp-texts/draft25.txt

anyway, attached is a diff against a plain tin-1.7.7er source which
should work around that problem and which implements basic
CAPABILITIES support (which is tried first, but AFAIK there is no
server which currently supports it, so you might want to comment it
out (#if 1 - #if 0)). if you (or Marco) doen't like this hack I
suggest to simply remove the call to check_extensions() (at least from the
tin versions in stable).

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#293978: tin does not work with news.mozilla.org (freeze at the beginning)

[Urs Janßen]

On Thu, Feb 10, 2005 at 02:30:25PM +0100, Urs Janßen wrote:
 anyway, attached is a diff against a plain tin-1.7.7er source which

next try...

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus
--- tin-1.7.7/src/nntplib.c 2004-11-15 18:44:25.0 +0100
+++ tin-1.7.7/src/nntplib.c 2005-02-10 14:17:41.0 +0100
@@ -51,7 +51,8 @@
static constext *xhdr_cmd = NULL;
static constext *xhdr_cmds = XHDR;
 #  endif /* 0 */
-   static t_bool have_list_extensions = FALSE;
+   enum extension_type { NO, LIST_EXTENSIONS, CAPABILITIES };
+   static int have_list_extensions = NO;
/* Set so we don't reconnect just to QUIT */
static t_bool quitting = FALSE;
 #endif /* NNTP_ABLE */
@@ -952,14 +953,9 @@
 
 #ifdef NNTP_ABLE
 /*
- * Try and use LIST EXTENSIONS here. Get this list before issuing
- * other NNTP commands because the correct methods may be
- * mentioned in the list of extensions.
- * Possible extensions include:
- * - HDR  LIST HEADERS
- * - OVER [MSGID]  LIST OVERVIEW.FMT
- * - LISTGROUP
- * - STARTTLS
+ * Try and use CAPABILITIES/LIST EXTENSIONS here. Get this list before
+ * issuing other NNTP commands because the correct methods may be mentioned
+ * in the list of extensions.
  *
  * Sets up: have_list_extensions, xover_cmd, (xhdr_cmd)
  */
@@ -971,47 +967,109 @@
char *ptr;
int i;
 
-   if ((fp = nntp_command(LIST EXTENSIONS, OK_EXTENSIONS, NULL, 0)) == 
NULL)
-   return;
-
-   have_list_extensions = TRUE;
+#  if 1 /* CAPABILITIES will replace LIST EXTENSIONS */
+   if ((fp = nntp_command(CAPABILITIES, INF_CAPABILITIES, NULL, 0)) != 
NULL) {
+   int cap_version = -1;
 
-   while ((ptr = tin_fgets(fp, FALSE)) != NULL) {
-   /*
-* Check for (X)OVER
-* XOVER should not be listed in EXTENSIONS (but sometimes is)
-* checking for it if OVER is not found does no harm.
-*/
-   if (!xover_cmd) {
-   for (i = 1; i = 0; i--) {
-   if (strcmp(ptr, xover_cmds[i]) == 0) {
-   xover_cmd = xover_cmds[i];
-   break;
-   }
+   have_list_extensions = CAPABILITIES;
+   while ((ptr = tin_fgets(fp, FALSE)) != NULL) {
+#  ifdef DEBUG
+   debug_nntp(, ptr);
+#  endif /* DEBUG */
+   /* look for version number */
+   if (cap_version == -1  have_list_extensions == 
CAPABILITIES) {
+   if (!strncasecmp(ptr, VERSION, 7))
+   cap_version = atoi(ptr + 8);
}
+   /* we currently only support CAPABILITIES VERSION 2 */
+   if (cap_version == 2) {
+   /*
+* Check for (X)OVER
+* XOVER should not be listed in CAPABILITIES
+* but checking for it if OVER is not found 
does no harm.
+*/
+   if (!xover_cmd) {
+   for (i = 1; i = 0; i--) {
+   if (strcasecmp(ptr, 
xover_cmds[i]) == 0) {
+   xover_cmd = 
xover_cmds[i];
+   break;
+   }
+   }
+   }
+   /*
+* LIST, READER, SASL, STARTTLS, STREAMING, 
AUTHINFO, HDR, IHAVE
+* IMPLEMENTATION, (MODE-READER)
+*/
+   } else
+   have_list_extensions = NO;
}
-#  if 0 /* currently not used */
-   /*
-* Check for (X)HDR
-* XHDR should not be listed in EXTENSIONS (but sometimes is)
-* checking for it if HDR is not found does no harm.
-*/
-   if (!xhdr_cmd) {
-   for (i = 1; i = 0; i--) {
-   if (strcmp(ptr, xhdr_cmds[i]) == 0) {
-   xhdr_cmd = xhdr_cmds[i];
-   break;
+   }
+#  endif /* 1 */
+
+   if (have_list_extensions == NO) {
+   char buf[NNTP_STRLEN];
+
+   buf[0] = '\0';
+   fp = nntp_command(LIST EXTENSIONS, OK_EXTENSIONS, buf, 
sizeof(buf));
+   if (!fp

Bug#293978: tin does not work with news.mozilla.org (freeze at the beginning)

[Urs Janßen]

On Mon, Feb 07, 2005 at 11:16:38AM +0100, Vincent Lefevre wrote:
 I've created an entry
 news.mozilla.org.newsrc-mozilla mozilla
 in my .tin/newsrctable file. But tin -ag mozilla gives:
 
 tin 1.7.6 release 20040906 (Baleshare) [UNIX] (c) Copyright 1991-2004 Iain 
 Lea.
 secnews.netscape.com Netscape-Collabra/3.52 03615 NNRP ready (posting ok).
 Your server does not have Xref: in its XOVER information.

there are several problems with that server, the first one is that the
Netscape-Collabra/3.52 server responbds with a different returncode
to a list extensions than e.g. inn does.

[Netscape]
| 215 Extensions supported by server.
| SEARCH
| SETGET
| OVER
| XPATTEXT
| XACTIVE
| LISTMOTD
| LISTSUBSCR
| LISTPNAMES
| .

[inn]
| 202 Supported NNTP extensions.
| AUTHINFO USER
| LISTGROUP
| .

tin expects a 202 responsecode otherwise it assumes that the server
doesn't support extensions. unfortunately tin doesn't expect a
multiline response here if the servers answer is not 202, so it
does not fetch the pending data on the socket and gets out of sync.

LIST EXTENSION isn't specified by an RFC and it looks like that it
will never be officially implemented (CAPABILITIES might be it's
replacement). so officiall we can't blame the netscape server, but
usualy INN is regarded as reference implementation so I'd say that
expecting an 202 answer is the right thing and the server is
'buggy'. there is still tins problem with unexpected multiline responses
and getting out of sync...

once you bypassed this problem (either by pathing check_extensions()
to expect 212 or by by not calling check_extensions() at all you
might find more problems like:

nntp command: LISTGROUP netscape.public.beta.feedback.help
: LISTGROUP netscape.public.beta.feedback.help
: 211 Article list follows
LISTGROUP netscape.public.beta.feedback.help: OK
setup_hard_base: LISTGROUP netscape.public.beta.feedback.help
nntp command: OVER 176-179
: OVER 176-179
: 224 data follows
OVER 176-179: OK
read_overview: 0 Bad overview record (6 fields)

and as the server doesn't store the xref header in the overviews you
might see a lot of XHDR XREF calls, but that's just cosmetics.


 Tin will try to use XHDR XREF instead (slows down things a bit).
 Reading keymap file...
 Reading input history file...
 Reading mail active file... 
 Try and save newsrc file again? (Y/n) Y
 
 Then tin freezes.

for me (but this is with the lastest spanshot) it still accepts the 'n'
answer. I didn't had a closer look at the code why it doesn't accept
'Y' here.

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#293978: tin does not work with news.mozilla.org (freeze at the beginning)

[Urs Janßen]

On Mon, Feb 07, 2005 at 04:20:38PM +0100, Vincent Lefevre wrote:
 On 2005-02-07 14:32:47 +0100, Urs Janßen wrote:
  LIST EXTENSION isn't specified by an RFC and it looks like that it
  will never be officially implemented (CAPABILITIES might be it's
  replacement). so officiall we can't blame the netscape server, but
  usualy INN is regarded as reference implementation so I'd say that
  expecting an 202 answer is the right thing and the server is
  'buggy'. there is still tins problem with unexpected multiline
  responses and getting out of sync...
 
 OK. However, in the absence of a specification by an RFC, tin should
 support the Netscape answer.

NNTP usualy doesn't allow two different return-codes for a single
command, so tins code doen't support that.

   Tin will try to use XHDR XREF instead (slows down things a bit).
   Reading keymap file...
   Reading input history file...
   Reading mail active file... 
   Try and save newsrc file again? (Y/n) Y
   
   Then tin freezes.
  
  for me (but this is with the lastest spanshot) it still accepts the
  'n' answer. I didn't had a closer look at the code why it doesn't
  accept 'Y' here.
 
 Yes, it accepts the 'n', but in this case, it quits immediately.
 Not very useful. :(

in your case with the somewhat broken server it the only usefull
thing todo, as tin is 'out of sync' anyway.

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#293978: tin does not work with news.mozilla.org (freeze at the beginning)

[Urs Janßen]

On Mon, Feb 07, 2005 at 04:20:38PM +0100, Vincent Lefevre wrote:
 On 2005-02-07 14:32:47 +0100, Urs Janßen wrote:
  LIST EXTENSION isn't specified by an RFC and it looks like that it
  will never be officially implemented (CAPABILITIES might be it's
  replacement). so officiall we can't blame the netscape server, but
  usualy INN is regarded as reference implementation so I'd say that
  expecting an 202 answer is the right thing and the server is
  'buggy'. there is still tins problem with unexpected multiline
  responses and getting out of sync...
 
 OK. However, in the absence of a specification by an RFC, tin should
 support the Netscape answer.

there is a draft wich 'defines' the responsecode:
draft-ietf-nntpext-base-24.txt, section 5.3

| 5.3  LIST EXTENSIONS
| 5.3.1  Usage
|This command is optional.
|Syntax
|   LIST EXTENSIONS
|Responses
|   202   Extension list follows (multiline)
|   402   Server has no extensions

but as mentioned above the command might be replaced with the new
CAPABILITIES command which might have a different returncode (looks
like it will be 101 for success as stated in
draft-ietf-nntpext-authinfo-06.txt and
draft-ietf-nntpext-streaming-03.txt).

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#240916: Keymap complains about collisions when any .tin/keymap file exists

[Urs Janßen]

On Tue, Mar 30, 2004 at 08:44:38AM -0800, Ken Bloom wrote:
  the mentioned keys are redefined in different contexts, this does n
  ot lead to a warning unless one of the keys is defined as
  'global'-key (e.g. QuitTin (global) and ConfigNoSave (limited local
  scope)). the local scope key overrides the global one so this doesn't
  cause any trouble. if you start to assign i.e. 'Q' to two global
  actions this will cause trouble, that's why we issue the warnings
  here. the keymap stuff needs a majpr rewrite, but that is on the
  TODO-list for years 
 
 If these are slated for a rewrite, then perhaps the warning can be
 supressed, or at least the annoying Press RETURN to continue can
 be supressed.

JFYI:
the latest snapshot of the unstable branch (released earlier today)
includes the mentioned rewrite of the keymap stuff. currently the
code does not warn anymore about key-redefinitions (which might
change again if we find a propper solution to warn about
redefinitions in the same scope but exclude those with a different
scope). btw. the new code isn't very well tested.

urs
-- 
Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;) - Linus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]