Re: [Pan-users] Re: Bug squashed

[K. Haley]

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