F14 os2 testing images available for XO-1 and XO-1.5

[Daniel Drake]

Hi,

Simon has built new Fedora 14 images for XO-1 and XO-1.5, available here:
http://build.laptop.org/F14/os2/

These efforts are now official so we'll step towards making this into
a proper release. There are still some pretty obvious issues though,
which we'll be working through.

Bug reports are now accepted, please put them in the "F14" milestone
on http://dev.laptop.org. If your bug is definitely within the realms
of the Sugar components included in the build (as opposed to OS-level
issues), the ticket would be better off on SugarLabs trac. If in doubt
you can file on dev.laptop.org or ask on this mailing list.

The big changes in this stream are below. I don't plan on making any
more, would prefer to focus on fixing and stability from now on.

Fedora 14
Sugar 0.90
GNOME 2.32
Linux 2.6.35.8

XO-1 switched from jffs2 to partitioned image: jffs2 boot, ubifs root

XO-1.5 switched from ext3 to ext4

Old OS images are not retained after olpc-update
http://lists.laptop.org/pipermail/devel/2010-September/029889.html

Activation initramfs split from "run" initramfs (for faster boot)

"Run" initramfs slimmed down to 1.9mb (no python in any non-activation
bootpath) (for faster boot)

Package list trimmed for a smaller image (even though we've likely
still grown from the F11 days, as Fedora gets bigger and bigger)



To install on XO-1 you need the .onu and .uim files, and the OFW
command to flash is:
 update-nand u:\foo.onu

Daniel

[Martin Langhoff]

On Sun, Nov 21, 2010 at 2:54 PM, Daniel Drake <dsd(a)laptop.org&gt; wrote:
>  "Run" initramfs slimmed down to 1.9mb (no python in any
> non-activation
>  bootpath) (for faster boot) 
Does it actually boot faster? I recall you were asking Mitch about
what seemed to be OFW delays in reading kernel / initramfs that meant
no difference when booting a slim initramfs.

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

[Daniel Drake]

On 21 November 2010 20:47, Martin Langhoff <martin.langhoff(a)gmail.com&gt; wrote:
>  On Sun, Nov 21, 2010 at 2:54 PM, Daniel Drake <dsd(a)laptop.org&gt;
> wrote:
> > "Run" initramfs slimmed down to 1.9mb (no python in any non-activation
> > bootpath) (for faster boot)
>
>  Does it actually boot faster? I recall you were asking Mitch about
>  what seemed to be OFW delays in reading kernel / initramfs that meant
>  no difference when booting a slim initramfs. 
Yes, it's faster. But I can't recall the timings that I took earlier
and only have 1 XO at the moment.
The IRC conversation you refer to (where initramfs uncompress took
more than 30 seconds) was an unexplained oddity that can't be
reproduced. (I suspect some kind of jffs2 corruption on the laptop in
question)

Daniel

[Martin Langhoff]

On Sun, Nov 21, 2010 at 4:23 PM, Daniel Drake <dsd(a)laptop.org&gt; wrote:
>  Yes, it's faster. 
Yay! That's good news.

I have dozen little questions about it (like - do you still include
our bootanim there? thinking about the fsck story...). I will probably
need to find the time to read/review the dracut-modules-olpc git logs.

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

[Daniel Drake]

On 21 November 2010 23:13, Martin Langhoff <martin.langhoff(a)gmail.com&gt; wrote:
>  On Sun, Nov 21, 2010 at 4:23 PM, Daniel Drake <dsd(a)laptop.org&gt;
> wrote:
>  I have dozen little questions about it (like - do you still include
>  our bootanim there? thinking about the fsck story...). I will probably
>  need to find the time to read/review the dracut-modules-olpc git logs. 
Fire away!

bootanim is still in use.
However, it does not live in the initramfs. (nothing new, this is how
its always been)

Daniel

[Daniel Drake]

On 21 November 2010 23:24, Daniel Drake <dsd(a)laptop.org&gt; wrote:
>  Fire away!
>
>  bootanim is still in use.
>  However, it does not live in the initramfs. 
It is launched from there though.

The initramfs changes described in this thread were only small, mostly
just 1 more modularization step so that you can build an initramfs
without activation support, overall the picture hasn't really changed.

Daniel

[Mikus Grinbergs]

XO-1 It keeps asking me over and over for a keyring password.

What is this for ?

How can I nullify this function ?

mikus

[Daniel Drake]

On 22 November 2010 00:06, Mikus Grinbergs <mikus(a)bga.com&gt; wrote:
>  XO-1 It keeps asking me over and over for a keyring password.
>
>  What is this for ? 
Open bug; this is http://bugs.sugarlabs.org/ticket/2339

>  How can I nullify this function ? 
It does go away if you are persistent. Choose an empty password.

Daniel

[Peter Robinson]

