glibc-2.16 doesn't declare gets() anymore.
Atached patch fixes issue.
Created attachment 317368 [details, diff]
I'd really would like to avoid this. Given that glibc-2.16 is masked the same way gnutls-3 is, I think we should just unmask the latter before unmasking the former, and that's it.
Latest gnutls-3 actually builds fine with glibc-2.16, that's why I say this.
Using gnutls-3 is going to cascade way more issues that are harder to fix than using gnutls-2 with the above patch.
Just isolating gnutls-3 and looking if it works under glibC 2.16 is not good enough. You have to go on and try to use it with OpenLDAP and many other applications and then you will see that it is not quite there where it should be.
I'm the one who's doing the testing for gnutls-3 so I know what problems are there (and I added the tracker bug as a dependency here).
But upstream considers version 3 the current stable so I'd rather not patch the old one just yet.
(In reply to comment #4)
> I'm the one who's doing the testing for gnutls-3 so I know what problems are
> there (and I added the tracker bug as a dependency here).
I had no clue that you are the tester for gnutls-3.
> But upstream considers version 3 the current stable so I'd rather not patch
> the old one just yet.
I don't want to attack you or anyone of the Gentoo developers but portage is full of old applications where upstream is considering a newer releases as stable and we in Gentoo land still run older releases/revisions/etc.
So your argument with gnutls-3 is valid but overall I still think that insisting in users installing gnutls-3 when switching to glibc 2.16.x is the wrong approach. Wrong because other packages break when using gnutls-3 and there are no patches/fixes available for those packages to run under gnutls-3. But there is a solution for gnutls-2.12.18 (and the never 2.12.x versions). So IMHO providing the patch for gnutls-2.x is the smaller problem. Maybe in a bunch of minutes/hours/days/whatever there will be patches and fixes in b.g.o or in portage for running certain applications with gnutls-3 but as of today this is not the case.
We still have to patch something, and I simply would prefer to patch what doesn't work with gnutls-3 rather than patch gnutls-2.
We're not talking about a breakage in ~arch: glibc-2.16 is still p.masked (and will probably stay that way for at least a couple more weeks), so I don't see any _criticality_ for patching gnutls-2. That's all it is.
Actually, knowing how things work in Gentoo, by linking the fixes for glibc-2.16 to gnutls-3 and thus to the fixes for that, is probably the quickest way to have gnutls-3 support done.
Since fixing pkg builds with gnutls-3 isn't moving that fast and this patch is trivial I've added it to 2.12.20.