Re: [Sugar-devel] Fw: Nano and soas03/04/05

[Sebastian Dziallas]

Sorry for the late reply... I'm quite behind my e-mail. :/

Just add --nogpg to your yum call, and it should work for now. We're 
looking to get this generally to work in Blueberry.

--Sebastian

Art Hunkins wrote:
> I'd really appreciate a response about this.
>
> On sticks make with snapshots soas03, 04, and 05, I've attempted to install
> nano. (Yes, I try to do "development" with the USB sticks themselves.)
>
> Via yum, tt downloads nano 2.0.9-6.fc13.i686.rpm, but then indicates that
> the rpm is not signed.
>
> Can I do anything - or do I need to wait for Blueberry for this to sort
> itself out?
>
> Art Hunkins
>
> - Original Message -
> From: "Art Hunkins"
> To:
> Sent: Tuesday, November 17, 2009 8:32 PM
> Subject: Nano and soas03/04/05
>
>
>> I've been working with the SoaS03, 04, and 05 iso's, and want to download
>> the nano text editor. I've not been able to do so.
>>
>> I do:
>> su
>> yum install nano
>>
>> This has always worked for me in the past.
>>
>> All goes well until I'm informed that the (fc13) rpm is not signed.
>> Perhaps a version incompatibility?
>>
>> What to do?
>>
>> Art Hunkins
>
> ___
> 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] Fw: Nano and soas03/04/05

[Art Hunkins]

I'd really appreciate a response about this.

On sticks make with snapshots soas03, 04, and 05, I've attempted to install 
nano. (Yes, I try to do "development" with the USB sticks themselves.)

Via yum, tt downloads nano 2.0.9-6.fc13.i686.rpm, but then indicates that 
the rpm is not signed.

Can I do anything - or do I need to wait for Blueberry for this to sort 
itself out?

Art Hunkins

- Original Message - 
From: "Art Hunkins" 
To: 
Sent: Tuesday, November 17, 2009 8:32 PM
Subject: Nano and soas03/04/05


> I've been working with the SoaS03, 04, and 05 iso's, and want to download 
> the nano text editor. I've not been able to do so.
>
> I do:
> su
> yum install nano
>
> This has always worked for me in the past.
>
> All goes well until I'm informed that the (fc13) rpm is not signed. 
> Perhaps a version incompatibility?
>
> What to do?
>
> Art Hunkins 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [SLOBS] meeting reminder

[Walter Bender]

We'll be meeting at 10AM EST (15:00 UC) on Friday, 20 Nov. in
irc.freenode.net #sugar-meeting, Please join us. The agenda can be
found in the wiki:

http://wiki.sugarlabs.org/go/Oversight_Board/Minutes#Agenda%20items

-walter
-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[James Cameron]

On Thu, Nov 19, 2009 at 03:11:07PM +0100, Tomeu Vizoso wrote:
> 2009/11/13 Jonas Smedegaard :
> > Generally, I recommend Sugarlabs to document clearly in source of
> > the various components (e.g. in an INSTALL file) which versions of
> > Python the code is expected to work against, and which version has
> > been extensively tested.
> 
> We have http://wiki.sugarlabs.org/go/0.86/Platform_Components for
> that, maybe we can point to that page in the INSTALL files of all
> Sugar modules?

I'm releaser of pptp and pptpd, and if I referred to Wiki pages for
build instructions, dependencies or test results external to my source
repository or tarball, I'm sure I'd get a few raised eyebrows or
complaints.

Is there a reason why you don't want to have these dependencies or known
test results in the source?  If they are not available at the time of
release, that's a good reason.  In which case saying that in INSTALL is
also a good idea.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [NEW FEATURE] write to the journal whenever you want

[Walter Bender]

On Thu, Nov 19, 2009 at 5:37 PM, Wade Brainerd  wrote:
> Looks like a nice improvement to me.
>
> But, per thread from a few weeks ago, I think the Keep vs Stop concept
> needs attention and this feature should probably become a part of
> whatever solution we reach for that difficult problem.

I don't want to minimize its importance, but I am not sure that the
Keep vs Stop issue is really related to the
write-about-what-you-are-doing-while-you-are-doing-it issue. The
former has to do with saving your work. The latter about reflecting
upon your work. Maybe it is a reasonable heuristic to save a version
every time you stop to write? In any case, we need the ability to
write at any time. (Right now, if you write in the Journal while an
activity is open, your changes are lost when the activity is closed.
This patch doesn't fix that problem either, but it eliminates the need
to go to the Journal i the first place--a somewhat controversial
approach.)

-walter


