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) > [mab@localhost ~]$ > > 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
