Re: OLPC vs Fedora packages

[Peter Robinson]

> Just thought I'd post my understanding of where the packages are at
> based on the list that was created at FUDCon
>
> For reference see https://fedoraproject.org/wiki/OLPC/Packages_for_F11
>
> Also there's the OLPCDelta tracking bug in RHBZ 462625 for quick
> tracking of the ones I'm aware of.
>
> KOJI packages
>
> GConf-dbus - Should be able to untag. I think its also used to reduce
> the deps on bonobo etc.
>
> SDL_mixer - see RHBZ 471623 - Need someone to update if my thoughts are 
> correct.
>
> abiword - mostly forked to reduce dependencies on things like
> printing. Probably will be unnecessary with the next major release as
> most of the old deps on libgnome libgnomeprint etc should disappear
>
> hippo-canvas - From my testing bigboard and mugshot compile OK but I
> can't really test so it should be mergeable.
>
> hulahop - OLPC-4 branch merged (and removed) just waiting for the push
> to mainline. Push to testing just happened today. So can essentially
> be removed from this list.
>
> initscripts - I seem to remember the main reason was due to rainbow
> using process number 1 and hence initscripts running as process number
> 2. JKatz is the one in the know here.
>
>  olpc-utils - due to olpcupdate not being in Fedora and its dependant on it.
>
> sugar-evince - Probably need to get evince split into evince-libs and
> evince so that sugar-evince can build against evince-libs. Not sure if
> there's plans to get sugar-evince upstreamed for easy maintenance
>
> telepathy* - no idea but its documented well by others :-)
>
> totem-* - dependency reduction - I think these can probably mostly go
> away with the plans to introduce the ability for multiple desktops to
> run (sugar and something else) as e-d-s will probably be there anyway
>
> upstart - I believe its the same as for initscripts (rainbow). This I
> think is another one for JKatz. I also think there was discussion on
> fedora-olpc back in Sept/Oct timeframe.
>
> JOYRIDE packages
>
> libertas-usb8388-firmware - is in Fedora-10 and rawhide already. I
> thought I'd unlinked the non mainline version as we were shipping the
> same package in F-10 as we are for 9.1.0 and rawhide has the latest
> (or near latest) version.
>
>
> I'll also link the RHBZ bugs if there is one near each of the
> mentioned packages in the wiki.

To reply to myself

The other things that also come to mind but aren't listed that I think
also need fixing are (or at least I'm not sure the state of them):
- xulrunner and the OLPC patches (currently using mainline Fedora
package) - Mario & Simon
- NetworkManager - Not sure what the state of the mesh patches (or
maybe its some other patches) is.
- numeric vs numpy (I think this is the pygtk issue).

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

OLPC vs Fedora packages

[Peter Robinson]

Just thought I'd post my understanding of where the packages are at
based on the list that was created at FUDCon

For reference see https://fedoraproject.org/wiki/OLPC/Packages_for_F11

Also there's the OLPCDelta tracking bug in RHBZ 462625 for quick
tracking of the ones I'm aware of.

KOJI packages

GConf-dbus - Should be able to untag. I think its also used to reduce
the deps on bonobo etc.

SDL_mixer - see RHBZ 471623 - Need someone to update if my thoughts are correct.

abiword - mostly forked to reduce dependencies on things like
printing. Probably will be unnecessary with the next major release as
most of the old deps on libgnome libgnomeprint etc should disappear

hippo-canvas - From my testing bigboard and mugshot compile OK but I
can't really test so it should be mergeable.

hulahop - OLPC-4 branch merged (and removed) just waiting for the push
to mainline. Push to testing just happened today. So can essentially
be removed from this list.

initscripts - I seem to remember the main reason was due to rainbow
using process number 1 and hence initscripts running as process number
2. JKatz is the one in the know here.

 olpc-utils - due to olpcupdate not being in Fedora and its dependant on it.

sugar-evince - Probably need to get evince split into evince-libs and
evince so that sugar-evince can build against evince-libs. Not sure if
there's plans to get sugar-evince upstreamed for easy maintenance

telepathy* - no idea but its documented well by others :-)

totem-* - dependency reduction - I think these can probably mostly go
away with the plans to introduce the ability for multiple desktops to
run (sugar and something else) as e-d-s will probably be there anyway

