Hi, Matt Thanks for your email ... answers below.
--Grant On 18 Jun, 2009, at 22:20, Matt Schafer wrote: > Howdy, > > 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 > http://chandlerproject.org/Developers/RunningChandlerFromSourceReleases > . > This did not work because the pre-built binaries are not at the URL > that the Makefile expects them. (Makefile expects files at > http://builds.osafoundation.org/external/jaunty/*, but the files > actually live at http://builds.osafoundation.org/external/*. 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. <http://mail-archives.apache.org/mod_mbox/lucene-pylucene-dev/200904.mbox/%[email protected]%3e > 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 (buildout.org), 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: http://svn.osafoundation.org/sandbox/packaging/deb/chandler/trunk which wraps the svn checkout & make procedure you were going through. Instructions for that are at: http://svn.osafoundation.org/sandbox/packaging/deb/HOWTO.txt HTH, --Grant _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
