[Pan-users] Re: Old Pan v0.14.2.91 keeps adding removed newsgroups into my .newsrc.

[Duncan]

Phillip Pi <address@hidden> posted
address@hidden, excerpted below, on  Mon, 20 Apr
2009 06:33:15 -0700:

> On Mon, Apr 20, 2009 at 11:52:53AM +0000, Duncan wrote:
>> > Oh wow. Pan has ~/.newsrc support now? I remember v0.106 didn't have
>> > it from my old post in 2006:
>> > http://lists.gnu.org/archive/html/pan-users/2006-08/msg00042.html ...
>> 
>> As Charles says in a reply there, it uses newsrc format natively now.
>> However, it doesn't use the specific name ~/.newsrc by default in part
>> because pan is now (with the rewrite, so from 0.90) fully multi-server
>> integrated, and newsrc is single-server only.
> 
> Can it still use one .newsrc (share with Tin) and one news server?

Yes, of course.  However, pan will first name it server-1.newsrc (or some 
such), and you'll need to then close pan and edit the servers.xml file to 
point it at the location you want.  If that location has your 
permanent .newsrc file, pan should pick it up on reopen.  Otherwise, move 
the one pan created to the new location.

> The reason why I like Tin
> is because I use it via SSH, mark busy binary newsgroups quickly and
> exit so I don't have to download old headers later. For example, I visit
> my busy binary newsgroups at 5 PM, mark all newsgroups to update their
> header values, save, and exit. After 9 PM, I go to Pan and download the
> newsgroup headers, find my stuff I want and download. At least I save
> and don't waste bandwidth on stuff I don't care. Yes, I know when things
> get released.

That makes sense.
 
>> Pan is much more stable now too.  I believe you'll find 0.133 much more
>> so than 0.10x was, for sure.  Looking at that old thread, the one thing
>> that pops out to me now about it is that possibly pan got mixed up with
>> that symlink in place before it was fully initialized.  But I doubt
>> you'll find the problem still there and if you do see it, I think we
>> can get it fixed this time.
> 
> I noticed lack of updates lately. Is this going to be a problem of
> getting updates/fixes if I run into any?

It could be.  0.132 was released on Aug 1, 2007.  One year later to the 
day, Aug 1, 2008, Charles released 0.133, but it was mostly a maintenance 
update, with one security fix and various distribution and user submitted 
patches so it would compile with newer gcc/glib etc, mainly.

But other than that maintenance release, Charles has been taking a break 
for nearing two years now.  He is known to do that sometimes and did 
really deserve a break as he had been pushing very hard on the rewrite 
for well over a year, with a new beta release every week or two.  
However, it would be nice if other developers joined the pan team and 
continued more steady if slower development while Charles takes his 
breaks.

Before that, the longest break was I believe over three years (with a 
single maintenance release in there somewhere), during which everybody 
pretty much came to believe pan was pretty much abandoned, but it turned 
out later that Charles was secretly working on the rewrite that became 
0.90 when he eventually made it public.

But before that, since late 2001 when I first became a pan user (back on 
pan 0.11, requiring gnome 1), Charles has always gone thru fits and 
spurts of pan development, working on it pretty hard for some months, 
then nothing public at all for months.  But that 3+ years before the 
release of the rewrite was definitely the longest dry spell, and at 
nearing two years now, this one's the second longest, I think.

>> The workaround for that, which I use here, is to setup multiple
>> entirely separate pan "instances", using the previously mentioned
>> PAN_HOME variable.  Here, I have text, test (which gets all my just go
>> to a group and look around stuff), and bin.  I've setup little pan
>> starter scripts for each one that does a bit of pre-start setup
>> including setting PAN_HOME as appropriate, to ~/pan/xxx, where xxx is
>> either text, test or bin.  Not only does this allow me to keep separate
>> group lists, but all settings are separate (save for the few files I
>> symlink to a common version, this includes my scorefile and
>> accels.txt).  Thus, I can have separate cache sizes and locations,
>> separate expiry settings, etc.  The last bit of config to go with this
>> is that I have separate kmenu entries for each instance as well,
>> instead of the normal single entry.  Of course I have hotkeys setup for
>> all my commonly used menu entries including pan, so I can start it with
>> the touch of a couple buttons.
> 
> Interesting, but you say this for multiple servers which I don't have
> and will not have.

