On Fri, 20 Jan 2017 22:10:29 +0100 Ola Lundqvist <o...@debian.org> wrote: > I have now been able to reproduce the problem. It is not solved by > merely adding more dependencies. I have to look further to find the > cause of the problem.
Hey Ola, I think I can help. First, though, I'm delighted to see that your ITP for tigervnc went through for Stretch. But is that still a default -depth of 32 I see - how are the poor users going to work out that they need to try -depth 24, per the warning in man xtigervnc, to get their, eg Java, text rendered properly? Anyway, I think the problem here has the same cause as the similar one described by: https://github.com/TigerVNC/tigervnc/issues/294: unable to load libvnc.so after installing 1.5.x or 1.6.0 I had another great experience with tigervnc-standalone-server this weekend, which lets me connect to Gnome 3 over a metro area as if I were in the office, in contrast to vino, where I have to tolerate several megabits per second of background traffic when idle, making interactivity unusably slow. Thus I wanted to replace vino with tigervnc-xorg-extension on the :0 of my just-upgraded-to-Jessie server. I faced: [238863.164] (EE) Failed to load /usr/lib/xorg/modules/extensions/libvnc.so: /usr/lib/xorg/modules/extensions/libvnc.so: undefined symbol: gnutls_transport_set_ptr2 ... which looks exactly like part of upstream's problem. On a Stretch system, with Debian's (yay!) native packaging, I see the gnutls_bye symptom instead. If I rebuild your Sid packaging, from apt-get source tigervnc, with: mad@shuttle:~/tigervnc-1.7.0+dfsg$ dpkg-buildpackage -nc -uc -us ... then apply upstream's patch, in my so very crude fashion, using what I think, having looked it up, is the shiniest flavor of Ubuntu that upstream supports: mad@shuttle:~/tigervnc-1.7.0+dfsg$ (cd unix/xserver && patch -p1 < ../../contrib/packages/deb/ubuntu-xenial/debian/xorg-source-patches/debian_libtool.patch) checking file ltmain.sh Hunk #1 succeeded at 7893 (offset 3 lines). checking file ltmain.sh Hunk #1 succeeded at 7571 (offset 3 lines). checking file m4/libtool.m4 Hunk #1 succeeded at 4947 (offset 11 lines). Hunk #2 succeeded at 5009 (offset 14 lines). Hunk #3 succeeded at 5784 (offset 17 lines). mad@shuttle:~/tigervnc-1.7.0+dfsg$ As you see, I get a reasonably clean application, but libvnc.so didn't rebuild when I repeated the dpkg-buildpackage command. Oh, for the simple days, when dependencies were complete and "make" was all you needed! Just removing the .so got me a build failure, causing more sadly grey-bearded head-shaking, but removing the .la and .lai files too: mad@shuttle:~/tigervnc-1.7.0+dfsg$ find . -name libvnc.* | xargs rm mad@shuttle:~/tigervnc-1.7.0+dfsg$ ... then repeating the dpkg-buildpackage command got me a ./debian/tigervnc-xorg-extension/usr/lib/xorg/modules/extensions/libvnc.so that, when used to replace /usr/lib/xorg/modules/extensions/libvnc.so, effaces the (EE) error from wherever ls -l /proc/$(pidof Xorg)/fd told me that the squirrels had buried Xorg.0.log. xdpyinfo now happily reports: mad@shuttle:~$ xdpyinfo | grep VNC VNC-EXTENSION mad@shuttle:~$ Sorry to make such a meal of such a trivial nugget, but I want to convey how little I understand. Now, if you'll excuse me, I'm off to try to similarly brutalize the old Jessie packaging of tigervnc 1.6.0, if I still have it lying around, to see if I can get back in to :0 on the server that I actually care about...
