fedora-olpc meeting notes and transcript, 8/15

[Greg Dekoenigsberg]

First, the summary:

We spent the hour trying to figure out the goals of "Fedora on XO," and 
how to get there.

The problem: Fedora does not yet boot directly on the XO without 
siginificant modification to kernel and initramfs.

The proposal: Have as many people as possible working on creating a small 
bootable Fedora, and then have dsd continue his excellent work on a tool 
that takes such an image and hacks it into something that will boot on an 
XO.

The downsides:

* Possibly discourages OLPC folks from pushing stuff upsteam into Fedora.

* Tools to create Fedora spins are not necessarily the best possible tool.

* Concerns that a standard Fedora desktop for the XO weakens the case for 
Sugar.

* Will not integrate with Sugar-based filesystem at this time.

The upsides:

* Can take the repetitive work of cranking through package profiles and 
place it on the shoulders of Fedora folks (like Sebastian and others)

* Lowest risk approach to getting something working quickly

* Once dsd's conversion script works, should make it trivial for anyone in 
Fedora-land to create and maintain their own XO-compatible image

A lively and interesting meeting.  :)  Full transcript follows.

* * *

<gregdek> All righty, then.
  Shall we start with the Fedora-on-XO stuff?
<jg> sure.
<gregdek> Do we have an XO booting Fedora yet?
  All spin-cutting questions aside?
--> ke4qqq (n=ke4qqq at 64.89.94.194.nw.nuvox.net) has joined #fedora-olpc
<m_stone> gregdek: I saw one, though I didn't look too closely.
<rnorwood> gregdek: well, we had TODOs from last mtg, but they were mostly 
jeremy.
<gregdek> rnorwood: Are those tracked on wiki yet?
<m_stone> (based on dsd's install-OLPC's-kernel+initramfs script)
<gregdek> m_stone: Someone at 1cc was booting one?
<rnorwood> gregdek: Nope.  Good idea, tho.  Some of the subtasks are/were:
<rnorwood> ** TODO: jeremy to build table of sugar activities and other 
packaging
    work items on the Fedora wiki
  ** TODO: Various people to take items from that list and package them
  ** TODO: jeremy to go to 1cc, revisit next week.
  ** TODO: rnorwood to track down the squeek/etoys licensing issues
  ** TODO: gavin to track down the squeek binary blob issue
  ** TODO: rnorwood to send out minutes
<jg> jeremy visited.
<rnorwood> gregdek: first one is done: 
http://fedoraproject.org/wiki/PackageMaintainers/WishList#Activities
<m_stone> gregdek: 
https://www.redhat.com/archives/fedora-olpc-list/2008-August/msg00063.html
<rnorwood> gregdek: Jeremy is waiting on resolving a technical spec file 
issue before the 2nd TODO gets more work.
<jg> dsd  & bobby did an install onto a 4 gig SD card; you've seen the 
mail.
<gregdek> Right.
<jg> I (my house) got struck by lightning last Friday, which has wasted 
immense amounts of my time.
<gregdek> OK, so to the Fedora image from dsd:
--- gavin_lunch is now known as gavin__
<gregdek> Should we be focusing on testing that on various XOs?
  Jeremy has 10 in his hands now.
  Should all 10 of those be allocated to people using dsd's spin?
<jg> gregdek: not a spin, a conventional install of fedora kludged to 
work.
<gregdek> OK.
  So how do we join the kludge to the real Fedora spin process, is perhaps 
the question.
<rnorwood> gregdek: all the packages need to be hosted in Fedora to make 
an official spin, IIRC.
<gregdek> The package manifest is fun to play with, but figuring out how 
we get a sustainable install process is the question.
<m_stone> rnorwood: yes.
<rnorwood> gregdek: and IIRC, the kernel is the biggest sticking point 
here.
<gregdek> I don't really care if it's "official", per se.
  We've got the same class of problems with customized ccrma kernels, for 
instance.
<m_stone> gregdek: dsd has provided a script that throws together the 
packages and dumps the correct kernel on top.
<rnorwood> gregdek: ok.  then I'm not sure how much of the fedora spin 
process we can use without being an official spin.
<gregdek> Then maybe that's sufficient for now.
<m_stone> this seems like as maintainable a process as you're going to get 
until all the upstream work is completely finished.
<gregdek> Could be.
  Is he using the ks files that jg+sebastian worked on?
