So pan has had a longstanding bug or "undocumented feature" related to fetching headers in the context of crossposted messages. I've not reported the bug as I've never felt I had a good enough grasp on the problem to report it properly, but now it's frustrating me enough to try anyway. Maybe others can help in describing the behavior well enough to finally get a good enough grasp on it to get it fixed.
The problem seems to appear on gmane in particular, and thus triggered by messages cross-posted to multiple mailing lists, with gmane's list2news behavior a possible/likely contributing factor. Where I've seen the problem, it's in relation to one group (mailing-list via gmane) that I'm already tracking and often subscribed to, where I want to download new headers for a related (and thus sometimes cross-posted to) group/list. The problem seems to be with pan's handling of the xref (I think) headers, where messages are marked read (already seen by pan) on the one group, such that -- here's the bug -- pan thinks all messages on the other group are all seen already, and thus will refuse to download headers, even with many messages on the group/list beyond the ones that were cross-posted. Unfortunately, once the bug triggers, pan seems to *never* see anything on the new-to-be-followed group, even *years* after the cross-posted messages that triggered the problem originally. The behavior is very similar to that of a server post-renumbering, where the new numbers are lower than the old numbers so below pan's high-water- mark for the group. The only thing I can figure out that could plausibly trigger this behavior is if the originally-tracked group is busier and thus has higher xref (I think that's the header) numbers, and pan is somehow treating the high- water numbers in the busier group as applying to the less-busy/lower- number group as well. If that's the case, pan would always see the higher high-water-mark of the busier group and thus always think there were no new headers to download in the less busy group, because it's using the higher high-water-marks for the busier group instead of the lower ones for the group I'm attempting to view. Where I'm seeing it: Long-term (a couple groups/lists for my distro: gmane.linux.gentoo.devel (busier and older group so likely much higher xref numbers, first tracked) gmane.linux.gentoo.project (newer group that pan refuses to fetch headers for) Current problem (I'm seeing a Linux bug and trying to see if it's already reported on the related Linux kernel lists): gmane.linux.kernel.mm (first group, likely older and probably busier so higher xref numbers) gmane.linux.cryptography (group that pan refuses to fetch headers for, finally triggering this report as the kernel bug appears for me with zswap as tracked on the mm group/list, but I've now isolated it to the crypto subsystems zswap depends on for compression, and tracked on the cryptography group/list -- only pan won't fetch the headers for that list!) Thoughts? Anyone else seen this to confirm? Better bug description or other ideas on what might be triggering the problem? -- 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 _______________________________________________ Pan-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
