|
|
|
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: 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 best thing to do is to maintain the package in its own repository, or its Also, it usually sounds like a good idea to integrate with upstream build Regarding organization, I can help with the debian-specific stuff, but I would Now, some comments about what you already did. debian/changelog: debian/control: debian/copyright: [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: debian/patches/11-unwritable-home.patch: debian/postinst: debian/rules: 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:
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: Ah, I didn't notice that. As I said, I'm not at all a java specialist > * 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. 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:
then that package can be "injected" into the collab-maint repository. Ive created a list of openfire dependencies:
-./src/web/WEB-INF/lib/dwr.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. 1) checked out svn to /tmp/openfire but dpkg told me, that building the package is not possible. strangely enough i got no further errors. best, Martin 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 From a Debian packaging PoV I suggest ripping out large chunks of the "source" tarball: 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: 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)? 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
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
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 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. src/web/muc-room-create.jsp 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 ! 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. 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]. 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. 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 License Agreement This is a legal agreement between You, the User of the Openfire application All ownership and copyright of the images and icons included in the Software You may not lease, license or sub-license the icons, or a subset of the icons, All icon files are provided "As is" without warranties of merchantability and This License Agreement shall be governed and construed in accordance with the 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. Yann |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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...