Re: [Sugar-devel] Physics Activity stopped after startup

[Asaf Paris Mandoki]

>>  I guess the other better/simpler option would be to A) remember the
>> state of the stop/start button, B) encourage the use of the 'Keep' button.
>> That way you could stop the simulation, build your experiment, and then hit
>> 'Keep' before starting the simulation again. That way you could always
>> resume the previously kept version and edit it some more if needed. That
>> also makes good use of the Journal metaphor rather than adding more 'save
>> states' into the activity itself. H, I'm rather liking this option...
>> ;-)
>
> I like this one better as well. Keeps the activity simple.

I would be glad to fix this but I'll be busy for a couple of week. If
it's not done when I'm free I'll give it a go. if we agree, a ticket
should be created.

We could do a composite solution where you can load a contraption from
the journal by clicking on a snapshot (maybe from a sidebar). Anyway,
the short term thing to do is to save the stop/start state. Anything
else would get done after we upgrade the UI which I guess will be in a
long time.

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

Re: [Sugar-devel] sugar-pippy dependencies

[Gary C Martin]

Hi Bernie,

On 29 Sep 2009, at 02:33, Bernie Innocenti wrote:

> Hello,
>
> the sugar-pippy rpm in Fedora depends on pygame, which is used by some
> of the examples.
>
> So far, so good, but pygame in turn depends on numpy, a 7.7MB package
> which a lot of huge dependencies such as atlas (11MB), libgfortran
> (1MB), blas (700KB) and python-nose (1MB).
>
> The rest of Sugar is now free of numpy, so it would be good if we  
> could
> get rid of it completely.  One quick solution would be splitting the
> problematic examples to a sugar-pippy-examples-extra package.
>
> Another possibility -- probably the cleanest -- would be splitting the
> optional classes surfarray and sndarray to a subpackage of pygame.

Hmmm, but isn't numpy a listed Sucrose dependancy for Activity  
developers to make use of? 0.86 and 0.84 for sure, possibly 0.82 as  
well (though maybe it was numeric back then).

I remember when we switched from numeric, several activities at least  
back then had to be updated (Measure was one), and I've almost used  
numpy myself for a couple of activity ideas I've hacked about with  
here (one is a cellular automata sand box environment, using bricks to  
program the rule sets, much like TA – I should really sit down and  
'get it done'). There may well be other activities relying on it.

Regards,
--Gary

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

Re: [Sugar-devel] sugar-pippy dependencies

[Wade Brainerd]

I wouldn't mind seeing a custom PyGame for Sugar (let's call it sugargame).
Ryan Gordon made a GTK backend for SDL which would allow the PyGame display
to coexist with GTK widgets[1].  Also, Nirav Patel has written a sweet
PyGame camera module which supports object tracking etc.  There's probably a
bunch of other useful stuff that could be rolled into PyGame beyond what
the (unmaintained) OLPCGames wrapper provides.

-Wade

[1] - http://lists.laptop.org/pipermail/games/2007-April/89.html

On Mon, Sep 28, 2009 at 9:33 PM, Bernie Innocenti wrote:

> Hello,
>
> the sugar-pippy rpm in Fedora depends on pygame, which is used by some
> of the examples.
>
> So far, so good, but pygame in turn depends on numpy, a 7.7MB package
> which a lot of huge dependencies such as atlas (11MB), libgfortran
> (1MB), blas (700KB) and python-nose (1MB).
>
> The rest of Sugar is now free of numpy, so it would be good if we could
> get rid of it completely.  One quick solution would be splitting the
> problematic examples to a sugar-pippy-examples-extra package.
>
> Another possibility -- probably the cleanest -- would be splitting the
> optional classes surfarray and sndarray to a subpackage of pygame.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs   - http://sugarlabs.org/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] sugar-pippy dependencies

[Bernie Innocenti]

Hello,

the sugar-pippy rpm in Fedora depends on pygame, which is used by some
of the examples.

So far, so good, but pygame in turn depends on numpy, a 7.7MB package
which a lot of huge dependencies such as atlas (11MB), libgfortran
(1MB), blas (700KB) and python-nose (1MB).

The rest of Sugar is now free of numpy, so it would be good if we could
get rid of it completely.  One quick solution would be splitting the
problematic examples to a sugar-pippy-examples-extra package.

Another possibility -- probably the cleanest -- would be splitting the
optional classes surfarray and sndarray to a subpackage of pygame.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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

Re: [Sugar-devel] [IAEP] Activity version compatibility

[Wade Brainerd]

Hey Gary,

On Mon, Sep 28, 2009 at 8:15 PM, Gary C Martin  wrote:

> Hmmm. So what happens when Sugar depreciates some API and breaks old
> activities? Say in a year or so when the core folks decide to remove the old
> toolbar API code? Or perhaps some of Telepathy and its API which is getting
> rather overdue for a fix'er'upper effort?


Yikes I really hope this never happens - the old toolbar code just depends
on GTK, right?  And if we drop some part of the collaboration API, couldn't
the Sugar team at least include a compatibility shim?  I guess it'll always
come down to a decision about how many activities are being broken and how
likely they are to be fixed.


> 1) Do the work to maintain backwards compatibility
>>
>
> See this is where I'm at. I'm very tempted to go back and add the old
> toolbar support back into Write (I already did this for Calculate and it's
> not too painful, working on the same for Labyrinth just now). The core devs
> don't think this is worth the effort, because they want folks to move up to
> newer versions of Sugar (and get to use all the great new features they have
> worked on), but the Activity developers also want their activities to be a
> maximum benefit right now, which means supporting 0.82 for the ~98% of our
> user base right now.


Ok then, I'm inspired :)  Is there a list of the activities that have been
ported to the new toolbar design somewhere, which need compatibility code
written?  It didn't seem trivial for Terminal, but it's only a few dozen
lines of code after all.

If it's just for developers that want to specifically warn that their
>> activity won't work. Why not let them just pop in a try/except around the
>> sensitive API and show an alert within their Activity? If they already know
>> enough to know it will fail, they'll know where and why.
>
>
Yep - an alert would work, or if there were a way for the activity to pass a
human readable launch failure message back to the launcher window we would
be all set.

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

[Sugar-devel] ~30 NEW XO-1.5 beta laptops now available "free" !

