Arch Linux User Repository

Thanks for the quick response! Yes, it's strange - installations with yay went without problems on other computers with the same Manjaro version (all updated to latest packages) but on 1 comp this error persists. Here's what I've found: 1. Verified that both /usr/lib/libturbojpeg.so and /usr/include/security/pam_appl.h are present. 2. Tried building without a helper (by following the AUR wiki page), worked, no errors.

Do you have perhaps any suggestions what could be happening with yay?

Also now that it's installed on the client and headless server, I cannot connect. I ran on the server vncserver and get on the client when using vncviewer: "Could not execute /opt/TurboVNC/bin/vncserver -sessionlist". On the server this path indeed doesn't exist. And in .vnc/my_headless_server:1.log I see permission errors:

08/02/2024 10:22:12 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
08/02/2024 10:22:12 Listening for VNC connections on TCP port 5901
08/02/2024 10:22:12   Interface 0.0.0.0
08/02/2024 10:22:12 Framebuffer: BGRX 8/8/8/8
08/02/2024 10:22:12 New desktop size: 1240 x 900
08/02/2024 10:22:12 New screen layout:
08/02/2024 10:22:12   0x00000040 (output 0x00000040): 1240x900+0+0
08/02/2024 10:22:12 Maximum clipboard transfer size: 1048576 bytes
08/02/2024 10:22:12 VNC extension running!
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Could not resolve keysym XF86CameraAccessEnable
> Warning:          Could not resolve keysym XF86CameraAccessDisable
> Warning:          Could not resolve keysym XF86CameraAccessToggle
> Warning:          Could not resolve keysym XF86NextElement
> Warning:          Could not resolve keysym XF86PreviousElement
> Warning:          Could not resolve keysym XF86AutopilotEngageToggle
> Warning:          Could not resolve keysym XF86MarkWaypoint
> Warning:          Could not resolve keysym XF86Sos
> Warning:          Could not resolve keysym XF86NavChart
> Warning:          Could not resolve keysym XF86FishingChart
> Warning:          Could not resolve keysym XF86SingleRangeRadar
> Warning:          Could not resolve keysym XF86DualRangeRadar
> Warning:          Could not resolve keysym XF86RadarOverlay
> Warning:          Could not resolve keysym XF86TraditionalSonar
> Warning:          Could not resolve keysym XF86ClearvuSonar
> Warning:          Could not resolve keysym XF86SidevuSonar
> Warning:          Could not resolve keysym XF86NavInfo
Errors from xkbcomp are not fatal to the X server
xstartup.turbovnc: Creating new session bus instance:
xstartup.turbovnc:   unix:path=/tmp/dbus-gFTG2Te6k1,guid=37d8e16a564524645eab200665c49d45
xstartup.turbovnc: Executing /etc/X11/xinit/xinitrc
/usr/bin/xstartup.turbovnc: line 209: /etc/X11/xinit/xinitrc: Permission denied
/usr/bin/xstartup.turbovnc: line 209: exec: /etc/X11/xinit/xinitrc: cannot execute: Permission denied
Killing Xvnc process ID 1834831

@terryer Hi! The errors you are getting are very strange to me. libturbojpeg.so is part of the dependency "libjpeg-turbo". It is located in /usr/lib if you want to verify it is on your system. And pam_appl.h is provided by the package "pam", which should be on most Arch systems as it is required by systemd amongst other packages. One of these being sudo, which is in return required by base-devel. pam_appl.h is in /usr/include/security/ if you also want to check for it. That being said since pam is directly required I'll be sure to add it to the dependency list.

However, I don't think that alone will fix your issue. Have you tried building the package without an AUR helper? The process is explained in the AUR wiki page in case you haven't tried it before.

After first yay -S turbovnc

CMake Error at cmakescripts/FindTurboJPEG.cmake:87 (message):
  Could not link with TurboJPEG library /usr/lib/libturbojpeg.so.  If it is
  installed in a different place, then set TJPEG_LIBRARY accordingly.
Call Stack (most recent call first):
  CMakeLists.txt:162 (include)


-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: turbovnc-exit status 4
 -> Failed to install the following packages. Manual intervention is required:

The next day running yay -S turbovnc:

-- XKB_DFLT_VARIANT = 
-- XKB_DFLT_OPTIONS = 
-- XORG_FONT_PATH = /usr/share/X11/fonts/misc/,/usr/share/X11/fonts/Type1/,/usr/share/X11/fonts/75dpi/,/usr/share/X11/fonts/100dpi/
-- XORG_REGISTRY_PATH = /usr/lib64/xorg
-- Looking for backtrace
-- Looking for backtrace - found
-- XORG_DRI_DRIVER_PATH = /usr/lib64/dri
-- Looking for include file security/pam_appl.h
-- Looking for include file security/pam_appl.h - not found
CMake Error at unix/Xvnc/programs/Xserver/hw/vnc/CMakeLists.txt:14 (message):
  Could not find PAM headers


-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: turbovnc-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
turbovnc - exit status 4

@PlasticSoup, thanks for adopting the package. Meant to deal with the out-of-date issue for months, but life kept interfering. Cheers

Having just adopted this package, I have done a major rewrite of the PKGBUILD in an attempt to meet packaging guidelines. Note specifically that the config directory is now in /etc/turbovnc and a PGP key is now used to validate the download. You can import the ASC file included or view the "Digital Signatures (Code Signing Policy)" at the upstream URL.

confirmed that it's running fine on raspberry pi 3 too. however i had to remove -d32 from /usr/bin/vncviewer script. otherwise i was getting the following error:

libjawt.so path: /usr/lib/jvm/java-20-openjdk/lib
Unrecognized option: -d32
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Hi, could you please change arch to the following arch=('i686' 'x86_64' 'aarch64' 'armv7h') I was able to set this up on a Raspberry Pi 4 and that change was needed in the PKGBUILD.

Similar issue: I had to pre-install jdk11-openjdk before building (maybe other version would have worked also, but plain jdk-openjdk (19.0.2) was not sufficient), otherwise got a build error about not being able to find java. The PKGBUILD should probably be changed to include some jdk under makedepends.

Hi: I make several changes to the PKGBUILD:

1. I moved java-environment to makedepends list and put java-runtime to depends list as jdk is only needed for building and jre is enough for runtime.
2. I removed the line specifying the openssl location as the current location is wrong (upstream package openssl has been upgraded to version 3) and the dependency is on openssl and not openssl-1.0.

I have tested the new PKGBUILD could build successfully and vncviewer runs normally. I did not test vncserver.

Here is the patch:

diff --git a/PKGBUILD b/PKGBUILD
index 4a4baf2..300896b 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -7,12 +7,12 @@
 pkgname="turbovnc"
 pkgdesc="An optimized version of TightVNC"
 pkgver=3.0.2
-pkgrel=2
+pkgrel=3
 arch=('i686' 'x86_64')
 url="http://www.turbovnc.org/"
 license=('GPL')
-makedepends=('cmake' 'rsync')
-depends=('libxaw' 'libxt' 'libxi' 'libxcursor' 'libjpeg-turbo' 'java-environment>11' 'openssl' 'python')
+makedepends=('cmake' 'rsync' 'java-environment>11')
+depends=('libxaw' 'libxt' 'libxi' 'libxcursor' 'libjpeg-turbo' 'java-runtime>11' 'openssl' 'python')
 sha256sums=('616dc72ce52351b70a239c2f464c83136e6143a23c7d316e3b29f68ea71c9949'
             'ccadf1fc708fad601e6113464d6c533a629f6dc9116f6071347cd0b465c1f48b')
 conflicts=('turbovnc-bin' 'tigervnc' 'tigervnc-svn' 'tightvnc')
@@ -25,7 +25,6 @@ backup=(etc/turbovncserver.conf
 build() {
   mkdir -p "${srcdir}"/${pkgname}-${pkgver}/build
   export JAVA_HOME=/usr/lib/jvm/default/
-  export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib/openssl-1.0/pkgconfig
   cd "${srcdir}"/${pkgname}-${pkgver}/build
   ln -sf ../CMakeLists.txt
   cmake -G "Unix Makefiles" \

Thanks!

@celogeek, do you think your vncserver.service file now will work OK with all desktops? (I never start VNC at boot, so I'm just not sure what would be the best option). In any case this file is not installed by this package, so not sure if I should keep it?