[Pan-devel] Re: Bugs in Debian

[Duncan]

Darren Albers <address@hidden> posted
address@hidden, excerpted below, on  Mon, 06 Aug 2007
21:51:37 -0400:

> Mario Iseli wrote:
>> Hello pan developers,
>> 
>> I think I already wrote you once about that. Please have a look at:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pan
>> 
>> As you see there are several bugs... I'm preparing an upload with the
>> 0.132 version to Debian, can anyone please tell me which of those bugs
>> (bugnumbers) are fixed in your new version. I have adopted this package
>> and it would take a lot of time to go through all of them and check if
>> they are fixed, I think you are much faster in that as you wrote all
>> that code. :)

>> (Please CC me, I'm not subscribed to pan-devel)
>> 
>> 
> *Reposting because I forgot Pan's behavior when sending posts offlist
> via email*

I think/hope gmane forwards these, since it scrambles the email address 
on this and certain other lists/groups depending on whether they were 
setup to do so.  (I participate in this list thru gmane.org's list2news 
gateway, as do a number of users.)  I've added the scrambled address to 
the mailto, so maybe we'll see.

> If you are maintaining the package you should probably subscribe to the
> list  ;-)

Seconded.  This and maybe user, tho pan devel is lower traffic.

> I am not a developer but here is my stab at it:

You may not be a developer, but you /are/ the one who has been 
contributing the Ubuntu packages, so I was going to suggest you and he 
compare notes, and hoping you'd reply.  (I saw this just as I headed for 
work and didn't have time to reply then.)

(I'm not a pan dev either, but /am/ I believe the senior list/group 
regular, and have made some observations about how Charles works over the 
years that may be helpful here.)

> 391321: I thought the scorefile moved over intact?  Duncan/Charles, can
> you confirm this?

Well, sort of.  The scorefile is the same basic (slrn scorefile based) 
format, but pre-0.90-rewrite, it had used some of the xnews adaptations.  
Charles says that was problematic to implement in a bug-free way, so he 
went stricter slrn format with the rewrite.

The big change (the only one AFAIK) is that while xnews used regex 
matches everywhere, slrn uses regex matches in most places, but used * 
wildcard matches for the newsgroups entries, which serve as section 
headings.

So while previously one could match all groups with a regex entry like so:

[.*]

slrn's wildcard format matches that as a group beginning with a literal 
dot, followed by anything (or nothing).  I don't believe such groups are 
even legal, so naturally, it doesn't work.  The slrn format for the same 
would be:

[*]


So that can be closed WONTFIX.  You /can/ redirect users to the slrn 
scorefile documentation, here:

http://www.slrn.org/docs/score.txt

Do note that there's a couple other minor differences.  (1) pan ONLY 
scores on headers in the overview, period.  There's NO way currently to 
get it to score on other headers, or on the message body content.  That's 
highly frustrating here too, as I've had a request in to allow post 
download scoring/filtering based on non-overview headers and body since 
before pan even had scores, when it was still binary filters.  However, 
as they say, he who codes, decides, and I'm not skilled enough to provide 
a patch, so... .  (2) pan retains one single xnews convention -- it's 
case insensitive by default.  Replace the : after the keyword with an = 
to force case sensitivity.

Finally, one more suggestion you can pass on.  When I did my switch, 
since I was using regex newsgroup/section entries, I had to redo it 
anyway.  It wasn't hard, but while I was there, I took the time to clean 
up my scorefile and reorganize it.  I went from over a hundred scores, to 
(pan says now) eight scoring rules in three sections.  Those rules are 
compound entries, naturally, but it's /vastly/ easier to work on the 
scorefile directly now, and I in fact choose to do all my scorefile 
editing directly, rather than thru pan, to ensure it stays that way.

> 396808: I think this was fixed in .115 but I can't find a bug report but
> I can't reproduce it.

Yes, this one was fixed.  Charles redid the line-wrapping code.  It works 
better now, altho there remain a couple minor tweaks that could be done.  
This one can be marked FIXED UPSTREAM or the like.  This bug had been 
there quite some time, since long before the the 0.90 rewrite, gnome bug 
#121178, fixed in pan 0.124.

