Mike Brown posted on Thu, 21 Jun 2012 00:43:32 -0500 as excerpted: > On Wed, Jun 20, 2012 at 10:17:06PM -0700, Joe Zeff wrote: >> I'm using Fedora 16 and Pan 0.135. You should be able to get an update >> from the standard repos. What distro are you using? > > Fedora 14 x86-64. I have a friend that went to 15 and absolutely hates > the Gnome massive change. 16 is supposed to have "fixed" a little bit > of it, but I gather Gnome still sucks, so I have not changed to either > version. It seems he is not the only one who hates the "new" Gnome. > > In any event, a yum update of pan gets nothing. Doing a yum install of > pan just stops with yum reporting that pan 0.133 is the latest. > > So I tried to do a compile of pan 0.138, only to have the configure fail > on the gmime test. It complains that 2.4, or later, doesn't exist, yet > a yum install (I know there are other ways to get a list of installed > packages, > this is just faster, in case it isn't installed) reports that gmime > 2.5.1-1.... > is installed. > > Kinda hard to compile something when configure doesn't correctly find > installed packages.
I'm with JZ, except that I'm a kde guy... on gentoo so I compile from source via script, but that means it's easy, since everything is compiled from source via script. Anyway, gentoo and from-source lets me build kde4 without the semantic-desktop stuff, which slows down the system, taking memory, etc, without for me being useful enough to pay-back for the slow-down. But if you want to stay with the gnome2 side, try either mate or cinnamon on a distro that has them. One is a continuing maintained gnome2, the other gnome3 but adapted back toward gnome2 work-alike. Either of those, or JZ's xfce or lxde, being the other two gtk-based desktops (xfce a middle ground between the heavier gnome/kde and the light stuff, lxde a lighter weight desktop). Between the four choices, you can probably find something that fits. Meanwhile, here I believe is the direct answer to your compile-from- sources problem: Binary distros (unlike gentoo but like Fedora) often split libraries into run-time library package and dependent-package built- time "devel" package. Since you're attempting to build pan from sources, you need the "devel" package as well as the runtime library. Note that if you just install the one, you'll probably get past that and have the same problem with a different library. Probably the easiest way to avoid that one-at-a-time "dependency hell" is to first try getting the srpm of the existing pan version (0.133) and try rebuilding it, or at least "pretend" to rebuild it. That'll give you a list of packages it needs to install first, probably mostly the development packages since you already have the runtimes installed, and you can then take that list and install the devel packages of versions corresponding to what you have now, checking the pan site to get the list of current dependencies in case you need to update various libs, to get at least most of them at once. One package you'll almost certainly have to upgrade is gnutls, since pan requires a quite recent version. If you look back a couple days on the list, you'll see a thread explaining how to tell pan that it doesn't really need such a high version, but you'll probably still have to upgrade, as the version you have most likely simply won't work -- wrong API. One caveat, however. Do check what other packages require gnutls, and be sure to check them after you upgrade it. It's possible you'll either have to upgrade them as well, or at least rebuild them, due in the first case to API changes, in the second to ABI changes even if the same API is maintained. One more dependency (and possibly even pan) upgrading hint: If you've not yet discovered it, take a look at rpmfind.net. This lets you check dependencies, etc, and you can often find rpms for either newer distro versions or different distros that work with your distro version too. At least that was my experience back on Mandrake, quite some years ago. But I've always been leading edge, not trailing edge, so I was always trying to install stuff that the distro hadn't packaged even in its latest version yet. So while it was great for me and it could well work for you, it's possible it doesn't work quite so well for trailing end. You'd just have to try it and see. Finally, there's another option that will let you continue using current pan and still connect via SSL. However, it's a bit complicated and while I understand the idea, I've never personally tried it -- but some here have, so you have people to ask if you decide to try this. The idea is to use a package called stunnel as a sort of secure local proxy. You configure it to listen on a loopback interface port (normally 127.0.0.1, likely standard nntp port 119 for your first server, perhaps 120 for your second if you have more than one, etc) for a connection from pan, which it then relays over its secure-tunnel (thus the name, stunnel) to the remote server. Then instead of configuring pan to connect to that remote server directly, you tell it to connect to the loopback interface, port 119 or whatever, that you setup stunnel listening on. This is certainly more complicated than pan doing it by itself, but pan simply didn't support ssl itself until very recently, and this was the workaround people who needed a secure connection with pan had used for... well, pretty much all of pan's (or stunnel's if it's newer, I don't know) existence, I guess. -- 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