<m_stone> gregdek: furthermore, it doesn't address the initramfs 
questions.
<jg> no.
<gregdek> Perhaps we should figure out how to join that work?
<m_stone> gregdek: challenging because ks is designed for making real 
spins; not for making hacked up stuff like what we've got.
<gregdek> Heh.
<m_stone> gregdek: to put it differently -- I looked at anaconda for the 
XO builds themselves and concluded that it was completely inappropriate 
for my purpose.
<m_stone> now jeremy knows a lot more about anaconda than I do, so there's 
hope.
<gregdek> So... new initramfs?
  Is that the critical path?
<m_stone> depends on your quality goals.
  the XO has a crazy filesystem structure -- for olpc-update.
  these spins that we're making can go in two places:
  on external media or on nand.
<gregdek> Which gives the highest likelihood of user success?
<m_stone> gregdek: they're good for different audiences.
--> dsd__ (n=dsd at gentoo/developer/dsd) has joined #fedora-olpc
--- dsd__ is now known as dsd_
<m_stone> anyway, my point is that the degree of interoperability that you 
get with the existing on-NAND sugar is going to vary greatly depending on 
how much hackery you want to do.
  ...
<gregdek> And who is the target audience for Fedora+XO?
<jg> gregdek: solving the olpc-update path transformation should be pretty 
easy, and orthogonal to making normal spins that install on external 
media.
<m_stone> jg: do you want them to share /home?
<jg> gregdek: g1g1 users who don't want sugar, and hackers.
<m_stone> jg: if so, then they are far from orthogonal.
<jg> m_stone: the fedora user's login can be different than /home/olpc.
<m_stone> jg: I asked a different question. do you want them to share 
/home.
<jg> I think we need to punt on interoperability until we get the upstream 
sugar work done.
<m_stone> there we go.
<gregdek> +1, I think.
  Given the timeframes you're talking about, risk mitigation is the most 
important goal, I think.
<jg> me to.
* m_stone notes, on the political spectrum, that you're increasing the 
quantity of bad press due to 'olpc abandons sugar' rumors.
<jg> m_stone: If possible, I want to include sugar as an alternate 
desktop, for exactly these reasons.
<gregdek> With luck, we can counteract that with strong Sugar work in 
parallel.
<jg> exactly.
<m_stone> gregdek: my point is that we need to plan on _even stronger_ 
sugar boosting if interop is not an immediate goal (which jg said its not)
  gregdek: sugar can't take too many more blows.
<gregdek> I think we can manage the perception issues aggressively with a 
lot of help from a broad community.
<jg> interop is on my 9.1 personal goals.
<m_stone> jg: best state that loud and clearly when discussing this.
<cjb> gregdek: That seems unrealistic; we've been doing stronger Sugar 
work for the last year, but people still think we ditched Sugar for 
Windows.
* m_stone will be quiet now.
<cjb> The fact that we all still have our day jobs and work hard on Sugar 
doesn't seem to get the message across.  :-)
<gregdek> cjb: How much of your time have you dedicated to talking to 
press?
  Shall I answer that question for you?  :)
<m_stone> cjb: we speak at 10 dB and NN speaks at 100 dB. what do you 
expect?
<jg> and NN sends incomplete, confusing messages....
<gregdek> I know this is a difficult thing to ask.  :)
<cjb> Right.  I'm just saying that Greg's suggestion of countering claims 
that we don't care about Sugar by working Sugar has a historically bad 
effectiveness.
<gregdek> But trust me to help you sort those perception issues out.
<cjb> s/working/working on/
<cjb> gregdek: ok!
  gregdek: happily.
<gregdek> I definitely recognize the exposure.
<m_stone> good.
<jg> I want to first deal with the "we're ditching Linux" rumors.... 
Sugar is a 2nd order bit question.
<gregdek> Heh.
  Yes and no
  Anyway.
  Easy to slip down this rathole.  :)
  Can we agree that we're working on a simple Linux-only install that is 