> On Thu, Nov 19, 2009 at 4:10 PM, Eduardo H. Silva  
> wrote:
>> I like the idea, and much prefer it.
>> As for the design, what about using as a toolbar icon the
>> journal+pencil icon? It would imply that you are writing something
>> into the journal, in this case the title and description and tags of
>> the current activity.
>> There is a potential problem of adding another persistent icon to the
>> toolbar, which is it shrinks the space for the activity's icons. If
>> this is the case, perhaps this functionality should be merged with the
>> Keep button in some way, but since Keep is/will be used to Keep new
>> versions and also to Keep the activiy in a different format it would
>> need a new design. Perhaps these options (Keep new version, Keep as X)
>> could be added as buttons on the top or bottom of the description
>> window which would be a secondary palette of the Keep button.
>>
>> Just food for thought.
>>
>> Eduardo
>>
>> 2009/11/19 Walter Bender :
>>> Many of us love the Naming Alert, but even more seem to despise it.
>>> With this feature, it is invoked from a toolbar button instead of
>>> automatically invoked on quit. It lets the learning take notes
>>> repeatedly and at any time during an activity session.
>>>
>>> See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime
>>>
>>> This is a quick hack. We may want to revisit the toolbar integration
>>> and certainly need a better icon :)
>>>
>>> Comments?
>>>
>>> -walter
>>> --
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>> ___
>>> 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
>>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [NEW FEATURE] write to the journal whenever you want

[Wade Brainerd]

Looks like a nice improvement to me.

But, per thread from a few weeks ago, I think the Keep vs Stop concept
needs attention and this feature should probably become a part of
whatever solution we reach for that difficult problem.

On Thu, Nov 19, 2009 at 4:10 PM, Eduardo H. Silva  wrote:
> I like the idea, and much prefer it.
> As for the design, what about using as a toolbar icon the
> journal+pencil icon? It would imply that you are writing something
> into the journal, in this case the title and description and tags of
> the current activity.
> There is a potential problem of adding another persistent icon to the
> toolbar, which is it shrinks the space for the activity's icons. If
> this is the case, perhaps this functionality should be merged with the
> Keep button in some way, but since Keep is/will be used to Keep new
> versions and also to Keep the activiy in a different format it would
> need a new design. Perhaps these options (Keep new version, Keep as X)
> could be added as buttons on the top or bottom of the description
> window which would be a secondary palette of the Keep button.
>
> Just food for thought.
>
> Eduardo
>
> 2009/11/19 Walter Bender :
>> Many of us love the Naming Alert, but even more seem to despise it.
>> With this feature, it is invoked from a toolbar button instead of
>> automatically invoked on quit. It lets the learning take notes
>> repeatedly and at any time during an activity session.
>>
>> See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime
>>
>> This is a quick hack. We may want to revisit the toolbar integration
>> and certainly need a better icon :)
>>
>> Comments?
>>
>> -walter
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> ___
>> 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] [NEW FEATURE] write to the journal whenever you want

[Eduardo H. Silva]

I like the idea, and much prefer it.
As for the design, what about using as a toolbar icon the
journal+pencil icon? It would imply that you are writing something
into the journal, in this case the title and description and tags of
the current activity.
There is a potential problem of adding another persistent icon to the
toolbar, which is it shrinks the space for the activity's icons. If
this is the case, perhaps this functionality should be merged with the
Keep button in some way, but since Keep is/will be used to Keep new
versions and also to Keep the activiy in a different format it would
need a new design. Perhaps these options (Keep new version, Keep as X)
could be added as buttons on the top or bottom of the description
window which would be a secondary palette of the Keep button.

Just food for thought.

Eduardo

2009/11/19 Walter Bender :
> Many of us love the Naming Alert, but even more seem to despise it.
> With this feature, it is invoked from a toolbar button instead of
> automatically invoked on quit. It lets the learning take notes
> repeatedly and at any time during an activity session.
>
> See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime
>
> This is a quick hack. We may want to revisit the toolbar integration
> and certainly need a better icon :)
>
> Comments?
>
> -walter
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> 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] [Karma] possible to meet soon to discuss new karma.js?

[Felipe López Toledo]

I'm online, why not now?


2009/11/19 Bryan Berry 

> I have refactored jquery.karma.js into karma.js and am now changing
> adding_up to use it.
>
> Will u have time soon for us to talk and discuss it?
>
> I have made a lot of changes that I want to discuss w/ u
>
> --
> Bryan W. Berry
> Senior Engineer
> OLE Nepal, http://www.olenepal.org
>
>


-- 
Felipe López Toledo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Karma] possible to meet soon to discuss new karma.js?

[Bryan Berry]

I have refactored jquery.karma.js into karma.js and am now changing
adding_up to use it.

Will u have time soon for us to talk and discuss it?

I have made a lot of changes that I want to discuss w/ u

-- 
Bryan W. Berry
Senior Engineer
OLE Nepal, http://www.olenepal.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [NEW FEATURE] write to the journal whenever you want

