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 19, 2009 8:06:17 am

Hi, Matt

Thanks for your email ... answers below.


On 18 Jun, 2009, at 22:20, Matt Schafer wrote:


I attempted to build Chandler desktop to get rid of the deprecation errors. I noticed that they have been fixed in the repository, so I exported the trunk at r16687.

I attempted to follow the instructions at . This did not work because the pre-built binaries are not at the URL that the Makefile expects them. (Makefile expects files at*, but the files actually live at*. No 'jaunty' directory.)

Yeah, I should upload packages for jaunty (I can actually do that today, since I'm double-checking that my new wx build works OK).

So then I decided that I'd try to make a full build. (Whew! That takes a while.) At least then, I'd have a nice clean .deb package that I could install on my everyday machine. That failed as well, because there is no Twisted egg package for Python 2.6 in the external package list. (I suspect this would also cause the run from source to fail as well, if it had gotten that far.)

I ran into this yesterday; it's actually a Makefile problem. (There's no need to download a Twisted binary on Jaunty, since the system- supplied package should work fine). Anyway, I committed the fix as rev 23140: as far as I know the full build should work now.

First, I recognize that there isn't much development effort going into the Chandler 1.x Desktop tree. But I also have become quite dependent upon Chandler in both my work and personal lives. So I need something to tide me over until Chandler 2 is ready.

And now for some questions: 1. What is the easiest way for me to proceed with the least amount of time from the developers?

Doing what you're doing seems fine ;).

2. I noticed that the build scripts are downloading a lot of stuff that I had already installed in packages. (setuptools, python-dateutil, pylint) These are the same version or newer in packages that I installed. Does the build process not recognize they're installed, and then skip the download and build?

The build process should be checking the python runtime for those packages, and only installing them if they're not present. It does this via something like

/usr/bin/python -c "from pkg_resources import require; require('python- dateutil>=1.3')" || /usr/bin/python -m easy_install 'python- dateutil>=1.3' ...

which should skip any actual installation if you installed dateutil via the Ubuntu package manager.

2a. vobject is a newer version downloaded by the build script than what I had installed. I understand why we may need to download that. Are the other packages modified in some way, or are they stock builds?

Besides the stuff that is actually built in external/ (custom versions of Berkeley DB, wxPython, stock PyLucene), and that newer vobject, I think everything else just uses OS packages, yes.

3. Does Twisted need to be built for a specific version of Python? Can I use the one that is in the Jaunty repositories?

I think I answered that one above; in short, "yes".

4. There is a lot of building for PyLucene that goes on. Can we use the pylucene package that is in the Jaunty repositories?

I tried that a while back, but that pylucene seemed to require python 2.5. (I suspect that's because some changes in in python 2.6 pylucene doesn't quite build "out of the box" with python 2.6; c.f.


Anyway, I was unable to get the hybrid python 2.5/python 2.6 monster to work correctly in Jaunty, and so I left things the way they were (except for the change in external/PyLucene/Makefile to get things to bulid at all). I'd be delighted if someone found a way to avoid having to build that from source for Jaunty, though.

Again, don't want to take a lot of your time. I'm willing to dig into this myself. But this is a huge project, and I don't know any of the development history. Any help is much appreciated.

Yes, there is a lot of history, and when something goes wrong with the build system it's not easy to diagnose the errors. If we were designing the system from scratch I suspect we'd probably just use something like buildout (, but in the meantime we have the existing mix of Makefiles, python scripts, etc. Throwing in Linux package management makes things even more interesting ;). Feel free to ask more questions on this list, or on IRC (I'm "gbaillie" on #chandler).

BTW, the debs we roll out for chandler 1.0.x releases are made using:

which wraps the svn checkout & make procedure you were going through. Instructions for that are at:



Open Source Applications Foundation "chandler-dev" mailing list