cant store article: bogus Xref: header in INN 2.5 ?

[Julien ÉLIE]

Hi Matija,

>> Please note that the patch is actually required only for slaves.  It
>> is not necessary to use it otherwise.  You will therefore be able to
>
> Yes... Also, when I upgrade my newsfeed master to Debian 2.5.2-2~squeeze1
> package, I will not need the patch even on xrefslave servers anymore, right?

Yes, you're right.
The Xref: header field generated by INN 2.5.2 does not contain any 
leading whitespace.


> So I can downgrade them to standard Debian packages (in order not to have to
> worry about security updates tracking etc).

Yep.


> Well, not for this problem; however newsfeed innd had few extra patches
> which I have to check if they're needed in 2.5.x -- there was something
> having to do with In-Reply-To errors and I've been adding few more headers
> to be available to perl filters...  Are in 2.5.2 all headers available in
> %hdr{} or are there only still just a dozen hardcoded ones copied like in
> 2.4.6?  I know there were talks about that, but don't remember if that get
> implemented...

Not all headers are in %hdr{}.  However, INN 2.5.2 contains far more 
than a dozen headers.
The complete list of known headers is near the beginning of:
     http://www.eyrie.org/~eagle/software/inn/docs-2.5/hook-perl.html

   Also-Control, Approved, [...]


If some headers are missing, please tell us.  We'll add them.



In-Reply-To: errors?  Is it
     http://inn.eyrie.org/trac/changeset/8442
?

   Fix a bug in nnrpd Perl filter hook: undefining an header
   or setting it to an empty value ("") generated an empty
   header line ("In-Reply-To: \r\n" for instance).
   Doing that now totally removes the header.


If you speak of this bug, it has been fixed in INN 2.5.0.  Only one 
commit in trunk (when it was CURRENT 2.5.0).



If you have other patches that would be interesting to integrate into 
trunk, feel free to send them — if of course there is no licensing issue 
with your work.


>> The committed patch is:
>>      http://inn.eyrie.org/trac/changeset/9376/trunk
>>
>> with an (innconf->xrefslave && i == HDR__XREF) condition.
>
> out of curiosity, why the extra "innconf->xrefslave" check? would always
> checking for HDR__XREF break something if we weren't xrefslave ?

It would not break anything.
The reason for the extra check is that the overview data is not 
RFC-compliant without it.

Xref:      server group:1
uses "server group:1" in overview data whereas "     server group:1" 
should be used!

Just for beauty and compliance with the NNTP protocol.


> Yes I did, thankfully it throttled itself soon enough due to "file exists"
> errors...  mc(1) with "sort by change time" cleaned it up quite painlessly,
> thankfully.

OK, that's great.  I am glad to hear that you managed to fix the mess.

-- 
Julien ÉLIE

« Le chemin le plus court d'un point à un autre est la ligne droite,
   à condition que les deux points soient bien en face l'un de
   l'autre. » (Pierre Dac)