On Mon, Nov 22, 2010 at 12:06 AM, Mikus Grinbergs <mikus(a)bga.com&gt; wrote:
>  XO-1 It keeps asking me over and over for a keyring password.
>
>  What is this for ? 
Its used by telepathy-mission-control so passwords aren't stored in
plain text files.

Regards,
Peter

>  How can I nullify this function ?
>
>  mikus
>
>  _______________________________________________
>  olpc mailing list
>  olpc(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/olpc
>

[Mikus Grinbergs]

Used yum to install the 1121 kernel.  Copied new /boot content into
/versions tree.  But booting still brings up the previous 1119 kernel.

What I did here worked fine with all previous builds.  What more needs
to be done to accomplish a kernel upgrade in this new build ?

Thanks,  mikus

[Daniel Drake]

On 22 November 2010 02:34, Mikus Grinbergs <mikus(a)bga.com&gt; wrote:
>  Used yum to install the 1121 kernel.  Copied new /boot content into
>  /versions tree.  But booting still brings up the previous 1119 kernel.
>
>  What I did here worked fine with all previous builds.  What more needs
>  to be done to accomplish a kernel upgrade in this new build ? 
See /boot/README
XO-1 is now using partitions.

Daniel

[Mikus Grinbergs]

On 11/22/2010 03:09 AM, Daniel Drake wrote:
>  See /boot/README
>  XO-1 is now using partitions. 
/boot/README did not help me with my running XO-1 build os2, in which
the only available partition is the ubifs for root.

Have now written http://dev.laptop.org/ticket/10462

Thanks,  mikus

[Simon Schampijer]

On 11/21/2010 08:54 PM, Daniel Drake wrote:
>  Hi,
>
>  Simon has built new Fedora 14 images for XO-1 and XO-1.5, available here:
>  http://build.laptop.org/F14/os2/
>
>  These efforts are now official so we'll step towards making this into
>  a proper release. There are still some pretty obvious issues though,
>  which we'll be working through.
>
>  Bug reports are now accepted, please put them in the "F14" milestone
>  on http://dev.laptop.org. 
I think we should add a Version field for F14 (e.g. 1.5/1.0 software 
Build F14). That field is set by the reporter of an issue. The milestone 
is set by the development team/maintainer to triage his work, when he 
thinks that issue can/will be handled.

Regards,
    Simon

[Daniel Drake]

On 22 November 2010 08:03, Simon Schampijer <simon(a)schampijer.de&gt; wrote:
>  I think we should add a Version field for F14 (e.g. 1.5/1.0 software
> Build
>  F14). That field is set by the reporter of an issue. The milestone is set by
>  the development team/maintainer to triage his work, when he thinks that
>  issue can/will be handled. 
Sounds good as long as someone is going to offer to triage all new
incoming bugs..?

Daniel

[Simon Schampijer]

On 11/22/2010 10:08 AM, Daniel Drake wrote:
>  On 22 November 2010 08:03, Simon
> Schampijer<simon(a)schampijer.de>  wrote:
> > I think we should add a Version field for F14 (e.g. 1.5/1.0 software Build
> > F14). That field is set by the reporter of an issue. The milestone is set by
> > the development team/maintainer to triage his work, when he thinks that
> > issue can/will be handled.
>
>  Sounds good as long as someone is going to offer to triage all new
>  incoming bugs..?
>
>  Daniel
>  
We have to do that at some point when we want to do a "serious" release. 
In any case, I think reporters should indicate a version. We should not 
abuse the milestone field to get that information.

Regards,
    Simon

[Daniel Drake]

On 22 November 2010 09:24, Simon Schampijer <simon(a)schampijer.de&gt; wrote:
>  We have to do that at some point when we want to do a
> "serious" release. In
>  any case, I think reporters should indicate a version. We should not abuse
>  the milestone field to get that information. 
If someone is doing that already for 10.1.3 (you? Sam?) could we
additionally ask them to do triage for F14? I guess they are already
having to look at all the bugs anyway just in case they are
10.1.3-related.

Daniel

[Simon Schampijer]

On 11/22/2010 10:59 AM, Daniel Drake wrote:
>  On 22 November 2010 09:24, Simon
> Schampijer<simon(a)schampijer.de>  wrote:
> > We have to do that at some point when we want to do a "serious" release.
> In
> > any case, I think reporters should indicate a version. We should not abuse
> > the milestone field to get that information.
>
>  If someone is doing that already for 10.1.3 (you? Sam?) could we
>  additionally ask them to do triage for F14? I guess they are already
>  having to look at all the bugs anyway just in case they are
>  10.1.3-related.
>
>  Daniel 
Yes, we do triage bugs for 10.1.3. Until 10.1.3 is out in mid December I 
don't want to get into F14 triaging. However as I have to read all the 
bugs anyhow, as you mentioned, I can make sure the version field is set 
correctly in new incoming bugs (and if I am sure it is a blocker for a 
F14 release I can set the milestone as well). That should be good enough 
for now to know what bugs one wants to work on for F14. Is that a good 
compromise?

(The Milestone field I really see as a way to manage the work.)
Regards,
    Simon

[Daniel Drake]

On 22 November 2010 10:32, Simon Schampijer <simon(a)schampijer.de&gt; wrote:
>  Yes, we do triage bugs for 10.1.3. Until 10.1.3 is out in mid
> December I
>  don't want to get into F14 triaging. However as I have to read all the bugs
>  anyhow, as you mentioned, I can make sure the version field is set correctly
>  in new incoming bugs (and if I am sure it is a blocker for a F14 release I
>  can set the milestone as well). That should be good enough for now to know
>  what bugs one wants to work on for F14. Is that a good compromise? 
Sounds good.

You could even simplify it a step further: just put all of them in the
F14 milestone without thought. As the scope of the release is not yet
defined it's not really possible to do a "real" triage. And knowing
what bugs are there could also help us define that scope.

Daniel

[James Cameron]

On Mon, Nov 22, 2010 at 09:03:28AM +0100, Simon Schampijer wrote:
>  I think we should add a Version field for F14 (e.g. 1.5/1.0 software
>
>  Build F14). 
I disagree.  The version field is for formal releases.  The reporter of
a bug may use "Development build as of this date" for the current F14
builds.  Identify the build version in the keywords field.  This has
been our practice for the past year.

On Mon, Nov 22, 2010 at 10:36:03AM +0000, Daniel Drake wrote:
>  You could even simplify it a step further: just put all of them in
> the
>  F14 milestone without thought. As the scope of the release is not yet
>  defined it's not really possible to do a "real" triage. And knowing
>  what bugs are there could also help us define that scope. 
I agree, just throw them into the F14 milestone.

trac does not allow us to easily manage tickets for multiple release
engineering streams.  If you sense a fight over which milestone a ticket
should be in (10.1.3 vs F14), then I suggest opening a new ticket.

-- 
James Cameron
http://quozl.linux.org.au/

[Simon Schampijer]

On 11/22/2010 11:55 AM, James Cameron wrote:
>  On Mon, Nov 22, 2010 at 09:03:28AM +0100, Simon Schampijer wrote:
> > I think we should add a Version field for F14 (e.g. 1.5/1.0 software
> > Build F14).
>
>  I disagree.  The version field is for formal releases.  The reporter of
>  a bug may use "Development build as of this date" for the current F14
>  builds.  Identify the build version in the keywords field.  This has
>  been our practice for the past year. 
"Development build as of this date" is ambiguous as we have the 10.1.3 
stream and the F14 stream :/

>  On Mon, Nov 22, 2010 at 10:36:03AM +0000, Daniel Drake wrote:
> > You could even simplify it a step further: just put all of them in the
> > F14 milestone without thought. As the scope of the release is not yet
> > defined it's not really possible to do a "real" triage. And knowing
> > what bugs are there could also help us define that scope.
>
>  I agree, just throw them into the F14 milestone.
>
>  trac does not allow us to easily manage tickets for multiple release
>  engineering streams.  If you sense a fight over which milestone a ticket
>  should be in (10.1.3 vs F14), then I suggest opening a new ticket. 
Yeah, I guess I have to do that then. The bad thing is that I have to 
touch tickets then and can not pass that to the reporter by indicating 
the version number. For anyone working on the F14 builds please make 
sure to set the milestone then accordingly on the tickets you are touching.

At least I could stop the initial request from a reporter setting 
milestones ;p

Regards,
    Simon

[Martin Langhoff]

On Mon, Nov 22, 2010 at 5:55 AM, James Cameron <quozl(a)laptop.org&gt; wrote:
>  I disagree.  The version field is for formal releases.  The reporter
> of
>  a bug may use "Development build as of this date" for the current F14
>  builds. 
Can we split "development build as of this date" into F11 and F14?

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

[James Cameron]

On Mon, Nov 22, 2010 at 07:50:52AM -0500, Martin Langhoff wrote:
>  On Mon, Nov 22, 2010 at 5:55 AM, James Cameron
> <quozl(a)laptop.org&gt; wrote:
>  > I disagree. ?The version field is for formal releases. ?The reporter of
>  > a bug may use "Development build as of this date" for the current F14
>  > builds.
>  
>  Can we split "development build as of this date" into F11 and F14? 
I think not.  Unnecessary expansion of the version popup.

The last thing we want is a bug reporter to not report a bug because
they don't know the answer to a question.  (If you are a bug reporter
reading this, just fill out the fields you know and hit submit).

For the community bug reporters who do know whether they are using F11
or F14, they'll know to report that, or the build number.  Keywords or
the body of the description is good for this.  The professional bug
reporters already do this well.

For triage by engineers working on one of the three build streams (the
10.1.3, the as yet unnamed F14, or the as yet unnamed F12 ARM), it would
be best if they examine every new ticket and complete the metadata.
Don't ever rely on the bug reporter to give you your metadata in the
initial capture; verify it.

-- 
James Cameron
http://quozl.linux.org.au/