On Jun 27, 2009, at 1:46, Grant Baillie <[email protected]> wrote:
> > On 25 Jun, 2009, at 14:07, Matt Schafer wrote: > >> Hi Grant, >> >> You wrote: >>> I guess the debian folks are aware of this: >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518623 >>> >>> 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). PyLucene builds and works fine against Python 2.6. To upgrade: - use PyLucene 2.4.1-2 - use the right JCC invocation (-m won't work until 2.7) (example is in Makefile) - implement the necessary changes in the repository lucene directory code (If I remember right, they're simple, having to do with byte arrays; the previous person that attempted this (techgurufloyd) figured them out by himself) Andi.. > > >>> 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 >> >> https://wiki.ubuntu.com/Packaging/Training/Logs/2009-06-25 >> >>>> 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 1.0.3.1 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 1.0.3.1 should be reasonably quick instead. >>> I'll >>> do the packaging changes today, and create a 1.0.3.1 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 1.0.3.1 in the chandler repository > > 2) Shuffled files in around in > http://svn.chandlerproject.org/sandbox/packaging/deb/chandler > (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 1.0.3.1 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). > > --Grant > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "chandler-dev" mailing list > http://lists.osafoundation.org/mailman/listinfo/chandler-dev _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
