Re: [Pan-users] [gentooers] New pan/ssl problem from gnutls upgrade

[Duncan]

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