[Walter Bender]

Many of us love the Naming Alert, but even more seem to despise it.
With this feature, it is invoked from a toolbar button instead of
automatically invoked on quit. It lets the learning take notes
repeatedly and at any time during an activity session.

See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime

This is a quick hack. We may want to revisit the toolbar integration
and certainly need a better icon :)

Comments?

-walter
-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] configuring Socksproxy for Jabber Server on the XO-1 or XO-1.5

[Manusheel Gupta]

On Thu, Nov 19, 2009 at 7:41 PM, Tomeu Vizoso  wrote:

> 2009/11/18 Manusheel Gupta :
>  > We did try to search around but have not been able to make much progress
> towards configuring socks proxy on the XOs. Are you aware if someone would
> have tried this
> > before?
>
> Just to be sure, you want to tell the presence service to connect to a
> ejabberd server through SOCKS?
>


Yes. Establishing this communication is useful for working with activities
using non-https protocols like XMPP ( e.g. - Chat activity). We are trying
to explore a variety of possibilities and scenarios, and build the basic
infrastructure before moving towards the development of activities like
Video Talk, VOIP service etc.



>
> > On a separate note, https-proxy works well for all data oriented
> connections using https protocol. Foxyproxy is another interesting Mozilla
> plug-in we are looking forward to explore.
>
> And with this you mean that you have managed to tell Browse to use a
> SOCKS server to access web pages?
>
>
Yes, exactly.

Thank you Tomeu.

Manu





> Thanks,
>
> Tomeu
>
> > Copying Morgan on the thread.
> >
> > Regards,
> >
> > Manu
> >
> >
> >
> >
> >
> >
> > On Wed, Nov 18, 2009 at 11:44 PM, Tomeu Vizoso 
> wrote:
> >>
> >> 2009/11/15 Manusheel Gupta :
> >> > Dear all,
> >> >
> >> > Do we have documentation somewhere on the steps involved in
> configuring socksproxy for jabber server on the XO-1 or XO-1.5? Please let
> us know.
> >>
> >> Hi Manu,
> >>
> >> have you done any progress on this since then?
> >>
> >> Thanks,
> >>
> >> Tomeu
> >>
> >> > Thank you.
> >> >
> >> > Regards,
> >> >
> >> > Manu
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> «Sugar Labs is anyone who participates in improving and using Sugar.
> >> What Sugar Labs does is determined by the participants.» - David
> >> Farning
> >
> >
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] sugar master will depend on simplejson again

[Sascha Silbe]

On Thu, Nov 19, 2009 at 04:33:05PM +, Daniel Drake wrote:


We've found that sugar's recent switch to cjson has caused issues and
cjson upstream doesn't seem receptive to fixing them.
The latter isn't quite true: It has rejected the specific patch for 
technical reasons (and proposed a different way to fix it). 
Unfortunately
a) quite some time (without it getting fixed upstream) has passed since 
and
b) I didn't get any response from upstream when asking about when it 
might get fixed.
So for all practical purposes (except someone coming up with a better 
patch) it's the same. :-/


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] sugar master will depend on simplejson again

[Daniel Drake]

Hi,

We've found that sugar's recent switch to cjson has caused issues and
cjson upstream doesn't seem receptive to fixing them.
So the plan is to move back to simplejson on monday, like things were
before.

Daniel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Jonas Smedegaard]

On Thu, Nov 19, 2009 at 04:01:55PM +0100, Tomeu Vizoso wrote:

On Thu, Nov 19, 2009 at 15:53, Jonas Smedegaard  wrote:

On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:


2009/11/13 Sascha Silbe :


On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:

As Tomeu mentions, Python 2.6 reduces the cjson/json performance 
advantage.


OK, didn't see this. Yes, using python standard library seems like 
the way to go.


Unfortunately not all distros ship Python 2.6 yet, most notably 
Debian. So we need to at least fall back to simplejson for those.


Sounds good to me, so maybe we can ask for a minimum of 2.6 for 
0.88? How well that plays with Debian and its derivatives?


I recommend you to not tune into specific needs of Debian or other
particular distros, but aim generally at the FLOSS world.

Generally, the faster you tighten the requirements, the more do you
discourage the use of long-term supported systems.  Which is bad for
deployers, especially those with few resources!

So please include fallbacks when using features available only in newer
backend libraries.  Not to play nice with Debian, but to play nice with
"slow movers".


I see the value in playing nice with "slow movers" but there's also a 
cost to be paid by both upstream and other distros, so if we can get a 
better idea of what we actually gain, we can better find the sweetest 
spot between old and recent dependencies.