upstart - I believe its the same as for initscripts (rainbow). This I
think is another one for JKatz. I also think there was discussion on
fedora-olpc back in Sept/Oct timeframe.

JOYRIDE packages

libertas-usb8388-firmware - is in Fedora-10 and rawhide already. I
thought I'd unlinked the non mainline version as we were shipping the
same package in F-10 as we are for 9.1.0 and rawhide has the latest
(or near latest) version.


I'll also link the RHBZ bugs if there is one near each of the
mentioned packages in the wiki.

Cheers,
Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOCamp 2: Day 3 update

[Samuel Klein]

Hello,

We are currently talking about a string of technical topics : l10n,
journal, performance/memory, power, and jffs/ubi --- through the end
of the day.

After this there will be a brief talk about digitizing and creating
books from ed cherlin at 5.  The post below has the latest information
for joining in.

SJ

On Tue, Jan 13, 2009 at 11:31 AM, Samuel Klein  wrote:
> We've made a few schedule changes today, with talks about
> customization, signing, and activation moved to later in the
> afternoon, and a longer session on the school server through the
> morning.
>
> http://blog.laptop.org/2009/01/12/xo-camp-on-tv/
>
> Feel free to leave comments, questions and ideas on the schedule's
> talkpage if you can't join in person.
>
> SJ
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

After XS 0.6 - future-of-the-XS wishlist...

[Martin Langhoff]

Yesterday, as part of XOCamp, Caroline Meeks pressed me a bit to talk
about my vision of the XS going forward. It is a somewhat hazy space,
as it's unclear whether I'll be able to work fulltime on this after
XS-0.6.

Now, even when you feel really certain about your future plans, a bus
could roll you over. Or your convertible could leave the road and
crash on the rocks in the sea.

So what's the XS plan then?

With 0.5.1 much of the infrastructure work is done, including network
services. With 0.6 that work should be complete, even if it'll be
lacking some nice-to-haves. Pat-on-the-shoulder, job well done.

The next stage -- if *I* get a chance to get it done -- is all about
focus on server-based education tools. First stop, Moodle. Right now
there is a barely usable moodle that auto-installs. I've written 2
plans for it -- one focused on the technical and more "mechanical"
issues, parts of it are already done, but many remain to do:

   http://wiki.laptop.org/go/XS_Moodle_plan

the second plan is more focused on making Moodle useful with primary
schoolers. Currently, moodle is great for text-centric interactions,
forums, wikis, reading content. But children 6 to 9 years are not text
centric yet. Surprisingly, it's not so hard to address that - along
with a host of other things to lower barriers of entry for classroom
use - see

http://wiki.laptop.org/go/XS_Moodle_design

It's probably about 8 months of work to get through all that.  So a
year out, my crystal ball gets hazy -- in the fog, I can make out the
outline of some further plans, such

 - merging edublog patches, make the moodle-based blog able to publish
to internet-based blogging sites - such as blogger.com

 - add a wikipedia-slice to the server - while the laptops do have a
"wikislice", the server can host a much thicker slice, and perhaps
have it editable too

 - complementary tools: Mahara, Mediawiki

 - of course, better tools to manage the deployment...

 - rebase on Fedora 11 or 12 (skip F10 as it's missing bits we need)

 - rebase Moodle work on Moodle 2.0 - which brings a nice API to deal
with repositories, unlocking a lot of content-repository options

 - replace squid with rproxy and hashcache

 - use btrfs as soon as usably stable, wrap yum/rpm actions in
"snapshot-try-or-rollback" scheme...

there you go. Now I can go back to living life dangerously without
feeling guilty :-)

Note note note note: this is pretty much *my* plan, my perception of
the most reasonable tradeoffs between the competing/conflicting
feature requests and the physical and resource constraints. Anyone
prepared to spend the 1% inspiration + 99% perspiration can refocus
this plan on areas that I might be ignoring... by getting it done.

In other words, the above is all hot air, and hot air doesn't count.
Working code does ;-)

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

[Server-devel] Towards XS 0.6

[Martin Langhoff]

Against all odds, the XS plans for 0.6 haven't changed much in this
last week. We have an opportunity to improve things a bit for the
upcoming deployments, which will be using 8.2.x --

It's a very limited timeframe, and a lot of things to do. There won't
be any time for frills or experimentation with bold new things. It is
time for hard focus on a short list of things that are enablers for
deployments, and for stability-focused bugfixing.