Well, sort of.  Pan is now pretty much multi-server transparent, once 
each server is configured of course.  However, using PAN_HOME is 
independent of that.  It's simply where pan looks to find its config and 
data, falling back to ~/.pan2 if PAN_HOME isn't set.  (I honestly don't 
know what it does if it's set but invalid, say a sentence fragment rather 
than a filesystem path.  I expect it would simply error and break if it 
was a filesystem path that pan couldn't read from or write to.)

So one server or more, doesn't matter.  If you wished to setup pan to use 
a non-default location, and possibly use that to enable you to run 
multiple independent pan instances, each pointed at its own config, the 
way I have my setup running, no problem.

>> The second missing feature, this one not yet implemented, is something
>> parallel to old-pan's rules.  There were only a few ways the rules
>> could be used back then.
> 
> Are those filter rules? I rarely use them.

Yes.  If you rarely use them, you won't miss them. =:^)

> Ah, I usually set my cache to 1 GB and empty out old ones. Also, every
> time I finish Pan, I do a catch up/mark all (shift+ctrl+m -- I hope this
> is way faster in newer Pan for those huge binary newsgroups!) and empty
> caches (shift+ctrl+del)) and exit manually.

It should be faster, yes.  Everyone agrees it's MUCH faster than old-pan 
was (unless you're running that GNOME assistive technologies stuff and 
therefore get hit with that bug, that is).

> OK, I will check it out when I have more free time (not now!). I will do
> a backup of my ~/.pan/ before I try it.

You shouldn't need to backup ~/.pan unless you specifically point new-pan 
at that dir using PAN_HOME as covered above.  new-pan defaults to 
~/.pan2, and in fact, if your package manager or whatever allows it, it's 
entirely possible to have both old-pan and new-pan installed together, 
using their default locations, without having one interfere with the 
other.

In fact, while I don't have old-pan officially installed using my package 
manager, I saved the binary before I uninstalled the package, and still 
have it around to reference if someone comes to the list/group with a 
question about it.  That's getting far less frequent, however, and one of 
these days I'll probably delete both it and my now years old data for 
it.  (While I do occasionally load old-pan to answer someone's question 
and have some data left over from when I did use it normally in case 
that's necessary to answer the question, I haven't actually connected to 
the server with it in years, so the data is static and stale, and only 
there for reference lookup purposes.  Thus, when I deleted the old 
binary, I'd just delete the entire ~/.pan data dir too, and be done with 
it.)

> Thanks. I use KDE v3.5.10 in pure Debian. The same OS that I tried newer
> Pan back in 2006. ;)

Still KDE 3.5.10 here, too.  4.2.x is getting better, and once I update 
my graphics card to better take advantage of its new features I might 
find it worthwhile switching to for normal use even if there are still 
missing things, but until then, I have 3.5.10 configured to my needs 
'till it fits like a comfortable glove, and until the graphics update, 
there's simply not enough actually better functionality in 4.x to make it 
worth going to all the trouble to get it configured equally to my liking, 
if it's even possible.
 
> Also, I am looking forward to using nzb in Pan too. I hope that works
> well now. I use nzbget via SSH though (no need for GUI).

It is said to work quite well, tho I don't use it personally so can't 
vouch for that myself.


BTW, something I've not mentioned yet that you may be quite happy with, 
pan can now be set to get headers from the command line (no-gui)! =:^)  
Run that from a cron job or something (or just invoke it using ssh as you 
mentioned), and you won't have to keep tin around /just/ for that any 
more. =:^)

Of course, that would make it all the MORE useful to have some method to 
set it to auto-download messages too, as old-pan could do using rules, 
tho one still had to invoke it from the GUI back then.  Oh well, I guess 
someday.

But anyway, it's certainly something I'd suggest you investigate.  As 
with most *ix programs, --help at the command prompt gets you a short 
blurb with the command-line details.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman