Re: slides from solar talk (ongoing now)
Sorry I missed today's discussion -- Easter celebrations went on quite a bit longer than I expected. The charge controller looks like a great project. I know there would be a number of markets for that even outside of the OLPC projects. I'm always looking for inexpensive charge controllers since the way we charge batteries has a lot to do with how long they will last and how many cycles they can undergo. An affordable MPPT controller is a great idea! The refrigeration project I am working on requires a solar panel, charge controller and battery. Pretty simple design... and I would like to specify and MPPT controller, but I'm not sure they can afford it. PWM (pulse width modulation) is better than no controller. Thanks for inviting me, Adam. Don't hesitate to send questions on renewable energy projects -- not sure if I can help, but I'd give it a try. Regards, Kim Quirk On Sun, Apr 4, 2010 at 5:17 PM, Holt h...@laptop.org wrote: Low-Cost Solar Charge Controller with the Maximum Power Point Tracking for the Developing World by Robert Pilawa, MIT Solar Researcher PhD Student http://www.slideshare.net/metasj/olpc-apr-4-2010 -- Energy Emporium 60 Main St, PO Box 351 Enfield, NH 03748 603.632.1263 http://www.energyemp.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. If schools agree that this a good idea (it also wipes all the data and provides students with a lot more room); then what I would push for is that saved data can continue to work on upgraded activities -- this is something that the activity developers have to worry about, but it decreases the test effort quite a bit and recommends that schools retest activities between school years. Kim On Mon, Jul 14, 2008 at 9:14 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Responding to all in one pass. From Scott - The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. GS - Sounds good but it still requires all activity developers to update their activities which I think is the central problem. Also, we still need to warn users in advance, especially if they upgrade via USB. Definitely will help so let's do it if its not too much work. From Michael - 2 - Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions GS - How certain are these and is there any documentation of them or what activity changes they will require? We should agree that they are must have items worth requiring activity upgrade before doing them and we should document what it will cost activity developers if we do. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. and related comments GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. GS - I'm asking if we can tell developers here are the things you can do which will be safe. That is, make some kind of promise of backward compatibility for some subset of all functionality. http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html GS - Will read Monday, thanks. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? GS - I thought it was precise :-) and I meant not. I want to know if we can promise that *any* activities will continue to work. I hoped that these Sugar activities are the only ones using some APIs (e.g. collaboration) and therefore the only ones susceptible to breakage. In the future if
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hmmm... I'm not sure that we have to lose all the information just becuase we did a clean install. If the backup of user data can be recovered (especially on a file by file basis). Don't we keep the meta data, so if the user choose to bring those items back into their laptop don't they still have date and time stamps, etc.? Kim On Mon, Jul 14, 2008 at 10:35 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 4:24 PM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. What if the web interface to the backups in the school server is as good or better than the local journal? Does it change any bit this issue? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Subject: Re: New 8.2 Stream To: OLPC Devel
For a 'change log' that is useful for both development and testing groups, I would like to ask that people please use the comments during check-in to add the trac item being fixed (when available) and a short description that would help others to know what to test or what feature has been added. We used to get these changelogs... and it was really helpful for the test groups. Kim On Fri, Jul 11, 2008 at 8:37 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, Interesting links, especially the diffs! I posted these links on the 8.2.0 overview page in a new section: http://wiki.laptop.org/go/8.2.0#Latest_Build_and_Diffs_from_Previous_Builds Let me know if that is OK with you. Can you add a little more to the explanation for these on the wiki page? This looks like information which will be important for developers (e.g. does it tell you where to get the latest code to add your fixes to?) and possibly testers. However, I think it will be more useful with a little more explanation. Thanks, Greg S * Message: 11 Date: Fri, 11 Jul 2008 10:25:35 +0200 From: Bert Freudenberg [EMAIL PROTECTED] Subject: Re: New 8.2 Stream To: OLPC Devel devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Am 11.07.2008 um 05:43 schrieb Bobby Powers: 2008/7/10 Dennis Gilmore [EMAIL PROTECTED]: in preparation for 8.2 we have a new 8.2 stream it can be found at http://pilgrim.laptop.org/~pilgrim/xo-1/streams/8.2/http://pilgrim.laptop.org/%7Epilgrim/xo-1/streams/8.2/ Please test and file bugs against it. This is the stream intended for the 8.2 test builds. This sounds good. Can you please explain how this differs from joyride, both at the moment and in the future? Is this based off of Joyride 21XX, what kind of sync will there be, etc. for the momentary difference see http://dev.laptop.org/~bert/8.2-joyride.htmlhttp://dev.laptop.org/%7Ebert/8.2-joyride.html I also added update.1-708 as 8.2-0 to see the initial differences: http://dev.laptop.org/~bert/8.2-pkgs.htmlhttp://dev.laptop.org/%7Ebert/8.2-pkgs.html - Bert - ___ 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: 8.2.0 Release Notes
We've had a couple of discussions about Release Notes and Feature lists. Here is my proposal: Feature lists -- I created a 'XO_Base_Features' page (which should keep the running list of features the XO supports as of the latest stable release). I added the as of release 8.1.1 to the top of this page. After 8.2 gets to be a stable release, then its features should be added the Base Feature doc and the note as of Release 8.2. Since there are many people working on docs that claim to be the 8.2 new feature set, I would like to recommend that Greg's 8.2 Release Notes contains the source data for the 8.2 new features. Everyone else should point to that and he will make sure this is kept up to date. I would like to point all other pages that claim to be the new features for 8.2, to Greg's Release notes. Will that work? [Michael, your work on 8.2.0 New Features was really a list of Base features, so I used that as the text for XO_Base_Features. 8.2.0_New_Features should point to Greg's release notes] Greg - Please tell us when you have a good set of 8.2.0 new features in the release notes. Thanks! Kim On Wed, Jul 9, 2008 at 11:28 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Wed, Jul 9, 2008 at 11:07 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Eben, Thanks for the link, very useful! FYI I have a Releases page at: http://wiki.laptop.org/go/Releases I saw this. I'm wondering how it's meant to be differentiated from eg. http://wiki.laptop.org/go/8.2.0. Perhaps we should merge the latter into the Releases page. Perhaps instead we should make the Releases page an index (akin to Release_Notes) and then use pages eg. Releases/8.2.0 to detail each release from now on. Perhaps we do that and also rename your current Releases page to Release_Status, and make sure we *only* put developer oriented status updates there, and reserve Releases for an index of all releases. Thoughts? - Eben ___ 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: joyride 2128 smoketest
With almost 400,000 deployed in the world, we need to have some good discussions on the backward compatibilty and upgradability of Activities. Some of the bugs Charlie is writing up from the QA first look at joyride may be answered by upgrading an activity to a newer one. So here are the questions we need to discuss: 1 - Is there anyway to ensure backward compatibility of activities (the 8.1.1 activities will work with 8.2)? -- seems like a long shot to me. 2 - For support purposes, do we need or want to say that activities will be backward compatible only across the year designator (8.1 activities will work with 8.2; but from 8.x to 9.x, the activities will need to be updated and probably retested and checked for new translations). 3 - Since I think it is going to be really hard to do either 1 or 2 above, then we have to have a strategy for easy activity upgrades. We've talked about this for a long time... do we have a proposal that we can really implement as part of the 8.2 release? Kim On Wed, Jul 9, 2008 at 11:25 AM, Murphy, Charles [EMAIL PROTECTED] wrote: I've been running a smoketest on the recent joyride-2128 build, and have just posted the results of what i've done so far at http://wiki.laptop.org/go/Test_Group_Release_Notes#Joyride_Builds . Here's a short summary of some of the more glaring issues: - The two XOs tested could not see each other on either simple mesh or on an AP with a schoolserver (both laptops are registered to the schoolserver in question, schoolserver.media.mit.edu). - Browse could not download .xo or .xol files. - Clipboard could not paste into Write. - Record has problems saving and playing back photos and videos. I'm not finished with the smoketest yet, but these issues seem bad enough to merit posting to devel and the wiki right away. I'll continue posting results to the wiki as they come in. Charles Murphy WPI Class of 2010, IMGD-Tech [EMAIL PROTECTED] Cell: (781)710-6950 ___ 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: 8.2.0 Release Notes
I think you should just start a page... Thanks, Kim On Tue, Jul 8, 2008 at 11:06 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Who is writing the release notes for 8.2.0? I am seeing a lot of good info on improvements pass by in e-mail or in Trac exchanges (e.g. http://dev.laptop.org/ticket/7443#comment:3). I want to start capturing them somewhere so users can see what changes/benefits are in the release. Maybe we can talk about this in the release meeting today... Thanks, Greg S ___ 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: How do we manage translation effort in Release process/roadmap?
This is a good point and I hope Michael will be able to address it. If there are any questions about how to get translations into pootle or into a build, please post them so we can get them resolved quickly. In order to help focus which translations are high priority for this release, I have listed the languages we are shipping to today and expect to ship to in the next 4-6 months. They are in size order: Spanish (Peru, Uruguay, Mexico), 200k Mongolia, 20k (10k now, 10k by end of year) French (Rwanda), 10k (5k now, 5k in late fall) Kreyol (Haiti), 13k (6k now, 7k later) Amharic (Ethiopia), 5000 Khmer (Cambodia), 1000 Dari (Afghanistan), 3000 (1k now, 2k later) Thai, 500 Devanagari, 500 Portuguese (Brazil), 200 Arabic, ~500 Receiving laptops in the next 3-6 months: Oceania, 500 Italy, 600 Turkey, 15k Senegal (French), 1000 Argentina, Equitorial Guinea, Panama (Spanish) Not included: Birmingham, South Carolina, NY (because they are English) and deployments that got US/Eng keyboards that weren't big enough to designate the shipping location. -Kim On Wed, Jul 2, 2008 at 12:20 AM, Korakurider [EMAIL PROTECTED] wrote: Hi, all. I have read though Greg's release process draft of OLPC (http://wiki.laptop.org/go/Release_Process_Home) and ReleaseTeam/Roadmap of SugarLabs (http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap). But both draft documents haven't explained translation of software (including activity) and others. Until midst of update.1 development, development of activities and translation had been aligned to the road map of XO software. it was straightforward; we were notified when window for translation of whole project was opened/closed. Now our collaboration has become complex, because of SugarLabs's split. Translators are still working with one unified portal (i.e Pootle), but I can't understand how and when each PO will be pulled to build. Without those knowledge it would be difficult for translation community to manage their schedule. Could you please explain about this? For instance, scheduled build of Terminal activity with pulling newer translation was announced recently. (http://lists.laptop.org/pipermail/localization/2008-June/001138.html) So we could easily manage the effort. But could we expect similar announcement for every activities, or will the window for translation of activity aligned to development road map of sugarlab or OLPC? Maybe I missed important thing, though... Thanks in advance /Korakurider ___ 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: [Deploy] fonts-thai-ttf has been abandoned!
For testing, Scott, we are growing a set of each new keyboard/language laptop that comes out of manufacturing. The 'ultimate' test for fonts, translations, keyboard integration is to load a build on these laptops. I have two of each new SKU and I have tried to label one as 'WP' (write protected for final test), and one is not write-protected to accept earlier builds. I don't want these leaving my office (until they have a more permanent home) since there are only 2 of each (I'm hoping they will mulitply while sitting on the ark). The slightly painful, but do-able test case with any MP laptop requires setting mfg data and re-imaging, and is documented here: http://wiki.laptop.org/go/Tests/Keyboard_mappings Kim On Tue, Jul 1, 2008 at 6:43 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 6:19 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 5:52 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: C. Scott Ananian wrote: We added a package named 'fonts-thai-ttf' to our builds a while ago for thai font support. However, no one here now remembers where this font came from, or where the upstream came from. Can someone familiar with thai support help out? Ideally we'd like to confirm the licensing and then grow a maintainer for this package in fedora. I *think* this was provided by behdad, adding him. Am I wrong to think that thaifonts-scalable should replace it? From http://koji.fedoraproject.org/koji/buildinfo?buildID=34572 it looks like you are right, considering the first changelog entry is from Behdad and explicitly mentions OLPC. But I'd like some confirmation from someone doing work in Thailand, if possible. Is there a test case I can run to find out if Thai support works? While we're at it: why are we including libthai-devel, consisting mostly of a whole bunch of .h files? Is there some need for that I'm missing (and can I test it)? --scott -- ( http://cscott.net/ ) ___ Deployment mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/deployment ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes
My thoughts in-line... Kim On Tue, Jul 1, 2008 at 6:16 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 5:13 PM, Greg Smith [EMAIL PROTECTED] wrote: - Kim will check with Peru and Greg will check with Uruguay teams to ensure that they do not plan to upgrade to 8.2.0. Action item due by July 20. Why don't we want them to use 8.2? Two reasons for Peru to stay with 8.1: 1 - Peru has 'blessed' their build for the next 75k laptops and we got it into production for them. It is 703+peru activities (which you knew, but may not have thought about the reason we ECO'd it into production was so they don't have to upgrade before giving them out to students). 2 - Peru has created and printed their User Manuals based on the UI of 8.1. We should expect and encourage them to continue on this path. We will support 8.1 until we ship 9.1, which should work for them. That's that part that I will confirm when I visit them. Greg has agreed to check in with Uruguay on where they are in their roll out to teachers and students. I suspect some words were left out, and what you really meant was, their schedules for adopting 8.2 are not pressing? If we don't expect our two largest deployments to adopt our release, why are we making it? KQ - We have many, many more deployments, trials, pilots, possibly G1G1, who will be just getting their laptops when 8.2 is ready or soon there after. This release is for them. Even in the case of G1G1, if those laptops go out with 8.1.1, they can MUCH more easily be upgraded to 8.2 than was possible with earlier releases. Something's not right here. Incidentally, on the blocking bug front, I notice that Uruguay's wireless problems with 703/708 were nowhere to be found on the roadmap for 8.2. This is a blocker to our producing something useful for the kids. KQ - Do you have a specific bug in mind? Let's make sure it gets listed when we start listing/triaging blocking bugs (which I agree we can start doing at any time); and make sure it is getting addressed. --scott -- ( http://cscott.net/ ) ___ 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: First Draft Development Process Proposal
On Tue, Jul 1, 2008 at 5:39 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Thanks for all the comments on the Development Process. http://wiki.laptop.org/go/Release_Process_Home A few gentle suggestions on managing the input. A - My intention is that this page (http://wiki.laptop.org/go/Release_Process_Home) will be the final page. So please put comments and discussion in the talk section. Feel free to make signed edits to the page if there is consensus. Any typo fixing or additional links and references are also welcome (e.g. does someone have a link and explanation of the OLPC-3 build which they can add to the builds section?). I want to manage comments on the Talk page and on this list if possible. KQ - feel free to move my comments to the talk page. (If I haven't already gotten to it) B - The best way to change a section is to offer alternative text and get consensus for it. Write exactly what you think the text should say, post it here and/or on the talk page. Once there are enough +1s we can call it final. A couple of people at 1CC need to sign off eventually but if the community agrees that's pretty certain to be the final word. C - The very best way have your input adopted is to write a section. No takers on the open items yet and there are some major areas ... I should have explained my plan for collecting comment before, sorry. I have no complaints about any of the input so far, keep it coming. Here are my responses to a few of the issues raised: 1 - Translations input GS - I agree we need a better definition of that. I added it to the to do list. 2 - Synching with Fedora schedule GS - No opinion right now. Is there consensus? How long do we need after a fedora release comes out before our release is ready? 3 - Core OS vs Core + Activities GS - My intention was that this doc is for Core OS. I added a to do list item for activities and removed on offending comment. We need a definition of what constitutes the Core OS. I prefer a URL with all relevant SW modules, but whatever developers need is OK. Do we have consensus that this doc is for Core OS only? KQ - I think a 'release' consists of everything needed to put it behind us: core OS, signed core OS with all the parts needed for all the upgrade capabilities (fs.zip, .crc, .img, .md5, .usb?,...); images+activities for all customizations (G1G1, Peru, possibly AL); documentation GS - That said, I think we should keep with current naming convention on Releases used in the field which include activities. The fewer times you change the naming convention the better. Also, I think we should document the naming convention down to the OS + Activities level even if we don't have a process for including activities yet. 4 - Support time frame. GS - I agree that release should be supported until the second subsequent release is out (ala Fedora). Do we have consensus on that? KQ +1 5 - Code names and community roadmap. GS - I agree with the code name idea and the community roadmap idea. Just type of the text you want on the page including where you want it to go. Post it to the talk section and/or send it to this list, get consensus and its in as far as I'm concerned. 6 - Types of builds, meaning of freezes, definition of what requires a minor release. GS - I agree that those could all be improved. Just type of the text you want on the page including where you want it to go. Post it to the talk section and/or send it to this list, get consensus. Thanks for the review and suggestions. I didn't see anyone commenting on whether this is useful or not. Are there any open source developers reading this who are on the fence about working with OLPC? Does this help explain how we work and does it help motivate you to chip in? Is it useful for the rest of you already working on the project? FYI I have a pre-planned vacation I need to take starting tomorrow. I will be back online Thursday July 10. I will collect all comments and edits then and make another major revision. Thanks, Greg S ___ 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: Inappropriate use of private meetings lists.
Scott, I think we all agree that communications can improve and constructive ideas on how to do that are always welcome. I'm not sure how you decided that we had consensus on following Mozilla's design principles. I don't remember being part of that discussion. I'm not sure how we define consensus, which brings me to one of the problems that consensus-driven decision making often faces -- how do we know when we've reached consensus? What strikes me as more fundamental or underlying in your comments is the disconnect between how some people think or want OLPC to be managed versus how we are actually managing and making day to day decisions. There are top-down decisions being made by a few people that drive the direction of OLPC. These decisions are not waiting for consensus, and they are made by a small number of people. I don't believe this is going to change (at least not in the short term). At the same time, there are many decisions that are driven by the community that come from the bottom up. This seems to work pretty well to involve the community in many areas of OLPC operations. I believe this 'business model' is intentional and that OLPC is not trying to be an organization run by consensus. The interesting discussions come from the areas where the top down meets the bottom up. We have a lot of decisions and discussions that need to happen in this middle ground. I would argue that this is where we are making our efficiency over consensus trade offs. Sometimes efficiency wins, and sometimes consensus wins. You (and many others) are helping to identify once we've made an efficiency trade off if there are better ways to communicate and how to make the information public. This is very helpful. There is an analogy here with pushing code upstream. It is often a good idea, but there are many reasons why every patch does NOT go upstream (you've argued quite a few yourself). Let's keep having the discussions, but recognize that these two decision making models exist at OLPC. Those who are employed by OLPC and need to carry out OLPC goals (sometimes in conflict with community goals) are asked to help make decisions in this middle ground. Kim On Tue, Jul 1, 2008 at 2:54 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: When Mozilla went public, the first item on their list of design principles was: External development counts more than convenience or ease-of-habit for internal-to-Netscape developers. The Netscape X-heads, for example, have moved all of their mail usage except for I'm-out-sick-today and any truly-proprietary messages to the mozilla.unix newsgroup. Likewise with NGLayout hackers and the mozilla.layout group. So it shall be for all development. http://www.mozilla.org/roadmap/roadmap-26-Oct-1998.html I thought we achieved broad consensus a few weeks ago that this principle should be adopted by OLPC, and it was indeed heartening to see more engagement on the devel@ lists and a shift away from private ad-hoc mailing lists. We created a list of 'truly-proprietary' messages, and occasionally even successfully moved conversations to devel@ when the topic strayed away from the proprietary and confidential on that list. I also thought I was successful in convincing management of the pressing need for a community liason, to help ensure that our openness was persistent, and to take personal responsibility for prodding people to use appropriate public fora. I was away in Europe for almost two weeks, and while I've been gone I'm sad to say it seems OLPC has been backsliding. On the truly proprietary list I have received messages about OFW2 status, even though it was made public at a press-invited event back in May, on our public mailing lists by our CEO himself (http://lists.laptop.org/pipermail/sugar/2008-May/005752.html), and on sites such as OLPCNews. I've also received many many other messages that don't pass any sort of confidentiality bar. Part of the problem, of course, is (as I raised earlier), without a community liason with authority, no one can definitely say what is safe to disclose and what is not, so people are erring on the side of caution and forgetting their prime directive of transparency. Further, many meetings and discussions that used to happen on public IRC channels, so as to better include our many non-local contractors and employees, not to mention interested members of the community, have reverted to face-to-face meetings. Expediency is the rationale given -- which of course is exactly the rationale rejected by the principle as stated above. Often transcription or call-in access is offered as a poor substitute to equal access for the community and external developers. Perhaps transparency is not actually a goal of OLPC. But if it is, OLPC has stopped making progress towards this goal. I am wondering if it is appropriate that I unsubscribe from the truly proprietary group and refuse to take part in face-to-face
Re: OLPC-Update + RPMs WAS:Re: OLPC XO Opera browser as Sugar activity
We separated out the activities so that we could push the testing and localization of activities out to the country. How many activities can they test? As many as they have people and time for. It is in the deployment guide (and starting to get good discussion from sales/deployment people) that a country must take responsibility for choosing, testing, and localizing activities and content. We will make the combined OS+Activities image for them, but our testing is limited to ensuring that the signed image loads and we'll do the equivalent of 10 minutes of testing (this is not exact, but meant to give you the idea that we won't spend days or even hours testing each customized image -- ideally this testing is automated so we can do 30 different country images in a day or in parallel). The country has to have done the testing to enusre proper operation of the activities and the correct language, etc.. OLPC's testing needs to be limited or there is no scalability. In the same way, we have set a precedent with Uruguay, that if they country wants to make changes to the code base that they need to send a developer to 1CC to learn how to work with our processes, our developers, our repositories, etc. and to make sure their features and bug fixes get in releases. And they have to do their own testing. If they do all that, then we will sign their builds, do the same '10 minute' test and be able to support them when they have to make more changes in the future. We won't fix their code, but we will encourage them to contribute as we do other developers. Note: for the G1G1 program OLPC has to choose the activities, ensure that the testing gets done (hopefully with community help), and take some responsibility for the activities that we ship. Kim On Mon, Jun 30, 2008 at 8:23 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Mon, Jun 30, 2008 at 07:10:23PM -0400, C. Scott Ananian wrote: On Mon, Jun 30, 2008 at 6:58 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jun 30, 2008 at 6:50 PM, [EMAIL PROTECTED] wrote: how many different deployment builds do you think are being supported at this time? I think it's still in the single digits. I expect this to change quite drastically soon. Let's not get ahead of ourselves. Someday we may be able to support lots of different configurations. Today, we will only be successful if we can limit the number of configurations in the field to a testable number (and then test them!). In your opinion what is a 'testable number'? That's the whole point of the core OS / activities split. Do whatever you like on the activities side, because that's your primary value-add (you == countries). We can also technically ensure that one bad activity won't spoil the whole bunch. We will in turn provide you with a core OS which is as stable and functional as we know how. There is another primary value-add, which is a different operating system or window manager. To enable this value-add we could be distributing a minimal image for each of the popular linuxes and then distributing packages to install sugar, activites, other window managers, etc. Such packaging would be most useful to deployments engaged in customization. We already know that countries want to be able to run more traditional desktop environments. Erik ___ 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: Ticket cloning
Thanks Noah! Kim On Fri, Jun 27, 2008 at 3:41 PM, Noah Kantrowitz [EMAIL PROTECTED] wrote: I have enabled ticket cloning support on dev.laptop.org. Just use the new Clone button on the ticket form. Enjoy. --Noah ___ 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: Manufacturing tags
John, Beyond SN and U#, I have found that I need these tags for correct keyboard/localization: KV LO KL KA only affects the keyboard in OFW (and default if missing is good) P# was important in older hardware. And if you change any of these tags, you need to re-image the software to actually use the new keyboard/language settings. Kim On Tue, Jun 17, 2008 at 5:00 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: From what I understand the keyboard related tags are directly related to the locale, so the information which is currently in the K* tags _might_ be retrieved from the locale tag (we would probably need to maintain a table in olpc-utils for this). Thanks, Sayamindu On Wed, Jun 18, 2008 at 1:56 AM, John Watlington [EMAIL PROTECTED] wrote: As replacing the SPI flash becomes a more regular occurence, reinstalling the manufacturing tags is becoming a problem. What tags are absolutely essential for our software to operate ? These are: SN (serial number) U# (uuid) What about these ?: LO (C locale) KL (keyboard layout) LA (country code) KA (Keyboard ASCII map) KV (keyboard variant) WM (wireless module MAC) SG (motherboard rev) B# (motherboard number) As every essential tag must be typed in, with a reboot between each, I would like to minimize the number of tags I restore. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ 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: [RFC] Unscheduled Software Release for SD Card Corruption Workaround
Deepak, I think you should feel free to release information and kernel rpms to the devel list, pretty much whenever you want since you (or others) can answer questions and help people who want to try this out. I would consider this as 'developer testing' -- which is great and shouldn't get bogged down in too much process. The benefit of going through a 'release process', in general, is to get the feature or bug fix out to the general public, documented (and supportable), after a more formal QA process. After you are happy with the developer testing, if there is a big enough demand in the general public we can go through the unscheduled release process to get a formal build, testing, and release (8.1.1). If the demand isn't too large and the timing is such that we are pretty close to 8.2.0 release, then we should target it for that release. Kim On Wed, Jun 25, 2008 at 9:14 AM, Deepak Saxena [EMAIL PROTECTED] wrote: On Jun 25 2008, at 00:04, Kim Quirk was caught saying: Thanks Deepak. I'd love to see the SD card corruption fixed, but we are just about finished with testing and are now in the release process for 8.1.1... so i recommend that we schedule this fix for the 8.1.2 release (if we do this release) and make sure it gets into 8.2.0, which might be the next release we get out the door. Ah, I didn't fully grok our release schedule and thought 8.1.1 was already out the door. Other thoughts? Eric and I talked about this a bit yesterday and we thought that doing a full USR is probably not needed. What we're looking at doing to help the G1G1 users who are impacted by this is to spin a kernel RPM and initrd that they can install. ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [RFC] Unscheduled Software Release for SD Card Corruption Workaround
Thanks Deepak. I'd love to see the SD card corruption fixed, but we are just about finished with testing and are now in the release process for 8.1.1... so i recommend that we schedule this fix for the 8.1.2 release (if we do this release) and make sure it gets into 8.2.0, which might be the next release we get out the door. Other thoughts? Kim On Mon, Jun 23, 2008 at 7:13 PM, Deepak Saxena [EMAIL PROTECTED] wrote: [Resend to proper sw-eco address] Hi, I've spent some time debugging trac #6532: SD corruption on suspend resume and propose that we provide some sort of update with a proposed workaround as this is an issue that has been seen by multiple G1G1 users. Doing a full USR may be overkill for this issue as we may just be able to provide a new kernel and intird RPM, but I'm not sure that we have an official way of providing individual package updates. Please see http://wiki.laptop.org/go/OLPC_SW_ECO_-_SD_CARD_CORRUPTION for the official proposal. Thanks, ~Deepak -- Deepak Saxena [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
Re: Making updating easier and Planning for Support
Deepak (and others interested in support), This is a good question and we've talked about it from time to time. The OLPC Support planning is really just now underway. We've made some good progress on the Hardware side of support (spare parts, repair centers, warranty, etc); and now we need some focus on the Software side of Support. Here is my proposal: First I'd like to begin separating 'Sustaining Engineering' functions from 'Development Engineering'. Sustaining is focused on the problems and bug fixes needed for countries (and G1G1). There has to be a close tie in between the groups and training from development to sustaining, but it should allow the Development team to be more forward looking. Secondly, I am proposing that our Support team can only support one major release along with the current one. With school systems being run on yearly basis, this would suggest that we plan for 2 major releases per year. That would give schools a chance to use either the fall or spring release as their base; and then plan to upgrade between school years to the next release. Here is an example: We provide release 8.2.0 in Aug/Sept; school systems that start in Feb or March would be encouraged to use this release, add their content and activities, test, and get the release out to the XOs before the start of the school year. We might need to provide 8.2.1 or 8.2.2 as they do their testing as major issues are found. We would plan 9.1.0 for the March time frame, which gives school systems that start in Aug/Sept a chance to test this release through the summer; and help us find bugs that might require 9.1.1. Then we would continue to provide patches and support for 8.2 until the follow Aug/Sept, when 9.2.0 is getting ready for release; and we would provide patches and support for 9.1 until the following March, when 10.1.0 is getting ready for release. We had been talking about as many as 3 or 4 major releases per year... so this is a good point of discussion and something I'd like to finalize in the next few weeks. Perhaps the minor/patch releases can allow small features so developers don't feel like they have only two times/year to get in a new feature. We have to think about what that means for testing and support. We also have to keep in mind that our audience is schools, teachers and students, not developers. If we start with a set of goals for the Support of our SW, then we can have a good discussion on this. Here are the three goals I have so far: 1 - Ensure that security issues and major bugs are addressed in a timely fashion 2 - Ensure that there are resources available to review, recreate, and help fix and test serious and critical problems from the field. 3 - Manage the process of development, test, and release for minor/patch releases. The resources we need for 'support' are almost the same as for working on the next major release: sustaining eng, development, build, release and test resources. So we really have to limit what we can support to one release back -- which has an impact on how many major releases we should do each year. Kim On Sat, Jun 21, 2008 at 7:37 PM, Deepak Saxena [EMAIL PROTECTED] wrote: On Jun 21 2008, at 20:10, Kim Quirk was caught saying: Sounds great! We've discussed a similar thing here, but I don't believe there has been any time for that. For g1g1 people there could possibly be 2 options - 1. Upgrade from 656 to 8.1.1, with the automatic second step of adding activities; or 2. Cleanstall to the 8.1.1 build that already includes activities (a signed candidate for this is available today). I've been thikning about update issues a bit and was wondering if we have plans/processes in place to handle maintaince of multiple releases? Meaning that when we release 8.2, will we still provide bug fixes and security updates to 8.1.1 users or are we expecting everyone to move forward to 8.2 and just EOL 8.1.x? Thanks! ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Adding a Next release milestone in trac
New milestone created. Kim On Sun, Jun 22, 2008 at 2:27 PM, Michael Stone [EMAIL PROTECTED] wrote: On Sun, Jun 22, 2008 at 03:38:25AM +0200, Marco Pesenti Gritti wrote: On Sun, Jun 22, 2008 at 3:34 AM, Eben Eliason [EMAIL PROTECTED] wrote: Make sense. Wonder why Michael has been using the rel- prefix? I attached the 'rel-' prefix because I think it very likely that we're going to invent other tags involving release numbers. I agree, I think we should just get rid of update.x. This has been the plan since the last nomenclature switch. Michael ___ 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: [Techteam] Adding a Next release milestone in trac
Sorry Eben... I didn't mean to reject your suggestion; I guess I don't quite understand it. We rename the major releases to 8.2 and 9.1, and what do we do with the features and bug fixes for 8.1.1? Kim On Sun, Jun 22, 2008 at 3:59 PM, Eben Eliason [EMAIL PROTECTED] wrote: Does this mean that my suggestion to generalize to 8.2.x and 9.1.x etc. was rejected? I still feel that this could be more useful, because it would map the milestones to the EOL policy for releases. That is, anything in the 8.2.x milestone will be dropped when we hit 9.2.0, etc. And, as mentioned before, this would allow the least significant version number to be managed with the tagging scheme; otherwise we'll have to deal with the messiness of adding point release milestones on the fly... Can we rename the current 8.2.0 to 8.2 (or 8.2.x) and 9.1.0 to 9.1 (or 9.1.x) instead? - Eben On Sun, Jun 22, 2008 at 3:51 PM, Kim Quirk [EMAIL PROTECTED] wrote: New milestone created. Kim On Sun, Jun 22, 2008 at 2:27 PM, Michael Stone [EMAIL PROTECTED] wrote: On Sun, Jun 22, 2008 at 03:38:25AM +0200, Marco Pesenti Gritti wrote: On Sun, Jun 22, 2008 at 3:34 AM, Eben Eliason [EMAIL PROTECTED] wrote: Make sense. Wonder why Michael has been using the rel- prefix? I attached the 'rel-' prefix because I think it very likely that we're going to invent other tags involving release numbers. I agree, I think we should just get rid of update.x. This has been the plan since the last nomenclature switch. Michael ___ 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier
Sounds great! We've discussed a similar thing here, but I don't believe there has been any time for that. For g1g1 people there could possibly be 2 options - 1. Upgrade from 656 to 8.1.1, with the automatic second step of adding activities; or 2. Cleanstall to the 8.1.1 build that already includes activities (a signed candidate for this is available today). If we can keep the upgrade or cleaninstall very simple, that would be great! Thanks for any help any can bring to this! Kim On 6/21/08, Christoph Derndorfer [EMAIL PROTECTED] wrote: Hello all, one of the things that repeatedly came up during a greet meetup at Friends Community School near DC which we had earlier today was that updating the software on the XOs was still too painful for many people. So especially with G1G1 2008 looming on the horizon I'm thinking that it might make sense to come up with an easier way to update the software. Some of the potential solutions discussed are * adding a separate activity that basically acts as a simplified gui for olpc-update, allowing users to upgrade to the latest signed software-builds (with an option to include release candidates) * integrating update functionality into the sugar-control-panel * adding a gui for Bert Freudenberg's script What do you guys think? Cheers, Christoph -- Christoph Derndorfer Co-Editor OLPCnews, http://www.olpcnews.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Sent from Gmail for mobile | mobile.google.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Adding a Next release milestone in trac
Michael, If we can all agree on tagging and on using exactly the same tags (which is very difficult); then we still have to deal with the milestone issue as the entire roadmap and all the past expectations have been that the milestone DO mean something. It is difficult to give up on milestones (at least for me) and I'm really concerned if tags are not a 'pull down' that we will NOT successfully search on tags and get all the trac items. Can we use a combination of milestones and tagging? If you want something to get into milestone 9.1.0; you put it there AND you tag it with rel-8.2.0:- rel-9.1.0:? Maybe the milestone represents the desired location of the feature, and the tags represent current expectations as to whether it can make one release or another. So if someone puts 'Groups' into Milestone 9.1.0; you might also tag it with rel-9.1.0:? because it is undefined and therefore not clear that can make that milestone without a lot more attention. As it gets broken down into smaller parts, some of those features might get rel-9.1.0:+ and some get -. We might put 'Grab key scrolling' into 8.2.0 as the desired milestone; with rel-8.2.0:? rel-8.2.1:+ (not sure it can make 8.2.0, but really think it can make 8.2.1). I think all the trac items still open once we hit a milestone should get automatically pushed into the next milestone. Kim On Fri, Jun 20, 2008 at 9:01 PM, Michael Stone [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 09:35:33PM +0200, Marco Pesenti Gritti wrote: On Fri, Jun 20, 2008 at 9:06 PM, Eben Eliason [EMAIL PROTECTED] wrote: I began wishing that I could meaningfully differentiate between the Future release and non-existent Next release components. Because we are unlikely to make a new major stable release within four months of shipping 8.2.0, our next major stable release will, in all probability, be named 9.1.0 -- the first major stable release of 2009. Looking out from today, I would expect it to land sometime in the first quarter of 2009. I could also easily imagine the creation of an 8.2.1 bugfix release to pick up minor improvements to 8.2.0 which are required after ship or which we lacked the resources to release on the first pass. As for how to represent these possibilities: I don't like the Milestone field because it fails to two important qualities of tickets: that they may have been considered for multiple releases and that they must be proposed, then accepted or rejected for release. Unfortunately, the Milestone field does not permit us to describe tickets which are in danger of slipping from a release, which are _proposed_ for a release but not yet accepted, or which have slipped through several releases. In reaction to these flaws, I am using a tagging scheme like: rel-8.2.0:- rel-9.1.0:? to describe tickets which are definitely not going into 8.2.0 and which have been proposed for 9.1.0. Does this scheme suit your needs? Michael ___ 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: thread summary: On Cerebro, Telepathy, yokes and whites
Greg, I am adding the 'testing' mailing list. We can use this 'real life' information for generating Use Cases and test cases but we will probably need to simplify it. There are too many things going on in this particular case. We have some use cases for school scenarios in some of these links: http://wiki.laptop.org/go/Tests/Connectivity_and_Collaboration - use cases in classroom http://wiki.laptop.org/go/Networking_scenarios - major types of scenarios http://wiki.laptop.org/go/Collaboration_Network_Testbed - 100 laptop testbed As well as generating use cases, this 'real life' scenario tells us that we have not conveyed what SHOULD work properly to people on the ground - as what they are trying to do is not even possible in today's builds. We've known that communications is a problem, but it emphasizes that we need to figure out some solutions... and telling this particular teacher, for instance, that what they are trying to do won't work, is not the right answer. Also, from a support perspective, it is really important when we get feedback or help requests directly from teachers in country that we try to get them in touch with their local support people - or we try to include the local tech support people. As Wad as identified in the past, if we try to help people where we really don't understand the local constraints or the RF layout we are more likely to make things worse than to actually provide help. With large country deployments, the first level of help needs to come from in house support. Thanks for bringing this up, Greg. It emphasizes a lot of things we need to address. Kim On Fri, Jun 13, 2008 at 8:49 AM, Greg Smith (gregmsmi) [EMAIL PROTECTED] wrote: Hi Poly et al, Thanks for the summary and documentation. After the last round on this subject http://lists.laptop.org/pipermail/devel/2008-May/thread.html#13898 I exchanged some e-mails with a teacher in Uruguay to get a better sense of exactly how they want to use the XO in class to collaborate. See: http://lists.laptop.org/pipermail/olpc-sur/2008-May/000118.html Here is the use case I got out of that exchange: - The class has 10 - 25 kids in the second grade each with an XO. There are 100 - 200 Xos in the school. Each class can join a different channel and time share (TDM :-)to keep the number of Xos per channel to a minimum. - One class (10 - 25) connects its Xos to the mesh (they do it by clicking the round mesh icon but they will do whatever works) - There is a wireless access point in the school and they see several other wireless Aps so there is some RF background. - One kid opens write (also want to use paint) sets it to share and starts writing. - In the neighborhood view the other students see the write icon and join the activity by clicking on it. - All the children start to write text and add pictures at more or less the same time - Each kid wants to save the file in their own journal at any time (this is where it crashed when they tried it with write) - After saving to the journal they want to see the shared document again. Its OK to require them to leave the share to open their own local copy as long as it doesn't crash if they do it out of order (what is supposed to happen if you are sharing a document then open a new one too?) Is that a well defined use case that you can turn in to an end to end test case? If not, what additional information or details do you need? My impression is that the teachers don't really care about the technology as long as they can do what is described above. I don't know exactly what software they have on their school servers (e.g. not sure about jabber). If we can tell them what software, configuration and steps they need to take in order to run a class as described that would be a very good start. I understand there is a write bug which is probably responsible for their issue. You can substitute paint or another activity if it helps isolate the collaboration aspects from the activity aspects. This can be something we test for a future release if its not something that is possible now. So please include build #s and time frames in any response. I wont say anything to the teacher about what is possible until I see a very solid reproduction of their environment and use case. I'll keep digging up real use cases and sharing them so let me know what kind of info you need to turn them in to test cases. No reference to Cerebro, telepathy etc, but I hope that helps. Comments and questions welcome. Thanks, Greg S ** Message: 3 Date: Wed, 11 Jun 2008 14:22:10 -0400 From: Polychronis Ypodimatopoulos [EMAIL PROTECTED] Subject: thread summary: On Cerebro, Telepathy, yokes and whites To: OLPC Development devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed This is a summary (a la Michael) of the cerebro/telepathy thread. Pol brought up the issue
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
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: Need advice to upgrade
We have been having similar problems in the office (tons of RF, if that matters), where one laptop can successfully connect to a WPA client and another one can't; or the same laptop might not be able to on a second or third attempt. If it worked once, it is likely that you can get it to work again... but clearly this is a bug. I started a new trac item, 7257. I am also experimenting with removing the config file: /home/olpc/.sugar/default/nm/network.config and rebooting. This has worked for me occasionally in the past. I'm still not sure if it is related to removing the config file, rebooting, or just timing... Others, please put your notes into this trac item. Thanks, Kim On Wed, Jun 11, 2008 at 8:36 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 11.06.2008, at 14:05, Jim Gettys wrote: My memory is that you may have one of the two known access point types with which we have problems, due to the chip/firmware used in that access point (note the pre-N designation). Michailis will know for sure, and it's probably recorded in our Trac system. Due to the very small population of those routers, (if my memory is indeed correct) we're unlikely to explicitly try to fix it. Oh. I had the impression that the WPA problems are well known and so I did not bother to report anymore. Are you implying it *should* work? - Bert - ___ 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: thread summary: On Cerebro, Telepathy, yokes and whites
Nice summary Pol! Kim On Wed, Jun 11, 2008 at 2:22 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: This is a summary (a la Michael) of the cerebro/telepathy thread. Pol brought up the issue of how the collaboration stack is currently implemented, that there should be a dead-simple networking API for activity development and proposed someone taking the lead in implementing a connection manager for cerebro (which currently offers a D-Bus API). http://lists.laptop.org/pipermail/devel/2008-June/015238.html Ben suggested that there is no need to abstract telepathy further because it's an abstraction layer in itself. Instead, API changes should be proposed, if any exist. http://lists.laptop.org/pipermail/devel/2008-June/015239.html Ricardo suggested that there should be someone working on a cerebro connection manager in parallel with jabber. http://lists.laptop.org/pipermail/devel/2008-June/015248.html Marco and Tomeu agreed that there should be a cerebro connection manager, Marco conceded to getting cerebro in joyride, but disagreed with adding an abstraction layer between telepathy and sugar/activities on the basis that telepathy is abstraction layer in itself and we must live with what is currently available for lack of resources and because compromises are often made in large software projects. http://lists.laptop.org/pipermail/devel/2008-June/015226.html http://lists.laptop.org/pipermail/devel/2008-June/015254.html Scott brought up the issue of children invariably trying to develop a multi-player game on sugar and failing because of the complexity of the collaboration API. Marco agreed with this problem and recognized the need for a python layer above telepathy/cerebro that can be invoked without DBus, while a lower level DBus-based API will be used by non-python activities. Both Marco and Scott saw the need for extensive tutorials and examples on how to use any networking API for activity development. http://lists.laptop.org/pipermail/devel/2008-June/015255.html Kim would like to figure out how to make progress on cerebro. http://lists.laptop.org/pipermail/devel/2008-June/015261.html Robert characterized telepathy primarily as an API to a variety of functionality and different communication mechanisms, recognized some problems in the implementation and the need for cerebro as one of the plans to deal with those problems. He also went through the history of how D-Tubes and stream tubes came about and noted that the requirements were not really clear when their (D-Tubes and stream tubes) implementation started. He also recognized the need to hide some of the complexities of network programming by adding a simplifying layer on top of telepathy, or by extending the current telepathy API. http://lists.laptop.org/pipermail/devel/2008-June/015262.html http://lists.laptop.org/pipermail/devel/2008-June/015258.html Finally, Morgan went through the history of how the Presence Service was implemented, that it predates the use of telepathy and that it contains some interesting, to put it politely, design aspects. He also went through his efforts to simplify the implementation of collaboration in activities by pushing the telepathy functionality from the activities into the PS where possible and his plans to simplify further collaboration in activities. http://lists.laptop.org/pipermail/devel/2008-June/015274.html Tomeu also suggested getting this summary together (thanks!) and that it may make sense to separate discussion on the API from discussion on the current implementation. I hope I captured the most important parts of this threads, feel free to blame me if I failed in any parts. Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ http://www.mit.edu/%7Eypod/ ___ 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: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
We are discussing this and the best use of resources to get to 8.2.0 and beyond. There will be many more discussions. I would like to figure out how to make progress on cerebro. Kim On Tue, Jun 10, 2008 at 9:34 PM, Robert McQueen [EMAIL PROTECTED] wrote: Ricardo Carrano wrote: We need Jabber to be working too. For the infra scenario in the schools to work. But if we consider Cerebro an important part of our future (at least I do) we should dedicate more attention to it. I don't know about the arrangements between OLPC and Collabora. It seems to be implied that if Collabora works in the Jabber front it won't be able to work in Cerebro. Is that the case? Really? Not really, no, we'd be happy to work on using Cerebro to implement the Telepathy APIs. We do however have a limited amount of resources to dedicate to on our work for OLPC, and they are spent as directed by the management at 1CC, as represented to us by Michael Stone. Currently the main priority for us is implementation of the XMPP server component (Gadget) to handle activity/buddy discovery and hence allow greater numbers of users on one XMPP server, and allow us to consider other XMPP daemons besides ejabberd. It's my opinion that we should also dedicate some of our resources to working on Telepathy - Cerebro integration too, so that we can make some comparisons and see how well the existing activities and UIs behave on a hopefully more mesh-friendly backend. We're currently discussing with Michael and the folks at 1CC how/when we can make this happen. Regards, Rob ___ 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: New XO-LiveCD Release 080607
This worked pretty well for me. I booted the LiveCD off my Macbook Pro and it started up the 703build of sugar (the previous LiveCD). Nice and fast! The only problem was the aspect ratio of my screen doesn't meet that of Sugar so some things are cut off the bottom making it difficult or impossible in some activities to work. Record couldn't use the camera or microphone, but measure could use the mic. Pippy could use the sound well, but you can't read the 'run' and 'stop' buttons. They are just buttons with no words. I think this is a great way for teachers or others who don't have an XO to work with Sugar and the activities to help design or enhance their curriculum. Thanks!! Kim On Mon, Jun 9, 2008 at 3:10 AM, [EMAIL PROTECTED] wrote: A new release 080607 of the Livebackup XO-LiveCD is available at: http://dev.laptop.org/pub/livebackupcd/build-708+joyride-2024 and mirrored in Germany at ftp://rohrmoser-engineering.de/pub/XO-LiveCD/ Main features and changes since version 080321: * Dual boot option for update.1 and joyride builds, You can try out the new SUGAR design by booting a recent OLPC joyride version. * Improved CD customization. Additional activities and RPM packages can be installed by putting them into CD top-level directories. * A new script to prepare USB boot devices out of the Live-ISO image. * Tested on a wide range of PC and laptop hardware and proved to work with all common virtual machines on Windows, MacOS and Linux. * Additional Xorg graphic drivers and improved X11 auto-configuration tools. * Bug fixes, updates and new activities. * Linux kernel 2.6.24.7, using the aufs-filesystem. This Live-CD project targets the main goals: * Give children, students, teachers and parents the opportunity to participate and use the educational software on a common PC. * Demonstration of OLPC/Sugar software to non-developers, you can also start the sugar desktop on Windows, Linux or MacOS using a Virtual Machine. * For developers the CD provides an easy maintainable Live-System, which could be used to develop and test activities on the sugar desktop. Further information is available in the PDF document: ftp://rohrmoser-engineering.de/pub/XO-LiveCD/XO-LiveCD_080607.pdf For discussion we invite you to join the mailing list: http://lists.laptop.org/listinfo/livebackup-xo-cd Regards Wolfgang Rohrmoser ___ 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: New, more realistic multi-hop network testbed
Some thoughts from a QA perspective: I consider the 100 laptops that I budgeted, ordered and help install in Peabody to be the QA collaboration testbed, which is expected to be used to recreate problems from the field and test out next release solutions. Since we had to dismantle Peabody, most of these laptops (about 70 of them) have been loaned to Poly in 1CC. Now that we have both a QA Lead and an intern, I expect we will need to refocus 20-30 laptops back to the QA testbed full time and we have signed a lease on the new test facility, which will be ready for the full 100 laptop test bed (or perhaps 200 laptops) by mid-July. Secondly, we also need to be working on the longer term solutions, such as those being investigated by Poly, Nortel, Michail, and Ricardo. If this also requires a 100 laptop test bed then we need to build one. We need to order these laptops and start making permanent homes for them. If the first step is to order 10 laptops, I will order them. Poly - What I can't tell from your progress reports is exactly what is needed for us to get to the next level. On the surface it sounds like you had to rebuild chat to make it work with cerebro. If so, does that mean all activities would have to be modified to a new API? What else is needed? How does the cerebro solution fit into the rest of the stack and the other technologies we are working on for 8.2.0 (August) and future releases? If the cerebro solution is still in research and there are a lot of issues that still need to be worked out before we can release it, then we need someone to help track all the issues and help resolve them through the stack in order to get something to release stage. Let's work with Michail on this as he probably needs to take the lead. As a first step, I will order 10 laptops for Poly to find permanent homes for throughout the MIT campus. Kim On Sat, Jun 7, 2008 at 12:02 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Honestly, I'm getting very burned out over the politicking here. Ricardo, Polychronis, and the Nortel guys seem to be the ones doing the real heavy lifting here on the mesh network. When they ask for something, I think we should give it to them. Ricardo and Polychronis agree that a sparse network testbed may be useful -- in addition to, not instead of, a dense collaboration testbed -- why can't we just say, yes, do that then. Wad is right, we still need a collaboration testbed, but as Poly points out this is currently Collabora's area of responsibility. --scott -- ( http://cscott.net/ ) ___ 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: [OLPC Security] G1G1: Security, to enable or disable...
The two issues that I am concerned about regarding the write protect flag with regards to G1G1: 1 - I thought requiring signed images was part of our bitfrost security. Doesn't it provide some protection from malicious images? Assuming we get to the point where upgrading is an easy click from the G1G1 machine, then we want to be sure that people don't mistakenly load non-signed images. If you are not a developer; doesn't this add a level of protection that we want for 90% of G1G1 recipients? 2 - I believe our support issues will go up significantly as people who have little or no experience are encouraged to download all sorts of untested builds with no easy way to get back to a working system. To feel better about the support issues, I would like the one-button push that restores a laptop to factory default. Actually walking people through a cleaninstall is a very time-consuming process right now. Finally, I agree with Scott, that the easiest thing we can do in the short term is to make the 'get a developer key' more prominent for those who want to find it. I would really like a brief note about how they should first be familiar with how to do a factory cleaninstall before they unprotect their machine. Kim On Wed, Jun 4, 2008 at 9:50 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 9:20 PM, reynt0 [EMAIL PROTECTED] wrote: I also want to be able to examine the XO as thoroughly as possible from my own (USA, educated, experienced, and so on) perspective. In that regard, FWIW I found the various infos I later could find from olpc a bit unclear or even seeming at first glance inconsistent about how usable a G1G1 XO could be as-delivered. My present understanding is that I will need a developer's key, and that I can get one by asking when I'm ready to (though I'm not sure if I would be able to if I were a non-compsci G1G1), tho I am willing to accept that this understanding may be wrong. http://wiki.laptop.org/go/Developer_key I would like to see the link for requesting a developer key made much more prominent in the library. (I've cc'ed SJ specifically to see if he can make that happen for me.) --scott -- ( http://cscott.net/ ) ___ 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: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
Agreed, Ed. The legalities of each country need to be determined and met before we can include that country in a Give One Get One program. Some of the things we need to understand are: Certifications, language/keyboard requirements, messaging, non-profit status, shipping, customs, support and warranties. I believe these issues (and perhaps more) will be different for almost every country. Kim On Sat, May 31, 2008 at 11:18 AM, Edward Cherlin [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 7:09 AM, Kim Quirk [EMAIL PROTECTED] wrote: Adam and Support gang, A second G1G1 program will still be only US/International keyboards (http://wiki.laptop.org/go/OLPC_Keyboard_layouts#US_International_keyboard). There are too many logistics, production, forecasting, and shipping issues associated with more than a couple of SKUs (different laptop configurations) for a G1G1 program. I don't know whether that is acceptable to Europe. They want Cyrillic (Bulgarian and Serbian layouts are completely different from each other and from Russian, Ukrainian, and Belarusian, which are all quite similar), Greek, and Eastern European (Czech, Slovak, Polish...are nearly identical), at least. I can look up the standard layouts in more detail if that will help. You need to specify exactly which countries will be included in your version of Europe. Lithuania, Latvia, and Estonia are EU members. So are Malta and Cyprus. Turkey is a candidate. Croatia, Bosnia/Herzegovina, Serbia, Macedonia, Montenegro, and Albania are not members. You had better get the lawyers to check out EU regulations on computer sales. I suppose that you can get away with printing only US International on the keyboard as long as you say so, very clearly, in the announcements and ads, and explain how to access the other layouts in a document shipped with the laptops. But, from a languages perspective, It would be great to point translators for European languages (or any languages) to various ways in which they can help translate our wiki pages and add to the product translations through Pootle. IFYP Here are some links: Localization of XO files: http://wiki.laptop.org/go/Localization Translating wiki pages: http://wiki.laptop.org/go/Translating Pootle page, including table of localizers: http://wiki.laptop.org/go/Pootle Pootle: http://dev.laptop.org/translate Localization mailing list at http://lists.laptop.org/ Thanks, Kim On Thu, May 29, 2008 at 3:14 PM, Adam Holt [EMAIL PROTECTED] wrote: Dear Kim, Can we get some preliminary discussion going in the next couple weeks, towards helping people set up fuller support structure for those European languages? Talk to me about any language support issues that management isn't handling. Or if nothing else, an idea as to how many EU countries are liable to be supported for 2008's G1G1? Whether it's 2 countries or 12 countries makes all the world of difference Uh, actually there are 27 countries in the EU, and 8 candidates. Non-members include Switzerland, Norway, and the new countries formed from former Yugoslavia (except Slovenia). ;) --A! %-[ -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
John, We experienced quite a large number of 'software broken' laptops when we first starting shipping both in Uruguay and in the G1G1 program. I thought one of the things Ivan did in Uruguay was to help them reflash their laptops when they couldn't boot due to journal corruption or other software related reasons. Not sure if this is the same problem. How many do you think are recoverable with software reflash? Have they been recovering these, or have these fallen into one of their other piles of 'broken' laptops? Thanks, Kim On Tue, Jun 3, 2008 at 6:47 PM, John Watlington [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 11:53 AM, C. Scott Ananian wrote: On Tue, Jun 3, 2008 at 11:28 AM, ffm [EMAIL PROTECTED] wrote: C. Scott Ananian-3 wrote: http://wiki.laptop.org/go/Olpc-update#USB_upgrade This will not work if the OS is not bootable and no alt-os image is on the disk. We should continue to try very hard not to let the OS become unbootable. If it is unbootable, something Very Wrong should have occurred and there's no guarantee that mount the filesystem and copy off /home will work either. Using a dev key and a rescue disk is probably a much better bet than any attempt at automagic. Please file bugs on ways you've managed to make the OS unbootable, or ways the alt-os image breaks (there are a few); these are likely to get more attention than trying to resuscitate a deprecated tool I wrote for firmware security debugging. I agree completely with Scott. An interesting data point, however, is that over half of the machines sent for repair in Uruguay are fixed simply by reflashing the machine. This may be an artifact of the old build they are using, but it is a disturbing statistic. In recent months, I've only had to reflash to fix problems which happened right after a previous reflash (#6906). That said, there's a separate bug in trac about X not starting when the NAND flash is full. I'm not sure if that's what you're referring to as not booting or not, but we should fix that, too. --scott -- ( http://cscott.net/ ) ___ 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
Developer program laptops are shipped out as US/International keyboards, English language, AK flag set, which means they do NOT need activation. They are permanently activated in the manufacturing data. The only thing they need to be a developer unit is a developer key. One more reason to add to Scott's list of why laptops are sent out to G1G1 'write protected' is so they are protected from non-signed images coming from malicious sources. If you don't use a developer's key to un protect the laptop, then you can only upgrade to OLPC signed builds. This is an important part of the bitfrost security that is implemented and working! FFM - if you really got two laptops from the developer's program that weren't activated, then could you put those details into an RT ticket and we'll debug it there. If there really are laptops going out that are un-activated that we don't know about, that will be a serious problem. The ONLY un-activated laptops are ones built for Peru, Mexico, and Uruguay. These are very specific SKUs and that include Spanish keyboards. Please open a ticket and let's figure that out. Thanks, Kim On Tue, Jun 3, 2008 at 1:07 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 03.06.2008, at 18:33, ffm wrote: On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Machines sent out via our developer program are always shipped out unsecured. Yet I've just recived two laptops via said program that had security enabled. Indeed. The machines distributed at LinuxTag last week also came w/o dev key - I think it is only the activation part that is disabled. My information may be out of date on the developer's program, since Adam has rebooted it recently and I don't think that developer's program machines actually come through OLPC any more. I should have said, used to be shipped out unsecured. Adam, are the new developer's program machines shipped direct, or do we have an opportunity to (at least) include a flyer explaining how to disable security on the machine? --scott -- ( http://cscott.net/ ) ___ 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: Software Status Meeting Tomorrow @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode
Including the testing ml as well. Items that are scheduled for testing (and might have issues for the 2pm edt meeting): 1 - Build 706, candidate 8.1.1, with fixes as described by Michael (I still see almost all the same problems with kreyol as were written up in #6973; and there are still some issues with Amharic. It is being tested in a network environment, what other testing is needed?) 2 - Build 703-2, peru image with activities (available from Scott today; needs discussion on how to name and store these 'country specific' images) 3 - Build 703-2, g1g1 image with activities (not available yet, but the support and mfg group are anxious to get it) 4 - Joyride and/or what we decide to use as the base for 8.2.0, August release. (Michael, I will be in another meeting at the same time, but I will try to get together with you later on these). Kim On Wed, May 28, 2008 at 12:18 AM, Michael Stone [EMAIL PROTECTED] wrote: Let's talk tomorrow about #7014, build 706 (which everyone ought to test; olpc-update -f update.1-706), and what we should take away from the fact that Blake and Ricardo were the only people who contributed patches/packages for inclusion in our bugfix release. Please reply to this mail with any other subjects that you would like us to discuss. I'll see if we can fit them in. Michael ___ 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: Release process
Scott, I agree with the need for at least the four branches that you have described below. I would think the Support team would be most familiar with the Stable branch; the QA/Test team would do most of their work (especially system level testing) from the Testing branch; and the Development people would be most active on the Unstable and Experimental branches. One of the jobs of the release manager should be to help identify things that are ready to move from a development branch into the testing branch by making sure the process steps along the way are completed, etc. A good set of 'readiness criteria' that people agree on ahead of time really helps when we get to each of the major decision points or freeze points in the schedule. Then there doesn't have to be too much arguing about whether a bug fix or feature makes the cut. We should recognize that for our projects there may be some bug fixes that we decide _must_ make the next release. That is usually what causes us to delay the release (as we did with Update.1 when we decided the fixes for Peru were more important than getting the release out on time). We should discuss this ahead of time so it isn't a surprise or a big disappointment to the community. We should agree on what (if anything) could delay the release; and how the status of those blocking items are monitored and communicated to everyone on a regular basis. Kim On Fri, May 23, 2008 at 2:07 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On 5/23/08, Simon Schampijer [EMAIL PROTECTED] wrote: I'm all for not landing broken code into joyride (which makes joyride the 'testing' branch of the debian triumvirate), ? Has this something to do with #7012: olpc-update ubuntu? No, it's just shorthand for a conversation we've had around here often: Debian has three or four 'branches' active at any given moment: * stable: (currently 'etch') -- the current stable branch; security fixes only. * testing: will become the next stable branch; only working code. * unstable: for development. things are expected to work, but might not. * experimental: for big pieces such as gnome which require coordination, but are expected to be broken often. EXPERIMENTAL follows the 'commit early and often' policy to allow people to closely track upstream git/svn/cvs and adapt their code to upstream API changes. UNSTABLE is where most packages land first. Packages in unstable are expected to work, but often break things, because integration is hard. Still, many (most?) debian developers run unstable on their main machines, acknowledging a willingness to encounter and report bugs as a trade for getting new features first. They also are helping debian by being the 'continuous integration' guinea pigs. TESTING. packages are moved from unstable to testing automatically in N days (14?) if there have been no blocking bugs filed against them in that time period. Thus, without explicit management, testing is far more likely to 'just work'. Developers who are a little less adventurous run 'testing', and testing gets a lot of focused attention and becomes very important in the run-up to the next stable release, because STABLE. at the point of a new debian release, the old 'testing' branch becomes the new 'stable' branch. No other RCs are made: the testing branch *is* always the best RC for stable possible at a given time. Release management mostly involves combing the bug database for regressions and minor bugs found in testing which were discovered after the 14-day grace period from unstable and which haven't already been fixed, documenting known 'wont-fix' and 'relnote' issues, and testing upgrades and installation. (Because of continuous integration, most people upgrade in steps through v1, v2, v3 of a package, and sometimes there are problems discovered when folks using the last stable release try to upgrade directly from v1 to v3. These issues are tested and caught during the release process, which seeks to ensure that stable-stable upgrades always work smoothly.) - Originally, joyride was seem as the OLPC equivalent of the 'unstable' branch (not always expected to work), and I proposed a 'killjoy' branch for 'testing' (always expected to be our best build at a given time). Michael's recent proposal of stronger release management seems to envision joyride becoming more of a 'testing' equivalent -- which does match how we seem to be portraying the joyride builds to our developers. This leaves a need for a place equivalent to 'unstable' which is less controlled: an easy place for developers to distribute their latest stuff which is expected to work but might not. I've also been pushing for new features to land first on 'experimental' equivalent branches: Dennis' FC9 is a good example here. It's known not to work yet, but we need to be able to distribute the work-in-progress in order to more efficiently help push it to completion, and to
Re: [Server-devel] Problems with mesh OLPC Sur list / problemas con la malla
Since I can't read Martin's answers in Spanish, I thought I would answer a few in English. If these two sets of answers don't agree, can someone point it out so we can get them right. See inline below. Kim 2008/5/15 Yama Ploskonka [EMAIL PROTECTED]: Hi y'all, I am double posting for I do not know whose fish this is. A teacher in Uruguay indicates issues with operating with mesh, two others confirmed they had a similar experience of random connectivity. Please help, either subscribe to OLPC-Sur to answer in Spanish or respond through either list or personally and I will translate back. Yama Translation of the original message: The problem I was mentioning is that we know the mesh in itself to work, what we have not been able to do is to achieve a collaborative activity such as you are supposed to be able to. Chat works perfectly, I connect, I see who is in the neighborhood, I invite that person and we chat; but it is very difficult with other activities. The connection is very unstable and in a group with 15-20 children there is always a couple XO that will not connect or they don't see the rest even if they are connected. We have solved this by working by pairs, but if it is supposed that the plan is one computer per child, what is proper is that each one have one, isn't it? As a sidenote, I am writing from the XO, two blocks from my house there is a school that has un punto de acceso, I am lucky I can connect!!! In the neighborhood you can see 3 points of the mesh (I do not know if that is what you call them, doesn't matter) 1, 6, 11. Generally connection works on 1. After this is established, it lasts less than half an hour and it breaks, or some XO disconnect. I want to make clear that even though the connection is random, I can choose on what mesh to connect by clicking on that point, it takes a few minutes but you can do it. Questions: Do you know how far this can be done? == Laptops should be able to connect to each other at 100meters or possibly more, if there are no RF 'barriers' (such as thick walls, metal or screen meshes). Are the numbers related to that radius? == I think you mean the number of laptops. The more laptops that are within the radius of the wifi, the higher the traffic and the less reliable the connections will be. We have made a number of changes in code and expect to make many more between now and the August release. Also, we are recommending infrastructure access points for classrooms with more than 20 laptops. Why do those XOs that are in one mesh see each other but not those in another? == The simple mesh channels 1, 6, and 11 are separate RF channels. There is no bridging in simple mesh mode. In a school server environment, the school server will bridge the three channels. It would be good that all the people who are connected see each other and the different points act as bridges to gather those who are farther away. In the classroom not all can connect to the same mesh so it is impossible to achieve a shared project. == If you don't have a school server, then you should have all the children click on the same mesh channel (1, 6, or 11). Another matter is that, suppose we can connect several people, chat or talk works impeccably but when we try to share activities that are like more complex such as Paint or Write (don't even mention eToys) all gets much more difficult. == Yes, most of these are bugs that we are still fixing. Some fixes were introduced in the 703 build; more bugs are being addressed in the upcoming August release. We recognize that the reliability of mesh and collaboration is high priority. greeTings original message follows El problema al que hacÃa referencia es que conocemos el funcionamiento de la malla en sÃ, lo que no hemos podido lograr es realizar una actividad colaborativa tal como se supone que deberÃa ser. El chat funciona perfectamente. me conecto, veo quién está en el vecindario, lo invito y charlamos; pero es muy difÃcil con las otras actividades. La conexión es muy inesatable y en un grupo de 15 o 20 niños siempre hay un par de xo que no se conectan o no ven a las demás aunque estén conectadas. Lo hemos solucionado trabajando en duplas, pero si se supone que el plan es una compu por niño, lo correcto serÃa que cada uno tenga la suya no? Comento que estoy escribiendo desde la olpc, a 2 cuadras de mi casa hay una escuela que tiene un access point, por suerte me puedo conectar!!! En el vecindario se ven 3 puntos de malla (no sé si asà se llaman, no importa) la 1, la 6 y la 11. Por lo general la conexión se logra en la 1. Luego de establecida la misma, dura menos de media hora y se corta, o se desconectan algunas xo. Quiero aclarar que si bien la conexión es aleatoria, puedo elegir en qué malla conectarme haciendo clic en el punto, toma unos minutos pero se logra. Preguntasss: Saben en qué radio de distancia funciona? Los números se relacionan con
Re: [Testing] [sugar] Release management for upcoming bug fix releases and August release
The prioritized list has been discussed in a number of venues, and has general acceptance. Chuck is having regular management mtgs (weekly) so I intend to put this priority list in front of this group every week to make sure that this list is well communicated and if someone needs to bring up a new priority or make a change in the order, we will get some notice. The second step, triaging bugs, is going to require help from everyone familiar with their area of the code base. It is important that people who have a stake in getting a bug fixed take some initiative here to represent their most critical bugs and send your thoughts on priorities to Michael and Jim. I don't believe this is a one person job. Here are some suggestions: * Ricardo and Wad have been prioritizing the wireless and mesh issues. * Marco has led the sugar team bug priorities in the past (do you want to do that again?). * Chris would probably be best one for gathering the power mgmt related issues. * Martin should represent server issues. * Each developer or tester should think about what they feel are high priority issues (upgrade issues, touchpad issues, backup) and send your requests to Michael and Jim to make sure they get evaluated. Bug triage is very time consuming, so I would ask that everyone chip in and Jim and Michael be responsible for understanding/prioritizing the trac items for the August release. Use cases are being developed as we go along. For instance, we have some use cases for the network/mesh scenarios. We should put for requirements or use cases whenever a feature or bug fix is more complicated than something one person can implement in an afternoon (like the control panel), or if there is disagreement about what it is supposed to look like to the end user. [Michael, I know you have a wiki page started for the August release. Can you put links to priorities, use cases, requirements, and trac filters associated with this release? Ideally we could have test cases and results linked there as well.] Other thoughts? Kim On Sat, May 17, 2008 at 7:01 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, On Tue, May 13, 2008 at 1:41 AM, Kim Quirk [EMAIL PROTECTED] wrote: A high level view of this process: 1) Prioritize feature and bug fix requests from deployments, developers, support, our sales/marketing group 2) Triage bugs to determine which bugs are critical to fix to meet the priorities 3) Translate these requests into requirements, use cases, and trac items (bug fixes or task items). Any news on this? Thanks, Tomeu ___ Testing mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sw-eco] Keyboard Support for Haiti Ethiopia - OLPC 8.1.1 bugfix release
I'm just getting some feedback from Quanta on problems with Mongolian laptops as they are producing a couple thousand this week and will be shipping them out. I will try to recreate these issues and we can see if they fit the same areas of change and if there is another fix that could be a candidate for bug fix release. Looking ahead, the next new keyboard/country that will be manufactured is Dari (Afghanistan), starting in 2 weeks from now. Perhaps I can get to testing that one as well with 703 and see what issues they will have BEFORE they have them. After Dari, there are only English and Spanish laptops for 5-6 weeks. For people who want to help with this testing, the basic idea is that you need to set your laptop to the desired country and then follow the test cases found here: http://wiki.laptop.org/go/Tests/Keyboard_mappings Kim On Thu, May 15, 2008 at 5:23 PM, Michael Stone [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 07:54:46PM -0400, Michael Stone wrote: --- officially --- According to tickets #6973 and #6945, 703 loads the wrong keyboard map for Haiti and inappropriately invokes GTK-IM for Ethiopia. It is proposed that we make a small bug-fix release to allow Haiti and Mongolia to make effective use of their laptops with a 703-like build. The USR process checklist for this release is here: http://wiki.laptop.org/go/OLPC_SW-ECO_5_Checklist and the Wiki documentation is at http://wiki.laptop.org/go/OLPC_SW-ECO_5 At present, we believe that #6973 and #6945 can be fixed without security-sensitive changes. I've filed #7014 to follow the life-cycle of the first candidate build containing Sayamindu's changes (plus a few other odds and ends). I'll need your help in the next couple of days to close that ticket by reviewing all the code changes made against the 703 package-set, finding or writing appropriate tests for the bugs listed, and executing those tests (as well as the smoke test). Also, I remain interested in pulling in other changes that close existing bugs. Please suggest some plausible changes. (I'll suggest a few myself in my next email). Thanks Michael ___ 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: Keyboard layout issues
This looks great, Sayamindu! Thanks for getting to this so quickly. Michael, Once the next step is figured out -- packaging, do we start a 704 build (based on 703) with just these fixes? Or do I test them out in a joyride first? Please tell me when there is a build I can test these fixes on. Regards, Kim On Wed, May 14, 2008 at 5:03 PM, Michael Stone [EMAIL PROTECTED] wrote: Sayamindu, Thanks for the awesome writeup. Do you feel comfortable enough with Fedora packaging to take responsibility for providing 703-compatible packages containing these changes? Thanks, Michael Status fragment: #6973 PKG ??? (Production problem: Haiti keyboard doesn't match keyboard mappings) #6945 PKG ??? (MFG Problem: Ethiopian keyboards don't provide English characters) #5996 ESC sayamindu (Mongolian, Devanagari keyboard/language testing) ___ 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: Devel Digest, Vol 27, Issue 59
Greg, The work that Pol is doing on mesh is all in development now... nothing that has been released in a signed build. So I would NOT recommend that many people try to upgrade to this. Plus I believe the work he is doing requires api changes, so other activities probably won't work collaboratively at all (Pol, you can confirm this). We should be careful to only recommend development builds to people technical enough to understand how to downgrade if they get into trouble and fully understand that they will probably lose all their data, etc. (like developers). Probably there are very few teachers who have enough technical understanding to be able to support a classroom of different builds. Other thoughts on this? Kim On Fri, May 9, 2008 at 9:01 AM, Greg Smith (gregmsmi) [EMAIL PROTECTED] wrote: Hi Polychronis, Thanks for sharing the results. Did you use a wireless AP or active antenna? If you can include a few details on that it will help. Can you also include the XO build # and XS build and config if relevant? Would you say that this test passed? That is, can we recommend that schools use the chat activity with one chat session which all join? Lastly, can you tell us what kind of testing time and focus you will have in the near future? I believe there is a mesh test lab coming up at Nortel in Ottawa as well. Any feedback on test capacity and plans there is appreciated too. I ask because there is recent feedback on mesh issues from a teacher at Lambayeque, Peru http://wiki.laptop.org/go/Lambayeque#Inconvenientes and a teacher in Uruguay has asked about supported Mesh features too. The Lambayeque page says: they wish they knew in advance that Acoustic Measure Activity would not work with 6 groups of two students each. That's mostly an issue with activity design and our communication about what activities support but it does raise a good test case (6 groups of 2 sharing a single activity). I think both (Peru and Uruguay) teachers can help define meaningful mesh use cases which will be applicable in many schools. I want to set the right expectation on our capacity before I ask them to spend a lot of time working with us. I can start by telling them that chat as you describe above will work well, if you agree. Then we can follow up to gather more details on how they want to use the mesh. The good news is they are motivated to use the mesh which helps validate one design goal of the XO. Now we just need to understand how they want to use it :-) It looks like you are focused on finding the maximum scale of Xos which can be in a mesh. That's clearly important info too. I'm just checking if you have capacity to look at a few other test scenarios as well. Thanks, Greg S Message: 5 Date: Fri, 09 May 2008 03:29:51 -0400 From: Polychronis Ypodimatopoulos [EMAIL PROTECTED] Subject: 65-node simple mesh test (and counting... ;-) To: OLPC Development devel@lists.laptop.org, Sugar ml [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dear devel, Here are the latest results from Cerebro's (http://cerebro.mit.edu) scaling properties. A 65-node testbed was used (703, Q2D14). The NetworkManager had to be disabled in order to stabilize the behavior of each XO's wireless interface. Unfortunately, the difficulty and time necessary to manage increasingly more nodes is linear (given that the NetoworkManager is disabled ;-), but increases steeply. ** Test plan: Cerebro was started on all 65 laptops almost at the same time. We attempted to emulate the 65 children turn on their laptops in class at the same time scenario. With Yani's help, it took about 5 seconds for both of us to press 'enter' on all laptops. Each XO would discover each other, exchange profile information and keep exchanging presence/discovery information. ** Measurements: Quantitative: According to the protocol, presence (mac address) arrives about other XOs first, then the profile for the newly arrived mac address is queried and finally the profile is cached. We assume that initially each XO has no cached information about other XOs. As a result, every XO will query everyone else. We measured the time it took for each XO to discover and exchange profile information with everyone else, bandwidth usage at all times (during profile exchange and after the network stabilized when all profiles were received everywhere) Qualitative: Collaboration was tested on all 65 nodes: one shared a chat session, everyone else joined. The chat session was based on Cerebro's collaboration model. ** Results: Discovery and profile information: The following graph shows arrival of profile information at each XO from other XOs a function of time. Each bar is a 3-second bucket representing the average number of profile arrivals during this 3-second period. The standard
Release management for upcoming bug fix releases and August release
Development and Testing community, We have started planning for the next SW releases. The goal is a bug fix release in a few weeks (8.1.1), and then the major August release (8.2.0). [NOTE: the release numbers are based on my last reading of the numbering convention... not sure if it is final.] A high level view of this process: 1) Prioritize feature and bug fix requests from deployments, developers, support, our sales/marketing group 2) Triage bugs to determine which bugs are critical to fix to meet the priorities 3) Translate these requests into requirements, use cases, and trac items (bug fixes or task items). After that planning, a weekly meeting can be held to manage the high priority items (Wed 2pm EDT). Michael Stone volunteered to be the release manager for the 8.1.0 (Update.1) release and is willing to continue through to the August release. He will provide much needed communications, planning, help in unblocking technical problems, and general project management. We are hiring people so I expect we will have some help for Michael soon. Don't hesitate to reply with thoughts or ideas on this process. Regards, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: OLPC News (05-10-2008) - Tech Team
down to allow for autmoation. - Wrote down how Olpcfs interacts with external storage devices. - Clarified some confusion on network principles; worked out some special cases with wad to add to the documentation. - There's a number of initramfs-related things to do: * customization key should support .i18n, .kbd, activation/developer keys * build quanta .img from customization key (hopefully using same codebase); we need to document a checksum procedure for them as well * modprobe usb-storage to allow modular USB. * bundle olpcrd w/ kernel (build system integration) * partition support Scott is hoping to tackle all of these in a batch while the code is in my head; if you've got additional desiderata, tell him while he's knee-deep in it. *Power:* Richard Smith: - Assembled a working multi-battery charger with enough parts for 9 functional channels. This includes modifications to the battery retention snap that solves the too hard to remove battery problem. Starting next week it will be placed out in the 1CC garden for people to use. Richard would like as many people as possible to use it to charge their batteries so he can begin to gather performance data. - The next issue is to decide what to do for fixing the retention snap on the upcoming test build of 50. Make the parts and then hand modify them or re-open the tooling. A new tool will mean a 4 week delay. *School Server:* John Watlington: - Released a new build of XS School Server software (build 163) this week which fixes some problems with an earlier bug-fix release (build 161). - Build 163 is recommended for all new installations. *Testing:* Gainnis Galanis: - has developed several Network testing scripts to collect and display information about the network configuration, telepathies and their status, the neighbor XOs and the forwarding tables. For details see http://wiki.laptop.org/go/Network_Resources. With the help of Michael Stone these scripts will be in the next joyride. Some of the data was taken from http://wiki.laptop.org/go/Test_Network_Configuration, which he also updated. - Yanni and Kim have also been working with the NYC team to try to meet their short term needs. Yanni created a script for associating to a cloaked AP. The script is available at http://wiki.laptop.org/go/Network_Resources. Polychronis Ypodimatopoulos: - reports the latest results from his Cerebro's (http://cerebro.mit.edu) scaling properties. A 65-node testbed was used with build 703, Q2D14. The NetworkManager had to be disabled in order to stabilize the behavior of each XO's wireless interface. - Results look very promising and can be found here: http://wiki.laptop.org/go/Simple_mesh_test_%28Cerebro%29. He was able to share a chat session with 65 laptops. *Support:* Adam Holt: - continues to work donor services questions as well as helping out those who are building up repair shops and repair skills such as Cortland Setlow (NYC) and Mel Chua (Cambridge/Boston area). - interviewed and hired two temporary support specialists to take on the final weeks of G1G1 calls and emails as we start to close down this program. Sara Lesko and Michael Taylor are now in Adam's office, which is the temporary location for the 'call center'. - re-initiated a project to build an asterix based call center with an automated response system. Emily Smith: - worked on about 75 new tickets this week, closing out 95% of the 90 that were open from previous weeks. - continues working the replacement, reshipment and refund requests. Kim Quirk: - worked with various deployment teams to address their longer term feature requests - provided activation server management to allow deployments to get their own developer and activation keys - continues to work on issues with the Spare parts program with Brightstar; as well as in discussions with volunteers to help create more business-like model for repairs. - answering pre-sales requests for technical information, network configuration, as well as bug fix requests from Peru - Urdu keyboard change requests, and on-going discussions to get a new Turkey keyboard into production. - Production issues from Quanta required testing and debug for Haiti and Ethiopia laptops. Thanks to Arjun Sarwal and Bernie Innocenti for their help. *Sysadmin:* Henry Hardy and Dennis Gilmore have installed the 9 new disks in the Coraid 1521 disk system and built a RAID5 array on the new disks. The parity disk is still being created. The new filesystem is mounted on grinch as /mnt/filer2. Henry and Richard Smith are continuing recovery efforts on the OLPC server in China. The file system was apparently damaged in a power outage severely enough that it is questionable if it is bootable in its current degraded state. We have ordered and will be building a replica of the server at 1cc in order to construct a bootable image we can physically mail to China so the server can be safely rebooted. ___ Devel mailing list
Re: 65-node simple mesh test (and counting... ;-)
This looks great, Poly. Can you please put this test plan and results into a wiki page, preferably linked somewhere off the main 'Testing' page. Thanks! Kim On Fri, May 9, 2008 at 3:29 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Dear devel, Here are the latest results from Cerebro's (http://cerebro.mit.edu) scaling properties. A 65-node testbed was used (703, Q2D14). The NetworkManager had to be disabled in order to stabilize the behavior of each XO's wireless interface. Unfortunately, the difficulty and time necessary to manage increasingly more nodes is linear (given that the NetoworkManager is disabled ;-), but increases steeply. ** Test plan: Cerebro was started on all 65 laptops almost at the same time. We attempted to emulate the 65 children turn on their laptops in class at the same time scenario. With Yani's help, it took about 5 seconds for both of us to press 'enter' on all laptops. Each XO would discover each other, exchange profile information and keep exchanging presence/discovery information. ** Measurements: Quantitative: According to the protocol, presence (mac address) arrives about other XOs first, then the profile for the newly arrived mac address is queried and finally the profile is cached. We assume that initially each XO has no cached information about other XOs. As a result, every XO will query everyone else. We measured the time it took for each XO to discover and exchange profile information with everyone else, bandwidth usage at all times (during profile exchange and after the network stabilized when all profiles were received everywhere) Qualitative: Collaboration was tested on all 65 nodes: one shared a chat session, everyone else joined. The chat session was based on Cerebro's collaboration model. ** Results: Discovery and profile information: The following graph shows arrival of profile information at each XO from other XOs a function of time. Each bar is a 3-second bucket representing the average number of profile arrivals during this 3-second period. The standard deviation is shown with the blue lines. http://wiki.laptop.org/images/a/af/65-arr-1.png The following graph is the cumulative distribution function. It shows that, on average, each XO has received about 95% of the profiles of the rest of the nodes within just 20 seconds. This performance boost is due to the fact that each XO queried for its profile, responds by broadcasting the profile, instead of unicasting it to the requester. As a result, the other nodes receive the profile too and the next node is queried, yielding a linear cost, instead of a quadratic one. http://wiki.laptop.org/images/7/72/65-cdf-1.png Bandwidth usage: The following wireshark snapshot shows bandwidth usage that peaks momentarily at about 60kbytes/sec. The snapshot is also in accordance with the first graph above, showing that after about 55 seconds the network stabilizes. After the network stabilizes, bandwidth usage drops to 1 packet every 3 seconds (less than 500bytes/sec), as the arrival rate adapts to the density of the network. http://wiki.laptop.org/images/5/51/Bandwidth-presence-info-1.png Chat session: Before the experiment was started, a node shared a chat session and all 64 nodes joined consistently. I sent a few chat messages from a couple of XOs and were received on all other XOs. ** Other notes After about 6.4 hours of continuous operation on all 65 nodes, Cerebro shows stable memory usage (10MB) and consistent CPU usage (83 minutes of CPU usage in 'top'). Comments/suggestions? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ http://www.mit.edu/%7Eypod/ ___ 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: An OLPC Development Model
*shipping* refers to what leaves the factory in China. We do not *ship* anything without activities installed. If you already have a build and you upgrade, you shouldn't lose your activities (that would be a bug if you did). If you do a 'cleaninstall' based on the old methods of cleaninstall, then you are liable to end up without activities... but you can add them back; so it shouldn't be the end of the world. If you do want to do a cleaninstall, you should use the new method that will add the activities back with a second boot. Kim On Wed, May 7, 2008 at 2:21 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Wed, May 7, 2008 at 8:10 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Wed, May 7, 2008 at 2:00 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Well, I think we should provide a set of default activities. And I think those should include the educational ones. Shipping default images with no activities on them doesn't send the right message either, imo. Dammit, why are we having the discussion again! We do not *ship* any image or machine with no activities installed. End of story. People download 703 and install it on their XO or run it in the emulator. And it's completely useless until they grab Bert script to download the activities (or get them in some other way). I had to guide someone through that process just yesterday and I can tell it was really confusing him. But feel free to disregard the problem, if it makes you feel better. Marco ___ 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: keyboard
Thanks for your input, Alp! I've copied the Devel group since there are interested people in this group who have been working on the Turkish keyboard. Regards, Kim On Wed, May 7, 2008 at 2:13 PM, Alp Simsek [EMAIL PROTECTED] wrote: Hello Kim, Sorry for the late response. I was on a flight and just arrived in Turkey. The attached Q keyboard is the correct ver sion (not the one on the link). However I spotted one error: there should be a V between C and B and the on the attached Q-keyboard, that is, the line that starts with a Z should read: Z,X,C,V,B,N,M,Ö,Ç,: and the shift character The \ character before the shift character should be moved up and should be part of the character that is currently *? (I have in front of me a Turkish keyboard at the moment). Thanks, Alp On Wed, May 7, 2008 at 6:01 AM, Kim Quirk [EMAIL PROTECTED] wrote: Hi Alp, I was given your name and email from Walter de Brouwer, the head of OLPC Europe. We are trying to get a keyboard layout for the XO laptop for children in Turkey. Would you be able to help determine the right layout -- or be able to put me in contact with someone who can help with this layout? We have two layouts already. One is a file attached to this email. And the other can be seen here: http://wiki.laptop.org/go/OLPC_Turkish_Keyboard We need to finalize on the layout as quickly as possible in order to start production. Thanks for any help you can provide, Kim Quirk Dir of Technology, OLPC On Tue, May 6, 2008 at 7:24 PM, walter de brouwer [EMAIL PROTECTED] wrote: Turkey has already signed for 100,000 units but I am waiting for the money in the account. They normally want to start in September, so that is a bummer. But nothing we cannot handle. The contract stipulates that we have 90 days from money in the account. Nicholas thinks we can do 20,000, the rest later, month per month. I remember Bernie telling me that he knew how to do the keyboards and it would take a couple of weeks. Was he not doing that for Turkey? I was under the impression that he was working on that and that bender helped him doing so. The turkey grassroots group is MIT-based, they are the Turkish alumni, there is a postdoc called alp who is a great guy and can help you. It was nicholas idea to use them for deployment. His email is [EMAIL PROTECTED] On Wed, May 7, 2008 at 12:06 AM, Kim Quirk [EMAIL PROTECTED] wrote: Ok... is there are few more people we can put on the review board? Please understand that it will be quite a few months to create a new keyboard, as Walter Bender was in charge of this process and we have to come up with a way around that. The other keyboard had not been built yet and not through final approval, so it is not a big loss to put that one aside. I'm curious as to where it came from because someone had given Walter all the info he needed to design that one. We should figure out if there was a reason for that. Any idea on how close Turkey is to signing a deal? Some idea on when they want laptops? I think the normal amount of time is 3-4 months from when they sign before we can start shipping in quantity. Thanks, Kim On Tue, May 6, 2008 at 4:13 PM, walter de brouwer [EMAIL PROTECTED] wrote: Ali tells me the keyboard is totally wrong; all computers use 99% Q keyboard in Turkey -- Walter De Brouwer CEO One Laptop Per Child Europe (www.laptop.org) Chairman RSA Europe (www.rsa.org.uk) Director Tau Zero Foundation (www.tauzero.aero) http://www.cfel.jbs.cam.ac.uk/about/residence/residence_debrouwer.html -- Walter De Brouwer CEO One Laptop Per Child Europe (www.laptop.org) Chairman RSA Europe (www.rsa.org.uk) Director Tau Zero Foundation (www.tauzero.aero) http://www.cfel.jbs.cam.ac.uk/about/residence/residence_debrouwer.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Open-door Fridays in Wellington, NZ (and a SHDH)
Sounds great, Martin! 'super happy dev house' -- is that a new zealand specialty? Kim On Sun, May 4, 2008 at 12:58 AM, Martin Langhoff [EMAIL PROTECTED] wrote: We just had a Super Happy Dev House thing here in Wellington, organized by the superlative Shiny Brenda. I'll post a link to pics soon. There is a big and growing OSS community here, and several people keen on hacking and testing the XO and the XS. So starting on Friday 16th I will be running an open door Friday where I will be hacking as usual, and invite people to work on aspects of the XS/XO with me. We have to find out how to make it productive, but that is part of it. If it works I'll do it every Friday, and try to expand it to Sat mornings or something like that. Very happy with how today's gone. I've cured an ailing B4. and Shaun's been testing some activities on a Qemu image, and on an MP. cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Open-door Fridays in Wellington, NZ (and a SHDH)
Sounds great, Martin! 'super happy dev house' -- is that a new zealand specialty? Kim On Sun, May 4, 2008 at 12:58 AM, Martin Langhoff [EMAIL PROTECTED] wrote: We just had a Super Happy Dev House thing here in Wellington, organized by the superlative Shiny Brenda. I'll post a link to pics soon. There is a big and growing OSS community here, and several people keen on hacking and testing the XO and the XS. So starting on Friday 16th I will be running an open door Friday where I will be hacking as usual, and invite people to work on aspects of the XS/XO with me. We have to find out how to make it productive, but that is part of it. If it works I'll do it every Friday, and try to expand it to Sat mornings or something like that. Very happy with how today's gone. I've cured an ailing B4. and Shaun's been testing some activities on a Qemu image, and on an MP. cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Signed build for Italy
Hi Bernie, Yes SKU 23 will come from Quanta with the 'ak' flag set (no activation lease needed). To 'roll' your own builds, you will need developer keys. I can make you the technical contact on the activation server to get the developer keys, or you can designate someone else. You can get the list of laptop serial numbers electronically from Brightstar when production is finished (check with Nicole Dallow). Use that at the activation server to get your own dev keys. I think you understand the fact that OLPC won't be able to support custom builds, so I would recommend that you try to build some local expertise as quickly as possible. If there are bugs that seem critical to Italy, you will have to have people to fix them locally and recreate the custom builds, etc. It would be great if appropriate patches can be pushed back up to OLPC. Kim On Tue, Apr 29, 2008 at 6:38 PM, Bernie Innocenti [EMAIL PROTECTED] wrote: C. Scott Ananian wrote: Italy is not interested in anti-theft of course. Could they have the laptops of SKU 23 already unlocked from the factory? Technically yes, but I am worried about Italy isolating themselves from future updates from OLPC. The deployment team will have to make a decision there. How large is the Italy deployment (or is this a pilot)? It's a real deployment, but not nationwide. The numbers I hear keep changing everyday, but the initial agreement was for 5K laptops in Florence + 5K laptops in a twin city. There are additional laptops for Brescia, Rome, and a mini-G1G1 that the ministry major for ICT wanted to promote. The deployment team will be mostly Torello and Francesco; Giulia and myself will help marginally -- or substantially, if we find the time. I'm not concerned about Italy remaining isolated, because of course the next OLPC release will catch up with Italian translation, and will therefore end this mini-fork. How can we make sure SKU 23 comes with this little mfg-data change from Quanta? -- \___/ _| o | Bernie Innocenti - http://www.codewiz.org/ \|_X_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Synchronizing xs-0.3 and xo-??? --- backups
I'm not seeing the use case that I *think* is the primary one: 1) Backup and restore from a disaster recovery perspective. and the secondary that goes with that is: 2) Ability to restore to a new laptop (as in the child lost the laptop or it died and they need to restore their work to a new laptop) You don't need any browsing capability for this. Kim 2008/4/22 Tomeu Vizoso [EMAIL PROTECTED]: 2008/4/22 Eben Eliason [EMAIL PROTECTED]: 2008/4/22 Tomeu Vizoso [EMAIL PROTECTED]: 2008/4/22 Martin Langhoff [EMAIL PROTECTED]: On Tue, Apr 22, 2008 at 10:18 PM, Ivan Krstić [EMAIL PROTECTED] wrote: My solution is the simplest design I could create that allows both emergency restore (laptop FS has been trashed, get everything back) and individual file restore and sharing via a web interface running on the XS, Indeed, reading bug 4200 the purpose of the protocol becomes clearer. What I don't understand completely is the drive behind retrieving the files via a web interface. I'd think that the main requirement is that the Journal can talk to it in a simple enough fashion -- perhaps it was a shortcut to avoid complex work on the Journal? Yes, having the journal activity browsing its own backup as well as the public sections of the other children could be quite a bit of work. A web app that allowed clicking on a link and having that entry installed in the journal seemed much better in the short-medium term. Well, let's not confuse these two use cases. I think they are quite different. Use case (a) offers a child a way to individually recover entries that they themselves created, but which have since been deleted from their Journal. Use case (b) offers a child a way to browse a repository of work that other children have created, with the ability to download, share, and modify those works. I think (a) deserves to be tied closely to the Journal UI, which serves as a history of what a given child has done, and is likely the place one already will be when discovering one wants something that has been deleted. Case (b) is much more appropriate as a web app, and for that matter likely requires additional UI capabilities for determining what is allowed to be presented in this mannerwe don't want every backed up entry to be publicly shared with the world. Yes, the two use cases are very different and, given enough resources, should be implemented separately. As we have so many important things left to do, it has been suggested that a child could mark one of the entries in its backup as public, so other people can access it. In this way, the backup section of a kid in the server would have the following functionalities: - browse backed up entries, - download one entry, - mark one entry as public, - mark it as accessible by other user of the school server. Does it look like a bad compromise between functionality and cost? Thanks, Tomeu ___ 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: [Olpc-open] Making Plans
OLPC's focus is on development, funding and delivery of laptops to the least developed countries. The expectations for features, testing, support, logistics, delivery, IT and RF infrastructure (to name a few things) are widely different between schools in Rwanda and those in NYC (for example). We just don't have the man-power today to meet these expectations world-wide. There are a number of partnerships that we are investigating that can help us by taking on some of these efforts themselves, but it will take time. Finding a 'sales' team is not the immediate problem to selling in the US. Kim On Mon, Apr 21, 2008 at 7:08 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Hi, Edward Cherlin wrote: On Fri, Apr 11, 2008 at 10:17 AM, Michael Stone [EMAIL PROTECTED] wrote: ... Chris, Scott, and I are formulating a release strategy for the next 8 or so months with detailed information about what we hope to release in 4 months. It remains to be seen how the strategy proposed by the Tech Team will be received by the sales team, the deployment team, and by other interested parties; however, I am fairly confident that, when presented, it will: ... In its final form, it will also explain what feedback we have received from sales deployment. In its draft form, it will propose a reasonable deadline for revisions based on new feedback from those teams. ... Michael Who are the sales team, apart from Nicholas? Is there a way for any of us to talk to them? I, OLPC Chicago, and others out here are working on Illinois HB5000, The Children's Low-Cost Laptop Act, which proposes to put laptops in up to 300 schools. It has passed the Illinois House and gone to the Senate. It needs amendments, and we are working with the Lieutenant Governor's office on this. We would like to coordinate our efforts with OLPC's. Which is the group providing input to the process from the eduction point of view (educators, teachers, kids)? Is this feedback part of the input from the deployment team? Thanks, Simon ___ 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: Turkish keyboard layout
Walter, Can you provide the state of the keyboards that have no note in the table: http://wiki.laptop.org/go/Mfg-data I have been assuming that this is the table that is most up to date. If there is no note in saying 'not yet approved', does that mean they have been through the entire approval cycle? Did you get a physical sample of each of these? Thanks, Kim On Mon, Apr 21, 2008 at 6:46 AM, Bernie Innocenti [EMAIL PROTECTED] wrote: [Sorry for this flood of Turkish related topics. It's only because I'm working from Turkey -- Captain Obvious] There seem to be two different keyboard layouts for Tukey, the F layout and the Q layout, named after the leftmost key of the top row. From our wiki and our X11 keyboard file, we seem to have picked the F layout: http://wiki.laptop.org/go/OLPC_Turkey_Keyboard But here everybody is telling me that the Q layout is the most widely used and the favorite. All the computers I see around me use this layout. Are we still in time to change the this in production? This seems to be yet another case where a country-specific build would be absolutely required, regardless of our planned release cycle. Obviously we'll get more and more of these cases as we deploy to a wider range of countries. So this seems like a good time to discuss how to have per-country builds released in parallel with ease. -- \___/ |___|  Bernie Innocenti - http://www.codewiz.org/ \___\ CTO OLPC Europe - http://www.laptop.org/ ___ 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: Translation refresh
I guess I'd like to err on the side that people believe by default that 'no activities are supported'. That way anything that works is a plus! In reality there are going to be some important things that we want to ensure are really working with every major build... so we will need to do some testing with real activities. Collaboration is really important to any release... so we need to include some activities that collaborate as part of formal testing. Similarly, Journal is much more than just an activity... so that will have to be part of systematic testing. Browse has to work as it is our connection to the outside world and to our local or school library. So that will have be part of any good test plan. You get the idea... Kim On Mon, Apr 21, 2008 at 5:11 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: 2008/4/20 Kim Quirk [EMAIL PROTECTED]: Bernie, I'd like to make two points regarding your notes: 1 - OLPC cannot be responsible for activities. So it is really much better that the activities are now separate from the base code to help get this point across to the country. As a 'sales' type person, you need to convey that activities are built, tested, translated by the community. OLPC will not be qualifying or certifying them. The country needs to reserve time and resources in its own schedule to help ensure testing and translation of the activities that they want. And they can do this, because the activities are not tied to our release schedule. If we can separate translations in a similar fashion that seems like a good way to go. So no activities at all are supported by OLPC? (the journal is technically an activity today, but is set to be merged into the shell when time permits). Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] where is Walter?
We are all grateful to have had Walter's leadership and inspiration to get us to this point. It should be inspiring to see OLPC branching out, expanding and increasing support for children in many different ways. OLPC has increased funding and resources in 2008 toward a continued commitment to helping kids in the least developed countries through deployment of XOs and Sugar. I don't think there is any shriveling or dying going on here. OLPC Association is way too small to meet this mission alone! Thanks, Kim On Mon, Apr 21, 2008 at 6:54 PM, Joe Barr [EMAIL PROTECTED] wrote: On Mon, 2008-04-21 at 18:22 -0400, Walter Bender wrote: Thank you for all of your support over the past two years and for all the feedback and encouragement you have given me. regards. -walter It really sucks to see OLPC shriveling up and dying. -- Resistance is not futile, it's (2PI * FREQ * L) / Q ___ 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: Turkish keyboard layout
Thanks Walter, Does this mean you have approved Uzbec, Pashto, French Canadian, and Kazakh? I am aware of the need for final approval of Italian, Khmer, and Napali. Quanta is sending these keyboards to OLPC this week. In the past when Quanta sends a first article for approval, do we need to match that up against the design from the wiki page? Or do you recommend some other step(s) for final approval? Thanks, Kim On Mon, Apr 21, 2008 at 7:49 PM, Walter Bender [EMAIL PROTECTED] wrote: Actually, I don't recall ever approving a Turkish keyboard... The rest of the table seems up to date as far as I know. I had been in close contact with several groups in Turkey about 12 months ago and at the time, they were advocating the F layout. It would certainly be easy enough to do a Q layout. -walter On Mon, Apr 21, 2008 at 7:29 PM, Kim Quirk [EMAIL PROTECTED] wrote: Walter, Can you provide the state of the keyboards that have no note in the table: http://wiki.laptop.org/go/Mfg-data I have been assuming that this is the table that is most up to date. If there is no note in saying 'not yet approved', does that mean they have been through the entire approval cycle? Did you get a physical sample of each of these? Thanks, Kim On Mon, Apr 21, 2008 at 6:46 AM, Bernie Innocenti [EMAIL PROTECTED] wrote: [Sorry for this flood of Turkish related topics. It's only because I'm working from Turkey -- Captain Obvious] There seem to be two different keyboard layouts for Tukey, the F layout and the Q layout, named after the leftmost key of the top row. From our wiki and our X11 keyboard file, we seem to have picked the F layout: http://wiki.laptop.org/go/OLPC_Turkey_Keyboard But here everybody is telling me that the Q layout is the most widely used and the favorite. All the computers I see around me use this layout. Are we still in time to change the this in production? This seems to be yet another case where a country-specific build would be absolutely required, regardless of our planned release cycle. Obviously we'll get more and more of these cases as we deploy to a wider range of countries. So this seems like a good time to discuss how to have per-country builds released in parallel with ease. -- \___/ |___|  Bernie Innocenti - http://www.codewiz.org/ \___\ CTO OLPC Europe - http://www.laptop.org/ ___ 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: [Server-devel] Customizing build 703 for mass deployment
What happens when you want to upgrade to the next OLPC build? Do you have to do it all again? Kim On Mon, Apr 21, 2008 at 10:25 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 3:37 PM, Bryan Berry [EMAIL PROTECTED] wrote: Currently, I use an extremeley inelegant method to create standard images for Nepal's deployment and I would very much like assistance in finding a more elegant method. Michael Stone has been helping me hack jffs2 images but I still haven't found a better method than booting into an os image, loading rpms and changing settings, then using save-nand to create a custom .img file. And then you copy that img from the nand to a usb stick that you can use on the rest of the laptops...? Not a bad trick ;-) m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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: Translation refresh
Bernie, I'd like to make two points regarding your notes: 1 - OLPC cannot be responsible for activities. So it is really much better that the activities are now separate from the base code to help get this point across to the country. As a 'sales' type person, you need to convey that activities are built, tested, translated by the community. OLPC will not be qualifying or certifying them. The country needs to reserve time and resources in its own schedule to help ensure testing and translation of the activities that they want. And they can do this, because the activities are not tied to our release schedule. If we can separate translations in a similar fashion that seems like a good way to go. 2 - Rolling a build takes a week, not 10 minutes. A build that is ready for release to the public, contains many steps: From check-ins, to packaging, to build creation, to testing, to the signing of the build, to getting a build properly into manufacturing... there are many steps and each step has many points of failure. Some of these we can eliminate over time through automation... but we aren't there yet. Kim On Sun, Apr 20, 2008 at 3:24 PM, Bernie Innocenti [EMAIL PROTECTED] wrote: On Sun, 2008-04-20 at 18:54 +0530, Sayamindu Dasgupta wrote: I don't think it makes sense to make seperate releases _only_ for translations. Why does rolling a release seem to be such a big thing? Generating a new OS image takes 10 minutes of machine time and this is as simple as it can get. All the other steps our release procedures that create overhead assume some amount of testing is necessary before a new OS hits users. But if the only thing you change is translations, it doesn't matter whether you're doing it with a new OS image or through a separate language pack. The resulting system will in both cases be the old one plus these new strings. And this is what you have to retest in both cases. What we need is a fastpath in our procedures for this case. I think we had something adequate for security updates. Michael? sidenote Our friends here told me that we must urgently translate the word Pippy because apparently it has a very inappropriate meaning in Turkish :-) /sidenote I am currently working on a language-pack builder for deployers and testers, which would generate language packs for different releases (eg: Update-1, or Joyride), etc. This should separate the release process substantially from the translations, and deployers can add enhanced language packs for the deployed systems as the translations evolve. This would add yet another degree of implicit dependencies to our system. The way I see it is that we already have a very dangerous situation where Sugar and the activities can freely vary with respect to each other with no robust dependency tracking. If we also add translations to the equation, we're making it much worse. Then you get bug reports such as I don't get a string translated to Turkish, you'd have to ask the user: - what OS release? - what activity version? - what language pack? Unless we plan to switch to a true package manager, we can't modularize things too much. However, to make this work we also need to follow some kind of branching policy wrt the releases (eg: once Update-1 is released, bugfixes targetted for subsequent minor releases f'd uor Update-1 should be committed to the Update-1 branch only, while development for Update-2 should continue in the devel branch). This has to be done for _all_ activities (and of course, the components of Sugar as well). Yes, this is what is being done already for Sugar and many other packages hosted on dev.laptop.org (although there's no policy that mandates it). -- \___/ |___|  Bernie Innocenti - http://www.codewiz.org/ \___\ CTO OLPC Europe - http://www.laptop.org/ ___ 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
Weekend - Technology Team, Details
*Network / Collaboration* Ricardo Carrano: * The multicast filter. To avoid waking up a suspended XO at every multicast frame received (they can be pretty frequent in a dense mesh) a multicast filter was implemented in the firmware release 22p8. Now the driver should announce the multicast addresses of interest. If it does not we have problems like #6818. A driver patch is now being discussed by Marvell and David Woodhouse. There has also been discussions (at the devel list) on the limit of 8 mac addresses in the filter. * The 6589 blocker. We are still fighting in the #6589 front, the fix included in the firmware 22.p9 (that also needs kernel support) was the introduction of a firmware ready event (or a 200ms wait time for backward compatibility). This fixed the bug but caused a race condition as a side effect, so a new firmware release - 22p10 was released (today). Relase 22p10 is the current firmware version under test now, and the next candidate to go into joyride (22p8 and 22p9 will be skipped) and succeed 22p6. Giannis Galanis: I updated the Update.1 release notes at http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes for most network issues. I also included most bugs we discovered with Wad in Peabody 100 laptop test. Guillaume Desmottes: * Investigated PS bugs that have been filed due to latest test beds. * PS bugs triaging * Wrote some improvements in PS and Telepathy to help debugging. * Discuss 1-1 tubes protocol in Salut * Reviewed a D-Bus tube fixed I have spend lot of time this week digging into presence bugs that have been filled by Wad according his observations during latest test beds (#6880 and next). I wrote a not-reviewed-yet Gabble fix for one of them (#6883) and improved PS debugging output and telepathy-glib to inform us when CM are disconnected from the bus (#6905). That should, hopefully, give us more information on some strange and hard to reproduce bugs. Morgan Collett: * Started my new role for OLPC, working on activity collaboration * Started http://wiki.laptop.org/go/Collaboration_Central as a page to track collaborative activities, developer resources and news about collaborative activities * Tested Jani Monoses' packages for Sugar in Ubuntu 8.04 (hardy) which is due to release next week as this will be a very useful way for people to run Sugar to write activities * The theme for this week's sugar developer meeting on IRC was collaboration. We had a good discussion about API issues in particular. * Started reviewing the state of collaboration code in core activities: submitted patches for Write for #5062 and #6021. * Process/Release* Michael Stone: This week, I published two commentaries on planning and I spent many hours working to broaden and deepen communication channels throughout the project. I also helped prepare a collection of activation leases for Mexico and I began trying to comprehend what packages could be updated in a near-term bug-fix release if the need arose to make one. Kim Quirk: Wrote up the first level of detail feedback from the sales team as to the priority of bugs fixes and features needed. I presented a summary of what works and diagrams of basic network configurations that have been tested and documented. There was much discussion about activation leases and mesh/collaboration. The sales team is also interested in easier XO upgrades, more video/text documentation of how things work, and better battery life. This information is part of the goals and priority planning that has been discussed heavily on various mailing lists. Dennis Gilmore: * started branching things for dist-olpc3 based on F-9 for testing * spoke with Fedora Brazilian Ambassadors on how they can help OLPC *General Software issues* Sayamindu Dasgupta: I have been figuring out possible ways to make the language packs more effective. Currently, the existing language packs are only a hackish solution to quickly check translations (and contains the translations only for the bleeding edge development branch). For actual deployment scenarios, we need more fine grained control over the contents of the language packs. Some of the parameters which should go into the building of the language packs (so that deployers can create a custom language pack for their deployments) include: a) Branch being followed (ship-2, update-1) b) Activities being included in the deployments I'm working on a web based tool which can do this - hopefully I'll be able to come up with something by next week. I also made a short presentation in the first meeting (over telephone) of OLPC India (which happened this Friday), outlining our translation workflow, so that people interested in contributing to the translation efforts can join us. Andres Salomon: - worked on getting more stuff upstream (I gave a summary of that at the software meeting, I'll give another update for weekend once the patches are actually in Linus's tree). - cleaned up kernel build trees on filer (which made me discover some
Re: freezing DCON for insecure boot
Bernie, It is really, really important that we don't encourage countries to have their own images if they are not developers participating in active development of our code base. We've had some good discussions around this recently as it has become very difficult to support Uruguay. This is why we separated out activities and content from the rest of the image. So that we CAN encourage countries to choose activities and content (and a few other things), but to try not to do any customization that requires their own image. I'm hopeful that what you are talking about is something that CAN go on the customization stick after the latest build has been installed. I just wanted to make sure you were up to speed with some of the more recent discussions we've had about customization. Once a country has agreed to send some developers to Cambridge to go through a build side by side with us, then they will have a better chance at successfully being able to support their own builds. We want to encourage them to get their changes into our builds so they won't have to manage their own streams forever. Scott and Michael will be able to go into the details of the customization process (if you don't know them). Thanks for your thoughts and understanding. Kim On Fri, Apr 18, 2008 at 6:19 AM, Bernie Innocenti [EMAIL PROTECTED] wrote: Hello Mitch Scott, I have a laptop with a developer key, running an unsigned image with a few customizations for Turkey. They want a pretty custom logo and I succeeded in getting it to work in insecure mode, but it looks ugly because they see the kernel barfing diag messages on the console for a few seconds before the bootanim kicks in. Is there some forth-fu I could use to fix it? A modified olpc.fth file would be best for me as I don't have much confidence with forth and much time to implement and test it myself. Thanks. -- \___/ |___|  Bernie Innocenti - http://www.codewiz.org/ \___\ CTO OLPC Europe - http://www.laptop.org/ ___ 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: New Planning Thoughts draft.
In my experience running QA teams and releases for commercial projects, small fast releases require (or imply) quite a bit of focused process and really good automation on the testing side. Also, after other discussions on this list, it seems like there are two other items that drive 'major release' twice a year and a few bug fix releases in between: 1 - Our target users (mostly schools) will not be upgrading often, and many will require weeks or months of their own testing before they do upgrade thousands of computers. 2 - From a support perspective, this audience will probably require that we support a major release for an entire school year. If we offer too many releases during that time, we will not be able to keep up with the backward compatibility matrix of releases that have to work with other releases. If kids upgrade on their own, will they work with the older version that was installed on 90% of the other laptops, etc. I think if our product were aimed at developers or if it was a server-based product where we could control the releases and there were no backward compatibility problems, then it would be great to have many small, fast releases. Kim On Thu, Apr 17, 2008 at 7:54 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 1:23 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: I see this too as a hard problem and don't really have experience neither. What I would expect is that working on frequent time-based releases with features slipping as needed works best for projects like linux distros, where slipping a feature grossly means not updating a set of packages to the latest stable version. Even linux distro (Fedora at least,), doesn't actually do focused releases. Roughly, they set a timeframe and they get in everything which is ready by that date. This is very easy for a linux distribution. It would be harder on the Sugar codebase but still very much feasible, it's the same approach of GNOME releases. Though Michael proposal goes a step further. We would be focusing only on one (or a very limited number) of goals per release. Marco ___ 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: [Server-devel] Mesh connectivity from regular WiFi gear
I thought there might be a wireless driver piece that needed to be addressed. I gave the PEAP trac item to Michail for comment. Thanks, Kim On Thu, Apr 17, 2008 at 1:51 PM, Marten Vijn [EMAIL PROTECTED] wrote: On Thu, 2008-04-17 at 09:27 -0400, Kim Quirk wrote: Martin, Wad, We have promised to provide NYC with a schedule for the item you mention, Martin, trac #6855, as well as support for PEAP. trac #6900. I have told them that PEAP was a 2009 feature (mainly because I wanted to discourage them), but they have asked if we can pull it in. Considering: http://www.freebsd.org/doc/en/books/handbook/network-wireless.html and http://www.freebsdmall.com/% 7Eloader/en_US.ISO8859-1/articles/wireless/article.htmlhttp://www.freebsdmall.com/%7Eloader/en_US.ISO8859-1/articles/wireless/article.html This would be possible and I am willing to put time in this. If needed, I could put some effort to put it in firmware (tinybsd) for any i386 mobo/embedded system. The XS could to radius (and optinally config AP's with ssh/or/puppet) Marten So the next step on these two items is to figure out the development and test effort associated with these two features. It would be great if people could add their thoughts into those trac bugs as to what work is needed. After we have that, we can weigh that against other priorities and come up with which release to put these in. Thanks, Kim On Thu, Apr 17, 2008 at 8:58 AM, Martin Langhoff [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 3:26 AM, John Watlington [EMAIL PROTECTED] wrote: If a school is using a mesh, we have a carefully designed system to ensure that a laptop doesn't go into simple mesh mode, and instead connects automatically with the school. If a school is using traditional WiFi, there is no such guarantee. This is possibly bad, as kids that aren't associated can interfere with those that are. When at NYC, you mentioned that the NM searches and prefers the school-mesh-n essids of mesh-type signals. And that perhaps we could make it lock into infrastructure-mode essids of that name with the same kind of preference. Would this simple fix help sort the problem out? Also, do we have wikipage of tested APs? cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel -- Marten Vijn http://martenvijn.nl http://wifisoft.org http://opencommunitycamp.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [sugar] Testing Update.1-702
Walter found a problem with Chat when using an open AP between two laptops. The Chat invitation shows after the first one shares it, but when the second laptop clicks on it, that opens a new chat -- it doesn't open the shared one. THey can't chat. It worked in simple mesh and school server mesh. Walter - please tell us if this is a show stopper for Update.1 -- especially given that we are pushing for AP in some deployments. If so, we should make sure someone is looking at that one first. Without knowing exactly when this regressed (I hope to try it on some 699 laptops), it isn't clear how quickly it can get fixed. Is there a trac item for this, Walter? Kim On Fri, Mar 28, 2008 at 10:40 AM, [EMAIL PROTECTED] wrote: Denis wrote: I ran through the smoke test today. I used update.1-703 I had one spanish and one english XO I had some keymap errors in X the console was fixed with the kbd update http://dev.laptop.org/ticket/6776 I had one issue with Read, Ive not yet filed a bug on it. I created a document in write. Put a picture in the middle with text on top. shared it between XO's. Which all worked fine. I copied to a usb key and opened on the the other XO. The image was left aligned. I wanted to repeat the test before filing a bug. --- This one of those bugs fixed in abiword-2.6.0 that I was talking about a few days ago. There are many more. Cheers Martin ___ 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: Playing w/ Activity packs in build 702
Thanks Bryan! Can you add a link to activity testing results from the Release Notes page with this info? ( http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes) It would be great for others to refer to this info when they download 702 and recent activities. Thanks, Kim On Wed, Mar 26, 2008 at 10:02 AM, Bryan Berry [EMAIL PROTECTED] wrote: Hey guys, Today I tested out almost of all of the activities on wiki.laptop.org/go/Activities on build 702. I remember reading an e-mail from Kim Quirk asking folks to test installing the activities on build 702. I am posting my findings here in case it might be useful. You may already be aware of the problems I encountered. First I downloaded all of the activities from the wiki page. I didn't use any automated scripts or xo-get because bandwidth is quite poor at my location. I didn't test out activity sharing, hopefully will do that tomorrow or Friday. What didn't work: OurStories v.1-beta Mimic v.1 MaMaMedia Storybuilder v.12 :( really an awesome activity Tuxpaint v.1 -- doesn't run at all Schoolsplay v.0.4- runs but display screwed up, hard to read MaMaMedia Creative Center v.3 - works but doesn't do __anything__, appears to be an advertisement Kuku - doesn't run Inferno - doesn't run Dr. Geo II - v.104 does run but really, really slowly Watch Listen v.10 doesn't even show an icon in the activity panel What Works: Scratch Need Words app to work w/ Nepali, otherwise mostly useless Newsreader runs but very slowly Maze Speak Browse Write Paint, OK Measure EToys Memorize StarChart Moon SimCity starts up, didn't play w/ it much Record TurtleArt SocialCalc Ruler PlayGo PollBuilder runs, but Lesson Plans don't render properly, appears to be xml-1.0, UTF-8 MaMaMedia Learning Center Jokebook Jump Jigsaw Puzzle XoIRC Implode Frotz XaOS Flipsticks Other issues: In general, Etoys-based activities start pretty quickly but take a long time to shutdown, literally 2 minutes. This is an issue our team in Nepal is wrestling w/. Hopefully we will come up w/ a solution that can be shared. I should ask Hilaire for help w/ this. Minimal documentation for Starchart, Go, Measure, Jump, Implode, Connect. These are __great__ activities but it would be hard for a kid to get into them w/out having background knowledge. Our two schools will share a 128 kbps Internet connection so it will be harder for the kids to google for answers. SocialCalc, appears to be proprietary. The license info read All Rights Reserved. How are we allowed to use it and how can we translate it? Am I missing something? I got some weird errors during bootup HAL daemon userdel: user 1035 does not exist I got 6 or 7 such messages Question: How do I install the locale for Gcompris? How do I install the TamTam suite? Hope this was of some use. On the whole, I was quite impressed by the breadth of activities. For now, 702 gets my vote for Update.1 stable release -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ 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: New update.1 build 702
Ricardo, Use this link to create your customization USB stick: http://wiki.laptop.org/go/Customization_key#Preparing_the_key: Chris, I have pulled together a set of bundles that include the latest version of each of the activities that shipped with G1G1. I would like people to use this set of activities in their bundles directory for testing 702 (unless they have their own customization bundles). How far along is the automated xo-get? (assuming that is what you are working on). Perhaps we can release my '702 G1G1 customization' zip for now. Also, it is a little confusing how we are dealing with the signed and unsigned versions. I can't get an unsigned version to work off one boot directory. I have to configure the boot directly to install the OFW and OS; and then change the boot directory (add the actos.zip and runos.zip) to be able to install the bundles. Is there some way to make this all work on an unprotected XO? Thanks, Kim On Sun, Mar 23, 2008 at 7:09 PM, Michael Stone [EMAIL PROTECTED] wrote: On Sun, Mar 23, 2008 at 05:35:28PM -0300, Ricardo Carrano wrote: Updated from 695 to 702. No activity icons on the frame... Ricardo, See http://dev.laptop.org/ticket/6598 http://lists.laptop.org/pipermail/devel/2008-March/011984.html for some explanation of what's afoot. Also, Chris Ball and the xo-get folks have done some work on scripts for assembling activity packs and for mass-installing activities on empty builds. Perhaps their work is of interest? Michael ___ 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: New update.1 build 702
Sounds great!! Thanks, Kim On Sun, Mar 23, 2008 at 10:00 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi Kim, Chris, I have pulled together a set of bundles that include the latest version of each of the activities that shipped with G1G1. I would like people to use this set of activities in their bundles directory for testing 702 (unless they have their own customization bundles). How far along is the automated xo-get? (assuming that is what you are working on). I have a script that pulls the latest versions of activities out of the update.1 repository into a bundles/ directory, and that knows which activities should be used for a Peru, Mexico or G1G1 customization key. I'll prepare a zip file of a customization key with the G1G1 activities on tomorrow, we can see if there are any version discrepencies between our bundles, and I'll release a G1G1 customization key and the script tomorrow. Sound okay? Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Maintaining Activity Packs
Michael, It seems like recording the compatibility matrix between builds and activities alone is a 2-3 person job in the very near future. Today it is probably a full time QA person -- and we are short about 3 QA people right now. It would be great to get some feedback as to how this can be achieved by the developer of the activity -- or what kind of automated tools can be developed to make it easy to test compatibilty; and how can we encourage people to do this testing. We have to assume that OLPC will NEVER have enough people to do backward compatibility testing for activities, other than a few very basic activities. Kim On Fri, Mar 21, 2008 at 7:25 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | * to the extent that we are able, we should record the compatibility | matrix between builds and activities Once upon a time, there was going to be a build called First Release to Service, and its number was to be 1. ~From http://wiki.laptop.org/go/Activity_bundles: Each activity.info file must have a host_version key. The version is a single positive integer. This specifies the version of the Sugar environment which the activity is compatible with. (fixme: need to specify sugar versions somewhere. Obviously we start with 1.) It seems to me that FRS ~= Update.1. It's all designed; it just needs to be implemented (and that's easy). | * what assistance are we obligated to provide to deployments? If OLPC is not completely daft, it must do everything possible to make the governments happy, so that they are most likely to recommend OLPC to their neighbors. | * if we discover notable flaws (security, legal, objectionable | content) in bundles that a deployment is using, what should we do? Communication and openness are the hallmarks of OLPC. | * in particular, whose responsibility is it to initiate communication | of this sort? What, you don't have a distinct relationship manager responsible for ensuring complete communication with each client? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5EPgUJT6e6HFtqQRAgtyAJ9pLkQZZSwjSZjCya67PUqGHqpDpACgmpjv wpUiyhV4z9aTu1wOc/RbPGk= =bZuB -END PGP SIGNATURE- ___ 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: Today's mesh testing.
Great! Thanks for the update, Chris. Kim On Sun, Mar 2, 2008 at 7:05 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, Daf and I got the school server jabberd/shared roster working today. We connected/registered 32 laptops to it with mesh TTL set to 1 for broadcast, and they were all able to see and join a shared chat session with each other. The workload on the spectrum analyzer increased from 18% (no-one connected) to 26% (all connected). The chat session is consistent -- no-one is dropping out and new messages are seen by each laptop, with a few seconds of lag. With the mass chat session still running, we shared a 500KiB PDF. First we joined the shared Read session with one laptop, and the download took 16 seconds to complete. We then joined two more laptops at once, the first download took 26 seconds and the second finished at 30 seconds. Five more at once: all finished around 1m00s. Ten more at once: the first finished at 2m18s, the last finished at 2m40s. There were no failures downloading the PDF. The sharing was unicast TCP, with mesh TTL set to 1, which explains the slightly worse than linear increase in download time for more laptops downloading at once. This is much more anecdotal than the full test plan, but we thought the testers currently in Peru would want to know what they can expect from the school server setup ASAP. We don't have more laptops upgraded and ready to join the network yet, but we don't have any reason to believe we've saturated the network -- with the PDFs downloaded and Chat still running, the duty cycle on the spectrum analyzer is now at 28%. (In general, wireless networks seem to start degrading around 40%.) - Chris and Daf. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Test / debug week has begun
All developers in the 1CC area should plan to spend time in the board room helping with setup, discussion of bugs, builds, and testing for our scaling, mesh testing. Please don't run any XO laptops outside of the board room today (and perhaps this whole week). Thanks! Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
Thanks Yani. I think we need to start with Update.1 and add the required fix(es) to that until we can get the next build together. Who can help with that? Ricardo, if you think there is anything else different with B4s in regards to network performance, please tell us. I'm not aware of anything in hardware. Dennis, Can you be prepared to quickly pull some builds together early next week? Thanks, Kim On Sun, Feb 24, 2008 at 4:39 PM, Giannis Galanis [EMAIL PROTECTED] wrote: Kim, You can see the diffs here: http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html http://dev.laptop.org/%7Erwh/announcer/joyride_vs_update1.html You will see that there are plenty of new stuff in joyride than just a telepathy-salut update. One thing we can do is use 693 and install the specific package, or make a new Update.1 build that includes it. But we should test it individually before putting it in the update.1 build. One thing we can do is have half the XOs with 1721 in one channel, and the other half with 693 in another channel. Also, how about using B4s? Is there any effect in the performance except suspend/resume? I remember Ricardo saying there were hardware changes related to 4470. Ricardo, can you confirm this? If we decide on the build by tonight, I can have all the XOs updated and ready by tomorrow. On Sat, Feb 23, 2008 at 5:08 PM, Kim Quirk [EMAIL PROTECTED] wrote: Agreed that Read sharing is the highest priority application. My concern is if there are a lot of other things in joyride, then it will take us a long time to get a release out based on joyride. If we pull the fix for Read back into update.1, (and other things that we find next week), then we won't waste time on testing or finding bugs in joyride. Does anyone have a good feel for the differences between today's Update.1 and joyride 1721 -- or can someone list the diffs so we can make a decision? Kim On Sat, Feb 23, 2008 at 8:13 AM, Walter Bender [EMAIL PROTECTED] wrote: Read sharing is a critical feature. Please do test it. -walter On 2/23/08, Morgan Collett [EMAIL PROTECTED] wrote: Giannis Galanis wrote: 2. I will try to update all of them with the build we will agree to initially test with. This would be 693/D13? There is a new version of telepathy-salut in 1721, which apparently only fixes smth related to stream tube flush(which i dont know what it is). I dont believe it important to our test. Other than that Update.1 i think should be ok. As I said in reply to Chris's mail, the salut fix is for Read in #6483. If you are going to test sharing PDFs in Read, please use Joyride-1721 otherwise there is a high chance it won't work at all under any conditions. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
Right. But the suspend and resume problems we've seen with the mesh and sharing can be recreated on a relatively small number of laptops (10). So we will either fix the problems, or turn off suspend in order to test for scaling issues above 50. We have 50 MPs for next weeks testing. So we should be ok. Kim On Sun, Feb 24, 2008 at 10:12 PM, John Gilmore [EMAIL PROTECTED] wrote: Ricardo, if you think there is anything else different with B4s in regards to network performance, please tell us. I'm not aware of anything in hardware. They don't suspend. So if MP's have networking trouble that happens when a laptop suspends, the trouble won't happen on a B4. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
Agreed that Read sharing is the highest priority application. My concern is if there are a lot of other things in joyride, then it will take us a long time to get a release out based on joyride. If we pull the fix for Read back into update.1, (and other things that we find next week), then we won't waste time on testing or finding bugs in joyride. Does anyone have a good feel for the differences between today's Update.1and joyride 1721 -- or can someone list the diffs so we can make a decision? Kim On Sat, Feb 23, 2008 at 8:13 AM, Walter Bender [EMAIL PROTECTED] wrote: Read sharing is a critical feature. Please do test it. -walter On 2/23/08, Morgan Collett [EMAIL PROTECTED] wrote: Giannis Galanis wrote: 2. I will try to update all of them with the build we will agree to initially test with. This would be 693/D13? There is a new version of telepathy-salut in 1721, which apparently only fixes smth related to stream tube flush(which i dont know what it is). I dont believe it important to our test. Other than that Update.1 i think should be ok. As I said in reply to Chris's mail, the salut fix is for Read in #6483. If you are going to test sharing PDFs in Read, please use Joyride-1721 otherwise there is a high chance it won't work at all under any conditions. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut and Suspend/Resume issues
It does feel like we should turn off suspend for some of our testing. I've experienced similar problems. Chris, do you recommend removing ohm? Or is there something else we should try? Kim On 2/19/08, Ricardo Carrano [EMAIL PROTECTED] wrote: I believe the most important issue here is that, the way it is now, suspend/resume will make a disconnected mesh unusable. On Feb 17, 2008 4:11 AM, Giannis Galanis [EMAIL PROTECTED] wrote: There are a couple of important issues/bugs regarding Salut and Suspend/Resume. FIRST, there is a sugar issue, (or at least it seems so). When an XO resumes after long suspends, all icons(APs, XOs, but not the meshes) instantly vanish*(#6467)*. Then they slowly reappear. Although with the APs the situation is pretty straightforward, with the XOs we have several cases: - all XOs in the mesh return almost instantly - all or some XOs return slowly one by one - nothing returns, and avahi peer list is empty*(#6498)* It seems that although suspend should keep the previous situation frozen, in fact the avahi peer list is affected. SECOND, we have a network issue, which suggests a war between suspend/resume and avahi/salut Suspend will be interrupted only with unicast packets, but Salut/avahi rely on multicast packets. The result is that when an XO that appears in the mesh view is suspended, avahi will treat it just as if it has left the mesh. - When an XO is being used(not suspended), all other suspended XOs in the mesh will start failing 1 by 1 - From the moment an XO is suspended in about 10-30min the icon will vanish.*(#6282)* - If within this time new XOs join the mesh than the icon will vanish instantly!!*(#5501)* - If gradually several removed XOs start to resume, their icons will start returning *As you can see, the XOs have very little chance to even see each other** RESULT: A mesh of several XOs will avoid icons flashing here and there, ONLY if no XO has been idle for more 10min, which is rather unlikely. Considering the effects of the FIRST issue, you would practically have to restart sugar or switch channel back and forth to return to your original status. Salut/avahi are very sluggish in handling failed connections, and suspend resume enhaces this effect. -- Sent from Gmail for mobile | mobile.google.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 691
Thanks Ricardo! Kim On Feb 11, 2008 10:59 AM, Ricardo Carrano [EMAIL PROTECTED] wrote: Kim, I wrote http://wiki.laptop.org/go/Libertas_Debug and linked from Test_Config_Notes. On Feb 9, 2008 2:17 AM, Kim Quirk [EMAIL PROTECTED] wrote: Ricardo, Can you add this 'enable wireless debug' info to the Test Config Notes: http://wiki.laptop.org/go/Test_Config_Notes Thanks! Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Items for update.1 RC3
I'm worried about these two Regression bugs. Things that worked in 656, last good shipping build: - Problem copying a photo to a write doc - 6405http://dev.laptop.org/ticket/6405(mstone is working on it) - Problem when sharing a document; try to add a photo and write crashes - 6407 http://dev.laptop.org/ticket/6407 (maybe a dup of 6170 - uwog?) (These are from Test Group Release Notes) Kim 2008/2/12 Erik Blankinship [EMAIL PROTECTED]: Record-52.xo http://dev.laptop.org/ticket/4525 If it is approved, Record-53.xo http://dev.laptop.org/ticket/6417 ___ 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: New update.1 build 691
Gary, Did you upgrade to 691 via olpc-update? If so, can you remove your /home/olpc/.sugar/default/nm/network.cfg file and reboot? I had to do this to get my WPA connection to work. I haven't been able to test WEP with this build, but I wouldn't be surprised if it is similar. Ricardo, Can you tell us what method of update (cleaninstall or network upgrade) you did and if your WEP and WPA just came up working, or if there is any sort of reboots, etc. needed. I have added some note in the Test Group Release Notes: http://wiki.laptop.org/go/Test_Group_Release_Notes To capture the high level of what works. Please add / modify as needed. Thanks, Kim On Feb 7, 2008 10:33 PM, Gary Oberbrunner [EMAIL PROTECTED] wrote: ffm wrote: I take it this is RC2? Does WEP work yet? Actually it mostly does for me, now. (WPA actually). I had to reboot a few times after the upgrade, but after that clicking on the WPA ap usually works. It doesn't autoconnect after a reboot (it tries though). But after that I can click on the AP and it connects OK usually. -- Gary ___ 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: Please test update.1 rc2.
Calling all Testers! This release candidate is available and ready for serious testing, build 691. Before Chih-yu left the office she pulled together some wiki pages with test cases and a place to record some results. Please take a look - help refine and create test cases - or help test and record some results!! http://wiki.laptop.org/go/Update.1 Also see (and add to) the high level release notes - add info that is helpful to others who are thinking about testing. http://wiki.laptop.org/go/Test_Group_Release_Notes Please add real bugs to TRAC. Thanks!! Kim On Feb 8, 2008 6:01 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Signed builds for update.1 rc2 (build 691) are now available at: http://download.laptop.org/xo-1/os/candidate/691/jffs2/ You can also 'olpc-update candidate-691', which will get the signed build. Release notes at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_691_Q2D13_.28RC2.29 Please test and file bugs! --scott -- ( http://cscott.net/ ) ___ 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: New update.1 build 691
Ricardo, Can you add this 'enable wireless debug' info to the Test Config Notes: http://wiki.laptop.org/go/Test_Config_Notes Thanks! Kim On Feb 8, 2008 7:35 PM, Ricardo Carrano [EMAIL PROTECTED] wrote: Ricardo, Can you tell us what method of update (cleaninstall or network upgrade) you did and if your WEP and WPA just came up working, or if there is any sort of reboots, etc. needed. I updated via network (olpc-update) and no extra reboots were necessary. WEP, which was broken since 656, worked immediately. WPA _continued_ to work. If an update to 691 _causes_ WPA to work, then it is a question of what was the previous version. But more important, I believe, is the fact that WPA not always work for some APs. Though this is not unusual in many devices (not only on the XO) the next step would be to determine which APs and WPA versions (encryption and authentication methods) are problematic. So, enabling debug... echo 0x6180 /sys/module/libertas/parameters/libertas_debug ... and sending dmesg outputs to a filed WPA bug, can be useful. -- RC ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 691
Mako and Bert, I added a note to the Roadmap for Update.1, to discuss these items for inclusion in the final release of Update.1. If it doesn't take place before the Wed SW meeting, it should happen then. 2pm EST, irc. Dennis, I think it would be best if you could help drive this process for the items that people have marked as Request for Update.1, but may have fallen through the cracks. Would it be possible for you to find the 'request for Update1' items a few days ahead of time and try to figure out what is needed for them to make it (such as a critical trac bug); and if there is questions on whether or not it should go in, then you can a least alert the person to the discussion so they have a chance to argue their case. Is this reasonable? Or another suggestion? We hope to have the final release candidate by the end of next week -- so I think that means we only want one more build. Also, the items that are still open on the Roadmap are going to get their final review and be moved to the next release unless someone is willing to make a good argument. Please review. Thanks, Kim On Feb 8, 2008 9:46 PM, Jim Gettys [EMAIL PROTECTED] wrote: Did you do a request for update in trac? Without that, we have no way to know if your testing in joyride has completed. - Jim On Fri, 2008-02-08 at 19:53 -0500, Benj. Mako Hill wrote: quote who=Build Announcer v2 date=Thu, Feb 07, 2008 at 05:53:23PM -0500 http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build691http://pilgrim.laptop.org/%7Epilgrim/olpc/streams/update.1/build691 Is there a reason that the approved olpc-library-common and -core packages were not in? The fixes aren't to critical bugs but they are also not to software. As #6371 says, they clean up CSS and text in the content pacakges. It's not clear to me if this is being treated like software or like translations but it would be good to have it communicated either way and in the build as soon as possible. Regards, Mako ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ 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
Weekly Test Meeting - Testing UPDATE.1; FRIDAY 4:00 PM EST
Earlier this week I sent out a message for people who want to help in testing for THursday afternoons. I need to change that to Friday afternoons, 4pm EST Over the next few weeks we are looking at the release candidates for Update.1. A reminder of the agenda/wiki page: http://wiki.laptop.org/go/Test_meeting_Minutes And the call in number: From the United States 866-213-2185 From Outside the United States 1-609-454-9914 accesscode: 8069698 Thanks, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What's left for Update.1
Jim, I think this is way too much stuff for Update.1. We are in code freeze. We have items 1 and 2 scheduled to go into RC2; I would suggest that we ONLY pick up Spanish, where we really fell short in the current build; I don't agree with holding up this build for either 4 or 5, as this feels like new, untested code - perhaps there is no 'fix' even available at this time (I'd need to see the arguments that this is blocking AND we have a fix); and I agree that we need to look at 'Blocking' bugs that are still open to see if we agree they are still blocking - or move them out. People can argue otherwise (I'm open to a good discussion), but my recommendation is to get this build out, with all the known issues well documented. Kim On Jan 31, 2008 10:11 PM, Jim Gettys [EMAIL PROTECTED] wrote: For comment and discussion, here are the showstoppers I know of for getting Update.1 finished. If you think there are others, please speak up now (and modify the subject line to start another thread). Activity developers: note we'll be asking you to upload updated activities to pick up all the recent flurry of translation work very soon. 1 - wireless firmware and driver support (to fix problems with WEP and WPA) 2 - q2d11 OFW - to fix battery problems 3 - update activities to pick up translation work, Spanish in particular, but not missing other languages we may need. 4 - UI fix for registration with the school server. http://dev.laptop.org/ticket/6136 5 - switch to gabble from salut at school. 6 -testing and fixing anything critical! If we don't want to hold up an RC2 to pick up translation, then we should anticipate an RC4 might be necessary (as we may have issues that come up with updated activities). 4 - we previously (without Dave Woodhouse being available to add to the discussion) thought we could/should punt #6135 and release note. However, talking with him about what we should really fix given his experience in Mongolia, the lack of positive confirmation that the laptop actually was registered is a real issue. The teachers are not familiar with English (or computers), and the subtlety of a menu entry going away isn't good enough. I think we need to seriously discuss about possibly/probably being update.1 fodder is the kids arrive at school in the morning problem. 5 - Use of mesh in large, crowded environments If everyone arrives at school running local link and resumed quickly, the network might melt from mdns mesh traffic's interaction with the mesh's implementation of mutlicast. We've upped the multicast bitrate for multicast as a band aid, until we can dynamically adjust the bitrate. But the fundamental issue comes that in large, dense school environments, can't expect multicast to scale far enough, and should be using unicast to a presence server (jabber in our current case) to handle this problem. Dave Woodhouse has suggested may be to try to get a response to the school server's anycast address, and if we get a response from a school server, switch from Salut to Gabble for presence service automatically. This is also somewhat mitigated by having working power management, as machines that have suspended due to idle stop sending mdns packets, and the kids presumably will want internet access and switch over when they arrive. But I'm not very confident that this will always work in large environment. Another temporary solution would be to have Ohm ask NM to reconnect if the machine is suspended for more than some interval, say, 30 minutes. -- Jim Gettys One Laptop Per Child ___ 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: Update.1 690 poweroffs?
Thanks for your info, Martin. Are you on Trac? Can you write up a bug for follow up? (Or if someone knows of a trac item that Martin can use to add his notes; that would be great). Thanks, Kim 2008/1/28 Martin Dengler [EMAIL PROTECTED]: I hate to trac something so vague, but please let me know if this better belongs there: I've been running update.1 build 690 on my G1G1 C2 for about 4 days now, and on 2 of the 3 nights (and one afternoon) since I installed it I've found it powered off. It's been connected to AC all three times, and each time the power button did no good - I had to take out the battery and disconnet the power to start it up. Today the battery light was on (green) but no other lights were on (the other two times no lights were on). I've never seen this behavior before. Anybody else seen this? Martin ___ 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 690 problems
Hi Gary, Thanks for these notes! On the WPA/WEP issues with this build, there is a trac bug already open, #6123 (WEP) or #6191 (WPA). Can you add your info to one of those? The other two issues might need new trac items. - kim On Jan 27, 2008 9:24 AM, Gary Oberbrunner [EMAIL PROTECTED] wrote: Hi, just joining this list. I have a g1g1 and just did my first developer-key update from the shipped build to the rc1 build (update.1-690). Here's a few issues: Connecting to my home WPA (v1, psk; linksys WAP54g) is flaky. I can usually get it to work but only after several tries. First (auto) attempt after reboot never works. I *think* I have to wait for it to time out connecting to all the APs I've ever used, and only then can I click the desired AP and it may connect (and it sometimes just asks repeatedly for the WEP key). This morning it doesn't work at all for me. :-( What log file can I enable/send? Once I'm connected, the browse activity is now extremely slow. Doesn't seem like a DNS delay, seems more like it's not responding to the network packets (but I haven't installed a sniffer so hard to say). The TurtleArt activity's title in the task bar (?) in the main screen has a typo: it's called TurteArt (missing the l). If you start TamTamJam and play (so it's playing the sequence) and then suspend, coming out of suspend takes a really long time; you press a keyboard key, a few notes come out, do that a dozen times or so and eventually the machine starts responding. Perhaps some audio events are getting queued up and should be flushed on resume? -- Gary Oberbrunner ___ 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: New update.1 build 690
I can't log into my simple WEP at home with this build...and I have had many builds where this has worked just fine, so I'm confident it is the build. Does anyone know why this is so broken in 690? Will we be able to get a fix? Trac item: 6123 Kim On Jan 26, 2008 10:29 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On Jan 26, 2008, at 14:41 , Dennis Gilmore wrote: On Friday 25 January 2008, Build Announcer v2 wrote: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build690http://pilgrim.laptop.org/%7Epilgrim/olpc/streams/update.1/build690 Changes in build 690 from build: 689 Size delta: 0M -ohm 0.1.1-6.4.20080119git.fc7 +ohm 0.1.1-6.6.20080119git.fc7 -bootfw q2d08a-1.olpc2 +bootfw q2d10-1.olpc2.unsigned This is the intended update1 rc1 build. Please give this extensive testing WPA still does not work for me. - Bert - ___ 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: a few GCompris activities have problems
Hi Teresa, It seems to me that it would be really good if you could somehow mark the activities which currently don't load or run on a particular build so others will not both trying to load them until they are fixed... It will be important to note what build didn't work, as well as what build does work... Some ideas on this? Kim On Jan 7, 2008 2:02 AM, Teresa Selling [EMAIL PROTECTED] wrote: I found a couple more activity problems: /discovery/micelaneous/babyshapes: coiuldn't find or load babyshapes/food/chocolate.png (missing all the items on the left) /discovery/micelaneous/clockgame: couldn;t find or load clockgame/clockgame-bg.jpg *Teresa Selling [EMAIL PROTECTED]* wrote: I went through most of the activities in the gcompris xo bundle and found that most work ok but a few have some problems: /computer/mouse/clickgame: couldin't find or load clickgame/sea1.jpg /fun/hexagon: couldn't find or load hexagon/strawberry.png /fun/anim: couldn't find or load skins/gartoon/boardicons/draw.svg /discovery/memory_group/memory: couldn't find or load memory/backcard.png /discovery/memory_group/memory_tux: couldn;t find or load memory/backcard.png /discovery/colors_group/advanced_colors: couldn;t find or load gcompris/timers/clock10.png -- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Teresa Selling Derry, NH -- Looking for last minute shopping deals? Find them fast with Yahoo! Search.http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ 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
Testing and Schedule update, Jan 7
Jan 7, 2008 This week we expect to finish testing on Ship2.2, with a few fixes as described in the USR (unscheduled software release), http://wiki.laptop.org/go/OLPC_SW-ECO_2. Update1, based on joyride, is the other focus for bug fixes and testing. Please use the Test Group Release Notes for a quick note as to whether a build (Ship2, Update1, or Joyride) is worthy of loading and testing: http://wiki.laptop.org/go/Test_Group_Release_Notes Here is the known meeting schedule for this week. If you would like to know more, please email the person in parens. (Sometimes meetings are not held each week): MONDAY: 1:00 pm EST, test meeting (Kim) 3:00 pm EST, multibattery charger mtg (Richard, Kim) TUESDAY: 1:00 pm EST (note the new time), Journal/datastore update (Kim) 1:30 pm EST, Tubes update (Kim) 4:00 pm EST, Security update (Michael Stone) 9:00 pm EST, SW Dev mtg - critical bug review (Jim, usually via IRC, olpc-meeting) WEDNESDAY: 11:30 am EST, Sugar/design mtg (Eben, Christian) 3:00 pm EST, School Server update (Wad) SUNDAY: 3:00 pm EST, content update (SJ), line2 4:00 pm EST, support update (Adam), line2 Most mtgs are on conf call: From the United States 866-213-2185 From Outside the United States 1-609-454-9914 line1: access code: 8069698 line2: access code: 1671650 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Login as root on 667
Marco, If this is the same issue that I just encountered in Joyride, then the login is now 'olpc' instead of 'root'. No password. Sudo should work (i believe). Kim On Dec 24, 2007 5:21 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, how do we login as root in the latest Update.1 image? There seem to be a password now and sudo is not installed. Marco ___ 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: Code freeze
Thanks for doing this work, Marco! I want to add an Update1 blocker, 5671, which is how to get a developer key. In the previous versions there was a link from the laptop to get a developer key (from the 'about your XO' in the browser)... I can't find that link in the most recent joyrides. Also, we need an Update1 release that includes a lot more stuff from joyride so we can be testing the update1 rather than Joyride. Jim - are there a bunch of things that should be in update1 that haven't moved from joyride yet? Do you think it will be possible to get an Update1 build this week with as much stuff from joyride as was slated to get in? Thanks, Kim On Dec 24, 2007 8:45 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, according to the roadmap we are now in code freeze for Update.1. I went through the Sugar core tickets and assigned to Retriage those I don't think it's worth or possible to fix for Update.1. Here are the remaining issues: http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarcomponent=browse-activitycomponent=journal-activitycomponent=datastorecomponent=presence-servicecomponent=read-activitycomponent=gtk-themeorder=prioritymilestone=Update.1col=idcol=summarycol=statuscol=ownercol=type Jim, Kim, I'm not sure how strong you want the freeze to be... Can you please go through the list (they are only 20 tickets) and make sure there aren't any you *don't* want to fix for Update.1? Thanks, Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Conf Call today for discussion of G1G1 Support, 2pm est
[Adam - can you check the email addresses for people? thanks] These minutes can be found here: http://wiki.laptop.org/go/Support_mtg Attending: Noah, Danny, Kate Davis, Adam Holt, Jim Gettys, Kim, Yani, Mary Lou, Ricardo, Chui-Yui, Rob (Marvell), Mitch, Don Hopkins From our main wiki page, there is a link in the text to help, wiki, and getting started (not currently on main page). Support wiki page: Provides lots of support options and community mailing lists Noah suggests that there is too much information on the Support pages. Kate suggests that we need to categorize the questions (how to get started, how to connect, how to work with activities). Which communities should newbies join? - [EMAIL PROTECTED] (look in lists.laptop.org) - irc.freenode.net, olpc-help It is recommended that we use the wiki FAQ for user-facing knowledge db; for both users and community support people to find their answers. There will be a discussion on community development on Wednesday afternoon - if you are interested contact Adam (holt at laptop.org). For IRC, we want to use olpc-help rather than olpc-support. We will be spread too thin to try and do both. We will ask our developers to help out here; but we don't want developers to be overwhelmed. The balancing act we have is that if developers are required to meet update1 goals AND answer a bunch of IRC questions. Probably need to delay update1. - Don Hopkins, Amsterdam (olpc netherlands user group) asked what he and his group can do to help. And provided some more questions that we should have answers for: - How can people get laptops in quantity; working with educational institutions; concrete proposals should probably be sent to walter at Laptop.org - How can you pay for 100+ laptops: contact the 'Give Many' program: [EMAIL PROTECTED], 800-379-7017 - How can I apply to the Developers program? http://wiki.laptop.org/go/Developers_Program Things that the Netherlands community could do would include making emulation/virtualization. -kim On Dec 17, 2007 12:37 PM, Kim Quirk [EMAIL PROTECTED] wrote: Now that we have G1G1 recipients we would like to discuss ways to help people get started and how to help answer all the questions that have begun to hit via [EMAIL PROTECTED], multiple IRC channels, forums, community-support, etc. Here are some ideas for agenda: * Groupings of people: by media and by expertise * How to find answers to questions * How to answer people (nicely) * How to handle unhappy people * How to use tools to create a knowledge base For calling in: From the United States 866-213-2185 From Outside the United States 1-609-454-9914 access code: 8069698 Thanks! (Note: there is no testing meeting at 1pm today) Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Conf Call today for discussion of G1G1 Support, 2pm est
Now that we have G1G1 recipients we would like to discuss ways to help people get started and how to help answer all the questions that have begun to hit via [EMAIL PROTECTED], multiple IRC channels, forums, community-support, etc. Here are some ideas for agenda: * Groupings of people: by media and by expertise * How to find answers to questions * How to answer people (nicely) * How to handle unhappy people * How to use tools to create a knowledge base For calling in: From the United States 866-213-2185 From Outside the United States 1-609-454-9914 access code: 8069698 Thanks! (Note: there is no testing meeting at 1pm today) Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WPA - testing
Michail, We have two other critical bug fixes that require us to do a build today and get it out asap. I had put the new firmware on that list to get into the new build, but we really have to understand if this bug is real. If you and Ricardo can look at this today (build is scheduled for 5pm), that would be great! Otherwise, I think the risk is too high to include 20.p47. Other thoughts? Kim On Dec 13, 2007 11:41 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Some people are experiencing problems with the latest joyride, looking like a firmware/kernel regression. See #5485. Marco ___ 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: wow, wireless go BOOM!
Elijah, Thanks for this information. It would be great if you can start a bug with all this info and then we can follow the suggested steps and results. Ricardo - can you add suggested tests for Elijah since this is an area you have spent a lot of your time recently :-) Thanks, Kim On Dec 10, 2007 7:39 PM, [EMAIL PROTECTED] wrote: today i updated my b4 to the latest firmware, then installed ship-2 via usb, then olpc-updated to the latest joyride build that i could find. [the impetus for the updates, today, beyond the RTC bug, was that the wireless on the B4 didn't seem to want to come on. Empty neighborhood screen, etc. There were some libertas error messages in the dmesg output, which were initially somewhat concerning. Now, I wish that I'd written them down. Oops.] a minute ago my ubuntu laptop (an aging dell inspiron 8200, with 802.11b truemobile mini-pci card, running 2.6.22...) started spewing error messages and the card began frequently resetting itself. LOTS of spewage. turning the b4 off seems to have eliminated the issue. huh. :-) possible complicating factors: My local network has a BUNCH of 802.11g devices on it. A d-link pci card, several different belkin and linksys usb dongles, etc. All talking to the one AP. And there are several, several, several APs RF-visible from here - typically 20-30, depending on which window of the house you happen to be closest to. There's also a B2-1 here, running 406.15, with very non-current-ish firmware on it. the AP to which the laptop and the B4 were both connected is a Netgear WGR614v6, running firmware V2.0.13_1.0.13NA. The B2-1 was disconnected and at a point where it would have liked for me to type in a WEP key. The AP is WEP, as there are several devices that don't do WPA and still need to work. This sounds a little bit like the reported WDS/frame/mesh scenarios that I've seen mentioned on a couple of occasions recently... but not exactly. I am happy to do further testing - and endure further possible crashes of my non-XO laptop - to help get this stable again. :-) --elijah ___ 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: boot failed after updating MP to joyride-357 (activation?)
One extra piece of info: Once you get a developers key, you should 'disable security' from the OK prompt. Then you can upgrade to any image. Here is a link to the wiki page with the process: http://wiki.laptop.org/go/Guide_to_Secure_Install Kim On 04 Dec 2007 10:36:21 -0500, Alexander M. Latham [EMAIL PROTECTED] wrote: --- Tomeu Vizoso wrote: Hi, After rebooting, a sad face appeared, 'BOOT FAILED' was written at the top left and under the laptop icon was a lock. Booting the alternate image (pressing the 'O' button while powering on) worked fine. What did I wrong? Thanks, Tomeu --- end of quote --- I'm guessing you were updateing from either 623 or 649, and that while your laptop has been activated, it is still secure. Secure laptops (having the write protect set) will only boot into signed images (i.e. the likely signed version of 623 or 649 that you had) None of the joyride builds are signed. If you want to run them, you need to turn security off on your laptop. To do this, Apply for a Developer Key. If you open the browser on 649, click on 'other' and then 'about your xo' At the very bottom of the page, there is a link to getting a developer key. Follow the instructions, and you should get a developer key in a day or two, depending on when cscott makes them. This will enable you to get to the ok prompt in open firmware, which means you can boot into any image you want. - AlexL ___ 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: What build should we be testing?
My suggestion is that people should test the joyride builds. At this point many bugs in ship2 have already been fixed in joyride. Be sure to include the build number and steps for reproduction in a bug report -- that helps alot! Thanks, Kim On Dec 1, 2007 5:41 PM, ffm [EMAIL PROTECTED] wrote: Should we be testing the Joyride or the ship.2 builds? -ffm ___ 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: Networking hangs
Please try Update1, build 641. The latest wireless firmware and kernel changes for the 4470 fix are in this build. Thanks, Kim On Nov 25, 2007 7:44 PM, Javier Cardona [EMAIL PROTECTED] wrote: Hi Hal, On 11/25/07, Hal Murray [EMAIL PROTECTED] wrote: After a while (1 to several hours), the network stops working. The mouse still works, at least until I try something that's too complicated. (...) Is this a known problem? If not, what should I do to get more info? ... This sounds like http://dev.laptop.org/ticket/4470 Javier ___ 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: wireless troubles, part 1: unencrypted AP
Pascal, We don't officially support WPA, as in we will not be working fixing issues associated with that until sometime after Dec1 (Update.1). The bug about not connecting to an AP, is actually been found to be multiple clicks when you hit the button on the touchpad. Not sure of the root cause for this bug... but if you use a USB mouse, you will not get the multiple click behavior and you will be able to connect to unencrypted and WEP enabled APs. I believe we will see many other problems with double instead of single clicking (liek with the WEP key enter box)... so I expect they will all be fixed at once with the double click fix. It might be worth waiting for the next release to file more bugs in this area... hopefully some of them will just go away. Kim On Nov 12, 2007 3:19 PM, Pascal Scheffers [EMAIL PROTECTED] wrote: No, I did not file a trac bug, yet. Apart from these two, I am also having trouble with my WPA network. It plain refuses to accept my key, I click OK and then nothing happens, and nothing special is seen in /var/log/messages either. The cancel button doesn't work either, only (repeatedly) clicking the 'x' button on the top-right of the dialog makes it go away... I've seen this for a while now, all the way back to joyride 20x Shall I file a bug for that too? Regards, - Pascal. On 12 nov 2007, at 20:51, Kim Quirk wrote: Did anyone write up a trac bug? Also, Please add quick notes for really broken things here: http://wiki.laptop.org/go/Test_Group_Release_Notes (and reference the bug. In this case it is a blocking bug for update.1) Alex - said he will log this bug... Thanks! Kim On Nov 12, 2007 2:37 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: On Mon, 2007-11-12 at 20:34 +0100, Pascal Scheffers wrote: I installed joyride-258 on my B4 with firmware Q2D04, and my wireless doesn't function anymore. Problem 1: I cannot connect to my completely open, unencrypted access point 'XO'. The AP is a Linksys BEFW11S4, other computers can and will connect to it. I can confirm this - I'm trying to connect to an ancient Dlink 802.11b router (completely open), and it is not working. Warm regards, Sayamindu -- Sayamindu Dasgupta http://sayamindu.randomink.org/ramblings ___ 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 262 test group results
Notes/major bugs on the 262 build can be found here: http://wiki.laptop.org/go/Test_Group_Release_Notes I don't believe we've been able to get through basic smoke with joyride or update.1 builds... until we do, it is probably good to use this page for bugs that have to addressed asap (blockers) and may keep others from testing. We are aiming to get something that makes it through the 1 hour regression test by the end of the week. Thanks! Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MP Build... FYI
John, It sounds like you recommend that Quanta put 624 on the laptops at the end of mfg test. Is that true? If so, I would support that decision as well; and we don't need to go through the release testing for 625. Regards, Kim On 11/4/07, John Watlington [EMAIL PROTECTED] wrote: There shouldn't be any problems if 624 is used for MP. The testing process is there for a reason, and should be strictly followed. The DCON bug that 625 fixes (#4479) will only show up on a small number of machines, and it's frequency is low enough in normal operation of our current software (where we only support sleep, not automatic suspend) that it will be an extremely rare complaint (roughly one tenth of the machines will show the problem once every 5-20K resumes --- that's a lot of button pushes!). When the display is powered down automatically for power conservation, the code path should reinitialize the DCON correctly. It is a low severity bug, the user hits any key and the problem clears up. RMA requests for machines showing this problem can be answered with a request that they upgrade their software. John On Nov 4, 2007, at 12:32 AM, Richard A. Smith wrote: Jim Gettys wrote: Ship.1 are the bits Quanta is currently putting on machines in the factory. It is Build 624; Firmware Q2D03. We are putting build 625 on mass production machines starting Monday, because this addresses a suspected bug, the failure to initialize the DCON registers when power is re-applied to DCON. Build 625 is in testing by Quanta right now. I just spoke with Arnold about the current 624/625 testing status. 624 testing was completed by Quanta and is ready to go. They were not able to start testing 625 because there was no signed image. Current plan is for 624 to go onto the machines. _If_ we claim that 625 are the new bits and sign them for use on MP machines then Quanta can start testing 625 on Monday morning. They _might_ be able to complete the testing in time for MP but Arnold says it will involve a lot of work from the .tw testing team. Gary and I will be headed to CSMC at 8pm Changshu time to look a the results of the 24 hour DCON test. I'll report back the results and then the team can make the call on going with 624 or trying to push for 625. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low-memory testing
This weekend I found that opening too many activities too quickly (I opened about 5 activities before waiting for them to each open); caused my machine to hang miserably. After about 20 minutes of absolutely no response, I held down the power button. There was no virtual terminal or dev teminal, the display was showing half of something it was trying to open, but nothing I could do would get a response. This might be CPU usage as oppose to memory corruption or leaks ... when I rebooted it did come up ok. Bug 4483. Kim On 10/28/07, Albert Cahalan [EMAIL PROTECTED] wrote: On 10/28/07, Jim Gettys [EMAIL PROTECTED] wrote: Albert, can you please see that there are proper trac entries fro any leaking applications? I made one, #4471, for the activity I am aware of. I'm concerned about worse things, like data corruption. Leaks and mere crashes are nothing in comparison. Running out of memory makes allocations fail. When that happens... Does JFFS2 corrupt itself? Reiserfs and ext3 have both suffered from this problem. Does the journal corrupt itself? I think it does, though I certainly don't have decent proof yet. Does a driver, in kernel or X, start a DMA to the wrong location in memory? (address 0, a previous allocation that has since been freed, or a clean page that was never locked down and just got discarded by memory pressure) BTW, there is also a need for power-loss testing. Do we get corruption if we interrupt etoys/squeak or the journal at a bad moment? Power loss will certainly happen. This could use an automated test rig. ___ 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: Monday Ship Mtg update message
Hi Yoshiki, The reason this has seemed fuzzy for a while is because the issues with the relatively new G1G1 program has brought up discussions about dates and how they might change. I think after today's discussion it has been finalized and unchanged from the First Deployment dates that have been in the roadmap for a few months now. https://dev.laptop.org/roadmap November 2, code freeze November 16, drop to quanta For individual activities we will always want people to be able to download from a website pretty much at any time, so further development and features to activities, should continue to be planned and released outside of the olpc schedule. We will stop taking bits for activities that are shipping on the laptop after November 2 (unless you make arrangements with Jim). Hope that helps. Kim On 10/25/07, Yoshiki Ohshima [EMAIL PROTECTED] wrote: Hi, Kim, I waited until somebody else asks this, but seems that I need to ask^^; How serious is the next deadline? While Etoys did create a new branch after Trial-3 deadline and development is going into the branch, not all our team members are comfortable with the tools enough to follow the joyride hourly builds and test our latest stuff on the actual B4 (and some of our new stuff is not in joyride yet for some reason). And for many developers with B4s, they probably install new build now and then, or stick to the stable builds and try other people's stuff now and then. And as I gather, there are reallly big changes underway. Now, even if the shipment of Trial-3 happens (it has not happened yet, right?) before the next code freeze date, the new code in the branch (not just Etoys' but everything else has similar issues I suppose) will not be tested well by many people, even ourselves, on B4. In this circumstance, how should we proceed? Should we proceed to push the changes to branch? Or is it a bad idea and it should be deferred? Thanks! -- Yoshiki At Mon, 22 Oct 2007 10:43:46 -0400, Kim Quirk wrote: Schedules: This is the last week of changes to the FRS, or Frist Deployment, code base. There are 70+ blocking bugs and over 230 high priority bugs. These should be the highest priority for most people who are helping out in both development and test. After this week, we will hand pick the bug fixes that will go into the build; and start shutting down the code churn. Please look through your bug list, including any other components that might be related to your bug list (sometimes they get put under the wrong component); and figure out what you believe to be the First Deployment show stoppers. Look at bugs that are assigned to the FRS milestone as well as those that have not been assigned or those that are untriaged. This is the code that our first deployment children in Uruguay will experience as well as those who are donating to the G1G1 program -- so we'd like to present the best user experience as possible. Meetings this week (please send me email if you need a call in number and don't have it): Monday 1pm EDT: Test meeting - where are we on the test sprint objectives; highest priority testing for this week Tuesday 12:00 (noon, EDT): Journal/datastore update, saving to the school server Tuesday 12:30 EDT: Tubes, presence, new mesh protocol, jabber servers Wednesday 11:30 EDT: Sugar UI (This might not be the correct time...Christian or Eben will send out time) Wednesday 4:00 pm EDT: Security update (NOTE the change of day) We may need a meeting on connectivity issues (to continue from where we left off with Marvell and Cozybits last week) We may need a meeting dedicated to school server integration We are coming down to the last few weeks. Thanks for everyone's focus and dedication to these difficult details. - Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Presence service bugs/enhancements
Thanks for putting these all together, Yani. Dafydd and Simon - can we discuss these and the new mesh protocol at the 12:30pm edt meeting today? I think some of these issues are supposed to be addressed with the more robust protocol. Thanks, Kim On 10/23/07, Giannis Galanis [EMAIL PROTECTED] wrote: Simon, The following are the current bugs/enhancements regarding the presence service. They are listed from high to low priority with their corresponding trac number. 1. The presence service should detect more efficiently the internet connectivity and switch to gabble when appropriate(4193) 2. In link-local XOs are seen in neighbor view but cannot be shared with. Sometimes they are not connected to the mesh anymore, but still present. In some such cases the avahi-browse cannot resolve the services of the corresponding XO. This is high priority but i dont have a log file in a blocking case, although i have experienced it in build617(4402) 3. Ability to switch from gabble to salut manually using the options: auto,salut,gabble(4403) 4. Ability to keep an activity alive when passing from salut to gabble and vice versa. This can occur automatically when internet connectivity is dynamically lost or recovered(4404) 5. In gabble, the public IP must be available in the buddy list, or at least be accessible through the jabber server upon request(4405) 6. The jabber servers should be switchable(to change from one to the other) in a neater way then accessing the config file and rebooting. This can probably be invoked by sending smth like ..xmlns:stream= http://etherx.jabber.org/streams; to=jabber.laptop.orgas i noticed in the log files. If it is simple to apply, can you describe how it can be done properly?(not on trac) Thanx yani ___ 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