And that's just fine with me. In times like this, it would be
irresponsible to spend time on secondary stuff.

More than ever, I will need your help to get this done, specially
around early testing.

What's coming in the next 2~3 months for the XS is

 *  Scalability: ejabberd/presence partitioning via Moodle

 * Lease mgmt - activation, renewal, blacklist
  o XS: network proto layer, USB-based delivery handling, mgmt UI
  o XO: firmware, initrd, userland
  o Needs simple service announcement scheme

 * Browse.xo transparent sign on - working with Simon

 * DS-Backup -- Restore UI

 * Management scheme
  o Scripts automation
  o Update callback scheme

 * Easier transparent OS and activity upgrade -
  o service announcement scheme
  o small XO work

 * XS on XO - working with Jerry

 * Basic reporting scheme

 * Ability to switch off registration service -- local teams are
worried about bogus registrations

 * Tie internet access to registration  -- some local teams are
worried about locals "stealing" very limited internet bandwidth. We
could block internet access from un-registered machines or just
throttle them very aggressively. Naturally, needs a 'whitelist'
mechanism and UI to whitelist teacher's non-XO laptops.

 * 2~3 weeks of polish on Moodle for the XS to close the gaps so that
we can start taking advantage of upstream work

cheers,



martin
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
server-de...@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel

New joyride build 2626

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2626

Changes in build 2626 from build: 2625

Size delta: 0.00M

-file 4.26-3.fc10
+file 4.26-4.fc10
-file-libs 4.26-3.fc10
+file-libs 4.26-4.fc10
-hal 0.5.12-12.20081027git.fc10
+hal 0.5.12-14.20081027git.fc10
-hal-info 20081022-2.fc10
+hal-info 20081219-1.fc10
-hal-libs 0.5.12-12.20081027git.fc10
+hal-libs 0.5.12-14.20081027git.fc10
-jack-audio-connection-kit 0.109.2-3.fc10
+jack-audio-connection-kit 0.116.1-3.fc10

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XS 05

[Martin Langhoff]

On Wed, Jan 14, 2009 at 12:06 PM, Henry Vélez Molina
 wrote:
> We have been working on the server and we do the upgrade to version
> 05, but we have some difficulties.
>
> Olpc-scripts folder is not in the path / etc / sysconfig /.
>
> Ejabberd service does not exist. Ie "service ejabberd start" prints
> that the service do not exists.

That is *very* strange. Two suggestions

 - I think that when the install starts it offers a menu (very early,
when the installer is booting). That menu has clouds in the
background, and the pre-selected option is "installed with kickstart".
Maybe you changed the option to "install"? The correct option to use
is the one that mentions kickstart...

 - 0.5 has some problems that will drive you crazy - those are fixed
in 0.5.1 . Skip 0.5 and go for 0.5.1-dev3 which I'm planning to
'bless' today or tomorrow as the official 0.5.1 :-)

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activities migration status

[Ed McNierney]

Gabriel -

No, there are no current plans to shut down any services on  
dev.laptop.org.  OLPC has an 8.2.1 release underway and we'll continue  
to maintain those services in the future.

On the other hand, anyone working on Sugar efforts such as Activity  
development should be encouraged to put all those efforts under the  
Sugar Labs roof where they can be more readily available to the entire  
Sugar community (not just the OLPC portion of it).  The last paragraph  
of Wade's message (quoted below) described it very well.

- Ed


On Jan 14, 2009, at 12:33 PM, Gabriel Eirea wrote:

> Wade:
>
> I'm an activity developer with my code at dev.laptop.org. I'm a bit
> confused about this migration. Is it necessary to change the location
> for some reason? Is dev.laptop.org going to be killed?
>
> I believe the Activity Team is a wonderful idea but would like to have
> this point clarified.
>
> Thanks,
>
> Gabriel
>
>
> 2009/1/14 Wade Brainerd :
>> On Wed, Jan 14, 2009 at 6:05 AM, S Page  wrote:
>>> I'm not sure what you're doing, but if you want activities...
>>> When the call went out for activities for 9.1.0 I put all the meta- 
>>> lists of
>>> activities in
>>> >> >
>>>
>>> That links to some interesting queries in
>>> http://wiki.laptop.org/go/Activity_queries  :
>>> * 45 pages with a Devel status
>>> * 116 pages that appear to have an activity bundle
>>> * 310 pages in Category:Activities in the main namespace.
>>>
>>> and I'm sure there are more activities that lack a page on on
>>> wiki.laptop.org
>>
>> Thanks, this is a great source of information.
>>
>> What we are trying to do is track down all the activities that have
>> been written (or started) and then migrate them to SugarLabs
>> infrastructure, with permission from their authors.  At the same time
>> we will encourage their authors to finish them, update them to work
>> with recent builds, document them, make sure they can be packaged for
>> non-XO distros, etc.
>>
>> -Wade
>>
>> -Wade
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activities migration status