essentially independent from the Sugarized file system?
<jg> for now, yes.
<gregdek> That's one.
  Do I have more?
<m_stone> gregdek: yes so long as we also agree to competently explain why 
this isn't sugar's death-knell
<gregdek> m_stone: I promise you.
  Pinky swear.
<m_stone> :)
* gregdek crosses his heart and hopes to die.
<cjb> Okay, works for me too.
<gregdek> All right.
  So what does that choice imply for our current critical path?
<jg> the critical path is getting a cut down spin to boot.
<m_stone> jg: where by 'spin', you mean a genuine Fedora Spin, right?
<jg> I'd be trying to work on that if I weren't in meetings all this week 
I've not been playing sysadmin to fix all the lightning damange....
<gregdek> So we've got the boot issues involving initramfs and kernel on 
one side...
<jg> m_stone: yes.
<m_stone> jg: i.e. no external packages.
<gregdek> ...and the Fedora spin work on the other side.
  How do we join these efforts sanely?
<jg> m_stone: includes packages from us.
  but only a few.
<gregdek> So to be clear:
  This is not a "Fedora spin".
  It can't and shouldn't be.
<jg> for the moment, yes.
<gregdek> It is a "based on Fedora" environment using the best tools 
available to make it sustainable to maintain.
<m_stone> jg: what? that seems to me to contract what you just said.
<jg> but my hope is it minimizes the number of changes.
<m_stone> *contradict
  jg: I explicitly asked you "Fedora Spin" -- no package divergence -- and 
you said "yes". was that a mistake? a future goal?
<jg> m_stone: marco claims to be about to work on fedora sugar 
packages....  I know you have some questions on whether he will find it 
hard to succeed.
<gregdek> To me, a spin is nothing more than "an internally consistent set 
of software packages".
<jg> yup.
<gregdek> And a Fedora spin is that, plus "only containing packages in the 
Fedora universe."
  We are talking about the former, *not* the latter.
<jg> yup.
  until/unless everything we need is upstream.
<gregdek> The livecd tools are able to create package manifests from 
multiple repos, I believe.
<jg> that's what I've called "nirvana".
  gregde.k: yes
<gregdek> Now, are we talking about a process that looks like:
  1. Build a "minimal OLPC/Fedora hybrod spin";
  2. Hack in initramfs changes;
  3. Slap it into an image;
--> nteon (n=nteon at dhcp-47-122.media.mit.edu) has joined #fedora-olpc
<gregdek> 4. Profit?
<jg> roughly.
  the closer it is to fedora, the easier it will be for us all to support 
it....
<gregdek> Right.
  Can we limit the unique packages to kernel and initramfs to start?
<jg> that's what sebastian tried to build last night.
<gregdek> How did it go?
<jg> the build seems to have failed, and I've not seen him on line today.
<gregdek> Please pardon my out-of-the-loopness...
  Hm!
* gregdek wonders if jeremy has had time to play with this.
<gregdek> When's the deadline to have something working?
  Do we have a clear one?
<jg> I was about to try to test the previous spin, with a manual hack of 
the kernel and initrd.
<gregdek> Carry on.  ;)
<jg> gregdek: the SD card dsd just put together is probably enough to keep 
the hounds at bay.
* m_stone is extremely confused about the goals of this whole endeavor and 
fears that some effort will be required if his non-confusion is important.
<jg> gregdek: but the sooner, the better.
<gregdek> Very good.  dsd_, thanks for buying us some time.
  m_stone: feel free to explain.
<m_stone> gregdek: I view the underlying goal here as procedural and 
communal. we're looking for increasingly powerful degrees of 'easy to 
maintain', 'accessible to both the OLPC and fedora communities', etc.
<gregdek> Right.
  And you feel like we're conflicting with that?
<m_stone> well, I view the current approach and intense focus on getting 
various filesystem trees to boot on the OLPC as rather counterproductive 
to that.
  for a couple of reasons.
<jg> how so?
* gregdek listens.
<m_stone> first, most of what jg has been asking for has been various 
degrees of easy installation.
  i.e. 'a completely isolated SD card that boots fedora on the OLPC'
