[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-devel] Re: Bugs in Debian
From: |
Duncan |
Subject: |
[Pan-devel] Re: Bugs in Debian |
Date: |
Tue, 7 Aug 2007 09:55:42 +0000 (UTC) |
User-agent: |
Pan/0.132 (Waxed in Black) |
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