[Gabriel Eirea]

Wade:

I'm an activity developer with my code at dev.laptop.org. I'm a bit
confused about this migration. Is it necessary to change the location
for some reason? Is dev.laptop.org going to be killed?

I believe the Activity Team is a wonderful idea but would like to have
this point clarified.

Thanks,

Gabriel


2009/1/14 Wade Brainerd :
> On Wed, Jan 14, 2009 at 6:05 AM, S Page  wrote:
>> I'm not sure what you're doing, but if you want activities...
>> When the call went out for activities for 9.1.0 I put all the meta-lists of
>> activities in
>> 
>>
>> That links to some interesting queries in
>> http://wiki.laptop.org/go/Activity_queries  :
>> * 45 pages with a Devel status
>> * 116 pages that appear to have an activity bundle
>> * 310 pages in Category:Activities in the main namespace.
>>
>> and I'm sure there are more activities that lack a page on on
>> wiki.laptop.org
>
> Thanks, this is a great source of information.
>
> What we are trying to do is track down all the activities that have
> been written (or started) and then migrate them to SugarLabs
> infrastructure, with permission from their authors.  At the same time
> we will encourage their authors to finish them, update them to work
> with recent builds, document them, make sure they can be packaged for
> non-XO distros, etc.
>
> -Wade
>
> -Wade
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activities migration status

[Wade Brainerd]

On Wed, Jan 14, 2009 at 6:05 AM, S Page  wrote:
> I'm not sure what you're doing, but if you want activities...
> When the call went out for activities for 9.1.0 I put all the meta-lists of
> activities in
> 
>
> That links to some interesting queries in
> http://wiki.laptop.org/go/Activity_queries  :
> * 45 pages with a Devel status
> * 116 pages that appear to have an activity bundle
> * 310 pages in Category:Activities in the main namespace.
>
> and I'm sure there are more activities that lack a page on on
> wiki.laptop.org

Thanks, this is a great source of information.

What we are trying to do is track down all the activities that have
been written (or started) and then migrate them to SugarLabs
infrastructure, with permission from their authors.  At the same time
we will encourage their authors to finish them, update them to work
with recent builds, document them, make sure they can be packaged for
non-XO distros, etc.

-Wade

-Wade
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New joyride build 2625

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2625

Changes in build 2625 from build: 2624

Size delta: 0.13M

-etoys 4.0.2201-1
+etoys 4.0.2205-1

--- Changes for etoys 4.0.2205-1 from 4.0.2201-1 ---
  + offer full authoring-tools menu even to all users
  + make Anthy based Japanese input work
  + add About flap on start screen
  + enable screen scaling a bit more eagerly

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: status of forks

[Peter Robinson]

>>> 1. forks to use different compile/packaging options to eliminate
>>> dependancies
>>>
>>> 2. forks to change the code (adding functionality in particular)
>>>
>>> I'm not _that_ interested in #1, but am very interested in #2, especially
>>> anything done to make things work with the XO hardware.
>>
>> I don't think there are any other than the kernel that are forked for
>> hardware issues, and the stock Fedora i386 kernel will work with the
>> XO but the likes of numerous ethernet/storage drivers, ISA, MCA, Token
>> Ring and the like are of little use for the device :-) . There use to
>> be a HW issue in the shipped gstreamer that caused it be be forked but
>> I'm not aware of any other hardware issues in mainline kernel issues.
>
> Another reason for forks is Rainbow.
>
> telepathy-gabble and telepathy-salut both had OLPC-3 branches for
> 8.2.x and have OLPC-4 branches for 9.1.0 because Rainbow runs
> activities under different UIDs and they all need to connect to gabble
> and salut - so there are two patches for each of these to weaken the
> usual UID restrictions. This weakens dbus and socket permissions on a
> multiuser system, so the patches are only suitable for running under
> Rainbow and upstream Telepathy won't merge them into releases.
>
> Since these are build-time patches, I'm not sure how you would remove
> this fork - since regular F-10 and F-11 shouldn't have the patches,
> but Rainbow requires them.