<jg> yes, that's to be able to get it into g1g1 hands, without requiring 
an SD card.
<m_stone> uh, _with_ requiring an sd card you mean?
  maybe jg is talking about a second tier of 'easy installation'; the 
ability to blow away the existing filesystem and use a stock fedora-like 
filesystem?
<jg> yes, easy installation.
<gregdek> To be clear:
<m_stone> and then finally some degree of interop -- the ability to boot 
either fedora or sugar off either NAND or SD and have them share data 
perhaps by having sugar as an alternate desktop
<gregdek> (sorry, go ahead)
<m_stone> gregdek: so what does this have to do with any of the procedural 
and communal maintenance bit?
<jg> m_stone: I don't expect data sharing until we've dealt with sugar's 
journal issue upstream.
<m_stone> jg: why? we've already got copy-to-journal and 
copy-from-journal. plus, the filenames are stable, so clever symlinking 
hacks are possible
<gregdek> It's a tactical goal that some folks in the Fedora community can 
help with.
<m_stone> jg: and we have external metadata in 8.2.0; easily backportable.
<m_stone> gregdek: fine, but why is it any better than 'olpc-update 
fedora-big' ?
<jg> m_stone: I'm trying to bound the "requirements" to the minimum.  If 
we get more, I'll be yet happier.
  underpromise, overdeliver.
<gregdek> m_stone: Maybe it's not.
<jg> m_stone: olpc-update fedora-big is my goal for installation.
<gregdek> I'm just looking for the approach that minimizes our short-term 
risk and allows Fedora folk to help.
<jg> just like debian, but with a fully usable environment ootb.
<m_stone> jg: I can't tell that from the way you're going about it.
<m_stone> gregdek: right.
<jg> m_stone: ergo the use of the live-cd-tools.
<gregdek> Listen, gentlemen, I'm a simple man.  :)
<jg> we can build an image, using standard tools, that can fit.
  that's what sebastian has proven.
<gregdek> Right.  That's my goal.
  I know it may be an imperfect goal.
  But it's something that many people have experience with: building their 
own Fedora spin.
<jg> exactly.
<gregdek> And it's a place where people can (a) use the tools they know, 
and (b) familiarize themselves with an environment that they do *not* know 
in the process.
<jg> and all dependencies are satisfied, so yum install xxxx will "just 
work".
<m_stone> jg: yum install working has nothing at all to do with the use of 
anaconda or of livecd-tools.
  and anaconda is not adapted for using nonstandard kernels or initramfsen 
which is _critical_ to the way olpc-update works.
  which is why everyone who has worked on XO software builds has used one 
of three alternatives.
  pilgrim, puritan, of manual image creation.
  *or
<gregdek> pilgrim is the ancestor of livecd-tools, you know.
<m_stone> gregdek: yes. I've spent quite a bit of time with both. (I 
helped debug livecdtools on the XS where it also at best marginally 
appropriate)
<gregdek> Which makes me wonder where the two have diverged, and why.
<m_stone> gregdek: and livecdtools made some design choices which 
_conflict_ with the easiest way to get distributions installed on the XO.
<gregdek> Are they similar enough to allow people to use ks.cfg files?
<m_stone> now you might have another goal, which is not to use olpc-update 
-- to simply rely on SD cards or on copy-nand.
<m_stone> gregdek: no, they're wholly different.
  gregdek: pilgrim is a big shell script which makes a chroot, installs 
some packages into, and wraps up the result.
<gregdek> My goal is to find the tools with the most common usage, so that 
you can leverage as much knowledge as possible.
<m_stone> gregdek: right, I understand that.
  gregdek: and I'm saying that jg is doing something different.
<gregdek> All right.
* gregdek takes a step back.
<m_stone> gregdek: anaconda and mkinitrd is going to require _surgery_ in 
order to be compatible w/ olpc-update. so you shouldn't expect that.
<gregdek> Why should we care about compatibility with olpc-update for the 
Linux-only side?
<m_stone> which means that you're either interested in SD-only or in 
copy-nand solutions.
<jg> m_stone: all we've done to date is to prove we can build, using 
live-cd-tools, and image small enough that it could coexist on nand with 
our image, which would make it possible for olpc-update to function.
<jg> gregdek: because then we can do an install without external media.
<gregdek> :)
<m_stone> or you want to rely on something like dsd's script to make the 
necessary changes to the filesystem churned out by anaconda.
  those are your three options.
