testing the debian package


#1

Hello again Martin,

I've just done my first try of SIP Communicator's debian package and its generator.

Excellent work! I didn't experience any serious problem building the package and was able to rapidly install and run SC! You've really done a great job!

While testing the package I've added some modifications/improvements that I found appropriate. Please let me know whether you are ok with all of them.

The following might also be of interest to other package maintainers.

First I've set .sip-communicator/log to be the official logging directory for installed versions of sip-communicator (as opposed to those run directly from the cvs sandbox). I therefore needed to add a

     mkdir -p ~/.sip-communicator/log

line in sip-communicator.sh cause apparently the java.util.logging logger does not create automatically.

I also had to add sc-bundles/util.jar to the classpath (again in sip-communicator.sh) as it contains the ScLogFormatter which is used for all sip-communicator logging. Without this all file logs get printed in xml and console logs do not have the standard SIP Communicator format.

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

Again in sip-communicator.sh i've added an "export" line for LD_LIBRARY_PATH in order to make sure that JMF .so's are usable by SC.

I've removed the better part of the jars in /usr/share/sc/lib as they are already included in the bundles that are using them. This also goes for liblog4j and libbcprov so I've removed the dependencies that the package had on them. I've therefore modified the rules script so that it would only copy those libs that are necessary.

This situation is kind of unclear however. I think it would be better to simply designate directories that contain shared jars and others that only contain bundle specific jars so that we could avoid having all package maintainers enumerate them one by one.

Anyways, a thing worth mentioning here is the fact that removing all these jars has brought the package size down to 5.5M

I also had to add jmf.jar to the classpath (sip-communicator.sh) and change default values for some log4j properties used in one of the packages.

Well, I think that's all. Let me know if you find any problems with my changes (I apologize if you do!).

Once you confirm they are ok, I'll add them to the cruisecontrol build so that they get generated on every CC build and uploaded to a location of you choice (a SC debian repo? :wink: )

Thanks again for the great work Martin.

Emil


#2

Emil Ivov wrote:

Again in sip-communicator.sh i've added an "export" line for LD_LIBRARY_PATH in order to make sure that JMF .so's are usable by SC.

Is this needed in the linux and windows installations. There I just change the PATH, which reflects java.library.path I think.

I also had to add jmf.jar to the classpath (sip-communicator.sh) and change default values for some log4j properties used in one of the packages.

Why is jmf.jar included? I think its not necessary.

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

sorry for my poor reactivity on the deb package... i was taken by something else.

I agree with all your modifications, however i put some comments inline.

Emil Ivov wrote:

First I've set .sip-communicator/log to be the official logging directory for installed versions of sip-communicator (as opposed to those run directly from the cvs sandbox). I therefore needed to add a

    mkdir -p ~/.sip-communicator/log

line in sip-communicator.sh cause apparently the java.util.logging logger does not create automatically.

I agree. Concerning the logs, are they incremental or they are overwritten for each session of the SC? I strongly prefer the latter choice.

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

Great. BTW, I was planning to add the control of the log level console output through the script that launch the SIP Communicator.

This situation is kind of unclear however. I think it would be better to simply designate directories that contain shared jars and others that only contain bundle specific jars so that we could avoid having all package maintainers enumerate them one by one.

I agree.
Talking about bundles, what about using the ~/.sip-communicator/plugins for the deployment as you suggested in another mail?

Anyways, a thing worth mentioning here is the fact that removing all these jars has brought the package size down to 5.5M

Hey, it is generally good to loose fat before the christmas season.

Once you confirm they are ok, I'll add them to the cruisecontrol build so that they get generated on every CC build and uploaded to a location of you choice (a SC debian repo? :wink: )

I will prepare a debian repository on download.java.net (just like where the Macosx nightly build is) and we can have a fresh development package of the SC every day via apt-get.

Martin

···

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Emil,

Some questions for the MacOSX packages.

Emil Ivov wrote:

