Re: [Sugar-devel] Attn maintainers Re:Pootle and POT files
On Sun, Aug 07, 2011 at 10:40:28PM -0400, Chris Leonard wrote: All, There is a widely held belief that Pootle takes care of updating the POT files in git and updating the Templates on Poolte. This is not entirely accurate. The fact is that there is nothing in the Pootle code itself that does this automatically. This automagical updating used to occur, but it was handled by scripts that Sayamindu had created to make it occur. These scripts have not been functioning for some time, probably since the last Pootle upgrade. We will look at re-establishing this functionality in conjunction with an upcoming upgrade of the Pootle version, but for now, if a developer makes UI string changes it is necessary for them to regenerate the POT file and commit it to git and then notify the Translation Team (me) to pull the changes up to Pootle with a Template Upgrade from VCS where they can then be distributed to languages with an Update from templates. That might be too messy.. ie, if pootle was handling this sort of things in auto mode, then, for sometime, all activity devs need to take care on theirs own, then pootle will back to processing in auto mode.. It sounds more problematically especially for honey (fructose is more centralized but even there we might have problems with in-time .pot updates). What about handling these .pot updates out-of-pootle and do not bother activity devs? If you give me a list of repos (I guess some kind of pootle config), I can setup regular .pot updates for git repos. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] [Dextrose] Sugar Server project initiation announce
On Sat, Jun 11, 2011 at 01:18:35AM -0700, Sameer Verma wrote: On Sat, Jun 11, 2011 at 12:06 AM, David Farning dfarn...@activitycentral.com wrote: -Original Message- From: Martin Langhoff [mailto:martin.langh...@gmail.com] Sent: Friday, June 10, 2011 11:46 PM To: David Farning Cc: Aleksey Lim; server-devel@lists.laptop.org; sugar-de...@lists.sugarlabs.org; olpc...@lists.laptop.org; dextr...@lists.sugarlabs.org Subject: Re: [Dextrose] [Sugar-devel] Sugar Server project initiation announce On Fri, Jun 10, 2011 at 10:44 PM, David Farning dfarn...@activitycentral.com wrote: You are 100% correct in these criticisms and concerns about Activity Central. We are a new company working in a new market. Failures and mistakes are inevitable. If you have been hurt by those mistakes, I apologize and accept full responsibility for them. Hi David! Look -- thanks for being so frank and open. Past it the past, and I've made mistakes aplenty myself. What I was trying to say was: you seem to be doing the same thing again. Like now. I mean -- today. How 'bout taking a slightly different tack? You just posted last week about cookie licking, which if you think about it... that perhaps applies to those big Ubuntu announcements last year for example. Perhaps could apply to this server thing -- we don't know yet. As I said, I frankly hope I am wrong. Anyway -- of course there may be business reasons for your forking. Happens. It's just that on the working with the existing project, the score isn't looking too good. I mean -- Aleksey subscribed to the xs-devel list, and his first message there was the opener of this thread. Classic. Based on Aleksey's past history of making good technical decisions, producing good implementations based on his designs, and his ability to work effectively with the existing community, I believe that what he produces will be a net gain for the Sugar/olpc ecosystem. As such, AC has given him the freedom to spend the next 6 months working on the server project. The technical decisions of how Aleksey solves the problem are separate from the business decisions of where Activity Central allocates its developer resources david ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Again, I like where this discussion is going, so it may be worthwhile to take some of this back to the drawing board. There is the issue of: 1) distro independence 2) content mgmt vs server admin separation 3) school vs library approach (curricular aka XS vs referential aka pathagar) Without building yet another school server, can we merge/improve upon what's already here? Incidentally, Nick Doiron has a post up on the Khan Academy videos being served offline (I've thought of the same situation, but with TED videos). http://mapadelsur.blogspot.com/2011/06/khan-academy-follow-up.html Neil Dsouza of http://teachaclass.org is in Indonesia (I think) setting up offline servers to serve Khan videos in an offline format. I hope to speak with him next week to see if we can collaborate/merge any of the efforts. I can't get rid of feeling that we are still talking about a bit different things: Thats the core difference between OLPC XS and Sugar Server ways, OLPC XS and Sugar Server and too different in two major cases: 1. Product vs. Project OLPC XS (how I got it and XS's clones from my pov) is a product from OLPC, ie, final product when you need to download in ISO, for example, and follow detailed instructions how to proper maintain it Sugar Server is a community, SL, project. Within this project happens (by all interesting people/deployments) development of core modules 2. OS vs. Tools OLPC XS (how I got it and XS's clones from my pov) is, due to its design, behaves as an OS: what sugar-server does on its own w/ humble deps[1] w/ only by one CLI tool in non-root manner (except initial install), XS does by having 3 projects/packages, bunch of shell/python scripts, running one process in root, creating local users (of course from root) (it is highly not welcome if are talking about one service I'm going to run on server, already configured and supported, to just serve XOs around). In other words XS assumes that it entirely control the OS. Sugar Server is being designed as one local sugar-server that serve only sugar specific features (no network setup, no iptabales setup, no Apache, no Moodle, no new local user, not root processes, etc) as a decent server does - on its own, you need only start it (event from sources directory); the second layer, which is independent
Re: [Server-devel] [Sugar-devel] Sugar Server project initiation announce
On Fri, Jun 10, 2011 at 01:08:35PM -0400, Martin Langhoff wrote: On Thu, Jun 9, 2011 at 1:51 PM, Aleksey Lim alsr...@activitycentral.org wrote: In fact, the project started three weeks ago but for now some of its core purposes became more clear, ie, ready for announcing. You guys are *weird*. I've been hearing from AC for a while that you'd help with XS, in private, and in grandiloquent public posts. I never received a single patch, rpm, or anything usable. Recently, Aleksey has been hacking on XS things, and that's excellent. And I apologize for not being more available -- I am working against some very tight and non-negotiable deadlines on the XO-1.75 project. Other times I have made myself available aplenty (with David van Assche for example). From Aleksey's efforts, I was expecting some patches, updated spec files, some reason to be happy. Instead, you announce that you fork or start from scratch (unclear to me which). There aren't major technical disagreements, or social disagreements -- at most you could complain that I've been a bit MIA for the last couple weeks. And you fork after a long long track record of promises -- in private and in public -- of working on the XS. Promises that were never followed up -- plenty of cookie licking if you want. Did anything ever happen with the plans announced at https://lists.ubuntu.com/archives/ubuntu-sugarteam/2010-October/002451.html ? You also announce this as a 'Sugar project' -- are those discussed with the board? If so... is there a 'check with current maintainer'? Or people make them up at will? It is a project started by one of SL contributors, the Sugar reflects on the core idea that make this new project different to the existed one, i.e., having explicit separation between upstream project and downstream solutions (based on Sugar Server and made on purposes according the the local needs). Thus, it is Sugar Server. It was the idea from beginning and I apologise if you got it wrong. Also, preventing another misunderstanding, it is not an AC project (there will be AC's Dextrose Server based on Sugar Server) but a project whithin SL (as I did for all my previous work). Beyond my irritation, I hope this one goes well, and leads somewhere. The XS needs love. A fork for the fun of it isn't exactly love but hey. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Sugar Server project initiation announce
Hi all, In fact, the project started three weeks ago but for now some of its core purposes became more clear, ie, ready for announcing. Some of major ideas: * Common project within Sugar Labs to keep core development process in one place; * It is not about configuring and supporting the whole server at school from scratch but about having a set of tough, local, doing its job well modules that might be included/excluded in downstream solutions; * Friendly support of customization on purpose in downstream products: * Modularizing, when components might be included on purpose to fulfill local needs, * Not patching in downstream but supplementing the upstream, e.g., install upstream packages and just add new packages with local customization or overrides (but not overriding installed files to let PMS work smooth) of upstream, * Provide useful API for components; * Be a GNU/Linux distribution agnostic, different deployment might decide to use different GNU/Linux distributions. * It is not only about supporting XO laptops but about any Sugar based environments; * Up to 1000 students per server. Why not improving existed OLPC XS: * its functionality is scattered among several projects and many of shell and python scripts * some of architectural decisions make XS not localized app on the server, e.g., using incron, external httpd (for not too high load), creating local users for handling backups * Sugar Server is not about configuring servers from scratch, but about having smart and local tools that might be used in downstream on purpose, eg, moodle and puppet are not a core of Sugar Server More info about Sugar Server architectural ideas might be find here: http://wiki.sugarlabs.org/go/The_Server/Architecture The home page is: http://wiki.sugarlabs.org/go/The_Server Current plans are: http://wiki.sugarlabs.org/go/The_Server/1/Roadmap http://wiki.sugarlabs.org/go/The_Server/1/Todo http://wiki.sugarlabs.org/go/The_Server/1/Components Source on git.sugarlabs.org: http://git.sugarlabs.org/server If you share the same vision on core purposes behind Sugar Server, you are welcome! -- Aleksey ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [OLPC-AU] e: Regarding my OLPC XS Wishlist (Abhishek Singh)
On Fri, Jun 10, 2011 at 12:24:45AM +1000, Sridhar Dhanapalan wrote: On 8 June 2011 04:44, Sameer Verma sve...@sfsu.edu wrote: On Tue, Jun 7, 2011 at 3:40 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Jun 6, 2011 at 12:30 PM, TONY ANDERSON tony_ander...@usa.net wrote: Meanwhile I have posted my version of the wish list as a wiki page: http://wiki.sugarlabs.org/go/School_Server_Wish_List Ntoe that people go to our wiki in search for documentation. That is your _personal_ wishlist. Please move it to a personal page. I really like where this discussion is going and the fact that we have two other XS related efforts in Nepal and Australia. Should we then make this a community wishlist that encompasses several wishes? Perhaps, but it must be clear that this is an opinions page and is not official. So far I have counted at least six school server types: * OLPC XS * XS-AU (Australia) * NEXS (Nepal) * Paraguay Educa server * Plan Ceibal server (Uruguay) * Sugar Server (Activity Central) One but critical change, it is: * Sugar Server project (Sugar Labs) * Dextrose Server, Sugar Server based, product (Activity Central) (I'm composing an announce for Sugar Server launch) I am keen to have some consolidation, to avoid parallel development and splintering of the community. I am open to discussion on how we can achieve this. Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ OLPC-AU mailing list olpc...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-au -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Fri, Jun 03, 2011 at 09:40:48AM -0400, Martin Langhoff wrote: On Fri, Jun 3, 2011 at 7:49 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 3 June 2011 21:31, Aleksey Lim alsr...@activitycentral.org wrote: btw, did someone try to use cloning paradigm for setting up new school servers instead of using regular install way? Just clonning the system will lest avoid many issues by design. Do you mean creating an image of a server installation and applying it to other machines? We've done that with the XS-AU (using clonezilla), and I'm pretty sure it works with an OLPC XS. Note that without a script that cleans up config state, you're bound to have some fun problems with the resulting systems. Do you mean particular script, which one? hth, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Aleksey ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: On 28 May 2011 08:31, Aleksey Lim alsr...@activitycentral.org wrote: On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote: On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Thank you! Forwarding this to the Dextrose list as well. I've also CCed guys who do XS work in .au Abhishek: thanks for sharing your wishlist. From my side, I see the whole picture in case of school server like having: * sugar-server[1], the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so) * any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace[2]). * final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs. We are looking to make our XS-AU[0] more modular to suit different use cases. Our initial goal (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? sugar-server in that case is a new project w/ more tough and localized design. work on a single interface to integrate well into existing networks. Installation is via USB and fully scriptable via kickstart files. The current XS is very monolithic and bureaucratic. It requires moderate sysadmin skills to install and maintain. Maintaining the presence service is cumbersome and impractical in our schools. The turnover of teachers and students is far too high to ensure that anything gets managed properly. We're looking to slim down the XS-AU such that we can have a simple collaboration server (which we currently call XS Lite) that is installable in a classroom as a drop-in appliance. ie, just having jabber server and somehow let students know where it is? is an ejabberd. btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Registration, Moodle, Squid, backups and so on are unnecessary. Each teacher can run their own server for their own class. Conveniently, this could easily run on an XO (XS-on-XO). in other workds there is no need in sugar specific stuff at all - just install jabber server from packages (maybe w/ sugar specific patches) and write its url on studensts' boxes. My own running though your wishlist keeping in mind sugar-server plans: 1) Porting XS to new version of Fedora sugar-server will be build on OBS[3] for distros that are being used in the field (deb or/and rpm based). So, downstream can just use these packages, add new one and create the final product (there is an idea to teach OBS to create isos for not only SUSE, obs is designed originally) You're using SuSE as a base? That sounds like an awful lot of work porting to a distribution that isn't widely used. Why not stick with the current platform, which benefits from Red Hat engineering and has a much larger developer, installation and user base? Not to mention that the XOs use the same platform, meaning that skills can be shared across client and server. OBS is not only suse (in fact, they renamed it from openSuse Build Service to Open Build System recently). In other words, it can create package for any rpm/deb based distro, but, afaik, it can create iso only for opensuse for now (and plan is looking how it might be done for other distros, but anyway using obs as a packages farm is good w/o having isos). The XS-AU has been working pretty well on Fedora 11 for quite some time. We've reconfigured it so that it runs as a set of packages on top of Fedora 11[1] rather than being a fork. We're quire confident that it'll work on Fedora 13 without much effort. Fedora 14 will need a bit of work since it has a newer version of Python. Sridhar [0] http://dev.laptop.org.au/projects/xs-au/wiki [1] http://dev.laptop.org.au/projects/xs-au/wiki/Install_on_an_existing_Fedora_installation Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au -- Aleksey
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 02, 2011 at 09:20:55AM +, Aleksey Lim wrote: On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote: (completed over a year ago) If I got it right, it is still the same OLPC XS code base but w/ tweaks? sugar-server in that case is a new project w/ more tough and localized design. btw whats the clon url for http://dev.laptop.org.au/projects/xs-au/repository reading sources from web pages is not too useful -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Regarding my OLPC XS Wishlist
On Thu, Jun 02, 2011 at 11:42:52AM -0400, Martin Langhoff wrote: On Thu, Jun 2, 2011 at 5:20 AM, Aleksey Lim alsr...@activitycentral.org wrote: btw, I'm planing to use Prosody instead of ejabberd. I have really bad experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many resources for regular 10-30 online users. Prosody is slim and light app and it alsready works fine w/ sugar-0.88. Have you spent any time learning how to configure ejabberd? Diagnosing your problem? Discussing it on the ejabberd mailing list? Well, I assume OLPC people did it many times before me, I just reused their experience tryinhg to follow wiki.l.o docs and using native packages from fedora. My plan is trying to figure out why 0.92 doesn't work w/ Prosody and run it on jabber.sl.o to see how much resources it will take in comparing w/ ejabberd. -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Activity packaging
On Wed, Aug 04, 2010 at 08:05:06PM +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Thats right, and all PackageKit benefits will be reused within 0sugar/0install (but mostly for non-sugar dependencies, it will be possible to reuse native packages for sugar application as well but see below). But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Sun, Aug 08, 2010 at 07:18:51AM -0700, Jon Nettleton wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. Well, I thought also about vcs but came to decision that it sounds like misusing of vcs: * vcs is all about sources (storing binaries is possible but is misusing), * all sugar related code will be shared only in sources, which is not bad in general (especially as an option) but sounds overkill for binary-based activities * all dependencies should be stored in vcs and deployed via vcs as well (otherwise system should be not pure vcs and will look pretty ugly) Also there is no need in storing results of experiments in vcs at all, e.g., doer just tweaks his local code and let 0sugar share it w/o commiting to vcs server(which should be used to fetch sources on client side), supporting per doer vcs servers would sound pretty overkill. Some kind of binding vcs repos with packaging/distribution stuff is possible and afaik many GNU/Linux distribution do packaging from, e.g., git repos (we can do similar things on our OBS), but they don't mix vcs and distribution. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 06, 2010 at 11:51:00AM -0400, Bernie Innocenti wrote: On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote: Sorry about the confusion, these questions were about the move from xo bundles to packages :( Ah! Communication FAIL! :) Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. To obtain (2) and (7), we might want to wrap the native packages with a distro-neutral meta-format, similar to the current activity.info files. I don't know the details yet, but I guess this is pretty much what Aleksey is doing with his 0sugar redesign. Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance i.e. for activity developer, process should look like pretty straight forward, everything what he needs is a spec file. Spec file is not like regular activity.info (some kind of metadata file that is used in runtime) but a regular spec file like .spec in rpm. Some examples of real (but for now only built only for 0install) http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_library http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Vala_library and how it will look like for activities http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_activity The milestones I'm planing are: * Having just 0sugar.info spec file (and 0distro build time dependency on obs), build native packages on bunch of rpm and deb based distros on OBS. I'm planing to have rpm and deb packages for Sucrose, Polyol, GC, OOo4Kids built from only 0sugar.info spec files in two weeks * Having just 0sugar.info and 0sugar tool, distribute homemade blobs (already works) and blobs built on OBS via 0install * merge all things together and make it useful within sugar - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core - switch from bundle_id identification to http urls for activities, (at some point it sounds like urls for microformat updates) it could be really useful if user on any sugar box could run activity just by mentioning its url * new UI, how it could look like with new packaging infrastructure So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. The rest of steps could be implemented in parallel manner. I think switching to a native package format is essential: currently, both the Fedora and Ubuntu teams are spending a lot of time to re-packaging just a few activities, resulting in duplicated effort and increased time-to-market for activities. just an OBS feature that could be used as is if most of activities will accessible from obs http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Use_Cases#Per_user_Sugar_on_a_stick -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 06, 2010 at 05:59:04PM -0400, Bernie Innocenti wrote: On Tue, 2010-07-06 at 19:56 +, Aleksey Lim wrote: Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance Will it also remove the need to ship fat bundles, as we do now? I mean, will it produce separate packages for each architecture/os or just one large package with many binaries in it? I tend to prefer the first way, like rpm and deb do. There is no any bundles in core design i.e. if you are talking about fat bundles we are talking about distribution method, in my mind such distribution methods could be: * via distro repos on obs(or other build farm), users attach these repos * via 0install, user just type sugar-activity/0lauch http-url to start activity or any software * for sneakernet, 0sugar tool could generate bundles like ./setup.py dist_xo does, imho there is not huge need in having smart/fat bundles like I tried to to with 0installed bundles; but anyway later practice will make it more clear - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core Wouldn't PackageKit be a perfect match for this? Firstly, 0install already can install native packages via PackageKit and secondly (keeping in mind your reply to Benjamin), talking about *only* native packages we loose one simple and core-for-sugar thing, any sugar user should be, at the end, a doer. For example, if we have TuxPaint activity and many doers are experimenting (change C code and compile) with it, what can do a person, who decides to try all these TuxPaint activities, having native packages as only distribution method? ask all doers use the same repo (sounds useless); attach repos per doer (conflicts); handle all issues by himself (not useful as well). With having 0install (which is already exists and works) as engine, we handle these issues automatically. Using 0install doesn't mean that everything is ok with 0install from sugar pov, e.g. one of core sugar workflows when user need only place activity to ~/Activities to make it useful is absent in 0install (it designed as regular packaging system e.g. there is no need in changing some software in /usr/lib). So, 0install is required later hacking but it effectively solve last of packaging issues - how to *launch*(not install) arbitrary activity in heterogeneous environment. So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. It's an amazing piece of work, Aleksey!! Considering that you're tackling on the hardest problem in the Sugar universe, I'm very impressed by the progress you've made in such a short amount of time. Well, not so short amount of time, my first commit to jhconvert (my first experience in meta packaging) was Fri Dec 05 01:29:55 + 2008 -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity for XO-1.5
On Thu, Apr 29, 2010 at 05:34:52PM -0300, Daniel Drake wrote: On 29 April 2010 17:23, Aleksey Lim alsr...@member.fsf.org wrote: Are there chances to decrease gst version? issue w/ core dump could be solved just by removing plughw check. I spent weeks on this during my OLPC internship. The gstreamer versions back then simply have too many bugs. gstreamer-0.10.14 was released 2.5 years ago. Let's be a little pragmatic here... Well, I was just talking about making new Record public on ASLO. At the end, it could be just not public and if ASLO will be used by deployment as update mechanism and update scheme w/ collections will be implemented, having new Record not public won't be problem (update collections will contain this particular version even if it is not public). So, I'm switching master on git.sl.o to new Record and uploading it to ASLO (in experimental state). Also I'm planing to use version like v84 to save some space for possible updates for Record on 0.82. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity for XO-1.5
On Thu, Apr 29, 2010 at 12:09:28PM -0300, Daniel Drake wrote:
On 29 April 2010 11:57, Daniel Drake d...@laptop.org wrote:
Updated again
git://dev.laptop.org/users/dsd/record
http://dev.laptop.org/git/users/dsd/record/
Aleksey, what do you think of these changes?
You mentioned before about being open to the idea but needing a new
maintainer -- I don't think we have any immediate options here. I can
be responsive for the next 2 weeks, but after that I have no idea.
I'm testing it on XO-1 and got several issues
1) Record tries to test plughw alsa device, but gst just crashes
I removed this test and Record started well. Not sure if it is right
to have such check at all i.e. override user preferences
2) Record never stops in video recording mode
nothing useful in log (attached)
--
Aleksey
1272561054.566657 WARNING root: Activity directory lacks a MANIFEST file.
1272561058.829694 DEBUG root: *** Act f873d32ed0d32e83d964ca9079ca9c083b5c1a24,
mesh instance None, scope private
1272561058.831774 DEBUG root: Creating a jobject.
1272561058.856203 DEBUG root: datastore.write
1272561059.055945 DEBUG root: dbus_helpers.create:
9a7112e9-2106-4765-a0f0-c83284131949
1272561059.059547 DEBUG root: Written object
9a7112e9-2106-4765-a0f0-c83284131949 to the datastore.
** (sugar-activity:1830): DEBUG: Got client ID
109e556b69337966b612725610604080450017980001
** (sugar-activity:1830): DEBUG: Setting initial properties
OIL: ERROR liboiltest.c 361: oil_test_check_impl(): illegal instruction in
mmxCombineAddU
1272561062.029255 DEBUG root: ('Setup widget', None)
1272561062.036445 WARNING root: No gtk.AccelGroup in the top level window.
1272561062.056974 DEBUG root: ('Setup widget', None)
1272561062.063760 WARNING root: No gtk.AccelGroup in the top level window.
** (sugar-activity:1830): DEBUG: Received SaveYourself(SmSaveLocal, !Shutdown,
SmInteractStyleNone, !Fast) in state idle
** (sugar-activity:1830): DEBUG: Sending SaveYourselfDone(True) for initial
SaveYourself
1272561062.329444 DEBUG root: ActivityService.set_active: 1.
** (sugar-activity:1830): DEBUG: Received SaveComplete message in state
save-yourself-done
1272561063.463991 DEBUG root: updateProgress 0
1272561063.836283 DEBUG root: updateProgress 0
1272561071.310498 DEBUG root: updateProgress 0
1272561071.313472 DEBUG record:ui.py: updateVideoComponents: MODE=(-1,0)
FULLSCREEN=(False,False) LIVE=(True,True) RECD_INFO=(False,False)
TRANSCODING=(False,False) MESHING=(False,False) windowStack=10
1272561071.827752 DEBUG record:ui.py: updateVideoComponents: MODE=(0,0)
FULLSCREEN=(False,False) LIVE=(True,True) RECD_INFO=(False,False)
TRANSCODING=(False,False) MESHING=(False,False) windowStack=10
1272561078.390400 DEBUG record:model.py: createNewRecorded: recorded.Recorded
instance at 0x8c3660c,
thumbFilename:08eb217c1abc2325c71759169cc61e3760e9457db_1272561078_thumb.jpg
1272561080.328931 DEBUG root: ('Setup widget', gtk.Button object at 0x8c803c4
(GtkButton at 0x889f2d8))
1272561083.056180 DEBUG root: updateProgress 0
1272561083.258794 DEBUG record:ui.py: updateVideoComponents: MODE=(0,0)
FULLSCREEN=(False,False) LIVE=(True,False) RECD_INFO=(False,False)
TRANSCODING=(False,False) MESHING=(False,False) windowStack=10
1272561087.735329 DEBUG root: updateProgress 0
1272561087.738331 DEBUG record:ui.py: updateVideoComponents: MODE=(0,0)
FULLSCREEN=(False,False) LIVE=(False,True) RECD_INFO=(False,False)
TRANSCODING=(False,False) MESHING=(False,False) windowStack=10
1272561095.542994 DEBUG root: updateProgress 0
1272561095.549123 DEBUG root: updateProgress 0
1272561095.552141 DEBUG record:ui.py: updateVideoComponents: MODE=(-1,2)
FULLSCREEN=(False,False) LIVE=(True,True) RECD_INFO=(False,False)
TRANSCODING=(False,False) MESHING=(False,False) windowStack=10
1272561100.543629 DEBUG root: updateProgress 0
1272561100.554570 DEBUG root: updateProgress 0
1272561100.557648 DEBUG record:ui.py: updateVideoComponents: MODE=(-1,1)
FULLSCREEN=(False,False) LIVE=(True,True) RECD_INFO=(False,False)
TRANSCODING=(False,False) MESHING=(False,False) windowStack=10
/home/sugar/src/activities/record2.activity/glive.py:429: Warning:
IA__g_object_notify: object class `GstV4l2Src' has no property named `norm'
self.pipeline.set_state(gst.STATE_PLAYING)
1272561115.468449 DEBUG root: updateProgress 0.00423637429873
1272561115.979860 DEBUG root: updateProgress 0.00849941571554
1272561116.498866 DEBUG root: updateProgress 0.0127796590328
1272561117.005732 DEBUG root: updateProgress 0.0170478006204
1272561117.526238 DEBUG root: updateProgress 0.0213852008184
1272561118.049576 DEBUG root: updateProgress 0.0257470409075
1272561118.567353 DEBUG root: updateProgress 0.030060082674
1272561119.073484 DEBUG root: updateProgress 0.0342795491219
1272561119.574958 DEBUG root: updateProgress 0.0384578247865
1272561121.810780 DEBUG record:ui.py: updateVideoComponents: MODE=(1,1)
FULLSCREEN=(False,False) LIVE=(True,True) RECD_INFO=(False,False)
Re: Record activity for XO-1.5
On Thu, Apr 29, 2010 at 02:41:58PM -0300, Daniel Drake wrote: On 29 April 2010 14:16, Aleksey Lim alsr...@member.fsf.org wrote: I'm testing it on XO-1 and got several issues Which OS version? 802 1) Record tries to test plughw alsa device, but gst just crashes I removed this test and Record started well. Not sure if it is right to have such check at all i.e. override user preferences What do you mean by crashes? Throws an exception? just coredump with bt #0 0xb63808b0 in ?? () from /lib/libasound.so.2 #1 0xb6366fcc in ?? () from /lib/libasound.so.2 #2 0xb6381636 in ?? () from /lib/libasound.so.2 #3 0xb6365436 in snd_pcm_hw_refine () from /lib/libasound.so.2 #4 0xb6362411 in snd_pcm_hw_params_any () from /lib/libasound.so.2 #5 0xb6161c12 in gst_element_class_get_pad_template_list () from /usr/lib/gstreamer-0.10/libgstalsa.so #6 0xb6160c43 in gst_element_class_get_pad_template_list () from /usr/lib/gstreamer-0.10/libgstalsa.so #7 0xb6a61d8f in ?? () from /usr/lib/libgstbase-0.10.so.0 #8 0xb69e7ab7 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #9 0xb69ed6e8 in gst_pad_link () from /usr/lib/libgstreamer-0.10.so.0 #10 0xb6a0d4ab in ?? () from /usr/lib/libgstreamer-0.10.so.0 #11 0xb6a0e909 in gst_element_link_pads () from /usr/lib/libgstreamer-0.10.so.0 #12 0xb6a0f58a in gst_element_link_pads_filtered () from /usr/lib/libgstreamer-0.10.so.0 #13 0xb6a0f6bb in gst_element_link_filtered () from /usr/lib/libgstreamer-0.10.so.0 #14 0xb6ac3f45 in ?? () from /usr/lib/python2.5/site-packages/gst-0.10/gst/_gst.so #15 0xb7dea549 in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0 looks like gst bug. What was the reason to use plughw in any case, is it pulse? Not sure if it is correct to add such workarounds on application level. 2) Record never stops in video recording mode nothing useful in log (attached) Unfortunately I don't have an XO-1 to reproduce or diagnose. Daniel -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity for XO-1.5
On Thu, Apr 29, 2010 at 04:26:56PM -0300, Daniel Drake wrote: On 29 April 2010 15:30, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Apr 29, 2010 at 02:41:58PM -0300, Daniel Drake wrote: On 29 April 2010 14:16, Aleksey Lim alsr...@member.fsf.org wrote: I'm testing it on XO-1 and got several issues Which OS version? 802 That's fedora 9, with gstreamer from Fedora 7. This activity requires Fedora 10 + corresponding gstreamer version or newer. (I spent months looking for a way to make it work nicely on both old and new, without sacrificing features or code quality, and failed. It's just not worth it.) The problem here is that fc10 has gst-0.10.20 but even for 0.88 Sugar Platform has 0.10.14 minimum version http://wiki.sugarlabs.org/go/0.88/Platform_Components So, new Record couldn't be nominated to be public on ASLO. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity for XO-1.5
On Thu, Apr 29, 2010 at 05:01:53PM -0300, Daniel Drake wrote: On 29 April 2010 16:39, Aleksey Lim alsr...@member.fsf.org wrote: The problem here is that fc10 has gst-0.10.20 but even for 0.88 Sugar Platform has 0.10.14 minimum version http://wiki.sugarlabs.org/go/0.88/Platform_Components So, new Record couldn't be nominated to be public on ASLO. i.e. we're held back by a very loosely maintained wiki page? There's no other solution? Well, Sugar Platform scheme was designed to solve dependecy related issues in not-only-one distro environment, if someone is ignoring it (public activity on ASLO), that will just break entirely scheme. For activities I support, I'm trying to not use non SP deps or include them to .xo (which is not good in case of gst of course) e.g. recent libxml and librsvg for GC. I'm talking about ASLO because in my mind restricting sugar activities only to one particular (sugar)distribution is not right even if it is about OLPC. Unfortunately ASLO doesn't support info about variety of distributions (since Sugar Platform is intended to cover all dependency related issues). So we can't mark new Record only for fc10+ (except note in activity description, which is not so useful). Are there chances to decrease gst version? issue w/ core dump could be solved just by removing plughw check. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity for XO-1.5
On Wed, Apr 21, 2010 at 02:59:38PM -0300, Daniel Drake wrote: On 20 April 2010 18:06, Daniel Drake d...@laptop.org wrote: Hi, Here's a version of the Record activity which works on XO-1.5: git://dev.laptop.org/users/dsd/record I updated this git tree. The code I announced yesterday is now in the v60-plus-tweaks branch. The master branch (non-fast-forward) is now the Record git tree from activities.sugarlabs.org, with my v60 rework placed on top of it. i.e. working towards a patch series that can be applied to SL upstream. It's working fine but has a regression over v66 - v66 supports systems without Xv, this one does not. (not a release blocker, IMO, but might not be too much effort to add this again) Current plans of Record on http://git.sugarlabs.org/projects/record: Since there are window related glitches on metacity (0.86+) and coding gst on python level is fragile (if make this precess smooth i.e. w/o just reset everything on every mode switch) in such not trivial case like Record. I was planing to code current master as less as possible and switch to camerabin and new UI w/ gtk.Window less design. Unfortunately I found that camerabin (w/ some proposed to upstream patches) can smooth work on XO-1 only in 176x144 mode, but in such resolution camera view region is less then usual which makes this mode useless. So, since most of users have XO-1 (I suppose) and coding two phases vide encoding (one encoded vide + wav and wav encoding in second phase) sounds pretty uncommon in not XO-1 case (and also for camerabin upstream) I postponed new Record coding. If there is an intention to have dev.l.o branch on git.sl.o, I can add new user to commiters list to merge/reset master to dev.l.o code. In this case we just need someone who will maintain it and also git.sl.o code is targeting to not only XO users and maybe Xv less issue could be a problem for someone (but not sure that many people will be affected). -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 09:31:25PM -0400, Bernie Innocenti wrote: On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. I agree on this, but it misses the point :-) I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. That's what I'm feeling all time started from the first time of my participating in sugar when I packaged sugar for several distros. Here are some real-world examples from this development cycle: * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs * activities such as Record tend to uncover obscure bugs in GStreamer * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable * ...not to mention NetworkManager... I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. and thats why I like 0install way - it is not tied to particular distro (packaging system) but can get benefits from all major distros (via PackageKit) and add distro agnostic packaging system. In my plans create distro agnostic sugar distribution entirely based on 0install - on most recent systems, users need only several clicks to install sugar w/o root privileges and even if sugar didn't packaged at all for this particular distro. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Missing Library File After GCompris Compilation
On Wed, Mar 10, 2010 at 10:38:48PM +0100, Bruno Coudoin wrote: Ok, this process has been deprecated by work done by Aleksey (in copy) to use 0install. My bundleit.sh will be removed once the 0install process for GCompris is in place. For the mean time, you can use it but the source operating system and the target one must be as close as possible to avoid the missing library situation which you faced. Bruno. Le mercredi 10 mars 2010 à 00:52 +0200, Tamer Alkhouli a écrit : I am bundling the activity using the provided bundleit.sh script, which you can find here: http://git.gnome.org/browse/gcompris/tree/src?h=gcomprixo I am using Ubuntu, are you suggesting that I should use aptitude to generate the XO file? If yes, how can that be done? Thanks, On Tue, Mar 9, 2010 at 10:54 PM, Bruno Coudoin bruno.coud...@free.fr wrote: Le dimanche 07 mars 2010 à 03:51 +0200, Tamer Alkhouli a écrit : Hello all, I was trying to modify one of the GCompris activities (memory-activity), and after bundling the compiled code and trying to install it using the sugar-install-bundle command on the XO, I got an error message telling me that libxcb-render-util.so.0 was missing. When I copied that file to /usr/lib/ everything worked just fine. Any idea why this problem showed in the first place? And how to fix it permanently? Note that the non-modified GCompris activity doesn't need that file. It depends on your intention about sharing your activity, * for all users (not only sugar) * for all sugar users (not only XO) * or just for XO (particular version, 1 xor 1.5) users 0install stuff, I'm going to propose for inclusion to main branch, is intended to cover all these situations (with resolving not GC issues like (not)existing of particular version of libxml/librsvg), thus it could be overkill if you want just to run activity on XO-1. In that case you can follow simpler scheme: * configure GC with --prefix=/ * make GC (you need only your activity and a couple of libs but just in case) * go to activity directory you want to bundle * run `make DESTDIR=path install-activity` * you will get path/activities/activity directory with all you need * follow regular(not related to GC) .xo bundle procedures to make .xo e.g. you can use http://git.gnome.org/browse/gcompris/tree/src/gcompris-activity?h=gcomprixo as startup script Well each library on which we depend brings its own dependency to us. It means that if you compile on a system were X depends on the library libxcb-render then our gcompris binary will require it. But if this library is not present on a given system then GCompris won't start at all because GNU/Linux expect all dynamic libraries required by a binary to be present. To avoid this situation, all GNU/Linux distribution have a packaging system in place. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Tamer Alkhouli -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Missing Library File After GCompris Compilation
On Thu, Mar 11, 2010 at 03:41:27AM +, Aleksey Lim wrote: On Wed, Mar 10, 2010 at 10:38:48PM +0100, Bruno Coudoin wrote: Ok, this process has been deprecated by work done by Aleksey (in copy) to use 0install. My bundleit.sh will be removed once the 0install process for GCompris is in place. For the mean time, you can use it but the source operating system and the target one must be as close as possible to avoid the missing library situation which you faced. Bruno. Le mercredi 10 mars 2010 à 00:52 +0200, Tamer Alkhouli a écrit : I am bundling the activity using the provided bundleit.sh script, which you can find here: http://git.gnome.org/browse/gcompris/tree/src?h=gcomprixo I am using Ubuntu, are you suggesting that I should use aptitude to generate the XO file? If yes, how can that be done? Thanks, On Tue, Mar 9, 2010 at 10:54 PM, Bruno Coudoin bruno.coud...@free.fr wrote: Le dimanche 07 mars 2010 à 03:51 +0200, Tamer Alkhouli a écrit : Hello all, I was trying to modify one of the GCompris activities (memory-activity), and after bundling the compiled code and trying to install it using the sugar-install-bundle command on the XO, I got an error message telling me that libxcb-render-util.so.0 was missing. When I copied that file to /usr/lib/ everything worked just fine. Any idea why this problem showed in the first place? And how to fix it permanently? Note that the non-modified GCompris activity doesn't need that file. It depends on your intention about sharing your activity, * for all users (not only sugar) * for all sugar users (not only XO) * or just for XO (particular version, 1 xor 1.5) users 0install stuff, I'm going to propose for inclusion to main branch, is intended to cover all these situations (with resolving not GC issues like (not)existing of particular version of libxml/librsvg), thus it could be overkill if you want just to run activity on XO-1. In that case you can follow simpler scheme: * configure GC with --prefix=/ you can also add --disable-sqlite --disable-gnet arguments if targeted environment won't have such libs * make GC (you need only your activity and a couple of libs but just in case) * go to activity directory you want to bundle * run `make DESTDIR=path install-activity` * you will get path/activities/activity directory with all you need * follow regular(not related to GC) .xo bundle procedures to make .xo e.g. you can use http://git.gnome.org/browse/gcompris/tree/src/gcompris-activity?h=gcomprixo as startup script Well each library on which we depend brings its own dependency to us. It means that if you compile on a system were X depends on the library libxcb-render then our gcompris binary will require it. But if this library is not present on a given system then GCompris won't start at all because GNU/Linux expect all dynamic libraries required by a binary to be present. To avoid this situation, all GNU/Linux distribution have a packaging system in place. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Tamer Alkhouli -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Aleksey -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Missing Library File After GCompris Compilation
On Thu, Mar 11, 2010 at 03:43:42AM +, Aleksey Lim wrote: On Thu, Mar 11, 2010 at 03:41:27AM +, Aleksey Lim wrote: On Wed, Mar 10, 2010 at 10:38:48PM +0100, Bruno Coudoin wrote: Ok, this process has been deprecated by work done by Aleksey (in copy) to use 0install. My bundleit.sh will be removed once the 0install process for GCompris is in place. For the mean time, you can use it but the source operating system and the target one must be as close as possible to avoid the missing library situation which you faced. Bruno. Le mercredi 10 mars 2010 à 00:52 +0200, Tamer Alkhouli a écrit : I am bundling the activity using the provided bundleit.sh script, which you can find here: http://git.gnome.org/browse/gcompris/tree/src?h=gcomprixo I am using Ubuntu, are you suggesting that I should use aptitude to generate the XO file? If yes, how can that be done? Thanks, On Tue, Mar 9, 2010 at 10:54 PM, Bruno Coudoin bruno.coud...@free.fr wrote: Le dimanche 07 mars 2010 à 03:51 +0200, Tamer Alkhouli a écrit : Hello all, I was trying to modify one of the GCompris activities (memory-activity), and after bundling the compiled code and trying to install it using the sugar-install-bundle command on the XO, I got an error message telling me that libxcb-render-util.so.0 was missing. When I copied that file to /usr/lib/ everything worked just fine. Any idea why this problem showed in the first place? And how to fix it permanently? Note that the non-modified GCompris activity doesn't need that file. It depends on your intention about sharing your activity, * for all users (not only sugar) * for all sugar users (not only XO) * or just for XO (particular version, 1 xor 1.5) users 0install stuff, I'm going to propose for inclusion to main branch, is intended to cover all these situations (with resolving not GC issues like (not)existing of particular version of libxml/librsvg), thus it could be overkill if you want just to run activity on XO-1. In that case you can follow simpler scheme: * configure GC with --prefix=/ you can also add --disable-sqlite --disable-gnet arguments if targeted environment won't have such libs heh, forgot to mention, on XO-1 you need librsvg = 2.26, libxml2 = 2.7.3 * make GC (you need only your activity and a couple of libs but just in case) * go to activity directory you want to bundle * run `make DESTDIR=path install-activity` * you will get path/activities/activity directory with all you need * follow regular(not related to GC) .xo bundle procedures to make .xo e.g. you can use http://git.gnome.org/browse/gcompris/tree/src/gcompris-activity?h=gcomprixo as startup script Well each library on which we depend brings its own dependency to us. It means that if you compile on a system were X depends on the library libxcb-render then our gcompris binary will require it. But if this library is not present on a given system then GCompris won't start at all because GNU/Linux expect all dynamic libraries required by a binary to be present. To avoid this situation, all GNU/Linux distribution have a packaging system in place. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Tamer Alkhouli -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Aleksey -- Aleksey -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Problem importing hulahop.webview() in sugar emulator
On Sat, Feb 13, 2010 at 05:06:38AM +0530, vijit singh wrote: Hello everyone, SocialCalc is based upon the use of hulahop.webview widget. While trying to run socialcalc on sugar emulator running on Fedora and Ubuntu, error saying No module hulahop was occurring. So, we tried installing hulahop on these linux distributions. *1. Firstly we tried with ubuntu-8.10, here are the exact steps taken- * * **xulrunner was pre-installed. And then I installed python-support.deb and libxul0d.deb which are pre-requistie packages for python-xpcom package (other pre-requistie packages were already installed). Then i installed python-xpcom. And then I installed python-hulahop and hulahop. * *Downlaod links for these packages are as follows:-* *http://packages.ubuntu.com/en/intrepid/python/python-xpcom* * http://packages.ubuntu.com/en/intrepid/python/python-xpcom** http://packages.ubuntu.com/en/intrepid/hulahop*http://packages.ubuntu.com/en/intrepid/hulahop * **http://packages.ubuntu.com/en/intrepid/python-hulahop* Now, though hulahop was getting imported but while using hulahop.webview, an error saying hulahop has no attribute webview occured. However, when we checked the hulahop folder, there was a file named webview.py, so this problem might be because of some kind of wrongly set library paths. *2. Then we tried it with ubuntu-9.10, with similar steps but got the same result.* for all ubuntu versions before 10.04(10.04 uses debian packages), try sugar repos from http://wiki.sugarlabs.org/go/Community/Distributions/Ubuntu the package is python-hulahop but it supports only 9.10, 9.04, 8.04 not sure if supporting 8.10 makes sense today, since LTS is 8.04 -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] gitorious and uploading public key
(CCed systems@ :) looks like we have porblems in git.sugarlabs.org I've created new project 4 days ago and it's still in creating phase http://git.sugarlabs.org/projects/shell/repos/mainline earlier, it took several minutes to create new project. On Wed, Jan 13, 2010 at 04:20:40PM -0500, Rafael Enrique Ortiz Guerrero wrote: Hi George. (adding sugar-devel to cc) It happen to me also, the solution (IIRC) then was wait, wait, wait. cheers. Rafael Ortiz On Wed, Jan 13, 2010 at 4:15 PM, George Hunt georgejh...@gmail.com wrote: Hi everyone, Earlier I successfully uploaded a public ssh key to git.sugarlabs.org. But then I decided to change key pairs, created a new set, and then tried to upload a the new one. I'm getting the following message: This sshkey is being created, it will be ready pretty soon I came back a day later. Still no joy. Tried again, same response. Any suggestions? George ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] gcompris connect4 locking up / oom'ing
On Thu, Jan 14, 2010 at 02:14:27PM +0100, Martin Langhoff wrote: Hi GCompris devs, I am seeing a problem with gcompris-connect4-12.xo when used on the latest stable version of the XO OS (8.2.1 aka 802). The symptom looks a lot like this libxml2-related bug that appeared in other gcompris components about 16 months ago -- http://dev.laptop.org/ticket/8641 . In fact, if I remove all instances of gt; and lt; from connect4.xml then the activity starts correctly (it later fails, I guess because I have mangled its configuration). Is this a known issue, is there a fix? cheers, Got similar issue, after upgrading libxml it was ok. I'm working on packaging v9 for ASLO and bundles will carry bunch of blobs(v9 uses recent pycairo) and I'll include new libxml as well. The reason to bundle v9(and some its deps) for XO-1, these bundles will be useful on XO-1(in contrast w/ v8): * new v9's goocanvas to speedup redering * optional no-zoom mode to speed up GC * sugar toolbars e.g. it will minimize CPU usage, since UI components will be plain gtk widgets * timing tuning for some dynamic activities (overwise they can brick XO-1) I'm plaing to upload them to ASLO this week. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] gcompris connect4 locking up / oom'ing
On Thu, Jan 14, 2010 at 04:12:11PM +0100, Martin Langhoff wrote: On Thu, Jan 14, 2010 at 3:40 PM, Aleksey Lim alsr...@member.fsf.org wrote: Got similar issue, after upgrading libxml it was ok. Was testing same -- and an update to libxml2-2.7.3-1.fc9 and libxml2-python-2.7.3-1.fc9 (latest in F9 updates) fixes the startup. That's good. I still get Couldn't find the board menu, or plugin execution error and it dies soon after I start using it. I'm working on packaging v9 for ASLO and bundles will carry bunch of blobs(v9 uses recent pycairo) and I'll include new libxml as well. Well, if it works with the libxml2 versions mentioned abouve, you can count on them being on 8.2.2 (but not earlier). Native packages are preferable, if system will have required versions they will be used, in other cases bundled blobs will be used. But all users will download fully bundled .xos since we dont have 0sugar support in shell and people are disagree w/ having activities(that download content on first launch) in existed ecosystem. The reason to bundle v9(and some its deps) for XO-1, these bundles will be useful on XO-1(in contrast w/ v8): When you say XO-1 are you thinking of the 8.2.x OSs, or just the new-gen F11 builds? 8.2 on XO-1 * timing tuning for some dynamic activities (overwise they can brick XO-1) Brick XOs? Do you literally mean brick it, or just crash / OOM? some dynamic games can eat lots of CPU I'm plaing to upload them to ASLO this week. Great - will be trying them out on my 8.2.2 builds if you tell me it's one of the target OSs... yup, it will be targeted to 0.82+ (and for systems that don't have recent pycairo which is required for v9, in fact we have 0.86 systems that are not ready to use v9 as is e.g. Jaunty based distros). -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] gcompris connect4 locking up / oom'ing
On Thu, Jan 14, 2010 at 04:40:50PM +0100, Martin Langhoff wrote: On Thu, Jan 14, 2010 at 4:20 PM, Aleksey Lim alsr...@member.fsf.org wrote: 8.2 on XO-1 Excellent -- thanks! * timing tuning for some dynamic activities (overwise they can brick XO-1) Brick XOs? Do you literally mean brick it, or just crash / OOM? some dynamic games can eat lots of CPU Right -- it'll make the XO unresponsive. When you're in the software/firmware/hardware world, brick means that a bit of hardware has been ruined in (mostly) unrecoverable way. A bogus firmware update would brick your XO for example. Hence my confusion. yup, it will be targeted to 0.82+ (and for systems that don't have recent pycairo Version? heh, at the beginning v9 had pycairo = 1.8 but looks like it was only because of new pycairo's API, for now, v9 works w/ previous API as well. So there are only: * libxml2-2.7.3 * librsvg-2.26.0 * sugar-toolkit(which is not python package but Vala project[1]) * libgee(as a sugar-toolkit's dep) [1] http://git.sugarlabs.org/projects/toolkit -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: User workflow sharing Journal Entries over USB sticks
On Tue, Dec 29, 2009 at 04:12:33PM +0100, Martin Langhoff wrote: On Tue, Dec 29, 2009 at 12:26 AM, Aleksey Lim alsr...@member.fsf.org wrote: I've uploaded patch with minor fixes and delete fix (b0113bf67c31dbeaa08cf0f1710c1be8d02a9b25 should be cherry-picked) Excellent! thanks! Will be re-diffing it a bit later today. to last sucrose-0.84, was backported 0.86 patch (f93c9de3ff6b7d7f1730c5056b0b4fae9f00a201) which prevents any editing of non-ds object, so we need to decide should we rollback this patch at first otherwise we need to remove redundant rename related code from #1636 patch Yes, I actually coded my patches to apply with that patch reverted. Had forgotten about it. I've uploaded sugar-1636-pre.patch with all reverts and cherry patches (be warned, I reverted f93c9de3ff6b7d7f1730c5056b0b4fae9f00a201 patch partially) and reuploaded sugar-1636.patch I have tested this code without those restrictions, and it works well (ie: renames work well...). 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 -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: User workflow sharing Journal Entries over USB sticks
On Mon, Dec 28, 2009 at 07:25:21PM +0100, Martin Langhoff wrote: Aleksey, List, Hope everyone is relaxing, enjoying and not reading the list... if you are... might be the right time to wake up from the excesses of Christmas celebrations :-) Looks like everyone forgot about these patches of mine. I've now posted them as http://bugs.sugarlabs.org/ticket/1636 -- the patches haven't changed but the r? might draw some attention. My old post below is still very relevant, and my notes after it, plus a request for help. On Sat, Dec 5, 2009 at 9:59 PM, Martin Langhoff martin.langh...@gmail.com wrote: I have 4 patches that fix this up so that we DTRT - attached in http://dev.laptop.org/ticket/9657 * 0001-Removable-disk-Save-metadata-and-preview-dlo-9657.patch * 0002-Removable-disk-read-json-formatted-.metadata-and-.pr.patch * 0003-Removable-disk-Handle-renames-dlo-9657.patch * 0004-Removable-disk-delete-preview-and-metadata-dlo-9657.patch With this * We save the files with their correct metadata * Read the metadata back, display it, copy it correctly into the DS, and search descriptions/tags if the user runs a search * Renames and removes are handled correctly on-disk (metadata/preview files are renamed or removed The above approach stems from long discussion in this same thread. If your email proggy doesn't do threads nicely, see http://lists.sugarlabs.org/archive/sugar-devel/2009-November/thread.html#20729 These patches fix the problem in the core code. There are two UI glitches, and I am needing help in sorting them out, 'cause I don't understand the OO-ish approach used in Journal UI. See below: The results are not perfect, as we have UI glitches -- on delete the file listing doesn't remove the file 'collapsedentry'; I've uploaded patch with minor fixes and delete fix (b0113bf67c31dbeaa08cf0f1710c1be8d02a9b25 should be cherry-picked) on rename, the new name is shown until you touch the scrollbar, there it reverts to the old name. to last sucrose-0.84, was backported 0.86 patch (f93c9de3ff6b7d7f1730c5056b0b4fae9f00a201) which prevents any editing of non-ds object, so we need to decide should we rollback this patch at first otherwise we need to remove redundant rename related code from #1636 patch To fix those UI glitches we need to issue a message to the InplaceResultSet instance somehow... except that we don't have a handle to it. I also attempted to do something like http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/b0113bf67c31dbeaa08cf0f1710c1be8d02a9b25 which sure looks right, but didn't work for me. Triggering these actions from the UI widget objects makes it all overly confusing to a newcomer like me. The ocassional dbus message makes it even more entertaining. In any case, the patches bring the backend behaviour to correctness. With some help we can also address the UI glitches (or punt and deal with them with later). and the patches will be soon followed by other patches that allow 0.84 read from 0.82-written USB disks, so that teachers that have saved their files on a USB stick before upgrade can use them. 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 -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Need Live CD to take to Argentina
On Mon, Dec 28, 2009 at 03:47:25PM -0800, Caryl Bigenho wrote: H All i... Did this ever get implemented? If so where do I find it? Are there any special instructions I need to make and use the live CD? Can a usb stick be used for file storage? If you need livecd only because machines don't support boot from usb, http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Blueberry#Boot_Helper and use usb sitck as if you booted from usb(i.e. your system will be located on usb) Otherwise just burn soas's iso to cd and use usb stick as a regular external storage(but there is an issue w/ storing journal objects on external sources, see http://bugs.sugarlabs.org/ticket/1636). http://wiki.sugarlabs.org/go/0.84/Sugar_LiveCD I would like to be able to take several copies with me to give to a tech person at an elementary school in Buenos Aires when I go there in mid-January. Thanks, Caryl ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [IAEP] Sharing work between XOs/SOAS devices
On Tue, Dec 15, 2009 at 12:30:22PM -0500, Gerald Ardito wrote: Hello all. As our 5th graders are doing more and more work with their XOs, their being able to turn in and share their work products (as opposed to collaborating with others) is becoming more and more important. My temporary solution is having them upload their work (along with reflections, if desired) to Moodle, which I can do because we have an XS implementation. However, this means that if a student has created a Memorize vocabulary game that s/he want to share s/he has to: 1. Create the game. 2. Save it to the Journal 3. Go to Browse 4. Navigate to Moodle 5. Find the right course/right assignment within the course 6. Upload game. S/he pretty much has to do the same thing to download and then play other games. This is certainly workable, but dramatically slows down the momentum of creating games and wanting others to play them. So, I am asking to create/offering to help create an Activity that allows users to share work products easily. I know that Bert was working on something called Distribute, which may be a starting place. It seems to share Journal objects, which seems right. I am happy to work with developers on this. I could create requirements, if need be. Just say the word. I look forward to what comes next. Thanks and best, Gerald What do you think about followed workflows, which is preferable 1) user, using search controls, minimize list of entries in Journal bookmark this entirely list(names it) share the whole list(bookmark) user can have several bookmarks other users see that 1st user shared some bookmarks and can open these bookmarks in theirs Journal(it could be separate icon like USB) (bookmarks could be useful not only for sharing) 2) there is no bookmarks user can share any object w/o bookmarking(e.g. by clicking star icon or so) other user see only one list of shared objects -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [IAEP] Sharing work between XOs/SOAS devices
On Tue, Dec 15, 2009 at 02:31:00PM -0500, Gerald Ardito wrote: Aleksey, I think option 1 is good. It keeps the favorites metaphor from elsewhere and allows for the sharing of multiple things at the same time. yeah, I also like 1st case, in fact I tried to implement it in Library-1 but at the end decided to do it in shell(and tried to propose it in two sucrose cycles), but now I'm sure such features should be done out or core, e.g. we can have short development cycle(since its only about implementation of one feature) and several implementation to choose right one. I'm going return to Library and we will have two sharing activities FileShare and Library-2. Thanks. Gerald On Tue, Dec 15, 2009 at 2:22 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Tue, Dec 15, 2009 at 12:30:22PM -0500, Gerald Ardito wrote: Hello all. As our 5th graders are doing more and more work with their XOs, their being able to turn in and share their work products (as opposed to collaborating with others) is becoming more and more important. My temporary solution is having them upload their work (along with reflections, if desired) to Moodle, which I can do because we have an XS implementation. However, this means that if a student has created a Memorize vocabulary game that s/he want to share s/he has to: 1. Create the game. 2. Save it to the Journal 3. Go to Browse 4. Navigate to Moodle 5. Find the right course/right assignment within the course 6. Upload game. S/he pretty much has to do the same thing to download and then play other games. This is certainly workable, but dramatically slows down the momentum of creating games and wanting others to play them. So, I am asking to create/offering to help create an Activity that allows users to share work products easily. I know that Bert was working on something called Distribute, which may be a starting place. It seems to share Journal objects, which seems right. I am happy to work with developers on this. I could create requirements, if need be. Just say the word. I look forward to what comes next. Thanks and best, Gerald What do you think about followed workflows, which is preferable 1) user, using search controls, minimize list of entries in Journal bookmark this entirely list(names it) share the whole list(bookmark) user can have several bookmarks other users see that 1st user shared some bookmarks and can open these bookmarks in theirs Journal(it could be separate icon like USB) (bookmarks could be useful not only for sharing) 2) there is no bookmarks user can share any object w/o bookmarking(e.g. by clicking star icon or so) other user see only one list of shared objects -- Aleksey -- Aleksey ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: 1.5 - gnome-packagekit?
On Mon, Dec 07, 2009 at 07:13:33PM -0500, Reuben K. Caron wrote: In the sugar environment we have the great resource of activities.sugarlabs.org that children can browse through to add new activities. However, on the Gnome side of things we only have the yum terminal commands. While I realize children can add, remove, and install programs using such commands, it is a bit problematic when you don't know the name of what you are searching for or the actual name of the package you want to install or remove. -Should we include gnome-packagekit to provide such functionality? -Or would including it increase the complexities of managing deployments? Since .XO and .XOL bundles were specifically designed to be safe for installation and removal, I'm concerned the inclusion of gnome- packagekit would allow one to more easily break their installation but I also think it would be nice for children to explore the rest of what Fedora has to provide. Regards, Reuben See another attempt, 0install[1]. I implemented initial code for PackageKit integration to 0install, so via 0install user can install native packages(could be useful if your 0install package has dependency like Qt, which could be useful to install from native packages). Having 0install integration to sugar, we have complex approach - let user install: 1) from native packages; 2) 0install packages if software wasn't well packaged; 3) install/build-in-place activity specific binaries(some python activities have C modules). [1] http://wiki.sugarlabs.org/go/Zero_Install_integration [2] http://sourceforge.net/mailarchive/message.php?msg_name=20091204020657.GA25203%40antilopa-gnu -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal behaviour on ext disk: what is sl#1262 about?
On Fri, Dec 04, 2009 at 07:03:53PM +0100, Martin Langhoff wrote: Hi Aleksey, all, I am trying to improve some Journal behaviours re external disks, so trying to understand the logic. Looking at git, dsd recently backported the fix for sl#1262 to 0.84. What is it supposed to do? cheers, Sugar doesn't full support external disks(e.g. writing), so after #1262 patch applied, 0.86 doesn't try to write metadata(like for regular Journal entries) thus doesn't fail. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] The Next Wave of Activity Sharing
On Sat, Jul 25, 2009 at 10:45:32AM +0200, Tomeu Vizoso wrote: [adding IAEP to cc] On Sat, Jul 25, 2009 at 10:09, Bastienbastiengue...@googlemail.com wrote: Joshua Eddy joshuage...@gmail.com writes: This is what Sugar Labs DC wants to bring to the table. For a more detailed description of this idea, please visit my blog: http://joshstechjournal.blogspot.com/ Nice idea! Thanks for sharing it. I presume ideally the config options would offer a website to publish to, along with the Jabber service. I love the idea of having a site for children to share their work, I think this is going to be really big hit for Sugar. Congratulations on taking this task. We have been already discussing this in #sugar during the last week with Jeff and Aleksey and several good ideas were shared, will be nice to put all our thoughts in common when we get to more detail. Everyone is welcome to formalize thoughts on http://wiki.sugarlabs.org/go/Features/Server_Objects_Sharing A somewhat minor concern I have with your proposal is that I'm not sure that just one global server will be enough for everybody. What about areas with local network but none or little internet access? If on the other hand deployments can set their own server as Bastien suggests, how would a child upload to the global one when connection conditions improve? But global server doesn't except local servers think about www.flickr.com - its global option but every community could have local servers. One could imagine that the control panel would allow to set a list of servers and the Publish menu item becomes a submenu where you can select the server to upload to, but things get complicated fast with maybe not too much value. What I would propose instead, based on my experience, is to start by the very basics and build on that after getting some feedback from actual users. I see how a publish menu item in the activity palette or the journal makes it easier than having to go to a specific site in Browse, but if you restrict the modifications at first to Browse, then you can install your new activity version on any existing Sugar version. btw, why just not using Browse, we already do this in case of ASLO is there real need to add additional complexity to sugar UI at least we could start using Browse, get feedback and add new features to 0.88(if its necessary). -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] wrong Activity versions for 8.2(.1) -- Etoys, Memorize, Terminal, Read, others
I guess, its more complex issue then just updating wiki
(btw updating several wikis after bumping new version could be a pain
for activity author).
I think having one method for all distributions to get updates
is much attractive way, so I've proposed it for 0.86 roadmap[1].
[1]
http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Activities_updates
On Sun, May 24, 2009 at 03:56:32AM -0700, S Page wrote:
XO's running 8.2.0 and 8.2.1 (thus Sugar 0.82.1) can use the Software
update control panel to update an activity group of activities and
collections. I believe Software update on 8.2.x determines the latest
versions from http://wiki.laptop.org/go/Activities/G1G1/8.2
Unfortunately these version numbers are independent of the bundles
pointed to by activity pages and their semantic info, let alone newer
versions on http://activity.sugarlabs.org. People recently fixed
Browse, but after running Software update to upgrade my 8.2.1
activities to latest version, I noticed several other discrepancies:
1. Software update doesn't update to latest version for 8.2.
Etoys at 94, but its web page's Activity_version says 98
== Someone should update http://wiki.laptop.org/go/Activities/Etoys_(8.2)
!?
== http://activities.sugarlabs.org/en-US/sugar/addons/versions/4030
is up to 100, but doesn't list a version for Sugar 0.82
Memorize at 28 and its web page's Activity_version says 28, but
http://activities.sugarlabs.org/en-US/sugar/addon/4063 says v.30 works
for Sugar 0.82
== Someone should update
http://wiki.laptop.org/go/Activities/Memorize_(8.2) and
http://wiki.laptop.org/go/Activities/Memorize_(latest)
Read at 56, web page Activity_version says 52 and 61, and
http://activities.sugarlabs.org/en-US/sugar/addons/versions/4028
doesn't list a version for Sugar 0.82.
== What is the latest Read version that works for 8.2.0?
Terminal at 18, but the web page's Activity_version says 19
== Someone should update
http://wiki.laptop.org/go/Activities/Terminal_(8.2) !?
== http://activities.sugarlabs.org/en-US/sugar/addons/versions/4043
doesn't list a version for Sugar 0.82
Turtle Art is at 10, web page doesn't identify a tested release.
http://activities.sugarlabs.org/en-US/sugar/addons/versions/4027 is
all the way to version 51 but doesn't list a version for Sugar 0.82
2. Activity updates to a later version than its wiki.laptop.org web page
IMO just delete redundant and out-of-date info on wiki.laptop.org.
Blank out the activity_version and OBX xobundle info for the activity,
and use
the {{activity migrated to sl.o}} template as Aleksey has been doing.
See http://wiki.laptop.org/go/Maintaining_activity_web_information
Browse at 102, web page Activity_version says its 98
also the web page's lang pootle links redirect to sugarlabs w/ bad
https and broken rewrite
TamTamEdit at 50, Mini at 49, SynthLab at 51; web page
Activity_version versions are 1 less than those.
3. Activities/G1G1/8.2 mis-identifies the version for 8.2 as (latest).
Sometimes http://wiki.laptop.org/go/Activities/G1G1/8.2 has the right
version for 8.2, but misidentifies it as the latest version when
activities.sugarlabs.org has something much more recent. The fix is
to change this page to pull in the (8.2) fragment.
4. I didn't grind through every versions page on
activities.sugarlabs.org. If your activity has a more recent version
than what's listed here that works on 8.2.1/Sugar 0.82, please update
its fragment.
Here's the set of versions on my XO-1 running 8.2.1 after Software update:
Analyze.activity 8
Browse.activity 102
Calculate.activity 25
Chat.activity48
Distance.activity14
Etoys.activity 94
Firefox-6.activity6 (not in Activities/G1G1)
Help.activity10
Implode.activity 5
Log.activity 16
Maze.activity 6
Measure.activity 21
Memorize.activity28
Moon.activity10
Paint.activity 23
Pippy.activity 30
Read.activity56
Record.activity 59
Ruler.activity3
Scratch.activity 12
Speak.activity9
TamTamEdit.activity 50
TamTamJam.activity 51
TamTamMini.activity 49
TamTamSynthLab.activity 51
Terminal.activity18
TurtleArt.activity 10
WikipediaEN.activity 4
Write.activity 60
5. There are many other activities not part of the G1G1 activities
group that are out-of-date on wiki.laptop.org. For example,
Colors! web page Activity_version says its 13, but
http://activities.sugarlabs.org/en-US/sugar/addons/versions/4050 says
version 15 is latest. Again, I think blanking it out and indicated
the version for Sugar 0.82 on Activities.sugarlabs.org's See All
Versions is the way to go.
Cheers,
--
=S Page
___
Sugar-devel
Migrate Paint to git.sl.o
Hi all, If anyone don't mind, I'm migrating Paint(Oficinia) to git.sl.o. Someone who's interested in developing this activity let me know and I'll add you to commiters list or change ownership. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Migrate Record to git.sl.o
- Forwarded message from Aleksey Lim alsr...@member.fsf.org - From: Aleksey Lim alsr...@member.fsf.org Subject: [Sugar-devel] Migrate Record to git.sl.o To: sugar-de...@lists.sugarlabs.org Date: Fri, 17 Apr 2009 12:19:21 + Hi all, If anyone don't mind, I'm migrating Record to git.sl.o. Someone who's interested in developing this activity let me know and I'll add you to commiters/change ownership. -- Aleksey ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel - End forwarded message - -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Sugar-devel] Migrate StoryBuilder to git.sugarlabs.org
Hi all, StoryBuilder's repo was moved to git.sugarlabs.org http://git.sugarlabs.org/projects/story-builder-branch -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[ANNOUNCE] Migrate HelloMesh to git.sugarlabs.org
Hi all, HelloMesh's repo was moved to git.sugarlabs.org http://git.sugarlabs.org/projects/hello-mesh -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[ANNOUNCE] Migrate JokeMachine to git.sugarlabs.org
Hi all, JokeMachine's repo was moved to git.sugarlabs.org http://git.sugarlabs.org/projects/joke-machine-branch -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[ANNOUNCE] Migrate SliderPuzzle to git.sugarlabs.org
Hi all, SliderPuzzle's repo was moved to git.sugarlabs.org http://git.sugarlabs.org/projects/slider-puzzle-branch -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[ANNOUNCE] Migrate JigsawPuzzle to git.sugarlabs.org
Hi all, JigsawPuzzle's repo was moved to git.sugarlabs.org http://git.sugarlabs.org/projects/jigsaw-puzzle-branch -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
CartoonBuilder moved to git.sugarlabs.org
Hi all, CartoonBuilder moved to git.sugarlabs.org -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Flipsticks moved to git.sugarlabs.org
Hi all, Flipsticks moved to git.sugarlabs.org -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
