[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] Re: very peculiar bug with EasySW news-server (home of CUPS)
From: |
SciFi |
Subject: |
[Pan-users] Re: very peculiar bug with EasySW news-server (home of CUPS) |
Date: |
Wed, 28 Mar 2007 20:36:48 +0000 (UTC) |
User-agent: |
Pan/0.126 (DemonSweat-SVNr211; powerpc-apple-darwin8.9.0) |
On Wed, 28 Mar 2007 16:25:03 +0000, walt wrote:
> On Wed, 28 Mar 2007 09:57:32 +0000, SciFi wrote:
>
>> Hi,
>>
>> Been noticing a peculiar thing with EasySW's news-servers (home of
>> CUPS).
>>
>> Add 'news.easysw.com' to your Pan server list, get the list of groups,
>> then subscribe to 'cups.commit'.
>>
>> Getting all headers shouldn't be too much at all.
>>
>> Go ahead to mark all headers read.
>>
>> Now, try getting new headers for that group, and you'll always be
>> presented with a number (448) even if no new posts have been made.
>>
>> Go ahead to mark all headers read again, rinse & repeat -- you'll
>> always see (448) new messages there...
>
> No, I don't see the number 448 anywhere, but I do see a bunch of article
> headers that apparently don't have bodies -- every article prior to
> March 2005, in fact. When I mark the group as read and then return to
> the group later on, all those headers are now gone -- until I fetch
> 'all' headers for that group again.
>
> Charles has made a remarkable number of commits to svn in the last two
> days -- maybe he's taking new viamins -- so the 448 thingy may have just
> been fixed in the latest 'Demon Sweat'. You might give it a try.
heh... did you peek at the headers in my posts here?
clue: User-Agent. ;)
I'm running svn r211 already.
hmm... I've set all of the servers to "never expire" anything
here... that might be a clue, at least I can set EasySW's server
to do that.
(I'm trying to get around to submit the patch to allow Pan to show
the version etc. in the User-Agent header, but since I am using
GNU's latest auto* tools, the autogen.sh won't create a working
build system with Pan's present state of affairs, so I resort to
manually updating the *.in files when the *.am's are modified.
I'll need to open another bugreport on this... it's beyond my
know-how to fix...)
Thanks for chatting... I'll continue to investigate. :)