I am aware that it is a bigger burden on upstream (i.e. you guys) to 
support a wider range of libraries.  This particular case does not sound 
like a much bigger burden, however: you need to figure out the 
workaround anyway for current releases, it is just a matter of how long 
you maintain it.


I fail to see how any distro will be hurt by you providing fallbacks - 
distros using newer libraries get the speed gains of those, without 
penalties of the fallbacks, no?


I recommend you to add a note in INSTALL file in the tarballs of code 
containing simplejson fallbacks to mention that the code _support_ 
Python 2.5 and newer, is _tested_ mainly on Python 2.6, and that you 
_encourage_ using Python 2.6 or newer due to known speed penalties of 
workarounds when using Python 2.5.


Sure, you can add such notes on web pages too, but I still recommend to 
use the common place for distributors to look for install-related notes 
which is an INSTALL file in the root of the tarball.



Oh, and in case you misunderstood me (why else call it "other distros"): 
I explicitly talked about *deployers* as slow movers, not distros.  
Debian, as an example (and only that, I am not comparing distros here!), 
is in no way slow if you (as deployer) choose to follow the "testing" 
branch. Similarly Fedora is _very_ slow if (as deployer) you are using 
quite old release of that distro - as is the case with OLPC and many 
XO-1 deployments as I understand it.



 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ANNOUNCE] sugar-datastore sucrose-0.86 branch

[Aleksey Lim]

Hi all,

sugar-datastore was branced for 0.86 bug fixes,
master branch is open for 0.88 commits.

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] sugar branched for 0.86

[Daniel Drake]

Hi,

I have just created the 'sucrose-0.86' branch in the sugar git
repository. Further 0.86 development will happen there, and 0.88
development will happen in master.

Daniel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Python 2.6 for 0.88 (was: Re: Rationale behind the JSON -> CJSON switch in Sugar codebase?)

[Tomeu Vizoso]

On Thu, Nov 19, 2009 at 16:24, Sascha Silbe
 wrote:
> On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:
>
>>> Unfortunately not all distros ship Python 2.6 yet, most notably Debian.
>>> So we need to at least fall back to simplejson for those.
>>
>> Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88?
>
> As mentioned Debian still doesn't include 2.6 even in unstable, so AFAICS it
> probably won't get into squeeze. Debian is going to continue with the (more
> or less) regular 2 year release cycle after squeeze, so we're going to be
> stuck with 2.5 for quite a while. I don't particularly like that, but can't
> do anything about it.
>
> Is there anything in 2.6 that's
> a) very useful for Sugar but
> b) doesn't have an easy enough fallback?

Generally, easy fallbacks can be found, the problem is cluttering the
source with those.

Regards,

Tomeu

> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLBWNGAAoJELpz82VMF3DavGAH/2tyAi7mnF+bO1X5SK6ZS06a
> oSd4hzLFZk+YoXtJZpBEeWnBGvuBk0sPYIRQb3P86zut7L6W6KLyaF8CHdHzEdYc
> Y0D1c3t5Fl81rZWFBcbS9rEdWd+zlCaCAptk5EoWFkbzr93TIz3faBBCOExkyrI4
> p4micC8ueAikfmhkA4w48OJLAcDti9A0i+t0DnDqzwdKs2gqJQ8kaRLwQSmimUMA
> L/dkmvey44KbXc10+ULXfxblX4jG/GAMYqHftXFLvm8VB8MV/pL/cA0krG3iygwh
> qYyyds70KGevpHhzPPxcdu1zFxzju/WGikFaAJ9zkg6dUQwB3zKSOBDxXbC0r5Y=
> =op7Y
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Python 2.6 for 0.88 (was: Re: Rationale behind the JSON -> CJSON switch in Sugar codebase?)

[Sascha Silbe]

On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:

Unfortunately not all distros ship Python 2.6 yet, most notably 
Debian. So we need to at least fall back to simplejson for those.

Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88?
As mentioned Debian still doesn't include 2.6 even in unstable, so 
AFAICS it probably won't get into squeeze. Debian is going to continue 
with the (more or less) regular 2 year release cycle after squeeze, so 
we're going to be stuck with 2.5 for quite a while. I don't particularly 
like that, but can't do anything about it.


Is there anything in 2.6 that's
a) very useful for Sugar but
b) doesn't have an easy enough fallback?

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] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

On Thu, Nov 19, 2009 at 15:53, Jonas Smedegaard  wrote:
> On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:
>>
>> 2009/11/13 Sascha Silbe :
>>>
>>> On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:
>>>
> As Tomeu mentions, Python 2.6 reduces the cjson/json performance
> advantage.

 OK, didn't see this. Yes, using python standard library seems like the
 way to go.