[Holt]

Can't be true?  MAD (Make A Difference) It is!  Twitter them Masses now
http://blog.laptop.org

Want to join the OLPC/Sugar volunteer team deciding who the luckiest, 
most talented 30 contributors will be?  Yes You Can :)
http://wiki.laptop.org/go/Support_Gang
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Activity version compatibility

[Gary C Martin]

Hi Wade,

On 28 Sep 2009, at 21:59, Wade Brainerd wrote:

On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin  
 wrote:


My main concern is, "how will most developers know what versions of  
Sugar
their activity will work under?" This is going to be an ever  
growing .info
string that will need constant maintenance once added. Will it be a  
white
list of sugar versions, a black list of sugar versions, a  
combination of

both, with omissions assuming it works, or fails?

So we end up with something like this in the .info that we may need  
to

update on every release:

  host_version = +0.82; -0.83; +0.84; +0.86



In the patch I posted, I assume that activities pick the oldest  
version of

Sugar they are compatible with.  For example, new Toolbar classes were
introduced in 0.86, so the latest Terminal will write:

host_version = 0.86.0

If you are a lazy activity developer, you simply write the version  
that you
tested the activity for.   There is no + or -, since we assume that  
Sugar
will not break old versions of activities with new releases.  This  
is not a
new concept; we have always had the monotonically incrementing  
host_version.

It's just never been incremented (or properly supported) before.


Hmmm. So what happens when Sugar depreciates some API and breaks old  
activities? Say in a year or so when the core folks decide to remove  
the old toolbar API code? Or perhaps some of Telepathy and its API  
which is getting rather overdue for a fix'er'upper effort?


I arrived here from a pragmatic place: I cloned Terminal from  
Gitorious and
realized it doesn't launch on my version of Sugar (SoaS  
Strawberry).  I
briefly looked into fixing it, but didn't see the immediate way to  
do that.

That left me with two options:

1) Do the work to maintain backwards compatibility


See this is where I'm at. I'm very tempted to go back and add the old  
toolbar support back into Write (I already did this for Calculate and  
it's not too painful, working on the same for Labyrinth just now). The  
core devs don't think this is worth the effort, because they want  
folks to move up to newer versions of Sugar (and get to use all the  
great new features they have worked on), but the Activity developers  
also want their activities to be a maximum benefit right now, which  
means supporting 0.82 for the ~98% of our user base right now.



2) Accept that users will experience crashes

I'd much rather have a third option, especially if we plan to make  
further

additions to the sugar toolkit along the lines of the new toolbars.
(Aleksey's sugar-ports library does go a long way towards making 1  
easier -

way to go!)

I'd much rather put the effort into fixing the launch pulsing  
window, so it
is not so stupid. It needs to recognise when a process failed to  
start, and,

at the very least, exit quickly back to the rest of the UI.



I have a prototype patch which fixes the launch window and adds an  
error

message.  I'll try to get it posted soon.


Cool :-)

[1] I cleaned up Walters TA bug icon for use in the new Log  
toolbar, but it

didn't make it in this time around
http://wiki.sugarlabs.org/go/File:Toolbar-bug.png


Awesome!  Mind if I use this in
http://wiki.sugarlabs.org/go/Features/Problem_Reports?


Sure go for it, here's the SVG:

<>


Sorry to be seeming to rain a little on the idea of release version

checking, but I'm not sure most developers will ever fill this out
correctly, and we're better of just being smarter about catching  
Activity
(start-up) tracebacks quickly. And happy to help in this area if  
folks think

this a good direction.


I agree that it's not likely that developers will fill it out  
consistently,
but at least they don't ever need to if they don't care about it.   
It's just
a way for activity developers like me who want to inform users that  
their

activities have a limit w.r.t. backwards compatibility.


If it's just for developers that want to specifically warn that their  
activity won't work. Why not let them just pop in a try/except around  
the sensitive API and show an alert within their Activity? If they  
already know enough to know it will fail, they'll know where and why.


Regards,
--Gary

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

Re: [Sugar-devel] [IAEP] Announcing the creation of a SoaS Decision Panel [organization process started]

[Luke Faraone]

On Mon, Sep 28, 2009 at 14:05, Sean McGrath  wrote:

> Bill Bogstad wrote:
>
>> We will conduct any  public discussions in the
>> s...@lists.sugarlabs.org mailing list with a subject line tagged with
>> [DP].
>
>
> Suggestion: As a favor to the mailing list archive searcher of the future,
> consider a tag [in addition to,instead of] "DP". The DP
> process may be repeated for different issues in the future.
>

Maybe [DP-1] or [SDP-1]?

-- 
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] Activity version compatibility

[Wade Brainerd]

On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin  wrote:

> My main concern is, "how will most developers know what versions of Sugar
> their activity will work under?" This is going to be an ever growing .info
> string that will need constant maintenance once added. Will it be a white
> list of sugar versions, a black list of sugar versions, a combination of
> both, with omissions assuming it works, or fails?
>
> So we end up with something like this in the .info that we may need to
> update on every release:
>
>host_version = +0.82; -0.83; +0.84; +0.86
>

In the patch I posted, I assume that activities pick the oldest version of
Sugar they are compatible with.  For example, new Toolbar classes were
introduced in 0.86, so the latest Terminal will write:

host_version = 0.86.0

If you are a lazy activity developer, you simply write the version that you
tested the activity for.   There is no + or -, since we assume that Sugar
will not break old versions of activities with new releases.  This is not a
new concept; we have always had the monotonically incrementing host_version.
 It's just never been incremented (or properly supported) before.

I arrived here from a pragmatic place: I cloned Terminal from Gitorious and
realized it doesn't launch on my version of Sugar (SoaS Strawberry).  I
briefly looked into fixing it, but didn't see the immediate way to do that.
 That left me with two options:

1) Do the work to maintain backwards compatibility
2) Accept that users will experience crashes

I'd much rather have a third option, especially if we plan to make further
additions to the sugar toolkit along the lines of the new toolbars.
 (Aleksey's sugar-ports library does go a long way towards making 1 easier -
way to go!)


> I'd much rather put the effort into fixing the launch pulsing window, so it
> is not so stupid. It needs to recognise when a process failed to start, and,
> at the very least, exit quickly back to the rest of the UI.
>

