Re: [Pan-users] Problems downloading binaries

[Orlok Nosferatu]

Orlok Nosferatu posted on Thu, 14 Apr 2011 14:36:08 +0000 as excerpted:

>> Duncan,
>>
>> First let me thank you for the time you take to help me.
>>
>> My comments are inline.
>
>Attach whatever importance you deem it's worth to the following comment.
>It's an observation and request, but not something as high priority as I
>consider say HTML, because HTML can be a security issue. So if you prefer
>your current quote style, fine. I'll deal with it.
>
>As a pan user, you should be familiar with the way it handles quotes.
>FWIW, I use pan and gmane.org's list2news service to follow and respond to
>this list. So I read and reply to your posts using pan.
>
>I appreciate the in-line quote/reply format.
>
<SNIP>
>
>>>> I have no problem downloading by nzb file. That's why my partition is
>>>> alive ;-P
>>
>>> If you can still download using pan via nzb file, pan can't be /too/
>>> screwed up, as that indicates it can both download to cache, and decode
>>> and save the attachments.
>>
>>> Wait a minute... pan's own tasks file is an nzb file, tasks.nzb in pan's
>>> data dir. If nzb's are working, pan should be fine, but maybe it's own
>>> tasks.nzb got corrupted!
>>
>>> With pan shutdown, try deleting that file.
>
>> I moved the old .pan2 directory and started anew. That would mean my
>> tasks.nzb was started from scratch too, wouldn't it? Still I have
>> problems downloading attachments after March 12th.
>
>Good point. So if it's a tasks.nzb corruption, it's getting dynamically
>recorrupted by something. That something would be a pan bug, so it's a
>pan bug, regardless!
>
>And here I thought I had the thing potentially solved! =:^(
>
>>>>> I'd strongly suspect [a] buggy library update
>
>>> FWIW, I have gmime 2.4.24 installed here. That's somewhat beyond
>>> your 2.4.14 version you list, but pan /should/ work with either,
>>> especially if compiled against it.
>>
>>> Depending on how your install works there, you may well be able to
>>> check the dates on the actual file
>
>> This is the contents of my /usr/lib directory:
>
>I deleted the extraneous perms, size, etc, leaving the following...
>
>> 2010-01-27 02:45 gmimeConf.sh
>> 2011-01-06 10:03 libakonadi-kmime.so.4 -> libakonadi-kmime.so.4.4.0
>> 2010-12-17 02:08 libakonadi-kmime.so.4.4.0
>> 2010-11-02 19:00 libcupsmime.so.1
>> 2010-01-27 02:45 libgmime-2.0.a
>> 2011-04-03 09:18 libgmime-2.0.so -> libgmime-2.0.so.2.2.22
>> 2010-08-21 09:19 libgmime-2.0.so.2 -> libgmime-2.0.so.2.2.22
>> 2010-01-27 02:45 libgmime-2.0.so.2.2.22
>> 2010-04-13 18:31 libgmime-2.4.a
>> 2011-04-09 13:33 libgmime-2.4.so -> libgmime-2.4.so.2.4.14
>> 2010-08-19 09:56 libgmime-2.4.so.2 -> libgmime-2.4.so.2.4.14
>> 2010-04-13 18:31 libgmime-2.4.so.2.4.14
>> 2011-01-06 10:03 libkmime.so.4 -> libkmime.so.4.4.0
>> 2010-12-17 02:08 libkmime.so.4.4.0
>> 2011-03-28 22:27 libsmime3.so
>> 2011-04-07 13:40 libsmime3.so.1d -> libsmime3.so
>>
>> The installations after March 12th are from
>> April 3rd (libgmime-2.0.so -> libgmime-2.0.so.2.2.22),
>> 9nd (libgmime-2.4.so -> libgmime-2.4.so.2.4.14)
>> and so on.
>
>OK, the akonadi stuff is kde, so we can ignore that. Cups is printing, so
>ignore that. The *.a files are for static linking, so ignore them too.
>And as mentioned, pan 0.134 at least, uses the newer gmime 2.4 (something
>else on your system evidently still uses the old 2.0/2.2 versions), so
>ignore 2.0/2.2. libkmime (kde??) and libsmime (secure connections, https,
>etc) are also irrelevant.
>
>That leaves:
>
>> 2011-04-09 13:33 libgmime-2.4.so -> libgmime-2.4.so.2.4.14
>> 2010-08-19 09:56 libgmime-2.4.so.2 -> libgmime-2.4.so.2.4.14
>> 2010-04-13 18:31 libgmime-2.4.so.2.4.14
>
>OK, that's a level we can actually manage to think about! =:^)
>
>The 2.4.so symlink (as opposed to 2.4.so.2) will have been installed by
>the -dev package, probably when you needed it to build pan. That was
>AFTER your problem. The other two are dated 2010, well BEFORE your
>problem, so gmime doesn't appear to be the issue.
>
>Dead-end with this particular library, but even if it's a dead-end for
>this particular problem, perhaps you'll find the experience helpful for
>the next time you have a problem.
>
>
>If you have the time and/or are desperate enough, you can take a look at
>the ldd command, which lists the libraries a binary will load when it
>runs. Here's an excerpt of what it lists for pan, here. (The $>>
>indicates the command line I used, which you'd change if pan is located
>elsewhere on your system, perhaps /usr/local/bin since you built it
>yourself. I removed the hex signatures for each lib that you'll see if
>you try this, for better posting formatting, and deleted most of the list
>(denoted by blank lines), this being just an example.)
>
>$>>ldd /usr/bin/pan
> linux-vdso.so.1 =>
> libgtkspell.so.0 => /usr/lib64/libgtkspell.so.0
> libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0
>
> libgmime-2.4.so.2 => /usr/lib64/libgmime-2.4.so.2
>
> libGL.so.1 => /usr/lib64/libGL.so.1
> libnsl.so.1 => /lib64/libnsl.so.1
> /lib64/ld-linux-x86-64.so.2
> libdl.so.2 => /lib64/libdl.so.2
> libresolv.so.2 => /lib64/libresolv.so.2
>
>Two of those I kept in the list are exceptions that need an explanation.
>
>linux-vdso.so.1 is a "virtual library" provided by the kernel. It's one
>way a userspace library can access kernel provided services. Because it
>doesn't have a real binary library file associated with it, there's no
>path information for it as there is for most libraries. But it still has
>a hex signature (which I deleted above), so you know the system
>successfully linked it in. (linux-vdso.so.1 is the amd64/x86_64 version.
>If you're running a 32-bit system, the name will be different, but the
>point is, there will be one library without a path listed but with a
>signature. This is the kernel "virtual" library and is entirely normal.)
>
>The other exception is the only one without a resolution link,
>/lib64/ld-linux-x86-64.so.2 (again, 64-bit name, 32-bit systems will have
>a slightly differently named lib with the same function). This is because
>unlike the others, the path to this library is hard-coded in the binary.
>It has to be, because this is the library that supplies the logic needed
>to load all the others! It's one of the libraries supplied by the glibc
>package, and needless to say, if it gets screwed up, your system itself is
>screwed up to the point pretty much nothing else will run!
>
>The point of the above is for the following suggestion, but as I hinted
>above, it'll take quite some time. Whether you have that time or are that
>desperate, for what might ultimately turn into a dead-end as did the gmime
>thing, is of course for you to decide.
>
<SNIP>
I perfored a ldd /usr/bin/pan. Of every line I got on screen I did a ls -la
and piped it to a file. Next I removed a bunch of characters at the start
of each line, and sorted the result (on the date). The last 15 lines of
these actions are:
2010-08-19 10:00 /usr/lib/libXinerama.so.1 -> libXinerama.so.1.0.0
2010-08-19 10:00 /usr/lib/libXrender.so.1 -> libXrender.so.1.3.0
2010-08-19 10:03 /usr/lib/libgtkspell.so.0 -> libgtkspell.so.0.0.0
2010-08-21 09:19 /usr/lib/libgmime-2.0.so.2 -> libgmime-2.0.so.2.2.22
2010-11-05 08:40 /usr/lib/libfreetype.so.6 -> libfreetype.so.6.3.22
2011-02-02 08:53 /lib64/ld-linux-x86-64.so.2 -> ld-2.11.1.so
2011-02-02 08:53 /lib/libc.so.6 -> libc-2.11.1.so
2011-02-02 08:53 /lib/libm.so.6 -> libm-2.11.1.so
2011-02-02 08:53 /lib/libnsl.so.1 -> libnsl-2.11.1.so
2011-02-02 08:53 /lib/libpthread.so.0 -> libpthread-2.11.1.so
2011-02-02 08:53 /lib/libresolv.so.2 -> libresolv-2.11.1.so
2011-02-02 08:53 /lib/librt.so.1 -> librt-2.11.1.so
2011-03-03 08:46 /usr/lib/libpango-1.0.so.0 -> libpango-1.0.so.0.2800.0
2011-03-03 08:46 /usr/lib/libpangocairo-1.0.so.0 -> 
libpangocairo-1.0.so.0.2800.0
2011-03-03 08:46 /usr/lib/libpangoft2-1.0.so.0 -> libpangoft2-1.0.so.0.2800.0

Of this result, only the last 3 lines fall in March this year, but are too 
early to
be the culprit (me thinks ...). I got a problem after the 12th ;'{

>
>> I installed using 'Synaptic Package Manager'. Hence the different
>> versions in my library (2.0 and 2.4).
>
>Yes. As I mentioned above, it's very likely something else on your system
>is still linked against the 2.0/2.2 series, thus pulling it in as well.
>The two versions are designed to coexist on the same system without
>getting in each other's way, so that shouldn't be a problem.
>
>> Might it be possible that deinstalling and reinstalling my mime
>> libraries solve my problem?
>
>It's possible, yes. But on a binary-based distribution, it's unlikely to
>solve the problem unless some part of the first install got accidentally
>deleted or something.

<SNIP>

To oblige I also manually added > to the reply ;-D

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