>>>
>>> Unfortunately not all distros ship Python 2.6 yet, most notably Debian.
>>> So we need to at least fall back to simplejson for those.
>>
>> Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88? How
>> well that plays with Debian and its derivatives?
>
> I recommend you to not tune into specific needs of Debian or other
> particular distros, but aim generally at the FLOSS world.
>
> Generally, the faster you tighten the requirements, the more do you
> discourage the use of long-term supported systems.  Which is bad for
> deployers, especially those with few resources!
>
> So please include fallbacks when using features available only in newer
> backend libraries.  Not to play nice with Debian, but to play nice with
> "slow movers".

I see the value in playing nice with "slow movers" but there's also a
cost to be paid by both upstream and other distros, so if we can get a
better idea of what we actually gain, we can better find the sweetest
spot between old and recent dependencies.

Regards,

Tomeu

>
>  - Jonas
>
> --
> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLBVvTAAoJECx8MUbBoAEhsisQAJKJPFTsWJZpbuwx0TiNAMm8
> t6ruywDn9rBz+g82qX6I9TS6QLQM6orbYsG8Sr9qLHIBT99zFPKvOS3mPxxZ+E67
> SCC9eLMeNHgfqkQdmH3tc0anSYirdsJtAMBJFQ28FNJ0LsnEd0dkqRlnr0NpVCPC
> Fv0tSz2X5M7J/+ZntBpkjbKCXmlGvPbGN7K6maegYgDFrEbUJHOQDg9GRlNURqfv
> 7QWRQ8ugDwc1J4dpkm+Wv+hAGOJMN1bri8z86+I+6MLMVu2E/G7782dnE3la2r7P
> JqNoZ0LJhOXFtex5Z+eYdrusyuHL6tvyG3Rq9QW9E9EIxsknzvvcNOvjcyVye8vV
> /xd1hqmQfuliYhZgTf0y9uZXHqiQC38vY9+DsDx1qIUoM0wli3TPpR90eWJbWuam
> EwbNBTvN9SeRCiQlZ4zOLqArBkzTBm/hgFdcEyLknZNzeYzrxEvXMZMcAC3ELTO8
> 1qugKtaoQPHWga9+mqVWHQaIKYirgg5C2pvon5JpPgd4p/Hm8jn61TkDsEJh+k07
> pzELul5atea+RxJ6N8wekJ7uk9fzKdigP07W9X+v7ED0eqeLiQsBzUwWJFb44zp1
> YwYDAbHrY/YQ+Gv5q3BBQ11miJ5FGkwS0bQeHRlTaHjnXTgfKQTGWiOa9hnDB3fh
> MdATnKjuBe0GtpH2wMry
> =sWVX
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Jonas Smedegaard]

On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:

2009/11/13 Sascha Silbe :

On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:

As Tomeu mentions, Python 2.6 reduces the cjson/json performance 
advantage.


OK, didn't see this. Yes, using python standard library seems like 
the way to go.


Unfortunately not all distros ship Python 2.6 yet, most notably 
Debian. So we need to at least fall back to simplejson for those.


Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88? 
How well that plays with Debian and its derivatives?


I recommend you to not tune into specific needs of Debian or other 
particular distros, but aim generally at the FLOSS world.


Generally, the faster you tighten the requirements, the more do you 
discourage the use of long-term supported systems.  Which is bad for 
deployers, especially those with few resources!


So please include fallbacks when using features available only in newer 
backend libraries.  Not to play nice with Debian, but to play nice with 
"slow movers".



 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] configuring Socksproxy for Jabber Server on the XO-1 or XO-1.5

[Tomeu Vizoso]

2009/11/18 Manusheel Gupta :
> Hi Tomeu,
>
> We did try to search around but have not been able to make much progress 
> towards configuring socks proxy on the XOs. Are you aware if someone would 
> have tried this
> before?

Just to be sure, you want to tell the presence service to connect to a
ejabberd server through SOCKS?

> On a separate note, https-proxy works well for all data oriented connections 
> using https protocol. Foxyproxy is another interesting Mozilla plug-in we are 
> looking forward to explore.

And with this you mean that you have managed to tell Browse to use a
SOCKS server to access web pages?

Thanks,

Tomeu

> Copying Morgan on the thread.
>
> Regards,
>
> Manu
>
>
>
>
>
>
> On Wed, Nov 18, 2009 at 11:44 PM, Tomeu Vizoso  wrote:
>>
>> 2009/11/15 Manusheel Gupta :
>> > Dear all,
>> >
>> > Do we have documentation somewhere on the steps involved in configuring 
>> > socksproxy for jabber server on the XO-1 or XO-1.5? Please let us know.
>>
>> Hi Manu,
>>
>> have you done any progress on this since then?
>>
>> Thanks,
>>
>> Tomeu
>>
>> > Thank you.
>> >
>> > Regards,
>> >
>> > Manu
>> >
>> >
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugarizing an application

[Tomeu Vizoso]