I believe there are now patches floating around to enable this at
runtime. See the changelog for the Fedora package
http://cvs.fedoraproject.org/viewvc/rpms/telepathy-salut/devel/telepathy-salut.spec?view=markup

> Oh, and one more reason for forks/branches: F-10 shipped with Sugar
> 0.82.x, but [the release formerly planned as 9.1.0] would have Sugar
> 0.84.x (and has 0.83.x packages in OLPC-4 now for testing on Joyride).

Yes, but if/as development goes upstream there's no reason why you
couldn't use rawhide and go more towards a Fedora style release which
is close to the joyride/9.x release style anyway.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

XS 05

[Henry Vélez Molina]

Hello to all.

We have been working on the server and we do the upgrade to version
05, but we have some difficulties.

Olpc-scripts folder is not in the path / etc / sysconfig /.

Ejabberd service does not exist. Ie "service ejabberd start" prints
that the service do not exists.

What can be done in this case?

Greetings

-- 
Henry Vélez Molina
Administrador de red OLPC
Fundación MArina Orth
Tel :341 23 59
Móvil: 312 769 0169
www.fundacionmarinaorth.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: status of forks

[Bert Freudenberg]

On 14.01.2009, at 13:15, Morgan Collett wrote:

> On Sat, Jan 10, 2009 at 11:47, Peter Robinson   
> wrote:
>>> I see two classes of forks
>>>
>>> 1. forks to use different compile/packaging options to eliminate
>>> dependancies
>>>
>>> 2. forks to change the code (adding functionality in particular)
>>>
>>> I'm not _that_ interested in #1, but am very interested in #2,  
>>> especially
>>> anything done to make things work with the XO hardware.
>>
>> I don't think there are any other than the kernel that are forked for
>> hardware issues, and the stock Fedora i386 kernel will work with the
>> XO but the likes of numerous ethernet/storage drivers, ISA, MCA,  
>> Token
>> Ring and the like are of little use for the device :-) . There use to
>> be a HW issue in the shipped gstreamer that caused it be be forked  
>> but
>> I'm not aware of any other hardware issues in mainline kernel issues.
>
> Another reason for forks is Rainbow.
>
> telepathy-gabble and telepathy-salut both had OLPC-3 branches for
> 8.2.x and have OLPC-4 branches for 9.1.0 because Rainbow runs
> activities under different UIDs and they all need to connect to gabble
> and salut - so there are two patches for each of these to weaken the
> usual UID restrictions. This weakens dbus and socket permissions on a
> multiuser system, so the patches are only suitable for running under
> Rainbow and upstream Telepathy won't merge them into releases.
>
> Since these are build-time patches, I'm not sure how you would remove
> this fork - since regular F-10 and F-11 shouldn't have the patches,
> but Rainbow requires them.


Well, the typical way would be to add a runtime option. Like per  
config file, or an environment variable, passed into the  
initialization routine, etc. Why shouldn't that option be able to go  
upstream?

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: status of forks

[Morgan Collett]

On Sat, Jan 10, 2009 at 11:47, Peter Robinson  wrote:
>> I see two classes of forks
>>
>> 1. forks to use different compile/packaging options to eliminate
>> dependancies
>>
>> 2. forks to change the code (adding functionality in particular)
>>
>> I'm not _that_ interested in #1, but am very interested in #2, especially
>> anything done to make things work with the XO hardware.
>
> I don't think there are any other than the kernel that are forked for
> hardware issues, and the stock Fedora i386 kernel will work with the
> XO but the likes of numerous ethernet/storage drivers, ISA, MCA, Token
> Ring and the like are of little use for the device :-) . There use to
> be a HW issue in the shipped gstreamer that caused it be be forked but
> I'm not aware of any other hardware issues in mainline kernel issues.

Another reason for forks is Rainbow.

telepathy-gabble and telepathy-salut both had OLPC-3 branches for
8.2.x and have OLPC-4 branches for 9.1.0 because Rainbow runs
activities under different UIDs and they all need to connect to gabble
and salut - so there are two patches for each of these to weaken the
usual UID restrictions. This weakens dbus and socket permissions on a
multiuser system, so the patches are only suitable for running under
Rainbow and upstream Telepathy won't merge them into releases.

