Re: [Server-devel] [UKids] XO-1 classrooms don't reliably connect to many/most Wifi AP's
I've seen XO-1s randomly drop off the AP in Paraguay. I *think* we solved it by disabling 802.11s (the mesh network). This can be done at boot time by setting a parameter of the libertas kernel module. Sorry for being vague, it's been a long time ago. On 02/07/2014 10:10 AM, Adam Holt wrote: /[Terry Gillett summarizes his weeks of testing, ///with this very revealing report below/. That's tgill...@gmail.com mailto:tgill...@gmail.com of the Village Telco project: can we/Nepal/Lesotho/others help him add the key takeaways to http://wiki.laptop.org/go/Wifi_Connectivity so the almost 2 million XO-1s worldwide can benefit? Spoiler Alert: XO-1 deployments must carefully buy the correct Wifi Access Point, EG Linksys WRT54GL or Billion 7404VGP appear to solve most all problems. Likewise we've had a lot of success in Haiti with the TP-Link TL-MR3020.]/ SUMMARY The core problem is that XO-1 laptops will not reliably connect to a range of wifi Access Points (AP). By comparison, XO-1.5 and later laptops will successfully connect to the same APs. The behaviour of a group of XO-1s is different from that when they are tested individually. A single XO-1 may connect quite reliably, but when used in a group of ten or more, many individual XO-1s will fail to connect to the AP. Note that this issue is just about connecting to the AP, it is not about whether the AP can sustain a large number of connections or handle the associated data throughput requirements. A number of routers configured as APs have been tested to establish a baseline. The test process used requires 10 XO-1 laptops and is as follows: 1. Set up the AP on an unoccupied wifi channel, at least two and preferably three channels away from unoccupied channels. 2. Connect each XO-1 individually to the AP and check that it is operating correctly and has adequate signal strength. 3. Power off all the XOs 4. Start up one XO and allow it to connect successfully. 5. Start up the other none XOs 6. When the last XO has completed its boot up sequence, check the connection status of each XO. The result of a connection test for each XO is one of the following: 1. Successful automatic connection 2. No connection, but AP icon shows in Network Neighbourhood (NN) window 3. The AP icon does not appear. Typically there will be a mix of XOs in each of the three states. A Pass requires that all ten XO-1s are successfully connected at the end of the test without manual intervention. The proportion of XOs in each state will typically vary from 20 to 80% in a Failed test. The proportion of successful connections seems to vary by router type, but changes in repeated tests. Individual XOs will typically be in different states in repeated tests. A range of routers has been tested with this procedure and the results appear in the table below. The only two routers that passed the test were the Billion and the Linksys. Interestingly both these routers date from the same vintage as the XO-1. Note that testing with less than five XO-1s results in a much greater likelihood of a Pass result, and if the same AP is tested with ten XO-1s it will likely fail. A Pass result with ten XO-1s is considered (at this point) to be a reasonable indication of likely success in a real world deployment with greater numbers of XOs. The working hypothesis is that modern APs have implemented the wifi specs and/or default configurations in a way that has resulted in an interoperability problem with the wifi implementation in the XO-1. ROUTER TEST RESULTS Billion 7404VGP(old, Star Int, proprietary OS) Pass Linksys WRT54GL (old, Broadcom, DD-WRT) Pass Netgear FWG114P (old, proprietary OS) Fail TP Link WR710n (new, proprietary OS) Fail TP Link WR703(Atheros AR9331, OpenWrt) Fail TP Link WR842 (Atheros AR9287, OpenWrt) Fail TP Link MR3020 (Atheros AR9330, OpenWrt) Fail TP Link WDR4300(Atheros AR9341, OpenWrt) Fail VT MP01 (Atheros AR23xx, OpenWrt) Fail VT MP02 (Atheros AR9331, OpenWrt) Fail -- Unsung Heroes of OLPC, interviewed live @ http://unleashkids.org ! -- Unsung Heroes of OLPC, interviewed live @ http://unleashkids.org ! --- You received this message because you are subscribed to the Google Groups Unleash Kids group. To unsubscribe from this group and stop receiving emails from it, send an email to unleashkids+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- _ // Bernie Innocenti \X/ http://codewiz.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Policy for non-responsive maintainers
Is this a good time to re-spin the discussion? Considering that it keeps coming up: lionaneesh-andro bernie: Could you help me takeover maintainership of an inactive activity? bernie lionaneesh-andro: ask alsroot, he maintains aslo * alsroot only maintains aslo, dirakx was taking care about aslo content bernie lionaneesh-andro: gonzalo_odiard and garycmartin are the activity team coordinators. bernie lionaneesh-andro: there's currently no written process for taking over an unmaintained activity. maybe ask them for permission first? bernie lionaneesh-andro: please, write to sugar-devel@ and cc me, alsroot, gonzalo and gary. lionaneesh-andro bernie: okay. Thanks. On Wed, 2012-10-31 at 19:04 -0400, Bernie Innocenti wrote: On Wed, 2012-10-31 at 14:27 -0300, Gonzalo Odiard wrote: If you are not in a hurry to get this discussed, I propose wait until we finish we 0.98 (one month aprox) Right now, all the people we want be involved in this discussion, are too busy (me too). There's no particular hurry. Actually, I brought up this particular issue just to make a more general point: we should codify our existing practices in the wiki for the benefit of new and existing contributors. Being swamped by an unclear process can be quite frustrating for a volunteer who just wants to get things done. About the summer young hackaton in Uruguay, I take your word. Glad to help, although it's unlikely that I'll be able to join in. -- _ // Bernie Innocenti \X/ http://codewiz.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Policy for non-responsive maintainers
On Thu, 2013-01-10 at 16:37 -0300, Gonzalo Odiard wrote: Adding permission in ASLO is easy.In GIT is not so easy, maybe only Bernie and Alsroot have permission? Is true we can create a cloned repo, but that have more problems. We need point pootle to the new repo (and we had this problem a lot in the past), and can be difficult finally know where is the last code. The version of Gitorious that we're running did not come with a web interface to perform administrative tasks. I wrote a bunch of SQL queries to change owners for projects and repositories. Later on, Aleksey figured out how to manipulate the database from an interactive Ruby prompt. Slightly cleaner, but still into the sysadmin realm: http://wiki.sugarlabs.org/go/Service/git Looking forward, Aleksey and I have planned to rebuild the VM from scratch and install the latest Gitorious. Migrating the data may turn out to be difficult and at this point I'm not even sure whether the latest code comes with a robust admin interface similar to ASLO. For the time being, please ask alsroot. If he's unavailable, I'll try to do it. We'd also like to invest some time traning new volunteers for the Infrastructure Team, but since the learning curve is a little steep I'm asking in exchange for a bit of commitment to help maintain the service and respond to emergencies: http://wiki.sugarlabs.org/go/Infrastructure_Team/Getting_Involved -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Policy for non-responsive maintainers
On Wed, 2012-10-31 at 14:27 -0300, Gonzalo Odiard wrote: If you are not in a hurry to get this discussed, I propose wait until we finish we 0.98 (one month aprox) Right now, all the people we want be involved in this discussion, are too busy (me too). There's no particular hurry. Actually, I brought up this particular issue just to make a more general point: we should codify our existing practices in the wiki for the benefit of new and existing contributors. Being swamped by an unclear process can be quite frustrating for a volunteer who just wants to get things done. About the summer young hackaton in Uruguay, I take your word. Glad to help, although it's unlikely that I'll be able to join in. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Thu, 2011-12-22 at 11:32 +1100, Sridhar Dhanapalan wrote: That's exactly the feedback I was looking for, thanks. That's a UI bug in Sugar. I would strongly prefer the Sugar environment to behave more like Android, where any app/activity that is in the bg may get an instruction from the shell / OS to cleanup and exit. Good that we're on the same wavelength - I had a similar thought! The annoying thing about Android, however, is that for an app to continue to work in the background it needs to be coded in that way. I suppose that if we were to treat Sugar as an 'appliance' UI (which is how I tend to think about it), this isn't such a bad idea. An additional problem is startup time. Python code tends to be a lot slower to load and initialize than compiled Java bytecode. Anyway, closing an activity automatically when memory is short would still be preferable to the current behavior of trashing the VM until the OOM kicks in. A quick hack would be to limit the number of activities that can run simultaneously. I agree. How about 4? Seems sufficient for most productive workloads. Our next OS will likely have the Dextrose resource monitor [1]. I don't think we should be expecting children to be managing their system resources, though. It should 'just work'. That was an attempt to make users more aware of the physical limits of the system rather than make the system itself smarter. An unexpected consequence reported from Uruguay is that some children would open plenty of activities *intentionally* because it's fun to see the laptop cry! Well, I guess it means that the concepts of memory and CPU weren't too hard to grasp after all. Better not give them any pets, though. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Thu, 2011-12-22 at 08:10 +0530, Anish Mangal wrote: Its interesting. Uy dropped it. Py loves it. One change that does need to happen is replace the 'Cry [ :'( ]' icon with a 'Tired' one [ :'S ] . I won't say anymore than this here, there have been LONG *excited* discussions on the merit and design of this :-) Changes that affect the user experience are controversial by their nature. Ideally, one would like to decide based on objective data, but usability studies have a tendency to be costly and inconclusive. -- _ // Bernie Innocenti \X/ http://codewiz.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] ejabberd eats up 100% cpu time when it should be idle
Context: bernie alsroot: beam on jita is eating up cputime :-((( bernie alsroot: are we already running the latest version with all the patches? martin_xsa says he has fixed some bugs in the fedora 14 rpm. alsroot bernie: yup, this is fedora packages. also ejabberd /var is being recreated to the initial state every day bernie alsroot: we should tell this to martin_xsa alsroot bernie: thats why I was for something else for school server bernie alsroot: me too... my experience with ejabberd has been terrible so far. but let's ask martin first... he seems confident that it can be made to behave well. bernie alsroot: i'll forward this conversation to him This is ejabberd-2.1.6-4.fc14.x86_64 from Feb 24 2011. Is there a newer release, perhaps? -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Dextrose] Regarding my OLPC XS Wishlist
On Thu, 2011-06-02 at 11:57 -0400, Martin Langhoff wrote: On Thu, Jun 2, 2011 at 11:56 AM, Aleksey Lim alsr...@activitycentral.org wrote: Have you spent any time learning how to configure ejabberd? Diagnosing your problem? Discussing it on the ejabberd mailing list? Well, I assume OLPC people did it many times before me, I just reused their experience tryinhg to follow wiki.l.o docs and using native packages from fedora. Yes -- everytime we saw a perf problem we diagnosed. Right now we don't see performance problems when load testing the XS. What's the exact binary package of ejabberd and configuration that works well? How many users has it been tested with? I've had similar an experience similar to Aleksey with all versions of the ejabberd I tried, and so did the Collabora people I spoke with. I tried tweaking the configuration a bit, but the impression I got is that ejabberd is over-engineered for our needs (only 1 server, about 1000 users). If you see perf problems in your specific setup, I can only suggest you diagnose -- perhaps with the help from the ejabberd developers via their mailing list. Thanks. Send me your public ssh key, I'll give you access to the machine hosting jabber.sugarlabs.org. If you make it work, I'll buy you a green beer at EduJam 2012 :-) -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: 11.3.0 build 8 released, for XO-1.75, XO-1.5 and XO-1
On Sun, 2011-10-02 at 23:10 +0100, Peter Robinson wrote: Yes, I discovered this week we don't ship any form of ntpdate or means of setting the hw clock via ntp with the XO releases, This was discussed a few months ago on sugar-devel. There's a concern that NTP could be abused to reset the system clock of stolen laptops back in time, thus preventing the expiration of an existing activation lease. Of course, one could also use the date command and hwclock to do the same effect, so the extra precaution of disabling ntp really only makes sense for deployments that take away root access. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing OLPC OS 11.2.0 for XO-1 and XO-1.5
On Mon, 2011-07-25 at 10:50 -0400, Martin Langhoff wrote: On Fri, Jul 22, 2011 at 4:32 PM, Daniel Drake d...@laptop.org wrote: We're pleased to announce the release of OLPC OS 11.2.0 for XO-1 and XO-1.5. Details of new features, known issues, and how to Bravo! I was bottled up in a plane right at the time of the release, so I couldn't really celebrate as it deserves. This release is a major milestone -- it is very usable for existing users (with some limitations - see the release notes), it puts us in sync with the latest Sugar code, and it gets us on track for XO-1.75 . It also incorporates bugfixes and features from new contributors. Happy happy. Even though I haven't had a chance to test it 11.2.0 yet, I'd like to join the choir of kudos. Thanks to all contributors for their hard work! -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Support for Firefox 3.5 is ending
On Sun, 2011-06-05 at 15:50 +1000, Sridhar Dhanapalan wrote: (sorry - sending again because I had the wrong address for the olpc devel list) Firefox 3.5 is being EOLed by Mozilla[0] and Google is dropping support for it[1]. In 10.1.3 this is default Web browser in GNOME and the backend of the Browse activity, so we should be thinking of what that means for us. The plan for Australia is to have a Fedora 14 build (based on DX12) ready by January. F14 comes with Firefox 3.6, which is the oldest version supported by Mozilla and Google. What would be even better is to have Firefox 4 available. By January, Firefox 3.6 will be quite old and close to EOL. Firefox 4 is a fair bit faster than 3.6, allowing us to squeeze extra performance out of our XOs. There is a yum repository for F14[2]. I use this on my F14 work machine (albeit in x86_64), and I've had no problem. Browse continues to work in Sugar. Are there any thoughts/plans about including Firefox 4 in the OLPC/DX OS? There was some discussion at EduJam. Browse is currently unmaintained, but Simon Schampijer and Gonzalo Odiard expressed interest in working on it. There was the question of missing support for the Python bindings of GtkMozEmbed, but the problem appears to be solved now. In the longer term, there's also the option of switching to Surf, an alternative browser based on WebKit which promises to be faster and less memory hungry than Browse. This depends on Lucian Branescu (or someone else) resuming the work on it. Migrating to Surf wasn't feasible with Fedora 11 because too many of WebKitGtk's dependencies were missing. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [Dextrose] Support for Firefox 3.5 is ending
(hey, is the clock of your computer set correctly? your message appears to be one day old!) On Sat, 2011-06-04 at 20:37 -0400, David Farning wrote: There was some discussion at EduJam. Browse is currently unmaintained, but Simon Schampijer and Gonzalo Odiard expressed interest in working on it. There was the question of missing support for the Python bindings of GtkMozEmbed, but the problem appears to be solved now. What is the solution? Ubuntu Natty ships a new version of python-gtkmozembed, which is based on xulrunner 2.0. Fedora 15 also has xulrunner 2.0, with Python bindings. Fedora 14 is still shipping xulrunner 1.9.2, which is roughly equivalent to the version used by Firefox 3.6. Backporting things from Fedora 15 is going to be a royal pain in the ass, since they have switched everything to Gnome 3. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Support for Firefox 3.5 is ending
On Sun, 2011-06-05 at 17:42 +1000, Sridhar Dhanapalan wrote: On 5 June 2011 17:02, Bernie Innocenti ber...@sugarlabs.org wrote: Fedora 14 is still shipping xulrunner 1.9.2, which is roughly equivalent to the version used by Firefox 3.6. Backporting things from Fedora 15 is going to be a royal pain in the ass, since they have switched everything to Gnome 3. Does that mean that with FF4 installed, Browse is still working because it is (equivalently) using FF3.6 as the backend? Would that mean that if we were to upgrade to FF4, we would have a disparity in rendering between GNOME and Sugar? Yes. Since version 3.5 (iirc), Firefox comes with its own forked version of xulrunner. The system-wide copy of xulrunner is distinct from the one bundled with the Firefox package. Same for nspr (the Netscape portable runtime) and nss (the netscape SSL implementation). And if you happen to use Thunderbird, you've even got a third copy of all these libraries in your system. Following the best traditions of Windows applications, Firefox and Thunderbird will store passwords, proxy settings and file associations in two different locations. Seeing this, the Chromium developers promptly reacted by bundling a dozen of large system libraries into their codebase, including ffmpeg, libicu, openssl and sqlite. Some of these have been diligently forked to ensure that packagers wouldn't accidentally try to use the system copies! -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: localpkg helper script for fedpkg
On Tue, 2011-01-25 at 16:11 -0500, Martin Langhoff wrote: If you are using or experimenting with fedpkg, I am putting some simple helper bits in an accessory localpkg python script (at http://dev.laptop.org/git/users/martin/localpkg or git://dev.laptop.org/users/martin/localpkg ). It currently has some helpers that allow me to build straight from a git checkout. Useful for tiny, non-upstream codebases that pack their own spec file. I often do local builds with fedpkg like so: fedpkg srpm rpmbuild --rebuild foo.rpm Wouldn't it be nice if fedpkg could provide a target equivalent to the old Makefile.common target local? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: localpkg helper script for fedpkg
On Tue, 2011-01-25 at 19:20 -0500, Bernie Innocenti wrote: I often do local builds with fedpkg like so: fedpkg srpm rpmbuild --rebuild foo.rpm Wouldn't it be nice if fedpkg could provide a target equivalent to the old Makefile.common target local? Oh, fedpkg already does have a local target! :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, 2011-01-24 at 15:21 -0500, Martin Langhoff wrote: Fedpkg has consolidated Fedora's common stuff into its code, so all you need is a git checkout with a spec file and some patches right there. And it'll build your stuff, locally, via koji, whatever. Real Nice. Yeah, fedpkg git are the best things that happened to Fedora in many years... I just wish we could get rid of the redundant changelog in the spec file. Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, 2011-01-24 at 20:38 +, Peter Robinson wrote: Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. try fedpkg update Cool! Then, can I make another wish? Some documentation :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, 2011-01-24 at 16:46 -0800, Jesse Keating wrote: That's a bit of a struggle, as there are times when you want something in the scm changelog that isn't really appropriate for the rpm changelog, like fixing a typo in the specfile between build attempts. We do provide the clog facility so that one can re-use the spec changelog for the SCM changelog when appropriate. I've also explored a bit using a %include directive to include contents from a changelog file, one that might be auto-generated from source control, but I didn't go very far with it. Basically I view the scm changelog as data that is relevant and important to your fellow maintainers, where as the rpm changelog is data that is relevant and important to the rpm consumers. While there is some overlap, they are not the same consumers. The old KDE 1.0 CVS repository used a sophisticated commit hook which would interpret tags in the comments such as CVSSILENT, CVSFEATURE or CVSSECURITY to suppress the notification email or add more recipients on cc. Couldn't we do something similar for suppressing entries we don't want to see in the package changelog? Besides: the changelog feature of rpm always stroke me as something so... gross! It is part of the package metadata, but due to size considerations it's not really part of the primary repodata. For multi-package specs, you end up with multiple copies of the same changelog in the rpm database. Moreover, RPM-based distributions use different incompatible formats for %changelog! Not to mention that the % changelog section is where you get 90% of the merge conflicts when porting changes between branches. By contrast, .deb packages simply include a compressed text file: /usr/share/doc/$PKG/changelog.gz. Why couldn't we switch to something similar and thus remove a lot of complexity from the rpm toolchain? (the package changelog is maintained manually, but Debian doesn't have a distro-wide package VCS). I'm just throwing around a bunch of ideas to think about... simplifying the fedora packaging workflow is an important goal, imho. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New Dextrose 2 build: os438dx
This release of Dextrose 2 is intended for beta testing. Images for the XO-1 and XO-1.5 can be downloaded here: http://wiki.sugarlabs.org/go/Dextrose I've not bothered uploading GNOME-enabled images, since Paraguay does not use it. I could be convinced to generate them if it's needed by a deployment for evaluation purposes only. The major highlight in this release is a simple automated updater based on yum which will hopefully enable us to deploy small updates effortlessly. The final release should be ready by Feb 22, when schools reopen in Paraguay, and if the updater works well we'll be able to fix any remaining bugs post-release. This build also includes a refresh of the new activity updater which supports the OLPC microformat protocol. Please test both these features vigorously. This release is missing several Sugar fixes that went into OLPC 10.1.3 over the last weeks. The queue of patches waiting to be merged in Dextrose is quite long and new features have to take precedence so they can get tested early on. We also have some small features that we hope to merge in time for this release. Consult the todo list for more information. === Changes === * Yum updater (alsroot, m_anish) * Notification system (tch) * Refresh activity updater (m_anish) * Revert to old build naming scheme, to avoid confusing users (bernie) === Updated activities === * Abacus-19 * Arithmetic-2 * Calculate-35 * Chat-69 * Distance-21 * Edit-8 * FotoToon-5 * Implode-10 * IRC-8 * Jukebox-20 * Labyrinth-11 * Maze-6 * Measure-32 * Memorize-36 * Paint-30 * Physics-8 * Pippy-38 * Record-87 * Speak-19 * TurtleArt-105 * VisualMatch-27 * Write-72 === Updated OS packages === * bitfrost-1.0.10-3.fc11.i586 * bootfw-q3a62-1.unsigned.i386 * etoys-4.0.2340-2.noarch * kernel-2.6.31_xo1.5-20101222.1243.1.olpc.7b21b8f27f2887b.i586 * kernel-firmware-2.6.31_xo1.5-20101222.1243.1.olpc.7b21b8f27f2887b.i586 * olpc-bootanim-2.12-5.dxo4.fc11.i586 * olpc-contents-2.6-1.fc11.i586 * olpc-kbdshim-16-1.fc11.i586 * olpc-powerd-32-1.fc11.i586 * olpc-powerd-dbus-32-1.fc11.i586 * olpc-runin-tests-0.9.43-1.noarch * olpc-update-2.23-1.fc11.noarch * olpc-utils-1.0.37-1.fc11.i586 * squeak-vm-3.10.5-4.fc11.i586 * xorg-x11-drv-openchrome-0.2.990-2.fc11.i586 * xorg-x11-drv-sisusb-0.9.1-2.fc11.i586 * xulrunner-1.9.1.9-2.fc11.i586 -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problems compiling bluetooth module
On Fri, 2011-01-07 at 12:28 -0200, Emiliano Pastorino wrote: It worked. I had to compile the whole thing and used the resulting bluetooth.ko I'm glad it worked! How were you compiling before? Just make modules SUBDIR=drivers/blah/blah ? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problems compiling bluetooth module
On Fri, 2011-01-07 at 15:32 -0200, Emiliano Pastorino wrote: I was doing make M=drivers/bluetooth Anyways, after compiling the kernel, olpc-configure doesn't recognize some hardware and now I have no sound or touchpad. I'll keep my bluetooth modules and flash my XO. To ensure that you have all options set correctly, you may want to copy the configuration file of the OLPC kernel from /boot/config-2.6.xx and copy it to .config in the root dir of the kernel tree. Then, you have to issue a make oldconfig or equivalent to regenerate the include files. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problems compiling bluetooth module
On Wed, 2011-01-05 at 16:12 -0200, Emiliano Pastorino wrote: Then, when i execute insmod net/bluetooth/bluetooth.ko, I get: insmod: error inserting 'net/bluetooth/bluetooth.ko': -1 Invalid module format Anything suspicious in the output of dmesg/ vermagic: 2.6.31.6 preempt mod_unload modversions GEODE 4KSTACKS Do these things match your running kernel? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problems compiling bluetooth module
On Wed, 2011-01-05 at 17:20 -0200, Emiliano Pastorino wrote: Anything suspicious in the output of dmesg/ kernel: [ 4892.710548] bluetooth: no symbol version for module_layout Hmm... can you verify that the stuff in .config of the kernel sources actually matches the stuff in /boot/config-2.6.31* of your XO? vermagic: 2.6.31.6 preempt mod_unload modversions GEODE 4KSTACKS Do these things match your running kernel? I'm running 2.6.31_xo1-20100701.1605.1.olpc.a8f1b26, that's all I know What does uname -a print? You might be running a newer or older kernel, or a kernel configured differently. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problems compiling bluetooth module
On Wed, 2011-01-05 at 14:43 -0600, Mikus Grinbergs wrote: Each kernel has something I might call a magic handle. [I do not know how that value is constructed - but I suspect that vermagic is only *part* of that value.] When a module needs to be dynamically loaded into the kernel, the (my name) magic handle for the include libraries with which that module was compiled must match the magic handle of the running kernel. If they don't - the result is the Invalid module format message. Some months ago I tried my best to compile a driver and add it to the os852 build - but no matter how careful I was - I could NOT satisfy that magic handle comparison when it came time to load that driver. [I ended up recompiling the whole kernel (now having the missing driver specified as part of the configuration for this kernel's compile).] The version of gcc might take part in computing the magic number. The idea is to prevent users from causing hard to diagnose bugs by inadvertently loading modules that aren't 100% ABI compatible with the running kernel. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] A heads up for the major changes that will appear in Fedora 15 / SoaS 5
On Thu, 2010-12-30 at 09:27 -0500, Martin Langhoff wrote: AIUI, from discussions with Simon and Tomeu that's not the case. Gnome people are not that insane, the old APIs will still work and be supported. They won't be the latest coolest API wiz-bang so support may be weaker, and/or we may get ah, well, the bug you mention is fixed in the introspection API, migrate to that instead of a fix to the problem you report. Personally, I don't mind *not* being in the bleeding edge for one cycle :-) I agree with you. There's no hurry to switch to GNOME 3 and there are higher priority tasks at this time. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] A heads up for the major changes that will appear in Fedora 15 / SoaS 5
On Thu, 2010-12-30 at 20:10 +, Peter Robinson wrote: On Thu, Dec 30, 2010 at 5:12 PM, Bernie Innocenti ber...@codewiz.org wrote: On Thu, 2010-12-30 at 09:27 -0500, Martin Langhoff wrote: AIUI, from discussions with Simon and Tomeu that's not the case. Gnome people are not that insane, the old APIs will still work and be supported. They won't be the latest coolest API wiz-bang so support may be weaker, and/or we may get ah, well, the bug you mention is fixed in the introspection API, migrate to that instead of a fix to the problem you report. Personally, I don't mind *not* being in the bleeding edge for one cycle :-) I agree with you. There's no hurry to switch to GNOME 3 and there are higher priority tasks at this time. So are we saying that we don't want sugar on a stick for the F-15 release cycle and are happy to have it dropped from the Fedora Spins and someone else is prepared do the work to get it back to that status? Or do people generally not care about SoaS? Is Fedora already dropping all the gnome2 libraries?? I can't believe this. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Modifying 353 (xo-1) to apply the dev.laptop.org/ticket/10195 fix
[cc += dextrose] On Fri, 2010-11-19 at 21:15 -0600, Mikus Grinbergs wrote: Bernie - you closed this ticket with I disabled the mesh on boot and no further incidents of this type were reported. Please - how did you disable the mesh on boot ? Like so: # enable debug for pgf # also disable mesh to see if this makes the bug go away cat $INSTALL_ROOT/etc/rc.local __EOF__ echo 0x26187 /sys/module/libertas/parameters/libertas_debug echo 0/sys/class/net/eth0/lbs_mesh __EOF__ Btw, I forgot to disable the debug logging in Dextrose! It's no longer necessary and has a small performance impact on the XO-1. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F14 os3 development image released (XO-1 and XO-1.5)
On Fri, 2010-11-26 at 17:49 +, Daniel Drake wrote: Thanks to everyone who provided feedback on os2. New build is ready: http://wiki.laptop.org/go/F14_for_XO (any help on the wiki page appreciated!) http://build.laptop.org/F14/os3/ Notably, suspend/resume is much more reliable and the graphics glitches are gone. Fixed tickets are: #10460DCON bad state on first suspend #10461XO-1.5 messes up serial console during resume #10464boot partition not mounted on partitioned XO-1 #10467serial console getty unusable after S/R #10478'About my Computer' shows: :Wireless Firmware: Not Available #10455libertas-related slab corruption #10459libertas cfg80211 slab corruption and: Latest F14 updates Linux 2.6.35.9 UVC + ldusb support xorg.conf.d for cleaner X configuration Firmware Q3A61 for XO-1.5 Please test and feed back! I've tested on an XO-1.5. Here are a few quick bug reports from my first 20 minutes of usage: == OS == * Despite the initrd optimization and ext4, boot time the same of before: 30 seconds (36 seconds on the first boot, due to ssh keys) * Graphics seem a lot more fluid on the XO-1.5. Not sure why, I like it. * AC plug/unplug events don't have any effect on the battery frame icon. * Automatic power management seem to have improved a lot and is almost unnoticeable. However, can't we disable it while the laptop is on AC? == Sugar == * The spiral view gives an initial impression of using something completely new, yet familiar. * Spurious password prompts at boot. This has been broken in 0.90 for a couple of months now. Is anyone working on this bug? * This is not a regression, but I just noticed that there's no way to connect to a hidden network from Sugar. A possible workaround is connecting from Gnome and then switching back to Sugar. * The Read activity shouldn't appear in the favorite view. == Activities == * The Record UI is still broken (tsk tsk :-). Seriously, is anyone working on the UI rewrite? * The Wikipedia activity fails to start. I think it also failed in Dextrose, until we merged a small backwards compatibility fix in sugar-toolkit. * TamTamMini, TamTamEdit and TamTamSynth fail to start * The Help activity is pretty outdated, not localized and generally not very useful. It also asks to save to the journal on exit. I would recommend removing it until someone improves it. * The cursor in Write stops flashing after 2-3 seconds. It does not seem to be related with automatic PM. * Browse has the 0x0 buttons problem. We fixed it in Dextrose by disabling sugar-settings-manager. We also tried to fix the actual bug in our XSETTINGS implementation (ask jasg for details). * Text in the Terminal is too big. We have a hack to fix this in Dextrose which consists in dropping a configuration file in ~/.sugar/default/terminalrc at build time. My overall impression of F14-S0.90 is very positive. I'm sure it won't take too long before it surpasses the F11 builds in terms of usability and stability. Good job! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] New 10.1.3 build os351 for XO-1 and XO-1.5
On Wed, 2010-11-03 at 15:02 -0200, Daniel Castelo wrote: Do you have any idea? Maybe we have to modify some Sugar packages to have this feature working? (remember that we have a version of sugar based on sugar 0.88). Do you have at least sugar-0.88-5.38dxo? It contains this patch: sl1725-homewindow-resize-on-resolution-change.patch (see also sl#2163) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] New 10.1.3 build os351 for XO-1 and XO-1.5
On Wed, 2010-11-03 at 14:11 -0400, Martin Langhoff wrote: On Wed, Nov 3, 2010 at 1:02 PM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: With this steps If I press the rotate button the screen changes, but the behavior is not appropriate. Grab latest olpc-utils rpm from http://dev.laptop.org/~martin/public_rpms/10.1.3/ , reboot and retry. If you still see problems, you gotta tell us more detail. Can you drop this new package in your public_rpms on dev.laptop.org? So it will appear in the repo from which dextrose pulls. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, 2010-10-20 at 08:35 -0500, Mikus Grinbergs wrote: The question is why does it take so long for the connection to be established? A 10-12 second reconnect time is to be expected: 1. A 1 second delay for the device to be probed and initialized on resume 2. NetworkManager has a 7 second delay hardcoded Really? That sucks! Finally explained why my simple shell script could connect in just 3 seconds whereas NM took a lot longer. [I hope that an XO which is in I've had my wireless connected for a whole hour mode can nevertheless detect whenever a __new__ AP shows up (whose radio signal was not previously noticed). If that is possible, then the SAME capability should be applicable even at startup time.] This is called background scanning. Most wifi firmwares do it because it's required to hop to another with the same ESSID and better signal quality. Background scanning may introduce several ms of latency while the radio is switching channels. Gamers know tricks to disable it. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, 2010-10-20 at 10:28 -0400, Martin Langhoff wrote: The hardcoded sleep *is* being removed. IME, that'll first uncover a variety of bugs and odd interactions/races in various drivers and hardwares it has been covering for. I'm hitting one of these races even *with* the hard-coded timeout: it's between wpa_supplicant and NetworkManager, on resume from suspend. It causes the list of available access points to remain blank. Dan Williams helped me analyze the issue, but we still have no fix. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: avahi might show confusing IP-addresses for the XOs it reports
On Sun, 2010-10-17 at 08:37 -0500, Mikus Grinbergs wrote: XO-1 os852 (with updated olpc-powerd) DISCLAIMER: This is FYI - I'm sharing my experiences While troubleshooting a problem I have on os852 xo1 (interface eth0 disappears), You're probably seeing this bug: After a very long chase, we fixed it for good in Dextrose by disabling mesh support: http://dev.laptop.org/ticket/10195 Besides this particular bug, we could never get the mesh to work reliably on the XO-1, and at this point I don't believe it will ever happen. The ad-hoc mode covers 99% of the real-world use-cases for the mesh, using a mature, standard protocol. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Script to install missing langs?
On Sun, 2010-10-10 at 19:49 -0400, Sayamindu Dasgupta wrote: BTW: I was wondering if you know why the Fedora RPMs for Sugar and Activities include message catalogs for en and even all the en_* variants: It was a hack that was used at some points to fix typos in code (eg: if you had Wopen in the source code, you could probably just change the translation of Wopen to Open in en_US, since if you changed Wopen to Open in the code, all other translations would had to be updated as well). Yet, do we really need a copy of the english catalog for each existing en_XX variant? It seems like a big waste of space. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problem with olpc-os-builder: ZD image of 20 MB
On Wed, 2010-10-13 at 13:56 -0200, Daniel Castelo wrote: With this configuration: [buildnr_from_file] suffix=uy path=uy-buildnr-0.88-1.5 When the version number has three digits the process fail. Seems like the image name couldn't have more than nine characters. For example with the image name: os100uy.zd the process Its very strange, because I know that many dextrose builds have long names. Yes, it's strange. Versions with 3 digits and 2 or 3 letters of suffix always worked well for me! Perhaps there are some invisible blanks in the .ini or in the buildnr file? Note that there's a real limit to observe: the old DOS 8+3 naming scheme. Otherwise, the OFW will display a mangled name. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Script to install missing langs?
On Sat, 2010-10-09 at 23:55 -0400, Sayamindu Dasgupta wrote: The build script filters out _all_ translation files, so even if glibc and sugar translations are there (and glibc contains the locale data as well), there might be other (usually low priority) translation files missing. For that, it is probably best to do a new spin. Yes, but the messages from system packages are unlikely to appear in the Sugar UI... I can't think of anything except for ERRNO strings, which are in glibc. BTW: I was wondering if you know why the Fedora RPMs for Sugar and Activities include message catalogs for en and even all the en_* variants: ber...@giskard:~$ ls /usr/share/locale/en_US/LC_MESSAGES/ compiz.mo org.laptop.Log.mo gcalctool.mo org.laptop.Terminal.mo libxine1.moorg.laptop.TurtleArtActivity.mo org.laptop.AbiWordActivity.mo org.laptop.sugar.Jukebox.mo org.laptop.Calculate.moorg.laptop.sugar.ReadActivity.mo org.laptop.Chat.mo wget.mo org.laptop.ImageViewerActivity.mo yelp.mo The en strings are built-in, so normally packages do not ship external catalogs for them. It smells like a bug in bundlebuilder. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Script to install missing langs?
On Sat, 2010-10-09 at 12:08 -0500, Jerry Vonau wrote: Think the fastest would be to force the re-installation the glibc-common rpm. Yes, and the sugar-* rpms too. We probably don't need any of the catalogs for the other system tools. Activities installed from .xo bundles will already have all languages installed. You can spin-up your own image with olpc-os-builder, editing the languages as required. This would be cleaner, of course, but Martin was thinking of small deployments lacking a technical team. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] Problem with olpc-os-builder: ZD image of 20 MB
On Wed, 2010-10-06 at 09:42 -0200, Daniel Castelo wrote:
Hi! We could generate XO 1.5 images (dextrose images) with olpc os
builder, but sometimes we get a strange behaviour: at the end of the
process olpc os builder give us this error message:
/home/latu/olpc-os-builder-1.1.0.dextrose.uy_4Oct/modules/sd_card_image/image.50.makefs.sh:
line 54: * 512: syntax error: operand expected (error token is * 512)
and the size of the ZD image generated is just 20 MB.
Have you ever seen this behaviour?
I've never seen it myself. Here's the relevant code:
48 local img_sectors=$(sfdisk -uS -l $img | grep img2 | awk '{print $4}')
49 echo (1 losetup error is normal here)
50 losetup -d /dev/loop6 || :
51 losetup -o $((8192 * $BLOCK_SIZE)) --sizelimit $((131072 * $BLOCK_SIZE))
/dev/loop6 $img
52 echo (1 losetup error is normal here)
53 losetup -d /dev/loop7 || :
54 losetup -o $(((8192 + 131072) * $BLOCK_SIZE)) --sizelimit $(($img_sectors
* $BLOCK_SIZE)) /dev/loop7 $img
The error probably occurs because $img_sectors is uninitialized. Try
adding some debug stamennts just after line 48. For example:
echo '*** BEGIN DEBUG ***'
sfdisk -uS -l $img
echo '---'
sfdisk -uS -l $img | grep img2
echo '---'
sfdisk -uS -l $img | grep img2 | awk '{print $4}'
echo '*** END DEBUG ***'
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Request for help with adding a driver to build os852
On 09/29/10 17:46, Mikus Grinbergs wrote: I need to add two drivers for external USB devices to os852. I believe that creating a complete build from scratch for the XO-1, which includes the drivers I want, ought to work -- but I'm intimidated at jumping into git and kernel-building, just for a couple of drivers. [Besides, I don't want to be in the business of build maintenance.] Building an OS image isn't actually so hard if you're an experienced Linux user, which you seem to be. I bet you can learn in less than two hours. Come on IRC for a guided tour. Building a custom kernel is a little harder. I build kernels like so: git clone --reference ~/src/kernel/linux-2.6 dev.laptop.org:/git/olpc-2.6 make ARCH=i386 xo_1_defconfig setarch i386 make ARCH=i386 xo_1-kernel-rpm Installing it on an XO with the versioned fs requires some magic: rpm -ivh kernel-*.rpm cp -a /boot/* /versions/boot/current/boot/ So far, I'm trying to see if I can compile those drivers from source -- but I'm having a HUGE struggle with the deficiencies of XO-1 package kernel-devel-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586 (it's missing header directories: 'arch/x86/include', 'include/trace', and 'include/asm-x86'). Hmmm building modules off-tree should work even with the olpc kernel, but nobody ever tests this so I'm not surprised it's broken. Try building the kernel rpm from scratch as explained above. But even when I've managed to compile the most recently available driver source and gotten an output module, 'modprobe' gives me unknown symbol errors, like the following (as logged in dmesg): [139115.158397] uvcvideo: disagrees about version of symbol v4l_compat_translate_ioctl [139115.158424] uvcvideo: Unknown symbol v4l_compat_translate_ioctl [...] Looks like you compiled your module against a config.h which was not the same of the OLPC kernel. Or maybe your driver requires a config option that is missing on the OLPC kernel. Either way, building in-tree should fix this problem. I'm asking that someone please tell me which Fedora kernel package comes closest to the XO-1 os852 kernel package - so I can go exploring for differences. I also suspect that the driver source code I used is not the same as the driver source code Fedora used -- do I have to look in Fedoraproject git for the driver source code to try to compile ? None of the Fedora kernel packages comes close to the OLPC kernel. It's a completely independent codebase, forked off from Fedora some 3 years ago. When 100% of the olpc patches will be in Linus' tree, the stock Fedora kernel will probably be able to boot on the XO out of the box. I'm not sure how far away into the future this is. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
On Sat, 2010-09-11 at 16:47 -0500, Mikus Grinbergs wrote: With that change applied on an XO-1 system to the Chat-66 on os1, I was able to collaborate with an XO-1 system running Chat-66 on os604dx, plus an XO-1 system running Chat-65 on os856, plus an XO-1 system running Chat-48 on build 802 -- that's a four-way-chat collaboration, using regular mesh, NOT ad-hoc. [By the way, Chat on the os604dx system still worked, even after I applied the pippy_apps.py fix there, as well.] Out of curiosity... what's build os604dx? :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Mon, 06-09-2010 a las 11:49 +0100, pbrobin...@gmail.com escribió: Done, but I'm afraid I had to give it negative karma: Looking at the upstream GIT of evince it looks like this is another of the apis that have been deprecated upstream and Read needs to be updated to fix the issue http://git.gnome.org/browse/evince/diff/libdocument/ev-selection.h?id=18d2af9bce80392407fae997c8dfa029f5a54123 To keep the testing cycle shorter, couldn't you just build the rpms locally and test them once on your system before pushing them to bodhi? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Mon, 06-09-2010 a las 22:59 +0100, pbrobin...@gmail.com escribió: I don't maintain that package. I also don't maintain Read. The gnome-python2 package I did update was just re-enabling the upstream. In that regard i did test the gnome-python2 package but but not against Read as where I was in the world at the time I didn't have a working F-14 system to hand with X working so its pretty hard to. At the moment I've worked every day in the last month and I've being travelling around Europe at least once a week so I'm battling to have time to do the basic stuff and I didn't believe I'm the only person in the sugar testing world. Sorry, didn't mean to sound like I did not appreciate your packaging work. Let me know how I could help, besides testing (although I'm also spreading myself very thin, as you know). The problem isn't evince or gnome-python2 but that Read needs to be updated again for the new upstream evince api changes (again). Looking in Read git the last tagged release is Read 79 yet on a.sl.o is Read 86. I'm not sure what the rest of the changes are or which version is correct so going on the official Read 79 release it wouldn't work any way. Sayamindu may know. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] Don't exclude all hunspell dictionaries
This is unnecessary and prevents deployments from easily adding dictionaries with custom_packages. --- modules/base/kspkglist.10.core.inc |1 - modules/custom_scripts/sugar_coredump.sh |7 +++ 2 files changed, 7 insertions(+), 1 deletions(-) create mode 100755 modules/custom_scripts/sugar_coredump.sh diff --git a/modules/base/kspkglist.10.core.inc b/modules/base/kspkglist.10.core.inc index faa3240..5f5ba79 100644 --- a/modules/base/kspkglist.10.core.inc +++ b/modules/base/kspkglist.10.core.inc @@ -77,7 +77,6 @@ ssmtp # dictionaries are big -aspell-* --hunspell-* -man-pages-* -words diff --git a/modules/custom_scripts/sugar_coredump.sh b/modules/custom_scripts/sugar_coredump.sh new file mode 100755 index 000..19d2dc0 --- /dev/null +++ b/modules/custom_scripts/sugar_coredump.sh @@ -0,0 +1,7 @@ +#!/bin/bash + +# let Sugar to dump core +# will hopefully let us track down sl#2064 +cat $INSTALL_ROOT/home/olpc/.xsession __EOF__ +ulimit -c unlimited +__EOF__ -- 1.7.2.2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Don't exclude all hunspell dictionaries
El Tue, 07-09-2010 a las 02:29 +0200, Bernie Innocenti escribió: --- /dev/null +++ b/modules/custom_scripts/sugar_coredump.sh @@ -0,0 +1,7 @@ +#!/bin/bash + +# let Sugar to dump core +# will hopefully let us track down sl#2064 +cat $INSTALL_ROOT/home/olpc/.xsession __EOF__ +ulimit -c unlimited +__EOF__ Oops. This hunk was obviously meant to be part of another commit, please ignore. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Sun, 05-09-2010 a las 00:53 +0100, pbrobin...@gmail.com escribió: Well I am for SoaS related things which while isn't XO hardware related it does affect everything further up the stack does that not count :-( Such parallel efforts are indeed mutually beneficial. Dextrose also enjoyed the pioneering packaging and testing effort carried on on 0.88 by the SoaS folks, plus the platform stabilization work done by dsd, pgf and cjb. Isn't this the normal thing in FLOSS development? No point as its directly Fedora related but if people could add positive karma to this it would be fixed quicker, else in about 4-5 days it will head to F-14 stable. https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14 Done, but I'm afraid I had to give it negative karma: ---cut--- Traceback (most recent call last): File /usr/bin/sugar-activity, line 21, in module main.main() File /usr/lib/python2.7/site-packages/sugar/activity/main.py, line 115, in main module = __import__(module_name) File /home/bernie/Activities/Read.activity/readactivity.py, line 25, in module import evince ImportError: /usr/lib64/python2.7/site-packages/gtk-2.0/evince.so: undefined symbol: ev_selection_get_selection_map Exited with status 1, pid 5410 data (None, open file 'fdopen', mode 'w' at 0x261a150, 'c9a33f84910d7499496f16cb75f4a930a1f234d4') ---cut--- -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Wed, 01-09-2010 a las 07:57 -0500, Mikus Grinbergs escribió: the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen. I recommend rebasing on the geode driver 2.11.9, which was just released by upstream. I've been testing it in Dextrose for about 3 weeks: it fixes all the known rendering bugs and has no regressions. The XO-1 os1 build already has xorg-x11-drv-geode-2.11.9-1.fc14.olpc1 This package is not in Fedora's git, though. I'll ask Dave Arlie if it's ok with him to update the package. I'm sure he'll be glad to hand-off this driver to someone who can actually test it. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Wed, 01-09-2010 a las 05:03 -0500, Mikus Grinbergs escribió: In Terminal, cursor movement keys don't work. [I also saw interference to Terminal (white background) from dmesg? lines (black background), after each boot -- but these would go away if I just restarted Sugar.] This could be X using the xfree86 keycodes instead of the evdev ones. What does setxkbmap -v say? Could not use text console (alt-ctl-Fn combo appears to be ignored). Same XKB misconfiguration, prolly. Among the non-starters were Chat and TamTam. Could you determine why? They do work with Sugar 0.88 on F11. So probably we have ABI issues in Fedora 14. (suppressed rant about Sugar not using a proper packaging system) Thank you muchly for your great leap forward, mikus Thank you very much for all the testing you've been doing. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Thu, 02-09-2010 a las 01:07 +0200, Bernie Innocenti escribió: rpm -Uvh http://download.sugarlabs.org/dextrose/testing/dxo2/rpms/i386/os/xorg-x11-drv-geode-2.11.9-1.fc14.i586.rpm The .fc14 is my mistake, this package is actually built for Fedora 11. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing the OLPC OS 10.1.2 final release!
El Mon, 30-08-2010 a las 21:00 -0400, Chris Ball escribió: I'm very pleased to announce build os852 as the final 10.1.2 release build for XO-1 and XO-1.5 laptops. [...] Kudos! Shouldn't this go to devel-annou...@lists.laptop.org as well? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Tue, 31-08-2010 a las 23:22 -0600, Daniel Drake escribió: Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen. I recommend rebasing on the geode driver 2.11.9, which was just released by upstream. I've been testing it in Dextrose for about 3 weeks: it fixes all the known rendering bugs and has no regressions. Hopefully it will also work well on newer X servers, but I have not had the opportunity to test yet. If you're ok with it, I could upgrade the xorg-x11-drv-geode package in Fedora 14. I really admire the work you're doing and wish I could help more than this, but time to work on XO builds is up for me. From now on I'll have just enough time to finish spinning-off Dextrose 2 in the hands of deployments. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
El Wed, 01-09-2010 a las 15:55 -0300, Martin Langhoff escribió: can you spin a F11 RPM of 2.11.9? If it's much improved, and a good testing shows it has no regressions, it's a candidate for 10.1.3. Enjoy: rpm -Uvh http://download.sugarlabs.org/dextrose/testing/dxo2/rpms/i386/os/xorg-x11-drv-geode-2.11.9-1.fc14.i586.rpm -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] sl#2259: Set Firefox default DPI to 96
--- modules/x11/kspost.60.misc.inc | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/modules/x11/kspost.60.misc.inc b/modules/x11/kspost.60.misc.inc index a48e352..ae6dd56 100644 --- a/modules/x11/kspost.60.misc.inc +++ b/modules/x11/kspost.60.misc.inc @@ -79,11 +79,16 @@ EOF chown -R olpc: /home/olpc/.scim -# disable Firefox's OGG plugin in favour of totem, because no hw accel is -# available. #10152 -[ -e /usr/lib/xulrunner-*/greprefs/all.js ] \ +if [ -e /usr/lib/xulrunner-*/greprefs/all.js ]; then + # disable Firefox's OGG plugin in favour of totem, because no hw accel is + # available. #10152 sed -i -e 's:\(media.ogg.enabled,\) true:\1 false:g' /usr/lib/xulrunner-*/greprefs/all.js + # sl#2259: The layout.css.dpi default setting results in a too big layout and fonts + sed -i -e 's:\(layout.css.dpi,\) -1:\1 96:' /usr/lib/xulrunner-*/greprefs/all.js +fi + + # remove gstreamer pulse element so that totem doesn't try to use it (#10158) [ -e /usr/lib/gstreamer-0.10/libgstpulse.so ] rm /usr/lib/gstreamer-0.10/libgstpulse.so -- 1.7.2.2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-configure
Sorry for the long delay, I had overlooked this unreplied message. El Sat, 14-08-2010 a las 14:35 -0500, Jerry Vonau escribió: On Sat, 2010-08-14 at 15:15 -0400, Bernie Innocenti wrote: Since you get en_US.UTF-8 either way, I would tend not to bother fixing this bug neither in olpc-configure nor in your mfg-data. I don't want en_US.UTF-8, I want what I set in os-builders' base/ksmain.10.core.inc file, I'm changing the install language there. Is there a reason not to do that? Now that you can switch between gnome and sugar, though that might be a good way to keep the two in sync. The lang option in ksmain.10.core.inc gets stored into /etc/sysconfig/i18n by imgcreate. Regardless of the contents of the manifacturing data, olpc-configure will *always* override /etc/sysconfig/i18n on first boot. To prevent this, you could touch /.olpc-configure from olpc-os-builder. Take care to also perform the rest of the initialization usually done by olpc-configure. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: [Dextrose] WiFi vs Suspend
El Wed, 25-08-2010 a las 20:45 +1000, fors...@ozonline.com.au escribió: * dmesg dmesg.out and attach it to the bug. Dextrose enables libertas debug in /etc/rc.local to help diagnose this bug. took me 10 minutes after it came good to work out dmesg so this is a bit later than the event: That's odd, debug does not seem to be on. Is this really os373py? What's in /etc/rc.local? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Tecnologia] Schoolserver development in Uruguay
El Thu, 19-08-2010 a las 22:24 -0300, SgtPepper escribió: The guys at La Rioja here wanted to go with puppet. I'll also go ahead and try CFengine. I asked around: everyone seems to think that Puppet is superior. The OSU-OSL is migrating from CFengine to Puppet, which is a strong indicator given their reputation. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Dextrose] WiFi vs Suspend
[cc += olpc-devel] El Wed, 25-08-2010 a las 11:05 +1000, fors...@ozonline.com.au escribió: OS373pyg Wifi is locked up after resume from sleep, must restart. I presume this bug is being tracked at dev.laptop.org/ in one of the 4 tickets below http://dev.laptop.org/ticket/10232 WiFi dies on suspended XO-1,os300 http://dev.laptop.org/ticket/10092 Networking broken over suspend/resume on os13 for XO-1 http://dev.laptop.org/ticket/9960 wake-on-WLAN doesn't always work\ (duplicate) http://dev.laptop.org/ticket/9967 ibertas suspend fails on XO-1 (fixed) There are a number of unsolved bugs in the libertas kernel driver or in its fantastically proprietary firmare. If you turned on automatic power management on an XO-1, you might be seeing this other one: http://dev.laptop.org/ticket/10195 In short, very rarely the libertas usb8xxx disappears from the USB bus when it receives certain commands from the driver. Suspend/resume are known to trigger quite frequently and the mesh also seems to cause it once or twice per day in a classroom of 30 students. Because time for debugging was running out, in the latest beta builds I had to disable both mesh support and automatic power management in the attempt to get rid of this bug. After one week of testing, the problem was not reported any more. If you spot this bug again, could you please: * check whether eth0 is still visible with ifconfig -a * check whether the Marvell 8xxx is still visible with lsusb * dmesg dmesg.out and attach it to the bug. Dextrose enables libertas debug in /etc/rc.local to help diagnose this bug. This never ending saga brings me back to an exasperated email that David Woodhouse wrote about 3 years ago, after spending many days in unfruitful debugging, in which he warned that access to the source code of the firmware was essential in order to nail down all the obscure Libertas bugs. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [PATCH] Use LSB functions for initscript
El Mon, 23-08-2010 a las 15:09 -0500, Jerry Vonau escribió: Be careful with that one, check the Requires of redhat-lsb first, there are lots of rpms that will get pulled in because of it. Indeed :-( I've always been looking for a good cross-distro replacement for start-daemon. The LSB init-functions are really a half baked solution that doesn't even include a portable way to print OK/FAIL after starting something. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Tecnologia] Schoolserver development in Uruguay
El Thu, 19-08-2010 a las 22:02 -0600, Daniel Drake escribió: Actually, no cleanup was being done on that particular schoolserver. Are you sure? Yes, and now I know why: [r...@schoolserver ~]# /usr/bin/ds-cleanup.sh Traceback (most recent call last): File /usr/bin/ds-cleanup.py, line 42, in module import syck ImportError: No module named syck The package is also missing on our xs 0.6. It's simply a missing dependency in ds-backup-server, but it broke all schoolservers worldwide ;-) After installing syck-python, ds-cleanup.py still doesn't seem to do anything. I'll figure out why another day, now it's 2am again. There's more than that. It's a tool that makes you really think through the changes that your making. It helps you centralize everything. It also results in a configuration that results in the ability to upgrade from any point in time to the latest version. It would be less error prone in many ways. That's true. The problem with this sort of tools is that it's very hard to diagnose what went wrong. On a puppetized machine, a rule containing rpm -i package; do_something failed after the first command for some obscure reason. Then, the first command would also keep failing because the package was already installed. This time we could blame it on the incautious rule author who forgot --force, but you see what I mean: error paths become complex with puppet because the flow control is non-linear (like in make) and rule execution happens asynchronously and in thebackground (even more obscure than make). And if you have a mix of offline and online servers, its a no-brainer. The puppet benefits (vs shell script) for connected servers are very significant. And if you can just take a few easy steps to share the configuration with your offline servers, you save a lot of time. That is true. OTOH, one could also share a script to be executed off a USB stick or over the net with Puppet. As ugly as it may sound, humans would probably find it easier to maintain linear code that could be debugged interactively from the command line, independently of an asynchronous client/server system based on interdependent rules. [takes breath] -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Initial port of idmgr to Debian
The following patch series makes idmgr work on the Plan Ceibal schoolserver out of the box, after configuring a different network address. [PATCH] create_registration: Directly create a v3 format database [PATCH] Use LSB functions for initscript [PATCH] Make users home directory configurable In order to get this accepted in Debian (and in Fedora), we'll have to relocate the package home from /home/idmgr to /var/lib/idmgr and probably also rename the package to olpc-idmgr or schoolserver-idmgr. ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] [PATCH] create_registration: Directly create a v3 format database
Signed-off-by: Bernie Innocenti ber...@codewiz.org --- idmgr.spec.in |2 +- scripts/create_registration |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/idmgr.spec.in b/idmgr.spec.in index bbdbcd5..9f8d09e 100644 --- a/idmgr.spec.in +++ b/idmgr.spec.in @@ -52,7 +52,7 @@ getent group xousers /dev/null 21 || groupadd xousers # Create the identity database, if there is no pre-existing one # and set the current rev number if [ ! -r /home/idmgr/identity.db ] ; then - # creates a v2 format file + # creates a v3 format file /home/idmgr/create_registration fi diff --git a/scripts/create_registration b/scripts/create_registration index b72a950..190b0f9 100755 --- a/scripts/create_registration +++ b/scripts/create_registration @@ -20,6 +20,6 @@ # create_registration # This script creates a new database for the registration server # -sqlite3 /home/idmgr/identity.db CREATE TABLE laptops ( serial VARCHAR(20) NOT NULL, nickname VARCHAR(200) NOT NULL, full_name VARCHAR(100) NOT NULL, pubkey TEXT NOT NULL, uuid VARCHAR(100), lastmodified TEXT DEFAULT '1970-11-12 12:34:56', PRIMARY KEY (serial) ) +sqlite3 /home/idmgr/identity.db CREATE TABLE laptops ( serial VARCHAR(20) NOT NULL, nickname VARCHAR(200) NOT NULL, full_name VARCHAR(100) NOT NULL, pubkey TEXT NOT NULL, uuid VARCHAR(100), lastmodified TEXT DEFAULT '1970-11-12 12:34:56', class_group INTEGER, PRIMARY KEY (serial) ) -[ -x /home/idmgr/storage_format_version ] || echo 2 /home/idmgr/storage_format_version \ No newline at end of file +[ -x /home/idmgr/storage_format_version ] || echo 3 /home/idmgr/storage_format_version -- 1.5.6.5 ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Intitial port of idmgr to Debian
For some reason, the cover letter of the previous patch series was not sent even though I had the --cover option in git-send-email (I blame Perl). ---cut--- The following patch series makes idmgr work on the Plan Ceibal schoolserver out of the box, after configuring a different network address. [PATCH] create_registration: Directly create a v3 format database [PATCH] Use LSB functions for initscript [PATCH] Make users home directory configurable In order to get this accepted in Debian (and in Fedora), we'll have to relocate the package home from /home/idmgr to /var/lib/idmgr and probably also rename the package to olpc-idmgr or schoolserver-idmgr. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[PATCH] Source user .Xmodmap, required for accessibility
Signed-off-by: Bernie Innocenti ber...@codewiz.org --- usr/bin/olpc-session |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/usr/bin/olpc-session b/usr/bin/olpc-session index 8d17e1d..145cac8 100755 --- a/usr/bin/olpc-session +++ b/usr/bin/olpc-session @@ -119,7 +119,8 @@ if [ -e $HOME/.olpc-active-desktop ]; then fi fi -# source custom user session, if present +# source custom user xmodmap and xsession, if present +[ -f $HOME/.Xmodmap ] xmodmap $HOME/.Xmodmap [ -f $HOME/.xsession ] . $HOME/.xsession # useful for performance work -- 1.7.2.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Schoolserver development in Uruguay
El Thu, 19-08-2010 a las 20:56 -0600, Daniel Drake escribió: XS-0.6 and some of the package updates that come later fix a few bugs related to ejabberd CPU/DB. I guess in Paraguay they are still on 0.5. Indeed. Three schools moved to 0.6 due to an HD crash and the 27 new schools which are receiving th next wave of laptops will have 0.6 too. Is there a documented upgrade procedure for the remaining 7 schools? If not, can we hope yum upgrade to be sufficiently smart? But it's not a huge issue because the XOs also have a copy of the journal. So, if technical resources are available for a quick XS repair, disruption should be minimal. Also my thinking. There's however the problem of loosing registrations to the schoolserver. With Sugar 0.84, all the laptops in the school would be stuck without the Register menu item. In Dextrose-1, we've worked around this and similar cases by providing a Register Again function. Admittedly, this solution sucks. Ideally we'd want laptops to probe for a schoolserver in the background and attempt to register automatically until they gain access. Something like the patch for Sugar 0.82 which you wrote. I wanted to rework it for 0.88 so we could merge it in Dextrose, but there wasn't enough time. You're giving numbers but missing an important consideration - the XS backup system makes multiple backups. And it'll continue to do make more and more copes until it meets a certain threshold based on disk size (likely to be 238GB in your case). At this point, it will purge the oldest backups before making new ones. Oops. Actually, no cleanup was being done on that particular schoolserver. There was a /var/lib/ds-backup/ds-cleanup.run left there from 2009 :-( [...] It's possible that within that space you have 10 backups of every journal. So you could possibly get away with a disk half the size, and only retain 5 copies. I'm inventing numbers (and they aren't strictly copies either), but you can provide real ones - how many backups (on average) are there of a journal in this server? What's the disk space used if you only total the space used by the most recent backup of each journal? Also, is it possible that your space-measuring script is counting a 5mb file with 2 hardlinks as 10mb of used disk space? Heh, these are good questions, but answering them all would take quite some time, and it's 1AM over here :-) You still have shell accounts on our schoolservers. Feel free to perform any forensic analysis of this kind. Excellent is a bit subjective, but yes, the fact that it requires any form of connectivity is a roadblock in many cases. However, we came up with a way around this (ideas only, for now, but wouldn't be hard to implement) for puppet: - clone all the puppet repositories and the config files and put them on a USB disk (and do this periodically) - install puppet-server on all the XSs (but dont run it by default) - go to a school with said USB disk, plug it in and run puppet-server - run puppet-client, connecting to localhost - stop puppet-server, unplug USB disk, go home Excellent idea, although the complexity of puppet is hard to justify if the only thing it provides over a mere shell script is some sophisticated dependency checks. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[PATCH] Disable some useless cron jobs
Signed-off-by: Bernie Innocenti ber...@codewiz.org --- modules/base/kspost.10.core.inc |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/modules/base/kspost.10.core.inc b/modules/base/kspost.10.core.inc index 431ca3a..d7cf96b 100644 --- a/modules/base/kspost.10.core.inc +++ b/modules/base/kspost.10.core.inc @@ -165,3 +165,11 @@ sed -i -e 's%\t\tdo_dsa%#\t\tdo_dsa%g' \ # disable sshd, saves memory and speeds up startup time /sbin/chkconfig sshd off + +# disable mdadm's cron job (sl#2185), plus a few more useless cron jobs +rm -f /etc/cron.weekly/99-raid-check +rm -f /etc/cron.daily/logrotate +rm -f /etc/cron.daily/makewhatis.cron +rm -f /etc/cron.daily/prelink +rm -f /etc/cron.daily/rpm +rm -f /etc/cron.daily/tmpwatch -- 1.7.2.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Looking for additional hands on XS
El Thu, 19-08-2010 a las 15:49 -0400, Martin Langhoff escribió: http://www.laptop.org/en/utility/people/opportunities.shtml Ha! I was just about to write you about some XS requirements for Uruguay :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Schoolserver development in Uruguay
calendars, lesson plans and even student records right inside the wiki. I have a dream that one day each school will evaluate and choose their favorite tools autonomously... but this is still a few years into the future. For the time being, we have to make a choice that would fit everyone and requires minimal remote management. If we make an impopular choice, teachers will simply start using Google Docs and other online tools. == Server management tools == Paraguay uses Puppet. We're very happy with it. Uruguay uses CFengine. They seem to be very happy with it as well. Both employ a flat hierarchy with one puppet master controlling all the schools, which is simple and straightforward, but requires excellent connectivity. Needless to say, comments are very welcome. Especially criticism. But no distro advocacy, please... they're all good, ok? :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Tecnologia] Schoolserver development in Uruguay
an issue that once with access you could delete your co-workers files, but they used it anyways A wiki has the same issues, but with versioning you can easily revert any vandalism, so it could be opened even to children. When a CMS was proposed, and later plone was accepted, i recomended dokuwiki, but for personal reasons i have to say, i have experience with dokuwiki, and deployment, updating, backup and other stuff is super fast (because it doesn't use a database, uses text files and folder schemes), but a being a wiki, is not as friendly to the newbie, because of the special syntax and all Except for Mediawiki, all the wikis I used use plain files or a VCS as their backend. Some wikis come with WYSIWYG ajax editors, but I find it simpler not to teach users much about the wiki syntax, so they mostly write plain text. The minimalistic wikis excel in not tempting users to waste too much time on syntax and concentrate on content instead. [...] If i think about what deplying in rwanda, uganda or even tibet, where the laptop is intended to go. There is no internet there, so their experience should point us to some key features that need to be included in the schoolserver Agreed. I'm sorry this got so long, but there was plenty to be said.. :-) Thanks for taking the time to summarize your first-hand experience, it's much appreciated. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Schoolserver development in Uruguay
El Fri, 20-08-2010 a las 00:51 -0300, Bernie Innocenti escribió: Heh, these are good questions, but answering them all would take quite some time, and it's 1AM over here :-) Meanwhile, my du run to find out the size of current backups completed: # du -sh --exclude datastore-200* /library/backup 92G/library/backup So, backing up the last versions of all journals would take just 92GB, which would take more that 4 days on a 2mbit link for the initial backup. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Clocks on XOs
El Wed, 07-07-2010 a las 01:58 -0400, Kevin Mark escribió: On Tue, Jul 06, 2010 at 05:03:02PM -0400, Bernie Innocenti wrote: PS: I just found yet another laptop which won't activate because the clock was set to 15 July 2000 (not 2010!). Do you see many of these? just a query as I dont know the details of activation: if the rtc is off by a year or more (10 year?) the laptop will not activte using the required activation lease key? so the rtc must be up-to-date to use an activation lease key? Yes, because the leases have an expiration date. (BTW: you dropped my name off the cc list in your reply. This is why I did not notice your question sooner) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Xorg-driver-geode] Update for geode driver
El Mon, 16-08-2010 a las 07:43 +0300, Mart Raudsepp escribió: I don't suggest using NoAccel though, as it loses XVideo and many other non-acceleration (read non-deceleration) related things too. That was just to test whether a particular ExA performance problem would disappear. We have an application called Turtle Art that renders a lot of rounded shapes using Cairo: http://wiki.sugarlabs.org/go/File:TAclock4.png When you drag around a dozen of those bricks on the XO-1 (Geode LX), you get one frame every two seconds. On the XO-1.5 (VIA based), you get fluid 10-20 fps motion. The difference is way too big to be justified by the difference in performance of the CPU or the graphics processor. Any idea? Have you tested rotation (and rotation + Xv) with current GIT code on the older xserver-1.6 found in FC-11 and XO-1 builds? Yes, it worked perfectly now. 90 degrees modes were broken in 2.11.8. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: strange behavior of 'rm'
El Mon, 16-08-2010 a las 01:16 +1000, Sridhar Dhanapalan escribió:
Is manually deleting the /home/olpc/Activities/{activityname}.activity
directory acceptable practice.
The only problem is that Sugar will not notice the change until
restarted.
Likewise, can I safely copy one of those directories from one XO to another?
Yes. But you'd have to restart Sugar to make it see the new activity.
The xo bundles are nothing but glorified zip files that get unpacked by
Sugar in the Activities directory. Simplicity is the only upside of our
crappy packaging format :-)
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: olpc-configure
El Sat, 14-08-2010 a las 02:05 -0500, Jerry Vonau escribió: I've been using OSBuilder to spin up some custom images, I'm just wondering if my XO-1.5 is a little strange or if I uncovered a bug. When olpc-configure is run at first boot and reads the $MFG_DATA in /ofw the LO tag that is returned has en_US.UTF8 in it which will never The LO tag in your laptop is incorrect. It should have been en_US.UTF-8 (with an extra dash). I've already seen another XO-1.5 like this, but it was a pre-production unit. Since you get en_US.UTF-8 either way, I would tend not to bother fixing this bug neither in olpc-configure nor in your mfg-data. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: strange behavior of 'rm'
El Fri, 13-08-2010 a las 09:39 -0500, Mikus Grinbergs escribió: A couple of times I've found that the 'rm' command I issue for this purpose (e.g., from Terminal, while running as root) appears not to work. [The latest occurred on os353pyg - I don't remember which earlier builds I saw it happen on.] I'm mystified: 0 [~]# rm .sugar/default/favorite_activities rm: remove regular file `.sugar/default/favorite_activities'? y 0 [~]# rm .sugar/default/favorite_activities rm: remove regular file `.sugar/default/favorite_activities'? y 0 [~]# rm .sugar/default/favorite_activities rm: remove regular file `.sugar/default/favorite_activities'? y 0 [~]# ls -la .sugar/default/ I can't reproduce it here (os373pyg, but should have same kernel as yours). However, I have an idea: what's the contents of $LANG and $LANGUAGE? The expected answer might not be y :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-update and 10.1.2
El Fri, 06-08-2010 a las 14:02 -0700, S Page escribió: If a USB olpc-update isn't possible, I'll have to flash my XO-1 and lose my work. Release notes say only, Make a copy of any data you wish to keep... how? Knowing that olpc-update was not going to be a viable solution in the field, we worked on making it easy to backup, reflash and restore. Dextrose now comes with an easy to use function to backup and restore your journal to the schoolserver or to a USB stick. In the future, we could enhance the journal UI to allow browsing the entire backup history and moving individual items back to the journal. We've been testing this procedure with 5th and 6th grade children for the past month and it works great after fixing various issues with schoolserver registration. Now, all I have to do to get an entire classroom updated is prepare 3 USB sticks, hand them out to the children and go drink tereré until they return the USB sticks. Sweet! :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Record audio Boot Log: Unknown driver cs5535 Audio
El Sat, 14-08-2010 a las 18:13 -0700, Thomas C Gilliard escribió: Bernie; Regarding Read; You mean Record, right? :-) Get Unknown driver cs5535 Audio on boot screen and in log: -clip 1.754619] geode-aes: GEODE AES engine enabled. [1.781359] Advanced Linux Sound Architecture Driver Version 1.0.20. [1.810118] cs5535audio :00:0f.3: setting latency timer to 64 [1.813869] Failure reading codec reg 0x7e,Last value=0x7e805368 [1.842261] Failure reading codec reg 0x7e,Last value=0x7e805368 [1.878117] ALSA device list: [1.902443] #0: CS5535 Audio cs5535audio at 0x1480, irq 5 [1.930127] TCP bic registered [1.954148] Initializing XFRM netlink socket --clip Do you have the right driver? I don't know much about the XO-1 sound driver. We have the same kernel that OLPC ships in os850. Perhaps pgf can tell us more? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update for geode driver
El Fri, 13-08-2010 a las 10:35 +0800, Huang, FrankR escribió: Bernie, You can git clone the lastest code from freedesktop for geode driver to use. The most outstanding rendering bug has been fixed. And some performance patch has been applied. I tested the driver on the XO-1 and couldn't spot any rendering bug neither in Sugar nor in Gnome, with full acceleration enabled and no quirks needed in xorg.conf. However, a long-standing bug is still there: setting Option NoAccel 1 makes the driver segfault during startup. Thank you very much for taking the time to do this neat work, Frank! (pls forward my notes the geode list, I'm not subscribed) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] ip route in rc.sysinit
El Wed, 11-08-2010 a las 07:41 +1000, James Cameron escribió: I agree with Bernie. I've used /etc/rc.local on previous builds to achieve the same result, though with NetworkManager disabled. You do not *need* the IP default route to be able to do as you suggest, so perhaps there is another need for it that you have not described. I have found that a small delay (or polling) is required between some of the commands; iwconfig, ifconfig, dhclient. Without the delay the dhclient runs slower, because it has to retry. I've been using this script to bring up my network when NetworkManager is broken: http://people.sugarlabs.org/bernie/wlanup DHCP always get the IP at the first try with iwlagn (Intel) and ath9k (Atheros) cards. Overall, it's a lot faster than NetworkManager, which makes me wonder where the extra time is being spent... -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] ip route in rc.sysinit
El Tue, 10-08-2010 a las 09:17 -0300, Esteban Bordon escribió: The script try to connect to the Access Point that have the better signal using iwlist, iwconfig and dhclient. If dhclient return 0 it executes ip route to obtain the server IP and it download a few files. If you set all the access points in the school to the same ESSID, then clients will automatically connect to the AP with best signal and even switch to a different one if you move around (however, since background scanning is slow, you might loose association if you move around too quickly). Regarding the server ip, it would be cool if you could use the DNS. dhcp could configure one nameserver on the client and an automatic search domain. For example, in the school where I'm sitting now I get this in my /etc/resolv.conf: domain escuela485.caacupe.paraguayeduca.org search escuela485.caacupe.paraguayeduca.org nameserver 172.18.0.1 The DNS managed by the schoolserver has a zone called escuela485.caacupe.paraguayeduca.org, in which there's a host schoolserver. With all this infrastructure in place, all you need to do to download a file is: wget http://schoolserver/file This script must to run before user takes control of the OS. My idea is add the script at initrd but later. If the script runs before NetworkManager is started, you might manually configure the network like this: ifconfig eth0 up iwconfig eth0 essid $AP_ESSID key off dhclient eth0 If everything goes well, when dhclient exits you should have a valid, IP, route and DNS. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 12:14 -0400, Bernie Innocenti escribió: El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. Building cairo-1.9.14 and pixman-0.18 went smooth on Fedora 11. They also seem to work fine on the XO. However, I did not notice any visible improvement. In case someone wants to try it out and run some benchmarks, I've uploaded the rpms here: http://people.sugarlabs.org/bernie/olpc/cairo-1.9/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] ip route in rc.sysinit
El Mon, 09-08-2010 a las 16:33 -0300, Esteban Bordon escribió: Hi all, I have a script that execute ip route to get the default gateway. If I run the script when sugar has started works fine, but, I need to run it during boot. I added a line in rc.sysinit calling it, but ip route doesn't prints any data. I tried to add the line in /etc/rc (like I used to in F9-0.82) and it neither prints the route. Any idea? NetworkManager starts after rc.sysinit and remains quiescent until Sugar tells it to connect. So I'm not surprised you don't get any route during boot. I wonder how it could possibly have worked in F9-0.82... -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Plans for a new xs release?
Martin, I was wondering if there are any plans to rebase the schoolserver onto a more recent version of Fedora. We seem to have stability and performance issues with ejabberd bundled with the XS 0.5. Probably also on 0.6, since it's also based on Fedora 9. I've also been running ejabberd on Karmic for a while. Stability has been good for me, but it remains an arcane and hard to manage piece of software. Robert McQueen today proposed switching from ejabberd to Prosody, which supposedly has a more active and helpful upstream. For more info, see http://prosody.im/ . Thoughts? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: MicroSD Card performance variance on XO-1.5
[cc += sugar-devel, tch] El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió: Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. We could do this even without an advanced reporting mechanism. The monitoring code in the CPU Memory meter could detect memory shortage and automatically quit the least recently used activity. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. A while ago, Tincho has been working on implementing the Freedesktop notification protocol in Sugar. This feature didn't make it for Dextrose, but perhaps it could be completed in time to be merged into 0.90. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Killing activities when memory gets short
El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but it has the advantage of being simple and not requiring a particular kernel. Once this is done, switching to a better solution should not require extensive changes to the UI code. BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. +1. This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 18:19 +0200, Tomeu Vizoso escribió: Sounds good, if that gives problems we can consider backporting just that patch. If the small patch below is really what was needed, I'm going to feel quite stupid: http://cgit.freedesktop.org/cairo/commit/?id=022291be1cbddf4f6722f0bf76ebda6922780276 Wait, that can't be everything. Where are all the software operations to work on RGB16_565 surfaces and convert them to/from other formats?!? Wait, I think I know: all the hard code is implemented in pixman. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
El Sat, 07-08-2010 a las 19:33 +0200, Tomeu Vizoso escribió: BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. NM is particularly active when there are more than a few APs available, wonder if it would be possible to tune it to group updates in batches. That would be a good question for Dan (cc'd :-). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Lazy Network Neighborhood updates
El Sat, 07-08-2010 a las 19:36 +0200, Tomeu Vizoso escribió: On a second thought, Sugar should probably only listen to events relevants to what is being currently displayed. This would display outdated data for a short while and would mean significant rework but may be a worthy goal for the future. We already readjust the network neighborhood layout on the fly when we switch view. It's funny to see the access points slide around :-) So, +1 for lazy updates, as long as NM keeps doing its background scanning even when it's not being queried by the client. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Tue, 03-08-2010 a las 16:26 +0200, Tomeu Vizoso escribió: This means that graphic operations would be considerably faster on the XO-1 because to date we are rendering to 24bit surfaces that the X server has to convert to 16bit every time. Fantastic news! In order to benefit in Sugar, do you think we'd have to wait until 16bit surface support is propagated to GTK, libsrvg, hippocanvas, etc? I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
El Fri, 06-08-2010 a las 18:50 +0200, Tomeu Vizoso escribió: I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero spin disk up costs, but slowish writes -- we have to start writing buffers out ASAP. I had also had the impression for some time that some knobs in the kernel could have been better tuned for the XO-1 and the actual workload. That was also my gut feeling. Swappiness also seems to be set too high. We should probably let the OOM killer kick in before the machine becomes totally unresponsive. Tuning the VM knobs is no joke. We could proceed by applying some reasonable changes early in the next development cycle, then sit back and wait for users to tell us their overall impression of using the system as usual. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] devel announce list; publicizing major software firmware updates
El Mon, 19-07-2010 a las 17:32 -0400, Samuel Klein escribió: We have a devel-announce list that hasn't been much used. We also have many people who are interested in getting news about any major release or security update, but don't have time to read all of the traffic that goes to devel. Reuben, Paul and I were discussing this earlier today; I would be happy to see more people using devel-announce to publicize major updates. As there is some demand for this kind of low-traffic list, if you are interested in that information, please sign up. http://lists.laptop.org/listinfo/devel-announce Is this list appropriate also for announcing unofficial builds for the XO, such as the F11-0.88 series? (lately I've become too lazy^W busy to post release notes for our builds...) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os206 - slow data transfers
El Tue, 20-07-2010 a las 16:26 +1000, James Cameron escribió: On Mon, Jul 19, 2010 at 11:41:07PM -0500, Mikus Grinbergs wrote: Earlier, I reported that ethernet data transfers into my XO-1.5 were now running slower than ethernet data transfers into XO-1 systems. I've just tested this, though I only had one ethernet device that I could test with. James and Mikus: what specific ethernet dongle were you using in these tests? Also, what does top say during the test? In particular, what are the percentages of system (sy), i/o wait (wa) and irq servicing (hi)? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
El Thu, 15-07-2010 a las 23:08 -0400, Paul Fox escribió: i think everyone (except apple, i'm learning tonight) agrees this is the correct setup when not in sugar. Lenovo also seems to be switching to the Apple layout: http://www.blogcdn.com/www.engadget.com/media/2010/01/thinkpadedgepost16.jpg http://www.thinkpads.com/wp-content/gallery/lenovo-thinkpad-edge-13-review/lenovo-thinkpad-edge-13-keyboard.jpg Almost all the historic F-key mappings have an alternative CTRL+key or ALT+key mapping in modern HIGs. Keys to control laptop volume and brightness are accessed much more frequently, so it's foreseeable that over time they will supplant the F-keys in PC keyboards. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1 10.1.2 build 301
El Fri, 16-07-2010 a las 07:44 -0600, Daniel Drake escribió: On 15 July 2010 21:31, Bernie Innocenti ber...@codewiz.org wrote: El Wed, 14-07-2010 a las 18:39 -0400, Chris Ball escribió: -NetworkManager-0.7.2.997-2.git20100609.fc11.i586 +NetworkManager-0.7.2.997-2.git20100609.fc11.olpc1.i586 Shouldn't this be .olpc1.fc11? No! Thanks for the clear and exhaustive explanation. I found the rationale here: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1 10.1.2 build 301
El Wed, 14-07-2010 a las 18:39 -0400, Chris Ball escribió: -NetworkManager-0.7.2.997-2.git20100609.fc11.i586 +NetworkManager-0.7.2.997-2.git20100609.fc11.olpc1.i586 Shouldn't this be .olpc1.fc11? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager time sync
El Wed, 07-07-2010 a las 12:20 -0400, Martin Langhoff escribió: Apparently the ntp protocol supports some server-signing of the messages -- we could use an OATS key for that. But it looks rickety. Authenticated NTP sounds like a good solution. NTP4 supports public key cryptography based on SSL certificates. We don't have to reuse the OATS keys for authentication and we also don't have to use the same server for OATS and NTP. Any trusted public ntp server should be fine. Maybe also the school servers. So, how about setting up a public ntp server and publishing the keys? I've already been running two public servers for one year or so: time1.sugarlabs.org time2.sugarlabs.org These are registered with ntp.org. I could generate keys and use them with py builds. Anyone else would be welcome to use our servers, of course. Alternatively, we could simply distribute ntp keys to our xs with puppet. However, this would stop working once the kids leave the school system. In case we opt for using public ntp servers with no authentication, I've also registered olpc.ntp.org (as recommended by someone in this thread). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Thu, 2010-07-08 at 11:02 +0200, Tomeu Vizoso wrote: Congratulations on the excellent work done to date by you all and on the sound (and well communicated) plan. I couldn't agree more. On top of this, interaction between OLPC, the Fedora community and the Sugar Labs community has been fantastically smooth and productive. (this is just my own perception, of course. As always, suggestions to improve our collaboration processes are very welcome). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rainbow
On Wed, 2010-07-07 at 01:18 -0400, Michael Stone wrote: XO and SoaS distributions are configured for sudo with no password. Yes. However, Uruguay does not maintain this configuration choice. I'm very sorry about this. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Raul and I would have liked to resurrect Rainbow in time for F11-0.84, and then for F11-0.88. We asked a couple of times about the current packaging status and what patches still need to be applied in Sugar, but it seemed that there was still too much integration work to be done. and nobody volunteered to work on it. If you check the dates carefully, you'll find that most of my recent work on rainbow and rainbow/sugar integration has occurred while I was on vacation from my real job. So please do count that as volunteer hours. Don't get me wrong, your volunteer work to enhance Rainbow is much appreciated, but it is not by itself sufficient to get Rainbow to work again with Sugar. There seems to be the need for someone who'd be willing to do the missing integration work. People with both Sugar and Rainbow expertise aren't that common. Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then we will all rue the day when we had the opportunity to make it safe and chose not to. I wouldn't worry very much: the attack surface of Sugar from the public Internet is very small: basically, just xulrunner. The LAN of an elementary school is relatively free of advanced crackers. This leaves out only unusual Sugar instances that are being used from home networks connected directly to the Internet. The worst attack vector I can think of would be a malicious activity. I think this is pretty much the same threat of malicious Firefox plugins, and it is being taken care of exactly in the same way. If it becomes Perhaps I'm not being paranoid enough... but anyway, if the situation worsens, we could always restore Rainbow and/or check gpg signatures on installation, like most Linux distros do. A non-privileged account can already effectively do anything that a spammer would like to do. And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch? (Or have you a better approach?) I thought the review got swamped on lkml a long time ago? Or maybe I was dropped off the cc list... Last thing I know, there was disagreement about what the correct approach was and some linux hackers derailed the thread by invoking the stackable LSM bullshit. What matters the most is that nobody thought that the scenario that your patch was trying to address wasn't an interesting one. You might have a chance to get *some* version of your patch approved if you aggressively reply to the nonsense reviews asking the reviewer: - how would you do it instead? - does your alternative effectively address my use-case? - you and X sent conflicting feedback, please sort it out among yourselves and let me know which approach is preferred - who is the authoritative maintainer to ack a patch like this? In a case like yours, the technical side of getting the patch right is very easy compared to mediating among conflicting design goals. I am still much more satisfied with the approach taken by 0install. [2] 0install is a huge leap forward compared to the crap xo bundle format, but still too much prototypal to cover half of our requirements. The biggest flaw is that there's no well-defined build system to obtain binaries from sources, so activities authors would have to setup multiple environments and build manually for all the architectures we intend to support. When you add a new architecture, it takes months or years before most activities become available for it. I've been advocating a proper build cluster for years. Now that OLPC is working on an ARM-based platform, it will be clear to anyone why it was needed. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activity packaging
On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote: Sorry about the confusion, these questions were about the move from xo bundles to packages :( Ah! Communication FAIL! :) Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. To obtain (2) and (7), we might want to wrap the native packages with a distro-neutral meta-format, similar to the current activity.info files. I don't know the details yet, but I guess this is pretty much what Aleksey is doing with his 0sugar redesign. I think switching to a native package format is essential: currently, both the Fedora and Ubuntu teams are spending a lot of time to re-packaging just a few activities, resulting in duplicated effort and increased time-to-market for activities. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Clocks on XOs
On Mon, 2010-07-05 at 08:22 -0600, Daniel Drake wrote: On 3 July 2010 16:52, Bernie Innocenti ber...@codewiz.org wrote: I checked: olpc-update-query only sets the clock if it's off by more than 24hours, so it cannot serve as a replacement for ntpdate. What's the requirement for super-accurate clocks on the XO? It doesn't have to be super-accurate, just good enough to show a clock with a meaningful time. Laptops with anti-theft enabled can get the time from the OATS server when it's off by more than 24 hours. Unlocked laptops don't have a way to synchronize the time at all. All we need to fix it is a trivial shell script. Why not do it? NOTE: whoever is interested in supporting configurations that take away root access from users will probably want to remove this functionality as well. Very sad :-( -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
Err, we've dropped sugar-devel off the cc list again :-) On Mon, 2010-07-05 at 10:37 -0400, Christian Marc Schmidt wrote: We are looking to schedule a design meeting next Saturday (July 10), at 10:30am EST (2:30 UTC/GMT). We'll be reviewing designs for the proposed Start new/Resume functionality in Home view. Please join! This Saturday I'll be in Belo Horizonte, probably without Internet connection. I'll try to join in if I can. Thanks, Christian On Sun, Jul 4, 2010 at 7:05 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-07-04 at 23:42 +0100, Gary Martin wrote: P.S. We keep slipping on a date/time for the next irc #sugar-meeting design meeting, folks are most welcome, Christian has some nice mockups he's been polishing up for publication. We're trying again for tomorrow/Monday, but no time confirmed just yet. Tomorrow (monday) I'll be in Caacupé all day and I might be offline most of the time. Please, give me some advance notice if the meeting is happening tomorrow. p.s. The Journal user-interface was invented, with a filter capability. Now a full screen dialogue user-interface would be duplicating what the Journal can show. I myself am not comfortable with duplication. I agree with Mikus, but I'd like to see the mock-ups -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