<gregdek> Right.
  Of those...
  I tend to lean to #3.
<m_stone> so far as I can tell, none of them is compatible with making the 
communal process you want.
<gregdek> Maybe that's wrong and hacky.  :)
<m_stone> :)
<gregdek> Well, yes and no.
  There's different work to be done, right?
  One set of work:
  Figuring out a small set of packages that fits well and gives a decent 
experience.
  This is work that *many* can share.
  Second set of work:
<m_stone> gregdek: sure.
<gregdek> Adapting that to the hw realities of the XO.
<m_stone> (puritan is a better tool for that job)
<gregdek> Which is probably not terribly scalable work.
  How many people use/know puritan?
<m_stone> gregdek: more than have succeeded in getting anaconda-built 
software to work on the XO.
<gregdek> And how many is that?
<m_stone> about 2 for puritan and 0 for anaconda.
<jg> and how many are familiar with puritan and anaconda, and have made 
the attempt?
<gregdek> Except, of course, that if you have a simple overlay script that 
massages the livecd output in a predictable way to fix kernel+initramfs, 
which should be a one-time cost operation, that number changes 
dramatically.
<m_stone> a small number are familiar with puritan because it is newer 
than anaconda and much more specialized.
  however, it is quite good at smashing together RPMs (and other package 
formats) into XO-compatible file-systems.
<dsd_> gregdek: thats what i'm scripting
<gregdek> m_stone: It feels like you're pushing to use puritan, and that's 
fine, if that's your choice.  But it'll be more difficult for me to 
deliver knowledgeable community members to your door.
<m_stone> gregdek: I'm pushing you to explain how your choices are going 
to fulfill your goals.
<gregdek> Whereas (livecd/etc.) plus (dsd_script) yields many possible 
contributors.
  Do others understand my viewpoint?
  dsd_?  jg?
<cjb> m_stone: but you're talking to people who don't have as much 
experience with the technology, so what they really need to hear is "I 
suggest doing <foo>, which would gain us <x, y, z>"
<jg> yes.
<dsd_> what purpose would these community members have? to assist the 
build process?
<gregdek> To iterate over packaging issues.
  To fix dependency problems in Fedora, which is your base.
<dsd_> yes, working on the community's home turf makes sense from that 
respect
<gregdek> To lower the bar for their contribution by allowing them to use 
tools they already know.
  Standard gregdek disclaimer: as always, I could be completely wrong.  :)
<jg> heh.  As can I, frequently ;-).
<m_stone> gregdek: so your desired outcome is a script that takes a .ks 
and runs it resulting in XO-compatible media.
<gregdek> Yes.  I think so.
<m_stone> e.g. by performing whatever hacks dsd finds are necessary on top 
of the output from anaconda.
<gregdek> Yes.  I think so.
<m_stone> gregdek: and how are you going to debug that?
<gregdek> It's still a package manifest, in the end.  What's the likely 
scope of changes?
<m_stone> gregdek: also, in a larger community sense -- how does it help 
anyone outside of Fedora/RH land?
  gregdek: hard to predict.
<gregdek> This is one specific goal.  There are many others.
  We also have the Sugar stuff to work through, and we haven't talked about 
it yet, because we've spent an hour debating this.
  What I'm offering is a way to help offload the maintenance of this Fedora 
spin from you guys...
<cjb> m_stone: I find it hard to follow your argument because you're 
pointing out downsides in one approach without mentioning which other 
approach has far fewer downsides and accomplishes the same goals.
<gregdek> ...so you can spend your capacity elsewhere.
<cjb> m_stone: pilgrim's hard to debug, too.  every piece of technology 
for doing this has downsides.  pointing at downsides doesn't tell me what 
we should actually do instead.
<gregdek> Anyway.
  I'm running out of time...
<-- kimquirk_ (n=kimquirk at pool-98-110-153-245.bstnma.fios.verizon.net) has 
left #fedora-olpc
<gregdek> ...so I will make my recommendation, and allow you to do with it 
as you will.
  I think that dsd_'s approach is good, and I'd like to see folks trying it 
