Re: Build streams
Hi, > Despite everybody denying this, it seems to me that the OLPC group > and the SugarLabs group are _NOT_ talking to each other. Please don't litter the list with this kind of non-sequitur. The new build streams discussion happened during our regular, public software meeting (you're invited, too), which was attended by Sugar Labs people who gave positive feedback on the proposal. You do us all a disservice by trying to create controversy. > Finally, finally, Joyride 2024 managed to 'make available to users' > some of the newer Sugar changes (packaged in a build, as opposed to > only available in source). Note that the Joyride system involves developers pushing packages to Joyride at their own will; the Sugar team released these changes when they decided that they wanted to. > But what the 'Build Streams' topic proposes is making Joyride a > "copy of the the olpc-3 stream" (does that mean a re-focus on > kernel work as opposed to UI work ?). I'm interested in how the > new Sugar behaves on my XO -- it is not clear to me how much broken > F9 stuff I might run into in the meantime. Rebasing onto F9 is happening for as many UI reasons as kernel ones: we want the new xulrunner packages in F9 for a better browsing experience, we want the NetworkManager package in F9 so that we can gain the recent features added to NM, and, yes, we need a kernel upgrade too. F7 is unsupported as of approximately today, which makes it a non-starter for future releases. The F9 build does boot into Sugar -- we aren't going to leave everyone with a broken build for long. It has bugs, though. We need help fixing the bugs more than we need a demand for constantly stable developer builds and an unwarranted supposition of conflict. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams
Chris Ball wrote: > ... we discussed creating some new build streams > in preparation for our August "8.2" release. > Joyride: This will move immediately ... Despite everybody denying this, it seems to me that the OLPC group and the SugarLabs group are _NOT_ talking to each other. Finally, finally, Joyride 2024 managed to 'make available to users' some of the newer Sugar changes (packaged in a build, as opposed to only available in source). But what the 'Build Streams' topic proposes is making Joyride a "copy of the the olpc-3 stream" (does that mean a re-focus on kernel work as opposed to UI work ?). I'm interested in how the new Sugar behaves on my XO -- it is not clear to me how much broken F9 stuff I might run into in the meantime. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Koji Tags for 8.2.0
Marco, Dennis, and I talked this afternoon and evening about how to
arrange our Koji tags for the 8.2.0 release. Assuming no serious
objections are raised by either you or the Fedora infrastructure and
release-engineering teams, we will take the OLPC-3 [1] CVS branch,
freeze the dist-olpc3 tag, and create dist-olpc3-{devel,testing,updates}
and dist-olpc4 tags.
[1]: OLPC-3 represents our third buildroot. Buildroots contain the
compilers and basic system libraries necessary to build other
packages.
+ dist-olpc3-devel - the site of ongoing development.
By default, your packages will be built into this tag.
(If we find it helpful in the future, we can create some tags like
dist-olpc3-devel-sugar or dist-olpc3-devel-wireless to separate
unrelated streams of development. We'll cross that bridge when we
come to it.)
+ dist-olpc3-testing - things that are ready for QA.
Will be used by the OLPC release team [2] to generate builds
suitable for consumption by QA.
[2]: (Currently yours truly; please contact me for exciting volunteer
and employment opportunities.)
+ dist-olpc3-updates - things that pass QA.
When we need to roll release candidates, we'll do so by snapshotting
dist-olpc3-updates. For example, when we get ready to release 8.2.0,
we'll produce a tag like dist-olpc3-8.2.0. (Maybe with an rc
attached?)
+ dist-olpc4 - Rawhide tracker + buildroot experimentation
Will contain any OLPC-specific changes needed to make Rawhide-based
builds. Will also be suitable for buildroot experimentation.
Eventually, if this works out, we'll add
dist-olpc4-{devel,testing,updates} and dist-olpc5.
Questions? Complaints? Pet peeves?
Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Switching to Kreyol ?
Hal Murray <[EMAIL PROTECTED]> writes: >> Mhh.. I can't seem to find a good reference on this. I will try to >> ask to some haitian developers. > > http://en.wikipedia.org/wiki/Kreyol > The word Kreyol may mean: > * Liberian Kreyol language > * Haitian Creole language (Kreyòl ayisyen) > * Kreyol Lwiziyen (Louisiana Creole) > > People in the US are probably familiar with Creole from the New Orleans > region. (We bought Louisiana from France in 1803.) Thanks*. The question is: where are the GNU/Linux users who configure their machine so that it speaks Kreyol? What is the equivalent of the en_EN.UTF-8 code then? I expect many of these users to be from the haitian diaspora, thus using canadian or french locale... * Not for the deal about Louisiana, of course. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
EduBlog git hosting - please add my key
Hi, Please add my rsa key to the EduBlog git respository. Thanks, Tarun ssh-rsa B3NzaC1yc2EBIwAAAQEAyDevtQVQWZdJto9sdWwLMGlKoWHryzxkZ2UJEOh/kqB3LlWMYJeOFX7yoI/LC/PqD+7M7lS27KKi4uBX+NzwqLXwoQqoxNwSR3ImwxbAAfwb+s4gNWAe3wVjF6Pb/D9lUV0v9FTaZ9l7l0TpyYcg7IJl1kV09IbYbSt0L3lxdlqYBh1XTL/Z8AIB9hp3X6buTBqQKtQFxky/HxMAeoV31MCsWje8GRuB1NPhM/O7y9hzO09I1FxUeBZ9mgDj6fS7ltgjdRRRIQX9kTsJ0zwXS1TPKA8PAVddGd6sk4M92+2XeKfven7gD3Cpl+urpz23NUVURp/IqgNSQYEivDHDFw== [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Networking] TCP is broken in mesh mode
On Wed, 11 Jun 2008, Trent Lloyd wrote: > Keep in mind however that the other traffic, i.e. discovering the > other XO is a multicast packet and therefor would be routed on the > mesh somewhat differently AIUI (its basically re-broadcasted by every > node?) > > Thus I suspect the issue is the nodes simply have no direct > communication at all given the lack of replies to the ARP packets.. > and any "other" tcp or ping is not going ot work if arps simply aren't > being replied to, as ARPs are in no way specific to the connection type. > > Thus I suspect the issue is that multicast forward is working (which > seems perfectly sane mentally, given what I know as the difference > between how unicast and multicast work on the mesh) but the direct > node-node path is totally broken and this would be a relatively > pointless excercise. > > I guess getting the mesh neighbour tables per Bill's email would be > the most useful step forward. And arp tables, that will give the idea if ARP responses were received and used to correctly update the tables. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Switching to Kreyol ?
> Mhh.. I can't seem to find a good reference on this. I will try to > ask to some haitian developers. http://en.wikipedia.org/wiki/Kreyol The word Kreyol may mean: * Liberian Kreyol language * Haitian Creole language (Kreyòl ayisyen) * Kreyol Lwiziyen (Louisiana Creole) People in the US are probably familiar with Creole from the New Orleans region. (We bought Louisiana from France in 1803.) -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Switching to Kreyol ?
Bernie Innocenti <[EMAIL PROTECTED]> writes: > Bastien wrote: >> One quick question: how to switch a laptop to kreyol language? >> >> I was able to switch to french by just using fr_FR.UTF-8 in >> /home/olpc/.i18n but what is the equivalent for Kreyol? >> I tried kr_KR.UTF-8 and ht_HT.UTF-8 but it failed. > > This will give the list of all supported values for $LANG: > > locale -a > > This will add long names: > > locale -a -v > > The language "Kreyol" does not even seem to be supported in > glibc 2.8! Mhh.. I can't seem to find a good reference on this. I will try to ask to some haitian developers. > Does it have alternate names? Is it a dialect of > another language? Well, no, Kreyol is a language on its own. It's derived from many language (among them are french, english, spanish) and there are actually several kreyol variants (Haïti, Jamaïc, etc...) The Pootle has a single Kreyol instance, that's why I expected someone had already tested it on a XO. Thanks anyway for the pointers, I will keep you posted on this. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Release Status Report - 8.2.0
Testing People, Support People, Technical Contacts in Deployments,
Please see the note below from Michael Stone who is the release manager for
our upcoming 8.2.0 release. Along with Michael acting as a central contact
point for development input to this release, Joe Feinstein has recently
joined OLPC as our QA Lead. He will be generating the release criteria, and
directing the test planning and execution. They are currently working to
document the full list of features targeted for this release. Please send
your thoughts on release criteria to Joe (copying appropriate public lists).
I have added a number of people to the TO: list who are technical contacts
from various country deployments. We are talking about setting up a mailing
list of deployment technical people (deployment-tech?). This list would be
used for OLPC to post release and use-case information to countries. It can
also be used for countries to provide feedback on requested features and
serious bugs. Continue to use '[EMAIL PROTECTED]' ticketing system to report
bugs and get general help. Please respond if there is interest in this
mailing list.
Thanks,
Kim Quirk
VP Software and Support
-- Forwarded message --
From: Michael Stone <[EMAIL PROTECTED]>
Date: Thu, Jun 12, 2008 at 6:12 PM
Subject: Release Status Report - 8.2.0
To: devel@lists.laptop.org, [EMAIL PROTECTED]
Cc: Kim Quirk <[EMAIL PROTECTED]>
I promised regular status reports on our release work and I've been lax
in writing them. Here are my current thoughts on the content of and
risks associated with our second ("August") 2008 release, 8.2.0. These
assesments are heavily based on current rates of improvement and
available labor. (I'm seriously concerned about upcoming distractions,
but don't quite know how to factor them in.)
Current Thoughts:
* I'm EXPECTING major changes in:
a) Sugar frame/home-view rework - Marco
b) Sugar control panel- Simon
c) Browser improvements - Simon/Tomeu
d) F-9 Rebase - Dennis/Michael
e) Manually enabled power management- Chris/Scott/Deepak
f) Presence & collaboration reliability bugfixing
- Collabora, Morgan
g) Backup to XS
* I'm NOT EXPECTING major changes in
the Journal
the Datastore
activity isolation (modulo faster launching)
the neighborhood view
* I'm UNCERTAIN about what architectural changes will be available for
consideration in:
collaboration (e.g. gadget, cerebro, telepathy-cerebro).
- Collabora, Polychronis
theft deterrence - Scott, Emiliano
software provisioning (e.g. olpc-update / reflash) - Scott, Mitch
wireless/connectivity - Michailis, Cozybit, Deepak
I'm also UNCERTAIN about several CONFIGURATION DEFAULTS like:
touchpad in absolute or relative mode?
hot-corners delay?
activity placement algorithm / view
invalid browser certificate handling algorithm
Next steps:
If you're working on something where I'm expecting major change, then
we should discuss moving your changes from development into an
official test build for QA in the next week. I suggest contacting me
by public email with your first proposal. Documentation in Trac bugs
or wiki pages will be happily accepted.
(If you think I've misjudged an changeset, please reply so that we can
fix the issue.)
Open Questions:
* You want to make changes to the release candidates. What is your
burden of proof (of quality/readiness) today? What will it be N weeks
from now?
* We managed to ship the Ship.1? release only after we agreed on the
"WE ARE DONE WHEN: ..." list. What are the contents of the release
checklist this time around? (Need to figure out how to involve the
deployment tech leads... in answering this).
Thanks,
Michael
P.S. - Ancillary documentation:
Release Process: http://wiki.laptop.org/go/Plan_of_Record-2008
Priorities: http://wiki.laptop.org/go/Priorities-2008
Stub 8.1.1 Features: http://wiki.laptop.org/go/OLPC_8.1.1_Features
(needs to be finished so we can write
http://wiki.laptop.org/go/OLPC_8.2.0_Features
for the QA dept).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: ANN: 8.1.1 Candidate Build - candidate-708
Michael Stone wrote: > Dear world, > > I'm pleased to announce that our first signed release candidate for the > 8.1.1 bugfix release is now available for downloading and updating. > Please help test it by I did, it basically worked fine with some minor glitches (marked ==> below). Thanks! > > 1. Procuring activities if you need them. See the release notes for > details. (I had updated my G1G1 to 703 a few weeks ago. For some reason installing the G1G1 activity pack from my USB flash drive didn't work for me and I had used Bert's script to install.) > 2a. olpc-update -f candidate-708 && reboot D'oh, first time I didn't use the -f option. `olpc-update candidate-708` displayed Trying irsync_pristine update from rsync://updates.laptop.org/build-candidate-708 ... Verifying update. Contents manifest failure at line 383 Last file examined: localtime (Maybe that's why you said use -f.) Then it went on to Trying irsync_dirty update from rsync://updates.laptop.org/build-candidate-708 - Creating contents for existing tree. Traceback (most recent call last): File "/usr/sbin/olpc-contents-create", line 90, in ... File "/usr/lib/python2.5/ utils.py, line 100, in mkdirobject entry['h'] = mkhashes (file(fullname), read()) MemoryError so I pressed Ctrl-C. Entering # free -m printed Mem: total 232, used 227, free 5, shared 0, buffers 0, cached 48 ==> Should update instructions suggest that users first stop running activities, or is this python "MemoryError" just an artifact of not using the -f "skip incremental update attempt" flag? Anyway, I retried using `olpc-update -f candidate-708` as instructed. It printed: WARNING: You seem to be attempting to download an unsigned development build, but you don't have a developer key. This will probably fail. ==> Is that warning expected since you said "signed release candidate" ? but it updated fine anyway. My laptop restarted three times, the last one brought me into Sugar. Home view > little guy > About this XO displays Build update.1 708 Firmware: Q2D16 Serial Number: CSN748011C2 ==> Maybe "About this XO" should say "8.1.1" and/or "candidate" instead of "update.1" part, otherwise looks fine! > please help update the > http://wiki.laptop.org/go/OLPC_8.1.1_Software_Release_Notes I reorganized it a bit to focus first on changes from Update.1, and tweaked other referenced pages. HTH, XO FTW, BBL, -- =S Page ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TWIN (tiny window system) on XO.
Hi Arnd, On Wed, Jun 11, 2008 at 10:42 PM, Arnd Bergmann <[EMAIL PROTECTED]> wrote: > On Wednesday 11 June 2008, Bert Freudenberg wrote: (snip) > It is being used by the 'petitboot' graphical boot loader on the > PlayStation 3, using fbdev, and works very well there. This is very useful to know.. thank you very much for this. Cheers, Paul ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Networking] TCP is broken in mesh mode
Hi All, On 11/06/2008, at 3:20 AM, Polychronis Ypodimatopoulos wrote: >> >> >> 1. A broadcasts an ARP request for B >> 2. B sees the ARP request and replies to A >> 3. A receives the ARP reply from B and sends a TCP SYN to B >> 4. B does not see the SYN packet (it does not appear in B's dump) >> 5. A retries a total of three times, but none of the SYN packets >> are seen >> by B. >> 3b. In parallel, A broadcasts a presence-info update with mDNS, >> indicating >> that it has shared the activity. >> 4b. B receives this broadcast, updates its presence-info cache, and >> even >> assigns B's XO icon a new location in the mesh view >> >> This behavior is fairly frightening. I have seen it occur in low- >> noise >> network environments with a total of 3 XOs, so I suspect a serious >> bug >> somewhere in the lowest levels of the network stack. Once this >> failure >> occurs, it is extremely reproducible. All subsequent invitations >> will >> continue to fail. I therefore suspect that the bug involves the >> driver or >> firmware reaching an invalid state and becoming stuck there. >> > > > You have to keep in mind that the driver/firmware may very well have > bugs, but: > > 1) the driver does not differentiate between different TCP/IP packets > (but may wrongly differentiate between unicast and broadcast/ > multicast). > Try establishing a separate TCP/IP connection when invitations > reproducibly don't work. > > 2) the firmware (in terms of a route existing or not) does not > differentiate between frames. Try pinging the other node when > invitations reproducibly don't work. Keep in mind however that the other traffic, i.e. discovering the other XO is a multicast packet and therefor would be routed on the mesh somewhat differently AIUI (its basically re-broadcasted by every node?) Thus I suspect the issue is the nodes simply have no direct communication at all given the lack of replies to the ARP packets.. and any "other" tcp or ping is not going ot work if arps simply aren't being replied to, as ARPs are in no way specific to the connection type. Thus I suspect the issue is that multicast forward is working (which seems perfectly sane mentally, given what I know as the difference between how unicast and multicast work on the mesh) but the direct node-node path is totally broken and this would be a relatively pointless excercise. I guess getting the mesh neighbour tables per Bill's email would be the most useful step forward. Regards, Trent ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Localization] [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
James Cameron <[EMAIL PROTECTED]> writes: > On Mon, Jun 09, 2008 at 06:19:58PM -0700, [EMAIL PROTECTED] wrote: >> but demanding that OLPC make them available in more places, and at the >> same time threatening them unless they provide dozens of localized >> versions, is not productive. > > Agreed. If this is going to cost too much, just give up on Europe. > Concentrate on what you are good at. Humor? > (In Australia, we use US keyboard layout, and only occasionally miss > having the BBQ and PUB keys.) Humor. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Switching to Kreyol ?
Bastien wrote: > One quick question: how to switch a laptop to kreyol language? > > I was able to switch to french by just using fr_FR.UTF-8 in > /home/olpc/.i18n but what is the equivalent for Kreyol? > I tried kr_KR.UTF-8 and ht_HT.UTF-8 but it failed. This will give the list of all supported values for $LANG: locale -a This will add long names: locale -a -v The language "Kreyol" does not even seem to be supported in glibc 2.8! Does it have alternate names? Is it a dialect of another language? -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Release Status Report - 8.2.0
Hi Deepak, > On Jun 12 2008, at 18:12, Michael Stone was caught saying: >> * I'm EXPECTING major changes in: >> >> e) Manually enabled power management - Chris/Scott/Deepak > Chris, Scott, what all do you need from kernel side for this? > Specific trac defects would be good. :) The direct dependencies are modular USB (#6935) and being able to turn off the wireless chipset (#3355). Before we can ship power management, though, we should also fix: * the SD corruption bug (#6532) -- if we can't fix it in time, we can inhibit suspend when an SD card is plugged in. * pushing wakeup decisions to the EC (#6010) -- this will make the wakeup logic more reliable. Thanks! - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Switching to Kreyol ?
One quick question: how to switch a laptop to kreyol language? I was able to switch to french by just using fr_FR.UTF-8 in /home/olpc/.i18n but what is the equivalent for Kreyol? I tried kr_KR.UTF-8 and ht_HT.UTF-8 but it failed. Or maybe I think it failed because the translation is not complete? Where could I check this? Thanks! -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Release Status Report - 8.2.0
On Jun 12 2008, at 18:12, Michael Stone was caught saying: > * I'm EXPECTING major changes in: > > e) Manually enabled power management- Chris/Scott/Deepak Chris, Scott, what all do you need from kernel side for this? Specific trac defects would be good. :) ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Release Status Report - 8.2.0
I promised regular status reports on our release work and I've been lax
in writing them. Here are my current thoughts on the content of and
risks associated with our second ("August") 2008 release, 8.2.0. These
assesments are heavily based on current rates of improvement and
available labor. (I'm seriously concerned about upcoming distractions,
but don't quite know how to factor them in.)
Current Thoughts:
* I'm EXPECTING major changes in:
a) Sugar frame/home-view rework - Marco
b) Sugar control panel- Simon
c) Browser improvements - Simon/Tomeu
d) F-9 Rebase - Dennis/Michael
e) Manually enabled power management- Chris/Scott/Deepak
f) Presence & collaboration reliability bugfixing
- Collabora, Morgan
g) Backup to XS
* I'm NOT EXPECTING major changes in
the Journal
the Datastore
activity isolation (modulo faster launching)
the neighborhood view
* I'm UNCERTAIN about what architectural changes will be available for
consideration in:
collaboration (e.g. gadget, cerebro, telepathy-cerebro).
- Collabora, Polychronis
theft deterrence - Scott, Emiliano
software provisioning (e.g. olpc-update / reflash) - Scott, Mitch
wireless/connectivity - Michailis, Cozybit, Deepak
I'm also UNCERTAIN about several CONFIGURATION DEFAULTS like:
touchpad in absolute or relative mode?
hot-corners delay?
activity placement algorithm / view
invalid browser certificate handling algorithm
Next steps:
If you're working on something where I'm expecting major change, then
we should discuss moving your changes from development into an
official test build for QA in the next week. I suggest contacting me
by public email with your first proposal. Documentation in Trac bugs
or wiki pages will be happily accepted.
(If you think I've misjudged an changeset, please reply so that we can
fix the issue.)
Open Questions:
* You want to make changes to the release candidates. What is your
burden of proof (of quality/readiness) today? What will it be N weeks
from now?
* We managed to ship the Ship.1? release only after we agreed on the
"WE ARE DONE WHEN: ..." list. What are the contents of the release
checklist this time around? (Need to figure out how to involve the
deployment tech leads... in answering this).
Thanks,
Michael
P.S. - Ancillary documentation:
Release Process: http://wiki.laptop.org/go/Plan_of_Record-2008
Priorities: http://wiki.laptop.org/go/Priorities-2008
Stub 8.1.1 Features: http://wiki.laptop.org/go/OLPC_8.1.1_Features
(needs to be finished so we can write
http://wiki.laptop.org/go/OLPC_8.2.0_Features
for the QA dept).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
RE: Upgrade G1G1 using autoreinstallation method
Thanks - solved. It's all there on the wiki, yes (blush). We have a lot of time pressures imposed by the political realities here, with 20+ countries each with their own government and process to go through, etc. I do appreciate your help! Do you also know about access points, it was stressed at the Countries meeting in Boston that 30+ XOs in one classroom do not collaborate very efficiently and the preferred method is to use an AP to enable collaboration/sharing in the classroom, even if there is no Internet access. We have had some D-Link DWL2100 APs sent to us for this purpose and what happens is that if there is no Internet connection the XOs do not associate themselves persistently with the APs but "hang up" and go looking for the mesh. Do you know anything about that? David Leeming -Original Message- From: Bert Freudenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 June 2008 7:28 p.m. To: David Leeming Cc: [EMAIL PROTECTED] Subject: Re: Upgrade G1G1 using autoreinstallation method On 12.06.2008, at 05:53, David Leeming wrote: > How can I upgrade G1G1 XO-1s using the auto-reinstallation method > with a flash drive? We have 100 to update here in PNG and it is > impossible to use olpc-update as the connectivity is so poor. We > have a flash drive with the new image 703 on it, and I successfully > updated a B4. But when I try a G1G1 laptop, even with pressing the > game keys it just boots normally without updating. I know I have > some gaps in my knowledge regarding the keys and security for the > G1G1 laptops, but unfortunately I need a quick answer. Much > appreciate any help. Make sure it is the signed build (called "703" not "update.1-703"), and remember you need an activity pack, too. See here: http://wiki.laptop.org/go/Secure_Upgrade - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Project name: EduBlog has been set up
Thanks very much ! I got the code on the tree :-) Yes, I Tarun will send his new key soon. Cheers, Marcel On Thu, Jun 12, 2008 at 4:08 PM, Henry Edward Hardy <[EMAIL PROTECTED]> wrote: > Mon, 26 May 2008 23:23:20 -0300, [EMAIL PROTECTED] wrote: > > Project Name: EduBlog > > Done. Your tree is here: > git+ssh://[EMAIL PROTECTED]/git/projects/EduBlog > > Please follow instructions here for importing your project: > http://wiki.laptop.org/go/Importing_your_project > > We are anticipating receiving a new RSA key for the second committer. > > Let us know if you have any problems with your tree. Happy hacking. > > Cheers, > > -- > Henry Edward Hardy > [EMAIL PROTECTED] > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
2008/6/12 Dennis Gilmore <[EMAIL PROTECTED]>: > On Thursday 12 June 2008, C. Scott Ananian wrote: >> Is the piece we're missing the correlation with koji branches / >> repository names? I've tried to encourage people to think of a more >> clever naming scheme, but lacking that I suggest that we name our >> branches according to our stable releases. For example: >> olpc8.1 <- repo for 8.1, 8.1.1, 8.1.2, etc >>with tags for each release >> olpc8.2 <- repo for 8.2, 8.2.1, 8.2.2, etc >>with tags for each release >> >> So our 'stable' build currently would come from the olpc8.1 branch, >> testing from olpc8.2, and unstable from olpc8.2 plus an 'unstable' >> repository or an 'olpc8.2-unstable' tag. When we release 8.2 we start >> an olpc8.3 or olpc9.1 branch. >> >> Do we need the 'dist-' prefix currently used by koji? If so, then add >> 'dist-' to the tags above. >> --scott > This is fine as long as we know we cannot move from testing to stable when > stable is based on 8.1 and testing is based on 8.2 things may be ok but > differences in the toolchain could result in everything including the kitchen > sync being brought in. > > that is why i proposed that each stable tree has its own testing branch. If I understand you correctly, I agree: the "stable"/"testing"/"unstable" is just a simplification of the actual process, used to help clarify things to the general public and QA. In actual practice, there is also a separate staging area used to test "updates to a released stable build". Renaming 'testing' to 'stable' happens atomically when we do a release. Updates to the stable build after that happen on a special testing branch which is separate from the "testing"/"unstable" branches on which the next release is being formed. If we use 'dist-olpc8.1', 'dist-olpc8.2', etc branches in koji, then having 'dist-olpc8.1-testing' and 'dist-olpc8.2-testing' branches makes sense. For most cases, if 'dist-8.1' is stable then 'dist-8.2' is testing and 'dist-8.2-testing' is unstable, but preparation of an 8.1.1 may happen on 'dist-8.1-testing' if packages can't be pulled directly from 'dist-8.2'. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
On Thursday 12 June 2008, C. Scott Ananian wrote: > Is the piece we're missing the correlation with koji branches / > repository names? I've tried to encourage people to think of a more > clever naming scheme, but lacking that I suggest that we name our > branches according to our stable releases. For example: > olpc8.1 <- repo for 8.1, 8.1.1, 8.1.2, etc >with tags for each release > olpc8.2 <- repo for 8.2, 8.2.1, 8.2.2, etc >with tags for each release > > So our 'stable' build currently would come from the olpc8.1 branch, > testing from olpc8.2, and unstable from olpc8.2 plus an 'unstable' > repository or an 'olpc8.2-unstable' tag. When we release 8.2 we start > an olpc8.3 or olpc9.1 branch. > > Do we need the 'dist-' prefix currently used by koji? If so, then add > 'dist-' to the tags above. > --scott This is fine as long as we know we cannot move from testing to stable when stable is based on 8.1 and testing is based on 8.2 things may be ok but differences in the toolchain could result in everything including the kitchen sync being brought in. that is why i proposed that each stable tree has its own testing branch. Dennis signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
Is the piece we're missing the correlation with koji branches / repository names? I've tried to encourage people to think of a more clever naming scheme, but lacking that I suggest that we name our branches according to our stable releases. For example: olpc8.1 <- repo for 8.1, 8.1.1, 8.1.2, etc with tags for each release olpc8.2 <- repo for 8.2, 8.2.1, 8.2.2, etc with tags for each release So our 'stable' build currently would come from the olpc8.1 branch, testing from olpc8.2, and unstable from olpc8.2 plus an 'unstable' repository or an 'olpc8.2-unstable' tag. When we release 8.2 we start an olpc8.3 or olpc9.1 branch. Do we need the 'dist-' prefix currently used by koji? If so, then add 'dist-' to the tags above. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
On Thursday 12 June 2008, Chris Ball wrote: > Hi Dennis, > >> from your initial email: Stable: Stable builds are specified by >> their release name (e.g. 8.1.1, 8.2), and the procedure for >> packages moving from Testing into Stable releases involves the >> Unscheduled Release Process: >> http://wiki.laptop.org/go/Unscheduled_software_release_process >> >> that indicate you intend to move updates from a F-9 base to a F-7 >> base. I dont know how else to read it. if im wrong please tell me >> how i should interpret it. > > The interpretation should be that we'll have an F-9 base in testing, and > then we'll make a release called, say, 8.2 that contains that build. > For the release after that, we'll have an F-10 base in testing, and > then we'll make a build called 8.3 that contains that. There is no > overlap between the 8.2 stable build and the 8.3 stable build; they're > independent. > > Perhaps you're having trouble because you're imagining "stable" as > existing permanently, rather than once per release. Stable is just a > symlink to the latest build that made it out of testing into a named > release. There would never be a reason to have stable be a different > base to the testing build that it came from. so what happens when we have 2 or stable releases to support. how do i get updates into the older ones? this is the workflow that i am envisioning. >> We constantly seem to be having the debian does it this way so lets >> do it that way discussion. rather than asking how fedora does it. > > I don't think we're borrowing anything from Debian other than the names > "unstable", "testing" and "stable". We aren't giving them the meanings > that Debian assigns to those names. We aren't proposing any > modification of our build process, even, except for a separate build > that takes changes less regularly than Joyride so that it can have > stronger change control. I don't have an issue with the naming. its is the fact that we will have multiple stable releases to support. and I don't see how we can do that with the proposed format. to me and i feel like i'm on the outside here. it looks like we have taken the workflow that debian has and said we will do the same. >> If we find the fedora way to be lacking then we should work to >> improve that. if it means looking at how Debian does it and saying >> thats much better then so be it. but lets not make it the first >> choice. We should work to improve the fedora process for all of >> fedora's users derivatives. > > I don't know of a "Fedora way" (or a "Debian way") for creating a > separate build stream for testing at a slower rate than Rawhide; let me > know if there is. It sounds like you're chiefly upset that we're using > the unstable/testing/stable nomenclature. I don't much care about what > we call them; feel free to propose alternate names if it would make you > happier. the workflow i'm envisioning releases will be similar to the way that fedora unity releases update respins. in that when we fork from the development tree. we have a series of releases to stabalise the builds. but we will continue development for that branch at a much slower pace. fixing bugs etc. we will then do periodic spins from it. The main difference to what you proposed and what i.m proposing is that we will be supporting multiple stable branches. and some adjustments in workflow to accommodate those changes. We should talk about this tuesday afternoon when im there in person. It will be the only time that i am in the office next week. The rest of my the week ill be doing things for fudcon. I will be in 1cc 23rd-27th Dennis signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
I think I can see Dennis's confusion about packages moving from F9 to F7, the initial writeup contains this: * Stable: Stable builds are specified by their release name (e.g. 8.1.1, > 8.2), and the procedure for packages moving from Testing into Stable > releases involves the Unscheduled Release Process: >http://wiki.laptop.org/go/Unscheduled_software_release_process This implies to me that individual packages *will* be copied from testing to stable. It might be better to say "the procedure for applying patches to Stable releases involves the Unscheduled Release Process", or something like that? Best, -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project: listen-spell is set up
Wed, 11 Jun 2008 17:16:41 +0530, [EMAIL PROTECTED] wrote: 1. Project name : Listen and Spell Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/projects/listen-spell Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
Hi Dennis, > from your initial email: Stable: Stable builds are specified by > their release name (e.g. 8.1.1, 8.2), and the procedure for > packages moving from Testing into Stable releases involves the > Unscheduled Release Process: > http://wiki.laptop.org/go/Unscheduled_software_release_process > that indicate you intend to move updates from a F-9 base to a F-7 > base. I dont know how else to read it. if im wrong please tell me > how i should interpret it. The interpretation should be that we'll have an F-9 base in testing, and then we'll make a release called, say, 8.2 that contains that build. For the release after that, we'll have an F-10 base in testing, and then we'll make a build called 8.3 that contains that. There is no overlap between the 8.2 stable build and the 8.3 stable build; they're independent. Perhaps you're having trouble because you're imagining "stable" as existing permanently, rather than once per release. Stable is just a symlink to the latest build that made it out of testing into a named release. There would never be a reason to have stable be a different base to the testing build that it came from. > We constantly seem to be having the debian does it this way so lets > do it that way discussion. rather than asking how fedora does it. I don't think we're borrowing anything from Debian other than the names "unstable", "testing" and "stable". We aren't giving them the meanings that Debian assigns to those names. We aren't proposing any modification of our build process, even, except for a separate build that takes changes less regularly than Joyride so that it can have stronger change control. > If we find the fedora way to be lacking then we should work to > improve that. if it means looking at how Debian does it and saying > thats much better then so be it. but lets not make it the first > choice. We should work to improve the fedora process for all of > fedora's users derivatives. I don't know of a "Fedora way" (or a "Debian way") for creating a separate build stream for testing at a slower rate than Rawhide; let me know if there is. It sounds like you're chiefly upset that we're using the unstable/testing/stable nomenclature. I don't much care about what we call them; feel free to propose alternate names if it would make you happier. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project name: EduBlog has been set up
Mon, 26 May 2008 23:23:20 -0300, [EMAIL PROTECTED] wrote: Project Name: EduBlog Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/projects/EduBlog Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project We are anticipating receiving a new RSA key for the second committer. Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
On Thursday 12 June 2008, Chris Ball wrote: > Hi Dennis, > >> As i have said previously and repeatedly been ignored (like most of >> what i say). this process will not work. period. It cant be made >> to work in the same fashion as Debian because its not Debian. >> everyone needs to quit trying to fit square pegs into round holes. >> >> things more than likely will never be able to move from testing >> into stable in the proposed format. why? because Testing is based >> on F-9 and uses the F-9 toolchain and dependencies. and stable is >> based on F-7 which uses completely different toolchain and >> dependencies. We need finer grained control over things. > > I think you need to read the proposal again. Unstable and Testing would > immediately be based on F9, and there is no "stable" other than released > builds -- stable is what happens to testing when it's done, so there's > no mix of F9 and F7 here. An F9 testing build becomes an F9 stable > release with its own release name, such as 8.1.1. from your initial email: Stable: Stable builds are specified by their release name (e.g. 8.1.1, 8.2), and the procedure for packages moving from Testing into Stable releases involves the Unscheduled Release Process: http://wiki.laptop.org/go/Unscheduled_software_release_process that indicate you intend to move updates from a F-9 base to a F-7 base. I dont know how else to read it. if im wrong please tell me how i should interpret it. >> Throw away what you know about debian's process. right now it >> counts for squat. > > I don't know what you mean by this. All we're doing is defining three > build names, and (our own) processes for moving packages between them. We constantly seem to be having the debian does it this way so lets do it that way discussion. rather than asking how fedora does it. If we find the fedora way to be lacking then we should work to improve that. if it means looking at how Debian does it and saying thats much better then so be it. but lets not make it the first choice. We should work to improve the fedora process for all of fedora's users derivatives. Dennis P.S. please reply to list and not CC me on mail to lists i'm known to be subscribed to. /me would like to see us doing a better job of not cross posting email and not replying to all but just to list. signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
Hi Dennis, > As i have said previously and repeatedly been ignored (like most of > what i say). this process will not work. period. It cant be made > to work in the same fashion as Debian because its not Debian. > everyone needs to quit trying to fit square pegs into round holes. > things more than likely will never be able to move from testing > into stable in the proposed format. why? because Testing is based > on F-9 and uses the F-9 toolchain and dependencies. and stable is > based on F-7 which uses completely different toolchain and > dependencies. We need finer grained control over things. I think you need to read the proposal again. Unstable and Testing would immediately be based on F9, and there is no "stable" other than released builds -- stable is what happens to testing when it's done, so there's no mix of F9 and F7 here. An F9 testing build becomes an F9 stable release with its own release name, such as 8.1.1. > Throw away what you know about debian's process. right now it > counts for squat. I don't know what you mean by this. All we're doing is defining three build names, and (our own) processes for moving packages between them. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
On Thursday 12 June 2008, Chris Ball wrote: > Hi, > > At the IRC software meeting yesterday we discussed creating some new > build streams in preparation for our August "8.2" release. These > streams were proposed: > > * Unstable/Joyride: This will move immediately (well, within a day or > two) to be a copy of the "olpc-3" stream, which is a build stream > preparing for a switch to Fedora 9, instead of the current Fedora 7. > > The Joyride release process will continue to be followed here. There > is still a lot of work to be done on the F9-based build: it will be > broken for a while as the kinks are worked out. Please help! > > * Testing: This will also be a copy of olpc-3, but with a different > release process. Changes will be moved from unstable into testing > upon negotiation with the release engineer, Michael Stone. This > build stream will be used by our QA team and community to assess > the readiness of features for the 8.2 release. > > * Stable: Stable builds are specified by their release name (e.g. 8.1.1, > 8.2), and the procedure for packages moving from Testing into Stable > releases involves the Unscheduled Release Process: > http://wiki.laptop.org/go/Unscheduled_software_release_process > > Anyone familiar with Debian's build naming will see intentional > similarities here. As i have said previously and repeatedly been ignored (like most of what i say). this process will not work. period. It cant be made to work in the same fashion as Debian because its not Debian. everyone needs to quit trying to fit square pegs into round holes. things more than likely will never be able to move from testing into stable in the proposed format. why? because Testing is based on F-9 and uses the F-9 toolchain and dependencies. and stable is based on F-7 which uses completely different toolchain and dependencies. We need finer grained control over things. We need to follow the fedora process here if we want things to work. Throw away what you know about debian's process. right now it counts for squat. Each stable tree need to have its own updates and updates-testing tree. which means once we create a stable branch we no longer build to it instead we build to a updates-testing-candidate tag we them move a package to updates-testing after testing we move to updates we can then do stable releases based on base + updates So we now have dist-olpc3 its a development tree things are automatically added to that tree as built. when we release a stable build on dist-olpc3 we freeze that tag forever. potential updates will then get build against dist-olpc3 and dist-olpc3-updates. they will land in dist-olpc3-updates-candidate developer will request that they get pushed to dist-olpc3-testing a which point rpms will be signed and pushed to a yum repository where they can be tested. once they have proved themselves in testing. we can then push to dist-olpc3-updates. This means that we will sign all the rpms we push for stable trees. we will need to have a popper master mirror that can be mirrored out. development tree rpms will be unsigned. we can then maintain multiple stable trees. if we need to maintain two stable trees off of one fedora release then we can branch things and have a dist-olpc3-1 for instance I want to reiterate that OLPC needs to work with fedora. We are based on Fedora and continue to cause ourselves unneeded pain by not working with fedora. If someone is looking for a good way to contribute to OLPC then please get involved in packaging for Fedora. we have many things that need to be put into fedora.including olpcrd etoys pyabiword rainbow olpcupdate olpccontents bootanim bootfw fonts-thai-ttf olpc-library-core olpc-library-common olpc-licenses squeak-vm olpc-logos libabiword libabiword-plugins GConf2-dbus hulahop Some of the require other packages not in fedora. some of which olpc has forked. we also need to ensure we do our work upstream. doing things upstream means that 1) We help everybody not just ourselves 2) that the maintainence burden is smaller Dennis signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANN: 8.1.1 Candidate Build - candidate-708
Great! Thanks for the updates, S Page! Michael, Scott, I believe the incorrect warning message that you are trying to load a build that isn't secure on a secure machine has been a bug for the last couple of builds. I wrote it up: 7265 ( http://dev.laptop.org/ticket/7265). Thanks, Kim On Thu, Jun 12, 2008 at 2:12 AM, S Page <[EMAIL PROTECTED]> wrote: > Michael Stone wrote: > > Dear world, > > > > I'm pleased to announce that our first signed release candidate for the > > 8.1.1 bugfix release is now available for downloading and updating. > > Please help test it by > > I did, it basically worked fine with some minor glitches (marked ==> > below). Thanks! > > > > > 1. Procuring activities if you need them. See the release notes for > > details. > > (I had updated my G1G1 to 703 a few weeks ago. For some reason > installing the G1G1 activity pack from my USB flash drive didn't work > for me and I had used Bert's script to install.) > > > 2a. olpc-update -f candidate-708 && reboot > > D'oh, first time I didn't use the -f option. `olpc-update > candidate-708` displayed > > Trying irsync_pristine update from > rsync://updates.laptop.org/build-candidate-708 > ... > Verifying update. > Contents manifest failure at line 383 > Last file examined: localtime > > (Maybe that's why you said use -f.) > > Then it went on to > > Trying irsync_dirty update from > rsync://updates.laptop.org/build-candidate-708 > - Creating contents for existing tree. > Traceback (most recent call last): > File "/usr/sbin/olpc-contents-create", line 90, in > ... > File "/usr/lib/python2.5/ utils.py, line 100, in mkdirobject >entry['h'] = mkhashes (file(fullname), read()) > MemoryError > > so I pressed Ctrl-C. > > Entering > # free -m > printed > Mem: total 232, used 227, free 5, shared 0, buffers 0, cached 48 > > ==> Should update instructions suggest that users first stop running > activities, or is this python "MemoryError" just an artifact of not > using the -f "skip incremental update attempt" flag? > > Anyway, I retried using `olpc-update -f candidate-708` as instructed. > It printed: > > WARNING: You seem to be attempting to download an unsigned > development build, but you don't have a developer key. This will > probably fail. > > ==> Is that warning expected since you said "signed release candidate" ? > > but it updated fine anyway. > > My laptop restarted three times, the last one brought me into Sugar. > > Home view > little guy > About this XO displays > Build update.1 708 > Firmware: Q2D16 > Serial Number: CSN748011C2 > > > ==> Maybe "About this XO" should say "8.1.1" and/or "candidate" instead > of "update.1" part, otherwise looks fine! > > > please help update the > > http://wiki.laptop.org/go/OLPC_8.1.1_Software_Release_Notes > > I reorganized it a bit to focus first on changes from Update.1, and > tweaked other referenced pages. > > HTH, XO FTW, BBL, > -- > =S Page > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams; preparing for 8.2 release.
Looks good to me. Thanks for writing it up. Kim On Thu, Jun 12, 2008 at 1:12 PM, Chris Ball <[EMAIL PROTECTED]> wrote: > Hi, > > At the IRC software meeting yesterday we discussed creating some new > build streams in preparation for our August "8.2" release. These > streams were proposed: > > * Unstable/Joyride: This will move immediately (well, within a day or > two) to be a copy of the "olpc-3" stream, which is a build stream > preparing for a switch to Fedora 9, instead of the current Fedora 7. > > The Joyride release process will continue to be followed here. There > is still a lot of work to be done on the F9-based build: it will be > broken for a while as the kinks are worked out. Please help! > > * Testing: This will also be a copy of olpc-3, but with a different > release process. Changes will be moved from unstable into testing > upon negotiation with the release engineer, Michael Stone. This > build stream will be used by our QA team and community to assess > the readiness of features for the 8.2 release. > > * Stable: Stable builds are specified by their release name (e.g. 8.1.1, > 8.2), and the procedure for packages moving from Testing into Stable > releases involves the Unscheduled Release Process: >http://wiki.laptop.org/go/Unscheduled_software_release_process > > Anyone familiar with Debian's build naming will see intentional > similarities here. > > Apologies in advance for any misunderstandings or omissions from the > discussion that crept in to this mail -- don't take this summary as > ratified until this thread stops getting new replies. :) > > Thanks! > > - Chris. > -- > Chris Ball <[EMAIL PROTECTED]> > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Build streams; preparing for 8.2 release.
Hi, At the IRC software meeting yesterday we discussed creating some new build streams in preparation for our August "8.2" release. These streams were proposed: * Unstable/Joyride: This will move immediately (well, within a day or two) to be a copy of the "olpc-3" stream, which is a build stream preparing for a switch to Fedora 9, instead of the current Fedora 7. The Joyride release process will continue to be followed here. There is still a lot of work to be done on the F9-based build: it will be broken for a while as the kinks are worked out. Please help! * Testing: This will also be a copy of olpc-3, but with a different release process. Changes will be moved from unstable into testing upon negotiation with the release engineer, Michael Stone. This build stream will be used by our QA team and community to assess the readiness of features for the 8.2 release. * Stable: Stable builds are specified by their release name (e.g. 8.1.1, 8.2), and the procedure for packages moving from Testing into Stable releases involves the Unscheduled Release Process: http://wiki.laptop.org/go/Unscheduled_software_release_process Anyone familiar with Debian's build naming will see intentional similarities here. Apologies in advance for any misunderstandings or omissions from the discussion that crept in to this mail -- don't take this summary as ratified until this thread stops getting new replies. :) Thanks! - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
School server on F8?
Are there any F8 RPMs for the school-server code? Our behemoth server is F8-based, partially because some of the hardware is only supported in F8 Kernels 2.6.24 and greater (Marvell P-ATA chips, etc). -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrade G1G1 using autoreinstallation method
On 12.06.2008, at 05:53, David Leeming wrote: > How can I upgrade G1G1 XO-1s using the auto-reinstallation method > with a flash drive? We have 100 to update here in PNG and it is > impossible to use olpc-update as the connectivity is so poor. We > have a flash drive with the new image 703 on it, and I successfully > updated a B4. But when I try a G1G1 laptop, even with pressing the > game keys it just boots normally without updating. I know I have > some gaps in my knowledge regarding the keys and security for the > G1G1 laptops, but unfortunately I need a quick answer. Much > appreciate any help. Make sure it is the signed build (called "703" not "update.1-703"), and remember you need an activity pack, too. See here: http://wiki.laptop.org/go/Secure_Upgrade - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
