Re: [Pan-users] Pan/0.139 - threading issue [solved - maybe]

[Dave]

----------------------------
On Monday 30 September 2013 11:57:35 Duncan wrote:
> Duncan posted on Sun, 29 Sep 2013 11:39:04 +0000 as excerpted:
> > OK, bug finally filed.
> > 
> > gmime 2.6.16-2.6.18 split references headers in the wrong place, 2.6.15
> > works fine
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=709031
> 
> OK, the bug is (or should be) fixed post in current git, post 2.6.18, so
> the fix should be in 2.6.19.  2.6.16-2.6.18 should be the final affected
> version range, 2.6.15- and 2.6.19+ should be fine.
> 
> In the fix, Jeff S. fixed gmime to treat references headers special, much
> like gmime was already doing for the message-id header, which it doesn't
> fold, but since references contains multiple message-ids, he decided to
> play it conservative and follow the RFC SHOULDs (not just the MUSTs),
> folding only between IDs, not internal to them.
> 
> That is assuming the fix works as intended and this and further posts get
> threaded correctly, since I'm running the patches now, but a quick look
> around at references headers (including that kmail one) that were broken
> with the bad version, says it's working. =:^)
> 
> If you want to apply the patches, there are two (watch the wrap, I'm not
> going to bother turning off pan's wrapping for this and I guess you
> probably know what it does to long URLs):
> 
> https://git.gnome.org/browse/gmime/commit/?
> id=a248cc044c6ad55505939363aa858c930867a014
> 
> ... and ...
> 
> https://git.gnome.org/browse/gmime/commit/?
> id=1373f11f9b3ecdbfb58a70a742506f3f6d5c57d8
> 
> You can download the patches directly from there using the "(patch)" link
> on each one.  Apply a248cc04 first as I think 1373f11f depends on it (tho
> I didn't actually check, I just set them up to apply that way here).  And
> you'll need to edit the first one (a248cc04) to remove the changelog diff
> from the patch, as there were further additions to the changelog between
> 2.6.18 and the patch.
> 
> Other than that edit, the patches apply cleanly to 2.6.18, which builds
> fine with them, and based on my quick look about after restarting pan,
> the problem does seem to have been fixed. =:^)

I finally got the time to apply the patches.  It's broke, but in a new, 
possibly related, way :-(

Still testing in free.virginmendia.test.
MID:  Message-ID: <address@hidden>

2nd reply, 3rd in thread order shows references like this
References: <address@hidden> <pan.2013.10.08.14.23.
        address@hidden>

(In case that gets split in your  message body pane, the split is between 23. 
and 40@ of the second reference.

knode sees and threads the whole thread correctly.

Pan sometimes see the replies, sometimes starts it off in a new thread, 
sometimes a new thread with no message or headers, ie it's in the header pane 
but even with header view on, nothing appears in the body pane and clicking 
reply-to does nothing on those posts.  Sometimes, after leaving that group and 
going back in, the blank message disappears forever.  Those messages appear 
just fine in knode.

Interestingly, knode doesn't seem to split the header line at all.  It just 
keeps getting longer.

Maybe I need to build gmime differently.  I used the FreeBSD ports system in 
the following way:

cd /usr/ports/maill/gmime26
make clean
make fetch extract

...then cd into the work/gmime-2.6.18...

patch < /usr/ports/mail/gmime26/patch1.dif
patch < /usr/ports/mail/gmime26/patch2.dif

...manually checked that patches are applied...

make && make deinstall && make reinstall

I've even shutdown/rebooted to make sure it's not the unpatched gmime still in 
memory.

I've also switched back to default MIDs instead of custom/pan instantiated 
MIDs.  The problems seem to only appear when reading with Pan now.  The 
threading looks ok, even with split References: headers.

I'm not doing anything special.  Just a simple post and then replying to it 
and then to to each reply in turn.  The 3rd post, 2nd reply, most of the time, 
will thread as a reply to the original, not the one it's a reply too and the 
References are missing.

I'm going back to gmime24 for now and will have a go at compiling current 
gmime the "linux way" and copy the files (if required) into the places FreeBSD 
expects them.