Create Ubuntu/Debian package

I've created a package and uploaded it to my webspace at http://homepages.uni-paderborn.de/wienczny/
The package has been built on ubuntu edgy but should work on any debian-distro with sun-java5-jdk packages in their repository.
Please have a look at it...

Attached latest Debian patch, which needs to be applied.

Matt, why did you attach that old version of my patch?
I have made huge improvements since then.
The current version of my patch can be found at https://dev.mobr.de/openfire/.

Moritz,

My apologies and thanks for pointing out that I attached the wrong patch version! I'll follow the link when applying the work.

-Matt

Hi,

i'm a Debian developer and (soon) an openfire user.

If you are interested in getting openfire into the official Debian & Ubuntu repositories, I could help you.

Just contact me at lucas@debian.org

Hi,

you can find our effort in the svn repository (/build/debian). There are still some bugs which have to be solved. The current package is buildable in two ways:
1. from tar.gz
2. from svn which uses 1. for building.

There are still some bugs in the package, which have to be solved before release. Ask Moritz about them.

OK, here are some comments.

First, it is generally a bad idea to maintain the debian-specific parts inside
the upstream source. If there's a bug in the packaging part, what will you do ?
Ask upstream to release a new version just for Debian ?

The best thing to do is to maintain the package in its own repository, or its
own subdirectory, preferably a repository where I could commit, if I'm the one
signing+uploading. (I'm not sure if it's the case of svn co
http://svn.igniterealtime.org/svn/repos/). http://alioth.debian.org/ provides
nice services.

Also, it usually sounds like a good idea to integrate with upstream build
scripts, but in reality, it usually causes more problems than benefits. Just
working from the released .tar.gz files works much better.

Regarding organization, I can help with the debian-specific stuff, but I would
prefer to only "sponsor" the package (double-check it, sign it, and upload it
to Debian) (I can also upload to Ubuntu). That means that one of you will be
listed as the Maintainer (others can be listed as "Uploaders", that is,
co-maintainers). That also mean that you are the ones responsible for dealing
with the bugs reported to the Debian Bug Tracking System (my Java is not very good, by the way).

Now, some comments about what you already did.
Generally, it looks very good. I like cdbs.

debian/changelog:
+ please don't integrate with upstream's build scripts (see above)
+ version should be <upstream version>-<debian version>. 3.3.1-1 to start, probably.
+ this changelog is the debian changelog: you only mark here what's specific to Debian, so no need to point to the full changelog.

debian/control:
+ sun-java5: can you switch to sun-java6, or would that cause problems ?

debian/copyright:
You should make it clear whether it's GPL v2 or later, GPL V2, or GPL (any version).
There are files in the archive which are not covered by the GPL. You have to list all cases in debian/copyright. There are files under LGPL, MIT and Apache 2.0, at least.
Also, we have a problem with the icons, which are non-free. Is it possible to replace them with some free icons ? If not, I'll have to ask if it's OK to distribute openfire in the "non-free" section of Debian.
Finally, some tests seem to be proprietary (see files in src/test/java/org/jivesoftware/util/ and src/test/throttletest/src/org/jivesoftware/openfire/test/throttle/).

[upstream problem] If possible, include the original text for the GPL in the archive. It makes it easier to check that it was not modified.

debian/openfire.postinst:
you use adduser, so you have to Depends on adduser.

debian/patches/11-unwritable-home.patch:
I'm not sure I understand what's that for ?

debian/postinst:
stale file ?

debian/rules:
Couldn't you change the install/openfire target to use an openfire.install file for dh_install instead ?

That's all for now

The package was not yet intended for inclusion into any distribution. It was build to make it possible for the jive guys to put a deb on their homepage for each release. If you want to help us to get into the major "deb"-Distributions this would be great.

Things, that additionally to those noted in your review, have to be done:

• use java dependencies from Debian/Ubuntu repository instead of those included with the tar.gz. Change the CLASSPATH to do that.
• Fix the bug that renders the package not buildable when openfire is installed on the system. (Something about /etc/openfire and symlinks) Reason not yet clear.

Java6 should work fine. It was not yet available on Ubuntu when the package was created.

The patch should be be applied to upstream or fixed by some different implementation. Openfire assumes that it has a directory with subdirs that it's the owner of and that it can write to. To comply with FHS the deb distributes openfire on different locations. This causes a check to fail that checks for write access in the root-directory of openfire. This check is disabled by the patch. To fix the underlying problem upstream should check every directory it really needs to write to.

debian/postinst is stale. It was not yet removed from the repo.

What should be done to create a package on alioth?

> The package was not yet intended for inclusion into any distribution. It was build to make it possible for the jive guys to put a deb on their homepage for each release. If you want to help us to get into the major "deb"-Distributions this would be great.

Yup, I can help you with that.

> Things, that additionally to those noted in your review, have to be done:
>
> * use java dependencies from Debian/Ubuntu repository instead of those included with the tar.gz. Change the CLASSPATH to do that.

Ah, I didn't notice that. As I said, I'm not at all a java specialist
(but I know XMPP/Jabber quite well)

> * Fix the bug that renders the package not buildable when openfire is installed on the system. (Something about /etc/openfire and symlinks) Reason not yet clear.
>
> Java6 should work fine. It was not yet available on Ubuntu when the package was created.
>
> The patch should be be applied to upstream or fixed by some different implementation. Openfire assumes that it has a directory with subdirs that it's the owner of and that it can write to. To comply with FHS the deb distributes openfire on different locations. This causes a check to fail that checks for write access in the root-directory of openfire. This check is disabled by the patch. To fix the underlying problem upstream should check every directory it really needs to write to.

Ok, that's fine. Could you document that in a comment in the patch ?

> What should be done to create a package on alioth?

The first step is to have a source package with:

• an _orig.tar.gz file
• a diff.gz file
• a dsc file
  (that means that the debian dir must be outside the sources)

then that package can be "injected" into the collab-maint repository.
and then, you can create an account on alioth and request to be added to
collab-maint, so you get commit rights.

Ive created a list of openfire dependencies:

• is not in the repository
  +is in the repository
  ? unsure about what library this acutally is

-./src/web/WEB-INF/lib/dwr.jar
-./src/test/throttletest/build/lib/smackx.jar
-./src/test/throttletest/build/lib/smack.jar
-./src/plugins/userImportExport/lib/isorelax.jar
-./src/plugins/userImportExport/lib/msv.jar
+./src/plugins/userImportExport/lib/commons-fileupload-1.0.jar
+./src/plugins/userImportExport/lib/relaxngDatatype.jar librelaxng-datatype-java
-./src/plugins/userImportExport/lib/xsdlib.jar
-./src/plugins/gateway/lib/irclib.jar moepii.sf.net
-./src/plugins/gateway/lib/jml.jar jml.sf.net
+./src/plugins/gateway/lib/wsdl4j.jar
+./src/plugins/gateway/lib/jaxrpc.jar libaxis-java
-./src/plugins/gateway/lib/smackx.jar
-./src/plugins/gateway/lib/smack.jar
-./src/plugins/gateway/lib/dwr.jar getahead.ltd.uk
-./src/plugins/gateway/lib/joscar-protocol.jar
+./src/plugins/gateway/lib/commons-discovery.jar libcommons-discovery-java
+./src/plugins/gateway/lib/xercesImpl.jar libxerces2-java
+./src/plugins/gateway/lib/axis.jar libaxis-java
-./src/plugins/gateway/lib/joscar-client.jar
-./src/plugins/gateway/lib/cindy.jar cindy.sf.net
?./src/plugins/gateway/lib/xml-apis.jar libxalan2-java libtomcat5-java libtomcat5.5-java
-./src/plugins/gateway/lib/picocontainer.jar picocontainer.org
-./src/plugins/gateway/lib/ymsg_network.jar
-./src/plugins/gateway/lib/joscar-common.jar
+./src/plugins/gateway/lib/saaj.jar libaxis-java
-./src/plugins/gateway/lib/ymsg_support.jar
?./build/lib/dist/activation.jar glassfish libnurjaf-java roxen4
?./build/lib/dist/servlet.jar roxen4.jar
?./build/lib/dist/jtds.jar
?./build/lib/dist/mail.jar
-./build/lib/dist/bouncycastle.jar
+./build/lib/dist/hsqldb.jar libhsqldb-java
-./build/lib/dist/postgres.jar
+./build/lib/dist/mysql.jar libmysql-java
-./build/lib/dist/jdic.jar
-./build/lib/merge/mina-filter-ssl-1.2.0.jar
+./build/lib/merge/commons-codec.jar libcommons-codec-java
-./build/lib/merge/mina-filter-compression-1.2.0.jar
-./build/lib/merge/jetty-util.jar
-./build/lib/merge/slf4j-api-1.1.0.jar
-./build/lib/merge/sitemesh.jar
+./build/lib/merge/xpp3.jar libxpp3-java
+./build/lib/merge/jaxen.jar libjaxen-java
-./build/lib/merge/stringprep.jar
-./build/lib/merge/jetty.jar
-./build/lib/merge/jstun-0.6.1.jar
?./build/lib/merge/jstl.jar tomcat5-webapps tomcat5.5-webapps
-./build/lib/merge/mina-core-1.2.0.jar
?./build/lib/merge/standard.jar tomcat5-webapps tomcat5.5-webapps
+./build/lib/merge/jzlib.jar libjzlib-java
J./build/lib/merge/dbutil.jar
-./build/lib/merge/slf4j-simple-1.1.0.jar
+./build/lib/merge/jsp-api.jar libservlet2.4-java libtomcat5-java libtomcat5.5-java
+./build/lib/merge/commons-httpclient.jar
-./build/lib/merge/commons-logging.jar
-./build/lib/merge/jmdns.jar
-./build/lib/merge/shaj.jar
-./build/lib/merge/dom4j.jar
?./build/lib/jasper-compiler.jar libtomcat5-java libtomcat5.5-java
-./build/lib/qdox.jar
+./build/lib/commons-el.jar libcommons-el-java
-./build/lib/ant-jive-edition.jar
?./build/lib/jasper-runtime.jar libtomcat5-java
-./build/lib/i4jruntime.jar
-./build/lib/pack200task.jar
+./build/lib/ant.jar ant
-./build/lib/xmltask.jar
+./build/lib/junit.jar junit
-./build/lib/ant-subdirtask.jar
-./build/lib/ant-contrib.jar

Lucas do you know somebody from the debian-java-team? They could be interested in helping us...

Hi,

I've met Thomas Girard <thomas.g.girard@free.fr>, who might be able to help.

But the best solution might be to simply mail the debian-java mailing list.

Hi,

i just wanted to test the debian package from svn, but had problems building the package.
basically i tried it like so:

1) checked out svn to /tmp/openfire
2) dpkg -b /tmp/openfire/build/debian openfire_svn_test.deb

