[sugar] packaging python

Marco Pesenti Gritti mpg
Tue Mar 6 04:45:30 EST 2007

On Tue, 2007-03-06 at 01:33 -0800, Neal Norwitz wrote:
> On 3/6/07, Marco Pesenti Gritti <mpg at redhat.com> wrote:
> > On Mon, 2007-03-05 at 23:16 -0800, Neal Norwitz wrote:
> > > What is the plan for packaging python?  It looked like when I did a
> > > build-base that it pulled down a stock python 2.5.  Are there any
> > > patches applied?  What will happen when we want to patch Python for
> > > OLPC?
> >
> > In sugar-jhbuild we are building stock python without any patch. For the
> > images we are using the Fedora python rpm, you can see the patches we
> > apply there from the srpm.
> >
> > If there are patches that needs to be applied we can do that both in
> > sugar-jhbuild and rpms.
> That's good to know, thanks.  Couple more questions:
> How do I submit the patches?  What branch should they be against (2.5
> release, 2.5 SVN, or something else)?  Would it be easier to put them
> up on python.org somewhere and let people download them/play with
> them?  By fedora, do you mean 6?  Hmmm, I don't see python 2.5 here:
> http://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/
>  Where can I get the rpm?

We are still using python 2.4 on the images. I hope we will be able to
switch to 2.5 soon. You can see the sources here:


> Also, for something like PGO, I would make a separate target or two in
> the makefile, but it wouldn't be the default target.  Is that a
> problem?  I'm currently thinking about 2 options, make pgo-fast and
> make pgo-complete.  The fast target would just run python a bit (ie,
> use the existing run when building all the modules).  The complete
> target would run the regression test suite which will take an
> additional 5 minutes or so depending on your box.

I'm not sure how we want to go about this exactly.

Usually we are trying to reuse Fedora packages to avoid additional
maintenance work. When the changes are generally useful I think we
should just try to get them upstream.

For OLPC specific customizations, personally I think we should verify
they actually improve performance of sugar or of the activities before
deciding to maintain our own package.


More information about the Sugar-devel mailing list