2009/11/12 Daniel Castelo :
> In a short term we are thinking in develop an activity to interact with 
> wwdial. In the future we are planning to test Sugar 0.8x and Network Manager 
> 0.7, and change our activity to interact with networkmanager. We should 
> investigate the way to interact with networkmanager (a set of APIs or 
> something like that).

Have you considered adding support for modems in the Sugar shell
instead of coding a new activity? That would be more in line with
Sugar's user experience.

Regards,

Tomeu

> Regards.
> Daniel
>
> On Fri, Nov 6, 2009 at 11:03 AM, Tomeu Vizoso  wrote:
>>
>> On Thu, Nov 5, 2009 at 16:51, Daniel Castelo
>>  wrote:
>> > I forgot to say you something important: !!!  thanks for your help!!!
>>
>> Welcome, how did you got this working?
>>
>> Thanks,
>>
>> Tomeu
>>
>> > On Mon, Oct 26, 2009 at 5:44 PM, Dan Williams  wrote:
>> >>
>> >> On Sun, 2009-10-25 at 09:39 +0100, Tomeu Vizoso wrote:
>> >> > On Wed, Oct 21, 2009 at 21:07, Dan Williams  wrote:
>> >> > > On Wed, 2009-10-21 at 13:46 +0100, Tomeu Vizoso wrote:
>> >> > >> On Wed, Oct 21, 2009 at 13:41, Daniel Castelo
>> >> > >>  wrote:
>> >> > >> > Sorry, just a distraction.
>> >> > >> > Is the image that we use in Uruguay, and doesn't have the root
>> >> > >> > access
>> >> > >> > available.
>> >> > >> > Network manager supports connections with a modem 3g?
>> >> > >>
>> >> > >> Current versions of NetworkManager do, but if it's the image now used
>> >> > >> in Uruguay (based in Fedora 9), then it may be too old.
>> >> > >
>> >> > > What version of NM ships on those?  NM 0.6x like we originally shipped
>> >> > > in the images in 2007/2008?  Or were Simon and Daniel able to update
>> >> > > them to NM 0.7.x?
>> >> >
>> >> > This is F9 with NM 0.6.5-0.12.svn3246.olpc3 . I think NM 0.7 support
>> >> > was added to Sugar 0.84 which hasn't gone into an official OLPC image
>> >> > yet.
>> >>
>> >> Ok, only NM 0.7.x and later support 3G.  So it looks like they will have
>> >> to wait for an official image, or install the NM 0.7.x ones by hand.
>> >>
>> >> Dan
>> >>
>> >> > Regards,
>> >> >
>> >> > Tomeu
>> >> >
>> >> > > Dan
>> >> > >
>> >> > >> I'm CC'ing Dan Williams who is the main author of NM in case he can
>> >> > >> suggest you a way forward.
>> >> > >>
>> >> > >> Regards and good luck,
>> >> > >>
>> >> > >> Tomeu
>> >> > >>
>> >> > >> > Thanks for your help
>> >> > >> >
>> >> > >> >
>> >> > >> > On Wed, Oct 21, 2009 at 10:26 AM, Tomeu Vizoso
>> >> > >> >  wrote:
>> >> > >> >>
>> >> > >> >> On Wed, Oct 21, 2009 at 13:22, Daniel Castelo
>> >> > >> >>  wrote:
>> >> > >> >> > OLPC release 9 (Joyride).  is enough?
>> >> > >> >>
>> >> > >> >> Sorry, not sure to what image that may correspond. Can you tell me
>> >> > >> >> how
>> >> > >> >> that image can be acquired? Depending on the configuration, root
>> >> > >> >> access may be available or not.
>> >> > >> >>
>> >> > >> >> But James' suggestion is good, if you can do it via
>> >> > >> >> NetworkManager,
>> >> > >> >> then you can work around the root limitation.
>> >> > >> >>
>> >> > >> >> Also, please don't drop the mailing list from the email recipients
>> >> > >> >> (do
>> >> > >> >> "reply all" instead of just replying to me).
>> >> > >> >>
>> >> > >> >> Regards,
>> >> > >> >>
>> >> > >> >> Tomeu
>> >> > >> >>
>> >> > >> >> > On Wed, Oct 21, 2009 at 10:05 AM, Tomeu Vizoso
>> >> > >> >> > 
>> >> > >> >> > wrote:
>> >> > >> >> >>
>> >> > >> >> >> On Wed, Oct 21, 2009 at 13:01, Daniel Castelo
>> >> > >> >> >>  wrote:
>> >> > >> >> >> > 0.82 of sugar with kernel 2.6.25-20090223.olpc
>> >> > >> >> >>
>> >> > >> >> >> A distribution is much more than sugar and a kernel, can you be
>> >> > >> >> >> more
>> >> > >> >> >> specific?
>> >> > >> >> >>
>> >> > >> >> >> Thanks,
>> >> > >> >> >>
>> >> > >> >> >> Tomeu
>> >> > >> >> >>
>> >> > >> >> >> >
>> >> > >> >> >> > On Wed, Oct 21, 2009 at 9:52 AM, Tomeu Vizoso
>> >> > >> >> >> > 
>> >> > >> >> >> > wrote:
>> >> > >> >> >> >>
>> >> > >> >> >> >> On Wed, Oct 21, 2009 at 12:50, Daniel Castelo
>> >> > >> >> >> >>  wrote:
>> >> > >> >> >> >> > First, I tried to sugarized gnome-ppp (made with  C and
>> >> > >> >> >> >> > gtk) and
>> >> > >> >> >> >> > execute
>> >> > >> >> >> >> > it
>> >> > >> >> >> >> > as an activity. But it doesn't looks fine. Now i am
>> >> > >> >> >> >> > thinking in
>> >> > >> >> >> >> > rewrite
>> >> > >> >> >> >> > gnome-ppp in python like "native" Activity. The problem
>> >> > >> >> >> >> > that i
>> >> > >> >> >> >> > have,
>> >> > >> >> >> >> > is
>> >> > >> >> >> >> > that
>> >> > >> >> >> >> > I need to execute wvdial as root and write the resolv.conf
>> >> > >> >> >> >> > file
>> >> > >> >> >> >> > with
>> >> > >> >> >> >> > the
>> >> > >> >> >> >> > dns
>> >> > >> >> >> >> > configuration. How can I run things with root privileges?
>> >> > >> >> >> >>
>> >> > >> >> >> >> Well, this has nothing to do with Sugar but with the
>> >> > >> >> >> >> underlying OS.
>> >> > >> >> >> >> Which distribut

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