out.
<ke4qqq> m_stone: Outside of Fedora/RH land people at least have a huge 
body of experience to tap - plenty of documentation to tap - not to 
mention significant community pool who already know how things work - can 
your alternative say the same?
<jg> dsd_'s approach is great, but doesn't result in a small image.
<m_stone> cjb: we should be pushing our patches upstream and fixing 
packaging bugs until we get to the point where Sugar and Fedora are 
completely indistiguishable in that the XO software distribution is a 
fedora install with some on-disk configuration changes.
<gregdek> Can dsd_'s approach be merged with the ongoing ks refinement 
work?
<m_stone> cjb: dennis was taking us in that direction and I continue to 
believe that it's the right way.
<jg> I also don't have insight into what is required to get us to where 
olpc-update can be used to do an installation.
<gregdek> m_stone: I also believe that it's right.  They are not mutually 
exclusive.
<m_stone> cjb: getting more contribution from Fedora folks should occur by 
asking them to install olpc-generated packages on F-9, F-10, etc. and 
fixing bugs. or through emulation, or by sending them XOs.
<cjb> m_stone: the unmentioned downside of that plan is that it doesn't 
get us something in time for G1G1.
  jg: that's a reason to learn more, rather than a reason not to try to 
achieve that.
<jg> cjb: I'm trying to learn; educate me ;-).
<gregdek> At some point...
  ...a wrong decision is better than none.  :)
  How do we move forward?
<m_stone> cjb: what is maintainable about what jg/gregdek are suggesting 
and who does it benefit?
--> jwilliam (n=jwilliam at jwilliam.dsl.xmission.com) has joined 
#fedora-olpc
<gregdek> m_stone: This predicates that the dsd_ scripts are actually any 
good.
  If they are...
<m_stone> gregdek: it's a hack. dsd could certainly maintain it 
indefinitely. hopefully someone directly from fedora-land could do so as 
well.
<gregdek> It's also a short-term solution, right?
<m_stone> gregdek: I'm skeptical of that.
<gregdek> Because the goal is NOT to have bootable Fedora forever.
<m_stone> gregdek: I think it's going to encourage people not to try to 
merge OLPC's changes into Fedora proper.
<gregdek> The goal is to have bootable Sugar on top of stock Fedora.
  Why?
  I have no idea where that assertion comes from.
  People on fedora-olpc-list continue to iterate through that list of 
forked packages to solve those problems.
  Do they not?
<m_stone> gregdek: no, they don't need to here.
  gregdek: they might continue to do so, because they're good people who 
share the same goal.
<dsd_> its a short term solution because in the longer term i hope that 
upstream kernel will boot on XO..
  then we're just left with xorg.conf and boot.fth
<gregdek> Right.
<m_stone> dsd_: and the initramfs
<gregdek> This is trying to get MORE help in solving a SHORT-TERM problem.
<dsd_> if upstream kernel boots on Xo
  then we use fedora's kernel and initramfs
  no need to customize
<gregdek> It does nothing to discourage the ongoing work on the LONG-TERM 
problems.
  They are separate.
  I don't know how to explain myself any more clearly.
<m_stone> gregdek: I don't buy it, but fortunately, I don't have to.
  gregdek: the best I'll give you is that it adds a marginal amount of 
value to jeremy's goal of widespread dependency splitting.
<gregdek> Then why are you arguing?  For the sport?  :)
  Anyway.  I'm out of time, gentlemen.
  dsd_: Is your script available for folks to check out / use?
<m_stone> gregdek: because I think that encouraging people to work really 
hard on getting OLPC to deal with Fedora properly and working really hard 
to modify Fedora procedures that are hard for OLPC to deal with is a far 
better place to expend effort.
<gregdek> m_stone: THEY ARE NOT MUTUALLY EXCLUSIVE.
<dsd_> gregdek: yes but it is totally untested, i havent even run it
<gregdek> It's a long road.
<dsd_> gregdek: going to test and fix it tonight
<gregdek> dsd_: Brilliant.  I look forward to hearing more about it.
  And if it sucks, we figure something else out.  :)
  Because, as always, I could be completely wrong.
  Anyway.
* gregdek bangs the gavel.