atom feed11 messages in org.osafoundation.chandler-devRe: [chandler-dev] Building Chandler ...
FromSent OnAttachments
Matt SchaferJun 18, 2009 10:19 pm 
Grant BaillieJun 19, 2009 8:05 am 
Matt SchaferJun 21, 2009 3:44 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:06 pm 
Grant BaillieJun 26, 2009 4:45 pm 
Andi VajdaJun 26, 2009 5:01 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 25, 2009 11:41:25 am

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

Hi Grant,

You wrote:

1) Are the python --> python2.6 changes required (or recommended)? I ask because we use that control file to build on Hardy, Intrepid and Jaunty, and so there would have to be a branch in svn if the dependencies were different on the 3 platforms.

Good question. You said in an earlier email that you couldn't get the python2.5-built PyLucene to work with the python2.6 environment in Jaunty. So I assumed that by building PyLucene in my package in the python2.6 environment, it would not work with 2.5. I don't know if this is a good assumption or not.

Hi, Matt

Oh, I see. Actually, I have no idea, either ... I had sort of assumed that having "python" be a Depends would pick up the default for the system (i.e. 2.5 on Hardy, Intrepid, 2.6 on Jaunty).

Since PyLucene is built as part of the package with the given debian/ directory, the control file should list the dependencies for PyLucene, also. I would imagine that in a proper packaging scheme, PyLucene would be in its own library package, it would have its dependencies, and the chandler package would then be python2.x agnostic. At the very least though, I do believe that the dependency should be python (<< 3.0). The Python folks have said that 2.x code won't work as-is in 3.0.

Right. I finally became aware of the existence of the Debian Python policy manual, and I think that's what it says :).

2) I'm not an expert on packaging, so I'm not sure if the fakeroot and svn-buildpackage dependencies are required. They are needed for creating .debs, but probably there are other ways of building/ extracting packages?

This is the first package I've built, and I'm just starting to read up on how to create packages and the Debian/Ubuntu policy. So I'm far from an expert!

From what I've read so far, fakeroot is needed to make a .deb in any case when you do not want to do the build as the superuser root. So I guess it's not strictly required. The same probably goes for svn-buildpackage: not strictly required, but very useful. I just put those in there to document all of the dependencies in one place. Again, I'm sure this will all be fixed up in the official packaging.

3) You're right about the openjdk-6-* dependencies: I guess we were setting the bar lower than we thought :P.

Yeah, the versions for the openjdk-6 dependencies seemed wrong. However, I think a bigger concern is requiring openjdk specifically. Perhaps it's okay when building. But there are a few different java runtimes out there. I personally prefer the sun-java6-jre. Depending on one of the virtual packages like java5-runtime or java6-runtime might be a better choice.

I'm assuming that this is a dependency of Lucene. (Do we need Java for any other component?) Lucene and PyLucene are going to be interesting. There is already a liblucene2-java package in Debian and Ubuntu. I'm guessing, but is PyLucene just a wrapper around that, exposing the Java interface to Python? There is also a pylucene project in Debian and Ubuntu. So maybe the trick is to get the maintainer of the pylucene package to use the liblucene2-java package. I really don't know how this is going to work. The dependencies that we must still build from external/ are going to be our biggest challenge.

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. 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).

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).

4) Yes, the file doesn't pick up the svn version automatically (it's tweaked by hand when creating new svn branches for builds). There is currently code to figure out the version from the .svn directory (if one is present); maybe there's a way to do the same thing for a file installed of a debian package.

For now, I can probably just make a patch file to change if I make any more private builds of trunk.

There is a lot in that control file that should not make it back into the repository. As I said, I'm still at the beginning of the learning curve. For instance, I noticed in my build log that the version of twisted that setuptools looks for is >= 8.1.0. I put (>= 8.2.0) in the Depends because that's what we have in external/.

Yeah, the 8.1.0 is for Intrepid -- chandler is fine with that version (but not anything earlier). Hm, now that I think about it, Hardy had an older version, so I'm going to need to create a branch in svn anyway for 1.0.4.

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 :).

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.


Open Source Applications Foundation "chandler-dev" mailing list