2009/11/13 Jonas Smedegaard :
> On Fri, Nov 13, 2009 at 01:10:35PM +0100, Sascha Silbe wrote:
>>
>> On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:
>>
 As Tomeu mentions, Python 2.6 reduces the cjson/json performance advantage.
>>>
>>> OK, didn't see this. Yes, using python standard library seems like the way 
>>> to go.
>>
>> Unfortunately not all distros ship Python 2.6 yet, most notably Debian. So 
>> we need to at least fall back to simplejson for those.
>
> Generally, I recommend Sugarlabs to document clearly in source of the various 
> components (e.g. in an INSTALL file) which versions of Python the code is 
> expected to work against, and which version has been extensively tested.

We have http://wiki.sugarlabs.org/go/0.86/Platform_Components for
that, maybe we can point to that page in the INSTALL files of all
Sugar modules?

> One thing is that Debian do not currently ship Python 2.6 as default version 
> of Python.  Another is that we ship multiple versions concurrently, and 
> attempt[1] to allow users to choose at runtime.
>
> Currently I package Sugar packages with the assumption that they all work 
> with Python 2.5 and newer - but it would sure be better if you explicitly 
> stated which version were a) believed working and b) actually tested.

2.5 is all we have required to date, AFAIK.

> ...or that you provide refression tests, so that distributors can 
> automatically discover if some odd setup suddently stop working at a "minor" 
> Sugar update.

We really need that, though I think that we should first get a more
normal ratio of maintainers per module before we raise the
expectations of packagers.

Regards,

Tomeu

>
>  - Jonas
>
> [1] it is often difficult to package for multiple Python releases, so some 
> package maintainers choose the easier approach of only packaging for whatever 
> is the default version (which allows Ubuntu to switvh to their often newer 
> default version with a simple rebuild of same packaging, but does not allow 
> users at runtime to switch to a different version for that Python module - 
> and all dependent modules).
>
> --
> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJK/WJvAAoJECx8MUbBoAEht5MP/jMSQ7WlDVmxbVjOQmje6jpd
> 08y+EulLZ3HnM0f+HrIDlxqXjFrdjam3dn6gBaLYx6OdZ6rAwLiZtpAUtcE2LLp4
> i5ykvuCOSiePVPCRY7PpaskGNy7s8lgc3mrGSz9mOyQageqjOa+mVhrVL4joHLL0
> vqK1Y/jBl2IzKEcYGZnlTn5y5ZK42OXSwzpGPiDcn9i0sco2+tuLz/4PEeVZKy2q
> k/SIFXtgMXl1RRsR6QuIg4zwVeZopQnvCMxdjrLdXH+OfjHOv1TvTzkZF24iH9/p
> SYS8ZrtvPbCDgShgo3G4NIYj+MMbcXp9rT9bH6Z70nyKavO5SzPI/UAonB7LgNkZ
> ZBoq5mz1ZXNqhb7kW/D1nz9t33PPikBQ+Fnuy4JUZFBYKx9UueBHxueMoCw/cm5D
> BjNFUhfQD6vCfH5g4MzXgQ0TvSmW4bJLfvJpRIF0DnLQSl6nileiO1RV2li+Oiix
> itM5yHJlY4DbhZpKYw38AWNGVDZSv/+4+8aLs6lfr3PGMGj47Vqok/ENftkqBY0x
> 2bmekjv0+391LzOkKTqRfptAMBl4rswR7aZjEiuqfiWYK7XtPKPOUJXT9ELV82fK
> suyuGVmlBVeeFif1ATzx++pjjDaEovXAXAh25wHBfnAAg97rdyuJBfUFX11j97Z2
> jgt7n4LsnbtSumeTxjQo
> =w3U6
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

