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
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