I have a prototype patch which fixes the launch window and adds an error
message.  I'll try to get it posted soon.


> [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it
> didn't make it in this time around
> http://wiki.sugarlabs.org/go/File:Toolbar-bug.png


Awesome!  Mind if I use this in
http://wiki.sugarlabs.org/go/Features/Problem_Reports?


> Sorry to be seeming to rain a little on the idea of release version
> checking, but I'm not sure most developers will ever fill this out
> correctly, and we're better of just being smarter about catching Activity
> (start-up) tracebacks quickly. And happy to help in this area if folks think
> this a good direction.
>

I agree that it's not likely that developers will fill it out consistently,
but at least they don't ever need to if they don't care about it.  It's just
a way for activity developers like me who want to inform users that their
activities have a limit w.r.t. backwards compatibility.

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

[Sugar-devel] Xoos Special Interest Group

[David Farning]

As promised, we have started work on the XO operating system SIG at
Sugar Labs.  The SIG pages are at http://wiki.sugarlabs.org/go/Xoos .

Based on feedback from the current developers working in this space,
the most valuable starting point will be to start making daily Xoos
builds.  The next step will be to work with others in this space to
create a release cycle which includes alphas, betas, and final
releases.  These releases will enable more users and testers to
participate in the development cycle.

Initially, communication will happen on the de...@lists.laptop.org,
sugar-...@lists.sugarlabs.org, and fedora-olpc-l...@redhat.com mailing
lists.

We have received initial support from the OLPC contributor program in
the form of developer machines.

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

Re: [Sugar-devel] Activity version compatibility

[Art Hunkins]

- Original Message - 
From: "Gary C Martin" 
To: "Wade Brainerd" 
Cc: "sugar-devel Devel" 
Sent: Monday, September 28, 2009 3:42 PM
Subject: Re: [Sugar-devel] [IAEP] Activity version compatibility


Hi Wade,

On 28 Sep 2009, at 13:26, Wade Brainerd wrote:

> Hey Bert,
>
> I wasn't aware of host_version - it looks like it's supported for
> content bundles, with any value other than 1 (hardcoded) raising a
> MalformedBundleException.  It's ignored for activity bundles.  So
> basically it was written into the spec and then dropped.
>
> I suppose we could resurrect host_version, or else add the new
> field.  I'm open to either avenue.  (Though I feel like just using
> the Sugar version as the value would be simpler than maintaining an
> independent version number)

My main concern is, "how will most developers know what versions of
Sugar their activity will work under?" This is going to be an ever
growing .info string that will need constant maintenance once added.
Will it be a white list of sugar versions, a black list of sugar
versions, a combination of both, with omissions assuming it works, or
fails?

So we end up with something like this in the .info that we may need to
update on every release:

host_version = +0.82; -0.83; +0.84; +0.86

If we only have this detection back ported for 0.84 and 0.86 I guess
the 0.82 is irrelevant even though that's what the majority of Sugar
users are currently using. I'd be likely to leave this line out and
accept any bug reports as feedback for 'please fix your activity to
work with this version of Sugar'.

I'd much rather put the effort into fixing the launch pulsing window,
so it is not so stupid. It needs to recognise when a process failed to
start, and, at the very least, exit quickly back to the rest of the UI.

It could (at a later date) be extended to do something smart with the
fail case; report the error to the user somehow – nice pretty error
graphic, the original mac bomb icon was a legend in its time, perhaps
a large bug icon [1] for 5 seconds ;-) – rather than just 'not
starting'; the UI could potentially lead folks to the crash log, or
just allow revealing the last traceback (if found) for manual
reporting (or debugging); the UI could potentially allow (only if
connected to the internet) the bug to be automatically posted back to
SL/developer for some automatic data mining to help decide which fail
cases folks hist most.

[1] I cleaned up Walters TA bug icon for use in the new Log toolbar,
but it didn't make it in this time around 
http://wiki.sugarlabs.org/go/File:Toolbar-bug.png

Sorry to be seeming to rain a little on the idea of release version
checking, but I'm not sure most developers will ever fill this out
correctly, and we're better of just being smarter about catching
Activity (start-up) tracebacks quickly. And happy to help in this area
if folks think this a good direction.



Yes. IMO, this is the right direction.

And yes, all developers should be strongly encouraged to make their 
activities work on as many versions of  Sugar as possible.

At the same time, it would behoove system developers to keep their 
improvements/enhancements when possible from "breaking" established code. 
(Activity developers have better things to do.)

Art Hunkins


Regards,
--Gary

> -Wade
>
> On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg  > wrote:
> (moving to devel list)
>
> I thought that's what host_version is for?
>
> - Bert -
>
>
> On 28.09.2009, at 02:40, Wade Brainerd wrote:
>
> Tentative patches posted to http://dev.sugarlabs.org/ticket/1442.
>
> An Alert when attempting to install the .xo bundle would be really
> nice, but this at least prevents the activity from appearing in the
> list.  It also adds the raw data, which could be displayed in the
> bundle's metadata.
>
> -Wade
>
> On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd 
> wrote:
> This might be a good time to introduce an optional
> "sugar_version=..." field into activity.info, so we can display a
> human readable error message when this mistake happens.  The
> activity will not launch unless Sugar's version is greater than or
> equal to the activity.info field.  Most activities will not need it,
> but in case of using non-backwards compatible APIs it will be handy.
>
> Is this too big a change to patch 0.84 and 0.86 with?  It will take
> at least two releases before it can have any real benefit.
>
> Regards,
> -Wade
>
> On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin
>  wrote:
> Hi Gerald,
>
> Many thanks for the feedback.
>
> On 27 Sep 2009, at 02:52, Gerald Ardito wrote:
>
> > Gary,
> >
> > This image came from Caroline Meeks at Solution Grove. It came as
> > part of a version of SOAS that she put together for me.
> >
> > Gerald
>
> OK, looks like a SoaS build mistake.
>
> Caroline, just a quick ping. Checking activities.sugarlabs.org, it
> tells me Write-63 was the last version compatible with Sugar 0.84.x. I
> believe Aleksey started working on the new 0.85.x toolbar code as of
> ve

Re: [Sugar-devel] [IAEP] Activity version compatibility