> 426149: No Upstream bug report and I can't reproduce since I don't run
> Mutt

Somebody did report it on pan-users, but not being a mutt user, I 
remember little beyond that.  I've not seen a pan-upstream bug on it, but 
that doesn't mean there isn't one.

> 434299: I think was fixed in 441442 (fix uulib bug that caused crashes
> and yEnc decoding)
> 
> 434828: I think this was fixed in 441442 and I am able to open it with
> 0.131

Nothing to add to Darren's reply for these two.

> 383330: I think this was fixed a long time ago, maybe in 0.115 under bug
> 357698?

As indicated on the bug and above, I believe this has been fixed for some 
time, likely with the 0.115 wrapping changes.

> 392696: 0.14.2.91 is no longer supported upstream and this bug wouldn't
> apply to the newer releases since they are a complete rewrite

Agreed.  It is a bit of a strange situation, since the official "stable" 
version is two years old now and officially unsupported, while the 
current version remains beta, but in reality, the current version is 
quite stable, and in fact, scales MANY TIMES better than the old version 
did, so pick a version and call it stable, if you wish.

> 405522: No upstream bug report and I don't think this is a valid bug...

Agreed.  As the author can't reproduce it either, it would seem to be 
closeable NEEDINFO, INVALID, NOTABUG, or whatever.

> 277411: 0.14.2.91 is no longer supported upstream however I think this
> is possible to do directly in the scorefile, this would be a question
> for Duncan.

Agreed on the 0.14.x unsupported, but the same wish would apply to 
current.  Unfortunately, I do NOT believe it's possible, because I don't 
believe reply-to is in the overview headers, which is all pan scores on.  
Again, frustrating, but those that code, decide, so... .

> 328306: 0.14.2.91 is no longer supported upstream and no bug report
> found upstream for the pre-1.0 releases.
> 
> 328307: 0.14.2.91 is no longer supported upstream and no bug report
> found upstream for the pre-1.0 releases.

Agreed on these two.  However, it should be noted that at least for /
sending/ (not what this bug is on directly, but related), it's possible 
to hook into the external editor functionality, making the "external 
editor" a script that does the gpg signing.

For this and the missing score/filter type functionality, using a large 
cache (must be set in the config file directly), it would of course be 
possible to do the downloads, then shut down pan and run a script to 
check whatever and insert headers or content (a gpg verified note, for 
instance), or delete the post as an effective killfile substitute.  I've 
contemplated creating an HTML deleting script, for instance, since I 
consider HTML based mail or news a security issue.  However, this sort of 
solution will definitely require scripting literacy and the necessary 
time, so isn't for everyone.

> 390710:  No Upstream bug that I can find and not fixed.

No additional comments.

> 391324: Upstream as bug 442145

An irritation for me, too.  (Thanks, Darren, for providing the convenient 
bug number for me to CC to. =8^)  So UPSTREAM, not yet resolved.

> 391649: No upstream bug report that I can find but has been mentioned on
> the mailing list a couple of times and I think this is by design.

Confirmed.  new-pan doesn't handle mail directly, choosing instead to 
hand it off to the configured GNOME/KDE/OSX/MSW/Custom mailer.  So, 
NOTABUG on this one.  (The user may need to configure a profile, but it 
won't be used if only the mailto line is filled in, not the newsgroups 
line.)

> 429484:  No upstream bug report that I can find (Though I may open one
> ;)

Comment on this one.  Pan's configuration directory can be set with the 
PAN_HOME environmental variable.  Using a various starter scripts to set 
this appropriately allows one to run multiple separate pan instances, as 
desired.  I've suggested this on the user's list relatively frequently, 
as a workaround to the single flat subscribed list issue, since it can 
get quite long and there may be groups you wish to subscribe to that you 
don't want your kids happening across, for instance.  Here, I have 
separate binary, text, and test pan instances, each with its own config, 
but one can arbitrarily arrange as many separate instances as desired, 
organized however they wish.

So, yes, opening up a second instance on the same config can be 
frustrating, definitely.  However, a fix for that shouldn't be allowed to 
break the existing ability to deliberately run multiple concurrent 
separately configured instances, thru the use of the PAN_HOME 
environmental variable.

