Duncan posted on Fri, 02 Nov 2012 01:24:38 +0000 as excerpted: > walt posted on Thu, 01 Nov 2012 15:22:39 -0700 as excerpted: > >> The 'testing/unstable' version of gentoo upgraded gnutls today >> (finally!) but then I discovered pan could not open a successful >> encrypted session with any of my news servers :( >> >> By painful trial-and-error I found that the update to gnutls from >> 2.12.20 today didn't break pan, it broke glib-networking instead, which >> is now linked against the new gnutls-3.1.3
>> Anyway, gentoo is currently using glib-networking-2.32.3 and I'm >> wondering if that version is too old to work with gnutls-3.x >> Duncan, have you done the update yet? > > I've done the update, yes, but unfortunately don't believe I can be much > help, as while I'm building pan with gnutls, I'm not actually /using/ > gnutls for gmane, the only server I have active[.] I actually upgraded > to gnutls-3.x quite some time ago [and have] been upgrading gnutls > regularly [b]ut, as I said, I've not actually been /running/ pan with > secure/gnutls connections for some months now, so while I know pan's > building fine with it, and working fine too, at least with non-secure > connections, I really can't tell you what secure connections are doing, > at all. > > So I know there's no build or unsecure runtime issues with it and pan, > but I don't know about secure-connections, and that seems to be the one > thing you haven't gotten working, either. > > But, I've been meaning to try secure connections again one of these > days. Now's as good a time as any, I guess, and the glib-networking > clue you mentioned could be useful if I run into problems. > > Let me get back to you. ... And here I am. =:^) After doing a new @world update (I hadn't in 2-3 days) with the routine followup etc-update, revdep-rebuild and depclean, plus checking on pan-9999 (no fresh commits) and openrc-9999 (1 fresh commit, checked, built and installed, did a couple net vs. net.lo config updates I had been putting off), the two "live" packages I'm following ATM, then doing the kernel git pull, whatchanged, rebuild and install I like to do before rebooting (uname -r now says 3.7.0-rc3-00077-g8c23f40)... I rebooted, loaded X/KDE, reconfigured my gmane server in pan to use secure connections once again, and restarted pan, then fetched headers. Pan asking me about a new gmane cert which I accepted. Pan fetched the headers (no updates in my subscribed groups), and I restarted pan once again. Once again I hit the fetch-headers button, and once again, it did so. Still no updates, but no errors either. Seems it's working fine with secure connections. Just to be sure, from my admin login (separate from my normal user login, which has very limited sudo privs, spacing shrunk for posting): $ sudo netstat -4p | grep pan netstat: no support for `AF INET (sctp)' on this system. tcp 0 0 ws:55339 ger.gmane.org:nntps ESTABLISHED 4515/pan So it's definitely a secure/nntps connection! =:^) However, I don't have glib-networking installed at all on this system: $ equery l -op glib-networking * Searching for glib-networking ... [-P-] [ ] net-libs/glib-networking-2.30.2:0 [-P-] [ ] net-libs/glib-networking-2.32.3:0 [-P-] [M ] net-libs/glib-networking-2.34.0:0 No I/installed. What's pulling in glib-networking for you? That's obviously not in my pan deps here. Here's my USE flags from an emerge --pretend pan: USE="spell ssl -gnome-keyring -libnotify" (I run a local overlay pan-9999.ebuild that lets me set a few git2.eclass vars in /etc/portage/env/net-nntp/pan, but synced it with the one in the tree only about a week ago, so deps should be current.) Both the tree ebuild and mine hardcode the build against gtk2, (econf --without-gtk3), so unless you're building manually or have customized that bit of your ebuild from the one in the tree, you're building against gtk2 as well and a gtk3 build can't be it. I just did a: $ USE="gnome-keyring libnotify" emerge --pretend pan It did want to pull in a few packages including gtk+-3.x, but it did NOT want to pull in glib-networking. So what's pulling in glib-networking? Whatever it is, pan's not pulling in glib-networking here, glib-networking isn't in fact installed at all, and gnutls-3.1.3 secure connections ARE working here. So it CAN work. And if you're right about that glib-networking thing, tracing why that's being pulled in to pan's deps and getting that fixed (either by turning off the USE flag pulling it in on some dependency, or by bugging it with gentoo) could well fix your issue. ... But now that I'm on the case, I'm curious... equery g --depth=5 pan, then using konsole's search-in-output to find glib-networking... Looks like libsoup, dependency of gnome-shell, dependency of virtual/notification-daemon, dependency of... libnotify!! libnotify has a single USE flag, gnome. USE=gnome or-deps on gnome-shell or x11-misc/notification daemon. USE=-gnome has a wider variety of or-deps, including kde-base/knotify. Since my desktop is kde, I obviously have USE=-gnome, and kde-base/knotify would fill that dep for me. That's why I'm not pulling in anything major besides libnotify, even if do an emerge --pretend with USE=libnotify set. I assume you're running gnome3 and have USE=libnotify and USE=gnome set. So pan's pulling gnome-shell in via USE=libnotify. If that's true, setting USE=-libnotify for pan in package.provided and rebuilding pan will hopefully kill that dependency, and with it, the bad gnutls-3.1.3 behavior you're seeing. Of course you'll then lose pan's libnotify feature, but here anyway, I'm somewhat confused on what it does anyway. pan seems to work fine with it off, but IIRC I had it on for awhile and didn't notice any notifications. Maybe that feature (which is fairly new, a Heinrich addition) wasn't working yet? Anyway, whatever the libnotify feature does, looks like you can choose between it and gnutls/ssl connections. Alternatively, knowing the dependency chain it's tracing thru, you may be able to rebuild one or more of glib-networking, libsoup, gnome-shell and libnotify, (that's dependency order, so do it in that order) against the new gnutls, and see if that eliminates the issue. Meanwhile, I've discovered a gnutls-3.1.3 issue of my own, tho it was working with gnutls-3.1.2. But it's claws-mail that's giving me the problem here (crashing on mail fetch), not pan. But a simple claws-mail rebuild doesn't seem to help, so I gotta dependency dig there too. But I know gnutls-3.1.2 was working with it and I still have the 3.1.2 ebuild from the pre-unmasking 3.1.3 build problem I explained previously, so I can simply revert to it for the time being, if it comes to that. -- 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