[Gary C Martin]

Hi Wade,

On 28 Sep 2009, at 13:26, Wade Brainerd wrote:

> Hey Bert,
>
> I wasn't aware of host_version - it looks like it's supported for  
> content bundles, with any value other than 1 (hardcoded) raising a  
> MalformedBundleException.  It's ignored for activity bundles.  So  
> basically it was written into the spec and then dropped.
>
> I suppose we could resurrect host_version, or else add the new  
> field.  I'm open to either avenue.  (Though I feel like just using  
> the Sugar version as the value would be simpler than maintaining an  
> independent version number)

My main concern is, "how will most developers know what versions of  
Sugar their activity will work under?" This is going to be an ever  
growing .info string that will need constant maintenance once added.  
Will it be a white list of sugar versions, a black list of sugar  
versions, a combination of both, with omissions assuming it works, or  
fails?

So we end up with something like this in the .info that we may need to  
update on every release:

host_version = +0.82; -0.83; +0.84; +0.86

If we only have this detection back ported for 0.84 and 0.86 I guess  
the 0.82 is irrelevant even though that's what the majority of Sugar  
users are currently using. I'd be likely to leave this line out and  
accept any bug reports as feedback for 'please fix your activity to  
work with this version of Sugar'.

I'd much rather put the effort into fixing the launch pulsing window,  
so it is not so stupid. It needs to recognise when a process failed to  
start, and, at the very least, exit quickly back to the rest of the UI.

It could (at a later date) be extended to do something smart with the  
fail case; report the error to the user somehow – nice pretty error  
graphic, the original mac bomb icon was a legend in its time, perhaps  
a large bug icon [1] for 5 seconds ;-) – rather than just 'not  
starting'; the UI could potentially lead folks to the crash log, or  
just allow revealing the last traceback (if found) for manual  
reporting (or debugging); the UI could potentially allow (only if  
connected to the internet) the bug to be automatically posted back to  
SL/developer for some automatic data mining to help decide which fail  
cases folks hist most.

[1] I cleaned up Walters TA bug icon for use in the new Log toolbar,  
but it didn't make it in this time around 
http://wiki.sugarlabs.org/go/File:Toolbar-bug.png

Sorry to be seeming to rain a little on the idea of release version  
checking, but I'm not sure most developers will ever fill this out  
correctly, and we're better of just being smarter about catching  
Activity (start-up) tracebacks quickly. And happy to help in this area  
if folks think this a good direction.

Regards,
--Gary

> -Wade
>
> On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg  > wrote:
> (moving to devel list)
>
> I thought that's what host_version is for?
>
> - Bert -
>
>
> On 28.09.2009, at 02:40, Wade Brainerd wrote:
>
> Tentative patches posted to http://dev.sugarlabs.org/ticket/1442.
>
> An Alert when attempting to install the .xo bundle would be really  
> nice, but this at least prevents the activity from appearing in the  
> list.  It also adds the raw data, which could be displayed in the  
> bundle's metadata.
>
> -Wade
>
> On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd   
> wrote:
> This might be a good time to introduce an optional  
> "sugar_version=..." field into activity.info, so we can display a  
> human readable error message when this mistake happens.  The  
> activity will not launch unless Sugar's version is greater than or  
> equal to the activity.info field.  Most activities will not need it,  
> but in case of using non-backwards compatible APIs it will be handy.
>
> Is this too big a change to patch 0.84 and 0.86 with?  It will take  
> at least two releases before it can have any real benefit.
>
> Regards,
> -Wade
>
> On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin  
>  wrote:
> Hi Gerald,
>
> Many thanks for the feedback.
>
> On 27 Sep 2009, at 02:52, Gerald Ardito wrote:
>
> > Gary,
> >
> > This image came from Caroline Meeks at Solution Grove. It came as
> > part of a version of SOAS that she put together for me.
> >
> > Gerald
>
> OK, looks like a SoaS build mistake.
>
> Caroline, just a quick ping. Checking activities.sugarlabs.org, it
> tells me Write-63 was the last version compatible with Sugar 0.84.x. I
> believe Aleksey started working on the new 0.85.x toolbar code as of
> version 64, breaking compatibility with earlier versions of Sugar:
>
>  http://activities.sugarlabs.org/en-US/sugar/addons/versions/4201
>
> Regards,
> --Gary
>
> ___
> 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:

Re: [Sugar-devel] Announcing the creation of a SoaS Decision Panel [organization process started]

[Bill Bogstad]

On Mon, Sep 28, 2009 at 12:48 PM, Chris Ball  wrote:
> Hi all,
>
> In Friday's SLOBs meeting, we approved the creation of a decision
> panel, with the following people eligible to join the panel:

Can I take it that SLOB is not formally requesting a two week deadline
to report back as was suggested on the wiki minutes?

Thanks,
Bill Bogstad

P.S.  We have already started organizing ourselves based on the
minutes.  We will conduct any  public discussions in the
s...@lists.sugarlabs.org mailing list with a subject line tagged with
[DP].  Individuals not on the panel who want to follow those
discussions should subscribe to that list.  We may make
announcements/request for input to other lists, but will not conduct
discussions in them or in all likelihood consider comments that are
only sent to those lists.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Announcing the creation of a SoaS Decision Panel

[Chris Ball]

Hi all,

In Friday's SLOBs meeting, we approved the creation of a decision
panel, with the following people eligible to join the panel:

Sebastian Dziallas
Luke Faraone
Martin Dengler
Bill Bogstad
Faisal Khan
Benjamin M. Schwartz
Samuel Klein
Sean Daly
Tabitha Roder
Caryl Bigenho
Daniel Drake
Abhishek Indoria

(If anyone else had volunteered but is missing from the list, the
group is welcome to add them in too.)

The approved scope for the Decision Panel is large.  We decided to
describe it as:

"""
Investigate the situation of how SoaS should be treated by Sugar
Labs, and related questions, including answers to the following:

*  Should Sugar Labs be a GNU/Linux distributor, rather than just
   an upstream producing Sugar releases?

*  Should SL be neutral about distributions containing Sugar, and
   refuse to endorse one over another?

*  Should 'Sugar on a Stick' be a phrase that SL asks its community
   to avoid using unless they refer to the SoaS-Fedora distribution?"

*  Any other question the Decision Panel deems required to provide an
   answer to the original question: "Is the current SoaS going to be
   the primary way Sugar Labs distributes a Sugar-centric GNU/Linux
   distribution?" 
"""

