forked packages
by Jim Gettys
Here's the current list of forked packages from Dennis for the current
OLPC image. Some probably don't need to exist; some are bug fixes, some
are to build a package differently (often to get rid of a dependency).
- Jim
--
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child
15 years, 9 months
Squeak and EToys packages for Fedora and OLPC
by Gavin Romig-Koch
I have posted my first draft of Squeak and EToys packages for Fedora and
OLPC. They are not yet ready for package review, but they are on their
way there. I'm *hoping* I can build .spec files that are usable for
both the Fedora and OLPC distributions. I would appreciate it if people
from both the Fedora and OLPC sides would try them out, and look them
over so see if what I'm doing is going to be acceptable.
http://code.google.com/p/squeak-fedora/
This consists of .spec files, .patch files, and a Makefile to download
upstream "sources" and build packages from them. There is also a TODO
file listing the things I think/know need to work on before these are
ready for Fedora or OLPC.
If you find issues contact me.
-gavin...
15 years, 9 months
Update on Squeak license issue
by Robin Norwood
Hi,
For the few of you who aren't on the extensive Cc list, we've had a
discussion about the Squeak license with Fedora legal (Tom Callaway)
and VPRI (Kim Rose and others).
To summarize:
o As of this moment, there is probably still some code in Squeak that
has not been properly moved to the MIT license. (Mostly because the
original contributors can't be found).
o Fedora can't accept code that is in this state.
o Kim Rose says:
"""
My colleagues, Yoshiki Ohshima and Bert Freudenbeg (along with a few
others) have been reviewing all code and our signed Relicensing
Agreements for the past week or so. I believe they are stripping out
any code that still remains in the image for which we do not have
signed agreements to cover. I will meet with them upon my return
from vacation week of August 18th to see exactly where we stand.
"""
So, it looks very hopeful that squeak will soon be entirely safe to
include in Fedora, and we'll know more after the 18th.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
15 years, 9 months
Re: [Server-devel] Need help: mounting usb devices on headless machines
by Martin Langhoff
On Thu, Aug 7, 2008 at 6:52 PM, James Cameron <quozl(a)laptop.org> wrote:
> Don't know about Fedoristas, but on Debian and derivatives this is what
> I do for a backup disk that is identified by UUID and then backed up to
> ... all when plugged in ... beep ... wait for rsync ... beep beep ...
> pull it out.
...
> echo -en '\007' > /dev/tty1
Well, it *seems* that I cannot get a bell to sound on any of the
systems I can get my hands on today. 2 XS (F7, based) desktop
machines, 3 different laptops (running F9, Hardy), no bell on
ambiguous autocompletion, no audible response to echo -en '\007' on
any tty. Nothing obvious in termcap/terminfo (I'm not too handy with
those but no 'vb' that I can see).
Hmmm. pcspkr.ko is loaded in all of them.
And the web is full of advise on how to *disable* it, so I guess
modern linuxen have disabled it en-masse, using some trick I can't
spot right now. The obvious place is termcap/terminfo, but nothing
there... Ah, grumble.
ideas?
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, 9 months
Re: Sugar on Fedora 10 Alpha - how to I run it?
by Mikus Grinbergs
> Now, when installing into the system with rpm, it would actually make
> more sense to use the standard directory layout. I'm only a little
> worried that it would complicate the build system of activities which
> doesn't use Sugar bundlebuilder.
For me on my XO, it takes less effort to "upgrade" an
already-installed build than to "install from scratch" a build, and
then customize. I recently used 'yum install' to apply Journal-97
to Joyride. [That is, the Journal activity was packaged as an rpm.]
It amused me that this "rpm" install did not update the
version-number in the XO's activity registry. It remained for me to
reboot before the registry showed that 97 had replaced 96.
mikus
15 years, 9 months
Meeting Minutes Friday, August 08 2008
by Robin Norwood
Hi,
Here are the TODOs from the meeting:
** 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
Next Meeting: 1700 UTC / 1pm Eastern US time Friday, Aug 15
Here is a rough IRC transcript. I tried to break things out by topic
and clean up some chatter.
<gregdek> I spent the week at OLPC HQ in Cambridge...
<gregdek> (yes, cjb, can you do that? thx)
<gregdek> ...and learned a whole bunch of stuff, and articulated some
goals a bit more clearly. <gregdek> So I'm going to throw out a couple
of projects that I think could be (relatively) low impact and
(relatively) high reward, and then open the floor for discussion about
what it'll take to get there.
** TOPIC: Sugar spin for Fedora, including bootable live CD.
<gregdek> POTENTIAL PROJECT #1: The Sugar spin for Fedora, including
bootable Live CD. <gregdek> WHY? Because there aren't enough
developers who can just take Sugar for a spin without lots of bizarre
incantations. <gregdek> By building and maintaining the Sugar packages
in Fedora (and elsewhere, but we care about Fedora) we can dramatically
expand the "geek user base" and thus the potential developer base.
<gregdek> So that's the goal. <gregdek> ...let's dig into that.
<jg> a piece of this project is helping marco with packaging of sugar,
and testing.... <jeremy> that's actually probably one of the bigger
pieces to be honest
<gregdek> We've got people already digging into building Sugar packages.
<jg> first step is that sugar becomes another desktop like gnome or
kde, and you log into sugar.
<gregdek> First step is that we get all the important packages
built. :) <jeremy> gregdek: very much so
<jg> "yum install sugar" should be the goal ;-).
* jeremy has started making some progress there
<jeremy> jg: 'yum groupinstall sugar-desktop' but yes :)
<jg> marco has the base packages packaged; but activities are not
packaged as rpms'.
<rnorwood> the wishlist is currently here:
http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist
<gregdek> Actually, this list represents multiple projects, and I
wonder if we should be breaking them out and tracking each project's
needs separately. <gregdek> For example: <gregdek> * XS packages
<gregdek> * Fedora on XO hardware packages <gregdek> * Sugar on Fedora
packages
<gregdek> So the next question: is the current wishlist-on-wiki
mechanism the right one?
<gregdek> Is it true that SL is trying to create different levels of
Sugar activities to indicate relative levels of stability? <cjb> Hm,
don't think that's been ratified properly. But we've certainly
struggled with that question in lots of places. <cjb> For example, just
for OLPC -- which activities should OLPC "support"? <jg> as few as
possible ;-)... <gregdek> My sense is that some activities are "core"
to the sugar experience and should definitely be prioritized. <jg> and
as many as necessary ;-) <gregdek> journal, browser, pippy, for
example. <gregdek> jg: You are a master of policy declaration. ;)
<cjb> Yeah. We've sort of used the list activities we shipped with the
original G1G1 as that list of "core", but not all of them are actually
maintained. <gregdek> Doh.
<gregdek> So I assume that there will exist, at some point, a set of
guidelines for what are "supported" and "unsupported" activities that
fall out of Sugar Labs discussions. <gregdek> But until that point,
what's our policy? <gregdek> "Package what we can find tarballs for"?
<cjb> gregdek: It's a bit of a bone of contention, but the G1G1 set
seems agreeable. (And I think it's what's been packaged already.)
<unmadindu> gregdek, cjb: or as a priority, we might want to package
whatever is there in
http://sugarlabs.org/go/ReleaseTeam/Roadmap#Fructose_Modules <cjb>
unmadindu: yup, looks right <jeremy> unmadindu: that's probably as good
of a starting place as any
<gregdek> Don't we have packaging guidelines for activities already for
activities on the Fedora wiki? <rnorwood> gregdek:
http://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines
<rnorwood> gregdek: the language issue that jeremy pointed out on the
ML being the biggest issue, It hink. <jeremy> rnorwood: there are a
couple of other things that feel like they could be better after doing
a couple of pakcages. once I have a few more done, I suspect I'll have
a better feel for "right"-ness <jeremy> gregdek: that's required for
inclusion in fedora <gregdek> So we're basically packaging these
directly from the source. Which means we are making rpms rather than
xos. <rnorwood> gregdek: I think in fedora terms, we just ignore the
concept of .xos <gregdek> I think that has to be right.
<cjb> Yeah. :) There have been "why not make .rpm be the .xo file
format?" discussions, I don't recall the outcomes. <jeremy> cjb: and
while that seems an interesting discussion, perhaps a tangent for this
meeting :)
<gregdek> So let me spell out the simple action items so far:
<gregdek> * Split out the wishlist into appropriate package sets (XS,
Fedora for XO, Sugar for Fedora, activities) <gregdek> * Point folks in
the wishlist to Fructose/Sucrose list and activity packaging guidelines
<pgf_> so this means there will be two formats used for installing
activities? rpm and xo? (i'm just trying to understand.) <gregdek>
pgf_: It's a fair question. <gregdek> pgf_: Users will always have the
option to install .xo files locally. <jg> pgf_: for a conventional
fedora desktop, you'd like to be able to do a yum install.... <pgf_>
okay. i'm convinced. :-)
<gregdek> One other thing:
<gregdek> Is it possible to associate a date with the wishlist items,
so we know which stuff has just been sitting, if it comes to that?
<gregdek> Or is that overkill? <rnorwood> gregdek: It's good practice
to include a date, yeah. <jg> heh. I think it makes sense if someone's
name is also attached.... <gregdek> Well, that's where I was going
next... <gregdek> :)
<gregdek> Or at least be able to say "unclaimed" or something.
<gregdek> We edge closer to trac tickets with every data field we
add... but I'd kind of like to hold off yet. :) <rnorwood> gregdek: so
when you start work on 'something', attach your name and date. Add
links to issues/bugs/discussion as needed, and remove it when it's
accepted into fedora.
* jeremy is making a table for the activities that should help...
<gregdek> Thanks, jeremy. :)
<gregdek> Hey jeremy, since you're building the table, do you want to
do the initial sort of the packages too? <jeremy> I'm trying to do that
too <gregdek> Very good.
* gregdek writes down "jeremy" in the big book of TODOs.
<gregdek> So down the line, once we've got these packages in...
** TODO: jeremy to build table of sugar activities to package as work
items.
<gregdek> ...the next question is "what needs to happen to allow us to
boot Fedora into Sugar instead of GNOME/KDE/xfce/wtfwm? <gregdek> Can
we add this feature to the F10 roadmap? <jeremy> gregdek: it should be
easy to do when we update the sugar packages. I can work with marco to
make sure it happens <gregdek> Needs a feature owner. jeremy, will
that be you, too? <rnorwood> gregdek: but the feature is a little bit
more than GDM. <gregdek> rnorwood: Such as? <gregdek> Maybe someone
needs to write a feature spec. <gregdek> Someone who volunteers the
notion that "the feature is a little bit more than GDM," maybe.
<rnorwood> gregdek: well, just 'make sugar work' and the other stuff
we're already planning to do. <rnorwood> gregdek: 'sugar works and a
reasonable set of activities packaged' <jeremy> I can probably throw
the start together and then make rnorwood help ;) <gregdek> ...my take:
if the feature is "allow GDM to boot Sugar in F10," that sort of
encapsulates all the rest of the work, yeah. <gregdek> ...I kinda think
that covers must of the "Sugar on Fedora" ground, amirite? <rnorwood>
gregdek: yup. Jeremy to do initial feature page, and press-gang
rnorwood to help
** TODO: jeremy to build initial
** TOPIC: Fedora on the XO
<gregdek> WHY? Because Sugar isn't "there" yet for a large segment of
the XO/G1G1 userbase, and despite numerous warnings that it's "not a
laptop project", people continue to expect it to be a standard laptop.
<gregdek> Which means that we're exploring dual-boot options of "Sugar"
or "some minimal straight Fedora". <gregdek> Which means that we need
to build a "minimal straight Fedora" that actually boots on the XO.
<gregdek> Which depends on people who have the hardware! <jeremy> which
depends on people that have the hardware
<jeremy> the thing that I don't entirely understand (maybe because I
haven't played with the hardware as much) is why this really entails
any sort of separate spin <jg> rnorwood: the problem is, then our
friends in redmond have another weapon. <jeremy> and isn't just people
making sure the hardware is well supported in fedora <jg> jeremy: size.
<gregdek> Other than a different kernel and some dependency
breakdowns... <jg> jeremy: RAM usage of some apps. <gregdek> ...but
maybe this is an opportunity to break down some deps in Fedora itself.
<jg> jeremy: audience.... <sdziallas> gregdek: yeah, definitely!
<gregdek> Like the fact that PersonalCopy-Lite is the biggest package
in the spin currently. :) <jeremy> jg: RAM usage of the apps -- fix
the apps, don't skirt the issue by forking things <jg> jeremy: somehow,
fixing evolution ain't going to happen overnight.
<jg> jeremy: I need something *quickly*.
<sdziallas> gregdek: I was able to ship around this libgweather stuff
(it was NetworkManager-gnome related), but this one could be fixed, too
<jeremy> and if the idea is that people with a g1g1 think that the xo
is a laptop and expect it to act like one, then they're going to just
expect fedora to *WORK* <jeremy> not go use some weird off to the side
thing <bryan_kearney> sdziallas: on a side note, could you send me the
kickstart file? bkearney(a)redhat.com? <sdziallas> bryan_kearnay: sure :)
<jg> jeremy: we have at least two alternatives for mail: thunderbird
and claws. <gregdek> I think that there's the ideal, and then there's
the pragmatic.
<jg> evo is not required.
<sdziallas> jg: agreed!
<jg> and it will send an interesting message to the evo folks ;-).
<gregdek> The pragmatic: we must provide *something* that is more
familiar than Sugar. <jeremy> jg: both of which are similarly bad in
memory usage to evo (or worse in some cases). I've used them
all :( <rnorwood> so - 1) Hardware support/kernel, 2) Install
size/deps, 3) RAM usage of some apps/evolution sucks <gregdek> Even if
it's not the best Fedora experience one might otherwise have. <jg>
jeremy: but evo comes with 50 meg of help png images: we can't afford
the flash load for evo.
<rnorwood> what about gnome/xfce
<rnorwood> ?
<jg> jeremy: need a "run out of flash" option.
<gregdek> The spin sebastian made was xfce-based.
<cjb> I think we're going to want GNOME
<jg> rnorwood: that is another option.
<rnorwood> (vs)
<cjb> oh :)
<gregdek> :)
<sdziallas> bryan_kearnay: e-mail's out
<sdziallas> well, I'd have wanted, too
<gregdek> So here's my question.
<jg> first thing to do is to get one working, and look at the RAM
footprint. <cjb> I'd like the full NM applet, full i18n, that kind of
stuff. <gregdek> Can straight Fedora work, if the kernel issue is
sorted? <jg> heh.
<jeremy> jg: it depends on what you're targeting as to what the need is
<cjb> plus we know a lot more about hacking on GNOME than on xfce,
speaking for the people in this channel. <jg> Ii8n is another problem.
<jeremy> jg: if you have more you're not saying that flows into the
need, I'm ears :) but nothing that's been said thus far really sounds
like that's the case <jg> turns out that the stock fedora CD space is
is dominated by eastern fonts and input methods. <cjb> I don't want to
end up in a situation where we get xfce and then we get feature
requests on high to add features to xfce that GNOME already has :)
<sdziallas> well, when doing the test runs on my machine here, every
gnome-based image was at least 100 mb larger than the xfce-based one
<gregdek> cjb: -EINGNOMEALREADYWONTFIX
<gregdek> I just want us to get to something that boots.
<gregdek> That's the first step. :)
<cjb> that'd be a good start, indeed.
<jg> jeremy: the same people who buy and OLPC thinking it is a
conventional laptop (despite our warnings) are the kind that want
something a bit more than xfce (at least when I've played with it).
<jg> gregdek: I agree entirely. <jg> that's the next step.
<jg> now we know we can build spins that are acceptably small.
>walters< That was quick. ;-)
<rnorwood> walters probably has some feedback about gnome-vs-xfce on
fedora-XO spin <gregdek> jeremy is coming to 1cc next week!
<cjb> yay!
<gregdek> That's the resolution. You guys can slug it out. Just get
something that boots plz, kthxbye. :) <jg> sounds good.
<walters> if anyone comes up with any hard data on why/how xfce is
smaller please do let me know <jeremy> and greg is now a lolcat
<jg> walters: I suspect icon files.
<jg> I haven't gone and looked carefully.
<gregdek> hai! can i haz bootfedoraxo?
<walters> jg: elaborate?
<rnorwood> walters: this is just a preliminary discussion, not
'decision time', fwiw <jg> there are png files for several sizes of all
the icons. <sdziallas> walters: fewer deps.
<jg> we can pick just one.
<gregdek> Yes.
<jg> and nuke the others.
<gregdek> We can just pick one.
<sdziallas> jg, gregdek: +1 :)
<gregdek> When the time is right, we can do all these things.
<cjb> By the way, dwmw2 boots stock Fedora on external USB hard disks.
<gregdek> Oh, he does, does he?
<cjb> so I don't think there are any large obstacles. someone
mentioned a kernel problem of some kind? <gregdek> I wonder why that
didn't work for us? <jg> heh.
<gregdek> Maybe we just used the wrong incantation.
<jg> different incantations.
<jg> I'm not an OFW incantation expert.
<cjb> yeah, seems like it should have worked, with F9.
<cjb> ah, that might be it.
<jg> cjb: no, some stuff went in after F9.
<gregdek> All right.
<jg> to kernel.org.
<gregdek> I think the devil is in the details here...
<jg> I betcha you need an updated kernel.
<gregdek> ...and I think we can trust jeremy to sort these out in 1cc
next week and report back next Friday? <jeremy> bah, who runs f9
anywya? rawhide everywhere! <cjb> maybe. you could even just use our
kernel. <jg> and our kernel still carries patches not yet in kernel.org.
<jg> that's the plan.
<gregdek> Brillianr.
<gregdek> t.
<jeremy> cjb: or maybe you could just use ours ;)
<cjb> we should also talk about getting a Rawhide OLPC stream at some
point. We're on F9 now, but we can rebase to F10 for our next release
(due around Christmas, I guess) <cjb> jeremy: we're trying! <gregdek>
Heh. <jg> ofw2 will probably make it much easier for a generic linux
kernel to "just work". <cjb> I think everything to enable booting an XO
on stock distros is upstream now <gregdek> OK.
<jg> but right now, it won't.
<gregdek> So...
<cjb> which is a pretty big step, it took a lot of work, we have custom
display hardware and all that stuff --- stickster is now known as
stickster_mtg <jg> cjb: but you still have to build for OLPC.
** TODO: jeremy to go to 1cc, revisit next week.
** TOPIC: Squeek/etoys licensing.
<gavin_> VPRI believes that they have done enough work to change the
licence to MIT, <gavin_> Will Red Hat legal except that, or ....?
<jg> gavin_: there is *no* license issue for squeak now, I'm aware of.
<rnorwood> gavin_: spot is The Legal Contact.
<gregdek> Yeah, so what are we talking about?
<jg> the last sillyness is that squeak has a binary blob, not rebuilt
each time. <gregdek> Right.
<gregdek> That's the real pain, from what I hear.
<cjb> likewise. VPRI say it's now BSD-licensed, I don't see who we are
to argue with them. <gregdek> Do we know why that is?
<jg> said binary blob can export every line of smalltalk that is in it.
<cjb> gregdek: it's just the development style. it's a feature.
<jg> so it is sillyness of people who don't understand about smalltalk.
<m_stone> gregdek: they come from a different school of programming.
<jg> or similar environments.
<cjb> they have total introspection of the blob, so they don't feel a
need to rebuilt it from scratch very often. the blob is the preferred
format for modification for them. <gregdek> Right. <gregdek> Which our
packaging standards totally don't account for. <cjb> I don't think
there's any legal issue here, just some people find it distasteful that
they can't diff it etc. <jg> people who've never seen introspection,
don't comprehend. <gregdek> So when you can actually create all source
on the fly from the binary, you are by definition shipping source?
<gregdek> Is that the contention? <rnorwood> So are there tarball
releases of squeek/etoys that say "I am MIT (or BSD) licenced"? <jg>
the binary *is* the source. <jg> rnorwood: I believe so. <cjb> gregdek:
I think there is source available too? It's just that the interpreter
isn't created from it each build. <rnorwood> Or an SCM we can pull
from? <cjb> rnorwood: Absolutely. <jg> rnorwood: the scm is *inside*
the squeak environment. <cjb> rnorwood: The problem is that VPRI had a
handful of decades-old contributors that they couldn't get agreement to
change the license from. <rnorwood> cjb: Ok - put it on the wishlist
page
( http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist )
<jg> it is entirely self-contained. <cjb> And they decided, given like
490/500 people who agreed to the change and 10 who were uncontactable,
to go ahead and change the license. <gregdek> I don't even know how to
begin to tackle the packaging issues. Maybe someone can get this issue
in front of FESCO? <cjb> I think spot was dubious that that was legal.
<rnorwood> cjb: Yeah, that may or may not be a problem. Spot is the
guy we need to interface with to get legal to make a call. <jeremy>
cjb: that's pretty dubious <gregdek> So it comes down to: <cjb> jeremy:
They'd be happy to rip out those people's code if they complained.
<jeremy> cjb: unless the contributions by those ten people are
insignificant/obvious <rnorwood> cjb: So Red Hat legal makes those
calls for us. <cjb> jeremy: I don't think any of them were major
contributions <jeremy> cjb: the problem is that you have to assume they
complain and rip the code out <cjb> rnorwood: yeah. so, that's the
problem, anyway. <cjb> if I were a lawyer, I'd say "don't possibly do
anything that sort of contributes risk to someone" <gregdek> So it's a
matter of comparing Fedora's risk profile with VPRI's. <rnorwood> cjb:
ok - how about you, jg, and anyone else who wants to be on the Cc send
me your email address and I'll start a conversation with spot about it.
<rnorwood> cjb: and see what he thinks the best way to proceed is.
<cjb> rnorwood: sounds good <gregdek> OK. Thanks, rnorwood. <jg>
rnorwood: bert freudenberg is the other person to be involved, on the
VPRI side. <gavin_> me too they've been working on for 20 years and
then have some random other group tell them they aren't allowed to :)
<gregdek> Well, it's tradeoffs, isn't it? <gregdek> "Hey, we'd like to
make your software available in one click to millions more users.
Accept or deny?" <jeremy> cjb: they can do whatever they want, but that
just means that it can't be in fedora <cjb> nod.
>cjb< hey, what's your email addy so I can Cc: you on squeek/etoys
>license issue
<gavin_> I was planning on takeing the squeak blob issue to FONC ...
<gavin_> does any one think that's unnecessary?
<gregdek> Maybe wait for legal to come back?
<rnorwood> cjb: well, if the answer is 'Our lawyers say this is legally
dubious, let us help you rip out the offending code...' <jg> jeremy:
the've been leaning over backwards as it is; but people who don't
bother to comprehend that environments like smalltalk are built in
fundamentally different ways than UNIX/Linux and complain they are
different (and they started first!), I have less patience for. <gavin_>
don't conflate the legal issue with the blob issue. <gregdek> Agreed.
<rnorwood> gavin_: sure. <jeremy> jg: the blob issue is different from
the licensing one <gregdek> If you want to attack both separately,
that's fine. <gregdek> But understand that progress on one blocks
implementation on the other.
>gavin_< Do you want me to Cc you in convo about the license issue? If
>so, what's your email addy?
* jeremy knows he does not know enough right now about the blob to say
anything intelligently one way or the other <gregdek> Doesn't mean the
issues can't be worked in parallel. <gregdek> Just that there's risk
that such work might end up useless. <rnorwood> gregdek: +1. gavin_ to
drive the blob issue, /me to drive the license issue. <cjb> yes, the
blob thing sounds like a non-issue. Some grumpy Debian people said
that if it can't be diff'd it's not "open source", which is ridiculous.
<gregdek> Heh. <gregdek> Let's try to be more reasonable than that. ;)
** TODO: rnorwood to track down the squeek/etoys licensing issues
** TODO: gavin to track down the squeek binary blob issue
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
15 years, 9 months
Introduction... (and OLPC Fedora spin).
by Jim Gettys
Hi,
I'm Jim Gettys, and I worry about much of OLPC's software and how it
fits together....
This instant, I've been investigating with Gregdec and Sebastian
Dziallas the feasibility of a more "conventional" fedora desktop to run
on the OLPC. The observed problem is that many people who get OLPC's as
part of G1G1 often don't read our warnings, and end up unhappy that they
get only Sugar, no email program, etc.... Since it is called a "laptop"
they have preconceptions kids don't.
Sebastian has done a spin that is only 550 megabytes (squashfs, so in
jffs2 it would be somewhat bigger) for a small set of western languages.
This isn't runnable yet (on the OLPC), but shows something useful can
easily fit. It turns out that several hundred megabytes are just fonts
and other localization files for Japanese, Chinese, etc. And yes, the
intent would be sugar would be included in this spin (whether all common
activities will fit, is much less clear).
If we go ahead with this, we'll need all the help we can get from fedora
folks....
In the fullness of time, nirvana would be that fedora might be
configured small enough (in a simple way) to at least match the size of
the minimal OLPC load (which is several hundred megabytes smaller).
This space is needed so that flash can be used mostly for books and
other content on 1 gig systems. If so, the OLPC software for the XO
could become just a fedora spin. Whether nirvana can be reached isn't
yet clear; lots of people are very sloppy about dependencies, and some
essential pieces are currently huge for bad reasons (like all glibc
locales live in the same file...).
- Jim
--
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child
15 years, 9 months
Kickoff meeting: 1700 UTC / 1pm Eastern US time today
by Greg DeKoenigsberg
We've been talking about it. Now we'll have it. Join us on freenode,
#fedora-olpc, at time in $SUBJECT.
The primary topics:
* Sugar on Fedora. How's it going? What's our goal? How do we create
and track actionable work items?
* Fedora on OLPC. Ditto.
* Other business people want to discuss.
See you all at 1pm Eastern US time.
--g
15 years, 9 months
Help with admin tasks
by Marco Pesenti Gritti
Hello,
we need to tag the following package for dist-olpc3:
sugar-base-0.82.1-1.fc9
sugar-datastore-0.82.0-1.fc9
sugar-toolkit-0.82.0-1.fc9
sugar-artwork-0.82.0-1.fc9
sugar-0.82.0-1.fc9
Dennis has been doing it for us, but he is not working for OLPC anymore.
Suggestions on how to handle it in the future? It would be nice if
either one of us could get permissions to tag these, or if a Fedora
admin would make himself available to do it...
Also I'm trying to build a package depending on the above sugar-toolkit,
but the old version is pulled (the new one was built a couple of hours ago).
http://koji.fedoraproject.org/koji/taskinfo?taskID=765163
Any idea why it's not in the buildroot yet?
Thanks!
Marco
15 years, 9 months
Need help: mounting usb devices on headless machines
by Martin Langhoff
Fedoristas in the crowd,
I am trying to find a tool that allows me to
- automount usb devices when they are plugged in (via udev/hal)
- would be nice to support removable devices
- trigger an associated script on mount
- all on a headless server!
There is no udev/hal automounter that works on headless servers
currently shipping on Fedora. Ivman is packaged, but not shipping
currently (dead upstream, very cumbersome config). Working with the
lvman config files is _not_ fun, and not modular at all - if several
school server pacakges want different things, it'll be a mess.
I have found an alternative that I like more, usbmount, which seems to
work, is trivial to configure, provides the subset of Ivman that I
need, and makes it simple for other packages to drop hook scripts
into place via /etc/usbmount/mount.d . It doesn't have an active
maintainer though.
So I need some help :-) and it's not too complex.
Option one - point me to something that works and is maintained -- if
you know of a good reliable tool that I missed, I want to know. Can
you help me configure it for this task?
Option two - help me package & tweak usbmount for F7 and F9. The
codebase is *tiny*, we can carry it.
Option three - you are very keen on wrangling ivman's complexity and
baroque xml. Grand! Let's teach it to do /etc/ivman/conf.d/ :-)
Option four: anyone with a better plan?
I'll probably start chipping away at #2 tomorrow...
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, 9 months
