hi, i just upgraded from gnutls-1.0.17 to gnutls 1.2.3. After the upgrade, i ran "revdep-rebuild -p" as recommed. it said: broken /usr/lib/libgnutls-extra.so.12.3.0 (requires libgnutls.so.11) broken /usr/bin/gnutls-cli (requires libgnutls.so.11) broken /usr/bin/gnutls-serv (requires libgnutls.so.11) broken /usr/bin/srptool (requires libgnutls.so.11) broken /usr/bin/gnutls-cli-debug (requires libgnutls.so.11) As you can see, the new "libgnutls-extra.so.12.*" is linked against the old "libgnutls.so.11" which has been unmerged now. While compiling gnutls, the programs and libraries seem to get linked aginst the already installed gnutls-version instead of the newly compiled one. Of course, emerging gnutls twice will help, but this should be fixed somehow. Reproducible: Always Steps to Reproduce:
emerge -C the old gnutls and emerge the new one gnutls would of showed up in the revdep-rebuild instructions at the end of the emerge.
yes, gnutls showed up in the revdep-rebuild instructions.
This update to libgnutls also breaks the calendar module in Evolution, and probably anything else that depends on libgnutls.so.11. A symlink of the old library version to the new one fixed Evolution for me. As far as Evolution's needs go, libgnutls.so.12.3.0 is backward compatible with libgnutls.so.11. Re-emerging Evolution did not fix this. It used to have two references to libgnutls.so.11 in its ldd list. The first of those change to version 12, but the second didn't. More libraries in /usr/lib are now broken because version 11 is gone.
Andrew - is the previous version of gnutls removed? Did you do a revdep-rebuild --soname-regexp libgnutls.so.1[0-1] as per the post install instructions? Have you got ccache enabled or a partially existing compile in /var/tmp/portage that would have somehow cached the previous version of gnutls for recompulation? I appreciate that a lot of the gnutls library is backwards compatible however I wouldn't 100% trust it. I suggest: 0. remove the .11 symlink 1. emerge -C gnutls 2. emerge gnutls 3. Check that gnutls doesn't link to the old version 4. rm -rf /var/tmp/portage 5. env FEATURES=-ccache revdep-rebuild --soname-regexp libgnutls.so.1[0-1]
Thanks for the feedback. I did all those, pretty much. There are some instructions at the end of the gnutls emerge that I should have done. Reading the glsa oriented info in this page also helped: http://bugs.gentoo.org/show_bug.cgi?id=90726#c10 Now I have gnutls 12 in place. The new version seems to have broken Evolution's ssl support, but I reported that in a different bug report: http://bugs.gentoo.org/show_bug.cgi?id=91095
thanks Andrew, I'd hoped the glsa would of come out a bit earlier however it was stalled due to a bit of confusion. Sven I hope your fixed too.
I guess the reason, why this bug was closed, is that after updating gnutls, it is recompiled autmatically by an revdep-reqbuild. Well, that _will_ result in a working gnutls again, but still the main reason why i opened this bug, hasn't been paid attention to. Emerging gnutls 1.2.3 while gnutls-1.0.17 is installed, will result in a broken gnutls. This can be solved of course, by re-emerging gnutls 1.2.3, what revdep-rebuild will surely do, but i think that it is absurd, that compilging gnutls only once results in a broken compilation. IMHO there's something broken with the build-process. If the maintainer thinks, that this is a problem with the build-process rather than the ebuild, i would at least expect that gnutls-developers are informed, that the build-process is buggy and uses the already installed versions of the library in favour of the newly compiled one. I took a look into the ebuild, and AFAIk this is _not_ a bug in the ebuild, since it does a pretty normale "configure; make; make install". Just my 50 cents.
ranting really doesn't impress me. Yes a better solution could of been done however I didn't have the time. Please provide a solution. It will probably be some correction in the library paths when linking.