How the panel proceeds to organize themselves and answer these
questions is entirely up to them.  Once a report is ready, SLOBs
will review it and vote on ratifying its suggestions.

Thanks,

- Chris, for SLOBs.
-- 
Chris Ball   
One Laptop Per Child
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] A Virtual Box solution that works with Sticks

[Bill Bogstad]

On Mon, Sep 28, 2009 at 10:45 AM, Caroline Meeks
 wrote:
> Hi,
> I'm trying to understand this.
> Is it possible to use the booting method Bill found, where we boot one
> kernal in Virtual Box, then that Linux mounts the USB and then it boots the
> Sugar kernal on the stick?

I'm not even proposing that. :-)   I would have to think about it a
while to see if there were even any advantages.

I think the fundamental problem here is that the people who are
commenting (including myself) have never seen
the actual problem occur.   The hardware/software resources available
as well as the minimum functionality (use cases) are still
hazy to me as well.

Could you clarify what you want to accomplish and leave anything out
that isn't essential?   For example, does it have to be VirtualBox (or
even virtualization)?  If something isn't required don't mention it
except in the list of resource you know you have available to solve
your problem.

Thanks,
Bill Bogstad

P.S. I'm cc'ing this note to s...@lists.sugarlabs.org as it clearly is
about SoaS Strawberry and has literally nothing to
do with Sugar development.   It's a more generic 'my machine won't
boot Linux' problem.  Where the Linux in question is SoaS Strawberry.
 I'm leaving sugar-devel on the cc line for now, but will probably
drop it if this thread continues and certainly will for any future
threads on similar topics.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] A Virtual Box solution that works with Sticks

[Caroline Meeks]

Hi,
I'm trying to understand this.

Is it possible to use the booting method Bill found, where we boot one
kernal in Virtual Box, then that Linux mounts the USB and then it boots the
Sugar kernal on the stick?


On Wed, Sep 23, 2009 at 10:19 PM, Gary C Martin wrote:

> Hi Dave,
>
> On 24 Sep 2009, at 01:55, Dave Bauer wrote:
>
> > Last I checked virtualbox could not boot from USB on a Mac. This may
> > have changed in a more recent version.
>
> Yep correct, that is still the case**. But, we were not talking about
> booting USB. Just mounting it and using the data-store from there,
> tweaking a VM for deployment 'should' be small change. This of course
> runs into all the 'what version of Sugar is installed in the VM' vs.
> 'what version of data-store is installed on the stick' but for a small
> deployment with control over both, and with specific HW needs, I don't
> see this as an issue.
>
> Additionally, if some data-store validation checks could be put in
> place I could even see this being a very positive feature for Soas and/
> or upstream Sugar; an ideal little solvable issue for the two to
> resolve in a way that would benefit any deployments with old or not
> currently compatible hardware (where either the OS or a VM has to be
> run from the physical machine).
>
> ** unless you put the whole damn vdi on the stick and forgo the idea
> of booting the stick independently as a normal OS, though there could
> be room to investigate booting of a small partition with a reliable
> host OS that did nothing but dive right into the VM for those cases.
> Seems doable, but scary. Would much rather spend effort in finding a
> way to boot a USB directly – likely requires providing a Mac only
> image, though they can quite happily boot from USB, they just require
> correct boot formats (EFI for Intel Macs) but current Linux's seems
> well behind that curve. Most other HW manufacturers are still on old
> BIOS set-ups, Macs can support this for booting, Boot Camp does just
> this, but not for booting from USB devices unfortunately.
>
> Regards,
> --Gary
>
> > Dave
> >
> >
> > On Wed, Sep 23, 2009 at 8:12 PM, Gary C Martin
> >  wrote:
> > Hi Bill,
> >
> > On 24 Sep 2009, at 00:17, Bill Bogstad wrote:
> >
> > > On Wed, Sep 23, 2009 at 4:26 PM, Gary C Martin
> > >  wrote:
> > >
> > >> Sure, you could just link the ~/default/datastore directory on
> > the VM
> > >> to the matching location on the stick. I'm not sure how the pretty
> > >> way
> > >> to do this would be (likely at this moment in time would be just
> > >> tweaking the VMs to assume the stick was there). Pop stick in, then
> > >> run the VM would be the workflow once set-up. From a future stand
> > >> point, you'd likely want to push upstream for a feature where Sugar
> > >> checked for valid (and correct version) data-stores on start-up
> > >> (perhaps with a UI if more than one valid data-store was found), so
> > >> any external media device, or perhaps even mounted network volume
> > >> could become the default data-store for that session.
> > >
> > > Could you clarify what you are suggesting?   Most VMs (including
> > > VirtualBox) typically use large files within the host  environment
> > to
> > > provide the contents of virtual disks to the OS running under
> > > virtualization. By default VirtualBox uses a format that dynamically
> > > allocates in the real filesystem as the guest OS actually writes to
> > > the virtual disk.   I don't think this file is going to be directly
> > > compatible with any file (or filesystem image) that SoaS is
> > storing on
> > > a USB stick.  If you were thinking of something else, please let me
> > > know.
> >
> > Yes, I routinely use the "Shared Folders" feature for VirtualBox on
> > the Mac :-) Every thing Sugar flavour I work on resides there for easy
> > access between different VMs. VirtualBox treats this as a device
> > (after installing guest additions) so after a reboot I run:
> >
> >sudo mount -o uid=500 -t vboxsf 
> > 
> >
> > ...which should should do the trick.
> >
> > Also be aware that you need to tell VirtualBox it's allowed to use
> > USB, I think it defaults to allow, but you can also filter for named
> > devices if that makes more sense in a deployment. I would also want to
> > sanity check the shut down process to make sure we didn't bork users
> > sticks at the end of a session.
> >
> > Ping if you'd like to work this through, should be easy enough for me
> > to set up a test cycle here if you think this is valuable.
> >
> > Regards,
> > --Gary
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> >
> > --
> > Dave Bauer
> > d...@solutiongrove.com
> > http://www.solutiongrove.com
> >
> >
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iae

