What's cooking in the XS pot this week (2008-08-26)
by Martin Langhoff
More OLPC spam :-) -- If you see a raft of "how do I make $something
work in F9" questions from me on fedora-devel... the email below
outlines what I am working on (in a nutshell, upgrading the School
Server spin to F9).
Help is deeply appreciated. While most stuff "just works", we have
some significant challenges:
- Networking infrastructure. Jerry has been helping lots, and any
pointers into how to tweak the udev-triggered in ways that don't
backfire... welcome! Not many people seem to be playing with it, and
our setup has some "special needs".
- Upgrade nicely.
- Pungi/revisor configuration and scripts for a truly minimal install.
- Kickstart / anaconda / firstboot tweaking.
cheers, m
---------- Forwarded message ----------
From: Martin Langhoff <martin.langhoff(a)gmail.com>
Date: Tue, Aug 26, 2008 at 11:57 AM
Subject: What's cooking in the XS pot this week (2008-08-26)
To: XS Devel <server-devel(a)lists.laptop.org>
xs-0.4 is out - so now we're on to xs-0.5. The plan for this week is to
- Keep track of any issues on 0.4 -- please report them via Trac or
post them here
- Add an activity installation server -- which may be available for
0.4. Douglas is working on this.
- Make an attempt to rebase on F9. This attempt is time-boxed - if by
EoB Friday we have a reasonably well cooked F9-based XS installer,
it's all go and xs-0.5 will be based on F9. If instead we have a pile
of issues, we'll document the issues and ask for help, but we'll drop
the F9 port from the xs-0.5 plans.
This is a hard-nosed risk mgmt strategy. F9 gives us security support
and a hopefully better build toolchain (anaconda, pungi and revisor
seem to be in much better shape, bugs in the F7 versions have been a
problem for us). On the other hand, it gives us no user-visible
features, and issues with the rebase can be very time consuming to
resolve.
Reaching end-of-Sept with only a F9-based version with no new features
for end users would be a bad scenario. Same date but with a buggy
F9-based version and no new features is our worst case. My plan does
not allow for either to happen :-)
The other non-ideal scenario is a F7-based release with features, but
with no security support. This is not the best, but on the risks map
this is not as serious because most XS installs we are planning to
support in deployments are _not_ on the internet -- they either have
no WAN/Internet connection or they are behind NAT. Their value as
targets and their exposure is very low.
I know some readers care a lot about security, and I am deeply
grateful that they do. If you are one of them, do your bit: help us
make the F9 port a success.
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
15 years, 8 months
fedora-olpc meeting notes and transcript, 8/15
by 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(a)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@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(a)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(a)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(a)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.
15 years, 9 months
[Fwd: Please help test our new 8.2.0 weekly beta, joyride-2301!]
by Michael Stone
I thought I'd pass along this global announcement which I just spammed
to the OLPC lists in case anyone over here is interested. (Also, do let
me know whether the denizens of this list would like to receive similar
announcements in the future.)
Regards,
Michael
--------------
We are thrilled to announce a new test build, joyride-2301, valid until
Wednesday, August 20.
Please help test it according to the detailed instructions at
http://wiki.laptop.org/go/Friends_in_testing
while we still have time to fix issues you might find!
Our specific interest this week has changed; this week, we'd love to
know:
"How many ways can you crash or hang your XO?"
Currently known issues are recorded at:
http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_joyride-2301
New issues should be filed in our bug-tracking system (dev.laptop.org)
according to
http://wiki.laptop.org/go/Submitting_bugs
or by notifying us by other means.
Thanks!
Michael
P.S. - I was asked to include to specific notices in this email; first,
that
http://wiki.laptop.org/go/Software_update
gives full details on the new Sugar Control Panel Activity Updater and
second, that we are hoping in future weeks to offer a new "Coordinated
Testing" volunteer opportunity as part of the run-up to the 8.2.0 raw OS
release. Poke me, Kim, Joe, Charlie, S Page, Seth, or Francesca for
details. Sneak preview:
http://wiki.laptop.org/go/Test_cases_8.2.0
15 years, 9 months
Re: OLPC Hosting Application: Fedora on XO
by Jim Gettys
Robert,
It isn't clear (yet) if something gnomeish or xfce is best, given the
target audience (G1G1 users, rather than kids). We'll see. Hackers are
a different audience than most G1G1 users we've had; certainly xfce is
fine for most of us. Only experimentation will tell if a more full
fledged Gnome is feasible for RAM footprint reasons or not.
But most of the point of this is to make installation really easy: to do
that, we'd like a customized fedora spin that can fit in flash
(co-resident with our usual software), so that installation will not
require external media. Most G1G1 end users who get systems can't handle
a long set of instructions such as your page outlines; by making a
fedora spin, we can get the installation down to "olpc-update fedora" or
some such one line command with in place installation. Sebastian has
shown that we can make a spin that is small enough.
Our other goal is, until nirvana arrives (praying it does) and the OLPC
distro is a proper subset of fedora without any broken dependencies,
that it be a fedora spin, so that what a user gets is exactly a version
of fedora, rather than something that may have brokenness if various
software is installed on top of the 8.2.0 release. It's too late in that
release cycle to try to get to nirvana for 8.2.0, and is probably 9.1
fodder. This is for support reasons: we don't want to have to deal with
thousands of support calls
The discussion of this is taking place on the fedora-olpc-list at redhat
com list.
In any case, thanks for all your help!
Best regards,
- Jim
On Thu, 2008-08-14 at 11:22 -0500, Robert Myers wrote:
> Sebastian,
>
> > 4. Longer description : we're going to provide a Fedora-based
> > : "traditional linux desktop" environment
> > : for the XO. if we can, we'd like in allow
> > : a parallel installation of this and sugar.
> >
>
> Sorry, but I don't understand the need for this repository. XFCE is
> already in common use to provide a more traditional windowing desktop
> for the XO. Its use is covered on the Wiki "http://wiki.laptop.org/go/Xfce".
>
> XFCE seems to be a good fit for the XO, full featured enough to support
> most traditional applications, conventional enough to suit the desire
> for a non-Sugar solution, and light enough to install easily. Gnome or
> KDE seem like too much, and the other lightweight environments look a
> little strange to me.
>
> The XFCE page suffers from some poor editing, competing solutions, and a
> failure of the instructions to keep up with changes on the XO, but that
> would seem to be able to be handled there.
>
> Bob
> _______________________________________________
> Devel mailing list
> Devel(a)lists.laptop.org
> http://lists.laptop.org/listinfo/devel
--
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child
15 years, 9 months
Re: Alternate distros from SD
by Jim Gettys
Cool.
On Thu, 2008-08-14 at 11:06 -0400, Daniel Drake wrote:
> Hi,
>
> As mentioned yesterday, me and Bobby spent a few hours working towards
> scripting the process of fixing up a SD-based regular distribution
> install to work on XOs...
>
> We started with Fedora 9 and had to make the following changes:
> - OLPC kernel (testing branch) and modules with a slightly modified
> config (building stuff into the image to avoid needing an initramfs)
> - /dev/console needs to be added to Fedora install when you aren't
> booting with an initramfs
> - /boot/olpc.fth boot script needed
> - Display settings from XO's xorg.conf required to avoid things
> looking really funky
>
> Things work quite well from that point. Wireless works, suspend too,
> mouse/keyboard just fine, ...
>
> More on the initramfs thing:
> Fedora doesn't like being booted direct from disk when the disk is
> mounted read-only (it tries to write to various files). So we had to
> drop the 'ro' boot parameter. That makes Fedora attempt to e2fsck the
> root partition when it is mounted read-write, so you get something like
> the following prompt on each boot:
> running e2fsck on a mounted partition is really dangerous, continue?
> (y/n)
>
> We then used the F9 initramfs, which worked (despite about 20 errors
> that it couldn't find modules or modules.dep, as you might expect). The
> best solution may be rolling a minimal initramfs for our case.
>
> After figuring out the above, I wrote scripts that will take a SD card
> where F9 has been vanilla-installed, and it will make the above changes.
> TOTALLY UNTESTED but if you want to look, its at
> git://dev.laptop.org/~dsd/XO-alt-distro
>
> Will probably spend a few more hours on this on Friday or Monday
> evening. We also want to look at the latest alphas for F10 and Ubuntu
> intrepid.
>
> I also looked at the USB key that Jim gave me, with his custom minimal
> fedora spin. I added my OLPC kernel from above and booted manually using
> openfirmware. The initramfs is absolutely needed here because there is
> no root fs on the card - the initramfs presumably mounts the squashfs
> image and then pivots into that. I reused the existing initramfs
> unmodified.
> That initramfs tried to load various modules and failed as expected, but
> it has logic to abort when such failures are detected. Didn't get any
> further than that. It'll certainly require modifying or re-rolling the
> initramfs to get this booting on XO.
Yes, it probably loads some modules from the image, and loses; we need
to respin the image so the modules and the booted kernel matches, I
suspect.
If the live CD image then boots, install to disk would be one way to get
it onto the SD card.
>
> Another funky bug: sometimes sdhci fails to initialize during boot,
> giving an odd error message which we didn't write down (some kind of
> command timeout). This is odd given that we're using an OLPC kernel and
> I don't think we've seen this on the XO?
>
Interesting. Deepak, any clue?
- Jim
--
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child
15 years, 9 months
OLPC kernel repository
by Sebastian Dziallas
Hi all,
I've been looking around for a repository containing the OLPC kernel,
which we wanted to include in our "Fedora on XO" effort.
Well, I came across this repo [1], which seems to include the packages
with the olpc-3 tag in koji. There's also a kernel in there, but I doubt
that it's the official OLPC one, since it has the same version number as
the one running on my local F9 machine! So far, no luck.
Robin's wiki page [2] concerning the forked packages states that the
kernel is "(not built in koji right now) Deepak Saxena will provide more
details later."
So how to get a repo with the OLPC kernel? Robin made me aware of this
one here [3] (thanks! :)). Is this the correct repository? There are
some kernel builds in there, but I also found recently this page on the
laptop.org wiki [4].
The two given links there to the master and stable branch contain both
RPMs, which are, according to the wiki, rebuilt every 30 minutes...
Do we need to use them? Or is there any other location for the kernel,
we're missing?
--Sebastian
---
[1]
http://koji.fedoraproject.org/static-repos/dist-olpc3-build-current/i386/
[2] https://fedoraproject.org/wiki/RobinNorwood/OlpcBranch
[3] http://xs-dev.laptop.org/~cscott/repos/joyride/
[4] http://wiki.laptop.org/go/Kernel
15 years, 9 months
Forked packages for OLPC
by Greg DeKoenigsberg
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
./telepathy-salut/OLPC-3
./gnash/OLPC-3
./sugar-presence-service/OLPC-3
./xorg-x11-server/OLPC-3
./texlive/OLPC-3
./NetworkManager/OLPC-3
./olpc-utils/OLPC-3
./poppler/OLPC-3
./abiword/OLPC-3
./xorg-x11-utils/OLPC-3
./ntp/OLPC-3
./pyabiword/OLPC-3
./hulahop/OLPC-3
./python-dotconf/OLPC-3
./sugar-evince/OLPC-3
./sugar-toolkit/OLPC-3
./initscripts/OLPC-3
./SDL_mixer/OLPC-3
./sugar-artwork/OLPC-3
./sugar/OLPC-3
./dotconf/OLPC-3
./xulrunner/OLPC-3
./upstart/OLPC-3
./gnome-python2/OLPC-3
./olpcsound/OLPC-3
./xkeyboard-config/OLPC-3
./speech-dispatcher/OLPC-3
./totem/OLPC-3
./sugar-datastore/OLPC-3
./ohm/OLPC-3
./fedora-release/OLPC-3
./gstreamer-plugins-base/OLPC-3
./pygame/OLPC-3
./totem-pl-parser/OLPC-3
./sugar-base/OLPC-3
./gnome-vfs2/OLPC-3
./telepathy-gabble/OLPC-3
15 years, 9 months
