On 29 Jun, 2009, at 13:48, Jacob Floyd wrote:
> Hey there,
> I'm Jacob Floyd, aka techgurufloyd. I was working for several months
> on getting Chandler to build on Gentoo. Gentoo is source-based, and
> to get it into the main tree, I couldn't include the dependencies in
> the build... It had to use the system libs wherever possible.
> My comments inline:
>
>> 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.
>
> Sweet. Making those patches bogged me down and my efforts had to
> focus elsewhere. Where can I get your patches? Like a tarball of
> them or something.
Hi, Jacob
For now, I have put the patches up on people.osafoundation.org:
The original changes (i.e. wx 2.8.something against Chandler's wx):
http://people.osafoundation.org/grant/patches-r55849.tar.gz
Ported over to current wx trunk:
http://people.osafoundation.org/grant/patches-r61245.tar.gz
Just in case it's not clear, see
http://people.osafoundation.org/grant/wx-checkout-info-r61245.txt
which is how I did the checkouts to patch.
This last set I haven't even compiled; there have been some
rearrangements in the source base, so I just got done porting the
patches. I'm about to go on vacation, but I'll probably try doing that
once I get back (next week).
> At least for gentoo, It was way too much hastle to create a separate
> chandlerwx because of the way python packages work (conversely, I
> did build db as a separate chandlerdb-lib package, as the libs lent
> themself well to this technique). So, I figured I'd build wx as a
> part of Chandler, at least until upstream gets the patches. To do
> so, I wanted to use the vanilla source tarballs, and apply a patch
> for each feature, so that as they're included upstream, I can drop
> the patch, until the point we can use a system version of wx. This
> also allows me to apply each of the gentoo specific patches, and
> make sure it's easy (or at least easier) for the Security team to
> apply any patches to both sources (vanilla wx and the chandler
> variant) as necessary. Maybe something similar will be needed on
> Ubuntu.
>
>> - 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.
>
> I was working on Gentoo. However, I've not been able to spend a lot
> of time on that for a month or two. If anyone's interested in what I
> did, I can help. However, my focus right now is to get a paid job.
> I made a package I called chandlerdb-lib that installs the db libs
> concurrently with the system db keeping everything separate. That
> was an interesting adventure. I can show the build process if desired.
I think that would be interesting, as it could be ported over to
Debian (Assuming it's OK with all the various licenses and policies).
>
>> - 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.
>
> I've put a link to that thread on
> http://chandlerproject.org/Developers/GentooBuildNotes
> DB_DBT_USERCOPY:
> http://forums.oracle.com/forums/thread.jspa?messageID=1504262�
> OSAF Bug#11547: http://bugzilla.osafoundation.org/show_bug.cgi?
> id=11547
(Oh great, I knew there was a link to that somewhere).
>
> ===[SNIP]===
>> 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.
>
> I've outlined the deps, at least as far as the gentoo packages are
> concerned, on the page: http://chandlerproject.org/Developers/GentooBuildNotes
>
> Another thing I was going to do is divide chandler into two
> packages: chandler and chandler-dev. Chandler-dev would have some
> things that would only interest those that would be developing with
> chandler. I was also going to create a separate package for each of
> the plugins, with Use-based (ie optional) dependencies from chandler
> to those plugins. That way someone could install it if they wished.
Yeah, that makes total sense.
Cheers,
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
