Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Thu, Feb 12, 2009 at 6:47 PM, wrote: > When starting up, call seed_xs_cookie() to Hi Simon, Hoping for some review :-) . Do you think this patch can make it into the sucrose-0.82 branch? With a tad of elbow grease, it also applies on top of master. The reason I ask for it on the 0.82 branch is that - It's low low risk -- in fact, the interesting ops are wrapped in a try/except block so a failure won't stop Browse from starting up. - It allows me to do a XS 0.5.2 or 0.6 relatively soon that integrates smoothly with the XO 0.8.2.x series. Deployments can ensure that they have an updated Browse.xo... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
From: Martin Langhoff
When starting up, call seed_xs_cookie() to
try to add a cookie for the XS with
- the hashed pubkey of the XO - the sha1 hash
is much smaller than the whole pubkey
- the XO colors
---
webactivity.py | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/webactivity.py b/webactivity.py
index e17d3b2..f3bc87a 100644
--- a/webactivity.py
+++ b/webactivity.py
@@ -26,6 +26,8 @@ import sha
import base64
import time
import shutil
+import sqlite3
+import cjson
from sugar.activity import activity
from sugar.graphics import style
@@ -98,6 +100,10 @@ class WebActivity(activity.Activity):
self._browser = Browser()
+# call after browser init
+# to ensure the storage dir exists
+self.seed_xs_cookie()
+
temp_path = os.path.join(self.get_activity_root(), 'instance')
downloadmanager.init(self._browser, self, temp_path)
sessionhistory.init(self._browser)
@@ -482,3 +488,72 @@ class WebActivity(activity.Activity):
downloadmanager.remove_all_downloads()
self.close(force=True)
+def seed_xs_cookie(self):
+
+_logger.debug('seed_xs_cookie')
+db_path = os.path.join(_profile_path, 'cookies.sqlite')
+
+# have we registered with the XS?
+prof = profile.get_profile()
+# profile.jabber_registered is old and buggy
+# - check for jabber_server instead
+if not prof.jabber_server:
+_logger.debug('seed_xs_cookie: not registered yet')
+return
+
+xs_fqdn = prof.jabber_server
+
+# the XS wants a unique identifier - it has
+# the SN and the pubkey. The pubkey is a bit
+# less widely known than the SN. Hash it to
+# make it shorter (590 chars to 40).
+cookie_data = { 'color': prof.color.to_string(),
+'pkey_hash': sha.new(prof.pubkey).hexdigest() }
+
+ # gecko creates the DB at startup
+ # so we seed it after Browse() is invoked
+_logger.debug('cookies file:' + db_path)
+
+try:
+jar_db = sqlite3.connect(db_path)
+c = jar_db.cursor()
+_logger.debug('opened file')
+
+# gecko delays creating the table
+# until it gets a cookie...
+c.execute('''CREATE TABLE IF NOT EXISTS
+ moz_cookies
+ (id INTEGER PRIMARY KEY,
+ name TEXT,
+ value TEXT,
+ host TEXT,
+ path TEXT,
+ expiry INTEGER,
+ lastAccessed INTEGER,
+ isSecure INTEGER,
+ isHttpOnly INTEGER);''')
+
+c.execute('''SELECT id
+ FROM moz_cookies
+ WHERE name=? AND host=? AND path=?''',
+ ('xoid', xs_fqdn, '/'))
+
+# the row exists, we're done
+if c.fetchone():
+_logger.debug('cookie exists')
+return
+
+expire = int(time.time()) + 10*365*24*60*60
+c.execute('''INSERT INTO moz_cookies (name, value, host,
+ path, expiry, lastAccessed,
+ isSecure, isHttpOnly)
+ VALUES(?,?,?,?,?,?,?,?)''',
+ ( 'xoid', cjson.encode(cookie_data), xs_fqdn,
+'/', expire, 0,
+0, 0 ))
+jar_db.commit()
+jar_db.close()
+_logger.debug('updated cookies successfully')
+except:
+_logger.error('error seeding cookies file')
+
--
1.5.6.6
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] etextRead activity and espeak
Hi, The educational team at OLENepal would like a 'karaoke-style' text reader above all other activities on the XO. This is primarily for English. Looking at the activity code, it looks like the speech code is there but disabled. Would it be possible to release a version that supports espeak without the Speech-Dispatcher pending its implementation in Sugar? This would give us a chance to experiment with creating 'read-aloud' stories. Tony > Thanks for your response. I never questioned that there was still > interest in TTS on the XO. What I was wondering is if there was any > progress made by Hemant Goyal or anyone else in getting the > Speech-Dispatcher software included with the Sugar distribution, if the > newer version of Python that resolved the power management issue was > included, etc. I've sent a couple of emails to Hemant and haven't heard > back from him. I was wondering if he was still working on these things, > or if someone else had taken over his work, etc. He was making RPMs for > Fedora for installing speech-dispatcher. > > James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities migration status
On Wed, Feb 11, 2009 at 8:34 PM, David Farning wrote: > On Thu, Feb 12, 2009 at 7:27 PM, Samuel Klein wrote: >> Is there no way to move/create an activity so that the same code push >> will update both sl's gitorious and olpc's git? >> >> Until there is a policy of sorts in place, and better yet an endowment >> supporting long-term maintenance of a server hosting projects (one of >> the two mentioned so far in this thread, or a dedicated >> project-hosting service elsewhere), I would focus on creating good >> mirrors, rather than on picking any particular single host. There is >> currently still risk of losing people's work. > > While you wait for a best case scenario We will continue to move > forward one step at a time. I was replying to the idea that people move backwards, and not mirror their code. SJ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities migration status
On Thu, Feb 12, 2009 at 7:27 PM, Samuel Klein wrote: > Is there no way to move/create an activity so that the same code push > will update both sl's gitorious and olpc's git? > > Until there is a policy of sorts in place, and better yet an endowment > supporting long-term maintenance of a server hosting projects (one of > the two mentioned so far in this thread, or a dedicated > project-hosting service elsewhere), I would focus on creating good > mirrors, rather than on picking any particular single host. There is > currently still risk of losing people's work. While you wait for a best case scenario We will continue to move forward one step at a time. david > SJ > > On Wed, Feb 11, 2009 at 3:39 PM, Luke Faraone wrote: >> On Wed, Feb 11, 2009 at 3:26 PM, Samuel Klein wrote: >>> >>> I like that part. Are there criteria for removing someone's project >>> if it's deemed inappropriate? >> >> Not yet, but I assume if someone thinks that somebody else's use of SL >> infrastrucutre is not under the project scope we'll discuss it on the >> sugar-devel or IAEP mailing list. >> >> -- >> Luke Faraone >> http://luke.faraone.cc >> > ___ > 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] Activities migration status
Is there no way to move/create an activity so that the same code push will update both sl's gitorious and olpc's git? Until there is a policy of sorts in place, and better yet an endowment supporting long-term maintenance of a server hosting projects (one of the two mentioned so far in this thread, or a dedicated project-hosting service elsewhere), I would focus on creating good mirrors, rather than on picking any particular single host. There is currently still risk of losing people's work. SJ On Wed, Feb 11, 2009 at 3:39 PM, Luke Faraone wrote: > On Wed, Feb 11, 2009 at 3:26 PM, Samuel Klein wrote: >> >> I like that part. Are there criteria for removing someone's project >> if it's deemed inappropriate? > > Not yet, but I assume if someone thinks that somebody else's use of SL > infrastrucutre is not under the project scope we'll discuss it on the > sugar-devel or IAEP mailing list. > > -- > Luke Faraone > http://luke.faraone.cc > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Auto-authentication for Browse -
On Wed, Feb 11, 2009 at 11:18 PM, Martin Langhoff wrote: > On Wed, Feb 11, 2009 at 10:25 PM, Andrés Ambrois >> I might be missing something, but you're storing the laptop serial number >> instead of the pubkey inside the cookie (unless /ofw/mfg-data/SN doesnt >> stores a pubkey), which was the original plan C. > > Good point. I didn't refer back to the spec. I think SN and the pubkey > are roughly equal in this situation > > - the XS has both > - if a 3rd party sniffs the cookie from the ether... is either of > them more damaging than the other? Having slept on this, I think it's better to use a hash of the pubkey. The SN known by other XOs without sniffing, as all the XMPP traffic has it as your username/jid. The pubkey hash is less widely known. Fleshing out a new patch... m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What's going on with Text To Speech on the XO?
Hemant, Tomeu, Assim and all, Has there been any progress on TTS since last summer? I'd love to see this project move forward. Prabhas has also indicated some interest in working on language-learning support, which is directly related... It would also be nice to have Listen and Spell among the regularly tested activities. SJ On Tue, Dec 16, 2008 at 4:22 PM, James Simmons wrote: > Ed, > > Thanks for your response. I never questioned that there was still > interest in TTS on the XO. What I was wondering is if there was any > progress made by Hemant Goyal or anyone else in getting the > Speech-Dispatcher software included with the Sugar distribution, if the > newer version of Python that resolved the power management issue was > included, etc. I've sent a couple of emails to Hemant and haven't heard > back from him. I was wondering if he was still working on these things, > or if someone else had taken over his work, etc. He was making RPMs for > Fedora for installing speech-dispatcher. > > James Simmons > > Edward Cherlin wrote: >> Welcome back. There is significant interest from other organizations >> in our use of TTS with text coloring. I have just started discussions >> with the Doug Engelbart Foundation, Creative Commons ccLearn, Alan >> Kay's Viewpoints Research, and OLE about a new project to create a >> full range of teaching materials around Sugar. TTS-TC is important for >> literacy, of course, and also for language learning. >> >> >> > > ___ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] FlipSticks-2
On Wed, Feb 11, 2009 at 10:17:08PM +, Aleksey Lim wrote: == Source == [...] == Bundle == [...] == NEWS = [...] Feature request: please add a link to a description of the activity (e.g. [1] in this case) to release announcements. Even better: add a short description (e.g. the "Summary" section of [1]) in text form as well. [1] http://wiki.laptop.org/go/Flipsticks CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] FlipSticks-2
== Source == http://download.sugarlabs.org/sources/honey/FlipSticks/FlipSticks-2.tar.bz2 == Bundle == http://download.sugarlabs.org/sources/honey/FlipSticks/FlipSticks-2.xo == NEWS = * OLPC#4740 Implement collaboration * OLPC#6892 GPL requirements * OLPC#9183 COPYING file is missed * OLPC#9166 adapt to non-XO screen resolution -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Fwd: [PyCon-Organizers] Open government sprint?
On Wed, 11 Feb 2009, Edward Cherlin wrote: > Is anybody going to PyCon? We have booth space and could use coders > and mentors for the sprints. I will be there. --g ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 03:38:04PM -0500, Luke Faraone wrote: >On Wed, Feb 11, 2009 at 2:56 PM, Jonas Smedegaard wrote: >> >> No need to get into details of what exactly is flawed with my >> packaging style, or how you would do things differently: > > >I'm just trying to see if I'm missing something as far as the workflow. You insist that these Debian-specific details should be shared with Bert, the Sugarlabs pedagogical list and the Sugarlabs development list. Very well... >Simply put, the commands given in your README do *not* work at all >without additional undocumented steps. Thanks for clarifying: My packaging style *is* documented, just incomplete. Others have found those shitty, half-baked incomplete notes useful. You have ignored help offered at the OLPC mailinglist at Alioth. Your only interest seems to be in upgrading core Sugar libraries to the unstable branch, not starting out with simple activities. My packaging style consists of git-buildpackage and CDBS, as you seem well aware. Both are in themselves rather well documented. Go read that documentation if you dislike mine. Or don't: You can package other packages using other packaging styles if you wish - just don't expect me to help you out with that. And don't try to change packaging style of existing packages. >> 3) Others are still free to follow my recommendation: Package through >> Debian, not directly at their pet derived distribution, to avoid >> duplicated work. >> > >We tried that, however you stated that you wanted to continue to use >0.82 for now. You complain that the packaging is too complex, yet you need even more complexity to track not only latest stable branch but also HEAD. Or more likely: you want us to package in the pace of Ubuntu release cycle (latest stable, except when Ubuntu is far from next release). Sorry, can't help you there. Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmTTFMACgkQn7DbMsAkQLiK2ACeLvHOc0sigRrhQjjqglnLbY+5 wAUAoJBO7W5jhIiyvlxuyYlIwU80pvC8 =Gl2y -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Build intrastructure
On Thu, Feb 12, 2009 at 10:28 AM, Bernie Innocenti wrote: > [cc += sugar-de...@] > > Marco Pesenti Gritti wrote: >>> As Peter suggested, I should look at getting nightly builds set up soon. >>> Would you like to share infrastructure so that the build run spits out >>> SoaS images at the same as F11-XO images? If so, any preference for >>> whether to do it on an OLPC machine or on something like sunjammer? >> >> Sharing infra on this makes a lot of sense to me. Personally I have no >> preference about where to host it. Bernie, what do you think? Is this >> something we can host? I guess we will need a rawhide box/VM. > > We can provide shell accounts on our buildslaves to anyone interested > in running nightly builds. We currently have 4 of them: > > buildslave1.sugarlabs.orgFedora 10 x86_64 > buildslave2.sugarlabs.orgFedora rawhide x86_64 > buildslave3.sugarlabs.orgOFFLINE > buildslave4.sugarlabs.orgUbuntu 8.10 Marco, Correct me if I am wrong: bs1 is working correctly bs2 has a kernel version issue. It works fine as a build bot, but your can run soas from it bs3 is down bs4 is now online, running as a buildbot. I can create users as necessary on these machines. So, we can let Bernie can focus on real 'developer' issues:) david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] buildbot failure in Sugar Labs Buildbot on sugar-base-Ubuntu804
The Buildbot has detected a failed build of sugar-base-Ubuntu804 on Sugar Labs Buildbot. Full details are available at: http://buildbot.sugarlabs.org/builders/sugar-base-Ubuntu804/builds/0 Buildbot URL: http://buildbot.sugarlabs.org/ Buildslave for this Build: Ubuntu804 Build Reason: Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: [PyCon-Organizers] Open government sprint?
Is anybody going to PyCon? We have booth space and could use coders and mentors for the sprints. -- Forwarded message -- From: Edward Cherlin Date: Wed, Feb 11, 2009 at 1:53 PM Subject: Re: [PyCon-Organizers] Open government sprint? To: Jacob Kaplan-Moss Cc: Massimo Di Pierro , "pycon-organiz...@python.org" On Wed, Feb 11, 2009 at 1:45 PM, Jacob Kaplan-Moss wrote: > On Wed, Feb 11, 2009 at 3:42 PM, Massimo Di Pierro > wrote: >> Where can find a list of proposed sprints? > > http://us.pycon.org/2009/sprints/projects/ What, no Sugar? Well, then, I'll propose it. I'm rewriting the Python definitions of Turtle Art tiles to enable demonstrations of an assortment of math and Computer Science capabilities. There is plenty of other work needed on other Sugar Activities written in Python. We need a generic framework that handles collaboration and interactions with the Journal and with the Moodle course management system, so that Activity developers can concentrate on what the Activity is supposed to do. We should also have some Activity frameworks where teachers or students can add graphics and math, say, without any explicit programming. > Jacob > ___ > PyCon-organizers mailing list > pycon-organiz...@python.org > http://mail.python.org/mailman/listinfo/pycon-organizers > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai (Ed Cherlin) -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai (Ed Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] buildbot failure in Sugar Labs Buildbot on GConf-dbus-Fedora10
The Buildbot has detected a failed build of GConf-dbus-Fedora10 on Sugar Labs Buildbot. Full details are available at: http://buildbot.sugarlabs.org/builders/GConf-dbus-Fedora10/builds/75 Buildbot URL: http://buildbot.sugarlabs.org/ Buildslave for this Build: Fedora10 Build Reason: Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed GConf-dbus build sincerely, -The Buildbot ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
Yes, I guess there is no problem with this, with the already given infrastructure give by SL is more than enough. Local Labs are independent enough to manage to have other services. Rafael Ortiz On Wed, Feb 11, 2009 at 12:48 PM, David Farning wrote: > On Thu, Feb 12, 2009 at 11:33 AM, Tomeu Vizoso > wrote: > > On Wed, Feb 11, 2009 at 18:29, David Farning > wrote: > >> On Thu, Feb 12, 2009 at 10:39 AM, Tomeu Vizoso > wrote: > >>> Maybe the issue here is that local labs have a much broader scope than > >>> the global Sugar Labs? > >> > >> I agree completely. Hopefully the local labs will focus in on a > >> particular area of the sugar ecosystem. A testing lab, a deployment > >> support organization, educational content development As such they > >> will dive much deeper into a particular area then sl can. > >> > >>> I see local labs having something to say about everything that the > >>> global Sugar Labs does, but not the other way around. > >> > >> Yes, but this discussion is about what services SL will provide for > >> the local labs. > >> > >> Local labs can do whatever they want, upstream SL has to make hard > >> decisions about which 'things' we can 'afford' to support. > >> > >> At this point in terms of infrastructure we can offer local labs: > >> email account, mailing lists, a instance of our existing wiki setup. > >> Anything else become to much work for our already overwork > >> infrastructure team. > >> > >> This ends up being very similar to the deployment support issues we > >> are facing. We are facing some hard issues about how we can _best_ > >> use our limited resources to improve the entire Sugar ecosystem. > > > > Right, that was the point I was trying to make: the SL's > > infrastructure is likely to not serve all the needs of all the local > > labs. > > > > Regards, > > > > Tomeu > > Sorry for misunderstanding your point. So many people and > organizations have been asking us for support since the changes at > OLPC that I am getting prickly about the issues:) > > david > > >> David > >> > >>> Regards, > >>> > >>> Tomeu > >>> > >>> On Wed, Feb 11, 2009 at 17:35, Rafael Enrique Ortiz Guerrero > >>> wrote: > Thank you for your thoughts on this, > > I was thinking in a cms not for communication fork but for > presentation > fork. > > Anyway we are still too young, but for the future we might want to > think in > having this static solutions in place. (i.e when we have people that > can > work on maintaining the infrastructure needed etc). > > > Rafael Ortiz > > > On Wed, Feb 11, 2009 at 11:15 AM, Sebastian Silva > wrote: > > > > I see your point about CMS being overkill. > > > > And I also agree with you, the release cycle anchors everything. > > > > I for one consider it a bug, not a feature, that we have this > division of > > channels of communication, as some of the aspects you relate should > be > > feeding each other more. > > > > It is natural because of the different workflows, however I'd like to > see > > some convergence. > > > > I'm studying the possible use of a social networking platform (pretty > much > > deciding on http://pinaxproject.com/ ). > > > > If I can tweak it to fit our workflows (I'm working with local > village > > visiting teachers to fit theirs) - in particular, i'm interested in > > including some sort of disconnected use (that is, for instance, > getting them > > a "news/mailing list/new activities feed" from the social network > with a USB > > monthly, and provide them with a way to "respond" - can be email - > can be > > manually performed once online. > > > > This is likely also the tool that will help manage the Bolivia > deployment > > (but we will likelly have some more connectivity in Bolivia). > > > > Looking forward to share more as things develop, looking for feedback > / > > synergy. > > > > Sebastian > > > > 2009/2/11 David Farning > >> > >> I tend to think that a cms is a bit of overkill for a young > organization. > >> > >> One of my personal long term goal is to determine how we can clone > SL > >> in Local SLs by reproducing the best practices of SL on a more local > >> scale. > >> > >> Developer side: > >> 1. The key component is the release cycle, ever thing else is > anchored > >> around the release cycle. > >> 2. Dynamic communication through mailing lists and irc. > >> 3. Static communication through wiki and bug tracker. > >> Any thing else is overkill > >> > >> Educator side: > >> 1. Release cycle - cool new features, bug fixes > >> 2. Moodle - teachers know moodle > >> > >> david > >> > >> On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero > >> wrote: > >> > Hello all. > >> > > >> > I was thinking that maybe S
Re: [Sugar-devel] Activities migration status
On Wed, Feb 11, 2009 at 3:26 PM, Samuel Klein wrote: > I like that part. Are there criteria for removing someone's project > if it's deemed inappropriate? Not yet, but I assume if someone thinks that somebody else's use of SL infrastrucutre is not under the project scope we'll discuss it on the sugar-devel or IAEP mailing list. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On Wed, Feb 11, 2009 at 2:56 PM, Jonas Smedegaard wrote: > > No need to get into details of what exactly is flawed with my packaging > style, or how you would do things differently: I'm just trying to see if I'm missing something as far as the workflow. Simply put, the commands given in your README do *not* work at all without additional undocumented steps. 2) You can continue being ignorant of Debian not mandating a specific > packaging style. > Oh, I understand this, and will add new packages to Debian as I always have. > 3) Others are still free to follow my recommendation: Package through > Debian, not directly at their pet derived distribution, to avoid > duplicated work. > We tried that, however you stated that you wanted to continue to use 0.82 for now. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities migration status
Can someone create a "project hosting" page for new projects on the sl wiki? On Wed, Feb 11, 2009 at 8:09 AM, Tomeu Vizoso wrote: > On Tue, Feb 10, 2009 at 01:29, S Page wrote: >> >> Then http://wiki.laptop.org/go/Project_hosting is obsolete. What's the >> equivalent page on sugarlabs.org? Not obsolete; just missing an important piece of information. >> Parts of http://wiki.laptop.org/go/Creating_an_activity are also >> out-of-date. I would particularly like to see the Scope section of a hypothetical "project hosting" page on the sl wiki; at the moment it seems that non-sugar projects might not be welcome to host/mirror their work there. For instance, the SL mission is "to produce, distribute, and support the use of the Sugar learning platform" rather than, say, to directly 'reinvent how computers are used for education through collaboration, reflection, and discovery' [the latter taken from Sugar's founding goals]. Would projects focused on the same goals but not currently part of the Sugar-platform-roadmap be welcome? > Note that you don't need to ask permission to anyone in order to get a > source repository created. I like that part. Are there criteria for removing someone's project if it's deemed inappropriate? SJ > Regards, > > Tomeu > ___ > 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] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 02:26:28PM -0500, Luke Faraone wrote: >On Feb 11, 2009, at 2:17 PM, Jonas Smedegaard wrote: > >> On Wed, Feb 11, 2009 at 01:38:27PM -0500, Luke Faraone wrote: >> 1) You consider packaging Pippy and sugar-base my way equally >> complex. >> >> 2) Failure to understand my way of sugar-base packaging is your >> reason for not packaging *anything* in *any* way through Debian. >> >> Or did I miss something? > >Yes, I'm saying the package maintinence operations under >git-buildpackage are more or less the same. Obviously, you need to >make changes to the buildfile, etc. > >I also fail to see the use of using git-buildpackage; we aren't going >to make use of upstream git snapshots and are almost always going to >be using an upstream tarball. Finally, git versioning and merging is >of little use since we are using CDBS' patchsystem. No need to get into details of what exactly is flawed with my packaging style, or how you would do things differently: 1) I can continue to do things my way 2) You can continue being ignorant of Debian not mandating a specific packaging style. 3) Others are still free to follow my recommendation: Package through Debian, not directly at their pet derived distribution, to avoid duplicated work. Thanks for your time, and interest in working together. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmTLVoACgkQn7DbMsAkQLjSqQCdGy0BqjqcBJ45mwwCNm5OC2oP xCoAoJsbTVSxFbW25Xw38WaZyyX/q6R0 =9rvB -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On Wed, Feb 11, 2009 at 12:04 AM, Samuel Klein wrote: > > http://dev.laptop.org/~wadeb/TypingTurtle-9.xo is the latest release but > I > > can't guarantee it works on anything but XO. > > [Getting pretty hot...] LOL.. any and all feedback is greatly appreciated! For example, in v9 I finally removed the word 'fuck' from the Bottom Row lesson (which includes keys from the other rows as well). > > SJ > Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On Feb 11, 2009, at 2:17 PM, Jonas Smedegaard wrote: > On Wed, Feb 11, 2009 at 01:38:27PM -0500, Luke Faraone wrote: >> On 2/11/09, Jonas Smedegaard wrote: > > >> Maybe we're just thick, but neither Morgan nor I were able to use >> your >> git README.packaging to upgrade a package to a new upstream version. >> It doesn't matter wheter we were upgrading sugar-base or Pippy. >> >> It seems that the file is missing some steps; moreover, how can we be >> expected to package new activities with git when even the steps for >> maintaining existing ones are lacking. > > Maybe it is me who are thick. Let's see if I understand it correctly: > > 1) You consider packaging Pippy and sugar-base my way equally complex. > > 2) Failure to understand my way of sugar-base packaging is your reason > for not packaging *anything* in *any* way through Debian. > > Or did I miss something? Yes, I'm saying the package maintinence operations under git-buildpackage are more or less the same. Obviously, you need to make changes to the buildfile, etc. I also fail to see the use of using git-buildpackage; we aren't going to make use of upstream git snapshots and are almost always going to be using an upstream tarball. Finally, git versioning and merging is of little use since we are using CDBS' patchsystem. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On Feb 11, 2009, at 2:17 PM, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, Feb 11, 2009 at 01:38:27PM -0500, Luke Faraone wrote: >> On 2/11/09, Jonas Smedegaard wrote: >>> On Wed, Feb 11, 2009 at 11:24:20AM -0500, Luke Faraone wrote: On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard wrote: > Debian POV: Someone needs to volunteer packaging > "sugar-etoys-activity". Drop an email to > debian-olpc-de...@lists.alioth.debian.org . > > Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar > activity package until a Debian package can be adopted. More info > at https://wiki.ubuntu.com/SugarTeam > > I recommend helping as "upstream" as possible instead of only > locally for Ubuntu. YMMV. > > [details back and forth snipped] > >> Maybe we're just thick, but neither Morgan nor I were able to use >> your >> git README.packaging to upgrade a package to a new upstream version. >> It doesn't matter wheter we were upgrading sugar-base or Pippy. >> >> It seems that the file is missing some steps; moreover, how can we be >> expected to package new activities with git when even the steps for >> maintaining existing ones are lacking. > > Maybe it is me who are thick. Let's see if I understand it correctly: > > 1) You consider packaging Pippy and sugar-base my way equally complex. > > 2) Failure to understand my way of sugar-base packaging is your reason > for not packaging *anything* in *any* way through Debian. > > Or did I miss something? > > > > - Jonas > > - -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmTJD0ACgkQn7DbMsAkQLgVKACeOlcvrypk9ENwzMaO/4IO1nu2 > DYgAn39Vp/oFchHoA52j6Nso5puJY8AM > =cx7E > -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 01:38:27PM -0500, Luke Faraone wrote: >On 2/11/09, Jonas Smedegaard wrote: >> On Wed, Feb 11, 2009 at 11:24:20AM -0500, Luke Faraone wrote: >>>On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard >>>wrote: >>> Debian POV: Someone needs to volunteer packaging "sugar-etoys-activity". Drop an email to debian-olpc-de...@lists.alioth.debian.org . Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar activity package until a Debian package can be adopted. More info at https://wiki.ubuntu.com/SugarTeam I recommend helping as "upstream" as possible instead of only locally for Ubuntu. YMMV. [details back and forth snipped] >Maybe we're just thick, but neither Morgan nor I were able to use your >git README.packaging to upgrade a package to a new upstream version. >It doesn't matter wheter we were upgrading sugar-base or Pippy. > >It seems that the file is missing some steps; moreover, how can we be >expected to package new activities with git when even the steps for >maintaining existing ones are lacking. Maybe it is me who are thick. Let's see if I understand it correctly: 1) You consider packaging Pippy and sugar-base my way equally complex. 2) Failure to understand my way of sugar-base packaging is your reason for not packaging *anything* in *any* way through Debian. Or did I miss something? - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmTJD0ACgkQn7DbMsAkQLgVKACeOlcvrypk9ENwzMaO/4IO1nu2 DYgAn39Vp/oFchHoA52j6Nso5puJY8AM =cx7E -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On 2/11/09, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, Feb 11, 2009 at 11:24:20AM -0500, Luke Faraone wrote: >>On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard wrote: >> >>> Debian POV: Someone needs to volunteer packaging >>> "sugar-etoys-activity". Drop an email to >>> debian-olpc-de...@lists.alioth.debian.org . >>> >>> Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar >>> activity package until a Debian package can be adopted. More info at >>> https://wiki.ubuntu.com/SugarTeam >>> >>> I recommend helping as "upstream" as possible instead of only locally >>> for Ubuntu. YMMV. >>> >> >>Yes, but our "hacks" are the result of a lack of understanding of your >>git-based packaging; > > That is one way to put it. > > Another is that you have had no interest in starting out with simple > stuff before complex stuff. I kept recommending you to try package an > activity with no odd dependencies (i.e. written in Python), but you kept > wanting to upgrade core Sugar libraries. > > You do not even need to use my packaging style. Just do not expect my > help, then. Discuss it with other members of the OLPC Alioth list, with > debian-mentors or whatever. > > > All I say here is to avoid duplicate work: Package for Debian and pull > that into derivatives, rather than packaging uniquely for each pet > derived distro. > > > >>It's interesting that Ubuntu had *working* sugar packages with *more* >>working activities six months ago. This is no longer the case, as we've >>synced to Debian packaging (which had some show-stopper bugs that >>required us to patch *each* activity you/we were shipping). > > Blame yourself for abandoning superior(?) packaging! My reasons for > different packaging style than older work by Jani Monoses is here: > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-April/84.html > > Blame yourself for needing distro-specific workarounds: They are caused > by your "running ahead" of Debian and then later wanting to adopt Debian > packaging that when in slightly different direction than your earlier > work. > > >>If you'd support a sugar-whatever-activity package that didn't use >>git-buildpackage or the multi-branch/tree workflow, I'd be happy to >>produce one, > > If you by "you" are referring to Debian, then sure, Debian supports > other packaging styles. > > If you are referring to me personally, then no, I see no reason to > support any other packaging styles than I want to use myself. > > If you are referring to the Alioth team, then feel free to use other > schemes. I am not the law. Heck, I am not even an admin of that group. I > just happen to actually get some work done. > > > Your freedom to choose packaging style should come as no surprise: > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-December/000681.html > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-January/000885.html > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-February/000894.html > > >>but as it stands the build and import process is undocumented. > > Bullshit! > > Complex parts, irrelevant for activity packaging, is missing. > > So stop whining and start packaging some simple Sugar activities. Maybe we're just thick, but neither Morgan nor I were able to use your git README.packaging to upgrade a package to a new upstream version. It doesn't matter wheter we were upgrading sugar-base or Pippy. It seems that the file is missing some steps; moreover, how can we be expected to package new activities with git when even the steps for maintaining existing ones are lacking. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On 2/11/09, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, Feb 11, 2009 at 11:24:20AM -0500, Luke Faraone wrote: >>On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard wrote: >> >>> Debian POV: Someone needs to volunteer packaging >>> "sugar-etoys-activity". Drop an email to >>> debian-olpc-de...@lists.alioth.debian.org . >>> >>> Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar >>> activity package until a Debian package can be adopted. More info at >>> https://wiki.ubuntu.com/SugarTeam >>> >>> I recommend helping as "upstream" as possible instead of only locally >>> for Ubuntu. YMMV. >>> >> >>Yes, but our "hacks" are the result of a lack of understanding of your >>git-based packaging; > > That is one way to put it. > > Another is that you have had no interest in starting out with simple > stuff before complex stuff. I kept recommending you to try package an > activity with no odd dependencies (i.e. written in Python), but you kept > wanting to upgrade core Sugar libraries. > > You do not even need to use my packaging style. Just do not expect my > help, then. Discuss it with other members of the OLPC Alioth list, with > debian-mentors or whatever. > > > All I say here is to avoid duplicate work: Package for Debian and pull > that into derivatives, rather than packaging uniquely for each pet > derived distro. > > > >>It's interesting that Ubuntu had *working* sugar packages with *more* >>working activities six months ago. This is no longer the case, as we've >>synced to Debian packaging (which had some show-stopper bugs that >>required us to patch *each* activity you/we were shipping). > > Blame yourself for abandoning superior(?) packaging! My reasons for > different packaging style than older work by Jani Monoses is here: > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-April/84.html > > Blame yourself for needing distro-specific workarounds: They are caused > by your "running ahead" of Debian and then later wanting to adopt Debian > packaging that when in slightly different direction than your earlier > work. > > >>If you'd support a sugar-whatever-activity package that didn't use >>git-buildpackage or the multi-branch/tree workflow, I'd be happy to >>produce one, > > If you by "you" are referring to Debian, then sure, Debian supports > other packaging styles. > > If you are referring to me personally, then no, I see no reason to > support any other packaging styles than I want to use myself. > > If you are referring to the Alioth team, then feel free to use other > schemes. I am not the law. Heck, I am not even an admin of that group. I > just happen to actually get some work done. > > > Your freedom to choose packaging style should come as no surprise: > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-December/000681.html > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-January/000885.html > http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-February/000894.html > > >>but as it stands the build and import process is undocumented. > > Bullshit! > > Complex parts, irrelevant for activity packaging, is missing. > > So stop whining and start packaging some simple Sugar activities. Maybe we're just thick, but neither Morgan nor I were able to use your git README.packaging to upgrade a package to a new upstream version. It doesn't matter wheter we were upgrading sugar-base or Pippy. It seems that the file is missing some steps; moreover, how can we be expected to package new activities with git when even the steps for maintaining existing ones are lacking. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
On Thu, Feb 12, 2009 at 11:33 AM, Tomeu Vizoso wrote: > On Wed, Feb 11, 2009 at 18:29, David Farning wrote: >> On Thu, Feb 12, 2009 at 10:39 AM, Tomeu Vizoso wrote: >>> Maybe the issue here is that local labs have a much broader scope than >>> the global Sugar Labs? >> >> I agree completely. Hopefully the local labs will focus in on a >> particular area of the sugar ecosystem. A testing lab, a deployment >> support organization, educational content development As such they >> will dive much deeper into a particular area then sl can. >> >>> I see local labs having something to say about everything that the >>> global Sugar Labs does, but not the other way around. >> >> Yes, but this discussion is about what services SL will provide for >> the local labs. >> >> Local labs can do whatever they want, upstream SL has to make hard >> decisions about which 'things' we can 'afford' to support. >> >> At this point in terms of infrastructure we can offer local labs: >> email account, mailing lists, a instance of our existing wiki setup. >> Anything else become to much work for our already overwork >> infrastructure team. >> >> This ends up being very similar to the deployment support issues we >> are facing. We are facing some hard issues about how we can _best_ >> use our limited resources to improve the entire Sugar ecosystem. > > Right, that was the point I was trying to make: the SL's > infrastructure is likely to not serve all the needs of all the local > labs. > > Regards, > > Tomeu Sorry for misunderstanding your point. So many people and organizations have been asking us for support since the changes at OLPC that I am getting prickly about the issues:) david >> David >> >>> Regards, >>> >>> Tomeu >>> >>> On Wed, Feb 11, 2009 at 17:35, Rafael Enrique Ortiz Guerrero >>> wrote: Thank you for your thoughts on this, I was thinking in a cms not for communication fork but for presentation fork. Anyway we are still too young, but for the future we might want to think in having this static solutions in place. (i.e when we have people that can work on maintaining the infrastructure needed etc). Rafael Ortiz On Wed, Feb 11, 2009 at 11:15 AM, Sebastian Silva wrote: > > I see your point about CMS being overkill. > > And I also agree with you, the release cycle anchors everything. > > I for one consider it a bug, not a feature, that we have this division of > channels of communication, as some of the aspects you relate should be > feeding each other more. > > It is natural because of the different workflows, however I'd like to see > some convergence. > > I'm studying the possible use of a social networking platform (pretty much > deciding on http://pinaxproject.com/ ). > > If I can tweak it to fit our workflows (I'm working with local village > visiting teachers to fit theirs) - in particular, i'm interested in > including some sort of disconnected use (that is, for instance, getting > them > a "news/mailing list/new activities feed" from the social network with a > USB > monthly, and provide them with a way to "respond" - can be email - can be > manually performed once online. > > This is likely also the tool that will help manage the Bolivia deployment > (but we will likelly have some more connectivity in Bolivia). > > Looking forward to share more as things develop, looking for feedback / > synergy. > > Sebastian > > 2009/2/11 David Farning >> >> I tend to think that a cms is a bit of overkill for a young organization. >> >> One of my personal long term goal is to determine how we can clone SL >> in Local SLs by reproducing the best practices of SL on a more local >> scale. >> >> Developer side: >> 1. The key component is the release cycle, ever thing else is anchored >> around the release cycle. >> 2. Dynamic communication through mailing lists and irc. >> 3. Static communication through wiki and bug tracker. >> Any thing else is overkill >> >> Educator side: >> 1. Release cycle - cool new features, bug fixes >> 2. Moodle - teachers know moodle >> >> david >> >> On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero >> wrote: >> > Hello all. >> > >> > I was thinking that maybe Sugar Labs could host, cms like drupal or >> > joomla >> > for Local Labs use, >> > Would be this an overhead for our young infrastructure ? >> > Is it better to Local Labs to have this kind of solutions sorted out >> > locally >> > ? >> > >> > >> > Cheers! >> > Rafael Ortiz >> > >> > ___ >> > IAEP -- It's An Education Project (not a laptop project!) >> > i...@lists.sugarlabs.org >> > http://lists.sugarlabs.org/li
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 11:24:20AM -0500, Luke Faraone wrote: >On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard wrote: > >> Debian POV: Someone needs to volunteer packaging >> "sugar-etoys-activity". Drop an email to >> debian-olpc-de...@lists.alioth.debian.org . >> >> Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar >> activity package until a Debian package can be adopted. More info at >> https://wiki.ubuntu.com/SugarTeam >> >> I recommend helping as "upstream" as possible instead of only locally >> for Ubuntu. YMMV. >> > >Yes, but our "hacks" are the result of a lack of understanding of your >git-based packaging; That is one way to put it. Another is that you have had no interest in starting out with simple stuff before complex stuff. I kept recommending you to try package an activity with no odd dependencies (i.e. written in Python), but you kept wanting to upgrade core Sugar libraries. You do not even need to use my packaging style. Just do not expect my help, then. Discuss it with other members of the OLPC Alioth list, with debian-mentors or whatever. All I say here is to avoid duplicate work: Package for Debian and pull that into derivatives, rather than packaging uniquely for each pet derived distro. >It's interesting that Ubuntu had *working* sugar packages with *more* >working activities six months ago. This is no longer the case, as we've >synced to Debian packaging (which had some show-stopper bugs that >required us to patch *each* activity you/we were shipping). Blame yourself for abandoning superior(?) packaging! My reasons for different packaging style than older work by Jani Monoses is here: http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-April/84.html Blame yourself for needing distro-specific workarounds: They are caused by your "running ahead" of Debian and then later wanting to adopt Debian packaging that when in slightly different direction than your earlier work. >If you'd support a sugar-whatever-activity package that didn't use >git-buildpackage or the multi-branch/tree workflow, I'd be happy to >produce one, If you by "you" are referring to Debian, then sure, Debian supports other packaging styles. If you are referring to me personally, then no, I see no reason to support any other packaging styles than I want to use myself. If you are referring to the Alioth team, then feel free to use other schemes. I am not the law. Heck, I am not even an admin of that group. I just happen to actually get some work done. Your freedom to choose packaging style should come as no surprise: http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-December/000681.html http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-January/000885.html http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-February/000894.html >but as it stands the build and import process is undocumented. Bullshit! Complex parts, irrelevant for activity packaging, is missing. So stop whining and start packaging some simple Sugar activities. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmTDA8ACgkQn7DbMsAkQLhHXACghUfXhv3eV5X6hCmYExiWr5Z9 dg8AnjuKQyfPiL3vAHNY/DR9+DybpBP7 =V4zH -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
On Wed, Feb 11, 2009 at 18:29, David Farning wrote: > On Thu, Feb 12, 2009 at 10:39 AM, Tomeu Vizoso wrote: >> Maybe the issue here is that local labs have a much broader scope than >> the global Sugar Labs? > > I agree completely. Hopefully the local labs will focus in on a > particular area of the sugar ecosystem. A testing lab, a deployment > support organization, educational content development As such they > will dive much deeper into a particular area then sl can. > >> I see local labs having something to say about everything that the >> global Sugar Labs does, but not the other way around. > > Yes, but this discussion is about what services SL will provide for > the local labs. > > Local labs can do whatever they want, upstream SL has to make hard > decisions about which 'things' we can 'afford' to support. > > At this point in terms of infrastructure we can offer local labs: > email account, mailing lists, a instance of our existing wiki setup. > Anything else become to much work for our already overwork > infrastructure team. > > This ends up being very similar to the deployment support issues we > are facing. We are facing some hard issues about how we can _best_ > use our limited resources to improve the entire Sugar ecosystem. Right, that was the point I was trying to make: the SL's infrastructure is likely to not serve all the needs of all the local labs. Regards, Tomeu > David > >> Regards, >> >> Tomeu >> >> On Wed, Feb 11, 2009 at 17:35, Rafael Enrique Ortiz Guerrero >> wrote: >>> Thank you for your thoughts on this, >>> >>> I was thinking in a cms not for communication fork but for presentation >>> fork. >>> >>> Anyway we are still too young, but for the future we might want to think in >>> having this static solutions in place. (i.e when we have people that can >>> work on maintaining the infrastructure needed etc). >>> >>> >>> Rafael Ortiz >>> >>> >>> On Wed, Feb 11, 2009 at 11:15 AM, Sebastian Silva >>> wrote: I see your point about CMS being overkill. And I also agree with you, the release cycle anchors everything. I for one consider it a bug, not a feature, that we have this division of channels of communication, as some of the aspects you relate should be feeding each other more. It is natural because of the different workflows, however I'd like to see some convergence. I'm studying the possible use of a social networking platform (pretty much deciding on http://pinaxproject.com/ ). If I can tweak it to fit our workflows (I'm working with local village visiting teachers to fit theirs) - in particular, i'm interested in including some sort of disconnected use (that is, for instance, getting them a "news/mailing list/new activities feed" from the social network with a USB monthly, and provide them with a way to "respond" - can be email - can be manually performed once online. This is likely also the tool that will help manage the Bolivia deployment (but we will likelly have some more connectivity in Bolivia). Looking forward to share more as things develop, looking for feedback / synergy. Sebastian 2009/2/11 David Farning > > I tend to think that a cms is a bit of overkill for a young organization. > > One of my personal long term goal is to determine how we can clone SL > in Local SLs by reproducing the best practices of SL on a more local > scale. > > Developer side: > 1. The key component is the release cycle, ever thing else is anchored > around the release cycle. > 2. Dynamic communication through mailing lists and irc. > 3. Static communication through wiki and bug tracker. > Any thing else is overkill > > Educator side: > 1. Release cycle - cool new features, bug fixes > 2. Moodle - teachers know moodle > > david > > On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero > wrote: > > Hello all. > > > > I was thinking that maybe Sugar Labs could host, cms like drupal or > > joomla > > for Local Labs use, > > Would be this an overhead for our young infrastructure ? > > Is it better to Local Labs to have this kind of solutions sorted out > > locally > > ? > > > > > > Cheers! > > Rafael Ortiz > > > > ___ > > IAEP -- It's An Education Project (not a laptop project!) > > i...@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/iaep > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Sebastian Silva Laboratorios FuenteLibre http://blog.sebastiansilva.com/ >>> >>> >>> ___ >>> IAEP
Re: [Sugar-devel] XFT emacs rocks on the XO...
On 11 Feb 2009, at 16:25, Tomeu Vizoso wrote: > On Wed, Feb 11, 2009 at 16:52, Gary C Martin > wrote: >> On 11 Feb 2009, at 05:59, Martin Langhoff wrote: >> >>> Stock F9 emacs isn't very usable on the XO screen, unfortunately. >>> Lack >>> of fonts and high dpi make it rather painful. After struggling a bit >>> to get a comfy hacking/editing environment on my XOs, I ended up >>> installing the precooked Xft-enabled emacs rpms, as per: >>> >>> http://wiki.laptop.org/go/Emacs >>> >>> and after setting a nice readable font... I'm very happy with the >>> setup. >>> >>> Also, the XO ships with a very limited vim. yum install vim-enhanced >>> has improved my part-time vim usage. >> >> Yea, sudo yum install of vim, git, pylint, and nethack ;-) are about >> the first things I do after a clean flash of an XO I plan to develop >> code on. >> >> --Gary >> >> P.S. For the record vim is 22Mb (most of which is perl), git is 3.8Mb >> (shares some of the aforementioned perl), pylint is 5Mb (almost all >> of >> that is mx), and nethack is just 1.3Mb (press ? for help). > > I guess the advantage of nethack is that once you install it you don't > need nor vim, nor git nor pylint anymore. Well, I recommend it purely for putting the hjkl cursor navigation keys into your muscle memory, ready for heavy vim coding sessions, and for acclimatising n00bs to the idea that, "text can be fun too!" :-p --G P.S. As an infovis, GUI, graphic, 3d Gouraud shaded, open GL, pixel necked geek kind'a guy – this is clearly the dark hidden side to my personality. > Regards, > > Tomeu > >>> cheers, >>> >>> >>> m >>> -- >>> martin.langh...@gmail.com >>> mar...@laptop.org -- School Server Architect >>> - ask interesting questions >>> - don't get distracted with shiny stuff - working code first >>> - http://wiki.laptop.org/go/User:Martinlanghoff >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> ___ >> Devel mailing list >> de...@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
On Thu, Feb 12, 2009 at 10:39 AM, Tomeu Vizoso wrote: > Maybe the issue here is that local labs have a much broader scope than > the global Sugar Labs? I agree completely. Hopefully the local labs will focus in on a particular area of the sugar ecosystem. A testing lab, a deployment support organization, educational content development As such they will dive much deeper into a particular area then sl can. > I see local labs having something to say about everything that the > global Sugar Labs does, but not the other way around. Yes, but this discussion is about what services SL will provide for the local labs. Local labs can do whatever they want, upstream SL has to make hard decisions about which 'things' we can 'afford' to support. At this point in terms of infrastructure we can offer local labs: email account, mailing lists, a instance of our existing wiki setup. Anything else become to much work for our already overwork infrastructure team. This ends up being very similar to the deployment support issues we are facing. We are facing some hard issues about how we can _best_ use our limited resources to improve the entire Sugar ecosystem. David > Regards, > > Tomeu > > On Wed, Feb 11, 2009 at 17:35, Rafael Enrique Ortiz Guerrero > wrote: >> Thank you for your thoughts on this, >> >> I was thinking in a cms not for communication fork but for presentation >> fork. >> >> Anyway we are still too young, but for the future we might want to think in >> having this static solutions in place. (i.e when we have people that can >> work on maintaining the infrastructure needed etc). >> >> >> Rafael Ortiz >> >> >> On Wed, Feb 11, 2009 at 11:15 AM, Sebastian Silva >> wrote: >>> >>> I see your point about CMS being overkill. >>> >>> And I also agree with you, the release cycle anchors everything. >>> >>> I for one consider it a bug, not a feature, that we have this division of >>> channels of communication, as some of the aspects you relate should be >>> feeding each other more. >>> >>> It is natural because of the different workflows, however I'd like to see >>> some convergence. >>> >>> I'm studying the possible use of a social networking platform (pretty much >>> deciding on http://pinaxproject.com/ ). >>> >>> If I can tweak it to fit our workflows (I'm working with local village >>> visiting teachers to fit theirs) - in particular, i'm interested in >>> including some sort of disconnected use (that is, for instance, getting them >>> a "news/mailing list/new activities feed" from the social network with a USB >>> monthly, and provide them with a way to "respond" - can be email - can be >>> manually performed once online. >>> >>> This is likely also the tool that will help manage the Bolivia deployment >>> (but we will likelly have some more connectivity in Bolivia). >>> >>> Looking forward to share more as things develop, looking for feedback / >>> synergy. >>> >>> Sebastian >>> >>> 2009/2/11 David Farning I tend to think that a cms is a bit of overkill for a young organization. One of my personal long term goal is to determine how we can clone SL in Local SLs by reproducing the best practices of SL on a more local scale. Developer side: 1. The key component is the release cycle, ever thing else is anchored around the release cycle. 2. Dynamic communication through mailing lists and irc. 3. Static communication through wiki and bug tracker. Any thing else is overkill Educator side: 1. Release cycle - cool new features, bug fixes 2. Moodle - teachers know moodle david On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero wrote: > Hello all. > > I was thinking that maybe Sugar Labs could host, cms like drupal or > joomla > for Local Labs use, > Would be this an overhead for our young infrastructure ? > Is it better to Local Labs to have this kind of solutions sorted out > locally > ? > > > Cheers! > Rafael Ortiz > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> >>> >>> -- >>> Sebastian Silva >>> Laboratorios FuenteLibre >>> http://blog.sebastiansilva.com/ >> >> >> ___ >> IAEP -- It's An Education Project (not a laptop project!) >> i...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/iaep >> > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-dev
Re: [Sugar-devel] csound or olpcsound (was Re: hello and how canIJoin?)
Could the performance modifications be made into a runtime option, specified in a configuration file or command line option somehow? On Wed, Feb 11, 2009 at 11:46 AM, victor wrote: > > You mean olpcsound.spec in upstream CSound sources, or more (or > > something else) than that? > > No, I mean there is an scons option (something like buildOLPC=1). I have a > spec of course, but that's for a fedora rpm. > > > You mean Felipe? > > yes, Felipe. And of course yourself, I was not aware you were doing > this with him, thanks for the work. > > > Still, the Debian packaging currently takes no special care for eventual > > special Sugar needs. If olpcsound is only about leaving out CPU-heavy > > stuff it should be a problem only for XO hardware (and similar low-end > > hardware). > > yes, that is why I am asking here what we should do. Originally, this > whole thing was XO-only, but it seems to broadening now. > > Victor > ___ > 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] csound or olpcsound (was Re: hello and how canIJoin?)
> You mean olpcsound.spec in upstream CSound sources, or more (or > something else) than that? No, I mean there is an scons option (something like buildOLPC=1). I have a spec of course, but that's for a fedora rpm. > You mean Felipe? yes, Felipe. And of course yourself, I was not aware you were doing this with him, thanks for the work. > Still, the Debian packaging currently takes no special care for eventual > special Sugar needs. If olpcsound is only about leaving out CPU-heavy > stuff it should be a problem only for XO hardware (and similar low-end > hardware). yes, that is why I am asking here what we should do. Originally, this whole thing was XO-only, but it seems to broadening now. Victor ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
Tomeu Vizoso wrote: >> Another issue is how we integrate the updater with addons.sl.o. >> Because the OLPC microformat is trivial, it might be easy to modify >> the remora's html output to be compatible with it. Mick, Tomeu and >> David, who have had a closer look at the code, might want to comment. > > If what you propose is to change the php pages to add/change class > attributes of existing html elements, then I think it's going to > increase significantly the rebasing efforts. What about adding new > pages for that purpose? I don't know how much work that would take (yet). >> With a web UI similar to addons.mozilla.org, the local UI for browsing >> new activities becomes redundant and could be culled, reducing the >> control panel module to a mere updater. I guess this is for the UI >> designers to decide. > > Well, but not all deployments will have access to a Remora instance, or yes? Scott clarified that there's actually no UI to browse new activities after all. (I still wonder where the initial list of activities comes from on a fresh new OS installation). Deployments can do whatever they like: 1) add their custom activities to our remora installation 2a) setup a local remora installation 2b) use a wiki or even a bare html page with the required tags (this is what OLE Nepal is doing) In (2a) and (2b), they can choose to put this service on a public server or on the XS. In the former case, they could configure squid on the XS to cache activities locally and save bandwidth. Also note that each activity bundle specifies its own URL for updates, so you can track activities installed from different places. We're offering a lot of flexibility for everyone here with very little effort on our side. >> Unless someone else steps up, I volunteer to do the minimum necessary >> integration work to make the current updater work in SoaS with >> addons.sl.o as a backend. > > How is that work going? The Sugar side works already. I need to commit my patches on git.sl.o after I come back from vacation. I believe Mick has been working on the remora side, but I don't know the actual status. Mick? -- // Bernie Innocenti - http://www.codewiz.org/ \X/ 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] [IAEP] Static services for Local Labs
Maybe the issue here is that local labs have a much broader scope than the global Sugar Labs? I see local labs having something to say about everything that the global Sugar Labs does, but not the other way around. Regards, Tomeu On Wed, Feb 11, 2009 at 17:35, Rafael Enrique Ortiz Guerrero wrote: > Thank you for your thoughts on this, > > I was thinking in a cms not for communication fork but for presentation > fork. > > Anyway we are still too young, but for the future we might want to think in > having this static solutions in place. (i.e when we have people that can > work on maintaining the infrastructure needed etc). > > > Rafael Ortiz > > > On Wed, Feb 11, 2009 at 11:15 AM, Sebastian Silva > wrote: >> >> I see your point about CMS being overkill. >> >> And I also agree with you, the release cycle anchors everything. >> >> I for one consider it a bug, not a feature, that we have this division of >> channels of communication, as some of the aspects you relate should be >> feeding each other more. >> >> It is natural because of the different workflows, however I'd like to see >> some convergence. >> >> I'm studying the possible use of a social networking platform (pretty much >> deciding on http://pinaxproject.com/ ). >> >> If I can tweak it to fit our workflows (I'm working with local village >> visiting teachers to fit theirs) - in particular, i'm interested in >> including some sort of disconnected use (that is, for instance, getting them >> a "news/mailing list/new activities feed" from the social network with a USB >> monthly, and provide them with a way to "respond" - can be email - can be >> manually performed once online. >> >> This is likely also the tool that will help manage the Bolivia deployment >> (but we will likelly have some more connectivity in Bolivia). >> >> Looking forward to share more as things develop, looking for feedback / >> synergy. >> >> Sebastian >> >> 2009/2/11 David Farning >>> >>> I tend to think that a cms is a bit of overkill for a young organization. >>> >>> One of my personal long term goal is to determine how we can clone SL >>> in Local SLs by reproducing the best practices of SL on a more local >>> scale. >>> >>> Developer side: >>> 1. The key component is the release cycle, ever thing else is anchored >>> around the release cycle. >>> 2. Dynamic communication through mailing lists and irc. >>> 3. Static communication through wiki and bug tracker. >>> Any thing else is overkill >>> >>> Educator side: >>> 1. Release cycle - cool new features, bug fixes >>> 2. Moodle - teachers know moodle >>> >>> david >>> >>> On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero >>> wrote: >>> > Hello all. >>> > >>> > I was thinking that maybe Sugar Labs could host, cms like drupal or >>> > joomla >>> > for Local Labs use, >>> > Would be this an overhead for our young infrastructure ? >>> > Is it better to Local Labs to have this kind of solutions sorted out >>> > locally >>> > ? >>> > >>> > >>> > Cheers! >>> > Rafael Ortiz >>> > >>> > ___ >>> > IAEP -- It's An Education Project (not a laptop project!) >>> > i...@lists.sugarlabs.org >>> > http://lists.sugarlabs.org/listinfo/iaep >>> > >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> >> >> -- >> Sebastian Silva >> Laboratorios FuenteLibre >> http://blog.sebastiansilva.com/ > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
Thank you for your thoughts on this, I was thinking in a cms not for communication fork but for presentation fork. Anyway we are still too young, but for the future we might want to think in having this static solutions in place. (i.e when we have people that can work on maintaining the infrastructure needed etc). Rafael Ortiz On Wed, Feb 11, 2009 at 11:15 AM, Sebastian Silva wrote: > I see your point about CMS being overkill. > > And I also agree with you, the release cycle anchors everything. > > I for one consider it a bug, not a feature, that we have this division of > channels of communication, as some of the aspects you relate should be > feeding each other more. > > It is natural because of the different workflows, however I'd like to see > some convergence. > > I'm studying the possible use of a social networking platform (pretty much > deciding on http://pinaxproject.com/ ). > > If I can tweak it to fit our workflows (I'm working with local village > visiting teachers to fit theirs) - in particular, i'm interested in > including some sort of disconnected use (that is, for instance, getting them > a "news/mailing list/new activities feed" from the social network with a USB > monthly, and provide them with a way to "respond" - can be email - can be > manually performed once online. > > This is likely also the tool that will help manage the Bolivia deployment > (but we will likelly have some more connectivity in Bolivia). > > Looking forward to share more as things develop, looking for feedback / > synergy. > > Sebastian > > 2009/2/11 David Farning > >> I tend to think that a cms is a bit of overkill for a young organization. >> >> One of my personal long term goal is to determine how we can clone SL >> in Local SLs by reproducing the best practices of SL on a more local >> scale. >> >> Developer side: >> 1. The key component is the release cycle, ever thing else is anchored >> around the release cycle. >> 2. Dynamic communication through mailing lists and irc. >> 3. Static communication through wiki and bug tracker. >> Any thing else is overkill >> >> Educator side: >> 1. Release cycle - cool new features, bug fixes >> 2. Moodle - teachers know moodle >> >> david >> >> On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero >> wrote: >> > Hello all. >> > >> > I was thinking that maybe Sugar Labs could host, cms like drupal or >> joomla >> > for Local Labs use, >> > Would be this an overhead for our young infrastructure ? >> > Is it better to Local Labs to have this kind of solutions sorted out >> locally >> > ? >> > >> > >> > Cheers! >> > Rafael Ortiz >> > >> > ___ >> > IAEP -- It's An Education Project (not a laptop project!) >> > i...@lists.sugarlabs.org >> > http://lists.sugarlabs.org/listinfo/iaep >> > >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > -- > Sebastian Silva > Laboratorios FuenteLibre > http://blog.sebastiansilva.com/ > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can IJoin?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Smedegaard wrote: > Still, the Debian packaging currently takes no special care for eventual > special Sugar needs. If olpcsound is only about leaving out CPU-heavy > stuff it should be a problem only for XO hardware (and similar low-end > hardware). Debian targets lots of low-end hardware. Also, I think there's a bit of confusion here. Does olpcsound do anything /differently/ from csound, or does it simply /leave out/ certain capabilities? If the latter, then it seems the question is more about saving disk space than CPU time. (Both are valuable, of course.) Either way, it seems like some metapackaging is in order, so that each dependency can choose to depend on one or either. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmS/F4ACgkQUJT6e6HFtqQpeQCfTR2RSanIyYZLeneaAi53VxW5 E2EAnjf0+eds5npGxadKW/BCrtxuT+X8 =v2Y+ -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] XFT emacs rocks on the XO...
On Wed, Feb 11, 2009 at 16:52, Gary C Martin wrote: > On 11 Feb 2009, at 05:59, Martin Langhoff wrote: > >> Stock F9 emacs isn't very usable on the XO screen, unfortunately. Lack >> of fonts and high dpi make it rather painful. After struggling a bit >> to get a comfy hacking/editing environment on my XOs, I ended up >> installing the precooked Xft-enabled emacs rpms, as per: >> >>http://wiki.laptop.org/go/Emacs >> >> and after setting a nice readable font... I'm very happy with the >> setup. >> >> Also, the XO ships with a very limited vim. yum install vim-enhanced >> has improved my part-time vim usage. > > Yea, sudo yum install of vim, git, pylint, and nethack ;-) are about > the first things I do after a clean flash of an XO I plan to develop > code on. > > --Gary > > P.S. For the record vim is 22Mb (most of which is perl), git is 3.8Mb > (shares some of the aforementioned perl), pylint is 5Mb (almost all of > that is mx), and nethack is just 1.3Mb (press ? for help). I guess the advantage of nethack is that once you install it you don't need nor vim, nor git nor pylint anymore. Regards, Tomeu >> cheers, >> >> >> m >> -- >> martin.langh...@gmail.com >> mar...@laptop.org -- School Server Architect >> - ask interesting questions >> - don't get distracted with shiny stuff - working code first >> - http://wiki.laptop.org/go/User:Martinlanghoff >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Build intrastructure
[cc += sugar-de...@] Marco Pesenti Gritti wrote: >> As Peter suggested, I should look at getting nightly builds set up soon. >> Would you like to share infrastructure so that the build run spits out >> SoaS images at the same as F11-XO images? If so, any preference for >> whether to do it on an OLPC machine or on something like sunjammer? > > Sharing infra on this makes a lot of sense to me. Personally I have no > preference about where to host it. Bernie, what do you think? Is this > something we can host? I guess we will need a rawhide box/VM. We can provide shell accounts on our buildslaves to anyone interested in running nightly builds. We currently have 4 of them: buildslave1.sugarlabs.orgFedora 10 x86_64 buildslave2.sugarlabs.orgFedora rawhide x86_64 buildslave3.sugarlabs.orgOFFLINE buildslave4.sugarlabs.orgUbuntu 8.10 Please, avoid using your shell accounts on sunjammer for heavy-duty jobs such as daily rebuilds. If you must, at least run these things with "nice -n 15 ionice -n 5 -c 3" to keep it from slowing down other users too much. Please also avoid using shell accounts on solarsail and trinity as we're going to phase them out at some point. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ 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] [IAEP] activites known not to either work at all or not on certin platforms
On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard wrote: > Debian POV: Someone needs to volunteer packaging "sugar-etoys-activity". > Drop an email to debian-olpc-de...@lists.alioth.debian.org . > > Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar > activity package until a Debian package can be adopted. More info at > https://wiki.ubuntu.com/SugarTeam > > I recommend helping as "upstream" as possible instead of only locally > for Ubuntu. YMMV. > Yes, but our "hacks" are the result of a lack of understanding of your git-based packaging; we found it much simpler to use a workflow like svn-buildpackage with get-orig-source where we don't have to deal with multiple branches, etc. All the benifits of using git are moot since you use a patch system, which I think is a better workflow. It's interesting that Ubuntu had *working* sugar packages with *more* working activities six months ago. This is no longer the case, as we've synced to Debian packaging (which had some show-stopper bugs that required us to patch *each* activity you/we were shipping). If you'd support a sugar-whatever-activity package that didn't use git-buildpackage or the multi-branch/tree workflow, I'd be happy to produce one, but as it stands the build and import process is undocumented. The lack of proper documentaiton has caused Morgan and I considerable frustration, adn was the reason that we decided to fork into non-git packaging for our temporary Ubuntu "hacks". (ie "making it work in a month so other people can actually use it") [1] I do not mean to say that Ubuntu packaging in principle is any worse > quality than packages adopted from Debian. Just that Ubuntu generally > seems to generally favor passing on the grunt work to Debian and treat > locally packaged stuff as temporary, i.e. hacks. > -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can IJoin?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 03:51:48PM +, victor wrote: >Yes, originally this was an XO-fedora only thing. However the >olpcsound 'lightweight' option is actually in the upstream sources >(as a build option). You mean olpcsound.spec in upstream CSound sources, or more (or something else) than that? >Debian packages of Csound are being maintained by one of our >team, so they should be kept reasonably updated (as the Debian >cycle permits). You mean Felipe? Still, the Debian packaging currently takes no special care for eventual special Sugar needs. If olpcsound is only about leaving out CPU-heavy stuff it should be a problem only for XO hardware (and similar low-end hardware). - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmS+40ACgkQn7DbMsAkQLjEbwCfR0+Y/jw1q1+DUmoAi1u9t/XT 8jcAnjiYc6FQ2QytECCE6EfXvweNkQ6z =vc6L -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
On Thu, Feb 12, 2009 at 10:15 AM, Sebastian Silva wrote: > I see your point about CMS being overkill. > > And I also agree with you, the release cycle anchors everything. > > I for one consider it a bug, not a feature, that we have this division of > channels of communication, as some of the aspects you relate should be > feeding each other more. + 1 The differing methods are _not_ a feature, they are a natural reality which we must accept and overcome. > It is natural because of the different workflows, however I'd like to see > some convergence. > > I'm studying the possible use of a social networking platform (pretty much > deciding on http://pinaxproject.com/ ). > > If I can tweak it to fit our workflows (I'm working with local village > visiting teachers to fit theirs) - in particular, i'm interested in > including some sort of disconnected use (that is, for instance, getting them > a "news/mailing list/new activities feed" from the social network with a USB > monthly, and provide them with a way to "respond" - can be email - can be > manually performed once online. > > This is likely also the tool that will help manage the Bolivia deployment > (but we will likelly have some more connectivity in Bolivia). > > Looking forward to share more as things develop, looking for feedback / > synergy. Thanks, and keep push things back upstream. david > Sebastian > > 2009/2/11 David Farning >> >> I tend to think that a cms is a bit of overkill for a young organization. >> >> One of my personal long term goal is to determine how we can clone SL >> in Local SLs by reproducing the best practices of SL on a more local >> scale. >> >> Developer side: >> 1. The key component is the release cycle, ever thing else is anchored >> around the release cycle. >> 2. Dynamic communication through mailing lists and irc. >> 3. Static communication through wiki and bug tracker. >> Any thing else is overkill >> >> Educator side: >> 1. Release cycle - cool new features, bug fixes >> 2. Moodle - teachers know moodle >> >> david >> >> On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero >> wrote: >> > Hello all. >> > >> > I was thinking that maybe Sugar Labs could host, cms like drupal or >> > joomla >> > for Local Labs use, >> > Would be this an overhead for our young infrastructure ? >> > Is it better to Local Labs to have this kind of solutions sorted out >> > locally >> > ? >> > >> > >> > Cheers! >> > Rafael Ortiz >> > >> > ___ >> > IAEP -- It's An Education Project (not a laptop project!) >> > i...@lists.sugarlabs.org >> > http://lists.sugarlabs.org/listinfo/iaep >> > >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > Sebastian Silva > Laboratorios FuenteLibre > http://blog.sebastiansilva.com/ > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
I see your point about CMS being overkill. And I also agree with you, the release cycle anchors everything. I for one consider it a bug, not a feature, that we have this division of channels of communication, as some of the aspects you relate should be feeding each other more. It is natural because of the different workflows, however I'd like to see some convergence. I'm studying the possible use of a social networking platform (pretty much deciding on http://pinaxproject.com/ ). If I can tweak it to fit our workflows (I'm working with local village visiting teachers to fit theirs) - in particular, i'm interested in including some sort of disconnected use (that is, for instance, getting them a "news/mailing list/new activities feed" from the social network with a USB monthly, and provide them with a way to "respond" - can be email - can be manually performed once online. This is likely also the tool that will help manage the Bolivia deployment (but we will likelly have some more connectivity in Bolivia). Looking forward to share more as things develop, looking for feedback / synergy. Sebastian 2009/2/11 David Farning > I tend to think that a cms is a bit of overkill for a young organization. > > One of my personal long term goal is to determine how we can clone SL > in Local SLs by reproducing the best practices of SL on a more local > scale. > > Developer side: > 1. The key component is the release cycle, ever thing else is anchored > around the release cycle. > 2. Dynamic communication through mailing lists and irc. > 3. Static communication through wiki and bug tracker. > Any thing else is overkill > > Educator side: > 1. Release cycle - cool new features, bug fixes > 2. Moodle - teachers know moodle > > david > > On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero > wrote: > > Hello all. > > > > I was thinking that maybe Sugar Labs could host, cms like drupal or > joomla > > for Local Labs use, > > Would be this an overhead for our young infrastructure ? > > Is it better to Local Labs to have this kind of solutions sorted out > locally > > ? > > > > > > Cheers! > > Rafael Ortiz > > > > ___ > > IAEP -- It's An Education Project (not a laptop project!) > > i...@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/iaep > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Sebastian Silva Laboratorios FuenteLibre http://blog.sebastiansilva.com/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 04:29:52PM +0200, Morgan Collett wrote: >On Wed, Feb 11, 2009 at 16:22, Jonas Smedegaard wrote: >> On Wed, Feb 11, 2009 at 03:57:22AM +0100, David Van Assche wrote: >>>you know what the irony is with all this... all we need to do to get >>>those packs working is type ./configure --with-libabiword >>> >>>I know because I took the painful step of doing it in from source... >>>this problem has now existed for 8 months... u tell me if that is >>>acceptable or not. u know the worst part of this entire debacle... >>>only the packzge ,aintainer can fix this 2 second fix::: but >>>obviously he has more important things to do. >> >> The one-line fix works only on combined compile and working >> environment. >> >> It takes slightly more to _package_ a library properly. >> >> The "important things" holding back Debian from fixing this at the >> moment is to actually release the 20-something-thousand packages as a >> whole. >> >> For Ubuntu the problem seems (from bugreports tagging the issue as >> fixed and then unfixed again) that the people actually working on >> "running ahead of Debian" for this specific issue are unskilled in >> packaging libraries. > >Jonas, > >I'm rather unskilled at packaging myself. However, somebody's got to >do it, and when I made noise about it nobody else stepped up. > >Ubuntu has a feature freeze in 8 days. We'll do what we can. No, we'll >do what we have to. > >BTW if you have any comments on the packaging of abiword or pyabiword, >please speak up - here, or the debian or ubuntu lists. If possible, >I'd like to fix this in a way that we can sync back with you after >lenny releases... I apologize if I made you look bad (or worse than you are :-) ). I did not intend to point fingers, only to describe current state of affairs. When I saw your attempt at fixing the issue I wondered how you could manage to provide a library without the whole shabang of lib* and lib*-dev packages. It actually made me pull the Debian sources of abiword and spend some time trying to come up with an elegant, minimal patch for the Debian abiword packaging. It turned out to be simple (for me), and after some time I got distracted and have not found/taken time to look at it again since then... Yes, I won't keep it to myself if I find a solution to this. But I will most probably not work on Ubuntu-specific hacks, as I find such work a duplication of effort. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmS+KEACgkQn7DbMsAkQLgV2wCeIMPFgmRAd+/oBLXSX4saALY8 DScAnROnk+p/9+Z6C90Q6XAfNeYit9Z+ =USx1 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora 10 machine to build soas-1 images
Hi, > Marco Pesenti Gritti wrote: >> No I haven't. See thread on de...@laptop.org about sharing build >> infra with OLPC though. > What is the subject? I fell behind with the OLPC lists. http://thread.gmane.org/gmane.linux.laptop.olpc.devel/22270/focus=22272 - Chris. -- Chris Ball ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can IJoin?)
Very cool - Anything you can push upstream is a win for everyone:) david On Thu, Feb 12, 2009 at 9:51 AM, victor wrote: > Yes, originally this was an XO-fedora only thing. However the > olpcsound 'lightweight' option is actually in the upstream sources > (as a build option). Currently it might be the case that it is i*86 > only (not sure how well it would build on other archs). So if > packagers are interested in this, they can avail of that option. > > Debian packages of Csound are being maintained by one of our > team, so they should be kept reasonably updated (as the Debian > cycle permits). > > Regards > > Victor > > - Original Message - > From: "Jonas Smedegaard" > To: > Sent: Wednesday, February 11, 2009 3:32 PM > Subject: Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can > IJoin?) > > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Wed, Feb 11, 2009 at 02:37:17PM +, victor wrote: Actually, your expertise would be needed to get the csound packages into the distributions. Currently we have the standard Csound package [1] and the olpcsound [2] package in Fedora. We should decide which package we should move forward. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76556 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=77007 >>> >>>Good, I am glad to dive in straightaway. This is my opinion: >>> >>>Csound-5.03 [1] is very old, there is actually a csound-5.07, >>>which is much newer. Olpcsound[2] is based on 5.08, the >>>last 'stable' version of libcsound-5.1. >>> >>>The difference between the two packages is that olpcsound is >>>cut-down and adapted to the requirements of OLPC/XO. Now >>>these might not be the same requirements of sugar (as a platform >>>independent OS), but is smaller and lighter. It does not have any >>>of the CPU intensive DSP code fro spectral processing etc. >> >> Interesting. I was unaware of that optimization issue. >> >> Would it perhaps make sense for Distributions to generically offer >> multiple variants of the csound libraries, with and without >> CPU-intensive processing? >> >> If so, the best approach is to improve upstream CSound build routines to >> compile these library variants, differently named so they can be >> installed concurrently, rather than packagers needing to compile >> everything multiple times and provide conflicting packages. >> >> >> As a much simpler alternative, if you could isolate the patches and/or >> compile flags needed for XO-friendly builds, then packagers could add >> them, either just commented out or enabled through some environment >> flag, for easy package rebuilding by (sub)distros aiming specifically at >> low-end hardware. >> >> >> >> (Your discussion seems Fedora/Redhat-centric to me. Tell me if I should >> simply keep silent with these more general comments) >> >> >> - Jonas >> >> - -- >> * Jonas Smedegaard - idealist og Internet-arkitekt >> * Tlf.: +45 40843136 Website: http://dr.jones.dk/ >> >> [x] quote me freely [ ] ask before reusing [ ] keep private >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEARECAAYFAkmS740ACgkQn7DbMsAkQLh8zACcCkWi+7EJO0qs1G0UXXZ8ER1l >> HYYAn1tJdPz2WfRiphFiiqYzIGRDvqVL >> =mlsN >> -END PGP SIGNATURE- >> ___ >> 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 > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
I tend to think that a cms is a bit of overkill for a young organization. One of my personal long term goal is to determine how we can clone SL in Local SLs by reproducing the best practices of SL on a more local scale. Developer side: 1. The key component is the release cycle, ever thing else is anchored around the release cycle. 2. Dynamic communication through mailing lists and irc. 3. Static communication through wiki and bug tracker. Any thing else is overkill Educator side: 1. Release cycle - cool new features, bug fixes 2. Moodle - teachers know moodle david On Thu, Feb 12, 2009 at 9:40 AM, Rafael Enrique Ortiz Guerrero wrote: > Hello all. > > I was thinking that maybe Sugar Labs could host, cms like drupal or joomla > for Local Labs use, > Would be this an overhead for our young infrastructure ? > Is it better to Local Labs to have this kind of solutions sorted out locally > ? > > > Cheers! > Rafael Ortiz > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Static services for Local Labs
A Wiki page is not always suitable for showing a project, that's why we are working on the landing page for Sugar Labs. =) Rafael Ortiz On Wed, Feb 11, 2009 at 10:48 AM, Luke Faraone wrote: > On 2/11/09, Rafael Enrique Ortiz Guerrero wrote: > > Hello all. > > > > I was thinking that maybe Sugar Labs could host, cms like drupal or > joomla > > for Local Labs use, > > Would be this an overhead for our young infrastructure ? > > Is it better to Local Labs to have this kind of solutions sorted out > locally > > What's wrong with using a wikipage, like we use with the rest of the site? > > > -- > Luke Faraone > http://luke.faraone.cc > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora 10 machine to build soas-1 images
Marco Pesenti Gritti wrote: > No I haven't. See thread on de...@laptop.org about sharing build infra > with OLPC though. What is the subject? I fell behind with the OLPC lists. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ 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] Keep tabs on Sugar development
>> 2009/2/10 Wade Brainerd : >>> PS- If you don't have an RSS reader already, try out Google Reader. >>> Its List view works pretty well for this feed. RSS support in Thunderbird is also very good. Simon Schampijer wrote: > Awesome, one missing piece for me! Can we add a tip somewhere in the DevelopmentTeam pages? -- // Bernie Innocenti - http://www.codewiz.org/ \X/ 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] XFT emacs rocks on the XO...
On 11 Feb 2009, at 05:59, Martin Langhoff wrote: > Stock F9 emacs isn't very usable on the XO screen, unfortunately. Lack > of fonts and high dpi make it rather painful. After struggling a bit > to get a comfy hacking/editing environment on my XOs, I ended up > installing the precooked Xft-enabled emacs rpms, as per: > >http://wiki.laptop.org/go/Emacs > > and after setting a nice readable font... I'm very happy with the > setup. > > Also, the XO ships with a very limited vim. yum install vim-enhanced > has improved my part-time vim usage. Yea, sudo yum install of vim, git, pylint, and nethack ;-) are about the first things I do after a clean flash of an XO I plan to develop code on. --Gary P.S. For the record vim is 22Mb (most of which is perl), git is 3.8Mb (shares some of the aforementioned perl), pylint is 5Mb (almost all of that is mx), and nethack is just 1.3Mb (press ? for help). > cheers, > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > 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] csound or olpcsound (was Re: hello and how can IJoin?)
Yes, originally this was an XO-fedora only thing. However the olpcsound 'lightweight' option is actually in the upstream sources (as a build option). Currently it might be the case that it is i*86 only (not sure how well it would build on other archs). So if packagers are interested in this, they can avail of that option. Debian packages of Csound are being maintained by one of our team, so they should be kept reasonably updated (as the Debian cycle permits). Regards Victor - Original Message - From: "Jonas Smedegaard" To: Sent: Wednesday, February 11, 2009 3:32 PM Subject: Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can IJoin?) > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, Feb 11, 2009 at 02:37:17PM +, victor wrote: >>> Actually, your expertise would be needed to get the csound packages >>> into the distributions. Currently we have the standard Csound package >>> [1] and the olpcsound [2] package in Fedora. We should decide which >>> package we should move forward. >>> >>> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76556 >>> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=77007 >>> >> >>Good, I am glad to dive in straightaway. This is my opinion: >> >>Csound-5.03 [1] is very old, there is actually a csound-5.07, >>which is much newer. Olpcsound[2] is based on 5.08, the >>last 'stable' version of libcsound-5.1. >> >>The difference between the two packages is that olpcsound is >>cut-down and adapted to the requirements of OLPC/XO. Now >>these might not be the same requirements of sugar (as a platform >>independent OS), but is smaller and lighter. It does not have any >>of the CPU intensive DSP code fro spectral processing etc. > > Interesting. I was unaware of that optimization issue. > > Would it perhaps make sense for Distributions to generically offer > multiple variants of the csound libraries, with and without > CPU-intensive processing? > > If so, the best approach is to improve upstream CSound build routines to > compile these library variants, differently named so they can be > installed concurrently, rather than packagers needing to compile > everything multiple times and provide conflicting packages. > > > As a much simpler alternative, if you could isolate the patches and/or > compile flags needed for XO-friendly builds, then packagers could add > them, either just commented out or enabled through some environment > flag, for easy package rebuilding by (sub)distros aiming specifically at > low-end hardware. > > > > (Your discussion seems Fedora/Redhat-centric to me. Tell me if I should > simply keep silent with these more general comments) > > > - Jonas > > - -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmS740ACgkQn7DbMsAkQLh8zACcCkWi+7EJO0qs1G0UXXZ8ER1l > HYYAn1tJdPz2WfRiphFiiqYzIGRDvqVL > =mlsN > -END PGP SIGNATURE- > ___ > 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] [IAEP] Static services for Local Labs
On 2/11/09, Rafael Enrique Ortiz Guerrero wrote: > Hello all. > > I was thinking that maybe Sugar Labs could host, cms like drupal or joomla > for Local Labs use, > Would be this an overhead for our young infrastructure ? > Is it better to Local Labs to have this kind of solutions sorted out locally What's wrong with using a wikipage, like we use with the rest of the site? -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 03:57:05PM +0100, Bert Freudenberg wrote: >On 11.02.2009, at 10:59, Morgan Collett wrote: >> >>> etoys >> >> This is packaged, but I think we're still missing a bit - the actual >> sugar activity for etoys. I don't personally have the time to work on >> it because I'm working on the above (and the actual glucose >> packages). > > >What needs to be done there? Can anybody else package this? Yes, anyone with some interest in .deb packaging can help. Debian POV: Someone needs to volunteer packaging "sugar-etoys-activity". Drop an email to debian-olpc-de...@lists.alioth.debian.org . Ubuntu POV: Someone needs to volunteer hacking[1] together a sugar activity package until a Debian package can be adopted. More info at https://wiki.ubuntu.com/SugarTeam I recommend helping as "upstream" as possible instead of only locally for Ubuntu. YMMV. - Jonas [1] I do not mean to say that Ubuntu packaging in principle is any worse quality than packages adopted from Debian. Just that Ubuntu generally seems to generally favor passing on the grunt work to Debian and treat locally packaged stuff as temporary, i.e. hacks. - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmS84kACgkQn7DbMsAkQLjj7gCeOHNkXx0yX1vSnJx7NDnN36YY 4RgAn3lJ+8ypu6NpxWPU0fiUodTIXuvS =y5x6 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora 10 machine to build soas-1 images
I would like to get a better handle on our build farm situation. Currently, buildbots ar running on the following machines. | buildslave1.sl.o | boar.prgmr.com | Fedora10 | | buildslave2.sl.o | boar.prgmr.com | FedoraRH | | buildslave3.sl.o | hydra.prgmr.com | | buildslave4.sl.o | pgrm?? | Ubuntu?? What are our needs in terms of: 1. fixes to the existing buildbot machines? 2. Other buildbot distros we would like? 3. SoaS build machines we need? What are a current resources and possible resources: 1. Possible machine donors? Other issues? thanks david On Thu, Feb 12, 2009 at 4:54 AM, Marco Pesenti Gritti wrote: > On Wed, Feb 11, 2009 at 11:49 AM, Bernie Innocenti wrote: >> Did you find one? I can ask prgmr.com to move our buildslaves to a >> new XEN VM which works with paravirtualized kernels. > > No I haven't. See thread on de...@laptop.org about sharing build infra > with OLPC though. > > Marco > ___ > 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
[Sugar-devel] Static services for Local Labs
Hello all. I was thinking that maybe Sugar Labs could host, cms like drupal or joomla for Local Labs use, Would be this an overhead for our young infrastructure ? Is it better to Local Labs to have this kind of solutions sorted out locally ? Cheers! Rafael Ortiz ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can I Join?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 02:37:17PM +, victor wrote: >> Actually, your expertise would be needed to get the csound packages >> into the distributions. Currently we have the standard Csound package >> [1] and the olpcsound [2] package in Fedora. We should decide which >> package we should move forward. >> >> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76556 >> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=77007 >> > >Good, I am glad to dive in straightaway. This is my opinion: > >Csound-5.03 [1] is very old, there is actually a csound-5.07, >which is much newer. Olpcsound[2] is based on 5.08, the >last 'stable' version of libcsound-5.1. > >The difference between the two packages is that olpcsound is >cut-down and adapted to the requirements of OLPC/XO. Now >these might not be the same requirements of sugar (as a platform >independent OS), but is smaller and lighter. It does not have any >of the CPU intensive DSP code fro spectral processing etc. Interesting. I was unaware of that optimization issue. Would it perhaps make sense for Distributions to generically offer multiple variants of the csound libraries, with and without CPU-intensive processing? If so, the best approach is to improve upstream CSound build routines to compile these library variants, differently named so they can be installed concurrently, rather than packagers needing to compile everything multiple times and provide conflicting packages. As a much simpler alternative, if you could isolate the patches and/or compile flags needed for XO-friendly builds, then packagers could add them, either just commented out or enabled through some environment flag, for easy package rebuilding by (sub)distros aiming specifically at low-end hardware. (Your discussion seems Fedora/Redhat-centric to me. Tell me if I should simply keep silent with these more general comments) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmS740ACgkQn7DbMsAkQLh8zACcCkWi+7EJO0qs1G0UXXZ8ER1l HYYAn1tJdPz2WfRiphFiiqYzIGRDvqVL =mlsN -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] buildbot traffic
Thanks On Thu, Feb 12, 2009 at 9:18 AM, Luke Faraone wrote: > On Feb 11, 2009, at 9:18 AM, David Farning wrote: > >> Luke, >> Can you make sure that traffic from the buildbot is making it through > > Done: buildbot has been whitelisted. I'm planning on adding a topic shortly > for those who use that functionality. > > -lf > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] buildbot failure in Sugar Labs Buildbot on GConf-dbus-Fedora10
The Buildbot has detected a failed build of GConf-dbus-Fedora10 on Sugar Labs Buildbot. Full details are available at: http://buildbot.sugarlabs.org/builders/GConf-dbus-Fedora10/builds/74 Buildbot URL: http://buildbot.sugarlabs.org/ Buildslave for this Build: Fedora10 Build Reason: Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed GConf-dbus build sincerely, -The Buildbot ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] buildbot traffic
On Feb 11, 2009, at 9:18 AM, David Farning wrote: > Luke, > Can you make sure that traffic from the buildbot is making it through Done: buildbot has been whitelisted. I'm planning on adding a topic shortly for those who use that functionality. -lf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] hello and how can I Join?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 02:10:36PM +0100, Simon Schampijer wrote: >victor wrote: >> Particularly my expertise is in the area of audio and there are two >> things I am particularly interested in: >> >> 1. Audio infrastructure, csound integration, pulseaudio adoption etc > >Actually, your expertise would be needed to get the csound packages >into the distributions. Not sure what you mean here, Simon, but if relevant then here is the state of CSound packaging for Debian: Debian "Etch" (current stable release): 4.23f13 Debian "Lenny" (next official release): 5.08.0 Debian "Sid" (eternal unstable branch): 5.08.2 We (Felipe Sateler and I) are currently finalizing 5.10.1 for Sid. Packaging for Lenny and Sid includes libraries and Python bindings needed for use with Sugar. So all in all, I'd say that CSound for Debian is taken care of - but moves only slowly, so if you are interested in CSound packaging for Debian and Debian-based distros, you are most welcome to join our little CSound team :-) Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmS6+gACgkQn7DbMsAkQLhHfQCdEkZinXKWhCVgcsKm+F5WeSPw MGIAnj43EDvlZSqSQf5zLnPU2vJOijj+ =f0yO -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] buildbot failure in Sugar Labs Buildbot on GConf-dbus-Fedora10
The Buildbot has detected a failed build of GConf-dbus-Fedora10 on Sugar Labs Buildbot. Full details are available at: http://buildbot.sugarlabs.org/builders/GConf-dbus-Fedora10/builds/73 Buildbot URL: http://buildbot.sugarlabs.org/ Buildslave for this Build: Fedora10 Build Reason: Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed GConf-dbus build sincerely, -The Buildbot ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] buildbot failure in Sugar Labs Buildbot on GConf-dbus-Fedora10
The Buildbot has detected a failed build of GConf-dbus-Fedora10 on Sugar Labs Buildbot. Full details are available at: http://buildbot.sugarlabs.org/builders/GConf-dbus-Fedora10/builds/72 Buildbot URL: http://buildbot.sugarlabs.org/ Buildslave for this Build: Fedora10 Build Reason: Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed GConf-dbus build sincerely, -The Buildbot ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On 11.02.2009, at 10:59, Morgan Collett wrote: > >> etoys > > This is packaged, but I think we're still missing a bit - the actual > sugar activity for etoys. I don't personally have the time to work on > it because I'm working on the above (and the actual glucose packages). What needs to be done there? Can anybody else package this? The activity is here: Bundle: http://etoys.laptop.org/rpms/Etoys-99.xo Tarball: http://download.sugarlabs.org/sources/sucrose/fructose/Etoys/Etoys-99.tar.gz - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 11:00:19AM +0100, Tomeu Vizoso wrote: >I see frustration but I'm having trouble knowing who should have done >something and failed to do it. > >Can we get a list of issues, each of them with a list of people that >may be able to do something about them? I believe clarity about these kinds of issues are cluttered by 2 factors: a) Overloading or "running ahead of" upstream work To exemplify a) let's look at Write: It depend on libabiword, which is not yet available in Debian. Debian POV: libabiword should be packaged for Debian and then Write should be packaged as well. Ubuntu POV: Hack together libabiword and Write packages until Debian provides them. Sugar POV: Hack together Write package with libabiword embedded until included by distros So multiple parts of the chain can "do something" about the issue. Some long term, some being hacks. Hacks has a high risk of causing confusion (and even worse if done badly). b) Activities wrongly treated as independent of system and architecture. Imagine the standard Write .xo package. It works on systems that provide libabiword but fails otherwise. There is no way to express as part of the .xo packaging that it requires this library, and no way for Sugar install process to check if the package will work. Imagine a hacked Write package embedding libabiword. What architectures to compile the library for and include with the package? amd64? powerpc? powerpc64? How about Pentium optimizations for ia32 (so-called "i686")? Imagine Chat. How can the end-user know that version 60 and newer won't work on 0.82? It cannot be expressed in the packaging, only on some web page that the user then needs to read ahead of updating. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAkmS5o0ACgkQn7DbMsAkQLhEBQCXeVqwyiBioMlAhTUSS/Y+bsHn WwCdFqMsFNMi2/J/sde64HrGPMhtlEQ= =+hMn -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fuse module to access datastore files from normal desktop
Hi tomeu, regards the fuse datastore module I have this questions: 1 - The title of an activity can contains all the character. But the filesystem canno handle / charater. At the moment this character became \ Is this correct? 2 - Only activity that are stored data can be accessibile. Is this correct? 3 - Nothing is show from activity that no write data file (. 4 - Only title and tags are taken from datastore (and if present the name of the activity). 5 - At the present the fuse module is not updated. We need to specify some refresh criteria 6 - How to handle the duplicate file? Add an (1), (2), or §1, §2 etc. Using (n) it is possibile have some error if the user have some activity with (n) at the last of title. Using § is need that the user is not able to insert this character in the title name. Of course it is possible to use other character then § 7 - It is possible to get the comment using extend attribute. It's possibile to get all the datastore attribute using extended attribute. If you think that is usefull I do it. Of course a lot of other thing need to be done, but I suppose to be a good starting point. At the moment you can find the binary and source code here http://mk8.codewiz.org/fsg.tar.bz2 I hope to move it on gitorious in the next days Regards, Torello ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] csound or olpcsound (was Re: hello and how can I Join?)
> Actually, your expertise would be needed to get the csound packages into > the distributions. Currently we have the standard Csound package [1] and > the olpcsound [2] package in Fedora. We should decide which package we > should move forward. > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76556 > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=77007 > Good, I am glad to dive in straightaway. This is my opinion: Csound-5.03 [1] is very old, there is actually a csound-5.07, which is much newer. Olpcsound[2] is based on 5.08, the last 'stable' version of libcsound-5.1. The difference between the two packages is that olpcsound is cut-down and adapted to the requirements of OLPC/XO. Now these might not be the same requirements of sugar (as a platform independent OS), but is smaller and lighter. It does not have any of the CPU intensive DSP code fro spectral processing etc. IMHO: olpcsound might be the best if we are not thinking of any specialised/intensive DSP and we need a light package. On the other hand, if these are not an issue anymore, we should go with standard Csound, and I would recommend updating the package to Csound-5.10 and libcsound-5.2. There is another issue, which is a real problem. Olpcsound and csound conflict, as they provide the same SONAME. This was not an issue originally, as olpcsound was built only for OLPC-N targets. Now, if there are no OLPC targets anymore and we are using FC targets, this is a problem. There is currently a ticket open on bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=473185 which I am keen on resolving as soon as possible. So if we don't need olpcsound anymore, we need to look into updating to csound-5.10 and using that package. That will resolve the problem. If we want to keep olpcsound, we will just need to find a solution to the conflict. Thanks Victor ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
On Wed, Feb 11, 2009 at 16:22, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, Feb 11, 2009 at 03:57:22AM +0100, David Van Assche wrote: >>you know what the irony is with all this... all we need to do to get >>those packs working is type ./configure --with-libabiword >> >>I know because I took the painful step of doing it in from source... >>this problem has now existed for 8 months... u tell me if that is >>acceptable or not. u know the worst part of this entire debacle... >>only the packzge ,aintainer can fix this 2 second fix::: but obviously >>he has more important things to do. > > The one-line fix works only on combined compile and working environment. > > It takes slightly more to _package_ a library properly. > > The "important things" holding back Debian from fixing this at the > moment is to actually release the 20-something-thousand packages as a > whole. > > For Ubuntu the problem seems (from bugreports tagging the issue as fixed > and then unfixed again) that the people actually working on "running > ahead of Debian" for this specific issue are unskilled in packaging > libraries. Jonas, I'm rather unskilled at packaging myself. However, somebody's got to do it, and when I made noise about it nobody else stepped up. Ubuntu has a feature freeze in 8 days. We'll do what we can. No, we'll do what we have to. BTW if you have any comments on the packaging of abiword or pyabiword, please speak up - here, or the debian or ubuntu lists. If possible, I'd like to fix this in a way that we can sync back with you after lenny releases... Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 11, 2009 at 03:57:22AM +0100, David Van Assche wrote: >you know what the irony is with all this... all we need to do to get >those packs working is type ./configure --with-libabiword > >I know because I took the painful step of doing it in from source... >this problem has now existed for 8 months... u tell me if that is >acceptable or not. u know the worst part of this entire debacle... >only the packzge ,aintainer can fix this 2 second fix::: but obviously >he has more important things to do. The one-line fix works only on combined compile and working environment. It takes slightly more to _package_ a library properly. The "important things" holding back Debian from fixing this at the moment is to actually release the 20-something-thousand packages as a whole. For Ubuntu the problem seems (from bugreports tagging the issue as fixed and then unfixed again) that the people actually working on "running ahead of Debian" for this specific issue are unskilled in packaging libraries. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmS3zYACgkQn7DbMsAkQLjdHQCgj3TO7hmes1PZD+txgEhPCWEb fGoAoKPo+6J+WINxDvWmCx85pjx8ZklA =BsNg -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] buildbot traffic
Luke, Can you make sure that traffic from the buildbot is making it through list moderation? thanks david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] no way to unsubscribe
Luke Faraone wrote: > On Wed, Feb 11, 2009 at 2:41 AM, Simon Schampijer > wrote: >> Hi, >> >> http://lists.laptop.org/listinfo/sugar is now redirected to the >> sugar-devel list on Sugar Labs. How am I supposed to unsubscribe now? > > > Try http://lists.laptop.org/options/sugar > Awesome - thanks! Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] activites known not to either work at all or not on certin platforms
On Wed, Feb 11, 2009 at 03:14:24AM +0100, David Van Assche wrote:
[...]
ok, that is about 50% of the failed testtube babies...
[...]
Thanks for your mail. I've been equally frustrated; even sugar-jhbuild
on Ubuntu intrepid that was recommended to me didn't work (it might now,
see recent thread regarding RPATH issues).
It's good to know I'm not the only one having so many problems with
Sugar ("geteiltes Leid ist halbes Leid" ;) ). I'm much more motivated
again.
The tables in the Sucrose section of the Supported Systems wiki page [1]
have a "Tested" column suggesting that Sugar is tested _and_ _working_
on Debian, Fedora and Ubuntu (at least that's how I interpreted that
column). IMO we should adjust that column to give a summary of how much
of Sugar is actually working, with a link to a more detailed status
page; for Starches as well.
[1] http://sugarlabs.org/go/Supported_systems
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] no way to unsubscribe
On Wed, Feb 11, 2009 at 2:41 AM, Simon Schampijer wrote: > Hi, > > http://lists.laptop.org/listinfo/sugar is now redirected to the > sugar-devel list on Sugar Labs. How am I supposed to unsubscribe now? Try http://lists.laptop.org/options/sugar -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] hello and how can I Join?
victor wrote: > Hello everyone, > > I have finally been able to turn my attention back to OLPC/XO. So now > I would like to see how I can join the development team in sugarlabs. Awesome, welcome at Sugar Labs. So the first important part you already did - subscribe to this list and stepped up :) There is also these other lists that might be of interest http://lists.sugarlabs.org/ and join.sugarlabs.org is as well a good resource. > Particularly my expertise is in the area of audio and there are two > things I am particularly interested in: > > 1. Audio infrastructure, csound integration, pulseaudio adoption etc Actually, your expertise would be needed to get the csound packages into the distributions. Currently we have the standard Csound package [1] and the olpcsound [2] package in Fedora. We should decide which package we should move forward. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76556 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=77007 > 2. Tools for music/audio activities development: csndsugui > http://wiki.laptop.org/go/Csndsugui > (I hope to move this to sugarlabs GIT, but I am not sure exactly where, > since this is not actually an 'activity'). I had hopes that this module could > eventually make it into sugar proper, once it is completed; Would that be > a good idea? Sure, that sounds great. You can move the repository over as a general project and once finished we can merge it. Instructions on how to move an existing repository can be found at http://sugarlabs.org/go/DevelopmentTeam/Git#Import_a_module_from_dev.laptop.org > So basically my questions are: how to get involved with these things? Where > to move the csndsugui repository and what else might be worth doing, > considering > my areas of expertise? > > Also, a more practical question. What is the best way of keeping up-to-date > with > sugar software for the XO? Joyrides? I am sorry bu the OLPC-sugarlabs split is > still not clear in my mind. So joyride is obsolete - we agreed that olpc should hop on the fedora train. That is why for example we try to minimize the forks of packages between olpc and Fedora. More Info on the exact procedure should come from Chris. Currently the best is to use Sugar on a Stick (http://sugarlabs.org/go/Sugar_on_a_Stick) to use the latest Sugar version on the XO. The latest version is: http://lists.sugarlabs.org/archive/sugar-devel/2009-February/011456.html You can copy it on the Nand for example. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities migration status
On Tue, Feb 10, 2009 at 01:29, S Page wrote: > Ed McNierney wrote: > >> On the other hand, anyone working on Sugar efforts such as Activity >> development should be encouraged to put all those efforts under the >> Sugar Labs roof where they can be more readily available to the entire >> Sugar community (not just the OLPC portion of it). > > Then http://wiki.laptop.org/go/Project_hosting is obsolete. What's the > equivalent page on sugarlabs.org? > > Parts of http://wiki.laptop.org/go/Creating_an_activity are also > out-of-date. You have some information here: http://sugarlabs.org/go/ActivityTeam/How_to_migrate_from_OLPC Note that you don't need to ask permission to anyone in order to get a source repository created. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Mon, Feb 2, 2009 at 10:46, Bernie Innocenti wrote: > C. Scott Ananian wrote: >> OK, thanks. The existing updater works fine in Debian; I don't know >> if it was ever pushed into koji, but it is certainly compatible with >> Fedora. If anyone wants to develop a new updater, I can probably >> offer some advice. Using an explicit update_url field in the activity >> is recommended for activities packaged with the current updater; the >> OLPC wiki default was only ever intended to be a bridge for legacy >> apps, not a recommended practice. I prefer email for initial >> discussions of updater ideas: 9am isn't a great meeting time for me. > > How did the Debian package cope with the dependency on olpc-update? > I thought we had to break that and integrate the relevant support > files in the control panel module. > > Another issue is how we integrate the updater with addons.sl.o. > Because the OLPC microformat is trivial, it might be easy to modify > the remora's html output to be compatible with it. Mick, Tomeu and > David, who have had a closer look at the code, might want to comment. If what you propose is to change the php pages to add/change class attributes of existing html elements, then I think it's going to increase significantly the rebasing efforts. What about adding new pages for that purpose? > With a web UI similar to addons.mozilla.org, the local UI for browsing > new activities becomes redundant and could be culled, reducing the > control panel module to a mere updater. I guess this is for the UI > designers to decide. Well, but not all deployments will have access to a Remora instance, or yes? > See also: > http://sugarlabs.org/go/ActivityTeam/Remora_port > http://sugarlabs.org/go/DevelopmentTeam/a.s.o > http://people.sugarlabs.org/dfarning/aslo_patches/ > > >> http://cananian.livejournal.com/48460.html also has some thoughts >> on updaters. > > Regarding the integration with PackageKit, long-term that would be the > best course, but since it would take a big rewrite I doubt it can > happen within the 0.84 time frame. > > Unless someone else steps up, I volunteer to do the minimum necessary > integration work to make the current updater work in SoaS with > addons.sl.o as a backend. How is that work going? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] hello and how can I Join?
Hello everyone, I have finally been able to turn my attention back to OLPC/XO. So now I would like to see how I can join the development team in sugarlabs. Particularly my expertise is in the area of audio and there are two things I am particularly interested in: 1. Audio infrastructure, csound integration, pulseaudio adoption etc 2. Tools for music/audio activities development: csndsugui http://wiki.laptop.org/go/Csndsugui (I hope to move this to sugarlabs GIT, but I am not sure exactly where, since this is not actually an 'activity'). I had hopes that this module could eventually make it into sugar proper, once it is completed; Would that be a good idea? So basically my questions are: how to get involved with these things? Where to move the csndsugui repository and what else might be worth doing, considering my areas of expertise? Also, a more practical question. What is the best way of keeping up-to-date with sugar software for the XO? Joyrides? I am sorry bu the OLPC-sugarlabs split is still not clear in my mind. Thanks Victor ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar.profile.jabber_registered and sugar.profile.is_registered() are deprecated?
On Wed, Feb 11, 2009 at 11:39 PM, Morgan Collett wrote: > I mean if we need to reinstate the is_registered tracking, or > something like that... I'm not sure of the status of the registration > feature in 0.84 - all I can say authoritatively is that from a jabber > server connection perspective, PS always automatically tries to > reregister if necessary. I don't know off hand what else the register > function for the XS does in terms of state in Sugar. Registration in 0.82 contacts the XS via XMLRPC, passing its SN, nick and pubkey. In return, it gets a backup server "url" (u...@fqdn) and a jabber server fqdn. I hope it still works, without that quite a few things break... m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora 10 machine to build soas-1 images
On Wed, Feb 11, 2009 at 11:49 AM, Bernie Innocenti wrote: > Did you find one? I can ask prgmr.com to move our buildslaves to a > new XEN VM which works with paravirtualized kernels. No I haven't. See thread on de...@laptop.org about sharing build infra with OLPC though. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora 10 machine to build soas-1 images
Marco Pesenti Gritti wrote: > Hello, > > do we have any F10 machine we can use to build Soas? sugarlabs1 has an > old kernel, which prevents me to build XO images. I'll likely need > sudo on it. Did you find one? I can ask prgmr.com to move our buildslaves to a new XEN VM which works with paravirtualized kernels. Our sugarlabs4.xen.prgmr.com machine is already using it. Ask dfarning for access to it while I'm still traveling around. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ 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] sugar.profile.jabber_registered and sugar.profile.is_registered() are deprecated?
On Wed, Feb 11, 2009 at 12:32, Martin Langhoff wrote: > On Wed, Feb 11, 2009 at 10:46 PM, Morgan Collett > wrote: >> Yes, way back we found that tracking is_registered was unreliable, > > Fair enough. However, a number of operations on the client side need > to know whether Sugar thinks it is registered. > >> Ask the server? > > Hmmm, no. I just want to know if we're registered, separately from > talking to the server. > > We do need a bit of state on the client side to track whether it > thinks it is registered. We also need a workflow if it turns out that > it isn't registered, or that the server's been wiped clean after it > lost its marbles. But that's a separate issue :-) > >> Looks like 0.86 needs a new feature around registration management as >> we're significantly after the 0.84 feature freeze. > > Do you mean 0.84 has no concept of a 'registration' action like 0.82 did? I mean if we need to reinstate the is_registered tracking, or something like that... I'm not sure of the status of the registration feature in 0.84 - all I can say authoritatively is that from a jabber server connection perspective, PS always automatically tries to reregister if necessary. I don't know off hand what else the register function for the XS does in terms of state in Sugar. HTH Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar.profile.jabber_registered and sugar.profile.is_registered() are deprecated?
On Wed, Feb 11, 2009 at 10:46 PM, Morgan Collett wrote: > Yes, way back we found that tracking is_registered was unreliable, Fair enough. However, a number of operations on the client side need to know whether Sugar thinks it is registered. > Ask the server? Hmmm, no. I just want to know if we're registered, separately from talking to the server. We do need a bit of state on the client side to track whether it thinks it is registered. We also need a workflow if it turns out that it isn't registered, or that the server's been wiped clean after it lost its marbles. But that's a separate issue :-) > Looks like 0.86 needs a new feature around registration management as > we're significantly after the 0.84 feature freeze. Do you mean 0.84 has no concept of a 'registration' action like 0.82 did? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Ignoring certain exceptions while debugging...?
On Wed, Feb 11, 2009 at 11:18 PM, Martin Langhoff wrote: > Having said that, there's a bug. The 'except' line in the patch should > be a bare 'except:'. In my last patch, I mistakenly committed an 'except IOError:' instead of a bare 'except:'. I changed the exception as a debugging measure: for that particular try/except, I wanted to _see_ the exception. Commenting out the try/except lines doesn't work very well with this whitespace-panicy interpreter, unfortunately, and de-indenting and re-indenting large chunks of code has its own risks because we don't have start/end block braces. So I was a little bit stuck on this -- catching a narrower exception sounded like a good temporary hack, and got me through... but then got through my pre-commit review. It looks like an honest exception! Is there a better way? mar...@letting-your-uselessness-with-python-hang-out... -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Auto-authentication for Browse -
On Wed, Feb 11, 2009 at 10:25 PM, Andrés Ambrois wrote: > Awesome work! Thanks! When it comes to python... I'm always proud when I achieve anything that exceeds a 'hello world' :-) Having said that, there's a bug. The 'except' line in the patch should be a bare 'except:'. > I might be missing something, but you're storing the laptop serial number > instead of the pubkey inside the cookie (unless /ofw/mfg-data/SN doesnt > stores a pubkey), which was the original plan C. Good point. I didn't refer back to the spec. I think SN and the pubkey are roughly equal in this situation - the XS has both - if a 3rd party sniffs the cookie from the ether... is either of them more damaging than the other? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
Hi, I see frustration but I'm having trouble knowing who should have done something and failed to do it. Can we get a list of issues, each of them with a list of people that may be able to do something about them? Thanks, Tomeu On Wed, Feb 11, 2009 at 10:16, David Van Assche wrote: > hey there sean essentially there is no difference between SoaS and > cd the problem comes from the distro specific intricacies, which > can be many more than devs care to admit... I agree.. this is not a > usable product unless it alll works... saying oh welll speak > doesnt work because of x or y, is no excuse. bios has nothing to do > with this, this is purely distro related... for example... on fedora > we have 80% workage, on ubuntu 40 maybe 50% workage... but for those > of us in the field selling this tech, this is not accpetable... I say > it again I know its an open source project but it doesnt help > funding if we cant even get the damn thing to run a cd, btw, is > worse than a stick at this point. at least for ubuntu goood > luck and lets work this shit out so we finally have a solution that > works in schoosl > > On Wed, Feb 11, 2009 at 9:50 AM, Sean DALY wrote: >> It is absolutely vital that SoaS boot/install work in a reliable way. >> Any nongeek user who can't use it will not bother reporting precise >> bug information, and moreover will lose motivation to try it again. In >> the case of branded USB sticks boot/install failures will make Sugar >> Labs appear as a cruddy product. Branded sticks will need to work >> every time. >> >> OK that said I ask you to bear with me since I don't know enough about >> the (surely formidable) technical hurdles in succeeding boot/install. >> Can anyone brief me on the importance/difficulty of the following >> factors? Perhaps there is a page which enumerates these factors? >> >> * User difficulty configuring BIOS boot from USB >> * Underlying distribution >> * Recognizing hardware >> * Dependencies >> * Network (LAN, Internet) connectivity: configuration, absence thereof >> * USB key locked in read-only mode >> * Missing or buggy activities >> >> >> Please forgive my ignorance but does SoaS generate a log at >> boot/install? Are there error codes specific to Sugar? I would imagine >> that's distribution-dependent... The user feedback rate could be >> improved if we communicate a super-simple procedure on boot/install >> failure, e.g. an e-mail address to send a boot/install log file to. As >> well (perhaps this happens already?), on successful boot/install and >> with Internet connnectivity, ideally the stick should phone home with >> the boot log which would indicate successful SoaS/hardware >> combinations and provide some statistics on how many sticks make it to >> screens. Of course, per privacy concerns there should be no >> user-identifiable information, or rather any such info should be >> immediately anonymized. Is there a way to trap errors in each >> activity, in case of error can the boot/install log be appended to, >> can a user feedback agent return the updated log to us if the Net is >> available? >> >> One more (maybe silly) question, is there a fundamental difference >> between Sugar on a CD and Sugar on a Stick? >> >> If this has been dealt with, any pointers to resources would be appreciated. >> >> thank you >> >> Sean >> >> >> On Wed, Feb 11, 2009 at 8:34 AM, David Van Assche >> wrote: >>> well this entire conversation was really brought about because I >>> couldnt practice speech with my 2 nephews... Im sorry if I crossed the >>> line a bit, but I think what I said needed to be said... SoaS is >>> indeed the best plqtform right now and the kids not only loved it >>> (one 9 the other 3) they needed no explanation for the interface... to >>> them it was as natural as eating a piece of bread. >>> >>> On Wed, Feb 11, 2009 at 6:04 AM, Samuel Klein wrote: On Tue, Feb 10, 2009 at 10:36 PM, Wade Brainerd wrote: > On Tue, Feb 10, 2009 at 9:14 PM, David Van Assche > wrote: >> Im gonna try and make this easy: >> >> SoaS - the latest fedora core based >> I tried to impress my 9 year old gescwister... (related one) >> Speak - it will not even launch why is it then on a disitributed >> stick? > > Aleksey Lim recently took over this orphaned package. Can you get in > touch > with him (alsroot on IRC) and help work it out? I have yet to even try > SoaS > but information on what activities do and don't work should be posted to > http://sugarlabs.org/go/ActivityTeam/ActivityStatus so we can triage them. > We are watching that page. Thus far most of our work has been migrating > activities over to SL.org but hopefully we can start actually getting them > to work on SoaS soon. On a sidenote: some of the most exciting work for me last summer was Hemant's text-to-speech work, which would have real impact if its integration into Sugar we
Re: [Sugar-devel] activites known not to either work at all or not on certin platforms
On Wed, Feb 11, 2009 at 04:14, David Van Assche wrote: > ok? I guess this will be contreversial but it must be said and acted > upon (much more importantly) > > Im gonna try and make this easy: > > SoaS - the latest fedora core based > I tried to impress my 9 year old gescwister... (related one) > Speak - it will not even launch why is it then on a disitributed stick? > > ubuntu - > no read That was a problem for all distros as OLPC shipped a forked evince. It will be fixed for jaunty. > no write We're working on that one - libabiword. Will also be fixed for jaunty. > no jiggzawpuzzle It fails because it depends on abiword. Will be fixed for jaunty. > etoys This is packaged, but I think we're still missing a bit - the actual sugar activity for etoys. I don't personally have the time to work on it because I'm working on the above (and the actual glucose packages). > scratch Not packaged for Ubuntu. License changed to non-free recently? > epathi I don't think anyone's looked at getting this working on Ubuntu. > measure > anything tam tam based > until very recently even browse Fixed - although may be broken again by today's Firefox updates - I'll get it updated ASAP. > pdf reader of any kind > measure > distance > slider > video chat > abc flower (thing doesnt even exist) Not packaged. We really need more people to step up and work on testing these activities as .xo on Ubuntu (and other distros) and help with packaging them if they don't work like that. When I got involved with Ubuntu packaging, I was asked by my manager at OLPC (my employer at the time) to NOT work on Sugar on Ubuntu. I did what I could in my personal time, but we had missed the Ubuntu feature freeze and nearly had to ship 0.79 or nothing at all. I'm more able to work on it now, and jaunty should work much better. It might be easier to get involved in smaller distros, but for Ubuntu we're still working without having any upload rights, and depending on getting the MOTU team to sponsor our uploads, until we can demonstrate sufficient experience. Not easy when time is tight. Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar.profile.jabber_registered and sugar.profile.is_registered() are deprecated?
On Wed, Feb 11, 2009 at 09:07, Martin Langhoff wrote: > Working with sucrose-0.82, I was surprised to discover that > > - there is no codepath that will set jabber_registered to true > - the only reliable thing to use is profile.jabber_server > - profile.is_registered() not consistent with either... > > I guess sugar devs already know this, Simon has removed all this cruft. Yes, way back we found that tracking is_registered was unreliable, especially when we had to reload the server or prune the registered users. After telling the nth person to edit the config file to set it back to unregistered, we simply made the Presence Service reregister automatically if it got an authentication failure, and ignored the setting. At the time, the "Register" menu option seemed to be magic, and nobody could say what it was supposed to do. (I think this was before there were regular XS releases.) > What is the new way of asking whether the XO is registered? Is there a > reasonable idiom that will work on 0.82 and current 'master'? Ask the server? Older releases required a non-empty (but not necessarily valid) jabber server (e.g. ship2.jabber.laptop.org) to be populated. 0.82 shipped with an empty jabber server by default. 0.84 has "jabber.sugarlabs.org" as the jabber server by default, now that we have gadget to prevent overloading that server. Any values besides these would show that the user (or the Register function) had changed the jabber server, but not whether registration on the populated server was successful. (And the presence of jabber.sugarlabs.org says nothing about whether the user registered on that server either.) Looks like 0.86 needs a new feature around registration management as we're significantly after the 0.84 feature freeze. Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Auto-authentication for Browse -
On Wednesday 11 February 2009 07:06:58 Martin Langhoff wrote: > On Sat, Jan 24, 2009 at 7:40 AM, Martin Langhoff > > wrote: > > Plan C - Simple HTTP cookie > > Here is a rough cut on the plan C, against the tip of sucrose-0.82 Awesome work! I might be missing something, but you're storing the laptop serial number instead of the pubkey inside the cookie (unless /ofw/mfg-data/SN doesnt stores a pubkey), which was the original plan C. Or is this just a sketch? -- Andrés signature.asc Description: This is a digitally signed message part. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] activites known not to either work at all or not on certin platforms
hey there sean essentially there is no difference between SoaS and cd the problem comes from the distro specific intricacies, which can be many more than devs care to admit... I agree.. this is not a usable product unless it alll works... saying oh welll speak doesnt work because of x or y, is no excuse. bios has nothing to do with this, this is purely distro related... for example... on fedora we have 80% workage, on ubuntu 40 maybe 50% workage... but for those of us in the field selling this tech, this is not accpetable... I say it again I know its an open source project but it doesnt help funding if we cant even get the damn thing to run a cd, btw, is worse than a stick at this point. at least for ubuntu goood luck and lets work this shit out so we finally have a solution that works in schoosl On Wed, Feb 11, 2009 at 9:50 AM, Sean DALY wrote: > It is absolutely vital that SoaS boot/install work in a reliable way. > Any nongeek user who can't use it will not bother reporting precise > bug information, and moreover will lose motivation to try it again. In > the case of branded USB sticks boot/install failures will make Sugar > Labs appear as a cruddy product. Branded sticks will need to work > every time. > > OK that said I ask you to bear with me since I don't know enough about > the (surely formidable) technical hurdles in succeeding boot/install. > Can anyone brief me on the importance/difficulty of the following > factors? Perhaps there is a page which enumerates these factors? > > * User difficulty configuring BIOS boot from USB > * Underlying distribution > * Recognizing hardware > * Dependencies > * Network (LAN, Internet) connectivity: configuration, absence thereof > * USB key locked in read-only mode > * Missing or buggy activities > > > Please forgive my ignorance but does SoaS generate a log at > boot/install? Are there error codes specific to Sugar? I would imagine > that's distribution-dependent... The user feedback rate could be > improved if we communicate a super-simple procedure on boot/install > failure, e.g. an e-mail address to send a boot/install log file to. As > well (perhaps this happens already?), on successful boot/install and > with Internet connnectivity, ideally the stick should phone home with > the boot log which would indicate successful SoaS/hardware > combinations and provide some statistics on how many sticks make it to > screens. Of course, per privacy concerns there should be no > user-identifiable information, or rather any such info should be > immediately anonymized. Is there a way to trap errors in each > activity, in case of error can the boot/install log be appended to, > can a user feedback agent return the updated log to us if the Net is > available? > > One more (maybe silly) question, is there a fundamental difference > between Sugar on a CD and Sugar on a Stick? > > If this has been dealt with, any pointers to resources would be appreciated. > > thank you > > Sean > > > On Wed, Feb 11, 2009 at 8:34 AM, David Van Assche > wrote: >> well this entire conversation was really brought about because I >> couldnt practice speech with my 2 nephews... Im sorry if I crossed the >> line a bit, but I think what I said needed to be said... SoaS is >> indeed the best plqtform right now and the kids not only loved it >> (one 9 the other 3) they needed no explanation for the interface... to >> them it was as natural as eating a piece of bread. >> >> On Wed, Feb 11, 2009 at 6:04 AM, Samuel Klein wrote: >>> On Tue, Feb 10, 2009 at 10:36 PM, Wade Brainerd wrote: On Tue, Feb 10, 2009 at 9:14 PM, David Van Assche wrote: > Im gonna try and make this easy: > > SoaS - the latest fedora core based > I tried to impress my 9 year old gescwister... (related one) > Speak - it will not even launch why is it then on a disitributed > stick? Aleksey Lim recently took over this orphaned package. Can you get in touch with him (alsroot on IRC) and help work it out? I have yet to even try SoaS but information on what activities do and don't work should be posted to http://sugarlabs.org/go/ActivityTeam/ActivityStatus so we can triage them. We are watching that page. Thus far most of our work has been migrating activities over to SL.org but hopefully we can start actually getting them to work on SoaS soon. >>> >>> On a sidenote: some of the most exciting work for me last summer was >>> Hemant's text-to-speech work, which would have real impact if its >>> integration into Sugar were completed. How close is that to being >>> possible? >>> http://dev.laptop.org/~wadeb/TypingTurtle-9.xo is the latest release but I can't guarantee it works on anything but XO. >>> >>> [Getting pretty hot...] >>> >>> SJ >>> >> ___ >> IAEP -- It's An Education Project (not a laptop project!) >> i...@lists.sugarlabs.org >> http://lists.sugarlabs.o
Re: [Sugar-devel] Auto-authentication for Browse -
On Wed, Feb 11, 2009 at 11:20 AM, Carol Farlow Lerche wrote: > There is an underlying set of security utilities that belong to Mozilla (NSS Good info! I'll be quite happy to look into the toolchain you mention at a later stage, or to take patches from a motivated volunteer. I am under a lot of time pressure and can't take on this -- unless perhaps it's very mature and well documented. cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Auto-authentication for Browse -
On Sat, Jan 24, 2009 at 7:40 AM, Martin Langhoff
wrote:
> Plan C - Simple HTTP cookie
Here is a rough cut on the plan C, against the tip of sucrose-0.82
- works on "first execution" of Browse
- works on subsequent executions of Browse
- adds the cookie entry if needed
Can we get this or something like it merged into Browse?
cheers,
martin
ps: my first patch in the Sugar environment. Was hard work but... Woohoo!
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
From 24c0497243b12748b7339ea438bc850083637a4e Mon Sep 17 00:00:00 2001
From: Martin Langhoff
Date: Wed, 11 Feb 2009 08:49:11 +
Subject: [PATCH] webactivity: seed the XS cookie at startup
When starting up, call seed_xs_cookie() to
try to add a cookie with our SN for the XS.
---
webactivity.py | 89
1 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/webactivity.py b/webactivity.py
index e17d3b2..de70981 100644
--- a/webactivity.py
+++ b/webactivity.py
@@ -26,6 +26,7 @@ import sha
import base64
import time
import shutil
+import sqlite3
from sugar.activity import activity
from sugar.graphics import style
@@ -98,6 +99,10 @@ class WebActivity(activity.Activity):
self._browser = Browser()
+# call after browser init
+# to ensure the storage dir exists
+self.seed_xs_cookie()
+
temp_path = os.path.join(self.get_activity_root(), 'instance')
downloadmanager.init(self._browser, self, temp_path)
sessionhistory.init(self._browser)
@@ -482,3 +487,87 @@ class WebActivity(activity.Activity):
downloadmanager.remove_all_downloads()
self.close(force=True)
+def seed_xs_cookie(self):
+
+_logger.debug('seed_xs_cookie')
+db_path = os.path.join(_profile_path, 'cookies.sqlite')
+
+# have we registered with the XS?
+prof = profile.get_profile()
+# profile.jabber_registered is old and buggy
+# - check for jabber_server instead
+if not prof.jabber_server:
+_logger.debug('seed_xs_cookie: not registered yet')
+return
+
+xs_fqdn = prof.jabber_server
+
+# username = SN
+ofw = self.have_ofw_tree()
+if not ofw:
+return
+
+sn = self.read_ofw('mfg-data/SN')
+
+ # gecko creates the DB at startup
+ # so we seed it after Browse() is invoked
+_logger.debug('cookies file:' + db_path)
+
+try:
+jar_db = sqlite3.connect(db_path)
+c = jar_db.cursor()
+_logger.debug('opened file')
+
+# gecko delays creating the table
+# until it gets a cookie...
+c.execute('''CREATE TABLE IF NOT EXISTS
+ moz_cookies
+ (id INTEGER PRIMARY KEY,
+ name TEXT,
+ value TEXT,
+ host TEXT,
+ path TEXT,
+ expiry INTEGER,
+ lastAccessed INTEGER,
+ isSecure INTEGER,
+ isHttpOnly INTEGER);''')
+
+c.execute('''SELECT id
+ FROM moz_cookies
+ WHERE name=? AND host=? AND path=?''',
+ ('xoid', xs_fqdn, '/'))
+
+# the row exists, we're done
+if c.fetchone():
+_logger.debug('cookie exists')
+return
+
+expire = int(time.time()) + 10*365*24*60*60
+c.execute('''INSERT INTO moz_cookies (name, value, host,
+ path, expiry, lastAccessed,
+ isSecure, isHttpOnly)
+ VALUES(?,?,?,?,?,?,?,?)''',
+ ( 'xoid', sn, xs_fqdn,
+'/', expire, 0,
+0, 0 ))
+jar_db.commit()
+jar_db.close()
+_logger.debug('updated cookies successfully')
+except IOError:
+_logger.error('error seeding cookies file')
+
+
+# static functions - stolen from
+# sugar/hardware/schoolserver.py
+# [they probably belong in a util lib]
+def have_ofw_tree(self):
+return os.path.exists('/ofw')
+
+def read_ofw(self, path):
+path = os.path.join('/ofw', path)
+if not os.path.exists(path):
+return None
+fh = open(path, 'r')
+data = fh.read().rstrip('\0\n')
+fh.close()
+return data
--
1.5.6.6
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] XFT emacs rocks on the XO...
On Wed, Feb 11, 2009 at 7:10 PM, Samuel Klein wrote: >> Also, the XO ships with a very limited vim. yum install vim-enhanced >> has improved my part-time vim usage. > > can we fix this in the next refresh? how much extra space did it > take? vim is useful. We do have vim-minimal, which works, but has no help, and no python mode that I can find (but I'm not a big vim user, so it might be there...) Getting vim-enhanced takes 22MB more, which is a fair bit for something 99.9% of our users won't want or need. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