2009/11/13 Sascha Silbe :
> On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:
>
>>> As Tomeu mentions, Python 2.6 reduces the cjson/json performance advantage.
>>
>> OK, didn't see this. Yes, using python standard library seems like the
>> way to go.
>
> Unfortunately not all distros ship Python 2.6 yet, most notably Debian. So we 
> need to at least fall back to simplejson for those.

Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88?
How well that plays with Debian and its derivatives?

Regards,

Tomeu

> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJK/Uy7AAoJELpz82VMF3DaVrgH/3eITIQpsTw69cnj17uNtp3s
> H68eBr/0MNUig0SxbT5pHfHoWshykYr0xet/5O/SqmWfBrv43VG1pGee1bqHEDOq
> /+8lGF0WRjOYWMFhtld5g8TEhT9mnDzrdqYVi9NqXSEszF5qyovRI8h6IbxNiT3M
> rlKOUWPmFDroOOKloqoMh5Z1ChxltGECXeblSs7mX6S6CUf4awM4xuljMyfB4WLP
> 597Oeqz33F7iQqdVhnhUoAavf/hM7NV3LNRulD3uLDfDjHrCZejrel1YXV4ZFw3G
> dQhKs6MunV0YAhIhZbAA8PGZT58xgWDoYB1qWTBFtW5cGjYJmbiYP41JC1dwq1c=
> =8WBF
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Bugs] #1447 NORM: Display a message when an activity fails to start

[Tomeu Vizoso]

2009/11/4 Gary C Martin :
> Hi Wade,
>
> Just wanted to ping on this; have been running with your 0001-Notify-
> shell-when-activity-process-terminates.patch and 0001-Added-Close-
> button-to-activity-launcher-rewrote-lay.patch applied to sugar-jhbuild
> for the last ~4 days, and it has been working very well. Some of quick
> comments:
>
> - On just one occasion (have not been able to reproducible) I saw the
> 'Stop' button briefly display before the activity successfully launched.
>
> - I'm trying to find a different error message ' failed to
> start.' now that 'Stop' is the button text. My mind keeps grating
> against the dilemma of stopping something that never actually
> started :-)
>
> - The pulse pause feels a little long, perhaps 1 or 1.5 sec would be
> long enough. I really need to try and get this patch on XO-1 HW and
> see what the launch time savings are like (I'm sure even a 1:1 ratio
> of animation to pause should save us a couple of 2 seconds in many
> cases).
>
> - What ever the final pulse animation timing/pause ends up at
> (assuming we see some XO-1 load improvement) it should also be used
> for the other pulsing animations as well (activity tray activity icons
> when launching, corner notification effects).
>
> Again, fab work! It really makes activity developing test cycle much
> more friendly :-)

So, do we have a positive vote from the design team on this? Wonder
what would be the best way to get some feedback from the field, is
there already a screencast we can pass around?

Thanks,

Tomeu

> Regards,
> --Gary
>
> On 31 Oct 2009, at 02:06, Sugar Labs Bugs wrote:
>
>> #1447: Display a message when an activity fails to start
>> 
>> +---
>>    Reporter:  wadeb        |          Owner:  wadeb
>>        Type:  enhancement  |         Status:  accepted
>>    Priority:  Normal       |      Milestone:  0.88
>>   Component:  sugar        |        Version:  Git as of bugdate
>>    Severity:  Unspecified  |       Keywords:
>> Distribution:  Unspecified  |   Status_field:  Unconfirmed
>> 
>> +---
>>
>> Comment(by wadeb):
>>
>> I posted a brand new patch for Sugar.
>>
>>  * Improves the layout so the icon doesn't move when the error appears
>>  * Uses Stop as suggested by Gary
>>  * Delays for a few seconds between pulses to give the user
>> something to
>> count and potentially improve performance.
>>
>> --
>> Ticket URL: 
>> Sugar Labs 
>> Sugar Labs bug tracking system
>> ___
>> Bugs mailing list
>> b...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/bugs
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel