[jitsi-users] Issue with "jitsi" wrapper script on debian

Hiya,

I had to edit the /usr/bin/jitsi script for it to work on a few
machines. Please see my comments on the script inline below:

#!/bin/bash

There's nothing bash specific in here, so you might as well use

#! /bin/sh -

# Get architecture
ARCH=`uname -m | sed -e s/x86_64/64/ -e s/i.86/32/`

That will return the kernel architecture, which might not be the
same as the debian installation architecture, or the java
architecture.

For instance, I've got one system here with:

~# uname -mr
3.0.0-1-amd64 x86_64
~# dpkg-architecture -qDEB_HOST_ARCH_BITS
32
~# dpkg-architecture
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i486-linux-gnu
DEB_HOST_MULTIARCH=i386-linux-gnu

Another 64 bit one but with the 32 bit java as the default:

$ update-alternatives --display java
java - manual mode
  link currently points to /usr/lib/jvm/ia32-java-6-sun/jre/bin/java
/usr/lib/jvm/ia32-java-6-sun/jre/bin/java - priority 15
  slave java.1.gz: /usr/lib/jvm/ia32-java-6-sun/jre/man/man1/java.1.gz
/usr/lib/jvm/java-6-sun/jre/bin/java - priority 63
  slave java.1.gz: /usr/lib/jvm/java-6-sun/jre/man/man1/java.1.gz
Current 'best' version is '/usr/lib/jvm/java-6-sun/jre/bin/java'.

I think the architecture should be hardcoded in the script
there. That is have one script for the 32bit jitsi package and
another one for the 64bit one.

Alternatively, you could use "dpkg-architecture
-qDEB_HOST_ARCH_BITS" or extract the architecture from

$ readelf -h /usr/lib/jitsi/lib/native/libcivil.so
ELF Header:
  Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Version: 1 (current)
  OS/ABI: UNIX - System V
  ABI Version: 0
  Type: DYN (Shared object file)
  Machine: Advanced Micro Devices X86-64
  Version: 0x1
  Entry point address: 0xaf00
  Start of program headers: 64 (bytes into file)
  Start of section headers: 160320 (bytes into file)
  Flags: 0x0
  Size of this header: 64 (bytes)
  Size of program headers: 56 (bytes)
  Number of program headers: 5
  Size of section headers: 64 (bytes)
  Number of section headers: 26
  Section header string table index: 25

or:

$ objdump -f /usr/lib/jitsi/lib/native/libcivil.so

/usr/lib/jitsi/lib/native/libcivil.so: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000000000000af00

or:

$ file /usr/lib/jitsi/lib/native/libcivil.so
/usr/lib/jitsi/lib/native/libcivil.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Though that would mean adding dependencies to any one of the
packages that contain those commands.

# Additionnal JVM arguments
CLIENTARGS=""

if [ $ARCH -eq 32 ]
then
    CLIENTARGS="-client -Xmx256m"
fi

javabin=`which java`

"command -v" is the standard equivalent of the non-standard "which" command.
javabin=$(command -v java)
But that would be useless since "command"/"which" just look for
the command in $PATH, so one might as well call "java" directly.

Also, what you want here is a java intepreter that is of the
same architecture as the libraries in /usr/lib/jitsi/lib/native.

Also, it seems that jitsi works better with sun-java than with
openjdk.

So you may want to go through the various JVMs installed and
pick the prefered ones.

Something like (for 64 bits)

set -f
IFS='
'
unset javabin
for i in $(update-alternatives --list java); do
  case $i in
    (*i?86*|*ia32*) continue;;
    (*/java-6-sun*) javabin=$i; break;;
    (*/java-6-*) javabin=$i;;
  esac
done
if [ -z "$javabin" ]; then
  printf >&2 '%s\n' "No suitable java interpreter found"
  exit 1
fi

SCDIR=/usr/lib/jitsi
LIBPATH=$SCDIR/lib
CLASSPATH=$LIBPATH/jdic_stub.jar:$LIBPATH/jdic-all.jar:$LIBPATH/felix.jar:$LIBPATH/bcprovider.jar:$SCDIR/sc-bundles/sc-launcher.jar:$SCDIR/sc-bundles/util.jar
FELIX_CONFIG=$LIBPATH/felix.client.run.properties
LOG_CONFIG=$LIBPATH/logging.properties

It's dangerous to use uppercase variable names as they might
match existing environment variables.

COMMAND="$javabin $CLIENTARGS -classpath $CLASSPATH -Djna.library.path=$LIBPATH/native -Dfelix.config.properties=file:$FELIX_CONFIG -Djava.util.logging.config.file=$LOG_CONFIG net.java.sip.communicator.launcher.SIPCommunicator"

# set add LIBPATH to LD_LIBRARY_PATH for any sc natives (e.g. jmf .so's)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LIBPATH/native

If LD_LIBRARY_PATH was previously empty or unset that will add
the current directory to LD_LIBRARY_PATH (thanksfully not too
much of a concern here as jitsi will be started in $SCDIR).

cd $SCDIR

cd -P -- "$SCDIR" || exit

exec COMMAND *

Quoting is wrong there. Should be:

COMMAND='
  "$javabin" \
      '"$CLIENTARGS"' \
      -classpath "$CLASSPATH" \
      -Djna.library.path="$LIBPATH/native" \
      -Dfelix.config.properties="file:$FELIX_CONFIG" \
      -Djava.util.logging.config.file="$LOG_CONFIG" \
      net.java.sip.communicator.launcher.SIPCommunicator'
eval "exec $COMMAND \"\$@\""

Attached is a fixed script for the amd64 jitsi package.

Best regards,
Stephane

jitsi (1 KB)

···

Data: 2's complement, little endian