@James,
1. you're changing "Register" and "Register again" to "Connect to
server", but it isn't clear in the commit message why it is necessary;
I felt as "Register" refers to an action done for first time (Add new
laptop entry in the server), while "Register again" means to redo the
same thing (Add another entry of the same laptop in the server). But
now as registration is done only once, while at other times, Sugar
only changes a few setting to adapt. Hence I felt to keep a constant
name "Connect to server" as it does not bother the user if he/she if
connecting to the server for the first time or otherwise, as things
are taken care of in the background. Just gave a thought.
Nevertheless, it also just say "Register" always.
please avoid `ssh-keygen -R` if server is unchanged, because
otherwise a rogue server can be introduced after registration,
(Would it be possible to change .ssh/config to add an entry for each
server? If so, the known_hosts file might not need changing at all).
I don't know much about the ssh host verification though, but I am
learning it and will come up with something better. We can edit the
.ssh/config file as it doesn't require root permission. Can you tell
me what entry would be there for each server and do we just have to
keep adding or we will have to manage it also?
please check for `os.command()` failure, which could happen if the
disk is full,
Do you mean 'os.system(command)'?
please add commit message references to the server-side changes
and invite server-de...@lists.laptop.org
<mailto:server-de...@lists.laptop.org> people with your feature page
and patch.
I didn't do any modification to the server side for this. Just setup
the server with "Services for XO laptops ...." enabled in the
schoolserver admin page. Though I have added this to my commit
message. Updated commit message:
https://github.com/ManashRaja/sugar/commit/3ad4d847d0f2373d5bfe9f6c8e201b358f3f68e0
@Jerry,
I haven't modified anything for this feature on the server side. I
found that it uses both idmgr and xs-authserver. But the 5000 port is
used by xs-authserver to display a list of registered laptops. I
didn't enable it myself, it was there. All I did was to setup my
server according to the instructions and enabled the "XO register"
feature from the admin page.
@Tony,
Can you tell me how ownCloud is supported by XSCE? I saw it in the
services ready to be enabled. So can we not move the storage location
of /library/user/<some_id> inside or account based user directories to
the cloud storage locations.
Thanks
On Sat, Apr 16, 2016 at 3:23 AM, Jerry Vonau <m...@jvonau.ca
<mailto:m...@jvonau.ca>> wrote:
> On April 15, 2016 at 4:18 PM Manash Raja <mpdman...@gmail.com
<mailto:mpdman...@gmail.com>> wrote:
>
>
> Hi all,
>
> I fixed the bug. I haven't created a PR just yet.
>
https://github.com/ManashRaja/sugar/commit/660985d2183416cd3ed758095e92adf82f87a10c
> As of now I am parsing HTML data for json data to look for
registered
> laptops at an XS from the webaddress http://schoolserver:5000
that serves
> a
> liist of registered laptops.
Interesting, 'idmgr' doesn't use port 5000, are you using
'authserver' on
the XSCE? Little background, idmgr was released by OLPC while
authserver
originates from ActivityCentral's dextrose work. I have no
knowledge of
which method was deployed by what deployment the XSCE project tries to
cover all deployments' needs, that is why both are present. Better
check
with Walter about using dextrose code, that might be frowned upon.
> I will modify it if there is another better method that can be
> implemented
> from the Sugar side (we don't intend to modify the server side I
guess).
>
Think you better plan to work on the server side also, you'll have
a clean
slate to work with.
> And here is the feature page as suggested by James.
> https://wiki.sugarlabs.org/go/Features/Multi_XS-server_registration
>
> Please have a look.
>
> I am very excited to be a part of the discussions that go into
the making
> of great features that can affect people down there in
deployment. :)
> There
> is a scope to do so much.
>
> Thanks
>
Jerry
> On Sat, Apr 16, 2016 at 2:32 AM, James Cameron <qu...@laptop.org
<mailto:qu...@laptop.org>> wrote:
>
> > On Fri, Apr 15, 2016 at 04:02:39PM +0800, Tony Anderson wrote:
> > > Hi, James
> > >
> > > This thread was getting long so I replied only to the most
recent
> > > communication. I am sure you have the full thread which
shows the
> > > scope of the discussion.
> >
> > You're making it longer, yes, by hijacking it. You can find
the full
> > thread here:
> >
> >
http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html
> >
> > > According to trac bug #362 was opened seven years ago
against 0.82
> > > and last looked at three years ago. Several competent people
looked
> > > at it and left comments. I see none that signify consensus.
> >
> > I take it that you don't want Manash to fix this bug, thanks.
> >
> > I'd like it fixed. I think there are others who want it
fixed. It
> > would probably help with XS testing as well.
> >
> > > To have a design discussion, it is valuable to have a proposed
> > > design.
> > >
> > > I have tried to explain my proposal in detail. If there are
> > > questions, I would be happy to try to respond. Fixing the
'Journal
> > > is Full' dialog is a major help. However, what do you
recommend to
> > > deployments when this happens?
> >
> > 1. upgrade to Sugar 0.108 (by RPM or images), or backport the
patch
> > [#9623, #1720] into your custom builds,
> >
> > 2. transcode content to play in browser not Journal,
> >
> > 3. delete any activities that are not needed,
> >
> > 4. deploy Sugar Network to use the network activity cache,
> >
> > Also delete the Browse temporary directories, you reported this on
> > 19th January, it remains a problem, and you refused to test my
fix, so
> > I lost interest very rapidly. [#4931]
> >
> > > The bottom line is that a reasonably active user is likely
to need
> > > more room to store her Journal than is available on the XO.
> >
> > No, because it's no longer a significant problem. XO-1 are in the
> > minority and getting rarer as they die. Those that haven't
died have
> > SD cards.
> >
> > > In the Journal code a filled star sets the 'keep' flag in the
> > > metadata. The cleared star clears the 'keep' flag in the
metadata.
> > > Using this feature greatly simplifies the coding and the Journal
> > > view. As far as I know, the only use of this at the moment is to
> > > support the Portfolio activity.
> >
> > You are using an implementation detail in describing the
flag. The
> > name given to the flag in documentation and user interface is
> > "favorite" (sic).
> >
> > > I think the detail view is inappropriate exactly as it would
be to
> > > move the multiple selection checkbox there. These controls
need to
> > > be immediately available.
> >
> > I disagree; they won't get used, and so it would be a waste of
> > valuable vertical space. The reason the checkbox won't get
used is;
> >
> > - most laptops don't have a server,
> >
> > - an LRU algorithm can maintain the cache effectively.
> >
> > > The 'backup/sync' script is a good place to do check storage
quotas
> > > because the script needs to touch the datastore on a regular
basis.
> > > It has access to the amount of store in use and the LRU
information.
> > > For example, if the user wants a document downloaded, the script
> > > knows its size and whether some other local copies need to be
> > > deleted to make room.
> >
> > I disagree. This script runs infrequently. The LRU must be
> > implemented inside the datastore for it to function properly.
> > Otherwise the lag between user action and response by the
script would
> > be too long.
> >
> > > While an implementation detail, so far no change has been
necessary
> > > to the datastore class.
> >
> > That's no reason not to change it.
> >
> > > Actually, since the 'keep' or favorite star sets the metadata,
> > > so far there has been no need to change the Journal.
> >
> > That's no reason not to change it.
> >
> > > "The multiple user feature is supported by Fedora and Sugar,
but we
> > > removed it for OLPC OS."
> > >
> > > I think I am beginning to understand. OLPC OS is your
generic name
> > > for the images to be installed on each model of the XO.
> >
> > Really, you are out of touch! OLPC OS is our name for the
operating
> > system releases on the XO laptop. We've been using the term
at OLPC
> > for a very long time, and use it in each release announcement.
> >
> > > I am deploying build 13.2.5 with Sugar 0.106 on all models.
> >
> > That's so sad. It was released in July 2015. It has the
journal full
> > bug you mentioned. I'm not interested in supporting that release,
> > because I've already released two others. Upgrade.
> >
> > > So you are saying that we, users of Sugar or ' OLPC OS'
could have a
> > > multiple user version of Sugar if 'you', as developers, didn't
> > > remove it.
> >
> > Well done.
> >
> > > As I understand it, you propose to generate unique
serial-numbers
> > > per user.
> >
> > No. I was describing what happens _now_ during registration, by
> > reference to the code:
> >
> > 1. for XO laptops the serial number of the laptop is used,
> >
> > 2. for non-XO laptops a serial number is generated randomly,
> >
> > 3. there is no attempt to ensure the random serial number is
> > unique, but the width of the random string is sufficient to
make it
> > unlikely,
> >
> > > So SSO would be guaranteed since no two users could have
> > > the same serial-number. This would certainly work and probably
> > > involve very little change to the existing code. What will
be needed
> > > is a 'dns' to map serial-numbers to usernames.
> >
> > No, I wasn't proposing that. It's your idea. I don't think it's
> > guaranteed to be unique though.
> >
> > > Every school I have worked with keeps a careful record of
students
> > > (often in paper ledgers). Currently I provide a name record in a
> > > Django database on the server (along with an XO inventory by
serial
> > > number).
> >
> > Fail to see relevance. Not all schools will or can do this.
> >
> > > Agreed that determining which Journal objects need to be
saved to
> > > the school server is not a difficult problem. However,
datastore is
> > > a class so each user's datastore and the common datastore
would be
> > > instances. So this seemed like a simple thing to implement.
> > >
> > > Actually, The deletion of Journal objects without an associated
> > > document works amazingly well. The number of objects in the
Journal
> > > view goes from hundreds to only a few (often less than 20).
> > > Moreover, these 20 are the obviously interesting ones.
Nothing is
> > > lost as the metadata is saved to the school server. It
becomes much
> > > easier to 'reflect' when you are only looking at the
documents you
> > > created. Meanwhile the myriad of objects can be subject to
> > > statistical analysis.
> > >
> > > For many activities, such as the Terminal, the document saved is
> > > actually 'state' information. This allows the Terminal
activity to
> > > be restored with tabs and pwd. There are many game
activities such
> > > as Memorize that also store state. It would seem more
appropriate to
> > > save this state information in the metadata. For example, a json
> > > could be created in the metadata to hold state information. The
> > > script could keep these objects to enable the user to resume.
> >
> > Your concept of metadata is not of interest to me; journal objects
> > must continue reflect the learner's use of the laptop if the
journal
> > is to meet the designed style of reflection.
> >
> > Unreflecting adults are not the target user.
> >
> > >
> > > Tony
> > >
> > > On 04/15/2016 01:36 PM, James Cameron wrote:
> > > >On Fri, Apr 15, 2016 at 10:25:59AM +0800, Tony Anderson wrote:
> > > >>Hi Manash
> > > >>
> > > >>The registration process is awkward but not the problem.
> > > >This is unfair scope creep. Manash began by asking about
bug #362
> > > >and
> > > >has been working to fix that. Now you're asking him to
consider a
> > > >much larger task; not a coding task, but a redesign of
Sugar Journal
> > > >and Backup interaction. This is huge.
> > > >
> > > >And as far as I can tell, students aren't even accepted yet
[1].
> > > >
> > > >1. https://en.wikipedia.org/wiki/Google_Summer_of_Code#2016
> > > >
> > > >What you propose is from a set of tasks [2] you added to
the Wiki,
> > > >which have not undergone any design review according to
Sugar Labs
> > > >design practice and feature policy. I do not see any
consensus on
> > > >these; we're yet to build a consensus.
> > > >
> > > >2.
> >
https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_on_the_Ground
> > > >
> > > >Or, it looks like you're trying to make your own fork of Sugar,
> > > >which
> > > >I'm fine with, it's open source after all, but to push that on
> > > >others
> > > >without their input is wrong.
> > > >
> > > >If you proceed without consensus as a sole designer, then
OLPC will
> > > >fork Sugar (as we already have so that XO-1s will go
faster), and
> > > >you'll be making your own builds.
> > > >
> > > >>The problem is that rsync is used to create backups of the
Journal
> > > >>and no effective means is offered to restore.
> > > >Agreed. We have no restore from server feature in Sugar 0.108,
> > > >along
> > > >with no way to start a backup to server, and no selective
restore.
> > > >
> > > >(We have backup to media, restore from media, but no selective
> > > >restore from media. Also, restore from media replaces
Journal!)
> > > >
> > > >>However, the ultimate problem is thinking of the problem
as one of
> > > >>backup. If you try to solve the wrong problem, often the
result is
> > > >>a
> > > >>wasted effort.
> > > >>
> > > >>The Journal is single place where Sugar users save their
documents.
> > > >>This is done by the Sugar activities when they close. The
majority
> > > >>of XOs are still XO-1s with a 1GB store.
> > > >This point in your argument is void, because XO-1 are 45%
of the XO
> > > >laptops manufactured so far. I have the numbers.
> > > >
> > > >Also, many XO-1 have been upgraded with an SD card.
> > > >
> > > >>If the available store is less than 50GB,
> > > >No, that's 50 MB, not 50 GB. See _SPACE_TRESHOLD (sic) in
> > > >sugar:src/jarabe/journal/journalactivity.py [3].
> > > >
> > > >3.
> >
https://github.com/sugarlabs/sugar/blob/master/src/jarabe/journal/journalactivity.py#L56
> > > >
> > > >>Sugar effectively shuts down.
> > > >This point in your argument is void, because this has been
fixed [4,
> > > >5, 6], please upgrade to Sugar 0.108 which is in OLPC OS
13.2.7 [6].
> > > >
> > > >4. http://dev.laptop.org/ticket/9623
> > > >5. https://bugs.sugarlabs.org/ticket/1720
> > > >6. http://wiki.laptop.org/go/Release_notes/13.2.7#Fixes
> > > >
> > > >>This typically results in the deployment reflashing the XO
erasing
> > > >>all of the documents created by that user - a tragedy.
> > > >It was a known bug, so that's a training issue. You previously
> > > >proposed to train a teacher to use "rm -rf" to delete a
known_hosts
> > > >file instead of Manash coding up an "ssh-keygen -R"
command. It is
> > > >inconsistent to be able to do one and not the other.
> > > >
> > > >>What I am proposing is to use the school server as the primary
> > > >>store
> > > >>for the Journal with its effectively unlimited storage
capacity.
> > > >>The
> > > >>ds_backup script needs to read the datastore uploading any
new or
> > > >>modified documents. The local datastore can then be viewed
as a
> > > >>cache for current working documents.
> > > >I'm favour of this ideal in principle, but it remains a
huge design
> > > >and consensus challenge, not a coding challenge.
> > > >
> > > >However, with the XO-1, XO-1.5 and XO-1.75 using IEEE
802.11g the
> > > >local wireless network will collapse sooner due to this new
load.
> > > >
> > > >>On the XO, the datastore is shown in the Journal. The
'keep' star
> > > >There's no such thing. There's a favorite star [7]. It has a
> > > >defined
> > > >purpose. Are you proposing to destroy that purpose, or add
another
> > > >column to the journal? There's even less room now that the
multiple
> > > >selection checkbox was added.
> > > >
> > > >7. https://help.sugarlabs.org/en/journal.html#journal-features
> > > >
> > > >>could be used to show whether there is a local copy of that
> > > >>document
> > > >>or not. If the document is not needed locally, the user
can clear
> > > >>the star. In this case, the backup script could delete the
local
> > > >>copy. If there is no local copy of the document, then the user
> > > >>could
> > > >>set the star. In this case the backup script could
download the
> > > >>document.
> > > >My preference would be for the flag to be in the Journal detail
> > > >view [8], where there is available display space.
> > > >
> > > >8.
https://help.sugarlabs.org/en/journal.html#journal-detail-view
> > > >
> > > >>This capability could be used to set a quota on the amount
of space
> > > >>used by the Journal. If the space is exceeded, the
'backup' script
> > > >>could delete local copies of document by LRU until the
quota is
> > > >>met.
> > > >>Similarly, there should be a quota on Sugar activities
which could
> > > >>also automatically be pruned back LRU. Managing the store
> > > >>automatically is consistent with keeping the Sugar UI as
simple as
> > > >>possible.
> > > >This should be built into Sugar rather than in the
non-Sugar backup
> > > >script. They should be maintained together.
> > > >
> > > >This would be a code change to git repository
sugar-datastore and
> > > >the
> > > >Journal activity in repository sugar.
> > > >
> > > >>As always, there are complications. The original OLPC
concept was
> > > >>that there would be one XO per user. As a result the
software was
> > > >>designed for a single user identified by the XO serial number.
> > > >The multiple user feature is supported by Fedora and Sugar,
but we
> > > >removed it for OLPC OS.
> > > >
> > > >>Today, many XO deployments provide enough XOs for a classroom.
> > > >>During the day, different students use the XO as their
class goes
> > > >>to
> > > >>the computer lab or as the computers are distributed from
classroom
> > > >>to classroom. However, all of the documents created are in
a single
> > > >>Journal with only the user's memory to indicate which
document goes
> > > >>with which user.
> > > >OLPC did not design OLPC OS to be used in this scenario, so no
> > > >surprise you've hit that. But it's not a Sugar problem. Don't
> > > >conflate Sugar with OLPC OS.
> > > >
> > > >>The OLPC Ubuntu Sugar 14.04 Trusty LTS (to use its
official name)
> > > >>solves this problem at the laptop side by using standard
gnu/linux
> > > >>logins.
> > > >The multiple user feature is supported by Ubuntu and Sugar,
and I
> > > >haven't removed it yet. I know how to; small configuration
change
> > > >to
> > > >lightdm package.
> > > >
> > > >Don't forget SoaS. The Fedora 23 SoaS is easily installed
to disk
> > > >and
> > > >has multiple user capability. The Fedora 24 SoaS is
shaping up to
> > > >be
> > > >just as good or better, since it is based on Sugar 0.108.
> > > >
> > > >>Each user has her own username and password. The Sugar
activities
> > > >>have been moved to common space in the file system so only
one copy
> > > >>is needed to support multiple users. Users are not 'olpc' but
> > > >>identified by their username. However, the datastore is
part of
> > > >>the
> > > >>user space (one datastore per user).
> > > >Yes. ODPU.
> > > >
> > > >>This is problematic since the backup script uploads to
> > > >>/library/user/serial-number on the school server.
> > > >No, you're wrong. In the Ubuntu scenario, the register_laptop
> > > >function will invent a serial number because it won't find Open
> > > >Firmware [1]. So it wouldn't be a problem. It doesn't
sound like
> > > >you've tested this.
> > > >
> > > >1.
> >
https://github.com/sugarlabs/sugar/blob/master/src/jarabe/desktop/schoolserver.py#L110
> > > >
> > > >>So, one strategy would be to upload to
/library/user/username. This
> > > >>requires that usernames be unique across all laptops using
a given
> > > >>schoolserver. This could be enforced at registration on
the school
> > > >>server.
> > > >Starting to sound very complicated. Single-sign-on (SSO)
across a
> > > >school. These are truly amazing teachers with lots of free
> > > >administration time.
> > > >
> > > >(There are deployments using Sugar with SSO already, but as
it's
> > > >outside the scope of Sugar we don't hear about them at
Sugar Labs,
> > > >and
> > > >we don't provide the facility in OLPC OS, but that doesn't stop
> > > >them.)
> > > >
> > > >>However, the Sugar releases for the XO
> > > >We call that OLPC OS, which includes Sugar and Gnome desktops.
> > > >
> > > >>still maintains Sugar activities in /home/olpc/Activities.
So, one
> > > >>requirement is to restructure Sugar as was done for OLPC
Ubuntu
> > > >>Sugar 14.04 Trusty LTS.
> > > >That would not block implementing a server datastore, since the
> > > >implementation would not care what $HOME is set to.
> > > >
> > > >(And besides, it's already done for SoaS, so the Fedora
activity
> > > >packages can be used immediately.)
> > > >
> > > >>Another approach might be to create directories for each
user of a
> > > >>single XO (e.g. /library/user/serial-number/user1).
> > > >That would require authentication service by the server
datastore.
> > > >
> > > >>Another complication is that the Browse activity downloads
files
> > > >>from the school server to the Journal (e.g. pdfs, mp3). These
> > > >>documents do not need to be saved to the users Journal
backup on
> > > >>the
> > > >>school server since they can be restored from the school
server
> > > >>'library'. Also, such documents when downloaded should be
stored in
> > > >>a common space available to all users of that laptop.
Fortunately,
> > > >>the source of a document is provided in the metadata.
> > > >What you describe here can also be solved by deduplication.
> > > >
> > > >The Journal Git backend proposed by Martin and Walter could
help
> > > >with
> > > >deduplication of journal objects across multiple journals.
> > > >
> > > >https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_Core
> > > >
> > > >>One approach would be to divide the datastore into two
directories
> > > >>on the laptop, one in common space and the other local to
the user.
> > > >>The Journal could show both sets of objects.
> > > >Or the server datastore would recognise content hashes of
server
> > > >artefacts and know it need not send the content from the
client to
> > > >the
> > > >server before LRU local deletion. It could hard link it.
> > > >
> > > >>Finally, each Journal object consists of a metadata file
and an
> > > >>optional document. The metadata files tend to clutter the
Journal
> > > >>display (mine has hundreds of Terminal activity and Log
activity
> > > >>entries). I would propose that the Journal show only
objects which
> > > >>have a document with a user-supplied name (a metadata
flag). The
> > > >>script should backup the metadata files for those objects
without a
> > > >>document to a 'log' on the school server for statistical
analysis
> > > >>but delete them from the local datastore. Journal objects
saved
> > > >>without a user-supplied name (but something like
Write.activity)
> > > >>should have their document deleted. As part of GSOC there
is an
> > > >>initiative to require users to supply a name for documents
they
> > > >>wish
> > > >>to save - so this problem may not be part of the 'backup'
scheme.
> > > >>Whether a document is saved or deleted, the metadata can
be saved
> > > >>to
> > > >>the log and displayed by the existing statistical tools.
> > > >I'm against any classification of journal objects in this
way. We
> > > >cannot know how useful a Terminal and Log activity object
is to the
> > > >learner.
> > > >
> > > >However, I would like a way for expert users to terminate an
> > > >activity
> > > >without saving a journal object.
> > > >
> > > >>As an old crumudgeon, I still believe design precedes coding.
> > > >>
> > > >>Reading the existing code is always a good idea:
> > > >>
> > > >>Sugar
> > > >>
> > > >> *
> > >
>>/usr/lib/python2.7/site-packages/jarabe/desktop/schoolserver.py
> > > >>#registers server - notice transition from gconf to gsettings
> > > >> * /usr/bin/ds_backup.sh #primarily decides if backup
can be
> > > >> run
> > > >> #backup logic is
> > > >> needed
> > > >>because an rsync can use a lot of bandwidth in a local network
> > > >> * /usr/bin/ds_backup.py #actually does the backup using
> > > >> rsync
> > > >>(note: -d option AFAIK deletes an object from the backup
if it is
> > > >>deleted in the source,
> > > >> #this has the effect
> > > >> of
> > > >>limiting the size of the datastore to the available space
on the XO
> > > >>not on the school server).
> > > >>
> > > >>Server (xsce6)
> > > >>
> > > >> * /usr/libexec/idmgr #contains a number of utilities
> > > >>used in registration
> > > >> * /library/users #contains a directory per
> > > >>serial-number of registered user
> > > >> #use ls -a to see
> > > >> files
> > > >>created. The idmgr creates a public/private key pair which
is used
> > > >>by sftp to authenticate - avoiding password
> > > >>
> > > >>Note: if you look at the server code, you can see why
registering
> > > >>the laptop on each connection works (and can avoid any
need for a
> > > >>registration menu item).
> > > >>
> > > >>When you get to know your way around the existing process,
I'll
> > > >>send
> > > >>you a copy of the ds_backup.py code I use to implement the
item by
> > > >>item backup.
> > > >You should start using GitHub like the rest of us.
> > > >
> > >
> > > _______________________________________________
> > > Sugar-devel mailing list
> > > Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
> > > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> > --
> > James Cameron
> > http://quozl.netrek.org/
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
<mailto: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