but dpkg told me, that building the package is not possible. strangely enough i got no further errors.
did i miss anything important?

best,

Martin

Anything we can do do advance this?

I've just done a build using this and thought it would be useful to add details of what I've done in case it helps someone else.

a) ran unix2dos over various files - the postinst/postrm scripts in particular require it
b) added libcommons-el-java, junit, libqdox-java as build-depends (so that we can drop them from the source package)
c) added libcommons-el-java as binary package depends
d) added to rules file: "ln -sf ../../java/commons-el.jar $(OPENFIRE)/lib"
e) removed the space after "#!" in the postinst (personal habit - I believe something can be picky)
f) I had to regenerate the patches
g) and make the changelog a valid entry (replaced the @version@ and @builddate@ strings

From a Debian packaging PoV I suggest ripping out large chunks of the "source" tarball:
the 30MB+ JRE
build/macosx

and replacing the libraries with the ones already in debian where you can

I should say that I ended up with an empty admin-jsp.jar (the build didn't report a failure though)

It would be nice to suppress this warning on installation:
adduser: Warning: The home directory `/var/lib/openfire' does not belong to the user you are currently creating.

i'd really wish this feature would appear in a future version and not only scheduled for the next, the next, the next and the next release

=) I don't blame you for feeling that way, but I'll tell you that I have an extensive background in many flavors of unix and one of my first big tasks is to tackle good packages across the board. I plan on having this worked out for 3.4.2. (it would have been 3.4.1, but 3.4.1 ended up being an emergency release) So I guess the best I can tell you is it's coming very soon now!

I have the .deb built at this point. I am working with an Ubuntu team member to test things out and make sure it's a "good" package. =)

Hi Daniel,

Where could I download the package (source + binaries)?
I'd like to have a look at it.

Also, are you interested in getting it into Debian?

Hi Lucas! I don't have it in a location where it's downloadable yet. It's planned for 3.4.3. We were working with one of the Ubuntu folk to look over it and such. I don't have a .deb available at the moment that's built against an actual release of openfire. Just "the current trunk".

Are y'all interested in actually serving it off of Debian's repos? We are planning on setting up our own yum and debian repos for folk to point at so they can get immediate updates when new releases come out. Would it be preferrable to serve it directly off of Debian's repos? We did like the idea of being able to track number of downloads by serving it out of our own, plus we figured if we're willing to do it, why not take load off the main repos out there for debian and ubuntu. =) Anyway, let me know what you think. If you'd like to talk directly about it, I'm daniel.henninger@jivesoftware.com both in terms of JID and email address.

I am not a Debian user (any more ), but a Fedora one, and I would be interested in the native packaging of OpenFire as well. By native packaging I mean, a) IcedTea and ecj, b) nothing which is already in Fedora should be included in the package.

I have a question about the Debian effort. Are you guys building with IcedTea and/or ecj or previous Sun non-free versions? I have tested binary tar.gz on Fedora, and it works perfectly well with IcedTea JVM, but I have no clue about compilation.

At this time, I don't think we have any plans on supporting anything other than Sun's official JVMs. We had had no end to problems when folk tried to use Gnu's stuff, and really I don't know anything about IceaTea other than it appears to be more or less the same thing as Sun's JVM. Of course, Openfire uses at least one thing that's specifically a "sun proprietary library" ... which may or may not be in this IceaTea build. (Even Sun's own compilers warn not to use it, just haven't had time to work out an alternate method yet) Either way, the Debian issue probably isn't the best place to discuss this. ;D There's another Fedora related issue in the JIRA, but mostly Openfire Support or meet us in the weekly chat to discuss.

Hi,

I tried to continue this packaging effort so openfire can be available in Debian repository.

You will find the package I made at the following url:

http://debian.pleiades.fr.eu.org/unstable/openfire_3.5.1-1.diff.gz
http://debian.pleiades.fr.eu.org/unstable/openfire_3.5.1-1.dsc
http://debian.pleiades.fr.eu.org/unstable/openfire_3.5.1-1_all.deb
http://debian.pleiades.fr.eu.org/unstable/openfire_3.5.1-1_i386.changes
http://debian.pleiades.fr.eu.org/unstable/openfire_3.5.1.orig.tar.gz

I tried to use jar files provided by debian packages instead of the ones provided in the archive when possible.

Lucas, I will interested by your review of this package.

I still have some problems with the following files which don't seem have the opensource licence header.
Daniel, are these files really licensed under the GPL2 License ?

src/web/muc-room-create.jsp
src/web/muc-room-delete.jsp
src/web/muc-room-affiliations.jsp
src/web/muc-room-edit-form.jsp
src/web/server-db-stats.jsp
src/web/muc-room-summary.jsp
src/web/muc-room-occupants.jsp
src/plugins/fastpath/src/web/agent-selectors.jsp
src/plugins/fastpath/src/web/interceptors.jsp
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/AgentNotFoundException.java
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/spi/dispatcher/DbDispatcherInfoProvider.java
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/spi/routers/DefaultRouter.java
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/spi/routers/MetaDataRouter.java
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/spi/JiveLiveProperties.java
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/spi/BasicRequestFilterFactory.java
src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/AgentSessionList.java
src/plugins/fastpath/src/java/org/jivesoftware/openfire/fastpath/history/ChatTranscriptManager.java
src/plugins/presence/src/java/org/jivesoftware/openfire/plugin/presence/TextPresenceProvider.java
src/test/throttletest/src/org/jivesoftware/openfire/test/throttle/ThrottleTestWriter.java
src/test/throttletest/src/org/jivesoftware/openfire/test/throttle/ThrottleTestReader.java
src/test/java/org/jivesoftware/util/XMLPropertiesTest.java
src/test/java/org/jivesoftware/util/IntEnumTest.java
src/test/java/org/jivesoftware/util/XPPWriterTest.java
src/test/java/org/jivesoftware/util/STUNServerTest.java
src/java/org/jivesoftware/util/ModificationNotAllowedException.java
src/java/org/jivesoftware/util/log/util/JettyLog.java
src/java/org/jivesoftware/util/InputOutputStreamWrapper.java
src/java/org/jivesoftware/util/Log.java
src/java/org/jivesoftware/util/InitializationException.java
src/java/org/jivesoftware/util/InternalServerErrorException.java
src/java/org/jivesoftware/util/cache/CacheFactoryStrategy.java
src/java/org/jivesoftware/util/cache/CacheWrapper.java
src/java/org/jivesoftware/util/cache/ClusterTask.java
src/java/org/jivesoftware/util/cache/CacheFactory.java
src/java/org/jivesoftware/util/cache/DefaultCache.java
src/java/org/jivesoftware/util/JiveProperties.java
src/java/org/jivesoftware/util/CookieUtils.java
src/java/org/jivesoftware/openfire/filetransfer/proxy/ProxyOutputStream.java
src/java/org/jivesoftware/openfire/filetransfer/FileTransferInterceptor.java
src/java/org/jivesoftware/openfire/filetransfer/FileTransferRejectedException.java
src/java/org/jivesoftware/openfire/event/UserEventAdapter.java
src/java/org/jivesoftware/openfire/container/PluginIconServlet.java
src/java/org/jivesoftware/openfire/http/BoshBindingError.java
src/java/org/jivesoftware/openfire/update/DownloadStatus.java
src/java/org/jivesoftware/openfire/session/GetSessionsCountTask.java
src/java/org/jivesoftware/openfire/commands/admin/user/UserProperties.java
src/java/org/jivesoftware/openfire/commands/admin/user/AuthenticateUser.java
src/java/org/jivesoftware/openfire/commands/admin/user/AddUser.java
src/java/org/jivesoftware/openfire/commands/admin/HttpBindStatus.java
src/java/org/jivesoftware/openfire/commands/admin/muc/CreateMUCRoom.java
src/java/org/jivesoftware/openfire/commands/clearspace/ChangeSharedSecret.java
src/java/org/jivesoftware/openfire/launcher/Uninstaller.java

The i4jruntime.jar jar file seems also to not be opensource.

Howdy, I've updated all of the mentioned files (and then some) to show GPL instead of the old license. Was simply an oversite on our part. Regarding i4jruntime.jar, just remove it, you don't need it unless you were using the Install4j based setup.

So, what's different about your package than the one provided by us on ignite realtime?

Hi Daniel,

Thanks for the license header update !
Indeed I had already dropped i4runtime.jar as I don't need it for the debian package.

The only restricted files remaining are the icons and images. Are you planning to change the license of these files ? If not, I will probably have to replace them in the debian package.

Concerning the differences with the ignite realtime package, in the first package I first made, the difference were limited, mainly debian compliance stuffs.
But since, I submitted the package on the java mailing-list and I was asked to remove the jar files or to have them compiled at build time, so I am currently reworking the package so it uses jar provided by existing debian packages (like bouncycastle, xpp3, ...).

I have begin to package some that were missing (jmdns, jstun, ...).

In this, I would be interested by any specific change you made in the jar files you provided.

Indeed I am currently have some difficulties using mina which recently entered the debian archive [1].
It seems the ExecutorFilter getEventQueueSize function doesn't exist in upstream mina.
For now I temporarily removed the MINAStatCollector class (which seems to be only used by the LoadStat plugin) in order to continue working but that's a not a solution.

[1] http://packages.debian.org/source/sid/mina

I believe we are using trunk MINA due to a wealth of fixes it includes. Using an older MINA than what we included may cause some unforeseen issues. I don't have details, I just know we've updated from trunk a number of times after running into some issue, contacting the MINA devs, and getting a fix.

As for the icons and images — what are they licensed as right now?

Hi Daniel,

I check out mina branch 1.0, 1.1, 2.0.0-M3 and trunk and I can't find the getEventQueueSize in the source code.
Are you sure you don't use a patched version ?

I saw the versions.txt file in build/lib which tells the versions number of jar libraries. Is this file up to date so I can rely on it to decide if I can use the corresponding debian package ?

Concerning icons and images, they as licensed with the following license according to the README.html file:

Openfire contains icons and images licensed from INCORS GmbH. All other
images are owned by Jive Software. All icons and images in Openfire are
provided under the following license agreement:

License Agreement

This is a legal agreement between You, the User of the Openfire application
("The Software"), and Jive Software ("Jive Software"). By downloading the Software,
you agree to be bound by the terms of this agreement.

All ownership and copyright of the images and icons included in the Software
distribution remain the property of Jive Software and INCORS GmbH. Jive Software
grants to you a nonexclusive, non-sublicensable right to use the icons royalty-free
as part of Openfire.

You may not lease, license or sub-license the icons, or a subset of the icons,
or any modified icons to any third party. You may not incorporate them into your
own software or design products.

All icon files are provided "As is" without warranties of merchantability and
fitness for a particular purpose. You agree to hold Jive Software harmless for
any result that may occur during the course of using the licensed icons.

This License Agreement shall be governed and construed in accordance with the
laws of Oregon. If any provision of this License Agreement is held to be
unenforceable, this License Agreement will remain in effect with the provision
omitted.

Copyright (c) Jive Software, 2007

Hi again Daniel,

I nearly packaged all java libraries used by openfire that were not in Debian, however I have a problem with dbutil.jar and stringprep.jar.
This seems to be code from jive software but I can't the find the source code in order to package it.
Do you know where I can get it ?

Yann

Hi Yann,

Just curious on the status of your question. Did you find the source to dbutil and stringprep ?

daryl

Hi Daryl,

No I didn't find the source to dbutil and stringprep, I wrote directly twice to Daniel Henninger but didn't receive an answer.

openfire will not be accepted in Debian if it contains jar that have not been build from source, so for now I'm stuck.

Yann

Hi Yann,

Daniel no longer works for Jive. Please write gato@jivesoftware.com and matt@jivesoftware.com

daryl

Hi Yann,

LG pointed me to this location:

http://www.igniterealtime.org/fisheye/browse/svn-org/openfire/trunk/build/lib/merge

Those jar files have the source included...

daryl

Yes, Gaston Dombiak also told me that. I will work again on the package soon, but I am a little busy right now.