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

[SciFi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




Hi,

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

What's more, I have not touched the
requisites (much) since mid-2012
(other than what the XQuartz/X11 itself installs).

So I've been thinking that Pan master/head itself might have logic
that now doesn't work with such older gmime
(I'd have to say Pan seems to be the only real change here).
I don't know now -- ergo I'm asking for help here.  ;)

I can't find a failed AW post in my Sent folder
(I cleaned things up recently).
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 am still trying _not_ to rebuild "everything",
 for reasons I've explained [much] earlier,
 yet even more-so now.)


I just built/installed the latest gmime-2.6.19
which should be in the 'working' range, right?
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
> 
> dyld: Symbol not found: _g_mutex_init
>   Referenced from: /usr/local/lib/libgmime-2.6.0.dylib
>   Expected in: flat namespace
> 
> Trace/BPT trap
> [RC=133]
> 
> $ _
… and I saw similar errors running "make check" on 2.6.19.

It's frustrating when ya see old bugs like this
crop-up when it's supposedly the latest code.
|>:*(((
I don't think I quite want to fool with this at
the gmime mail-list for now.

So I went back to 2.6.10
since it _used_ to work here.

(I saw your gentoo post, too --
 as I read it,
 maybe 2.6.15 might work,
 yet I'm thinking 2.6.10 _was_ ok
 but now it isn't,
 -or- we have a new bug entirely)


I investigated what MacPorts does with gmime
and it seems to build 2.6.19 fairly plainly
(no special compiler/linker flags AFAICS,
 just as I did).
Perhaps no-one has really used it there
to discover whether the dyld errors are
occurring elsewhere.

Then I looked at what Fink does,
and it only provides gmime-2.2.24 and -2.4.26
and nothing in the -2.6.x range at all.
I would probably lose functionality here
if I went that far back with gmime --
I really want as much GPG etc as possible
(hoping HM will finish it <g>).
[You can see GPG works with my 'signed' text here
 done with TextWrangler and MacGPG
 then c&p'd into Pan's editor.]

So, I guess I'm back to square-one here
if I can't use =< gmime-2.6.15.


Thanks for taking time.



-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJSxMxzAAoJEKkeWNKet7+KSAoIAKVMoDFV3dA5pFsTlwQoINIj
PWsoVfzj4Y+xGu/UfcgzWHtXNvGn1uXBCBT71WkEGkejWDiISSm4HMei3hr6/OcY
rjPt1RNYG3Zbzn2IcuV0zRtt9H8nZv4ls08fUHhqF5ilHaNBcCiAo9Zuc26AwHB/
6kOnMoHD3mtuLn7H5W2YLqpClZhgmzwWoZVCeCNe+3HjXdJ7X/iKdz7XPESIhg2+
7qtn8NnBgshLH1cl9oUqKqcV31a19JrJ2MTnU0f2Qma5sgjp6k1PUOn8Of7Xl4qO
k5CyfgiqHxjujSsr5TxTW0bRGM8Mbfmp2RdK98DlIKtNYn/1pSMrg/lghjXdGyc=
=7Hnb
-----END PGP SIGNATURE-----