Forked packages for OLPC

[Dennis Gilmore]

On Tuesday 12 August 2008 01:28:30 pm Robin Norwood wrote:
> On Tue, 12 Aug 2008 11:34:16 -0500
>
> Dennis Gilmore <dennis at ausil.us> wrote:
> > On Tuesday 12 August 2008 10:55:25 am Greg Dekoenigsberg wrote:
> > > So we've got a list of packages that have been forked in OLPC from
> > > their F-9 equivalents.  Thanks to Dennis Gilmore and Jim Gettys for
> > > getting these together.  It might be a good idea to figure out:
> > >
> > > (a) why they're forked;
> > > (b) whether we can unfork;
> > > (c) how we keep track of why and when we fork.
> > >
> > > --g
>
> I took the liberty of organizing these a bit by topic:
> > > ./gnash/OLPC-3
> >
> > should not have been forked
> >
> > > ./sugar-presence-service/OLPC-3
> >
> > no longer using,  using F-9 packages now
> >
> > > ./abiword/OLPC-3
> >
> > should not be needed.  should be able  to use fedora's branch
> >
> > > ./ntp/OLPC-3
> >
> > can be unforked,  changes were made to fedora's ntp,  drops perl
> > requirement
> >
> > > ./pyabiword/OLPC-3
> >
> > should not be needed.  should be able  to use fedora's branch
> >
> > > ./sugar-artwork/OLPC-3
> >
> > no longer using,  using F-9 packages now
> >
> > > ./sugar/OLPC-3
> >
> > no longer using,  using F-9 packages now
> >
> > > ./python-dotconf/OLPC-3
> >
> > should not be needed.  should be able  to use fedora's branch
> >
> > > ./sugar-toolkit/OLPC-3
> >
> > no longer using,  using F-9 packages now
> >
> > > ./sugar-datastore/OLPC-3
> >
> > no longer using,  using F-9 packages now
> >
> > > ./sugar-base/OLPC-3
> >
> > no longer using,  using F-9 packages now
> >
> > > ./pygame/OLPC-3
> >
> > should use fedora's
>
> Is there anything that needs to be done for these?  Are they untagged
> in Koji so OLPC no longer builds against them?
 someone would need to go through and do a bunch of untagging.  but its doable  
ive been tagging the f-9 sugar builds over as they happen.  before F-9 updates 
are pushed.  though once the F-9 updates are pushed we should untag so we pull 
from F-9 

> > > ./texlive/OLPC-3
> >
> > rebuild against the old poppler
> >
> > > ./poppler/OLPC-3
> >
> > using an old version not sure why.
>
> Who can investigate poppler and maybe figure out what's up?

hides a bug it seems

> > > ./dotconf/OLPC-3
> >
> > not sure on this one
>
> Who can investigate this?
>
> > > ./speech-dispatcher/OLPC-3
> >
> > not sure on this one
>
> Who can investigate this?
dsd  can you look please

> > ./telepathy-salut/OLPC-3
> > has a patch that disables security that upstream wouldnt take.  i
> > wanted them to add it as a run time option.  the dbus security breaks
> > rainbow
> >
> > > ./telepathy-gabble/OLPC-3
> >
> > has a patch that disables security that upstream wouldnt take.  i
> > wanted them to add it as a run time option.  the dbus security breaks
> > rainbow
>
> Is this going to be a permanent fork?  Can OLPC move away from needing
> this patch, or can we convince upstream to take an amended patch?
considering upstream wrote it and when i suggested a runtime flag to enable it, 
and they stronly objected.  there needs to be a propper way around it.  likely 
it needs some PolicyKit rules to be made to work and drop the patch.

> > > ./xorg-x11-server/OLPC-3
> >
> > needed to enable evdev.  Fedora disables it
>
> Any idea why Fedora disables it?  Can Ajax be convinced to enable it
> again?
because it hosed peoples locales.  ajax  has been working on a better fix.  and 
F-10 it may be enabled.

> > > ./NetworkManager/OLPC-3
> >
> > we are using 0.6.x  there is work to move to 0.7
>
> Is this likely to be done in time for F10?
sugar needs to learn to deal with both the NM-0.6 and NM-0.7 api.  AFAIK that 
and gettings some patches upstream are the remaining issues