First I've set .sip-communicator/log to be the official logging directory for installed versions of sip-communicator (as opposed to those run directly from the cvs sandbox). I therefore needed to add a

    mkdir -p ~/.sip-communicator/log

line in sip-communicator.sh cause apparently the java.util.logging logger does not create automatically.

The MacOSX package has the same issue. Unfortunately, I did not find a
way to create a specific directory when the package is installed
(because installing a package is just a drag'n drop).

One solution could be to store the logs inside the macosx application (a
mac application is actually a directory that you can browse).

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

For the solution I proposed above, I would need a specific
logging.properties (but I guess we could store it in
resources/install/macosx)

I've removed the better part of the jars in /usr/share/sc/lib as they are already included in the bundles that are using them. This also goes for liblog4j and libbcprov so I've removed the dependencies that the package had on them. I've therefore modified the rules script so that it would only copy those libs that are necessary.

Thanks for the hints. The patch sent in my previous mail (about
sip-communicator.version) includes some modifications to the build.xml
to reduce the macosx package size (the DMG is now around 8Mo)

Thanks,

···

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hello Damencho,

Damian Minkov wrote:

Emil Ivov wrote:

Again in sip-communicator.sh i've added an "export" line for LD_LIBRARY_PATH in order to make sure that JMF .so's are usable by SC.

Is this needed in the linux and windows installations. There I just change the PATH, which reflects java.library.path I think.

Yes that's right. Windows uses PATH for loading shared libs (dll-s) and hence that's the directory that java uses for initializing java.library.path.

I also had to add jmf.jar to the classpath (sip-communicator.sh) and change default values for some log4j properties used in one of the packages.

Why is jmf.jar included? I think its not necessary.

You are right! I've removed it.

I also noticed that I've missed out the BrowserLauncher2.jar lib. It is not included in a bundle because it is used by more than one so it needs to be inside lib and in the system classpath.

I've modified rules and sip-communicator.sh accordingly.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Martin,

Martin Andr� wrote:

Hi Emil,

sorry for my poor reactivity on the deb package... i was taken by something else.

I agree with all your modifications, however i put some comments inline.

Emil Ivov wrote:

First I've set .sip-communicator/log to be the official logging directory for installed versions of sip-communicator (as opposed to those run directly from the cvs sandbox). I therefore needed to add a

    mkdir -p ~/.sip-communicator/log

line in sip-communicator.sh cause apparently the java.util.logging logger does not create automatically.

I agree. Concerning the logs, are they incremental or they are overwritten for each session of the SC? I strongly prefer the latter choice.

Every session starts a new log. You are right, incremental logging would easily produce GBs of log files.

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

Great. BTW, I was planning to add the control of the log level console output through the script that launch the SIP Communicator.

Sure. That could be interesting.

This situation is kind of unclear however. I think it would be better to simply designate directories that contain shared jars and others that only contain bundle specific jars so that we could avoid having all package maintainers enumerate them one by one.

I agree.

OK Then I guess we could have something like this:

* sip-communicator/lib - bundle specific libs (i.e. included in the bundle jars)
* sip-communicator/lib/share - bundles that need to remain in the classpath on runtime
* sip-communicator/lib/native/osname - native shared libs.

If you agree, could you start an issue on this please?

Talking about bundles, what about using the ~/.sip-communicator/plugins for the deployment as you suggested in another mail?

Yes. I tried this one but there seems to be no direct way of telling Felix that our profile directory is in a location relative to the user home. At least I didn't find any. I can see a work around but it needs to be tested, especially on non-unix OSs.

The code that handles this in Felix is located in org.apache.felix.framework.cache.BundleCache (grep for user.home)

// First, determine the location of the cache directory; it
// can either be specified or in the default location.
String cacheDirStr = m_cfg.get(CACHE_DIR_PROP);
if (cacheDirStr == null)
{
    // Since no cache directory was specified, put it
    // ".felix" in the user's home by default.
    cacheDirStr = System.getProperty("user.home");
    cacheDirStr = cacheDirStr.endsWith(File.separator)
        ? cacheDirStr : cacheDirStr + File.separator;
    cacheDirStr = cacheDirStr + CACHE_DIR_NAME;
}

As you see the only way to make Felix use the user.home is to not specify a profile directory. We could however specify .sip-communicator/plugins as a profile name and that should put bundles where we want them. I haven't tested this yet and don't know whether the slash would properly work on windows. Perhaps we should consult the Felix guys before trying this. Maybe they'd agree to add support for "%h" or "~" in the profile dir string.

Anyways, a thing worth mentioning here is the fact that removing all these jars has brought the package size down to 5.5M

Hey, it is generally good to loose fat before the christmas season.

Once you confirm they are ok, I'll add them to the cruisecontrol build so that they get generated on every CC build and uploaded to a location of you choice (a SC debian repo? :wink: )

I will prepare a debian repository on download.java.net (just like where the Macosx nightly build is) and we can have a fresh development package of the SC every day via apt-get.

Oh how great! I am looking very forward to this :wink:

Incidentally, any idea on what it takes to have this in debian's official repositories?

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hello Romain,

Romain KUNTZ wrote:

Hi Emil,

Some questions for the MacOSX packages.

Emil Ivov wrote:

First I've set .sip-communicator/log to be the official logging directory for installed versions of sip-communicator (as opposed to those run directly from the cvs sandbox). I therefore needed to add a

    mkdir -p ~/.sip-communicator/log

line in sip-communicator.sh cause apparently the java.util.logging logger does not create automatically.

The MacOSX package has the same issue. Unfortunately, I did not find a
way to create a specific directory when the package is installed
(because installing a package is just a drag'n drop).

Well I am doing the mkdir -p on launch and not during the installation. Would this work for mac?

One solution could be to store the logs inside the macosx application (a
mac application is actually a directory that you can browse).

Sure. If the default mac configuration allows non-root users to write in there then this would be the simplest way to handle the issue.

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

For the solution I proposed above, I would need a specific
logging.properties (but I guess we could store it in
resources/install/macosx)

Sure.

I've removed the better part of the jars in /usr/share/sc/lib as they are already included in the bundles that are using them. This also goes for liblog4j and libbcprov so I've removed the dependencies that the package had on them. I've therefore modified the rules script so that it would only copy those libs that are necessary.

Thanks for the hints. The patch sent in my previous mail (about
sip-communicator.version) includes some modifications to the build.xml
to reduce the macosx package size (the DMG is now around 8Mo)

Yes, great! I've just applied it.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi again,

I just thought about something.

> Talking about bundles, what about using the ~/.sip-communicator/plugins
> for the deployment as you suggested in another mail?

Yes. I tried this one but there seems to be no direct way of telling
Felix that our profile directory is in a location relative to the user
home. At least I didn't find any. I can see a work around but it needs
to be tested, especially on non-unix OSs.

The code that handles this in Felix is located in
org.apache.felix.framework.cache.BundleCache (grep for user.home)

> // First, determine the location of the cache directory; it
> // can either be specified or in the default location.
> String cacheDirStr = m_cfg.get(CACHE_DIR_PROP);
> if (cacheDirStr == null)
> {
> // Since no cache directory was specified, put it
> // ".felix" in the user's home by default.
> cacheDirStr = System.getProperty("user.home");
> cacheDirStr = cacheDirStr.endsWith(File.separator)
> ? cacheDirStr : cacheDirStr + File.separator;
> cacheDirStr = cacheDirStr + CACHE_DIR_NAME;
> }

As you see the only way to make Felix use the user.home is to not
specify a profile directory. We could however specify
.sip-communicator/plugins as a profile name and that should put bundles
where we want them. I haven't tested this yet and don't know whether the
slash would properly work on windows. Perhaps we should consult the
Felix guys before trying this. Maybe they'd agree to add support for
"%h" or "~" in the profile dir string.

Specifying .sip-communicator/plugins as a profile name isn't good
enough because it would again put the repository inside ~/.felix. We
are currently chatting with Pavel and he suggested that we should try
setting a profile_name of ../.sip-communicator/plugins. This might
work. Pavel said he'll try and share the results on this list.

Crossing my fingers.

Emil

P.S. We should really send a mail to the felix-dev list, describing
the situation.

···

On 12/3/06, Emil Ivov <emcho@emcho.com> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi

I have un subscribed from this mailing list twice now
and keep getting these emails.

Please un subscribe me.

Thanks

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Emil,

Emil Ivov wrote:

The MacOSX package has the same issue. Unfortunately, I did not find a
way to create a specific directory when the package is installed
(because installing a package is just a drag'n drop).

Well I am doing the mkdir -p on launch and not during the installation. Would this work for mac?

I did not manage to find a way to execute shell commands at execution time. Maybe there is a way to do so, I'll go on investigating that.

One solution could be to store the logs inside the macosx application (a
mac application is actually a directory that you can browse).

Sure. If the default mac configuration allows non-root users to write in there then this would be the simplest way to handle the issue.

Yes, non-root users can write inside the application directory.
The only issue I see is that if multiple users execute sip-communicator on the same machine, there may be a problem with the lock on the logs.

But in the meantime, the following solution will allow to get logs from the users:

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

For the solution I proposed above, I would need a specific
logging.properties (but I guess we could store it in
resources/install/macosx)

Sure.

I have done the same than for the felix.properties:
- a sed file (logging.properties.sed) to add in resources/install/macosx
- a patch to apply to the build.xml to prepare the logging.properties specific to macosx

(this patch assumes that the previous patch I re-sent this morning have been applied).

Thanks,

logging.properties.sed (117 Bytes)

build.xml-20061218-log-macosx.diff (1.34 KB)

···

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp


#11

Hello Everyone,

Sorry for the late reply. Unfortunately, the idea of having
felix.cache.profile=../.sip-communicator/plugins didn't work. Here's the output:

Welcome to Felix.

···

=================

Error creating bundle cache:
java.lang.IllegalArgumentException: The profile name cannot contain the file separator character.
        at org.apache.felix.framework.cache.BundleCache.initialize(BundleCache.java:305)
        at org.apache.felix.framework.cache.BundleCache.<init>(BundleCache.java:99)
        at org.apache.felix.framework.Felix.start(Felix.java:248)
        at org.apache.felix.main.Main.main(Main.java:208)

--Pavel Tankov

--- Emil Ivov <emcho@emcho.com> wrote:

Hi again,

I just thought about something.

On 12/3/06, Emil Ivov <emcho@emcho.com> wrote:
> > Talking about bundles, what about using the ~/.sip-communicator/plugins
> > for the deployment as you suggested in another mail?
>
> Yes. I tried this one but there seems to be no direct way of telling
> Felix that our profile directory is in a location relative to the user
> home. At least I didn't find any. I can see a work around but it needs
> to be tested, especially on non-unix OSs.
>
> The code that handles this in Felix is located in
> org.apache.felix.framework.cache.BundleCache (grep for user.home)
>
> > // First, determine the location of the cache directory; it
> > // can either be specified or in the default location.
> > String cacheDirStr = m_cfg.get(CACHE_DIR_PROP);
> > if (cacheDirStr == null)
> > {
> > // Since no cache directory was specified, put it
> > // ".felix" in the user's home by default.
> > cacheDirStr = System.getProperty("user.home");
> > cacheDirStr = cacheDirStr.endsWith(File.separator)
> > ? cacheDirStr : cacheDirStr + File.separator;
> > cacheDirStr = cacheDirStr + CACHE_DIR_NAME;
> > }
>
>
> As you see the only way to make Felix use the user.home is to not
> specify a profile directory. We could however specify
> .sip-communicator/plugins as a profile name and that should put bundles
> where we want them. I haven't tested this yet and don't know whether the
> slash would properly work on windows. Perhaps we should consult the
> Felix guys before trying this. Maybe they'd agree to add support for
> "%h" or "~" in the profile dir string.

Specifying .sip-communicator/plugins as a profile name isn't good
enough because it would again put the repository inside ~/.felix. We
are currently chatting with Pavel and he suggested that we should try
setting a profile_name of ../.sip-communicator/plugins. This might
work. Pavel said he'll try and share the results on this list.

Crossing my fingers.

Emil

P.S. We should really send a mail to the felix-dev list, describing
the situation.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hi,

I have committed those patches (for the MacOSX package), so I confirm that I can commit to the CVS :slight_smile:

Thanks,
Romain

Romain KUNTZ wrote:

···

Hi Emil,

Emil Ivov wrote:

The MacOSX package has the same issue. Unfortunately, I did not find a
way to create a specific directory when the package is installed
(because installing a package is just a drag'n drop).

Well I am doing the mkdir -p on launch and not during the installation. Would this work for mac?

I did not manage to find a way to execute shell commands at execution time. Maybe there is a way to do so, I'll go on investigating that.

One solution could be to store the logs inside the macosx application (a
mac application is actually a directory that you can browse).

Sure. If the default mac configuration allows non-root users to write in there then this would be the simplest way to handle the issue.

Yes, non-root users can write inside the application directory.
The only issue I see is that if multiple users execute sip-communicator on the same machine, there may be a problem with the lock on the logs.

But in the meantime, the following solution will allow to get logs from the users:

I've created a new instance of the logging.properties file and have added it to resources/install for use by all installers (that's one of the points that other package maintainers may be interested in). This instance of logging.properties has a reduced log level for console logs and stores log files inside the ~/.sip-communicator/log directory.

For the solution I proposed above, I would need a specific
logging.properties (but I guess we could store it in
resources/install/macosx)

Sure.

I have done the same than for the felix.properties:
- a sed file (logging.properties.sed) to add in resources/install/macosx
- a patch to apply to the build.xml to prepare the logging.properties specific to macosx

(this patch assumes that the previous patch I re-sent this morning have been applied).

Thanks,

------------------------------------------------------------------------

s/java.util.logging.FileHandler.pattern\ =\ %h\/.sip-communicator\/log/java.util.logging.FileHandler.pattern\ =\ log/

------------------------------------------------------------------------

--- sip-communicator/build.xml 2006-12-18 15:47:24.000000000 +0900
+++ sip-communicator-20061218-log-fixed/build.xml 2006-12-18 15:38:06.000000000 +0900
@@ -331,6 +331,15 @@
                 trim="true"/>
       </condition>
+ <!-- Prepare the logging.properties file for macosx -->
+ <exec executable="/usr/bin/sed" + dir="${basedir}"
+ input="${inst.resrc}/logging.properties"
+ output="${macosx.resrc.dir}/logging.properties">
+ <arg value="-f"/>
+ <arg value="${macosx.resrc.dir}/logging.properties.sed"/>
+ </exec>
+
       <!-- Prepare the felix.client.run.properties file for macosx -->
       <exec executable="/usr/bin/sed" dir="${basedir}"
@@ -384,11 +393,12 @@
           <include name="${bundles.dest.macosx}/*.jar" />
           <exclude name="${bundles.dest}/*-slick.jar" />
         </jarfileset>
- <javafilelist dir="${lib}" files="logging.properties"/>
+ <javafilelist dir="${macosx.resrc.dir}" files="logging.properties"/>
         <javafilelist dir="${macosx.resrc.dir}"
                       files="felix.client.run.properties"/>
        </jarbundler>
+ <mkdir dir="${macosx.app.dir}/${macosx.app.name}-${sip-communicator.version}.app/Contents/Resources/Java/log"/>
     </target>
      <!-- Create the DMG - This only works on MacOSX (need hdiutil) -->

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@sfc.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net