Debian package for SC

Hi all,

I've just commited the necessary files to build a debian
package for the
SIP Communicator. I've also updated the ant build.xml file
to add a 
"deb" task to easily create a Debian package. This
task depends on the 
"make" task and will be skipped if the needed
tools (dpkg-buildpackage) 
are not found. The Debian package are available under
release/debian.

Are there any volunteers running Debian willing to test the
package?

Cheers,
Martin

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Martin,

I've tested the debian package everything works fine. builds
(after 
install dependencies) and installs ok.

There are some exceptions but they are not connected to the
debian package.

The one exception is if you run SC under root a directory 
/tmp/sip-communicator.bin which is not usable if you run
then
from normal user - Exception Access Denied is thrown.

Martin André wrote:
> Hi all,
>
> I've just commited the necessary files to build a
debian package for the
> SIP Communicator. I've also updated the ant build.xml
file to add a 
> "deb" task to easily create a Debian package.
This task depends on the 
> "make" task and will be skipped if the needed
tools 
> (dpkg-buildpackage) are not found. The Debian package
are available 
> under release/debian.
>
> Are there any volunteers running Debian willing to test
the package?
>
> Cheers,
> Martin
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hey Damian,

Damian Minkov wrote:
> Hi Martin,
> 
> I've tested the debian package everything works fine.
builds (after 
> install dependencies) and installs ok.
> 
> There are some exceptions but they are not connected to
the debian package.
> 
> The one exception is if you run SC under root a
directory 
> /tmp/sip-communicator.bin which is not usable if you
run then
> from normal user - Exception Access Denied is thrown.

Good catch. Actually, the current behavior (from the cvs
source) for 
oscar is to deploy its bundles in the current directory in a

sip-communicator.bin directory. Because the package installs
the files 
under /usr/share/sip-communicator, it is impossible for a
normal user to 
write here. So i changed the destination to /tmp. but didn't
though at 
the multiuser issue. I changed the behavior to have the
default oscar 
one, ie deploy in ~/.noscar/sip-communicator.bin.

Thanks,
Martin

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Martin,

