Re: [Sugar-devel] Who's interested in testing a new installer for SoaS?
On Sun, Aug 09, 2009 at 06:14:21AM +0530, Joshua N Pritikin wrote: On Sat, Aug 08, 2009 at 06:00:08PM +0200, Sebastian Dziallas wrote: I'm looking for some volunteers to test the hard disk installation with the latest SoaS snapshot and newly designed installer. I'm planning to load the latest snapshot on two XO-1 laptops using Option 3 described here: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC Will that work? The answer is no. Now I have an XO laptop that doesn't boot. It shows the XO man and that's it. How do I debug this? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Who's interested in testing a new installer for SoaS?
On Sun, Aug 09, 2009 at 02:27:51PM +0530, Joshua N Pritikin wrote: The answer is no. Now I have an XO laptop that doesn't boot. It shows the XO man and that's it. How do I debug this? I held down the Check button so I could see the boot messages. Maybe I haven't waited long enough. It stopped at creating devices (after starting udevd). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Who's interested in testing a new installer for SoaS?
On Sun, Aug 09, 2009 at 02:46:50PM +0530, Joshua N Pritikin wrote: A few lines up from the last boot message, it says: mount: unknown filesystem type 'jffs2' That can't be a good sign. I got the same failure with the Strawberry release. Has anybody realized success with Option 3? http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login)
Ton van Overbeek wrote: Regarding getting auto-login to work after restarting X. Yesterday I looked at the slim sources and it seems at first sight easy to add auto login of the default user after the first login. Any interest in me trying to implement this? If we use an extra option to slim we could push this change upstream to Fedora and then we do not have to maintain our own manager (olpc-dm). But maybe Sebastian is already happy with a working olpc-dm. Ton van Overbeek Ahhh! Sorry, I missed this entirely and just noticed it in another folder when going through my e-mail today. Well, I certainly wouldn't mind if you went ahead and gave it a try, but I'm not sure how likely it is that this change would be accepted, pushed into a release and then packaged for Fedora. Well, you're right, I'm happy with a working olpc-dm, but I'm also always looking for ways to improve SoaS... ;) Thanks a lot, --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Who's interested in testing a new installer for SoaS?
Joshua N Pritikin wrote: On Sun, Aug 09, 2009 at 02:46:50PM +0530, Joshua N Pritikin wrote: A few lines up from the last boot message, it says: mount: unknown filesystem type 'jffs2' That can't be a good sign. This is indeed not a good sign. We've had this some time ago with the Rawhide-XO builds. Apparently, it affects our general images, too. See for the report: https://bugzilla.redhat.com/show_bug.cgi?id=500196 Martin Dengler has been building special builds of SoaS for the XO, which we should probably get out soon. Martin, what's the current state of that, can we put 'em up? :) I got the same failure with the Strawberry release. Has anybody realized success with Option 3? http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC I wasn't aware of the fact that it affects us directly, but it looks like we might need to clean up our docs at some point... Sorry for the issues, --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login)
Sorry, I was once again victim of GMail's interface and answered only to Sebastian instead of to the list. -- Forwarded message -- From: Mathieu Bridon (bochecha) boche...@fedoraproject.org Date: Sun, Aug 9, 2009 at 19:05 Subject: Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login) To: Sebastian Dziallas s...@sugarlabs.org Hi, On Sun, Aug 9, 2009 at 19:00, Sebastian Dziallas wrote: Ton van Overbeek wrote: Regarding getting auto-login to work after restarting X. Yesterday I looked at the slim sources and it seems at first sight easy to add auto login of the default user after the first login. Any interest in me trying to implement this? If we use an extra option to slim we could push this change upstream to Fedora and then we do not have to maintain our own manager (olpc-dm). But maybe Sebastian is already happy with a working olpc-dm. Ton van Overbeek Ahhh! Sorry, I missed this entirely and just noticed it in another folder when going through my e-mail today. Well, I certainly wouldn't mind if you went ahead and gave it a try, but I'm not sure how likely it is that this change would be accepted, pushed into a release and then packaged for Fedora. One thing to keep in mind: it would have to be actually accepted *upstream* before it can go in Fedora. Also, Rawhide is now frozen for F12Alpha, so even if that's accepted upstream, if you want this change in Fedora 12, you'll have to ask a freeze break to Rel-Eng. [1] Better do it quick :) Best regards, [1] http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Deployment feedback braindump
Hi, In response to the thread I started recently about feedback from deployments, I've been thinking a lot about specific changes/features that would be a big help for deployments. And even though it only takes 10 minutes in a classroom to see some real potential areas for improvement, actually I am finding the task of selecting a few important features/bugs/changes very difficult, and I keep coming back to various broad questions and loose ideas about Sugar's direction, goals, and SugarLabs' roles. So I'm afraid that I'm creating another vague, broad and fluffy discussion without any real immediate technically actionable items, but I'm going to try and put my thoughts into writing anyway. Suggestions on how to make some of these ideas actionable would be appreciated. I fully understand that nobody can really define Sugar's direction at the moment since it's all volunteer time, but hopefully we can at least get some objective things written down which will possibly feed the motivation of our valued hackers. I'll start with roles. Sugar was born inside the belly of OLPC, and SugarLabs was born out of OLPC, effectively taking some roles of OLPC and further opening them to a community. So, in terms of roles, you might look at this as OLPC being top of the food chain (I'm referring to the times when OLPC had a substantially larger technical team), with SugarLabs below doing some specific subset of OLPC's earlier work (i.e. developing the UI), and finally deployments below being the consumers. But actually I think it makes sense for this model to be considered differently, as follows: SugarLabs is the top of the chain, it is the upstream that generates the core user experience. One step down, OLPC as an implementation specialist (again referring to the time when the development team was more substantial) takes Sugar from upstream, makes some small customizations to fit the OLPC mission, and fills in some big gaps of OS development and support, deployability and scalability, distribution, hardware work and software to support such hardware, user support, etc. Then the deployments feed directly from OLPC, not sugarlabs. In this model, OLPC performs a huge chunk of support for sugar's users. I think this model was working reasonably well (and was improving over time) but the middle layer (OLPC) has now changed to the point where it is not performing many of the roles mentioned above, or at least not in much capacity. So who can take over this work? It is certainly very important. My gut feeling is that SugarLabs should - but that really is only because (1) a number of the OLPC people who would be involved in the above roles are no longer OLPC people, but they are still sugarlabs contributors, and (2) there are no other good candidate parties that I can think of, so I naturally have desires that the one that I do know of pick up the work ;) These might not be considered good reasons, but it seems that sugarlabs was designed with the consideration of having OLPC performing a great deal of support on its behalf, and I don't recall seeing any proposed change of SugarLabs' direction in response to OLPC's recent restructuring. I've only written about OLPC so far, although it's clear that SugarLabs is aimed at a broader audience. And in persuit of these efforts, SugarLabs has started muddying the waters by taking on (in small scale) some of OLPC's prior roles -- namely becoming a OS builder (e.g. SoaS) and a deployment implementer (e.g. GPA). Sometimes I even see hints of broadening even further, for example, in a SoaS meeting recently I saw some interest in SugarLabs becoming involved in improving Linux support for hardware chipsets -- a problem that half the friggin' world is already working on. So: which roles is SugarLabs trying to fill? Although I know that SugarLabs is trying hard to broaden beyond OLPC deployments, I'm going to throw in a couple more comments along OLPC-specific lines anyway: if SugarLabs is going to continue to be a deployment implementer, i.e. doing anything and everything required to make places like GPA work, then I would encourage the interested people to not forget about OLPC deployments. With a bit of determination, it is possible to get yourself to these places. And with a reduction of support from OLPC themselves, they would really benefit from your help. Unlike most new Sugar deployments they have often already solved various problems related to logistics, finance, politics and scale, so you could focus directly on the Sugar experience. The next item that keeps coming up in my thoughts is that of aims and objectives for the platform, in a technical sense. OLPC still has a set of 5 clear principles that have stuck from early on, and have really really really taken root at deployments. I was always impressed with OLPC's focus on considering the scalability of any new technology entering the platform (i.e. we're going to be replicating this A LOT - will it work in numbers?),
[Sugar-devel] SoaS-for-XO-1 image (was Re: Who's interested in testing a new installer for SoaS?)
On Sun, Aug 09, 2009 at 07:04:06PM +0200, Sebastian Dziallas wrote:
Martin Dengler has been building special builds of SoaS for the XO,
which we should probably get out soon. Martin, what's the current state
of that, can we put 'em up? :)
Adventurous people can copy-nand:
http://people.sugarlabs.org/~mtd/soas-xo1/soasxo50.{img,crc}
--Sebastian
Martin
pgpRGKSCOuO18.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] bender: new uplink change of IP, Aug 8 18:30 CEST
El Sat, 08-08-2009 a las 18:00 +0200, Bernie Innocenti escribió: We could also add IPv4 port forwarding for the VMs, but I expect that 6to4 won't be as unreliable as the sixxs.net service has been. I added an A record for bender.sugarlabs.org alongside the existing record. Yesterday night I made some experimentation with 6to4 and it seems to work beautifully. I took this route down for the time being as I still need to figure out a new strategy to assign addresses to the VMs within the smaller /16 subnet provided by 6to4, which is too small for MAC-address based IP autoconfig. One becomes easily spoiled with all this IPv6 goodness, to the point that the equivalent of an IPv4 class B net now seems way too restrictive :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1146 UNSP: (Default) Text is too small. This can be easily seen even on the (SoaS) login screen.
This happens on all text (i.e., not-image) display, to my knowledge. Obvious examples are the Log and Terminal Activities. The most problemmatic examples are when text is used in a PyGTK boxed context (such as the 4 activities included in Victor Lazzarini's csndsugui project). Basically text appears (in SoaS) to be the same font-size as on the XO-1, where it is appropriate. Somehow text is not being appropriately rescaled (or whatever the appropriate term is) for larger screens. Art Hunkins - Original Message - From: SugarLabs Bugs bugtracker-nore...@sugarlabs.org Cc: b...@lists.sugarlabs.org Sent: Sunday, August 09, 2009 5:22 AM Subject: Re: #1146 UNSP: (Default) Text is too small. This can be easily seen even on the (SoaS) login screen. #1146: (Default) Text is too small. This can be easily seen even on the (SoaS) login screen. --+- Reporter: abhunkin | Owner: tomeu Type: defect | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar |Version: 0.84.x Severity: Unspecified| Resolution: Keywords: | Distribution: SoaS Status_field: Unconfirmed| --+- Comment(by tomeu): Does this happen with all activities? Or only some are affected? -- Ticket URL: http://dev.sugarlabs.org/ticket/1146#comment:2 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS-for-XO-1 image (was Re: Who's interestedin testing a new installer for SoaS?)
Is there any other way in which the XO-1 will ever be updated (in respect to Sugar) - beyond build 802? Art Hunkins - Original Message - From: Martin Dengler mar...@martindengler.com To: Sebastian Dziallas s...@sugarlabs.org Cc: sugar-devel@lists.sugarlabs.org; Joshua N Pritikin jpriti...@pobox.com Sent: Sunday, August 09, 2009 3:14 PM Subject: [Sugar-devel] SoaS-for-XO-1 image (was Re: Who's interestedin testing a new installer for SoaS?) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Who's interested in testing a new installer for SoaS?
On Sun, Aug 09, 2009 at 07:04:06PM +0200, Sebastian Dziallas wrote: Joshua N Pritikin wrote: I got the same failure with the Strawberry release. Has anybody realized success with Option 3? http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC I wasn't aware of the fact that it affects us directly, but it looks like we might need to clean up our docs at some point... Thanks for your candid admission. I noted the problem on the wiki. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
On Sun, Aug 9, 2009 at 10:41 AM, Daniel Draked...@laptop.org wrote: Sugar currently doesn't even have support for the library bundle technology which was adopted by various sugar deployments, as it doesn't have a way of accessing the index.html pages short of typing in the file path in Browse. (the functionality of olpc-library needs to become part of the sugar platform, in some form) That's http://dev.sugarlabs.org/ticket/574 The proposed Sugar Labs replacement is quite different , http://wiki.sugarlabs.org/go/Activities/Library and the Unified Browser / Unified Objects proposals. It still seems like the best way to get a class of kids on the same page is to start at some web page, like http://wiki.laptop.org/go/XS_Moodle_design#Straight_into_the_course_and_current_content adding an interactivity component that would be impossible to have when working with paper-based exercise books. And impossible with PDFs. But interactive HTML pages, cached locally using Google Gears or HTML5 local storage so you can work through the exercises in or out of school... it sounds plausible. Never bet against the browser. Cheers, -- =S Page ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1146 UNSP: (Default) Text is too small. This can be easily seen even on the (SoaS) login screen.
I am curious as to how Turtle Art behaves in your tests. (I include a scaling factor which is different for non-OLPC-XO displays.) -walter On Sun, Aug 9, 2009 at 3:59 PM, Art Hunkinsabhun...@uncg.edu wrote: This happens on all text (i.e., not-image) display, to my knowledge. Obvious examples are the Log and Terminal Activities. The most problemmatic examples are when text is used in a PyGTK boxed context (such as the 4 activities included in Victor Lazzarini's csndsugui project). Basically text appears (in SoaS) to be the same font-size as on the XO-1, where it is appropriate. Somehow text is not being appropriately rescaled (or whatever the appropriate term is) for larger screens. Art Hunkins - Original Message - From: SugarLabs Bugs bugtracker-nore...@sugarlabs.org Cc: b...@lists.sugarlabs.org Sent: Sunday, August 09, 2009 5:22 AM Subject: Re: #1146 UNSP: (Default) Text is too small. This can be easily seen even on the (SoaS) login screen. #1146: (Default) Text is too small. This can be easily seen even on the (SoaS) login screen. --+- Reporter: abhunkin | Owner: tomeu Type: defect | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar | Version: 0.84.x Severity: Unspecified | Resolution: Keywords: | Distribution: SoaS Status_field: Unconfirmed | --+- Comment(by tomeu): Does this happen with all activities? Or only some are affected? -- Ticket URL: http://dev.sugarlabs.org/ticket/1146#comment:2 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS-for-XO-1 image (was Re: Who's interestedin testing a new installer for SoaS?)
On Sun, Aug 9, 2009 at 6:00 PM, Art Hunkinsabhun...@uncg.edu wrote: Is there any other way in which the XO-1 will ever be updated (in respect to Sugar) - beyond build 802? Future passive voice and open source together have infinite possibilities ;-) If you read http://wiki.laptop.org/go/Future_releases : OLPC is developing a Fedora 11 Remix for the XO-1.5 hardware, see [F11 for 1.5]. Community volunteers are adapting this work to create images that run on the [XO-1] hardware, see [F11 for XO-1]. These builds have been announced and discussed on the OLPC devel and Fedora-olpc mailing lists. I think one difference is these F11 builds also include a Gnome desktop as a Sugar alternative. Regards, -- =S Page ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Physics] egg libraries sorted -- Journal JSON saving addition, then release?
Hi all, I manually included pkg_resources.py from setuptools so that pythons 2.6.x would still be supported using the .egg libraries. Then released and included new Elements (0.13) which is Asaf's JSON changes. Gary or others -- can you test that the .egg-fest I committed works on SoaS (python 2.6?) and/or on XO (python 2.5)? Asaf -- anything left for the physics activity portion of JSON saving? Thanks again to both of you for your amazing work. Still need to do some testing/playing, but the roll tool seems great! :) Brian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS-for-XO-1 image
On Sun, Aug 09, 2009 at 08:14:12PM +0100, Martin Dengler wrote:
Adventurous people can copy-nand:
http://people.sugarlabs.org/~mtd/soas-xo1/soasxo50.{img,crc}
This is quite close to usable!
* It mounts USB keys.
* Sound works.
* The font size is tolarable.
The only critical bug I found after brief testing is that sometimes the
menus get stuck on the screen. This is fairly reproducable. If you allow
the full menu to appear in the home view and then move the mouse out of
the menu quickly then sometimes the menu remains stuck on the screen
indefinitely.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
