4:39 a.m.
Hi All,
I thought now that we're getting closer to the Fedora 11 freeze it
would be a good time for everyone to where they're at as we move
towards F-11/9.1.0/olpc-next.
I've been keeping the wiki page up to date as I go along and filling
in more details as I find out about them. The fixed list is slowly
growing shorter. If there are updates that aren't on the list at the
moment please add them, or reply with details so I can add it.
https://fedoraproject.org/wiki/OLPC/Packages_for_F11
There is also a tracking page for issues with rawhide on w.l.o. It
would be nice if as issues are added the appropriate track/BZ number
is added to it so its easy to find out the current status of them.
http://wiki.laptop.org/go/Rawhide-XO
The main and probably most major issues outstanding are the
kernel/boot process - so
kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of
stuff.... of which I have no real idea about. Updates?
The remaining issues are mostly either package deps or getting them into Fedora.
There's a couple of reviews of which I've had no response from the
submitter. These are 2 fonts packages (and I'm not sure of the state
of the other 2 'orphaned' ones but they're not listed as such in the
packageDB) as sugar-record.
olpcsound should disappear as soon as csound is updated to > 5.08 and
I've done most of the ground work on this (RHBZ 493107)
pygtk support for numpy finally landed in trunk this morning....
awaiting the date for a release and will then organise to get it into
Fedora and dependant packages updated from numeric to numpy if they
support it.
The final few things are the likes of abiword (which will have most
issues fixed for the next major release) and stuff which needs people
to submit review requests.
Cheers,
Peter
4:55 a.m.
These are 2 fonts packages (and I'm not sure of the state
of the other 2 'orphaned' ones but they're not listed as such in the
packageDB) as sugar-record.
I suppose you're talking about abyssinica-fonts and nafees-web-naskh-fonts.
They were orphaned and I took ownership of those 2 packages.
The packages were updated to conform the new packaging guidelines by
their previous maintainer (Bernie) before he orphaned them, so they
are in good shape.
I only didn't put them in the "fixed" list on the wiki page as I still
didn't have time to look at the fontconfig rules and how to add them
to the packages. I'll do that as it's the Right Thing as soon as I
find the time to, but it's not necessary AFAIK so the issues with
those packages (they are orphaned) are fixed.
There's also a comment about renaming the abyssinica-fonts package,
but Bernie couldn't help me on that and there was no bug opened asking
for it (as was the case with issues with new font packaging
guidelines).
So, as far as OLPC on F11 goes, I'd say those 2 are "fixed".
----------
Mathieu Bridon (bochecha)
5:02 a.m.
> These are 2 fonts packages (and I'm not sure of the state
> of the other 2 'orphaned' ones but they're not listed as such in the
> packageDB) as sugar-record.
I suppose you're talking about abyssinica-fonts and nafees-web-naskh-fonts.
They were orphaned and I took ownership of those 2 packages.
The packages were updated to conform the new packaging guidelines by
their previous maintainer (Bernie) before he orphaned them, so they
are in good shape.
I only didn't put them in the "fixed" list on the wiki page as I still
didn't have time to look at the fontconfig rules and how to add them
to the packages. I'll do that as it's the Right Thing as soon as I
find the time to, but it's not necessary AFAIK so the issues with
those packages (they are orphaned) are fixed.
There's also a comment about renaming the abyssinica-fonts package,
but Bernie couldn't help me on that and there was no bug opened asking
for it (as was the case with issues with new font packaging
guidelines).
So, as far as OLPC on F11 goes, I'd say those 2 are "fixed".
Excellent! That's great news. I knew the old owners name started with
B but that was it so I couldn't tell if the maintainer listed in pkgdb
was him or someone else :-)
You don't want to take over the review for the other two font packages
by chance (I'm not sure if there's a procedure for this but can look
to find out), I'm happy to do the review side of things for them.
Cheers,
Peter
5:13 a.m.
You don't want to take over the review for the other two font
packages
by chance (I'm not sure if there's a procedure for this but can look
to find out), I'm happy to do the review side of things for them.
No, sorry.
I already have so little time for the huge amount of packages I
maintain (yeah, I know, 4 is a lot ^^'), I'd rather act responsibly
for those and take more only when I feel I'll be able to do so.
Regards,
----------
Mathieu Bridon (bochecha)
4:20 p.m.
The main and probably most major issues outstanding are the
kernel/boot process - so
kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of
stuff.... of which I have no real idea about. Updates?
It's pretty trivial to disable Rainbow, whereas it's not trivial to
get maintainers of half a dozen packages to adopt patches that let
them deal with Rainbow. So if you want F11 to work on OLPC, disabling
Rainbow's UID fiddling in the version of Sugar that ships in F11 is
the obvious short-term cure.
Some of the initscript changes related to the bizarre idea of running
the "anti-theft" process as pid 1 so it couldn't be killed by root.
This required changing "init" so it didn't run as pid 1. This is
trivial to fix by running the anti-theft process (which is a no-op
loop on most OLPCs anyway, and should in a sane world merely exit) on
some other pid, and running init where it belongs.
It looks like perhaps the kernel changes have slipped right through
the F11 schedule. Is it seriously likely that the F11 kernel
maintainers would adopt a pile of OLPC patches that aren't in the
upstream kernel, between the Beta and the Final F11 releases? Had
these changes been adopted (by Fedora or by the Linux kernel) early in
the release cycle, they could've been well tested to make sure they
don't introduce any problems into non-OLPC hardware. But now, it
appears that F11 won't be able to suspend on OLPC, which makes it
almost useless for laptop use (as opposed to developer use when the
laptop is sitting on a desk with permanent AC power). Such is the
price of firing all of your kernel developers.
Even the bug report that tracks the kernel power management changes
has fallen into disarray (the Fedora "Bug Zapper" zapped it in November
and nobody has bothered to fix it since):
https://bugzilla.redhat.com/show_bug.cgi?id=465284
John
4:32 p.m.
john wrote:
It looks like perhaps the kernel changes have slipped right through
the F11 schedule. Is it seriously likely that the F11 kernel
for the record, this was a conscious decision. everyone knew there
wouldn't be time to get XO-specific changes upstream, and back to
fedora, before F11. as you say, it was the cost of going broke.
the challenge is now to get those changes upstream in time for F12.
maintainers would adopt a pile of OLPC patches that aren't in
the
upstream kernel, between the Beta and the Final F11 releases? Had
these changes been adopted (by Fedora or by the Linux kernel) early in
the release cycle, they could've been well tested to make sure they
don't introduce any problems into non-OLPC hardware. But now, it
appears that F11 won't be able to suspend on OLPC, which makes it
almost useless for laptop use (as opposed to developer use when the
laptop is sitting on a desk with permanent AC power). Such is the
i think the plan is to make an OLPC-patched kernel available for
the distribution creators.
paul
price of firing all of your kernel developers.
Even the bug report that tracks the kernel power management changes
has fallen into disarray (the Fedora "Bug Zapper" zapped it in November
and nobody has bothered to fix it since):
https://bugzilla.redhat.com/show_bug.cgi?id=465284
John
_______________________________________________
Fedora-olpc-list mailing list
Fedora-olpc-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-olpc-list
=---------------------
paul fox, pgf(a)laptop.org
4:32 p.m.
Hi John,
It's pretty trivial to disable Rainbow, whereas it's not
trivial to
get maintainers of half a dozen packages to adopt patches that let
them deal with Rainbow.
Yes, we aren't using rainbow in the F11 builds.
Some of the initscript changes related to the bizarre idea of
running the "anti-theft" process as pid 1 so it couldn't be killed
by root.
Or this.
But now, it appears that F11 won't be able to suspend on OLPC,
which makes it almost useless for laptop use (as opposed to
developer use when the laptop is sitting on a desk with permanent
AC power).
Sure, but you can install a different kernel on your F11 image, such as
OLPC's custom kernel (this has already been tested working), or just
the minimum set of patches to the F11 kernel that add suspend/resume
support, as Scott Douglass and Martin Dengler have been looking at
recently.
I hope we can get some power management patches (even if they're basic
patches rather than everything we have) upstream and back for F12. We
started the F11 project with the knowledge that we wouldn't be able to
get much of what we need upstream and back in time for its release.
Thanks,
- Chris.
--
Chris Ball <cjb(a)laptop.org>
4:45 p.m.
Hi Chris,
> It's pretty trivial to disable Rainbow, whereas it's
not trivial to
> get maintainers of half a dozen packages to adopt patches that let
> them deal with Rainbow.
Yes, we aren't using rainbow in the F11 builds.
> Some of the initscript changes related to the bizarre idea of
> running the "anti-theft" process as pid 1 so it couldn't be killed
> by root.
Or this.
> But now, it appears that F11 won't be able to suspend on OLPC,
> which makes it almost useless for laptop use (as opposed to
> developer use when the laptop is sitting on a desk with permanent
> AC power).
Sure, but you can install a different kernel on your F11 image, such as
OLPC's custom kernel (this has already been tested working), or just
the minimum set of patches to the F11 kernel that add suspend/resume
support, as Scott Douglass and Martin Dengler have been looking at
recently.
I hope we can get some power management patches (even if they're basic
patches rather than everything we have) upstream and back for F12. We
started the F11 project with the knowledge that we wouldn't be able to
get much of what we need upstream and back in time for its release.
So is that trying to get them into 2.6.30?
Peter
2:31 a.m.
> But now, it appears that F11 won't be able to suspend on
OLPC,
> which makes it almost useless for laptop use (as opposed to
> developer use when the laptop is sitting on a desk with permanent
> AC power).
Sure, but you can install a different kernel on your F11 image, such as
OLPC's custom kernel (this has already been tested working), or just
the minimum set of patches to the F11 kernel that add suspend/resume
support, as Scott Douglass and Martin Dengler have been looking at
recently.
I hope we can get some power management patches (even if they're basic
patches rather than everything we have) upstream and back for F12. We
started the F11 project with the knowledge that we wouldn't be able to
get much of what we need upstream and back in time for its release.
Since OLPC's "upstream" is both Linus's kernel releases, and
Fedora's
distributions, there are two upstream places to push OLPC's hardware
support patches to. Have we only been trying to get them into one of
those places (Linus's)?
The F11 kernel currently carries about 60 patches beyond Linus's version.
Some are tiny 4kb patches; others are 300KB. Why aren't any of the
XO-1 hardware support patches included in the F11 kernel?
John
8:04 a.m.
On Wednesday, April 08 2009, John Gilmore said:
> > But now, it appears that F11 won't be able to
suspend on OLPC,
> > which makes it almost useless for laptop use (as opposed to
> > developer use when the laptop is sitting on a desk with permanent
> > AC power).
>
> Sure, but you can install a different kernel on your F11 image, such as
> OLPC's custom kernel (this has already been tested working), or just
> the minimum set of patches to the F11 kernel that add suspend/resume
> support, as Scott Douglass and Martin Dengler have been looking at
> recently.
>
> I hope we can get some power management patches (even if they're basic
> patches rather than everything we have) upstream and back for F12. We
> started the F11 project with the knowledge that we wouldn't be able to
> get much of what we need upstream and back in time for its release.
Since OLPC's "upstream" is both Linus's kernel releases, and
Fedora's
distributions, there are two upstream places to push OLPC's hardware
support patches to. Have we only been trying to get them into one of
those places (Linus's)?
The F11 kernel currently carries about 60 patches beyond Linus's version.
Some are tiny 4kb patches; others are 300KB. Why aren't any of the
XO-1 hardware support patches included in the F11 kernel?
As has been said here again and again, as a matter of policy, the Fedora
kernel maintainers are against adding patches that aren't already in an
upstream subsystem maintainer's tree and thus headed to Linus. There
are a few holdouts for legacy reasons, but those are dropping in number
with each passing kernel release.
If it's good enough for the Fedora kernel, it's good enough for
upstream. And the flip side of that is that if it's not good enough for
upstream, why would you think that it's good enough for Fedora?
Jeremy
8:10 a.m.
2009/4/8 John Gilmore <gnu(a)toad.com>:
Since OLPC's "upstream" is both Linus's kernel
releases, and Fedora's
distributions, there are two upstream places to push OLPC's hardware
support patches to. Have we only been trying to get them into one of
those places (Linus's)?
The F11 kernel currently carries about 60 patches beyond Linus's version.
Some are tiny 4kb patches; others are 300KB. Why aren't any of the
XO-1 hardware support patches included in the F11 kernel?
I don't think any effort has been made (since layoffs) to get any
kernel patches upstream anywhere, mostly due to time constraints. But
anyone is welcome to step up and do so!
During a quick discussion with Chris and some others we seemed to
agree on the following:
- regardless of Fedora/F11/F12 status, policies or whatever, the
first thing to do in any case is to get the patches upstream to Linus
- we haven't actually tried sending our patches specifically to
Fedora (knowing that they aren't quite ready for Linus) - but IMO this
would be a bad idea
- we don't really know Fedora's kernel policies for accepting
non-upstream patches, or for backporting upstreamed patches into
current Fedora kernels
- my opinion: getting patches upstream to Linus, or perhaps even as
far as linux-next, would be enough for the fedora kernel maintainers
to include the patches in the F11 release kernel as an update. So
let's not rule out suspend-on-F11.. it's possible that
F11-plus-updates may work in future.
The biggest showstopper right now seems to be finding someone to do
the work of upstreaming the patches. And, in my opinion and
experience, the correct way to do this is to approach upstream saying
"hey, we have this weird hardware, how would you like to see the
kernel code crafted? here's a possible patch to act as the basis of
discussions"
and *not*
"hey, we have this weird hardware, please take our patches as-is
without consideration because we've shipped them internally for 2
years"
which makes the task harder (since kernel hacking may be needed as a
result of discussions), but should lead to success :)
Daniel
4:35 p.m.
Given everything discussed so far, is it worth considering an F11-OLPC
branch, with the intent of merging with F12?
-- Kevin Sonney
-- kevin(a)sonney.com
“Around here, however, we don’t look backwards for very long. We keep
moving forward, opening up new doors and doing new things… and
curiosity keeps leading us down new paths.”
–Walt Disney
I check email a couple times daily; to reach me sooner, click here:
http://awayfind.com/ksonney
2:58 a.m.
New subject: Rainbow, olpc-update, and olpcrd.
The main and probably most major issues outstanding are the
kernel/boot process - so
kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection
of stuff.... of which I have no real idea about. Updates?
Peter,
Your remark does not contain any specific questions so it's a little
hard for me to give you a coherent update. Instead, I'll make some
general remarks in the hope that they will elicit further questions.
1. As has been recently pointed out, Rainbow is not currently in use
on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*).
However, some have wondered whether it might make a reappearance in
sugar-*-0.86. To speed this outcome, I have prepared new versions of
rainbow (0.8.*) which are easy to install and test on many different
platforms. See
http://wiki.laptop.org/go/Rainbow
for current status information.
(I await further rainbow-0.8.* questions, comments, concerns, and
test results with particular interest.)
2. There is little change in the state of olpcrd and olpc-update.
Daniel Drake did some nice work in February to make the toolchain
support OFW-hosted key overlays and, so far as I know, is happily
serving Paraguay-signed leases and software updates over Paraguay's
test schools' wifi network.
(Dan -- could you please update
http://wiki.laptop.org/go/Security
with links to a description of how you've deployed these
technologies?)
(Peter -- Did you have some specific question about the technology or
about its inclusion [or lack thereof] in Fedora?)
Regards from Athens,
Michael
4:23 a.m.
New subject: Rainbow, olpc-update, and olpcrd.
Peter,
Your remark does not contain any specific questions so it's a little
hard for me to give you a coherent update. Instead, I'll make some
general remarks in the hope that they will elicit further questions.
Sorry, there were no real questions, but its more about the status of
where it stands within Fedora rawhide. The current understanding is
what's documented at this link. If you have more to provide that would
be great (I was already aware of rainbow and the PID changes but
didn't put details in as I don't know alot about early boot
processes).
https://fedoraproject.org/wiki/OLPC/Packages_for_F11
1. As has been recently pointed out, Rainbow is not currently in use
on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*).
However, some have wondered whether it might make a reappearance in
sugar-*-0.86. To speed this outcome, I have prepared new versions of
rainbow (0.8.*) which are easy to install and test on many different
platforms. See
I presume you mean later than 0.8.2?
http://wiki.laptop.org/go/Rainbow
for current status information.
(I await further rainbow-0.8.* questions, comments, concerns, and
test results with particular interest.)
I believe the major concerns around about the changes to init to run
it as PID 1 and what changes can be made for Fedora mainline
acceptance. I have no idea about the pros and cons of this hence the
generic query.
2. There is little change in the state of olpcrd and olpc-update.
Daniel Drake did some nice work in February to make the toolchain
support OFW-hosted key overlays and, so far as I know, is happily
serving Paraguay-signed leases and software updates over Paraguay's
test schools' wifi network.
(Dan -- could you please update
http://wiki.laptop.org/go/Security
with links to a description of how you've deployed these
technologies?)
(Peter -- Did you have some specific question about the technology or
about its inclusion [or lack thereof] in Fedora?)
About its inclusion in Fedora.
Peter
5524
days inactive
5525
days old
14 comments
9 participants
participants (9)
-
Chris Ball -
Daniel Drake -
Jeremy Katz -
John Gilmore -
Kevin Sonney -
Mathieu Bridon -
Michael Stone -
Paul Fox -
Peter Robinson