Re: [Sugar-devel] [IAEP] Activity version compatibility

[Bill Bogstad]

On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg  wrote:
> (moving to devel list)
>
> I thought that's what host_version is for?

I asked that exact question seven days ago:

http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019643.html

I'm copying the relevant part of that message below.  My suggested
design appears to be similar to Wade's with two major differences:

1. I suggested hijacking host_version instead of creating a new field.
2. I suggested adding an API so that an activity could query the
actual version and adapt itself to the underlying functionality.

Bill Bogstad

Here's the excerpt:

The lack of good dependency reporting and version tracking for
Activities makes this difficult.   Something like XO bundles could
work better for  for some scenarios though.

For example, has anyone ever done anything with the 'host_version'
field in the Activities *.info file?  Maybe it could be hijacked for
Sugar library dependencies. Not as remotely capable as full dependency
checking, but core Sugar (glucose) could at least use this for direct
Activity dependency issues.  Preferentially with a pop-up telling
people there may be incompatibilities.  Activities that stick with
direct Sugar supplied functionality would be safe.  Glucose would know
what range of values it supports and would alert if an Activity is
outside of that range.  Activities would request the minimum value
that works for them in their info file. Perhaps Activities could also
query for the maximum value supported and change their behavior based
on it.  (This assumes that Glucose functionality is monotonically
increasing and the cost of retaining compatibility with older versions
of the Glucose API is reasonable for at least a few releases.)

I

>
> - Bert -
>
> On 28.09.2009, at 02:40, Wade Brainerd wrote:
>
>> Tentative patches posted to http://dev.sugarlabs.org/ticket/1442.
>>
>> An Alert when attempting to install the .xo bundle would be really
>> nice, but this at least prevents the activity from appearing in the
>> list.  It also adds the raw data, which could be displayed in the
>> bundle's metadata.
>>
>> -Wade
>>
>> On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd 
>> wrote:
>> This might be a good time to introduce an optional
>> "sugar_version=..." field into activity.info, so we can display a
>> human readable error message when this mistake happens.  The
>> activity will not launch unless Sugar's version is greater than or
>> equal to the activity.info field.  Most activities will not need it,
>> but in case of using non-backwards compatible APIs it will be handy.
>>
>> Is this too big a change to patch 0.84 and 0.86 with?  It will take
>> at least two releases before it can have any real benefit.
>>
>> Regards,
>> -Wade
>>
>> On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin
>>  wrote:
>> Hi Gerald,
>>
>> Many thanks for the feedback.
>>
>> On 27 Sep 2009, at 02:52, Gerald Ardito wrote:
>>
>> > Gary,
>> >
>> > This image came from Caroline Meeks at Solution Grove. It came as
>> > part of a version of SOAS that she put together for me.
>> >
>> > Gerald
>>
>> OK, looks like a SoaS build mistake.
>>
>> Caroline, just a quick ping. Checking activities.sugarlabs.org, it
>> tells me Write-63 was the last version compatible with Sugar 0.84.x. I
>> believe Aleksey started working on the new 0.85.x toolbar code as of
>> version 64, breaking compatibility with earlier versions of Sugar:
>>
>>        http://activities.sugarlabs.org/en-US/sugar/addons/versions/
>> 4201
>>
>> Regards,
>> --Gary
>>
>> ___
>> 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-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] Ubuntu compatibility test stick

[Caroline Meeks]

ok lets try to get Skype working tonight.
thanks

On Mon, Sep 28, 2009 at 8:38 AM, Sean DALY  wrote:

> Yes, if the task is simple and clear enough, motivated teachers and
> parents will try to do that I think.
>
> And even slightly geeky people will be able to do it no problem...
>
> Sean
>
>
> On Mon, Sep 28, 2009 at 2:20 PM, Sascha Silbe
>  wrote:
> > [Dropped out soas@ because I don't think I can post there]
> >
> > On Mon, Sep 28, 2009 at 01:57:49PM +0200, Sean DALY wrote:
> >
> >> And of course, with no network, no phoning
> >
> > That's an advantage of Canonical using a USB stick to do it: You can just
> > store it on the stick and retrieve all logs after the show. For
> > "decentralized" testing an upload form explaining how to locate the USB
> > stick (mount point / drive letter) and the file on it (file name) might
> do
> > the trick.
> >
> > CU Sascha
> >
> > --
> > http://sascha.silbe.org/
> > http://www.infra-silbe.de/
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iQEcBAEBAgAGBQJKwKogAAoJELpz82VMF3Darn8IALAPhqdTLPOsx9ELMLuSNzdD
> > VltIKoydIeKkmjQPca7yLbH7EnmKsS1yX4m2QRP3rCFTwcQ8bi3Opmb0e4ncr1rg
> > Rt52ByGsZ7f4BfXhqV3bV3TMHa3SmGuUIKiBBXIWp9d96FrGcyjj6qr9CV8lh4TM
> > h1rhhalrg/4PKpp/wIcTsN3NhFCRz0Sn5pHujgYcVdigjz+L7WGNs0DRZHo1+d3z
> > /zM20ic4cTRVxu+sti03oHMBBeNodvBjiuvJQtJKblUH6zxQ8tShAgTaQk6BCxUi
> > cxWV1NYrfHoaaEE+06pa6QJCy07vMSn6kQety6UBp8g+xnXrdKQVkrRRGaMWzF4=
> > =KlSO
> > -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
>



-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Error running socialcalc on sugar live cd

[vijit singh]

Tomeu,

I am not having access to the live cd today as I am not having a good net
connection here. I would let you know about it 2morrow as soon as I will get
the live cd.

Regards,
VIJIT aka sumit

On Mon, Sep 28, 2009 at 4:17 PM, Tomeu Vizoso  wrote:

> On Sun, Sep 27, 2009 at 23:47, vijit singh 
> wrote:
> > Hello all,
> > Some of my co-developers are facing some issues running socialcalc on
> sugar
> > live cd. A ZipExtractException is being reported in the log. I am
> attaching
> > a photo log with this mail. Kindly give your suggestions about what could
> be
> > the possible reasons. Also, has anybody faced any such problem while
> running
> > any activity on the sugar live cd.
> > I would also be checking it myself on the sugar live cd today, am
> > downloading the live cd iso file with my poor net connection currently.
>
> Hi,
>
> can you check you can write to /home/olpc/Activities?
>
> Regards,
>
> Tomeu
>
> --
> «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] Ubuntu compatibility test stick

