Re: [Pan-users] Pan 0.139-7 will not start

[Duncan]

Maurice posted on Mon, 14 Mar 2016 19:36:03 +0000 as excerpted:

> Using V.139-6 here on Mageia-5 with no problems, I tried using V.139-7
> on Mageia-6 Beta, but it fails (using a copy of Mageia-5's .pan2
> directory):
> 
> $ pan GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> news.pan.NZB was not provided by any .service files
> 
> (pan:7270): Gtk-WARNING **: Theme directory  of theme oxygen has no size
> field
> 
> **
> ERROR:pan-tree.cc:80:GtkTreeIter PanTreeStore::get_iter(const
> PanTreeStore::Row*): assertion failed: (row)
> Aborted (core dumped)
> address@hidden ~]$
> 
> Does Pan 13-7 do things differently?

[The following can be read as much more aggressively grouchy than I 
intend.  Please don't take it as such.  I'm simply trying to convey the 
scale of the question you asked and help you find mageia distro-specific 
answers you as a mageia user can find much more conveniently than I as a 
gentoo user can.  There's more practical troubleshooting suggestions 
further down, in the troubleshooting section.]


EINSUFFICIENTINFO

Presumably, mageia's v.139-7 is based on pan's 0.139, plus various 
patches.  Most or all of them could be from (upstream, that's us) pan's 
git repo, basically, pan built from snapshots of the live git repo, or 
they could be mageia-specific patches, only mageia's pan package 
maintainer and folks looking at the mageia pan package history would know.

Further, even if the package is built from near-pure upstream sources, 
there's quite a few build-time options, including building against gtk2 
(recommended) or gtk3 (generally works but reports say is somewhat 
buggier, and the recommendation remains gtk2 so the gtk3-only bugs don't 
get much investigation because most folks are on the gtk2 version), and 
building in support (and linking against libraries) or not for everything 
from dbus support, to notifications, to spell-checking, to ssl/tls secure 
connections.  What choices your distro package maintainer has made there 
aren't known, except to him and those looking at that package changelog 
and/or using the package (where it'll be obvious if things like 
spellcheck and secure connections are supported or not).

Then of course pan links against all those libraries at build-time, with 
a minimum version necessary for each, but all the libraries have their 
own version history and bugs in some versions but not in others.  I've 
personally been involved in tracing a number of bugs over the years, that 
turned out not to be in pan itself, but rather, in specific versions of 
some library or other that pan links to and uses.

To non-mageia users, from the posted information, both pan v.139-6 and 
pan v.139-7 would appear to be the same, but for whatever distro-specific 
version changes, which we wouldn't know about.  Those changes would be 
covered in the package changelog, but unless we're actually the distro 
developer ourselves or are actually looking at that changelog, we haven't 
the foggiest clue what they are or how extensive they may be, and as the 
three paragraphs above should demonstrate, they could be **VERY** 
extensive indeed, even if it's the exact same upstream code used, with 
exactly zero change in distro supplied patches, as well, simply based on 
build-time configuration options and what specific libraries and their 
versions were enabled and linked.

And sure, I could look up the package on rpmfind (or google I imagine, if 
I didn't know about rpmfind) and read the changelog there to tell you 
what changed, but you could do it just as easily as I could, and as you 
obviously have the package installed as well, it's very likely you can do 
it easier, without resorting to external resources, by simply invoking 
the appropriate package manager or rpm command to view that changelog.


Troubleshooting:

Meanwhile, in terms of troubleshooting, when pan (or pretty much any 
other app) fails to start after an upgrade, there's two questions to ask 
right away:

1) Will the app start with a clean app config?

For pan, that means moving PAN_HOME (~/.pan2/ by default, but you can 
point it elsewhere by setting the PAN_HOME variable in the environment 
pan inherits as it starts) elsewhere (or pointing it somewhere else if 
you've set the var) and trying with new pan configuration.

If that works, you know it's a problem in the user's application 
configuration itself, and can bisect that config from there to see what 
specific setting is the problem, or simply blow away the existing config 
and start over from scratch, if it's easier.

2) Will the app start with a clean user config?

The same question as above, but now at the entire user scope.  Perhaps 
you have some theme or other user level, not app level, setting, that is 
causing that app to crash.

This is tested by either moving your entire user config (/home/whatever) 
elsewhere temporarily, and seeing if you can start pan with an entirely 
clean user config, or by setting up and logging in as a new user, 
temporarily, to see if pan will start from there.

If that works, then you know it's a problem in your specific user config, 
and can bisect the problem from there.  If it doesn't, but the app worked 
previously, then you know it's a problem in the upgrade you just did, or 
in the non-user system level configuration.  Only at that point do you 
really need to start looking at what changed between versions, etc, 
because only at that point have you eliminated the possibility that it's 
a specific user config issue.

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