Building Chandler 1.0.3+ on Ubuntu 9.04 (Jaunty)
|
|
Matt Schafer
|
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.) 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.) 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? 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? 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? 3. Does Twisted need to be built for a specific version of Python? Can I use the one that is in the Jaunty repositories? 4. There is a lot of building for PyLucene that goes on. Can we use the pylucene package that is in the Jaunty repositories? 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. Thanks, Matt _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
Grant Baillie
|
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/%3calpine.OSX.2.00.0904221059001.15435@...%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 |
||||||||||||||||
|
Matt Schafer
|
Hi Grant,
Thanks for your help. I was able to successfully build the .deb for Jaunty using rev 16688. I used the packaging directory in the sandbox repository with the instructions you quoted. I tweaked both the debian/changelog file and the debian/control file. An svn diff is at the end of this email. Took me a little bit to get the control file right. I got the Build-Depends fixed up, but then when I tried to install the package, it wanted to install an old version of vobject, because I failed to remove it from the Depends line. The diff can be hard to follow, so here is a summary of the changes to Build-Depends and Depends: Build-Depends: 1) Change python-dev (>=2.5) to python2.6-dev 2) Delete python-vobject 3) Add python-twisted (>=8.2.0), fakeroot and svn-buildpackage Depends: 1) Change python (>=2.5) to python2.6 2) Delete python-vobject 3) Add python-twisted(>=8.2.0) One other thing I noticed. The openjdk-6-* packages in Build-Depends and Depends require a version >=0.6b11. But the packages in the Ubuntu repository for Jaunty are version 6b14-1.4.1-0ubuntu7. It looks like the control file is looking for 0.6 or later, and the packages are 6 or later. This would make all packages satisfy the version requirement, even if they're older than 6b11. Not sure this is what we want. Also couldn't figure out how to get the version string in Chandler (splash screen and Help>About) to reflect the built version. Since r16688 has 1.0.4.dev, that's what it displays. Though after installation, I manually changed version.py to 1.0.3+svn-r16688. I'm not too worried about it, since I'll be the only one using this package. Unless other folks would like it, too. Bottom line: I now have a Chandler 1.0.3 that works in Jaunty without the error and deprecation warnings. Life is better now. Matt svn diff of checked-out sandbox/packaging/deb/chandler/trunk: Index: debian/control =================================================================== --- debian/control (revision 1977) +++ debian/control (working copy) @@ -2,16 +2,16 @@ Section: mail Priority: optional Maintainer: OSAF buildmasters <[hidden email]> -Uploaders: Jared Rhine <[hidden email]> +Uploaders: Jared Rhine <[hidden email]>, Matt Schafer <[hidden email]> Standards-Version: 3.8.0 -Build-Depends: debhelper (>=7), build-essential, curl, subversion, python-dev (>= 2.5), gcc (>=4.2), gettext, patch, libgtk2.0-dev, libsdl1.2-dev, openjdk-6-jre-headless (>=0.6b11), openjdk-6-jdk (>=0.6b11), ant, python-setuptools (>= 0.6c6), python-m2crypto (>= 0.18.2), python-configobj (>= 4.3.2), python-zopeinterface (>= 3.3.1), python-pyicu, python-dateutil, python-vobject, python-epydoc, python-docutils (>=0.4), pylint, python-parsedatetime, imagemagick, inkscape, quilt +Build-Depends: debhelper (>=7), build-essential, curl, subversion, python2.6-dev, gcc (>=4.2), gettext, patch, libgtk2.0-dev, libsdl1.2-dev, openjdk-6-jre-headless (>=0.6b11), openjdk-6-jdk (>=0.6b11), ant, python-setuptools (>= 0.6c6), python-m2crypto (>= 0.18.2), python-configobj (>= 4.3.2), python-zopeinterface (>= 3.3.1), python-pyicu, python-dateutil, python-epydoc, python-docutils (>=0.4), pylint, python-parsedatetime, imagemagick, inkscape, quilt, python-twisted (>=8.2.0), fakeroot, svn-buildpackage Homepage: http://chandlerproject.org/ Vcs-Svn: http://svn.osafoundation.org/chandler/trunk/ Vcs-Browser: http://svn.osafoundation.org/viewvc/chandler/trunk/ Package: chandler Architecture: any -Depends: libsdl1.2debian (>= 1.2.9), libgtk2.0-0 (>= 2.10), openjdk-6-jre (>=0.6b11), python-m2crypto (>= 0.18.2), bzip2 (>= 1.0.3), python (>= 2.5), python-setuptools (>= 0.6c6), python-configobj (>= 4.3.2), python-zopeinterface (>= 3.3.1), python-pyicu, python-dateutil, python-vobject, python-parsedatetime, libc6 +Depends: libsdl1.2debian (>= 1.2.9), libgtk2.0-0 (>= 2.10), openjdk-6-jre (>=0.6b11), python-m2crypto (>= 0.18.2), bzip2 (>= 1.0.3), python2.6, python-setuptools (>= 0.6c6), python-configobj (>= 4.3.2), python-zopeinterface (>= 3.3.1), python-pyicu, python-dateutil, python-parsedatetime, libc6, python-twisted (>= 8.2.0) Description: Manage and share events, calendars, and notes with a desktop application Described as a "Note-to-Self Organizer", Chandler Desktop provides a unique way to track calendars, tasks, and notes, each placed into one Index: debian/changelog =================================================================== --- debian/changelog (revision 1977) +++ debian/changelog (working copy) @@ -1,3 +1,12 @@ +chandler (1.0.3.1~svn16688-1) unstable; urgency=low + + * Bugs fixed in this release (tracker @ http://bugzilla.osafoundation.org): + - Bug#12792 Chandler does not work under Ubuntu 9.04 Jaunty + - Bug#12802 Italian translation missing in 1.0.3 + - Bug#11059 Upgrade twisted to 8.2.0 + + -- Matt Schafer <[hidden email]> Sun, 21 Jun 2009 11:03:22 -0700 + chandler (1.0.3-1) unstable; urgency=low * Bugs fixed in this release (tracker @ http://bugzilla.osafoundation.org): On Fri, Jun 19, 2009 at 8:06 AM, Grant Baillie <[hidden email]> wrote: BTW, the debs we roll out for chandler 1.0.x releases are made using: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
|
Grant Baillie
|
On 21 Jun, 2009, at 15:45, Matt Schafer wrote: > Hi Grant, > > Thanks for your help. I was able to successfully build the .deb for > Jaunty using rev 16688. I used the packaging directory in the > sandbox repository with the instructions you quoted. > > I tweaked both the debian/changelog file and the debian/control > file. An svn diff is at the end of this email. Took me a little > bit to get the control file right. I got the Build-Depends fixed > up, but then when I tried to install the package, it wanted to > install an old version of vobject, because I failed to remove it > from the Depends line. > > The diff can be hard to follow, so here is a summary of the changes > to Build-Depends and Depends: > > Build-Depends: > 1) Change python-dev (>=2.5) to python2.6-dev > 2) Delete python-vobject > 3) Add python-twisted (>=8.2.0), fakeroot and svn-buildpackage > > Depends: > 1) Change python (>=2.5) to python2.6 > 2) Delete python-vobject > 3) Add python-twisted(>=8.2.0) > > One other thing I noticed. The openjdk-6-* packages in Build- > Depends and Depends require a version >=0.6b11. But the packages in > the Ubuntu repository for Jaunty are version 6b14-1.4.1-0ubuntu7. > It looks like the control file is looking for 0.6 or later, and the > packages are 6 or later. This would make all packages satisfy the > version requirement, even if they're older than 6b11. Not sure this > is what we want. > > Also couldn't figure out how to get the version string in Chandler > (splash screen and Help>About) to reflect the built version. Since > r16688 has 1.0.4.dev, that's what it displays. Though after > installation, I manually changed version.py to 1.0.3+svn-r16688. > I'm not too worried about it, since I'll be the only one using this > package. Unless other folks would like it, too. > > Bottom line: I now have a Chandler 1.0.3 that works in Jaunty > without the error and deprecation warnings. Life is better now. Hi, Matt Good job on getting the deb built! A couple of questions, comments, and answers to your questions: 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. 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? 3) You're right about the openjdk-6-* dependencies: I guess we were setting the bar lower than we thought :P. 4) Yes, the version.py 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. --Grant _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
Matt Schafer-2
|
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. 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. > 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. > 4) Yes, the version.py 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 version.py 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/. 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. 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. Matt _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
|
Grant Baillie
|
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: 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. 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 version.py 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 version.py > 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 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. --Grant _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
|
Matt Schafer-2
|
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.) > 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. > 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. Matt _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
|
Grant Baillie
|
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). >> 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 |
||||||||||||||||
Andi Vajda
|
On Jun 27, 2009, at 1:46, Grant Baillie <[hidden email]> 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 |
||||||||||||||||
|
Grant Baillie
|
On 26 Jun, 2009, at 17:02, Andi Vajda wrote:
> > On Jun 27, 2009, at 1:46, Grant Baillie <[hidden email]> > wrote: >> ... >> 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) Thanks for the info, Andi. Is there anything wrong with building the old version (2.3-something) with the changed jcc invocation? That seems to work (and searches in Chandler don't crash :o). I think that techgurufloyd's chandlerdb patch is in this message: http://markmail.org/message/q275nfaywxvzpqpz I'd be more than happy to make that change (and the PyLucene version change) if it's a way toward not having to build PyLucene as part of Chandler on Ubuntu :). --Grant _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev |
||||||||||||||||
|
Andi Vajda
|
On Jun 27, 2009, at 2:58, Grant Baillie <[hidden email]> wrote: > On 26 Jun, 2009, at 17:02, Andi Vajda wrote: > >> >> On Jun 27, 2009, at 1:46, Grant Baillie <[hidden email]> >> wrote: >>> ... >>> 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) > > Thanks for the info, Andi. Is there anything wrong with building the > old version (2.3-something) with the changed jcc invocation? That > seems to work (and searches in Chandler don't crash :o). No, that should work too but the idea is to use a PyLucene that is compatible with the version provided by Ubuntu. You could then just use it instead of building it. If that version is newer than what Chandler currently uses, in particular with regards to the java array handling code, then upgrading is going to require these changes in Chandler's repository code. > I think that techgurufloyd's chandlerdb patch is in this message: > > http://markmail.org/message/q275nfaywxvzpqpz > > I'd be more than happy to make that change (and the PyLucene version > change) if it's a way toward not having to build PyLucene as part of > Chandler on Ubuntu :). Yes, that's the idea (I'd offer to help out but I'm away from my computer for the next three weeks). Andi.. > > > --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 |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
