On 1/14/2010 11:05 PM, SciFi wrote: > Hi, > > Yes you described my problem very closely (I suppose you can blame me for > instigating this ;) ). > > We have applied that simple one-line patch here, > (others are listed as bug-report numbers in my User-Agent header line), > compiled & installed it, > and tried fetching one of those posts again. > > This time the poster made sure 'yenc' is mentioned on his Subject lines, too. > Well, that doesn't really matter. Pan only uses the subject line to get part counts not the encoding type. After all subject lines can and do lie sometimes. > On pan's stdout|stderr path, we see numerous lines like this: > > (pan:80747): Pango-WARNING **: Invalid UTF-8 string passed to > pango_layout_set_text()" > > The pan gui event log shows many lines with junk like this: > > Thu Jan 14 23:20:52 2010 - Article "BrainSurge-2010-01-04-0.tp Yenc > (/3213)" is incomplete -- the news server(s) don't have part > <VFt2n.137596$LB1.124207(at)news.usenetserver.com4773> > > The closest filename inside our article-cache looks like this: > <VFt2n.137596$LB1.124207(at)news.usenetserver.com.msg> > so something is still tacking-on extra bytes after the end-string dot-com > there, by the time pan tries to do the uudeview phase at least. > Now this is strange. The msg in your cache should be the correct part, could you check that & see if its complete? If that is the correct part then why is pan trying to retrieve it a second time with a messed up id? For that matter I can't figure out how it got messed up like that in the first place. When pan packs the ids for a multipart it stores the first id a a reference & all others as a beginning length, and end length, and a unique middle. When the id for a part is requested it copies the beginning & ending from the reference id. In this case the end should be (at)news.usenetserver.com> so how could 4773 be inserted? > FWIW > Our pango & cairo etc came from the Xquartz-2.4.0 project, built just a few > months ago (i.e. recent versions) for the multi-arch (4 types of) CPUs being > supported by Apple itself (ppc, ppc64, i386, x86_64). We are likely using > the i386 flavour. > Much more detailed info here (lists libs & versions included): > <http://xquartz.macosforge.org/trac/wiki/X112.4.0> > It'll put me into a bind if we need to upgrade any X11 pieces > (for ex I believe we are still at gmime-2.2.23). > Just FYI, gmime 2.2 & 2.4 can be installed at the same time. The only possible clash are some demo programs that don't matter. Also the relatively recent work by Charles upped pans requirements to gtk 2.16 & glib 2.18. Of course none of these are actually part of X11.
I used an nzb for the article you mentioned and tried to replicate the messed up ids with both my master branch and integration branch but couldn't. Since you seem to have tried getting the file from a newsgroup instead of an nzb there are two places were the problem could show up, the group file and tasks.nzb. Lets see if the group file is ok, grep the group file for VFt2n to check for a bad id. If that is ok then you should grep tasks for the same thing. Put pan offline, add the article for saving, wait a few seconds for pan to update tasks, then grep. After that you can delete it from the task window and put pan back online. Hopefully this should narrow down were the problem is occurring.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
