[Pkg-tigervnc-devel] Bug#851842: Bug#851842: tigervnc-xorg-extension - libvnc.so fails to load with undefined symbol: gnutls_bye

[Martin Dorey]

On Fri, 20 Jan 2017 22:10:29 +0100 Ola Lundqvist <opal at 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 at 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 at 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 at 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 at shuttle:~/tigervnc-1.7.0+dfsg$ find . -name libvnc.* | xargs rm
mad at 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 at shuttle:~$ xdpyinfo | grep VNC
    VNC-EXTENSION
mad at 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-tigervnc-devel/attachments/20170129/3d34c501/attachment.html>