Re: [Pan-devel] AW is rejecting some postings when the "Newsgroups:" line becomes word-wrapped also. (Re: Bug with long header lines)

[Duncan]

SciFi posted on Thu, 02 Jan 2014 02:20:52 +0000 as excerpted:

>>> What version of gmime are you running?
> 
>> $ pkg-config --modversion gmime-2.6 2.6.10
> 
> I remember seeing those discussions on -user (plus I'm responding to a
> related thread here at -devel).
> When I saw I should have 2.6.10 here,
> I decided I was not inside that buggy range so I should be okay.

2.6.10 -- you should be good for the bug I worked with, as it was due to 
the new parser only introduced in 2.6.16.  Before that the old parser was 
used, but of course there may have been other bugs fixed since then.

> But as I remember, the Newsgroups: line looked like this:
>> Newsgroups:<whitespace?notsure?>\n <indent>group1,group2,group3\n
> and possibly other header-lines wrapping similarly,
> which caused AW to reject the post with 441/RFC1036 feedback. That's why
> I explained there needs to be _some_ text on that 'first line' e.g. with
> the keyword+colon on it,
> that's how I take RFC-1036 anyway.

I haven't looked at those specifics, but I believe you're correct.

> I just built/installed the latest gmime-2.6.19 which should be in the
> 'working' range, right?

Correct, for the references header bug.  However, the fix for that simply 
special-cased the references header.  Since you're dealing with the 
newsgroups header, that fix wouldn't help.

> I've rebuilt Pan "just in case", too.
> Now when I start Pan, I get this:
>> dyld: lazy symbol binding failed: Symbol not found: _g_mutex_init
>>  Referenced from: /usr/local/lib/libgmime-2.6.0.dylib
>>  Expected in: flat namespace

Wait, wait, wait!...

2.6._0_ ???

I'm not sure how OSX library versioning conventions work, but I know on 
Linux...

The library "slot" as it were, will be 2.6, with the micro-version within 
that slot 2.6.10, 2.6.19, whatever.

Normally on Linux, the micro-version library is the actual binary, with 
the "slot" version library actually being a symlink to the micro-version 
library.  Often there are two symlinks for various slot levels.

Now it looks like gmime has a slight variation on that theme, but here's 
what 2.6.19 installs here (listing library binary and symlinks only):

/usr/lib64/libgmime-2.6.so ->           (symlink to binary)
/usr/lib64/libgmime-2.6.so.0 ->         (symlink to binary)
/usr/lib64/libgmime-2.6.so.0.619.0      (actual binary)

For comparison, I dug up my 2.6.13 binpkg and checked what it had:

/usr/lib64/libgmime-2.6.so ->           (symlink to binary)
/usr/lib64/libgmime-2.6.so.0            (symlink to binary)
/usr/lib64/libgmime-2.6.so.0.600.13     (actual binary)

And the other binpkg I happen to have, 2.6.18 with the patch:

/usr/lib64/libgmime-2.6.so ->           (symlink)
/usr/lib64/libgmime-2.6.so.0 ->         (symlink)
/usr/lib64/libgmime-2.6.so.0.618.0      (actual binary)

(FWIW 2.6.13 is probably gentoo stable so kept in-tree and thus in my 
archive when I cleaned up.  The missing versions between it and 2.6.18 
were never stabilized, and were removed from the tree when a new version 
was introduced, so were cleaned from my binpkg archive when I ran the 
cleanup script.  2.6.18 would probably be cleaned up now too, only I 
haven't cleaned out old versions since I upgraded to 2.6.19.)

Now your error above reports a libgmime-2.6.0.dynlib, so obviously the 
versioning scheme is slightly different.

But, double-check that it's either a symlink pointed at the correct 
binary (presumably), or the correct binary itself.

Make sure it is *NOT* a stale bit left over from a previous libgmime 
2.6.0 install, from however many months/years ago!

Because that could really REALLY screw things up (I've had it happen 
before), and could certainly explain various bugs such as this.

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