Re: [Pan-users] Problems downloading binaries

[Duncan]

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.  As as so often been said, it 
makes following threads a lot easier, when posts may be missing and/or one 
is following enough separate threads to make remembering which posts were 
upstream in a particular one difficult.  Great.

As you are no doubt aware, pan uses the ">" quote indicators to deduce 
nesting level and color the quotes accordingly, /normally/ making it quite 
simple to see what was a reply to what.

But your quote format defeats that algorithm.  Pan can't tell your reply 
from the quote to which you are replying, and thus can't color them 
differently.  As a result, every time I see a post like this, I begin 
reading what you are replying to, in this case, my posted material, as if 
it were your reply, and it causes momentary mix-up and a deja vu as it 
reads just like something I've seen before, because I have.  When it's a 
reply to me, it's as if I'm seeing my own thought process (because I am!), 
not just agreement, but the exact same thing (because it is!), echoed back 
at me!  While as most folks I appreciate agreement, seeing what at first 
appears to be my clone in a reply is... disconcerting, to say the least!  
I'm not used to thinking in terms of another Duncan running around, and 
now he's posting to the same group/list I am!  =:^)

Within a few seconds, probably fractions of seconds but it seems longer, 
I've recognized what happened and reoriented, but those first few seconds 
or fractions of seconds are... not particularly comfortable!

Once I've reoriented, at least you DO clearly delineate your reply from 
mine.  That's a good deal better than a lot of folks I've seen, where they 
expect the reader to immediately deduce from a paragraph break that it's a 
reply to the previous quote.  That's a good thing.  But when one's used to 
seeing quotes in a different color, as I am with pan...

So, I'm not sure how much trouble it'd be to configure your mail client to 
use the traditional ">" style quote demarcers, but it'd make for a more 
pleasant reading experience on my end if you did.  Again, if it's 
difficult or impossible to do with your client, or if you have a strong 
preference for your current style, no big deal.  I'll adapt, momentary 
disorientation or not.  But if it's an easy config change on your end and 
you don't have any strong personal attachment to your current quote style, 
it'd be nice.

Anyway, I've manually re-quoted the below as the quote-levels are
beginning to stack up and get confusing, when two of them appear
to be at the same level.

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

Given the above list provided by ldd, and with the two exceptions listed 
above, it should be possible to check every single one of those libraries 
(and there's WAY more than I listed, as you'll see if you run the ldd 
command yourself) to see what its date is, much as we did the gmime 
library above (but without the narrowing down step since the list gives 
you the exact file you need the date on).  Anything with a date from when 
pan was still working should be fine.  Anything with a date newer... might 
be a problem, but if it's AFTER pan broke, it indicates an update since 
then, which indicates the library might have been repeatedly updated.

If you're lucky, you will find a list of one or a few libs that were 
updated exactly when pan broke.  These will be most interesting, as their 
the most likely problem.  Anything with dates when pan was fine are 
definitely known to be fine as well.  Anything with dates AFTER pan was 
ALREADY known to be broken MIGHT have had multiple updates, so are of some 
interest, but any in the EXACT range of the pan break, that might have 
triggered the break, are the ones we are most interested in.

For those knowing enough about their system, many of the listed libs could 
be ignored for a first-run check at least, since their primary 
functionality is elsewhere, or because they're so basic to the system that 
it's unlikely there's a problem or something else would be broken as 
well.  libdrm.so.* and libXext.so.*, two libraries in my list here that I 
picked basically at random as examples, I'd not check the first time thru, 
as I know they're X/display related, and thus quite unlikely to be 
triggering pan save issues.  (If they were faulty, pan and probably other 
apps would be having display issues, not attachment saving issues.)  That 
would eliminate a lot of date checking the first time thru, while still 
likely finding the problem update.  But it's still remotely possible 
they're somehow indirectly related (they have some weird conflict with a 
different library that DOES directly handle attachment functionality in 
some way), so if the first round didn't produce any reasonable candidates, 
I'd go thru again, checking the less likely ones.

But those without that sort of in-depth system knowledge will have to do 
date lookups on pretty much everything listed, which will require quite 
some time and patience.  But if it's a library problem, this method is 
reasonably likely to narrow down the candidate list, however much patience 
and time it requires.  Are you that desperate and/or have that much spare 
time?  Of course, that's your question to answer, not mine.

> 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.  If there's a problem with the package as it 
shipped, simply reinstalling isn't going to fix it.  On a sources based 
distribution like Gentoo (which I run), the chances of a rebuild from 
sources (the critical part) and reinstall are much better, since the 
rebuild may correct the problem.  But with a binary-based distro, the 
rebuild is handled by the distribution, not (normally) the end user.  In 
theory, they test for problems before releasing a package so there should 
be less problems than in a from-source distro (or when building your own, 
manually), but if the problem isn't caught by those tests, simply 
reinstalling the same binary package with the same problem, won't fix it.

Now if you had built and installed those packages manually, instead of 
using synaptic, I'd say definitely try it.  But otherwise...

Building your own version can at times help, but that's a topic well out 
of scope of what I can help you with here.  The actual process isn't so 
bad on its own, but there's a lot that can go wrong with a lot more 
packages than pan if something goes wrong with your build, and once you're 
doing it yourself, the distribution really can't properly support you, 
neither can I (nor really, can anyone easily, at least not without some 
sort of trusted sysadmin relationship, and possibly $$ involved as well, 
an entirely different level from the "best-effort" support of lists/
groups), so it's a can of worms best left unopened at this point, I 
believe.

> Do you
> have a link to a manual describing the steps I need to do? (Deinstalling
> using the package manager, installing ???)

No, I don't.  I could certainly do some research and get the necessary 
information, but as explained above, that's well out of present scope.  
The best I could do would be to refer you to, probably, your local LUG, 
Linux User's Group, or possibly, the Ubuntu-specific lists, as I'm a 
Gentooer, definitely not an Ubuntu guy, and that's not likely to change 
unless someone were to pay me serious enough money to motivate a change in 
my priorities. =;^P

(For a good Gentooer, trying to work on most binary distributions, it's 
not limited to Ubuntu, is rather like being thrown in a cold lake with one 
arm and one foot tied to each other and told to swim.  It might well be 
possible, if one has motivation like trying to save one's own life, but 
it's not something a good Gentooer is likely to actually /want/ to do, by 
any means!  That Ubuntu is Gnome based and as a kde guy I feel much the 
same about Gnome's "our way is the only proper way, so by removing those 
customization options, opportunities to let you do it WRONG, we're 
actually protecting you from yourself" policy, definitely compounds what's 
already a bad situation with pretty much any binary distribution, to a 
good Gentooer, at least.  Both binary distributions in general and Gnome 
in general, seriously handicap a power user, to the point it really DOES 
feel like swimming with a leg and arm tied together, and combining them... 
<shudder>  OTOH, they're often perfect for the user that's not 
particularly interested in configuring their computer, and just wants it 
to work so they can get what they REALLY want to do, done.  But if 
anything does go wrong, as it seems to have done here, OUCH, because 
you're fighting the system to try to fix it!  Different strokes for 
different folks, etc, and if it's what you're comfortable with, good for 
you! choice is what free software's all about! but the fact remains, for 
me, Ubuntu is not my idea of fun, for sure, and it'd take quite a stack of 
money or other such motivation to change my mind! (And even then, it 
wouldn't be fun, it'd be purely for the money or whatever, not for the 
fun, for sure!))

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