[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Pan 0.139-7 will not start
From: |
Duncan |
Subject: |
Re: [Pan-users] Pan 0.139-7 will not start |
Date: |
Tue, 15 Mar 2016 00:07:33 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 3dffc90) |
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