Since these are build-time patches, I'm not sure how you would remove
this fork - since regular F-10 and F-11 shouldn't have the patches,
but Rainbow requires them.

Oh, and one more reason for forks/branches: F-10 shipped with Sugar
0.82.x, but [the release formerly planned as 9.1.0] would have Sugar
0.84.x (and has 0.83.x packages in OLPC-4 now for testing on Joyride).

Regards
Morgan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activities migration status

[S Page]

Rafael Enrique Ortiz Guerrero wrote:

> Today I went through dev.laptop.org/git 
> identifying those projects
> that contain Sugar activities.
> 
> http://sugarlabs.org/go/ActivityTeam/ActivityStatus
> 
> Still remaining is to go through Activities/All (and code.google.com
> ,
> personal sites, etc) and find those activities which do not have d.l.o
> repositories.
> 
> The list is *massive*.  I had no idea we had so many cool activities
> in various stages of development! 

I'm not sure what you're doing, but if you want activities...
When the call went out for activities for 9.1.0 I put all the meta-lists 
of activities in


That links to some interesting queries in 
http://wiki.laptop.org/go/Activity_queries  :
* 45 pages with a Devel status
* 116 pages that appear to have an activity bundle
* 310 pages in Category:Activities in the main namespace.

and I'm sure there are more activities that lack a page on on 
wiki.laptop.org

--
=S
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activity not getting registered in the journal

[Bert Freudenberg]

On 14.01.2009, at 07:26, shivaprasad javali wrote:

> Hi,
>
>   I have an activity written in c++. I have used catmoran's  
> libsugarise library to sugarise my activity and create the activity  
> bundle. It runs fine on the XO but when I run my activity it is not  
> registered in the journal. I have attached a copy of my  
> activity.info file and sugarise script which loads the libsugarise  
> and calls my application. Can anyone figure out why the activity is  
> not registered in the journal?

The sugarize library (which is Albert's originally, catmoran just  
bundled it with my shell script to be easier to use) does nothing  
about the Journal. It only makes sure a proper icon is shown in the  
frame.

You will have to do the Journal integration yourself. An example of  
this was discussed in the "Journal integration for Scratch" thread.

Besides, if you indeed write the activity yourself in C++ there is no  
need to use the sugarize library in the first place. This was made  
purely to sugarize existing apps, and is rather insufficient for  
proper activities.

>   Also I wanted to ask one more thing. The applciation needs the  
> home path i.e. path to /home/olpc.

What for?

> But I cannot get this from the $HOME variable as this will not be  
> where the activity is installed when run from the activity launcher.  
> So I have hardcoded the path in my application to /home/olpc. How  
> safe do you think it is. Is it reasonable to assume that the users  
> home path will be this. Is there any other way I can get this path?


It is not reasonable to assume this.

Looking at your script it hard-codes the path to your activity bundle.  
This is not good practice and not necessary either. Please refer to  
the original of the script:

http://lists.laptop.org/pipermail/devel/2008-January/009387.html

and also it seems like a good idea for you to read

http://wiki.laptop.org/go/Low-level_Activity_API

which describes to the best of my knowledge what an activity author  
needs to do if she is not using the Python activity toolkit.

- Bert -

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: What keeps me going...

[Tomeu Vizoso]

Thanks, we need this kind of encouragement. I'm adding the SugarLabs'
IAEP mailing list to cc so more people can benefit from it.

Thanks again,

Tomeu