I am afraid that storing bundles in the ~/.noscar directory
could lead 
to another problem. I am not sure that oscar would update (I
actually 
believe it won't) update installed bundles after you upgrade
your 
sip-communicator with an apt-get update. In other words, the
/usr/share 
directory will be upgraded but this won't change anything
for the user 
after they restart their sip-communicator.

This adds up to the fact that keeping duplicates of the SIP
Communicator 
on the user machine does not sound quite right.

We'd have to think of something else like for example
distributing the 
oscar repository itself and configuring oscar to install
only newly 
downloaded bundles/plugins in the user home and keeping the
rest in 
/usr/share.

Any ideas?

Emil

Martin André wrote:
> Hey Damian,
> 
> Damian Minkov wrote:
>> Hi Martin,
>>
>> I've tested the debian package everything works
fine. builds (after 
>> install dependencies) and installs ok.
>>
>> There are some exceptions but they are not
connected to the debian package.
>>
>> The one exception is if you run SC under root a
directory 
>> /tmp/sip-communicator.bin which is not usable if
you run then
>> from normal user - Exception Access Denied is
thrown.
> 
> Good catch. Actually, the current behavior (from the
cvs source) for 
> oscar is to deploy its bundles in the current directory
in a 
> sip-communicator.bin directory. Because the package
installs the files 
> under /usr/share/sip-communicator, it is impossible for
a normal user to 
> write here. So i changed the destination to /tmp. but
didn't though at 
> the multiuser issue. I changed the behavior to have the
default oscar 
> one, ie deploy in ~/.noscar/sip-communicator.bin.
> 
> Thanks,
> Martin
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Emil,

Emil Ivov wrote:
> Hi Martin,
> 
> I am afraid that storing bundles in the ~/.noscar
directory could lead 
> to another problem. I am not sure that oscar would
update (I actually 
> believe it won't) update installed bundles after you
upgrade your 
> sip-communicator with an apt-get update. In other
words, the /usr/share 
> directory will be upgraded but this won't change
anything for the user 
> after they restart their sip-communicator.
> 
> This adds up to the fact that keeping duplicates of the
SIP Communicator 
> on the user machine does not sound quite right.

Hmmm, you're right... as usual 

> We'd have to think of something else like for example
distributing the 
> oscar repository itself and configuring oscar to
install only newly 
> downloaded bundles/plugins in the user home and keeping
the rest in 
> /usr/share.
> 
> Any ideas?

This seems good to me. I'll look if this is possible to do
such thing 
with Oscar.

BTW, do someone know other projects using oscar? How are
they packaged 
under multi-users OS?

Martin

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hello Martin,

Anything new on the multi user issue?

Incidentally, I wanted to ask you something. Wouldn't it be
nice to add 
a dependency on libaoss for the sip-communicator .deb
package and launch 
it with LD_PRELOAD set to /usr/lib/libaoss.so ?

Since JavaSound uses OSS, as soon as it opens the sound
device it hogs 
on it (at best) or fails if another app is already using it.
This 
happens for both sound notifications and rendering incoming
audio 
streams. Since recently (I don't know when exactly), alsa
have enabled 
dmix and dsnoop by default for non-multichannel sound cards
so it would 
be enough to make the sip-communicator use Alsa. This would 
automatically resolve the multiple access issue.

I've been using the SIP Communicator with libaoss lately and
it works 
really fine.

WDYT?

Emil

Martin André wrote:
> Hi Emil,
> 
> Emil Ivov wrote:
>> Hi Martin,
>>
>> I am afraid that storing bundles in the ~/.noscar
directory could lead 
>> to another problem. I am not sure that oscar would
update (I actually 
>> believe it won't) update installed bundles after
you upgrade your 
>> sip-communicator with an apt-get update. In other
words, the /usr/share 
>> directory will be upgraded but this won't change
anything for the user 
>> after they restart their sip-communicator.
>>
>> This adds up to the fact that keeping duplicates of
the SIP Communicator 
>> on the user machine does not sound quite right.
> 
> Hmmm, you're right... as usual 
> 
>> We'd have to think of something else like for
example distributing the 
>> oscar repository itself and configuring oscar to
install only newly 
>> downloaded bundles/plugins in the user home and
keeping the rest in 
>> /usr/share.
>>
>> Any ideas?
> 
> This seems good to me. I'll look if this is possible to
do such thing 
> with Oscar.
> 
> BTW, do someone know other projects using oscar? How
are they packaged 
> under multi-users OS?
> 
> Martin
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Emil,

Emil Ivov wrote:
> Hello Martin,
> 
> Anything new on the multi user issue?

No, not yet. I saw you commited to the cvs many things
recently (looks 
like we are really close to the first beta release ;)). I
will check if 
there is no incidence on the debian package build and will
search for a 
solution for the multi user issue by the end of the week.

> Incidentally, I wanted to ask you something. Wouldn't
it be nice to add 
> a dependency on libaoss for the sip-communicator .deb
package and launch 
> it with LD_PRELOAD set to /usr/lib/libaoss.so ?
> 
> Since JavaSound uses OSS, as soon as it opens the sound
device it hogs 
> on it (at best) or fails if another app is already
using it. This 
> happens for both sound notifications and rendering
incoming audio 
> streams. Since recently (I don't know when exactly),
alsa have enabled 
> dmix and dsnoop by default for non-multichannel sound
cards so it would 
> be enough to make the sip-communicator use Alsa. This
would 
> automatically resolve the multiple access issue.
> 
> I've been using the SIP Communicator with libaoss
lately and it works 
> really fine.
> 
> WDYT?

Well if you tell me that it works fine, I have absolutely no
objection 
to add a dependency on the alsa-oss package (containing
libaoss). I will 
check it.

Martin

> Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net