http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build319/
-xkeyboard-config.noarch 0:1.1-5.20071009cvs.olpc2
+xkeyboard-config.noarch 0:1.1-5.20071120cvs.olpc2
--
This email was automatically generated
Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html
It is because the network settings are bad.
If you are using Qemu Manager (recommended) you have to delete the
default network card setting on the VM image properties (third property
page, Network) and include the following on the last property page
(Specify Optional Command Parameters):
-net
I looked at the lists, don't really see a more appropriate one.
I've downloaded the image for 611 and booted it with qemu. It came up, asked
me for my name, select a color etc. Then a while after that I get an X with
an arrow, it waits a minute, jumps to console, some error appears, and it
Thanks, but didn't help. Is it because I don't have sound in qemu? I caught
the error by running snagit and capturing the screen right between reboots.
(EE) AIGLX: Screen 0 is not DRI capable
expected keysm, got guillemontleft, line 823 of us
expected keysm, got guillemontleft, line 823 of us
Thanks, but didn't help. Is it because I don't have sound in qemu? I
caught
the error by running snagit and capturing the screen right between
reboots.
It was sound. Added -soundhw all
And now it runs.
a) Shouldn't it pause for someone to be able to see the error message?
b) Why does it
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build321/
-cups-libs.i386 1:1.2.12-7.fc7
+cups-libs.i386 1:1.2.12-8.fc7
-openldap.i386 0:2.3.34-3.fc7
+openldap.i386 0:2.3.34-4.fc7
--
This email was automatically generated
Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html
From now until further notice, ONLY load packages into joyride for final
testing before asking for approval for update.
We are in our final run up to Update.1.
Joyride and Update.1 were synchronized as of Monday evening, November
21.
YOU SHOULD BE TESTING/USING the UPDATE.1 build, found at;
On Nov 20, 2007, at 20:43 , Jim Gettys wrote:
Joyride and Update.1 were synchronized as of Monday evening,
November 21.
I guess you made a sign error when subtracting 1 from today and meant
Nov. 19th.
But, more importantly - could you let us know what the plan is with
Update.1? I see
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build322/
-bootanim.i386 0:0.12-0
+bootanim.i386 0:0.13-0
-kernel.i586 0:2.6.22-20071120.4.olpc.2a55c90c922695e
+kernel.i586 0:2.6.22-20071120.5.olpc.53add009d83c69b
+telepathy-salut.i386 0:0.1.9-0.10.olpc2
-telepathy-salut.i386
Bert, all,
Here's what is going on:
We have to have something for the first systems and G1G1 that have a few
key bugs fixed; the wireless driver, and a key fix for the browser
(turns out that our browser, and any current firefox development
version, including the Firefox 3.0 beta released today
Done - I believe this also closes #1669
On Nov 15, 2007 5:16 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
In fact, you *only* need a shell account.
- Bert -
On Nov 15, 2007, at 23:11 , Owen Williams wrote:
oh I thought it would be done through ftp.
Then I'll also need one shell
Hi,
We'll be having the regular software meeting on IRC (irc.freenode.net
#olpc-meeting) tonight at 9pm EST. See you there!
Date/time:
http://www.timeanddate.com/worldclock/fixedtime.html?month=11day=20year=2007hour=21min=0sec=0p1=43
- Chris.
--
Chris Ball [EMAIL PROTECTED]
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build323/
-Analyze-4.xo
+Analyze-5.xo
-Journal-72.xo
+Journal-73.xo
-fontconfig.i386 0:2.4.2-3.fc7
+fontconfig.i386 0:2.4.2-4olpc.fc7
+gettext.i386 0:0.16.1-9.fc7
+libgomp.i386 0:4.1.2-27.fc7
-ohm.i386 0:0.1.1-5.5.20071112git.fc7
+ohm.i386
Jim,
So in short, we're screwing down the lid on Update.1. But we likely
have to do a Ship.2 build, and that on top of a feature release is a bad
idea, so we'll let Update.1 slip and be sane about letting it be ready
when it is ready, rather than having to throw it over the wall on
On Tue, 2007-11-20 at 17:04 -0800, Yoshiki Ohshima wrote:
Jim,
So in short, we're screwing down the lid on Update.1. But we likely
have to do a Ship.2 build, and that on top of a feature release is a bad
idea, so we'll let Update.1 slip and be sane about letting it be ready
when it is
http://xs-dev.laptop.org/~cscott/olpc/streams/update1/build638/
-kernel.i586 0:2.6.22-20071119.bernie11.olpc.9f4c8d20
+kernel.i586 0:2.6.22-20071120.5.olpc.53add009d83c69b
-ohm.i386 0:0.1.1-5.5.20071112git.fc7
+ohm.i386 0:0.1.1-5.6.20071120git.fc7
-sugar-datastore.noarch
Backport of a patch to olpc-2.6 I'm going to post to linux-wireless.
When both interfaces are down (~IFF_UP), turn off the radio to save
power. When either interface is opened (via iwconfig up or otherwise)
turn the radio back on unless the radio was explicitly disabled by the
user via 'iwconfig
On Tue, Nov 20, 2007 at 11:18:07PM -0500, Dan Williams wrote:
This should allow NetworkManager to be told to go to sleep, at which
point it will mark all devices down, and with this patch should turn off
the radio and save power.
Good.
Comments?
Very slight possibility of further
Question.
How is this intended to interact with the mesh connectivity intended for
the laptops? I'm of the understanding that the mesh being powered and on
is more or less a baseline design feature of the XO-as-platform.
Or is this an airplane mode feature that's going to get a button-push
Mesh forwarding is always on. Therefore, disabling radio when interface
in not up will disable mesh forwarding as well. Have you thought of
this?
Thanks
-Ashish
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan
Williams
Sent: Wednesday, November 21,
On Tue, 2007-11-20 at 23:38 -0600, [EMAIL PROTECTED] wrote:
Question.
How is this intended to interact with the mesh connectivity intended for
the laptops? I'm of the understanding that the mesh being powered and on
is more or less a baseline design feature of the XO-as-platform.
Yes,
On Tue, 2007-11-20 at 21:45 -0800, Ashish Shukla wrote:
Mesh forwarding is always on. Therefore, disabling radio when interface
in not up will disable mesh forwarding as well. Have you thought of
this?
Yes, though interactions with suspend/resume need to be investigated
here.
First, if NM is
Hi Dan,
Last I knew there were cases where mesh forwarding was _not_
supposed to be on due to the high power drain of the 8388 when the
radio was enabled, plus the airplane case. As long as the
networking core doesn't close the devices on suspend, this patch
shouldn't have
Because somehow this email arrived to may inbox three months
later,^^;, it is a good time to write a reminder.
1) eToys:
It would be very nice to have support for Analog Input in eToys.
For a month or so, Etoys has a support for Analog Input, in a sense
that it can basically do what amixer
24 matches
Mail list logo