[Sean DALY]

Yes, if the task is simple and clear enough, motivated teachers and
parents will try to do that I think.

And even slightly geeky people will be able to do it no problem...

Sean


On Mon, Sep 28, 2009 at 2:20 PM, Sascha Silbe
 wrote:
> [Dropped out soas@ because I don't think I can post there]
>
> On Mon, Sep 28, 2009 at 01:57:49PM +0200, Sean DALY wrote:
>
>> And of course, with no network, no phoning
>
> That's an advantage of Canonical using a USB stick to do it: You can just
> store it on the stick and retrieve all logs after the show. For
> "decentralized" testing an upload form explaining how to locate the USB
> stick (mount point / drive letter) and the file on it (file name) might do
> the trick.
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJKwKogAAoJELpz82VMF3Darn8IALAPhqdTLPOsx9ELMLuSNzdD
> VltIKoydIeKkmjQPca7yLbH7EnmKsS1yX4m2QRP3rCFTwcQ8bi3Opmb0e4ncr1rg
> Rt52ByGsZ7f4BfXhqV3bV3TMHa3SmGuUIKiBBXIWp9d96FrGcyjj6qr9CV8lh4TM
> h1rhhalrg/4PKpp/wIcTsN3NhFCRz0Sn5pHujgYcVdigjz+L7WGNs0DRZHo1+d3z
> /zM20ic4cTRVxu+sti03oHMBBeNodvBjiuvJQtJKblUH6zxQ8tShAgTaQk6BCxUi
> cxWV1NYrfHoaaEE+06pa6QJCy07vMSn6kQety6UBp8g+xnXrdKQVkrRRGaMWzF4=
> =KlSO
> -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] Activity version compatibility

[Wade Brainerd]

Hey Bert,
I wasn't aware of host_version - it looks like it's supported for content
bundles, with any value other than 1 (hardcoded) raising a
MalformedBundleException.  It's ignored for activity bundles.  So basically
it was written into the spec and then dropped.

I suppose we could resurrect host_version, or else add the new field.  I'm
open to either avenue.  (Though I feel like just using the Sugar version as
the value would be simpler than maintaining an independent version number)

-Wade

On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg wrote:

> (moving to devel list)
>
> I thought that's what host_version is for?
>
> - Bert -
>
>
> On 28.09.2009, at 02:40, Wade Brainerd wrote:
>
>  Tentative patches posted to http://dev.sugarlabs.org/ticket/1442.
>>
>> An Alert when attempting to install the .xo bundle would be really nice,
>> but this at least prevents the activity from appearing in the list.  It also
>> adds the raw data, which could be displayed in the bundle's metadata.
>>
>> -Wade
>>
>> On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd  wrote:
>> This might be a good time to introduce an optional "sugar_version=..."
>> field into activity.info, so we can display a human readable error
>> message when this mistake happens.  The activity will not launch unless
>> Sugar's version is greater than or equal to the activity.info field.
>>  Most activities will not need it, but in case of using non-backwards
>> compatible APIs it will be handy.
>>
>> Is this too big a change to patch 0.84 and 0.86 with?  It will take at
>> least two releases before it can have any real benefit.
>>
>> Regards,
>> -Wade
>>
>> On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin 
>> wrote:
>> Hi Gerald,
>>
>> Many thanks for the feedback.
>>
>> On 27 Sep 2009, at 02:52, Gerald Ardito wrote:
>>
>> > Gary,
>> >
>> > This image came from Caroline Meeks at Solution Grove. It came as
>> > part of a version of SOAS that she put together for me.
>> >
>> > Gerald
>>
>> OK, looks like a SoaS build mistake.
>>
>> Caroline, just a quick ping. Checking activities.sugarlabs.org, it
>> tells me Write-63 was the last version compatible with Sugar 0.84.x. I
>> believe Aleksey started working on the new 0.85.x toolbar code as of
>> version 64, breaking compatibility with earlier versions of Sugar:
>>
>>   http://activities.sugarlabs.org/en-US/sugar/addons/versions/4201
>>
>> Regards,
>> --Gary
>>
>> ___
>> 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-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ubuntu compatibility test stick

[Sascha Silbe]

[Dropped out soas@ because I don't think I can post there]

On Mon, Sep 28, 2009 at 01:57:49PM +0200, Sean DALY wrote:


And of course, with no network, no phoning
That's an advantage of Canonical using a USB stick to do it: You can 
just store it on the stick and retrieve all logs after the show. For 
"decentralized" testing an upload form explaining how to locate the USB 
stick (mount point / drive letter) and the file on it (file name) might 
do the trick.


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] Ubuntu compatibility test stick

[Sean DALY]

Bulletproof boot will assure the success of Sugar on a Stick beyond
geeks and even geeky teachers. The installation barrier is what holds
back widespread GNU/Linux installs over another OS; SoaS overcomes
that.

We don't have a hardware compatibility matrix yet, but we should, and
ideally the data could come from Sugar boot attempt logs. I have half
a dozen netbooks I will video booting and tag them "Sugar boots!" but
a boot time generated log would be even better.