On Mon, Jan 12, 2009 at 22:58, Sameer Verma  wrote:
> So, a lot of people have been asking me this lately in the OLPC
> context. "What keeps you going?" Of course, this question has been
> asked by different people with different intentions. Some are
> genuinely surprised that I have so much free time, while others
> suspect a hidden treasure. So, I decided to shoot off this e-mail to
> the lists for two reasons. One, I am not sure which list is
> appropriate, and two, I think many of us do question the merits of
> this project from time to time, and I want to share my sentiments with
> you all. Feel free to delete if you don't like it.
>
> During my visit to India a long time friend asked me this question.
> "What keeps you going with a project like this?" He wanted to know
> where I got all this free time from. Well, the assumption is a bit
> off. A lot of the time I put into the project aligns with my
> profession as well. Sustainable IT, network infrastructure, software
> development, collaboration, etc. are all parts of my research stream.
> so is FOSS development, adoption and use. So, finding time isn't that
> much of a stretch. Its a two way street. I am able to bring these
> things into my classroom and into my research. Of course, without
> support from my family, this would be extremely difficult. For
> instance, when I am off, gallivanting in Jamaica and working on a
> pilot there, my wife has to cover for me and she does so with a lot of
> effort, but we think its all for a good cause. We hope some of this
> will make a difference in the lives of communities there.
>
> Others, such as some of my students, have asked me the same question
> but with a little "wink wink" glint in their eye. They think there is
> something ulterior or somehow I am getting paid or I am bucking the
> system (wonder where they got that idea from). Getting across the
> volunteer ethic is very hard. Either you get it or you don't. Of
> course, volunteer-ism is driven by many things including ego, fame,
> and little green laptops. It is also driven by a desire to make a
> difference in the system. Sometimes the system doesn't want that
> change, but we still push for it. But that's another e-mail.
>
> Then there are some of us who have an addictive desire to take things
> apart. You know who I'm taking about! Take apart and put back together
> things that most people would leave untouched. People who subscribe to
> Make magazine or own a soldering iron would know. Its a strange itch,
> but its an ethic that brings people together. Its hard to explain
> these things to people who've never opened a radio, or a watch. On the
> other hand, if you are the "Maker" type, you would instantly know. We
> were surprised at the courage of attendees at the December OLPC-SF
> meeting. They took their XOs apart and put them back together. Well,
> most of us did. Only Robert needed some help from a 7 year old
> attendee :-) (Sorry Robert. Couldn't resist!)
>
> I think its a lot of these reasons that keep us all together in this
> project and its offshoots, but one experience has captured my
> enthusiasm unlike any other. This was a trip to Khairat, India's first
> pilot site (http://wiki.laptop.org/go/Khairat_school). I had seen
> pictures, and even videos and news clips of Khairat. But driving out
> there with the folks from Reliance (the pilot partner) was a turning
> point. Seeing five year olds handling their XOs with ease was just
> amazing. Seeing them document their lives and showing me photos via
> the journal suddenly made a lot of sense. All discussions of a lack of
> a file manager were moot at that point. Rahul and Manisha sure don't
> need a file manager to show me what they did! They could care less
> about /etc or /usr/local/  I wish I could get the journal on my Ubuntu
> Thinkpad laptop.
>
> They had documented a tight rope walker who visited Khairat. They had
> documented Gandhi's birthday (2nd Oct) and showed me the photos. They
> didn't care that Sugar was slow. After all, for them to know that
> Sugar is slow, they would have to know something faster! They love
> their XOs and it shows. Then there is Mr. Surve, the teacher at
> Khairat. With very little training, this man gets his gang going. He's
> built solar system animations in e-toys and precipitation cycle in
> Paint. He has made his own lesson plans in Write and is constantly
> yelling in Marathi (local language) "Go to the neighborhood. Join the
> mesh". Who woulda thunk it? In the middle-of-nowhere-Khairat, a
> teacher is yelling a his kids to join the mesh. A draft version of
> 802.11s has made it that far! Of course Rahul and Manisha don't know
> that. And they don't need to, because we have a team of do-gooders who
> take care of all that. And that's where my respect and unconditional
> support for this 

Re: Journal integration for Scratch

[Bert Freudenberg]

The script looks good, except for the name mangling magic (which is a  
bit hard to understand because of mis-indentations). This wouldn't  
even work with your XO's language set to non-English (which the  
majority of XOs use).

I would simply name the file "$object_id.sb".

- Bert -

On 14.01.2009, at 07:04, Philipp Kocher wrote:

> Hi John
>
> Yes, we need the mimetypes.xml file as well (thanks Tomeu I forgot  
> the USB flash drive use case). I have tested the attached  
> mimetypes.xml. It is working fine. Put it in the activity directory.
>
> Furthermore we have to change the scratch-activity script, so the  
> parameter with the scratch project object-id gets converted (copy- 
> from-journal) in a file and passed on to scratch. See the attached  
> scratch-activity script. I am not an expert with bash scripts, so  
> please give feedback.
>
> I would like to extend the script so project files in the journal  
> directory are copied back to the journal after exiting scratch, but  
> for opening project it should work fine.
>
> Best regards,
> Philipp
>
> John Maloney wrote:
>> Hi, Phillip.
>> Thanks for all your hard work in tracking this down. I had looked  
>> at several other packages, including EToys, and couldn't figure out  
>> from them how to do this.
>> I will make these changes to the next XO Scratch bundle.
>> Is that all I need to do? What about the mime types XML file  
>> similar to the one added by Etoys? Does that turn out to be  
>> unnecessary?
>>-- John
>> On Jan 13, 2009, at 12:55 AM, Philipp Kocher wrote:
>>> Tomeu Vizoso wrote:
 On Mon, Jan 12, 2009 at 18:50, Bert Freudenberg >>> > wrote:
> On 12.01.2009, at 18:11, Tomeu Vizoso wrote:
>>> So what would the Scratch activity have to do so files put  
>>> into the
>>> Journal
>>> (maybe by downloading) are displayed using a Scratch icon  
>>> rather than the
>>> generic document icon?
>> Shipping a mimetypes.xml file inside the bundle as explained  
>> here:
>>
>> http://wiki.laptop.org/go/Activity_bundles#Bundle_Structure
>>
>> Sugar will call update-mime-database and will merge that file  
>> into the
>> xdg mime database.
>>
>> I think that John is already trying this.
>
> Guess I'm confused then - I thought that's exactly what Philipp  
> had done.
 I think he just changed the mime_types field in the .info file.
> And I just checked and it does work with Etoys projects. When  
> downloading
> one it indeed gets an etoys icon (although at a smaller size -  
> why is that?)
 No idea, though I think that the mime database is updated in the  
 etoys
 rpm and not in the bundle, am I right?
 Regards,
 Tomeu
>>>
>>> Thanks Tomeu to lead me to the /home/olpc/.local directory.  
>>> However, the
>>> mimetypes.xml is not necessary to get the icon in the journal. I  
>>> just
>>> had to copy the scratch icon file in the activity directory to
>>> "application-x-scratch-project.svg" (also in the scratch activity
>>> dirctory). The Memorize Activity is a good example for using that  
>>> feature.
>>> Sugar has to be restarted after installing Scratch to show the icon.
>>>
>>> John, could you please make the following changes in the next  
>>> Scratch
>>> version:
>>> - add the line "mime_types = application/x-scratch-project" to the
>>> activity.info file
>>> - copy the scratch icon to "application-x-scratch-project.svg" in  
>>> the
>>> activity directory
>>>
>>> Etoys gets configured by different packages. e.g. the rpm
>>> etoys-3.0.2153-1.noarch is adding the file
>>> /usr/share/mime/packges/etoys.xml and the rpm sugar- 
>>> artwork-0.82.3-1.olpc3 is
>>> adding the file
>>> /usr/share/icons/sugar/scalable/mimetypes/application-x-squake- 
>>> project.svg.
>>>
>>> Regards,
>>> Philipp
>>>
> 
> http://www.freedesktop.org/standards/shared-mime-info 
> ">
>   
> Scratch Project
> 
>   
> 
> #!/bin/sh
> # Author: Bert Freudenberg
> # Modified by: John Maloney
> # Purpose: Run Scratch using the Squeak virtual machine
>
> echo "scratch-activity"
> echo "$@"
>
> echo "$0" "$@"
> echo
>
> # arguments are unordered, have to loop
> args=""
> while [ -n "$2" ] ; do
>case "$1" in
>   -b | --bundle-id)   bundle_id="$2"   ; args="$args BUNDLE_ID  
> $2" ;;
>   -a | --activity-id) activity_id="$2" ; args="$args ACTIVITY_ID  
> $2";;
>   -o | --object-id)   object_id="$2"   ; args="$args OBJECT_ID  
> $2";;
>   -u | --uri) uri="$2" ; args="$args URI $2";;
>   *) echo unknown argument $1 $2 ;;
>esac
>shift;shift
> done
>
> # really need bundle id and activity id
> if [ -z "$bundle_id" -o -z "$activity_id" ] ; then
>  echo ERROR: bundle-id and activity-id arguments required
>  echo Aborting
>  exit 1
> fi
>
> # some debug output
> echo launching $bundle_id instance $activity_id
> [ -n "$object_id" ] && echo with journal obj $object_id
> [ -n "$uri"   ] && echo loading uri $