> > > ./olpc-utils/OLPC-3
> >
> > olpc only though could likely live in fedora just fine
> >
> > > ./ohm/OLPC-3
> >
> > makes no sense on any other hardware  though wouldnt hurt being in
> > fedora.
>
> These appear to already be branched for F9 and rawhide, just not
> built.  Do they need to pass a package review, or does someone just
> need to build them?
everything got branched for F-9 if it had a devel branch.  the way cvs works 
all packages have to get added at the devel level

> > > ./hulahop/OLPC-3
> >
> > needs pyxpcom which is not enabled in fedora's xulrunner
> >
> > > ./xulrunner/OLPC-3
> >
> > needed to enable pyxpcom  it needs to get enabled in fedora so that
> > browse can work, caillion is supposed to be fixing.  but as yet has
> > not.
>
> Is there a BZ for this?  Does caillon need to be nudged?

honestly not sure if there is a bug. last i spoke to him,  he was unsure if he 
could make the changes or not due to mozilla. ( they are such a hugh roadblock 
at times)

> > > ./xorg-x11-utils/OLPC-3
> >
> > dropped some dependencies
> >
> > > ./sugar-evince/OLPC-3
> >
> > minimal evince for the XO,  should be in fedora and pulled in from
> > there
> >
> > > ./SDL_mixer/OLPC-3
> >
> > Droped perl
> >
> > > ./gnome-python2/OLPC-3
> >
> > needed to drop deps,  package should be split up some so that we can
> > use fedora's package
> >
> > > ./olpcsound/OLPC-3
> >
> > its a subset of csound for the XO,  we should make it so that csound
> > provides the minimal needs of OLPC
> >
> > > ./gstreamer-plugins-base/OLPC-3
> >
> > needed to drop perl dependency there is one plugin that pulls in perl
> >
> > > ./gnome-vfs2/OLPC-3
> >
> > needed to drop some dependencies
>
> Are there BZ's filed for these so work can be done to split up the
> Fedora packages so OLPC can only take the smallest bits?
>
> > > ./totem/OLPC-3
> >
> > need a minimal totem  that doesnt bring in perl and some gnome
> > libraries, F-9's  was horribly broken,  we are using totem from
> > rawhide
> >
> > > ./totem-pl-parser/OLPC-3
> >
> > needed version from rawhide to match totem.  it had better Requires
>
> Is there a BZ to track this?
likely not 

> > > ./initscripts/OLPC-3
> >
> > is needed
>
> Does it make sense to have an olpc-initscripts package that is in
> Fedora proper?
not really.  differences are fairly minor.  like 3 vts instead of 7. 

> > > ./upstart/OLPC-3
> >
> > init doesnt run as pid 1  due to the way the intramfs runs  should be
> > fixed.
>
> Does that mean it should already be fixed, and we can get rid of this,
> or that it needs to be fixed?  Is there a BZ for it?
its not fixed.  but needs to be. probably not a bug for it.

> > > ./xkeyboard-config/OLPC-3
> >
> > changed some keymappings,  really should get fixed properly
>
> BZ?
>
> > > ./fedora-release/OLPC-3
> >
> > different macros for dist.  probbaly should write a olpc-release just
> > for olpc
>
> I think that's the standard way inside rel-eng.  I'm sure Jesse Keating
> knows the proper way to do this.
>
> > kernel should be branched and built in koji. currently its built
> > elsewhere.
>
> Is there any work or hope of getting the OLPC kernel and stock Fedora
> kernel to converge?
It would need to be a subpackage.  its possible.  most of the olpc specific 
bits are now upstream  or on their way there.  having a .geode.rpm kernel 
build for the XO would be good.  it would then let people more easily build 
their own images  from only fedora repos.

> Does it make sense to get these into a list/table on the wiki?
>
> I'm sure we can find someone with Mad Table-making Skillz to do that.
yes it should along with bugzilla reports as needed.  One thing we need to do 
is make sure when things get broken into subpackages  the subpackages are not 
required  so we dont just end up with the same situation.

Dennis