I wondered about this in February
(http://lists.sugarlabs.org/archive/sugar-devel/2009-February/011804.html)
but visibly, a major part of the problem is running down who could
things that could go wrong - distro side, networking configuration,
Activities.

It may well be that technical problem X implies filing a "bug ticket",
but teachers won't bother doing that if they are evaluating SoaS.
They'll just shrug and think it's not ready. if they check back a few
months later and still can't get it to work, they'll just mention to
their colleagues how unreliable it is.

An automatically generated log of what works/doesn't which phones home
to us would yield precious data about what's going wrong. I understand
this would be quite difficult to code though. And of course, with no
network, no phoning - although an access through the Sugar Control
Panel could at least make copy/paste into a mail to
feedb...@sugarlabs.org possible.

Sean


On Mon, Sep 28, 2009 at 12:48 PM, Sascha Silbe
 wrote:
> Hi!
>
> Just seen mentioned in the Ubuntu Weekly News: Ubuntu had a test stick at
> the Atlanta Linux Fest that tried out the usual problematic features (WiFi,
> sound, etc.) with the user answering whether it worked or not [1]. So the
> user could determine whether Ubuntu should work properly. All test results
> were collected by Canonical.
> Something like this for SoaS would be really great.
>
>
> [1] http://www.workswithu.com/2009/09/23/will-ubuntu-910-work-on-your-pc/
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJKwJSKAAoJELpz82VMF3DaSgkH/1d6AxtFtkr/U7JjfbZaHJK+
> bbyMAtIm/Ax+5MQlwLW1/LJ8KW84P2KVJs/c5FgLaR5NsZ3gHWUxi+rbcnvW4Nvc
> XVL8oepeKikiZ1khDTh7JkpF4ojUVhv9be9Jah9W4J0hJimCU5Pk8deTMYbi4+xq
> vXViTtPjSrPRBBpMX8i370Y3TWwll8xMEXoZJCyogKPYIgQiDHYqrWQ85E8pU9x2
> gZtIF41xJf6D8kJReoma9DTUoItelIgWi9bunWptIp5fxbG+EGm8uOVfa/m3SClL
> z8EGcBd54MT68pfLkduVu1gDPg6UR2H7A0umJ5REn7IFNSD1d6eTFfE3GHgzvLs=
> =eq3w
> -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] how to pick older version of an activity for a custom sugar spin

[Hamilton Chua]

Hi Aleksey,

Thanks for pointing this out. This change eluded me as I am still using
the code tagged "strawberry" but this looks easy enough to backport and
include into the kickstart files I am using.

Thanks !

Hamilton

> 
> For now, SugarPlatform version is hardcoded in .ks, see
> http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-aslo-and-content.ks#line61
> so, you just need to change it to 0.84
> 

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

Re: [Sugar-devel] [IAEP] Activity version compatibility

[Bert Freudenberg]

(moving to devel list)

I thought that's what host_version is for?

- Bert -

On 28.09.2009, at 02:40, Wade Brainerd wrote:

> Tentative patches posted to http://dev.sugarlabs.org/ticket/1442.
>
> An Alert when attempting to install the .xo bundle would be really  
> nice, but this at least prevents the activity from appearing in the  
> list.  It also adds the raw data, which could be displayed in the  
> bundle's metadata.
>
> -Wade
>
> On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd   
> wrote:
> This might be a good time to introduce an optional  
> "sugar_version=..." field into activity.info, so we can display a  
> human readable error message when this mistake happens.  The  
> activity will not launch unless Sugar's version is greater than or  
> equal to the activity.info field.  Most activities will not need it,  
> but in case of using non-backwards compatible APIs it will be handy.
>
> Is this too big a change to patch 0.84 and 0.86 with?  It will take  
> at least two releases before it can have any real benefit.
>
> Regards,
> -Wade
>
> On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin  
>  wrote:
> Hi Gerald,
>
> Many thanks for the feedback.
>
> On 27 Sep 2009, at 02:52, Gerald Ardito wrote:
>
> > Gary,
> >
> > This image came from Caroline Meeks at Solution Grove. It came as
> > part of a version of SOAS that she put together for me.
> >
> > Gerald
>
> OK, looks like a SoaS build mistake.
>
> Caroline, just a quick ping. Checking activities.sugarlabs.org, it
> tells me Write-63 was the last version compatible with Sugar 0.84.x. I
> believe Aleksey started working on the new 0.85.x toolbar code as of
> version 64, breaking compatibility with earlier versions of Sugar:
>
>http://activities.sugarlabs.org/en-US/sugar/addons/versions/ 
> 4201
>
> Regards,
> --Gary
>
> ___
> 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-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] how to pick older version of an activity for a custom sugar spin

[Aleksey Lim]

On Mon, Sep 28, 2009 at 06:17:59PM +0800, Hamilton Chua wrote:
> Hello,
> 
> I am creating custom spins from strawberry branch with sugar 0.84 and I
> have modified the kickstart file (soas-sugar.ks) to get the latest
> versions of the activites from activities.sugarlabs.org.
> 
> The problem is that some of the latest activities are no longer
> compatible with 0.84 and now work with 0.86.
> 
> Is there a way for me to tell the kickstart file to get to 0.84
> compatible version of the activity instead of the latest version of the
> activity?

For now, SugarPlatform version is hardcoded in .ks, see
http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-aslo-and-content.ks#line61
so, you just need to change it to 0.84

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

[Sugar-devel] Ubuntu compatibility test stick

[Sascha Silbe]

Hi!

Just seen mentioned in the Ubuntu Weekly News: Ubuntu had a test stick 
at the Atlanta Linux Fest that tried out the usual problematic features 
(WiFi, sound, etc.) with the user answering whether it worked or not 
[1]. So the user could determine whether Ubuntu should work properly. 
All test results were collected by Canonical.

Something like this for SoaS would be really great.


[1] 
http://www.workswithu.com/2009/09/23/will-ubuntu-910-work-on-your-pc/


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] Error running socialcalc on sugar live cd

[Tomeu Vizoso]

On Sun, Sep 27, 2009 at 23:47, vijit singh  wrote:
> Hello all,
> Some of my co-developers are facing some issues running socialcalc on sugar
> live cd. A ZipExtractException is being reported in the log. I am attaching
> a photo log with this mail. Kindly give your suggestions about what could be
> the possible reasons. Also, has anybody faced any such problem while running
> any activity on the sugar live cd.
> I would also be checking it myself on the sugar live cd today, am
> downloading the live cd iso file with my poor net connection currently.

Hi,

can you check you can write to /home/olpc/Activities?

Regards,

Tomeu

-- 
«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] how to pick older version of an activity for a custom sugar spin

[Hamilton Chua]

Hello,

I am creating custom spins from strawberry branch with sugar 0.84 and I
have modified the kickstart file (soas-sugar.ks) to get the latest
versions of the activites from activities.sugarlabs.org.

The problem is that some of the latest activities are no longer
compatible with 0.84 and now work with 0.86.

Is there a way for me to tell the kickstart file to get to 0.84
compatible version of the activity instead of the latest version of the
activity?

Thanks in advance for any help.

Best,

Hamilton


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