atom feed11 messages in org.osafoundation.chandler-devRe: [chandler-dev] Building Chandler ...
FromSent OnAttachments
Matt SchaferJun 18, 2009 10:20 pm 
Grant BaillieJun 19, 2009 8:06 am 
Matt SchaferJun 21, 2009 3:45 pm 
Grant BaillieJun 24, 2009 4:44 pm 
Matt SchaferJun 25, 2009 12:41 am 
Grant BaillieJun 25, 2009 11:41 am 
Matt SchaferJun 25, 2009 2:07 pm 
Grant BaillieJun 26, 2009 4:46 pm 
Andi VajdaJun 26, 2009 5:02 pm 
Grant BaillieJun 26, 2009 5:58 pm 
Andi VajdaJun 27, 2009 12:21 am 
Subject:Re: [chandler-dev] Building Chandler 1.0.3+ on Ubuntu 9.04 (Jaunty)
From:Grant Baillie (
Date:Jun 26, 2009 4:46:03 pm

On 25 Jun, 2009, at 14:07, Matt Schafer wrote:

Hi Grant,

You wrote:

I guess the debian folks are aware of this:

and my reading of that is that it's not a lucene dependency, but a pylucene dependency.

Yes. The liblucene2-java package has no Python dependency, and the most recent version of that package has changed the Depends to openjdk-6- jre or java5-runtime. I don't know what the Build-Depends is.

I should also add I have no idea what happens if you try to run pylucene against a different java runtime: The build process seems quite intricate (IIRC it pulls down both java and lucene source), and so I'm not sure whether it would just work. Probably something for the pylucene list (which must be hosted by Apache now, I guess).

I've only looked at it for a few minutes, but it seems like the build process pulls down some java sources to build the jcc tool. Since there is also a separate jcc package, the pylucene package probably doesn't need any of that, either. I may do some research into the pylucene project. Andi is quite active in the pylucene-dev mailing list. But even with all of that, I'd have to contact the Debian pylucene maintainer, since he's already produced one package. (That existing package, by the way, pulled the source in January 2008, when the project was still managed by OSAF.)

At the least, I think it would be good to get that source (or newer) to build against python 2.6 (for Karmic).

In any case, I guess the Linux packaging goal would be to have chandler depend only on pylucene. In fact, we could probably do that today (i.e. with the existing Jaunty package) if we made chandler depend explicitly on python 2.5. (There are a couple of scripts that might need to be #!/usr/bin/python2.5 rather than #!/usr/bin/python).

That seems the most logical way to do it. Depend on pylucene, let the pylucene package depend on the lucene package, jcc, etc., and let the lucene package depend on a Java runtime. That's after the packaging is all settled in the ideal fashion.

But if the current Chandler package builds and uses the Lucene that is stored in the chandler svn repository, all of those dependencies need to be listed in that package. Otherwise, if I try to install that package tomorrow, I wouldn't have the necessary java runtime installed, if it's a fresh system.

As for depending on python2.5, I'd be reluctant to do that. It may solve the dependency problem, but it would pull in another python installation. I'm not sure what the quick and dirty solution is.

I understand your reluctance :). Mostly, I was thinking it might be useful if we tried to break out all the various required subprojects into their own packages.

On 25 Jun, 2009, at 00:41, Matt Schafer wrote:

Also, I just learned today that there is a tool called pbuilder that creates a minimal chroot environment that has only packages marked Essential and the build tools. I probably should start building our packages there to ensure that we don't have bad dependencies.

Oh, that sounds cool. I have been using minimally installed VirtualBox instances, and hand-parsing the Build-Depends entry to install those packages, but a tool to do it would hopefully be easier :).

Check out the log of the Ubuntu package training session from last night. It's at

And now another question. I noticed this evening that at least one other person has asked in chandler-users for a Jaunty build of 1.0.3. Should we do a release for Jaunty, just so that folks have something that can be run? Right now, we have no publicly available package for that distribution.

Yes, you're right. I was originally going to crank a 1.0.4, since there are non-Jaunty fixes that should make it out into there world, but rolling a Jaunty should be reasonably quick instead. I'll do the packaging changes today, and create a svn "tag" for building.

Let me know if there's anything I can do to help.

Thanks; for now, I have:

1) Created an svn tag for in the chandler repository

2) Shuffled files in around in (essentially, to make different debian/ directories for hardy, intrepid & jaunty, because of different dependencies on python and python-twisted).

Let me know if these changes look reasonable.

I will do Jaunty builds (i386 and amd64) once I have access to my box with VMs on it (probably this weekend).

(I'm also interested in seeing what pbuilder is all about, but I haven't had time to look at it).


Open Source Applications Foundation "chandler-dev" mailing list