Creating a spin - any mechanisms around $product-release, $product-release-notes, $product-logos packages...?
by Martin Langhoff
I'm finishing off the F9 port of the OLPC School Server, and as part
of that I'm preparing xs-release, xs-release-notes and xs-logos
packages.
As far as I can see, these are pulled because they provide
system-release and system-logos. fedora-release-notes is pulled in by
fedora-release, and perhaps by something depending on indexhtml
(httpd?).
My key question is: will anything in the Fedora machinery (anaconda,
rpm, yum) be looking for a magic "product" name, and then try to use
it to request $product-release?
(I ask to be safe - recently got very confused by anaconda not
upgrading Fedora-based spins due to mismatching 'product' between
.discinfo and /etc/redhat-release . Knowing these special rules is
important ;-) and I have not found yet any document laying out the
subtle traps awaiting anyone doing a Fedora derivative as I am
doing...)
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
A few F9 upgrade things I need help with...
by Martin Langhoff
As part of the XS upgrade, I've ended up caught with a number of F9
oddities -- none of them a complete blocker, but definitely rought
edges...
- Cannot include beecrypt in Pungi/Revisor build - this is probably a
bug worthy of filing in BZ but needs a bit of diagnosys.
http://dev.laptop.org/ticket/8363
- Anaconda conflicts with xs-config - Filed as BZ 461550
http://dev.laptop.org/ticket/8366
- Anaconda crash during install with USB-disk-based ks.cfg BZ 461453 -
this probably affects all USB-disk based installs.
- Anaconda: Install from USB disk: only ISO picked up BZ 461548
- Anaconda: Install from USB disk: Awkward to provide a ks.cfg BZ 461549
All of these are - I think - worthwhile to whack for the
ease-of-install experience with Fedora and the XS...
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
Progress on a Fedora Spin...
by Sebastian Dziallas
...progress wherever you look...
We've done quite a big step forward in minimizing the size of a Fedora
Spin - thanks Jeremy! I've been creating spins over the day lately and
with the latest commit on livecd-tools, I'm more than happy that the
--instLangs argument for kickstart files does now work.
What does this mean? Well, we're able to reduce the size of the final
image heavily, so that we'll end up with more than 100 MB less of
/usr/share stuff on the spin.
Where are we now? I've been rebasing the spin to Rawhide (F10), which is
still not that stable now, but I think this will change more soon than
late. The latest image I built has a size of 323 MB (!) - excluding
claws-mail due to some dependency issues in Rawhide right now.
Apparently, there's still some cups and other stuff in there, so we
might still get lower...
I'm pretty excited and would really like to thank Jeremy for his work :)
--Sebastian
15 years, 8 months
Sugar group?
by Marco Pesenti Gritti
Hello,
now that we started to package activities, should we create a Sugar
group in rawhide?
It would be nice to be able to just "yum groupinstall Sugar"...
Marco
15 years, 8 months
OLPC kernel patches not upstream yet...
by Jim Gettys
Jeremy Katz asked the reasonable question of the feasibility of Fedora
carrying patches in advance of kernel.org, for stuff destined to
eventual inclusion. I quickly checked with Andres on the current state
of what isn't upstream in kernel.org.
There are two big items left (for this round changes; if we can really
get to things like fixing USB resume, there are likely more such in the
future...).
o The device tree patch; the hold up here is that there are multiple
implementations of this on Sparc, PPC, and now x86, and no current
agreement among the guilty on which should become the "standard"
version. Until/unless the kernel community can come to consensus, this
seems something not reasonable for a fedora patch. Andres would like to
hear from davem in particular on this topic. And we *might* get more
insight week after next after the kernel summit.
o the touchpad driver for our ALPS touchpad. We're finally likely to be
able to come up with something reasonable now that the EC code problem
has been found, that won't be full of so many one off hack work-arounds.
As this is a separate driver for unique hardware, this seems like
something that could go into Fedora without likely headaches, if someone
wants to keep it synchronized. But I think the standard touchpad driver
does at least "work".
Note that this presumes we're still using at least a OLPC .config file
going forward as we don't have VESA support for booting in our firmware
(we use fbdev), so a generic x86 Fedora kernel won't boot. We also
don't want/need to carry the over whelming ton of device drivers, mostly
for hardware that can never be plugged in, just for space reasons. It
would certainly be nice someday if a generic x86 kernel could boot (and
a standard Fedora desktop spin); I'm not exactly sure what that would
entail at this point, but for now, this seems like a more speculative
question and beyond the initial time frame for G1G1. I'm personally
also by far mos comfortable using a kernel that is as close as possible
to what we've been testing for our 8.2.0 release at this date, for
support reasons.
Jeremy also noted a bit of version skew between the fedora and olpc rpm
spec file that could/should be resolved; there were a couple of trivial
config file changes that enables something build from the OLPC kernel to
be used in a Fedora spin (the squashfs patch, which all distros carry
but isn't in kernel.org, and one other item that I forget).
Andres, Deepak, did I miss anything?
- Jim
--
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child
15 years, 8 months
Notes from Friday's meeting
by Greg DeKoenigsberg
Sorry for being a bit late presenting these notes. I also apologize for
the format -- I will be basically managing the task list and keeping notes
there.
The URL for the latest task list, as a reminder:
https://fedoraproject.org/wiki/OLPC/Tasks
===
Task Name Owner Priority Target Date Status/Notes
Figuring out how to create small localized spins SebastianDziallas, gettys
1 Update on 9/12 How can we make small images by cutting out unnecessary
language info, and make particular builds that are customized for
particular languages? Sebastian and Jim continue to work on this.
Recommending SD hardware for Fedora JeremyKatz 1 Update on 9/12 Microsoft
has already done a lot of working figuring out which SD card will work
best with their OS; we should leverage that work to figure out what SD we
should be offering to G1G1 users as the Fedora add-on.
pyxcom/xulrunner issues JeremyKatz / ChrisAillon 1 Update on 9/12 In order
to get the Browse activity to work properly natively to Fedora, we need to
resolve the xulrunner fork in OLPC repos -- ChristopherAillon is trying to
get those changes upstream, but is still on vacation.
Packaging Sugar activities GregDekoenigsberg 1 Weekly update We need to
closely track to the packages listed on the [roadmap] with the package
requests that are tracked on the [wishlist page].
Python performance issues between F7 and F9 MarcoPesentiGritti 1 Update on
9/5 Python in F9 is much slower, making Sugar performance painful --
gregdek will try to put the Sugar folks in touch with the Python experts
in Fedora.
Installation path JimGettys 1 Update on 9/12 What's involved in
installation onto internal NAND? What's involved to be able to use
olpc-update? What needs to be done to ensure wear levelling? Jim Gettys
will lead a discussion on-list.
Bug tracker JimGettys 1 Update on 9/12 How do we track various work items
that are non-obvious? JimGettys will lead a discussion on-list.
--g
15 years, 8 months
An idiot installs Sugar on rawhide
by Greg DeKoenigsberg
That idiot is me.
I installed Rawhide as of September 5th, a minimal install. Here's what I
did, and what happened. Cut to the end for my idiot follow-up questions.
:)
===
1. yum install sugar
Installs 20 packages. Great.
===
2. sugar-emulator
Breaks. Still not installing Xephyr. Hmm.
===
3. yum install xorg-X11-server-Xephyr
Installs Xephyr. Great.
===
4. sugar-emulator
Traceback, as follows:
Traceback (most recent call last):
File "/usr/bin/sugar-shell", line 30, in <module>
from main import main
File "/usr/share/sugar/shell/main.py", line 34, in <module>
import view.Shell
File "/usr/share/sugar/shell/view/Shell.py", line 38, in <module>
from view.frame import frame
File "/usr/share/sugar/shell/view/frame/frame.py", line 29, in <module>
from view.frame.activitiestray import ActivitiesTray
File "/usr/share/sugar/shell/view/frame/activitiestray.py", line 23, in
<module>
from sugar.graphics.tray import HTray
File "/usr/lib/python2.5/site-packages/sugar/graphics/tray.py", line 22,
in <module>
from sugar.graphics.palette import Palette, ToolInvoker
File "/usr/lib/python2.5/site-packages/sugar/graphics/palette.py", line
922, in <module>
class WidgetInvoker(Invoker):
File "/usr/lib/python2.5/site-packages/gtk-2.0/gobject/__init__.py",
line 40, in __init__
cls._install_properties()
File "/usr/lib/python2.5/site-packages/gtk-2.0/gobject/__init__.py",
line 68, in _install_properties
" or getter. This is not allowed" % (cls,))
TypeError: GObject subclass <class 'sugar.graphics.palette.WidgetInvoker'>
defines do_get/set_property and it also uses a property which a custom
setter or getter. This is not allowed
===
So. Idiot questions!
1. Who owns the Sugar package, and should we be adding
xorg-X11-server-Xephyr as a dependency?
2. Why am I getting this traceback? I'm guessing it's another dependency
that isn't getting installed, but I don't know what it is.
--g
15 years, 8 months
Current state of conventional file systems on Flash & Linux....
by Jim Gettys
I had a conversation with Dave Woodhouse this morning, that people
should internalize.
The wonderful demoing of running Fedora, Debian, Ubuntu on a SD card,
without thought about where what is stored, is something likely to come
back to bite us downstream as people use it as a serious support
problem. There is real danger, particularly on commodity media, of
wearing out the flash device.
We need to give serious thought to where what gets stored, on what file
system. The only wear leveling we can *count* on is on JFFS2 on our
internal flash. And we can strongly encourage the use of particularly
"good" vendors/models of flash.
- Jim
<jg> If you are running a conventional file system on a flash device,
what's the right solution for wear leveling right now for conventional
SD or USB.
<dwmw2> Prayer. .
<dwmw2> SD and USB stuff -- none of the things with the built-in
translation layers -- have ever been observed to be reliable enough to
contemplate using them.
<dwmw2> although hopefully the new set of SSD stuff for laptops will
mean they have to improve.
<dwmw2> but you can't really know what's going on under the covers.
<jg> yeah, I know I can't rely on the hardware.
<dwmw2> They might be doing some form of wear leveling; they might not
<jg> the question is, do we have any wear leveling software layer?
<dwmw2> often, if the devices do, they'll do it within certain regions.
Not really for wear leveling on a block device. We have stuff like FTL
which lets use emulate a block device on top of real flash and that
obviously does wear leveling, but we don't have anything which will
deliberately spread writes around on a block device.
That probably would want to live in the file system itself, rather than
a block<->block mapping layer -- although I dare say you _could_ do it
with some kind of DM plugin; it's probably something we should look at
doing in btrfs. Btrfs has a 'wandering tree' setup, a bit like logfs.
I'm planning to see if I can make it work on raw flash, too. Should be
really good.
<jg> ok, for now, you *really* want to be careful on what you put where
you put what, and what kind of media you use if you put a conventional
system, say, on SD, to get the best you can get on wear characteristics.
<dwmw2> yeah. I wouldn't want to bet the farm on SD or _anything_ which
does internal stuff for you. I've never met one that I'd want to take
home and meet my mother.
Would be an interesting project to tweak block allocation schemes in
traditional file systems to think about wear leveling and not
defragmentation.
<jg> That's what I thought; probably why our M$ friends are being so
picky on which SD card they use.
<dwmw2>that and the speed of SD cards of course -- they don't want slow
ones :)
<jg> yup.
<jg> Thanks for the insight; it is roughly what I thought, but as I
don't track the area, I wanted to be up-to-date....
<dwmw2> Nothing much has changed since we dropped the magic translation
layer chip from the XO when we first started
<jg> ah, but for our internal flash, we have jffs2.
<dwmw2> the trend of putting SSDs in laptops will have a decent effect
in time, I hope, but it hasn't yet. Jffs2 doesn't scale much further. We
need ubifs/logfs or maybe btrfs in future. The not-so-distant future, I
hope. I'm allegedly going to be getting a shiny new translation layer
(make flash look like disk) soon, which I'm supposed to make look like
proper Linux code and merge upstream
--
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child
15 years, 8 months
