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


#1

Hiya,

sorry, I had posted this to the wrong mailing list, here's a
repost on the dev list.

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


#2

Hi,

thank you for the script, I will check it. But we must also see how we can
plug different scripts for amd64 and x86 debs in our build procedure.
Can you please create a feature request with attaching your script so we
don't loose track of it.

Thanks
damencho

···

On Fri, Sep 30, 2011 at 4:11 PM, Stephane Chazelas < stephane.chazelas@gmail.com> wrote:

Hiya,

sorry, I had posted this to the wrong mailing list, here's a
repost on the dev list.

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
Data: 2's complement, little endian
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


#3

2011-10-05 13:49:56 +0300, Damian Minkov:

thank you for the script, I will check it. But we must also see how we can
plug different scripts for amd64 and x86 debs in our build procedure.
Can you please create a feature request with attaching your script so we
don't loose track of it.

[...]

Hi Damien, actually, it's more than a feature request, it's
several bugs.

- jitsi won't start on systems where the default "java"
  interpreter is gcj for instance (common on debian).
- it won't work properly if the default java interpreter is the
  ia32 one on and amd64 machine and vice versa (though that
  would be a lot less common).
- it won't start if the path of the first java command in $PATH
  contains spaces or tabs or newline characters.
- it may not work properly or as expected if any of the
  arguments given to jitsi contain spaces or tabs or newlines or
  shell wildcard characters (*, ?, [)

Note that the script I suggested is debian/ubuntu specific
because of the use of the update-alternatives debian command.

Maybe a better option would be to loop through all the known
locations of java executables compatible with jitsi on the
supported platforms.

Do you want me to raise one or several bugs or a feature
request?

···

--
Stephane


#4

Hi again,

2011-10-05 13:49:56 +0300, Damian Minkov:
> thank you for the script, I will check it. But we must also see how we
can
> plug different scripts for amd64 and x86 debs in our build procedure.
> Can you please create a feature request with attaching your script so we
> don't loose track of it.
[...]

Hi Damien, actually, it's more than a feature request, it's
several bugs.

- jitsi won't start on systems where the default "java"
interpreter is gcj for instance (common on debian).
- it won't work properly if the default java interpreter is the
ia32 one on and amd64 machine and vice versa (though that
would be a lot less common).
- it won't start if the path of the first java command in $PATH
contains spaces or tabs or newline characters.
- it may not work properly or as expected if any of the
arguments given to jitsi contain spaces or tabs or newlines or
shell wildcard characters (*, ?, [)

Note that the script I suggested is debian/ubuntu specific
because of the use of the update-alternatives debian command.

Maybe a better option would be to loop through all the known
locations of java executables compatible with jitsi on the
supported platforms.

Well as we talk about debian packages I think its ok to use
update-alternatives.

Do you want me to raise one or several bugs or a feature
request?

yes please file a bug report describing the problems you have seen and also
mentioning this discussion :slight_smile:

Thanks
damencho

···

On Wed, Oct 5, 2011 at 3:31 PM, Stephane Chazelas < stephane.chazelas@gmail.com> wrote:

--
Stephane


#5

Hey folks,

На 05.10.11 15:51, Damian Minkov написа:

Hi again,

    2011-10-05 <tel:2011-10-05> 13:49:56 +0300, Damian Minkov:
    > thank you for the script, I will check it. But we must also see
    how we can
    > plug different scripts for amd64 and x86 debs in our build procedure.
    > Can you please create a feature request with attaching your script
    so we
    > don't loose track of it.
    [...]

    Hi Damien, actually, it's more than a feature request, it's
    several bugs.

    - jitsi won't start on systems where the default "java"
     interpreter is gcj for instance (common on debian).
    - it won't work properly if the default java interpreter is the
     ia32 one on and amd64 machine and vice versa (though that
     would be a lot less common).
    - it won't start if the path of the first java command in $PATH
     contains spaces or tabs or newline characters.
    - it may not work properly or as expected if any of the
     arguments given to jitsi contain spaces or tabs or newlines or
     shell wildcard characters (*, ?, [)

    Note that the script I suggested is debian/ubuntu specific
    because of the use of the update-alternatives debian command.

I am a bit rusty with my debian but I seem to remember that
upgrade-alternatives permanently modifies user preferences. Isn't this
the case? If so, then it doesn't sound like a very kosher thing to do as
an application.

Emil

···

On Wed, Oct 5, 2011 at 3:31 PM, Stephane Chazelas > <stephane.chazelas@gmail.com <mailto:stephane.chazelas@gmail.com>> wrote:

    Maybe a better option would be to loop through all the known
    locations of java executables compatible with jitsi on the
    supported platforms.

Well as we talk about debian packages I think its ok to use
update-alternatives.

    Do you want me to raise one or several bugs or a feature
    request?

yes please file a bug report describing the problems you have seen and
also mentioning this discussion :slight_smile:

Thanks
damencho

    --
    Stephane

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

2011-10-05 16:51:43 +0300, Damian Minkov:
[...]

yes please file a bug report describing the problems you have seen and also
mentioning this discussion :slight_smile:

[...]

http://java.net/jira/browse/JITSI-985

added.

I also included another less OS dependant approach at solving
some of the problem (jitsi2 attachment there).

Best regards,
Stephane


#7

2011-10-06 18:24:19 +0200, Emil Ivov:
[...]

> Note that the script I suggested is debian/ubuntu specific
> because of the use of the update-alternatives debian command.

I am a bit rusty with my debian but I seem to remember that
upgrade-alternatives permanently modifies user preferences. Isn't this
the case? If so, then it doesn't sound like a very kosher thing to do as
an application.

[...]

update-alternatives doesn't deal with user settings. It's a
system command that queries/change system settings: which
implementation of a command/man-page... to use by default when
several are available.

update-alternative --config java

will select where the /etc/alternatives/java symbolic link will
point to (and /usr/bin/java is a symlink pointing to
/etc/alternatives/java).

update-alternative --list java

called by the suggested script, however only queries the
available registered alternatives (usually by package
installation script) for "java" without changing any setting.

A system administrator can also register more alternatives with
the --install option.

On this system:

$ update-alternatives --list java
/usr/bin/gij-4.6
/usr/lib/jvm/ia32-java-6-sun/jre/bin/java
/usr/lib/jvm/java-6-sun/jre/bin/java
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

Of which only the 3rd will work correctly with jitsi.

···

--
Stephane


#8

На 06.10.11 19:44, Stephane Chazelas написа:

2011-10-06 18:24:19 +0200, Emil Ivov:
[...]

    Note that the script I suggested is debian/ubuntu specific
    because of the use of the update-alternatives debian command.

I am a bit rusty with my debian but I seem to remember that
upgrade-alternatives permanently modifies user preferences. Isn't this
the case? If so, then it doesn't sound like a very kosher thing to do as
an application.

[...]

update-alternatives doesn't deal with user settings. It's a
system command that queries/change system settings: which
implementation of a command/man-page... to use by default when
several are available.

update-alternative --config java

Yup .. that's the part that worried me.

will select where the /etc/alternatives/java symbolic link will
point to (and /usr/bin/java is a symlink pointing to
/etc/alternatives/java).

update-alternative --list java

called by the suggested script, however only queries the
available registered alternatives (usually by package
installation script) for "java" without changing any setting.

Right. That's what I needed to hear.

Thanks,
Emil

···

A system administrator can also register more alternatives with
the --install option.

On this system:

$ update-alternatives --list java
/usr/bin/gij-4.6
/usr/lib/jvm/ia32-java-6-sun/jre/bin/java
/usr/lib/jvm/java-6-sun/jre/bin/java
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

Of which only the 3rd will work correctly with jitsi.

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31