> 434255: I think you can answer yes to this one...  lol

=8^)

> 130623: WTH?!  0.7.6-1?!  lol

Probably WORKSFORME.  Pan-upstream has been shipping an icon in the 
tarball for quite some time.  I assume Debian has been integrating it or 
its own solution for nearly as long.

> 392695: This works for me and I it looks like the reporter fixed it on
> their side.

No additional comment.

> 389906: Upstream is 349240, waiting on the new gnome print dialogs

Confirmed, with the note that it's the GTK print dialogs, not GNOME.  I 
believe they've been in current GTK for a release or two now, but this 
isn't likely to make it into pan until post 1.0 stable (1.0 has been 
planned as the next official stable).

The suggested workaround is to save the message as text, open it in your 
favorite text editor, and print from there.  There's no reason that 
shouldn't work, unless like me you simply don't have a printer. =8^)

> 238324:  0.14.2.91 is no longer supported upstream however the bug still
> shows open upstream.

The filer wishes to create multiple instances of the same header.  
There's documentation on the (forwarded) bug as to how to do so, but 
Charles doesn't seem that enthusiastic.  I'd say Debian can close it as 
UPSTREAM.  I'd recommend Charles set it target "bluesky", if he's not 
particularly interested in it as it seems.

> 245957:  0.14.2.91 is no longer supported upstream however the feature
> has not been implemented in the new version either.

Seems Charles is interested in implementing this as a sig toggle option.  
It may be post 1.0, or not, if he gets a wild hair. =8^)  For Debian, 
UPSTREAM (which does seem to be what "Forwarded" functions as, anyway.

> 284735:  Version is no longer supported upstream however the bug is
> already refiled for the pre-1.0 beta's

Gnome-session awareness.  As I've written on the forwarded bug KDE can 
handle it just fine as is.  I've been very glad that Charles hasn't been 
keen on adding GNOME dependencies, only GTK, which in turn makes porting 
to other platforms (the MSW port, for instance) much easier.  I seriously 
doubt this is going to get anywhere, even if a working patch is provided, 
if it requires GNOME dependencies.  The only way to do it therefore is 
with GTK only.  As I said, I've no idea why GNOME can't handle it as is.  
KDE can and does, and KDE's not even built on GTK, as is GNOME.

For Debian, UPSTREAM.

> 103000:  Version is no longer supported upstream however the bug can be
> refiled against the new 1.0 Release.

Socks proxy request.  UPSTREAM, no additional comments.

> 145796: Version is no longer supported upstream however the pre-1.0
> beta's have a redo button in the task manager
> 
> 242947: The new 1.0 beta's have this menu

No additional comments on these.

> 249898: Version is no longer supported upstream however the bug can be
> refiled against the new 1.0 release

Scorefile expiration X days after last use instead of X days after 
creation.  This is almost certain to get a WONTFIX upstream.  The reason 
is that as explained above, pan's scorefile format is borrowed from slrn 
and is in general slrn compatible.  Unless slrn implements something like 
this, therefore, it's unlikely pan will do so.

> 385890: Still Open upstream

Per group retention of sort order.  This could be useful and there's been 
a patch available for awhile. Anyway, UPSTREAM for Debian.

> 388566: Still Open upstream

Save text, filenames as subject (vs. msgid).  Could be useful but as 
noted, there are possible complications.  As such, I doubt it'll go 
anywhere unless there develops a much bigger user demand for it than 
we've seen so far.  UPSTREAM for Debian.

> 391325: Closed upstream as invalid since the option is already there.

Multiple ordered sort.  The above says it all.

> 391327: Still Open upstream

"Dialog-less" saves.  Popular request.  This should make it back in 
eventually as a result.

In the mean time, the suggested workaround is to multi-select large sets 
of posts to save at once, so one deals with the dialog there's no way 
around less often.  If one deletes or marks read everything one does /
not/ want to download, then (filtering on unread-only if desired) one can 
do a single select-all-messages, save, and only deal with the save dialog 
once per group per session.

Hope the additional commentary was useful, to the OP or someone else.

-- 
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