Re: [OLPC-AU] Determining developer lock status
On Thu, 2011-03-10 at 15:22 +1100, James Cameron wrote: > On Thu, Mar 10, 2011 at 03:06:10PM +1100, Sridhar Dhanapalan wrote: > > We find this to be a bit hit-and-miss - sometimes the prompt shows and > > sometimes it doesn't. I normally turn on the XO while either holding > > down the Esc key or tapping it repeatedly. Is there something more > > reliable? I am trying to get a remote (non-technical) teacher to do > > this, so it needs to be easy. > > See http://wiki.laptop.org/go/Ok for my standard answer. > > > I forgot to mention another thing - this is for XO-1.1s (XO-1s with an > > XO-1.5 style trackpad). > > We don't use the term XO-1.1, sorry. Please don't introduce it. > > The expert method (holding down the escape key while turning on the > laptop) works fine for me when I test with this type of laptop, on > Q2E45. The expert method won't work in some cases though because it > conflicts with the data stream between the firmware and the keyboard > during the critical discovery phase. > I like to hold down the check key when booting, then when prompted to release, hit the escape key. I just do that out of habit now, like to watch the scrolling text of the boot sequence. > With Q2E45, a USB keyboard can also be used to obtain the Ok prompt, > but it takes an extra moment after the startup sound begins. > > You might also attempt to boot from USB. If it does not boot an > unsigned image, then it is probably secure. > > You might also check the manufacturing tags using the Terminal activity, > but you did ask for simplest, and you didn't say anything initially > about your hit-and-miss experience. > >From a terminal 'ls /ofw/mfg-data' look for 'ww' for unlocked boxes, if missing or 'wp' is present, then it's locked. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Determining developer lock status
On 10 March 2011 04:06, Sridhar Dhanapalan wrote: > We find this to be a bit hit-and-miss - sometimes the prompt shows and > sometimes it doesn't. This can happen on some laptop models if you press esc too early. Wait for the sound, then press it. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[ANNOUNCE] XOpup-2.1
XOpup-2.1, puppy linux for the XO-1 and XO-1.5 is released It includes on the latest 2.6.35 kernel and chrome driver from the OLPC git. Thanks to the replacement of wxCam with Guvcview, that works much better, is now only 88MB. It also includes a first attempt of a Spanish language pack. See the full announcement here: http://ftp.cc.uoc.gr/mirrors/linux/XOpup/Announce_XOpup-2.1.html and changes from XOpup-2.0 here: http://ftp.cc.uoc.gr/mirrors/linux/XOpup/Docs/changelog.html#2.1 On a related note, we would really like to port Sugar to Puppylinux, but the list of dependencies is really huge (with puppy standards). Did anyone tried to see what is the minimal set of dependencies, compile statically, trimmed library features to the minimum required, etc? I can understand that this may not be the appropriate practice, but I was wondering if there are any behind the scenes attempts, just for kicks ;) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Lego WeDo + TurtleArt - Screenshot & Code!
On Wed, Mar 9, 2011 at 9:19 PM, Ian Daniher wrote: > Hi All! > I'm writing with good news. I successfully have integrated the Lego WeDo > with TurtleArt. > Here's a screenshot: http://itdnhr.com/static/WeDoScreen.png > The code needed can be found in my git repo > at https://github.com/itdaniher/WeDoMore/. > TurtleArt specific files can be found > at https://github.com/itdaniher/WeDoMore/tree/master/TurtleArt. > The svg files go in the "icons" folder. > The "usb" folder goes in the root of the TurtleArt directory. > The file "wedo_plugin.py" goes in the plugins folder in the TurtleArt > directory. > The folder "WeDoMore" goes in the root of the TurtleArt directory. > This project is not ready for primetime yet. The only semipolished code is > the actual Python WeDoMore library. Anything and everything in my repo that > is related to turtleart should be considered 'alpha,' that is, may cause > your computer to spontaneously burst into flames. That being said, it works > perfectly for me, and I could definitely use testers. > If you feel like giving it a go, and if you find any bugs, please report > them at https://github.com/itdaniher/WeDoMore/issues. > Best wishes and many thanks, The first pass at documentation for the plugin code is here: http://wiki.sugarlabs.org/go/Activities/TurtleArt/Plugins Just a beginning, but hopefully of some use. -walter > -- > Ian > On Wed, Mar 9, 2011 at 13:17, Martin Langhoff > wrote: >> >> Hi Ian! >> >> great to have you around! I am interested in your work with WeDo, both >> the python plugin, and the TA integration. >> >> For the NXT integration, the parts are >> >> 1 - an rpm that has the udev rules >> 2 - an rpm with nxt_python (python library, some utilities) >> 3 - a TA plugin >> >> In your case, we'll probably want to use the same model for packaging. >> The rpm with the udev rules already has rules for wedo. Once your >> library code is ready for release, let me know and I'll look into >> making an rpm. >> >> For the TA plugin it may be a good idea to share notes with Emiliano >> -- he's doing the NXT stuff. The TA plugin will probably be shipped >> with TA once ready. >> >> If you can keep those tiers separate, it will be a big win. Have you >> seen the nxt_python library API? If yours is reasonably close you >> might save some effort. >> >> >> >> m >> -- >> martin.langh...@gmail.com >> mar...@laptop.org -- Software Architect - OLPC >> - ask interesting questions >> - don't get distracted with shiny stuff - working code first >> - http://wiki.laptop.org/go/User:Martinlanghoff > > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.1 differences
While more testing is good, I would point out that Jon's frankenstein machine is much more different from the hardware you will be installing onto than the original XO-1 (CL1). The ONLY differences between the CL1A and CL1 laptops is the single-mode capacitive touchpad instead of the dual mode resistive/capacitive one. Regards, wad On Mar 10, 2011, at 1:26 AM, Sridhar Dhanapalan wrote: > On 10 March 2011 15:15, Jon Nettleton wrote: >> On Wed, Mar 9, 2011 at 8:09 PM, Sridhar Dhanapalan >> wrote: >>> A year ago, we deployed about 200 XO-1.1 machines in a community. I'm >>> not sure if that version number is official, but it's what we call >>> XO-1s with XO-1.5 style capacitive trackpads. >>> >>> I am going to that community in a couple of weeks to upgrade them to >>> the latest OS build. I only have the standard XO-1s available to me >>> for testing. Is there anything peculiar that I need to know about the >>> XO-1.1s that will affect development and testing? >> >> I would not say that is an official XO-1.1, but I have replaced my >> XO1's base with one from my alpha board XO 1.5. I think the end >> result is basically what you are describing. The hardware designers >> would probably know if the hardware is an exact match. >> >> If you let me know which build you plan on installing, I can test for you. > > Hi Jon, > > Thanks for your offer! The latest build of the release we are developing is > at: > > http://download.laptop.org.au/XO/F11/10.1.3/XO-1/au2-rc2/ > > Cheers, > Sridhar > ___ > 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: XO-1.1 differences
On Thu, Mar 10, 2011 at 7:57 AM, John Watlington wrote: > > While more testing is good, I would point out that Jon's frankenstein > machine is much more different from the hardware you > will be installing onto than the original XO-1 (CL1). > > The ONLY differences between the CL1A and CL1 laptops is the > single-mode capacitive touchpad instead of the dual mode > resistive/capacitive one. > As I figured, my hardware modifications were not exactly the same as the production ones. Even so I will report back that I was able to install and run the requested image on my "frankenstein" XO1 with an XO 1.5 keyboard and mouse. Sridhar I hope that gives you a bit more confidence in your upgrade path. Good luck. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-AU] Determining developer lock status
> I'm still awaiting feedback from the school (getting information out > of remote schools is often hard). I'm trying to ascertain whether > their CL1As are developer locked. According to the production info on your SKU (SKU 67) all your CL1As where shipped unlocked. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Load testing the XS school server
Benjamin Tran (one of my students) has been working on his Masters thesis for over a year, load testing different hardware configurations running XS 0.6 school server. He defended his thesis successfully and his work is now up on the OLPC wiki. http://wiki.laptop.org/go/XS_Load_Testing The platforms tested were: XS-on-XO1 FitPC FitPC2 OLPCorps SolidLogic Generic PC Dell Precision 670 dual Xeon workstation w/4GB RAM Note that the work has certain limitations based on his thesis requirements and the data available from the field. Both Ben and I are happy to continue the work beyond his thesis effort. cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor, Information Systems Director, Campus Business Solutions San Francisco State University http://verma.sfsu.edu/ http://opensource.sfsu.edu/ http://cbs.sfsu.edu/ http://is.sfsu.edu/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os-builder: could we roll a 1.3.1?
On 3 March 2011 22:21, Martin Langhoff wrote:
> - Very clearly, the changes I am proposing do _not_ affect the build
> of 10.1.3 -- they don't change the .ks file prep, or anything after. I
> am happy to run test to verify
Sorry for the delayed response, I haven't had much OLPC time this week :(
I agree that all your changes are safe. I was just worried about the
general idea of allowing further commits after a released build. But
this is not the first time I have come across the kind of thing you
have identified.
So I'm thinking we should agree and document that small, safe changes
can be made (as long as its clear that the default configuration
builds won't be affected at all), and switch the wiki to recommending
version (e.g.) "1.3" for 10.1.3, rather than specifying the exact
version 1.3.0. It is then clear that the official OLPC OS release was
built using the x.x.0 version, but the wiki would suggest that users
and deployments go for the newer one (1.3.1) allowing for fixes like
the ones you have identified, without worry that the default build
output would change.
what do you think about the attached change?
diff --git a/doc/README.devel b/doc/README.devel
index 3b2d456..5cb3c9b 100644
--- a/doc/README.devel
+++ b/doc/README.devel
@@ -265,8 +265,8 @@ When releasing an official OLPC OS build, you should do the
following:
- Make and test the build
(assuming test success...)
- Bump olpc-os-builder version number
- - Modify config to set suggested_oob_version in [base] to the new version
- number
+ - Modify config to set suggested_oob_version in [base] to the first two
+ components of the new version number (e.g. 1.3)
- Delete [base].official setting from config
- Save config in examples/ directory with appropriate name
- Tag and release new olpc-os-builder
@@ -283,3 +283,43 @@ was made. If deployments try to replicate the same build
but use a different
oob version with different module code, then they will end up with the
undesirable result of an OS build that is somewhat different from the official.
+
+== VERSION NUMBERS ==
+
+The olpc-os-builder version number has 3 components, e.g. v1.2.3
+
+The first component relates to the version of Fedora the tool works with.
+It must be incremented every time the tool is modified to produce builds based
+on a new version of Fedora.
+
+The second component refers to the minor release of the official OLPC OS
+release that the tool was used to build. It must be incremented when starting
+work on a new minor release. For example, v1.2.0 was used to build
+OLPC OS 10.1.2, this was incremented to v1.3.0 when development started on OLPC
+OS 10.1.3.
+
+The third version component starts at 0 for a given OLPC OS release. The
+official OLPC OS release is always made with 0 as the third component
+(e.g. v1.3.0). If new versions of olpc-os-builder are released that still
+build the same OLPC OS release, this number gets incremented (see below for
+more information).
+
+
+== CODE FREEZES ==
+
+By definition, OLPC OS releases are always made with olpc-os-builder releases
+that have 0 as the 3rd version component (e.g. v1.3.0). As an aim of the tool
+is to allow for exact reconstruction of OLPC OS releases into the future,
+the branch where this olpc-os-builder was made automatically goes into a code
+freeze.
+
+In this frozen state, further commits can be made, but only for small patches
+which undoubtedly do not affect the build output when the standard OLPC OS
+configuration is used. The equivalent functionality or fixes must already be
+present in the master branch. If there is any doubt as to whether the change
+would affect the standard build output, it is not applied.
+
+Examples of commits that are permitted are fixes to bugs that prevented the
+build tool from running at all under certain environments, small changes to
+modules not used by the official OLPC OS configuration, etc.
+
diff --git a/osbuilder.py b/osbuilder.py
index b8ee3cb..ef5bac8 100755
--- a/osbuilder.py
+++ b/osbuilder.py
@@ -289,10 +289,10 @@ class OsBuilder(object):
if self.cfg.has_option('global', 'suggested_oob_version'):
suggested = self.cfg.get('global','suggested_oob_version')
-if suggested != VERSION:
+if self.suggested_mismatch(suggested):
print
print "WARNING: The build configuration you are using suggests
that"
-print "olpc-os-builder version v%s should be used." % suggested
+print "olpc-os-builder version v%s.x should be used." %
suggested
print
print "You are using v%s" % VERSION
print
@@ -317,6 +317,11 @@ class OsBuilder(object):
self.read_config()
+def suggested_mismatch(self, suggested_version):
+# we only compare the first two version components
+current_version = VERSION.rsplit('.', 2)[0]
+return current_version != suggested_version
+
def get_ks
Re: [OLPC-AU] Determining developer lock status
On Thu, Mar 10, 2011 at 06:13:04PM +1100, Sridhar Dhanapalan wrote: > I was out there a year ago to assist in the initial deployment, but at > the time I was quite green and so didn't know what to look for. I do > remember that we used NANDblaster clone an installation from one of > our own CL1 XO-1s to the school's CL1As (turning each on while holding > the four game keys). Would that be an indication that they are not > locked? Yes. The only NANDblaster function that will work to a secure laptop is nb-secure [1]. nb-clone (which is what you did) requires an non-secure target laptop set. Otherwise the security system would be bypassed. On using the four game keys ... This works for both secure and non-secure systems. If the system is secure, the sender must be sending a signed image; otherwise the receiver will stop before writing to it NAND, saying "Placement spec bad signature!". [2] 1. http://wiki.laptop.org/go/Nandblaster_for_XO-1#NANDblasting_a_Signed_NAND_Image_File 2. http://wiki.laptop.org/go/Nandblaster_for_XO-1#..._with_Game_Buttons -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os-builder: could we roll a 1.3.1?
On Thu, Mar 10, 2011 at 3:56 PM, Daniel Drake wrote: > Sorry for the delayed response, I haven't had much OLPC time this week :( np - we're all busy! > I agree that all your changes are safe. I was just worried about the > general idea of allowing further commits after a released build. But > this is not the first time I have come across the kind of thing you > have identified. That's completely understood, and I meant to stay the heck away from any risky changes. We're on the same page -- your changes read very sane to me. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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
Re: Memory replacement
On 10 March 2011 05:51, Paul Fox wrote: > kevin wrote: > > and having my anti-static wrist guard properly attached - advice please: > go, > > no-go, spend the extra pennies and get a Class 4/6/8/10. All I know for > > sure is the 2GiB card in there has to be replaced. There are progressively > > if you're using the machine a lot, and you have the pennies, the difference > a faster card makes will be noticeable. I assume that this is just for personal use and not for deployment. A few months ago I enquired about the possibility of getting Class 6 cards in our deployment XOs, and was informed that none of the Class 6 cards tested could pass reliability tests. That sort of thing becomes critical if you want the XO to last for five years in the field. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Memory replacement
On Mar 9, 2011, at 2:23 PM, Arnd Bergmann wrote: > On Wednesday 09 March 2011 17:31:24 Kevin Gordon wrote: >> go, no-go, spend the extra pennies and get a Class 4/6/8/10 > > Note that Class 8 does not exist (except fakes) and class 10 is > usually not faster than class 6 if you run ext3 on it. > > Also, a Sandisk card is usually faster than a card from > most other manufacturers even if they are one class faster > nominally. I'll call BS on that claim. Sandisk cards are all over the map, depending on the controller used internally.Please understand that these manufacturers change controllers all the time --- tests results from nine months ago are invalid. > See > https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey > for a list of many cards. Go for a brand that has a larger > number of open segments. Also make sure that the partition > is aligned to 4 MB, otherwise you waste half the performance > and expected life. We align our images to 8 MB boundaries, as 4MB isn't enough for some cards. Since fs-update installs the partition table as well as the partition images, this happens automatically. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Review of sound card photogates
An interesting paper on arXiv ... http://arxiv.org/abs/1103.1760 - shows various photogate sensor designs for attachment to microphone inputs, - describes variations in how microphone inputs on sound cards are wired, - points out some of the value of purpose-built software as opposed to use of common tools like Audacity. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-AU] Determining developer lock status
On 11 March 2011 06:02, Richard Smith wrote: >> I'm still awaiting feedback from the school (getting information out >> of remote schools is often hard). I'm trying to ascertain whether >> their CL1As are developer locked. > > According to the production info on your SKU (SKU 67) all your CL1As > where shipped unlocked. Thanks everyone. I've just confirmed with the school that they have SKU 67, and that they are not developer locked. *sigh of relief* Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.1 differences
On 11 March 2011 04:22, Jon Nettleton wrote: > On Thu, Mar 10, 2011 at 7:57 AM, John Watlington wrote: >> >> While more testing is good, I would point out that Jon's frankenstein >> machine is much more different from the hardware you >> will be installing onto than the original XO-1 (CL1). >> >> The ONLY differences between the CL1A and CL1 laptops is the >> single-mode capacitive touchpad instead of the dual mode >> resistive/capacitive one. >> > > As I figured, my hardware modifications were not exactly the same as > the production ones. Even so I will report back that I was able to > install and run the requested image on my "frankenstein" XO1 with an > XO 1.5 keyboard and mouse. > > Sridhar I hope that gives you a bit more confidence in your upgrade > path. Good luck. Thanks for that, Jon. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
