Hi, Matt That plan sounds great. Overall, I'm fine with using a launchpad PPA if that's simplest; also I think Jared set up one @ OSAF a while back.
I suspect that there is a fair amount of work to do (as you can see by running lintian on the deb you produced :o). There are a few areas I can think of: 1) Chandler's dependence on patched external libraries, viz wxPython and Berkeley DB (package libdbX.Y). So far as those go: - I have finally gotten a chance to work on creating patches (against wx trunk) for the various wx enhancements Chandler needs. The plan is to submit those as enhancement requests/bugs that should come out in wx 2.9.x. Hopefully that is consistent with your Karmic+1 plan. - A while back, Jacob Floyd did some work on creating Chandler packages for OpenSUSE (IIRC, it could have been another non-Debian Linux). He basically created a libchandlerdb package out of Chandler's patched Berkeley DB (with the library names changes to avoid file conflicts). Possibly this is a route to consider for Ubuntu. - Otherwise, as I remember it, there's a thread on the Berkeley DB dev list somewhere about a patch Andi submitted that somehow appeared in their trunk in a form that wasn't thread-safe. I can hunt around for the link if we want to try to get them to change their code. Or, possibly Andi remembers more. 2) The current Chandler build process uses Python's package management system (setuptools/pypi.python.org) to check for dependencies and install python packages. (Examples are EggTranslations and zanshin). Presumably, we should create .debs for these, and I think Jared Rhine started the process of doing that, e.g. http://svn.osafoundation.org/sandbox/packaging/deb/zanshin/trunk . 3) I suspect that the localization mechanism (plugins and EggTranslations) is violating Debian policy in some ways; there might have to be changes to the i18n code if this is the case. Or we could distribute binary python eggs for all the translatable data (icons and/ or gettext files) 4) Possibly lower down on the totem pole is that some of our dependencies (e.g. epydoc, docutils, pylint) are really only there to run tests and/or create documentation. In a world where I had a lot of time I would break chandler up into chandler and chandler-dev packages, where the chandler package just had the stuff you need to run the app. --Grant On 24 Jun, 2009, at 15:11, Matt Schafer wrote: > Howdy, > > After building the current trunk of Chandler Desktop for Ubuntu 9.04 > (Jaunty) [1], I decided to find out what it would take to package this > into a .deb that would be available on the Ubuntu repositories. After > some initial investigation, I found that someone has started a > packaging effort in Debian [2]. He and I have decided to team up to > do the Debian packaging. It will give me a chance to learn from an > experienced maintainer and give him some manpower to figure out the > chandler source tree. > > As for Ubuntu. They pick up all packages in Debian unstable prior to > their DebianImportFreeze date [3]. They generally do not include new > packages or updates to packages after the Ubuntu release except for > security fixes and, rarely, major functionality fixes. For the next > release of Ubuntu (9.10, codenamed Karmic Koala), DebianImportFreeze > is tomorrow [4]. Since Ubuntu has a 6-month release cycle, I would > guess that gives us at most 6 months to get the package incorporated > into Debian in time for Ubuntu Karmic+1. > > In addition to the official Debian and Ubuntu repositories, we can > create packages and upload them to a custom repository hosted on the > OSAF web site or using a PPA hosted in Launchpad [5]. This would > allow us to get the packages out sooner to Chandler users and to > upload new fixes and releases between the Ubuntu releases. > > Hopefully, we can get this package created by Karmic+1. At any rate, > I'd be happy to work directly with the Chandler project and devs with > any fixes and suggestions, if you're interested. > > Please let me know if this plan is not desirable. > > Matt > > PS: Sorry for the ever-changing email addresses and IRC nicknames. > (I was [email protected].) I've finally settled on what I want to > move forward with. This is where you'll see me in the future. > > References: > [1] http://markmail.org/thread/u4zybvu7womnwxmp > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449031 > [3] https://wiki.ubuntu.com/DebianImportFreeze > [4] https://wiki.ubuntu.com/KarmicReleaseSchedule > [5] http://launchpad.net/ is the package maintenance system for > Ubuntu. > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > 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
