Re: [Sugar-devel] [GIT] how to add an admin?
On Mon, Sep 21, 2009 at 12:09:53PM -0500, Felipe López Toledo wrote: > Hi guys > does anyone know how to grant admin/owner privileges on a git project to a > contributor user? > -- > Felipe López Toledo AFAIK in gitorious, only one user can have admin privileges, so you can just pass ownership. Create ticket on bugs.sugarlabs.org for component git.sugarlabs.org or ping bernie or lfaraone on #sugar. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] hard code freeze exceptions
On Tue, Sep 22, 2009 at 04:54:44PM +0200, Tomeu Vizoso wrote: > Hi, > > we have these tickets in the review queue currently marked for 0.86: > > #1339 After download, 'Show in Journal' option doesnt switch you to the > Journal > #1342 range queries use lexical comparison, not numerical > #1410 Progress bar for reading volumes appears only once > #1412 Progress bar for reading volumes nevers stops if can't read all > volume entries > #1411 Do not start title editing for non-ds objects > #1404 metadatareader: error return without exception set > > Do we agree these are critical enough to be pushed now for 0.86.0? > Otherwise, they will be in 0.86.1. We can discuss these(and new) patches during devel meeting. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Signed updates for Sucrose-0.86
Hi all, For now, all bundles aren't signed but in new Sucrose-0.86 updater control component was introduced(which is based on updater component from OLPC but doesn't use bitfrost). Sucrose updater just fetches metadata from ASLO[1] and download proper xo bundles. So, the question is, should secure updates from ASLO be a blocker for 0.86 release(it could be https:// access for metadata or signed metadata updates or so). [1] http://activities.sugarlabs.org/services/update.php?id=org.laptop.WebActivity&appVersion=0.84 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.86.0
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.86.0.tar.bz2 == News == * fix 'error return without exception set' on ARM (#1404) * eliminate incorrect warning about unknown search terms (#1363) * Fix AUTHORS file * Add AM_MAINTAINER_MODE macro to configure.ac ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.86.0
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.86.0.tar.bz2 == News == * Do no fail on system activities in Home view #1427 * Remove duplicate string #1413 * Use correct color when resuming an entry from the favorites view #1397 * Progress bar for reading volumes nevers stops if can't read all volume entries #1412 * Error while deleting non-ds objects from Journal #1415 * Progress bar for reading volumes appears only once #1410 * After download, 'Show in Journal' option doesnt switch you to the Journal #1339 * Ignore data/sugar-emulator.desktop * Handle situations where keyboard model is stored as '' or None. Completes dslo #1341 * Create ~/Activities if it doesn't exist yet #1400 * Remove remaining .xo files from cancelled updates #1399 * Invisible downlading progress bar in Journal #1388 * Implement functionality of the cancel button #1361 * Don't automount all the volumes at startup #1357 * Use default extension if needed #1253 * Create new activity_id if the entry lacks one #1276 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] how to pick older version of an activity for a custom sugar spin
On Mon, Sep 28, 2009 at 06:17:59PM +0800, Hamilton Chua wrote: > Hello, > > I am creating custom spins from strawberry branch with sugar 0.84 and I > have modified the kickstart file (soas-sugar.ks) to get the latest > versions of the activites from activities.sugarlabs.org. > > The problem is that some of the latest activities are no longer > compatible with 0.84 and now work with 0.86. > > Is there a way for me to tell the kickstart file to get to 0.84 > compatible version of the activity instead of the latest version of the > activity? For now, SugarPlatform version is hardcoded in .ks, see http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-aslo-and-content.ks#line61 so, you just need to change it to 0.84 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-pippy dependencies
On Mon, Sep 28, 2009 at 09:33:17PM -0400, Bernie Innocenti wrote: > Hello, > > the sugar-pippy rpm in Fedora depends on pygame, which is used by some > of the examples. > > So far, so good, but pygame in turn depends on numpy, a 7.7MB package > which a lot of huge dependencies such as atlas (11MB), libgfortran > (1MB), blas (700KB) and python-nose (1MB). > > The rest of Sugar is now free of numpy, so it would be good if we could > get rid of it completely. One quick solution would be splitting the > problematic examples to a sugar-pippy-examples-extra package. > > Another possibility -- probably the cleanest -- would be splitting the > optional classes surfarray and sndarray to a subpackage of pygame. pygame and numpy are parts of Sugar Platform[1], at least for 0.84, so, the right question is should these pakcages be a part of SP-0.86 I guess +1 for both, since we have honey activities that are depend on these packages. [1] http://wiki.sugarlabs.org/go/0.84/Sugar_Platform -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-pippy dependencies
On Tue, Sep 29, 2009 at 12:36:19PM +, Aleksey Lim wrote: > On Mon, Sep 28, 2009 at 09:33:17PM -0400, Bernie Innocenti wrote: > > Hello, > > > > the sugar-pippy rpm in Fedora depends on pygame, which is used by some > > of the examples. > > > > So far, so good, but pygame in turn depends on numpy, a 7.7MB package > > which a lot of huge dependencies such as atlas (11MB), libgfortran > > (1MB), blas (700KB) and python-nose (1MB). > > > > The rest of Sugar is now free of numpy, so it would be good if we could > > get rid of it completely. One quick solution would be splitting the > > problematic examples to a sugar-pippy-examples-extra package. > > > > Another possibility -- probably the cleanest -- would be splitting the > > optional classes surfarray and sndarray to a subpackage of pygame. > > pygame and numpy are parts of Sugar Platform[1], at least for 0.84, > so, the right question is should these pakcages be a part of SP-0.86 > I guess +1 for both, since we have honey activities that are depend on > these packages. But if question is only about Pippy deps, jhconvert's Pippy doesn't have these deps(sugar-platform does). > [1] http://wiki.sugarlabs.org/go/0.84/Sugar_Platform -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Content of new SugarPlatform-0.86
Hi all, We have 0.86 release, so we need new SugarPlatform specification. New wiki page[1] is just copy&past of SP-0.84 page, so any improvements are welcome. [1] http://wiki.sugarlabs.org/go/0.86/Platform_Components -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.86 plans
On Tue, Sep 29, 2009 at 11:06:56AM -0400, Walter Bender wrote: > I am planning to blog about the plans for 0.86 in the various distros. > In order to ensure I get my facts straight, I am asking that those of > you involved in packaging please send me a sentence or two describing > your targets. Some info could be taken from http://wiki.sugarlabs.org/go/Development_Team/Packaging -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Wiki] Reorganize sugar download pages
Hi all, For now we have three wiki pages to get download info: * http://wiki.sugarlabs.org/go/Downloads * http://wiki.sugarlabs.org/go/Supported_systems * http://wiki.sugarlabs.org/go/Development_Team/Packaging That could be confusing, so maybe having one page for users who want only stable releases/ways-to-run-sugar and another page for developers and experienced users? In my mind http://wiki.sugarlabs.org/go/Supported_systems is redundant - all info from that page could be moved to per-distro pages? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.86 plans
On Tue, Sep 29, 2009 at 11:06:56AM -0400, Walter Bender wrote: > I am planning to blog about the plans for 0.86 in the various distros. > In order to ensure I get my facts straight, I am asking that those of > you involved in packaging please send me a sentence or two describing > your targets. Among jhconvert's official repos, Mandriva: 0.86 was packaged to development repository and will be in the next 2010.0 release(2009-11-03) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-pippy dependencies
On Tue, Sep 29, 2009 at 04:10:39PM -0400, Bernie Innocenti wrote: > El Tue, 29-09-2009 a las 12:36 +0000, Aleksey Lim escribió: > > pygame and numpy are parts of Sugar Platform[1], at least for 0.84, > > so, the right question is should these pakcages be a part of SP-0.86 > > I guess +1 for both, since we have honey activities that are depend on > > these packages. > > In Sugar shell 0.82, the only thing that numpy was providing was a bit > matrix. In 0.82, we replaced it with faster and lighter C code in > sugar-base, and it was a big performance win. > > I suspect the #1 usecase for numpy is to compensate for lack of good > array support in Python. > > > Questions: > > 1) are there lighter-weight alternatives for the most popular uses of > numpy? > > 1) how many of the existing activities actually depend on numpy? In my case, ~60 ASLO's activities: * Measure * Speak(and Memorize since it has Speak's code) * olpcgames(FoodForce2, story-builder, falabracman, Maze) > 2) would it be hard to remove this dependency from them? Not sure about 0.86(we need, at least, fix existed activities) and I'm not sure at all about activities that are out of ASLO. > 3) Should we define a policy for deprecating components of the Sugar > Platform in new revisions? All evolving standards need to find a > balance between new features with old feature removal to avoid unbounded > bloat. Thats a good idea anyway, policies for inclusion/exclusion components from/to SP, so we have first precedent.. > 4) Even if numpy is going to stay around for the Sugar Platform, could > we remove it from Pippy and other core activities to save resources and > allow shipping lighter weight live distros? In case if have numpy in Pippy, in my mind it doesn't make much sense in having two Pippies: * developers(and experienced users) are aware of such things(and they don't need Pyppy installed from packages - in most cases they don't use Pippy at all or use git repo). * end users, in most cases, will use sugar-platform meta package thus will have numpy anyway -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Test ballot complete. Feedback
On Tue, Sep 29, 2009 at 06:02:22PM -0500, David Farning wrote: > I would like to announce the completion of the Sugar Labs Test Election. > > Know issues: > The election server is very overloaded. It was not uncommon for the > server to take a minute or more to process a a submission. As far as > I can tell everyones vote was processed. Please keep track of your > 'token' so you can verify that you vote has been processed correctly. > > The test election was mis-configured to run until October 28 instead > of September 28. I will verify that the SLOBs election is configured > correctly. > > Incorrect email on membership roster. I received one notice that > someone did not receive a voter token. I will verify their name > against the membership log and update the email roster list as > necessary. > > Does anyone else have feedback on the test election? Please submit > that feedback to this list or to me personally. > > David Farning > SLOBs election 2009-2010 referee > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > Didn't get any feedback and voter tokens on my email to members@ as well. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.86.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.86.1.tar.bz2 == News == * Screenshot file is not deleted #1445 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] bug in record version 64
On Mon, Oct 05, 2009 at 11:35:22AM -0300, Bruno Fabiano wrote: > image gets stucked while reproducing a video in the 2 new qualities. > when i try to delete a video system reboots. What hardware(XO?) and sugar(0.86?) platform you are using? I'm planing to inspect all honey activities(and Record), I have commit access to, next week. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: [Marketing] 2009 Free Software Awards
On Fri, Oct 09, 2009 at 08:17:00AM +1300, Tim McNamara wrote: > 2009/10/8 Rafael Enrique Ortiz Guerrero > > > fyi ..Sugar or it's representative should be nominated :). > > > > http://www.fsf.org/news/2009FSAwardsCall > > > > > Hi all, > > Apologies for my lack of knowledge. Does Sugar contain any non-free > components? afaik nope, at least for Sugar Platform otherwise trisquel people should blame us :) http://trisquel.info/en/trisquel-sugar > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New Sugar theme for Activity Library
Hi all, Josh Williams finished new Sugar theme for Activity Library(ASLO), please test it from [1]. Thanks Josh, it looks awesome. In several days ASLO code base will be rebased to last AMO, (it should give us new AMO features like tagging and new developers UI) and new theme will appear on the main site. [1] http://activities-devel.sugarlabs.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Olpc-france] Demande d'information technique sur Sugar
On Fri, Oct 09, 2009 at 01:34:03PM +0200, s.bouta...@free.fr wrote: > Hi, > > Selon Elena of Valhalla : > > > 2009/10/9 Sean DALY : > > > Here's a question from France: can Sugar run over an ARM processor? > > > > > > Mathieu says Debian might do so. > > > > > > Any information appreciated. > > > > I'm working on OpenEmbedded recipes to be able to build sugar for > > various devices, including many ARM based ones, but it's taking quite > > some time; I can't say when it will be working seamlessy. > > > > Currently the best way to have sugar running will probably be using > > debian, and of course there will be issues with binaries in the > > activities. > > Sugar does runs on other architecturs too: as on the Yeeloong and the Gdium > laptops, both using an mips processor. Here, a Yeeloong launchs Sugar, > however, > du to dependencies issues, it's not yet usable. We are using the binaries > provided by the official repositories. On could use the jhbuild method too. > > On the Gdium, shipped with Mandriva, we are trying to achieve the same result, > but the jhbuild process fails early. > > As for the arm target, it appears to be a promissing platform, as a few arm > notebooks/netbooks are announced in the next monts or are already available. > Consequently, trying to port Sugar on those platforms will certainly be worth > the effort. I packaged 0.84 to CaixaMagica12 [1] wich is Mandriva2008 based distro, had to backport bunch of packages [2].. [1] http://wiki.sugarlabs.org/go/Community/Distributions/Magalh%C3%A3es [2] http://git.sugarlabs.org/projects/magalhaes -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Sugar theme for Activity Library
On Fri, Oct 09, 2009 at 07:08:52AM -0300, Gonzalo Odiard wrote: > I can't test in the new version , but in the actual spanish version, the > links form Developers panel to activity page is > http://activities.sugarlabs.org/es-ES/sugar/firefox/addon/4212 when must be > http://activities.sugarlabs.org/es-ES/sugar/addon/4212 Could you post exact url where you found "firefox" link. I checked it on http://activities.sugarlabs.org/es-ES/developers/addon/edit/4212 in en/es and it contains correct links. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Tue, Oct 13, 2009 at 12:39:59AM -0400, Bernie Innocenti wrote: > Dear Zero Install developers, > > as you may know, Sugar is a learning environment consisting of > educational activities packaged and distributed as "bundles", which are > some kind of glorified zip files. > > This design was chosen because we wanted to enable our learners to > participate in the creation of new activities using our stack. > Secondarily, our security model benefits from unprivileged installation. > > Unfortunately, our activity bundle format is very limited: no > dependencies, no multi-arch build system, no signature checking, weak > versioning model, no concept of source bundles, and general immaturity > of the toolset. On the other hand, most (but certainly not all) our > activities happen to be simple, "Pure Python" applications with no need > for the complexity of a full-blown packaging discipline. Most of us like > this simplicity and wish to retain it. Nevertheless, now that Sugar runs > on multiple architectures and OSes, these limitations are starting to > chafe. > > Zero Install appears to have identified reasonable compromises for many > of these trade-offs. While I'm not yet claiming that z-i would be a > better alternative for us to pick off the shelf, there's certainly a lot > of experience within your community to learn from. > > Also, I understand from previous discussions [1] that hosting for > package repositories would be helpful to you. I think we could help out > by sharing our bandwidth and disk space. Sounds like an interaction in > which both sides have something useful to give :) > > How about getting together on IRC to exchange ideas regarding packaging > strategies? I'd propose next Saturday @ 1500UTC [2], of course > negotiable. > > [1] http://article.gmane.org/gmane.comp.file-systems.zero-install.devel/2753 > [2] > http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=17&year=2009&hour=11&min=0&sec=0&p1=43 I'm personally +1024 for 0install integration(and even in 0.88 cycle), in my mind it could be good way to fix blobs and non-SP dependencies issue, so * our pure python bundles is preferable way to deploy activities (0install syntax could be optional) * there is tendency to integrate sugar to regular desktops, so we don't have to package all non-sugar software, just a way to resolve unique dependencies and provide binaries for several architectures(which is related to 1st point) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Conozco Uruguay-7
On Tue, Oct 13, 2009 at 03:07:59PM -0400, Caroline Meeks wrote: > I just got a 404 error when I tried to download this onto a Sugar VM from > a.sl.o > > On Mon, Oct 12, 2009 at 4:32 PM, Sugar Labs Activities < > activit...@sugarlabs.org> wrote: > > > Activity Homepage: > > http://activities.sugarlabs.org/addon/4199 > > > > Sugar Platform: > > from 0.82 to 0.86 > > > > Download Now: > > http://activities.sugarlabs.org/downloads/version/29277 > > > > Release notes: > > > > > > Reviewer comments: > > This request has been approved. > > > > Sugar Labs Activities > > http://activities.sugarlabs.org > > > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > Looks like we have permitions issue, ASLO can't push new .xos to to /upload/activities. Can someone chown /upload/activities and rsync /upload/activities from /srv/www-sugarlabs/activities/files. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [ASLO] Release Conozco Uruguay-7
On Wed, Oct 14, 2009 at 08:53:05PM +, Aleksey Lim wrote: > On Tue, Oct 13, 2009 at 03:07:59PM -0400, Caroline Meeks wrote: > > I just got a 404 error when I tried to download this onto a Sugar VM from > > a.sl.o > > > > On Mon, Oct 12, 2009 at 4:32 PM, Sugar Labs Activities < > > activit...@sugarlabs.org> wrote: > > > > > Activity Homepage: > > > http://activities.sugarlabs.org/addon/4199 > > > > > > Sugar Platform: > > > from 0.82 to 0.86 > > > > > > Download Now: > > > http://activities.sugarlabs.org/downloads/version/29277 > > > > > > Release notes: > > > > > > > > > Reviewer comments: > > > This request has been approved. > > > > > > Sugar Labs Activities > > > http://activities.sugarlabs.org > > > > > > ___ > > > Sugar-devel mailing list > > > Sugar-devel@lists.sugarlabs.org > > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > Looks like we have permitions issue, > ASLO can't push new .xos to to /upload/activities. > Can someone chown /upload/activities and rsync /upload/activities from > /srv/www-sugarlabs/activities/files. It should work now for new and old .xos. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: > [cc += dfarning, alsroot, syst...@] > > El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: > > I've made some bug fixes to the new ASLO design, I've tested it lightly > > and it seems to work in all major browsers (even ie6). If you have a few > > moments, please test it out (download/upload activities, browse around) > > and let me know if you see any display bugs or major usability issues. > > > > http://activities-devel.sugarlabs.org/en-US/sugar/ > > All links to activity bundles appear to be broken :-( > For example: > > > http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail > > I'm not sure how to fix it, but I can imagine that it may be related > with moving the activity bundles from their old location > (/srv/www-sugarlabs/activities/files) to the upload directory > (/srv/upload/activities/) done by Dfarning in order to enable > Mirrorbrain. > > Earlier today, alsroot asked me to fix some permission issues that would > prevent aslo from writing new activities in the new location. Thats intended to be so, activities-devel is just mysql copy of activities, I thought, it shouldn't affect activities-devel testing(but you can create new activity/version and it should be downloaded). > also noticing that there's still a copy of the activities in the old > location, and it is also bigger by 40MB! Thats because /srv/www-sugarlabs/activities/files contains some tmp directory, it shouldn't affect .xo downloading. > /me is very confused :-/ > > Could anyone who was involved please write a short description of what > was changed exactly? I'm only trying to reconstruct the current > situation, not looking for a scapegoat. We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. For now we have two independent sources for .xo downloads: * /srv/www-sugarlabs/activities/files for not public activities and for 30min age public activities * mirrored /upload/activities for all public activities, after making new .xo public, ASLO uploads it to /upload/activities > Hmm... well, perhaps we can learn something from this accident: > > The classic way to avoid the "too many cooks" syndrome would be to > appoint a single official maintainer and make all the change requests go > through him. However, I feel this "solution" would create lots of > critical roles and ultimately defeat our ongoing attempts to > decentralize system administration. > > Instead, we shall establish simple procedures to improve sysadmin > coordination and communication. For example: > > 1) commit configuration changes in git along with a short description >of what was done and why. We already have repositories for /etc and >also and we could create more repos as needed; Yeah, for now, ASLO configs are stored only in ~activities/site/app/config > 2) write a short report for systems@ when we make substantial changes >to a service; > > 3) write or update the wiki documentation for important sysadm >procedures such as installing a new instance of a service > > Use your common sense to decide what needs to be documented and how much > detail is needed. At all costs, we want to avoid putting too much > bureaucratic burden on volunteers because it's the most effective way to > make them look for something more exciting to do. > > We could save time by coalescing steps (1) and (2): all we need to do is > enabling a post-commit hook in the repositories that would send patches > to systems-logs@ . We need to be extra careful not to expose passwords > in this way. Any volunteers to write and test this procedure? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 07:34:50AM +, Aleksey Lim wrote: > On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: > > All links to activity bundles appear to be broken :-( > > For example: > > > > > > http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail > > > > I'm not sure how to fix it, but I can imagine that it may be related > > with moving the activity bundles from their old location > > (/srv/www-sugarlabs/activities/files) to the upload directory > > (/srv/upload/activities/) done by Dfarning in order to enable > > Mirrorbrain. > > > > Earlier today, alsroot asked me to fix some permission issues that would > > prevent aslo from writing new activities in the new location. > > Thats intended to be so, activities-devel is just mysql copy of > activities, I thought, it shouldn't affect activities-devel testing(but > you can create new activity/version and it should be downloaded). I've just symlinked /upload/activities to /srv/www-sugarlabs/activities-devel/files, so now it shouldn't confuse activities-devel testers. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 07:34:50AM +, Aleksey Lim wrote: > On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: > > [cc += dfarning, alsroot, syst...@] > > > > El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: > > > I've made some bug fixes to the new ASLO design, I've tested it lightly > > > and it seems to work in all major browsers (even ie6). If you have a few > > > moments, please test it out (download/upload activities, browse around) > > > and let me know if you see any display bugs or major usability issues. > > > > > > http://activities-devel.sugarlabs.org/en-US/sugar/ > > > > All links to activity bundles appear to be broken :-( > > For example: > > > > > > http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail > > > > I'm not sure how to fix it, but I can imagine that it may be related > > with moving the activity bundles from their old location > > (/srv/www-sugarlabs/activities/files) to the upload directory > > (/srv/upload/activities/) done by Dfarning in order to enable > > Mirrorbrain. > > > > Earlier today, alsroot asked me to fix some permission issues that would > > prevent aslo from writing new activities in the new location. > > Thats intended to be so, activities-devel is just mysql copy of > activities, I thought, it shouldn't affect activities-devel testing(but > you can create new activity/version and it should be downloaded). > > > also noticing that there's still a copy of the activities in the old > > location, and it is also bigger by 40MB! > > Thats because /srv/www-sugarlabs/activities/files contains some tmp > directory, it shouldn't affect .xo downloading. > > > /me is very confused :-/ > > > > Could anyone who was involved please write a short description of what > > was changed exactly? I'm only trying to reconstruct the current > > situation, not looking for a scapegoat. > > We just tried to utilize AMO feature when it lets user download > public .xos from mirror sources and from files/ for other cases. > Recently all .xo were downloaded from files/(even after creating symlink > in /upload to files/).. and it was done from several attempts. > > For now we have two independent sources for .xo downloads: > * /srv/www-sugarlabs/activities/files for not public activities > and for 30min age public activities > * mirrored /upload/activities for all public activities, > after making new .xo public, ASLO uploads it to /upload/activities > > > Hmm... well, perhaps we can learn something from this accident: > > > > The classic way to avoid the "too many cooks" syndrome would be to > > appoint a single official maintainer and make all the change requests go > > through him. However, I feel this "solution" would create lots of > > critical roles and ultimately defeat our ongoing attempts to > > decentralize system administration. > > > > Instead, we shall establish simple procedures to improve sysadmin > > coordination and communication. For example: > > > > 1) commit configuration changes in git along with a short description > >of what was done and why. We already have repositories for /etc and > >also and we could create more repos as needed; > > Yeah, for now, ASLO configs are stored only in > ~activities/site/app/config hmm.. but what about passwords in ASLO configs > > > 2) write a short report for systems@ when we make substantial changes > >to a service; > > > > 3) write or update the wiki documentation for important sysadm > >procedures such as installing a new instance of a service > > > > Use your common sense to decide what needs to be documented and how much > > detail is needed. At all costs, we want to avoid putting too much > > bureaucratic burden on volunteers because it's the most effective way to > > make them look for something more exciting to do. > > > > We could save time by coalescing steps (1) and (2): all we need to do is > > enabling a post-commit hook in the repositories that would send patches > > to systems-logs@ . We need to be extra careful not to expose passwords > > in this way. not sure, ASLO configs could be not obvious for others, so we need explanation in email anyway. >> Any volunteers to write and test this procedure? > > Well, we don't need such ASLO specific administration 24x7, most of time > it could be just regular file-permissions/apache/etc administration. Maybe just reuse issue tracker, I mean it could be a good way from decentralization pov and all interested people can subscribe to bugs.sl.o email notifications. So all administration related tasks(not only ASLO) could be requested on bugs.sl.o at first. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Memorize 33 is buggy - what should I do?
On Thu, Oct 15, 2009 at 10:38:03PM -0400, Caroline Meeks wrote: > I doubt this is a SoaS only problem but I haven't tested it on an XO > > Tickets - 1055 I'm going to test Memorize in last soas2(12-Oct-2009) #1055 is about pulseaudio issue, maybe in last soas it will be better > , 1503 > > 1503 is a total blocker for using Memorize and 1055 is going to give me hell > in the field trying to get kids not clear that inviting face. #1503 looks weird, telepathy signals don't work... trying to investigate -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.86.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.86.3.tar.bz2 == News == * Sporadic freezes while scrolling journal #1506 * Suppress race condition with Journal appearing on sugar startup #1373 * Alt+Space not working to show/hide the tray #1476 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.86.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.86.2.tar.bz2 == News == * Do not stop processing motion-notify-event #1507 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Memorize 33 is buggy - what should I do?
On Fri, Oct 16, 2009 at 09:12:24AM +, Aleksey Lim wrote: > On Thu, Oct 15, 2009 at 10:38:03PM -0400, Caroline Meeks wrote: > > I doubt this is a SoaS only problem but I haven't tested it on an XO > > > > Tickets - 1055 > > I'm going to test Memorize in last soas2(12-Oct-2009) > #1055 is about pulseaudio issue, maybe in last soas it will be better Caroline, could you test last soas(in my case it sounds more smooth) > > , 1503 > > > > 1503 is a total blocker for using Memorize and 1055 is going to give me hell > > in the field trying to get kids not clear that inviting face. > > #1503 looks weird, telepathy signals don't work... trying to investigate and Memorize-34 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO updates
On Fri, Oct 23, 2009 at 03:30:08PM -0700, Josh Williams wrote: > Updates have been made to ASLO, I'm sure there are display bugs floating > around because a lot of the code was changed. Please take a few minutes > to test it out: > > http://activities-testing.sugarlabs.org/en-US/sugar/ > > If you're an activities developer, please check out the developers hub > to check for errors (btw, I haven't made all of the branding changes > yet, please just check for display errors): > > http://activities-testing.sugarlabs.org/en-US/developers just encontered, wrong paging in Browse and Firefox -- Aleksey <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO testing
On Mon, Oct 26, 2009 at 01:42:50PM -0700, Josh Williams wrote: > If you have a minute please test: > > http://activities-testing.sugarlabs.org/en-US/sugar/ > > Bugs fixed since last round of testing: > > 1. # of Activities downloaded number added > 2. Fixed pagination for long search results > 3. Fixed user profile section > 4. cleaned up a few general typographical inconsistencies > > Thanks, > > Josh > Another issue, inconsistence in translation input box.. -- Aleksey <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO testing
On Mon, Oct 26, 2009 at 01:42:50PM -0700, Josh Williams wrote: > If you have a minute please test: > > http://activities-testing.sugarlabs.org/en-US/sugar/ > > Bugs fixed since last round of testing: > > 1. # of Activities downloaded number added > 2. Fixed pagination for long search results > 3. Fixed user profile section > 4. cleaned up a few general typographical inconsistencies > > Thanks, > > Josh > overlapping and selcolor in dev menu on http://activities-testing.sugarlabs.org/en-US/developers/addon/edit/4055/ -- Aleksey <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Activity Library v4
== News ==
* rebase to last AMO code base
* new sugar theme
== News for users ==
* revert fast link to global statistics
http://activities.sugarlabs.org/en-US/statistics
(click on "activities downloaded" at the right top corner on main page)
* bar with links to common sugar resources at the left top corner on
main page (analog of http://www.sugarlabs.org/ links bar)
* vote for particular collection
* attach personal tags to activities
(on left sidebar, click "Add a tag" button)
== News for activity developers ==
* New developers UI
http://activities.sugarlabs.org/developers
* per activity developer profile
("Developer Profile" button in edit menu)
* attach default tags to activities
("Tags" button in edit menu)
* see recent activity for particular activity
("Recent Activity" button in edit menu)
== News for editors ==
* promo box was disabled for this release
(will be sugarized and enabled for next release)
* editors can black list tags
(http://activities.sugarlabs.org/sugar/admin/tags)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Submitting New Activities
On Sat, Oct 31, 2009 at 08:32:49PM -0400, Art Hunkins wrote: > David, > > Thanks for the fast response. > > Attached is a zip archive that contains both Activities - > OurMusic.activity and OurMusicMC.activity. as was already said, you need to uplaod .xo (which was created by setup.py), I uploaded your two activities to http://activities-testing.sugarlabs.org/ w/o errors could you post .xo bundles that you tried to upload. > The latter is a Multiple (MIDI) Controller version of the former. > OurMusic works with .82 on up; OurMusicMC only works on .86. > > The brief descriptions are already posted at Gitorious. > > Art Hunkins > > - Original Message - From: "David Farning" > > To: "Art Hunkins" > Cc: > Sent: Saturday, October 31, 2009 7:33 PM > Subject: Re: [Sugar-devel] Submitting New Activities > > > >Art, > > > >Will you send me a copy of what you are trying to upload to. Aleskey > >merged against amo last night. I'll see what I can find. > > > >thanks > >david > > > >On Sat, Oct 31, 2009 at 6:27 PM, Art Hunkins wrote: > >>After getting good help in pushing my new activities (Our Music, and Our > >>Music MC) to Gitorious thanks to Gary and Wade (many thanks, guys), I've > >>been trying to upload them through the SugarLabs Developer Hub. > >> > >>I'm having trouble. When I do my upload as a .zip archive, I get > >>the message > >>that only .xpi, .xml, and .jar file types are allowed. (As a > >>Windows person, > >>these types are fairly unknown to me.) last AMO has different gettext msgid strings and ASLO could have some missed translations, I fixed message you mentioned. > >>When I upload an Activity as an .xo bundle, I get an exotic > >>"error on page" > >>message, with no acknowledgement that the attempt was successful. > >> > >>These are the only two formats (.zip and .xo, actually virtually > >>the same) > >>in which I know to upload an activity. > >> > >>What to do? > >> > >>Art Hunkins > >> > >>___ > >>Sugar-devel mailing list > >>Sugar-devel@lists.sugarlabs.org > >>http://lists.sugarlabs.org/listinfo/sugar-devel > >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Submitting New Activities
On Mon, Nov 02, 2009 at 09:31:45AM -0500, Art Hunkins wrote: > Attached are the two .xo bundles. > > BTW, I created them manually - not with the help of setup.py. Yeah, that was the problem, valid .xo bundles should contain directory w/ activity name on top of files hierarchy, anyway the best option is creating .xo bundles with setup.py. > That > could be the problem, though I don't think so. Please let me know. btw ASLO says on uploading attached bundles: Oops! There seems to be a problem with this file... The activity bundle must contain a file named activity/activity.info Please correct this problem and upload your file again. I guess "activity/activity.info" could be confused, since it means "/activity/activity.info", I'll tune error message -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Submitting New Activities
On Mon, Nov 02, 2009 at 08:36:51PM -0500, Art Hunkins wrote: > Aleksey, > > I made the change you suggested, as in the attached .xo. > > I still was unable to upload, receiving the same message "error on > page". The "error log" is not at all helpful; I uploaded in Win XP, > and the message you indicated did not at all come through. Are you using firefox under winxp? I don't have win*, so I can't test it > I uploaded with the following archive names: OurMusicMC-1.xo, > ourmusicmc-1.xo, OurMusicMC.xo and ourmusicmc.xo. Same result for > each. but anyway if you are trying to upload new activity it should be failed since there are already both these activities(I guess David uploaded them), so use http://activities.sugarlabs.org/en-US/developers/versions/4226/ http://activities.sugarlabs.org/en-US/developers/versions/4227/ to manage versions for these activities(if you want to reupload existed version, you need to delete that version first) I tried to upload your attached bundle and it didn't fail. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Submitting New Activities
On Mon, Nov 02, 2009 at 11:18:21PM -0500, Art Hunkins wrote: > All is good now. > > Prior to this evening, "Our Music MC" was not showing up as an > activity for me. (I appreciate David having uploaded both > activities, and am sorry the "MC" version was late appearing.) Now > it is "here", and I have completed its presentation (having learned > in the meantime how to take snapshots!) > > FYI: I'm using IE8 in Windows as a browser. dunno about ie and windos, while merging AMO I can't test it > It might be helpful on the initial commit/upload page in the > developers hub to state that the "Activity file" should be an .xo > bundle, and that its top directory should be (blah, blah). And > perhaps give the OLPC link telling how to make bundles. That would > sure have been helpful to me. already done :) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] pippy woes
On Tue, Nov 03, 2009 at 03:27:13PM +, Daniel Drake wrote: > Hi, > > Latest pippy on activities.sugarlabs.org is v35, but the latest one in > git is v34. Please could git be updated? > > activities.sugarlabs.org says that pippy v35 is only for Sugar v0.86 and > newer, is that true? Does groupthink require this? > > pippy is currently broken because of: > http://trac.sugarlabs.org/ticket/1058 > It has a patch, but at a glance I can't see how or why it would change > anything. > Who is the pippy maintainer? can we get this merged and released, > please? Including a 0.84-compatible release, pretty please. > Aleksey, perhaps you could add an explanation of the bug to the ticket, > that may help get things sorted out. yup, http://bugs.sugarlabs.org/ticket/1058#comment:7 > > Thanks, > Daniel > > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] is csound-python part of the Sugar Platform?
On Tue, Nov 03, 2009 at 11:35:12AM +, Daniel Drake wrote: > Hi, > > http://wiki.sugarlabs.org/go/0.84/Platform_Components doesn't make it > clear. Is csound-python part of the Sugar platform? In my mind its wasn't part of SP-0.84, we didn't have activities (at least on ASLO) that use python binding. But I guess we can add it to SP-0.86 - in most cases if distribution has csound, it has python binding. > For old OLPC builds, olpcsound did include the csound python module, > although this was unused by all of the standard OLPC-shipped activities. > (TamTam uses csound directly, without the python wrapper) > > As of the latest fedora packages, the standard csound packages do not > include the python wrapper, you need an extra package (csound-python) > for that. > > FWIW, The OurMusic activity requires this. > > Thanks, > Daniel > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] is csound-python part of the Sugar Platform?
On Fri, Nov 06, 2009 at 05:23:12PM +, Tomeu Vizoso wrote: > On Tue, Nov 3, 2009 at 18:51, Aleksey Lim wrote: > > On Tue, Nov 03, 2009 at 11:35:12AM +, Daniel Drake wrote: > >> Hi, > >> > >> http://wiki.sugarlabs.org/go/0.84/Platform_Components doesn't make it > >> clear. Is csound-python part of the Sugar platform? > > > > In my mind its wasn't part of SP-0.84, we didn't have activities > > (at least on ASLO) that use python binding. But I guess we can add it to > > SP-0.86 - in most cases if distribution has csound, it has python > > binding. > > It was thought that it would be part of the platform since the very > beginning, so activities like the ones in the TamTam series were > developed. TamTam uses csound directly(w/o csound-python) > I thought Memorize used it as well? Memorize was swithced to gstreamer -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] 0depend feature request
Hi all, To have some implementation mockups for next 0install debates, I've coded how(I'm thinking) 0install integration could be implemented in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned repos[2] and follow simple test case[3]. [1] http://wiki.sugarlabs.org/go/Zero_Depend [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Thu, Nov 12, 2009 at 08:10:11PM +0100, Tomeu Vizoso wrote: > On Thu, Nov 12, 2009 at 06:51, Aleksey Lim wrote: > > Hi all, > > > > To have some implementation mockups for next 0install debates, > > I've coded how(I'm thinking) 0install integration could be implemented > > in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned > > repos[2] and follow simple test case[3]. > > Hi, > > I would like to know more about how the experience changes for > activity authors 0depend is just optional feature, for bundles that have activity/0depend.xml file, while launching activity sugar(via 0install) will download(or build, just 0install feature) all dependencies that are mentioned in 0depend.xml and pass proper info via environment variables (PATH, PYTHONPATH etc) to activity startup. > and what happens when the .xo is not downloaded from > the web but copied from an usb stick. only 0depend.xml makes sense(its just regular bundle file), if it exists, shell will enable 0install integration. > Thanks, > > Tomeu > > > [1] http://wiki.sugarlabs.org/go/Zero_Depend > > [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope > > [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test > > > > -- > > Aleksey > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] New aslo@ mailing list
Hi all, To ease Activity Library editors coordination, ASLO will send all kinds of review requests to new mailing list a...@lists.sugarlabs.org. So, any editor(and not only editrs) can subsribe to this list and be informed of all reviews threads. Broadcast editor notifications were removed since it doesn't make much sense in case of having new mailing list. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Discrepancy regarding an Activity
On Sun, Nov 15, 2009 at 01:47:08PM +0100, Jonas Smedegaard wrote: > By comparison, Debian have little technical protection against > uploading evil code, but have a social "mechanism" of only allowing > official members to upload (combined with requiring a large effort > to become "official member"). I do not see the Debian design here > as brilliant, but it seems to me that current Sugarlabs approach is > even weaker :-/ In that case we just follow AMO practice, but our editors policy doesn't cover all cases[1] e.g. for various non-technical questions, I guess this topic[2] should be picked by SLOBS. [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy#Additional_technical_policy_for_editors [2] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy#Non-technical_policy -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] New aslo@ mailing list
On Thu, Nov 12, 2009 at 11:33:10PM +, Aleksey Lim wrote: > Hi all, > > To ease Activity Library editors coordination, ASLO will send all kinds > of review requests to new mailing list a...@lists.sugarlabs.org. So, > any editor(and not only editrs) can subsribe to this list and be > informed of all reviews threads. There is no need in subscription to this list for activity developers, every review email from ASLO will be CCed and REPLYTOed to proper activity authors. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release GCompris Additional Content-12
On Mon, Nov 16, 2009 at 06:06:05AM -0500, Sugar Labs Activities wrote: > Activity Homepage: > http://activities.sugarlabs.org/addon/4090 > > Sugar Platform: > 0.82 - 0.86 > > Download Now: > http://activities.sugarlabs.org/downloads/file/26359/gcompriscontent-12.xo > > Release notes: > * GCompris 8.4.13 release > * Run in sugar 0.86 environment This release is also for all GCompris activities. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] sugar-datastore sucrose-0.86 branch
Hi all, sugar-datastore was branced for 0.86 bug fixes, master branch is open for 0.88 commits. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Non sugar activities on ASLO
Hi all, Non sugar activities we (could)have on ASLO: ++ programs with high sugar integration(journal etc.) + programs that start smooth in sugar environment(sugarised screen mode etc.) - programs that are just absent in GNU/Linux distributions -- programs that present in GNU/Linux distributions In case of '-*' programs we just not follow Occam's razor principle moreover we are splitting education community(people should know that there is "native" GCompris and "sugarized" GCompris). On the other side if ASLO intended to be software repository for sugar DE. So, what about not multiplying entities and reusing 0install for '-*' programs(but still not sure about '--'). For example in case of OO4kids activity we can create 0install infrastructure(and benefit other non sugar 0install users) or reuse existed 0install package. For sugar user, 0install "activities" will look on ASLO like other activities, so click on "Download" button just runs sugarized 0install GUI. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote: > Hi all, > > Non sugar activities we (could)have on ASLO: > > ++ programs with high sugar integration(journal etc.) > + programs that start smooth in sugar environment(sugarised screen mode > etc.) btw "sugarizing" programs only by fixing window issues and bundling blobs to .xo could be also wrong way to go, better to have universal method to run non-sugar programs w/o troubles with non-fullsreen/dialogs/etc windows. Does someone have any idea.. maybe special "desktop" mode to run non-sugar applications, fullscreen top window which is represented by one item in activity tray(or special icon in sugar frame). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 05:59:44PM +0100, Tomeu Vizoso wrote: > On Mon, Nov 23, 2009 at 17:30, Aleksey Lim wrote: > > On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote: > >> Hi all, > >> > >> Non sugar activities we (could)have on ASLO: > >> > >> ++ programs with high sugar integration(journal etc.) > >> + programs that start smooth in sugar environment(sugarised screen mode > >> etc.) > > > > btw "sugarizing" programs only by fixing window issues and bundling > > blobs to .xo could be also wrong way to go, better to have universal > > method to run non-sugar programs w/o troubles with > > non-fullsreen/dialogs/etc windows. > > Is there any serious problem other than the launcher not appearing in > the home view? About the launcher issue, we could support .desktop > files. I've just tried to start several non-sugar applications(gnome-terminal, gimp, ooffice) and it looks now not so bad as I thought before. If we fix launcher related issues and maybe set gnome theme to something non-sugar(sugar theme looks ugly for regular gnome applications) and we can stop "sugarizing" applications just by tweaking window sizes(tuxpaint, gcompris) and start .desktop applications and 0install packages as is. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 12:03:24PM -0600, David Farning wrote: > On Mon, Nov 23, 2009 at 10:59 AM, Tomeu Vizoso wrote: > > On Mon, Nov 23, 2009 at 17:30, Aleksey Lim wrote: > >> On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote: > >>> Hi all, > >>> > >>> Non sugar activities we (could)have on ASLO: > >>> > >>> ++ programs with high sugar integration(journal etc.) > >>> + programs that start smooth in sugar environment(sugarised screen mode > >>> etc.) > >> > >> btw "sugarizing" programs only by fixing window issues and bundling > >> blobs to .xo could be also wrong way to go, better to have universal > >> method to run non-sugar programs w/o troubles with > >> non-fullsreen/dialogs/etc windows. > > > > Is there any serious problem other than the launcher not appearing in > > the home view? About the launcher issue, we could support .desktop > > files. > > > > Regards, > > > > Tomeu > > I have been trying to keep current active Sugar Labs developers 'out > of the way' on activities.sugarlabs.org policies. a.sl.o is one of > the most user driven and user visible aspects of Sugar Labs.A very > interesting recent thread has been about distributing scratch via > a.sl.o. This has been interesting, and hopefully precedent setting, > because it has been driven by users asking for something rather than > Sugar Labs trying to provide something. > > One of the key premises behind community development is participants > who see a problem which needs fixing and then take the time to fix > it. In this case, Jeff has been tracking down what is necessary to > distribute scratch as an .XO bundle. The short answer for why scratch > is not in a.sl.o is that no one has had the time, interest, and > ability to package and maintain scratch 1.4. Maybe that person will > be Jeff or he can find someone who can work on scratch. in case of "how to package something to .xo bundle"(which is not sugar activity) I start think that we are trying to do redundant work, we can utilize 0install(for example), so sugar and 0install(for example) communities will benefit each other. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Thu, Nov 12, 2009 at 05:51:27AM +, Aleksey Lim wrote: > Hi all, > > To have some implementation mockups for next 0install debates, > I've coded how(I'm thinking) 0install integration could be implemented > in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned > repos[2] and follow simple test case[3]. > > [1] http://wiki.sugarlabs.org/go/Zero_Depend > [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope > [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test I've changed this feature a bit, so now its a Zero Install integration[4] The reason for this feature is to cover situations: * an activity has dependencies that weren't included to the Sugar Platform * install/build activity specific binaries * run non-sugar applications that are not well packaged to GNU/Linux distributions [4] http://wiki.sugarlabs.org/go/Zero_Install_integration -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 07:39:14PM +0100, Martin Langhoff wrote: > On Mon, Nov 23, 2009 at 7:31 PM, Aleksey Lim wrote: > > I've changed this feature a bit, so now its a Zero Install integration[4] > > Good to see progress on this. Much appreciated. Some questions... > > - Why is the depcheck happening at "first start" time? Install time > seems be more appropriate: install time means there is a src of > software, needed deps can be grabbed from the same src if present... in that case we entirely depend on 0install, so sugar provide just new GUI for 0launch(here just for downloading/building dependencies). > - What happens if the deps are missing? If the user is offline? activity fails to start but in case of offline, 0install provides some options that could be useful for users(0share, 0mirror). > - What happens when the build fails? activity just fails, and of course we can add some kind of bugreporting feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 07:06:19PM +, Gary C Martin wrote: > Hi Aleksey, > > On 23 Nov 2009, at 18:45, Aleksey Lim wrote: > > > On Mon, Nov 23, 2009 at 07:39:14PM +0100, Martin Langhoff wrote: > >> On Mon, Nov 23, 2009 at 7:31 PM, Aleksey Lim > >> wrote: > >>> I've changed this feature a bit, so now its a Zero Install integration[4] > >> > >> Good to see progress on this. Much appreciated. Some questions... > >> > >> - Why is the depcheck happening at "first start" time? Install time > >> seems be more appropriate: install time means there is a src of > >> software, needed deps can be grabbed from the same src if present... > > > > in that case we entirely depend on 0install, so sugar provide just new > > GUI for 0launch(here just for downloading/building dependencies). > > > >> - What happens if the deps are missing? If the user is offline? > > > > activity fails to start but in case of offline, 0install provides some > > options that could be useful for users(0share, 0mirror). > > > >> - What happens when the build fails? > > > > activity just fails, and of course we can add some kind of bugreporting > > feature. > > First up, to be honest, I don't plan to use or involve myself with 0install > for any activities I'm involved with > (may be if it works invisibly as a worst case fallback)... if you have ready to use 0depend.xml file(for example from another activity which uses the same deps) you as developer should only place it to activity/ directory and for users starting this activity means only having additional downloading progressbar(for the first time). > But, if a deployment/teacher wanted to distribute one (or several) of these > non-Sugar compliant installs on a USB stick for remote class installation, is > it a trivial step for them to put 'the activity' on a stick so it can be > installed without any network access or local server at install time? 0install integration is just an optional addon to activity bundles, you can all time package fat .xos as usual. > Example: Teacher travels from a remote village to an education ministry or > town with internet access once a month. Downloads a selection of new > activities and content from ASLO to their USB stick. Journeys back to their > village and uses the USB stick to install/upgrade each machine, kids also > share the activity .xo bundle from Journal with friends who can't make it to > the school. http://wiki.sugarlabs.org/go/Zero_Install_integration#Deploy_0install_packages_from_ASLO_like_a_regular_sugar_activities as an addition, we can support offline mode for such activities (request for downloading all required deps for all such activities by one click). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 08:05:21PM +0100, Martin Langhoff wrote: > On Mon, Nov 23, 2009 at 7:45 PM, Aleksey Lim wrote: > >> - Why is the depcheck happening at "first start" time? Install time > >> seems be more appropriate: install time means there is a src of > >> software, needed deps can be grabbed from the same src if present... > > > > in that case we entirely depend on 0install, so sugar provide just new > > GUI for 0launch(here just for downloading/building dependencies). > > So it'll be triggered when users download & run an .xo? When they > double-click an .xo from a USB disk? 0install procedures will be triggered on avery activity launch, but we can trigger them on uploading such bundle to journal(installation), so there won't be any differences (in case of downloading from ASLO) between regular activities and activities w/ 0install dependencies > Will there be a way (control panel?) to see the disk space taken by > 0install stuff and prune/uninstall parts? dunno, I guess in most cases its a designers question I thought about simple download progress bar for launcher http://wiki.sugarlabs.org/go/File:0depend-launcher.png, control panel for setup 0install settings and we can have context menu item for activities that have 0install dependencies to show 0install status. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 07:22:23PM +, Aleksey Lim wrote: > On Mon, Nov 23, 2009 at 07:06:19PM +, Gary C Martin wrote: > > Example: Teacher travels from a remote village to an education ministry or > > town with internet access once a month. Downloads a selection of new > > activities and content from ASLO to their USB stick. Journeys back to their > > village and uses the USB stick to install/upgrade each machine, kids also > > share the activity .xo bundle from Journal with friends who can't make it > > to the school. > > http://wiki.sugarlabs.org/go/Zero_Install_integration#Deploy_0install_packages_from_ASLO_like_a_regular_sugar_activities > > as an addition, we can support offline mode for such activities > (request for downloading all required deps for all such activities > by one click). ..and share such dependencies by http://0install.net/0share.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 08:00:49PM +, Aleksey Lim wrote: > On Mon, Nov 23, 2009 at 07:22:23PM +0000, Aleksey Lim wrote: > > On Mon, Nov 23, 2009 at 07:06:19PM +, Gary C Martin wrote: > > > Example: Teacher travels from a remote village to an education ministry > > > or town with internet access once a month. Downloads a selection of new > > > activities and content from ASLO to their USB stick. Journeys back to > > > their village and uses the USB stick to install/upgrade each machine, > > > kids also share the activity .xo bundle from Journal with friends who > > > can't make it to the school. > > > > http://wiki.sugarlabs.org/go/Zero_Install_integration#Deploy_0install_packages_from_ASLO_like_a_regular_sugar_activities > > > > as an addition, we can support offline mode for such activities > > (request for downloading all required deps for all such activities > > by one click). > > ..and share such dependencies by http://0install.net/0share.html or doing something similar to http://roscidus.com/desktop/Zero2Bundle or http://0install.net/0export.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 02:46:52PM -0600, Jim Simmons wrote: > Aleksey, > > It would be helpful to have a way to distribute things like the > gstreamer espeak plugin you wrote. Fedora doesn't currently include > it. It would be even better if you could distribute versions that > work on the XO running .82, as well as versions for current Fedora. > Don't know if that was what you had in mind. yeah, thats another reason to have 0install dependencies - having over-distributions method to install deps that can't be installed from native packages(not yet packaged, packaged incompatible version). http://wiki.sugarlabs.org/go/Zero_Install_integration#Support_0install_integration_in_sugar_.3C0.88_activities -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Tue, Nov 24, 2009 at 12:20:15PM +0100, Simon Schampijer wrote: > Hi, > > as a follow up on an older thread: > http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html > - we want to get the versioning sorted in 0.88 for real. So far we came > up with these three options: > > a) The release cycle dependent one: Activities name their activity after > the Sugar version they are developed against. If it was released during > the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Most of activities are compatible with several release cycles, so using SP in activity versions adds only confusing > b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. > Fixes would go into 115.1, 115.2... > > c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be > 115.0.0. Fixes would go into 115.1.0, 115.2.1... > > What do people like best? > > Thanks, > Simon > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Tue, Nov 24, 2009 at 02:21:09PM +0100, Simon Schampijer wrote: > On 11/24/2009 01:42 PM, Gary C Martin wrote: > > Hi Simon, > > > > On 24 Nov 2009, at 11:20, Simon Schampijer wrote: > > > >> Hi, > >> > >> as a follow up on an older thread: > >> http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html > >> - we want to get the versioning sorted in 0.88 for real. So far we came > >> up with these three options: > >> > >> a) The release cycle dependent one: Activities name their activity after > >> the Sugar version they are developed against. If it was released during > >> the 0.88 cycle and developed against 0.88, then it would be 0.88.x. > > Ok, I do not like that option neither. And the people that have replied, > do not neither. > > > Should we also try and resolve the Fructose issue as well here? Is Fructose > > just a random grab bag of demo activities, or is it the set of activities > > that are dependant on a single specific release of Glucose? Right now it > > contains a mix of both. I'd be against including Sugar version numbers in > > activity version number (unless perhaps they fail to work in other sugar > > releases). Activity development should be as far removed from the Glucose > > development cycle as is feasibly possible. > > > > If Fructose becomes the set of Glucose dependent activities (like Browse), > > they could be the only ones that require special versioning support > > Yes, good point. We should revisit the current activities in Fructose > and think if it makes sense to keep them in Fructose. As you said, one > point is if an activity has dependencies on the platform itself like > Browse (Hulahop). In mind thats wrong way, some activities have non-sugar SP dependencies and can work fine with several SP releases, I guess its better to not add additioanl complexity and use only one source for compatibility info - on ASLO(moreove we have fructose activities on ASLO). BTW for 0.88 can exclude fructose from core packages at all and let deployers decide what should be included to deployments. > > I propose to go through all Fructose activities and see which one makes > sense to keep in Fructose. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fructose - What is it? What should it be?
On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote: > Hi, > > this came up several times now. People where wondering what Fructose is. > From the definition it is: > > The Sugar developers will need some example set of activities with which > to demonstrate Sugar. This set is Fructose. The packages in Fructose > should be selected to make the resulting environment as impressive as > possible for a potential client or user. Packages should therefore be > stable, polished, and exercise the widest possible range of features. > Fructose may also serve as an example for people constructing their own > Activity sets. [1] > > The current list of activities can be found at [2]. > > The fructose activities follow the Sucrose development cycle (0.84, > 0.86...). This means they follow the freezes, provide source tarballs, > need a present maintainer etc. The duties are described at [3]. The > activity gets noted in release notes, possibly more attention by the > localization teams as revenue. > > In the end their are downsides and upsides to be part of Fructose. There > were some arguing, that only system dependent activities should be part > of it (e.g. Browse with the dependency on hulahop). > > There were some discussions that we would loose the show case activities > when an activity would not be part of Fructose anymore. This comes down > to packaging, as for rpm packaging one needs to provide the source > tarballs and need to follow certain rules. Some distributors may ship > the .xo bunles at one point, otherwise probably won't, so it is a good > habit to do the source releases. > > Anyhow, this is a bit of the background. Let's think how we can move > forward on this topic. We should do it quickly, to be able to keep the > work on 0.88 going. In my mind, the best thing we can do is making clear definition: 1) we have core with strong release cycle * glucose(and its dependencies) * sugar platform(additional dependencies) (core) 2) various sugar activities (the rest of development community) 3) sugar users (the rest of community) Relations between 1) and 2) totally depends on sugar release cycles. Activity developers decide what release cycles they can/should/will support. For activities like Browse it will several activities versions per SP release. Most activities will support several SP release. Relations between 2) and 3) is task for various deployment methods. Since fructose makes sense mostly for users, its content should totally depends on deployers not core. So I can't see the 4rd place for fructose, only as a part of 2). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Zero-install-devel] 0depend feature request
On Tue, Nov 24, 2009 at 10:20:27PM +, Thomas Leonard wrote:
> 2009/11/24 Michael Stone :
> > Aleksey wrote:
> >
> >> To have some implementation mockups for next 0install debates,
> >> I've coded how(I'm thinking) 0install integration could be implemented
> >> in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned
> >> repos[2] and follow simple test case[3].
> >>
> >> [1] http://wiki.sugarlabs.org/go/Zero_Depend
> >> [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope
> >> [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test
> >
> > Aleksey,
> >
> > I tried out your patches in a Debian Sid chroot with
> >
> > zeroinstall-injector-0.42.1-1
> >
> > installed and got the following exception in shell.log when running your
> > test
> > case:
> >
> > AssertionError: Solver is not ready!
> > {http://rox.sourceforge.net/2005/interfaces/ROX-Lib>: None,
> > :
> > v1 (/home/sugar/Activities/Terminal.activity/activity)}
> >
> > The problem seems to be that you haven't told the policy object to solve the
> > feeds. You can do that with
> >
> > policy.solve_with_downloads()
> >
> > and maybe in other ways too.
>
> That's right:
>
> - need_download() will do a solve and return True if you're missing
> feeds or implementations
> - solve_with_downloads() will solve and download any extra feeds it
> needs repeatedly until it has all the information it needs
> - solve_and_download_impls() will additionally download the selected
> implementations afterwards
I've just tried simple example[1] with simple feed[2] in system w/o
any 0install remains and it fails for the first time[3] but runs ok for 2nd.
I missed something in example code or its a unpredictable behaviour
(since [3] cailms for missed ROX-Lib dependensy but
solve_and_download_impls() should make all downloads)?
[1] http://pastebin.be/22131
[2] http://pastebin.be/22132
[3] http://pastebin.be/22133
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] SoaS v2 approaching RC state
On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: > On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas > wrote: > > Hi all, > > > > with the next SoaS release coming up really soon (final image is > > supposed to be composed this weekend, release date is Dec 8), there's a > > new snapshot ready for you. It includes a lot of fixes and smaller > > adjustments. It's currently only available as a general .iso build, > > others will presumably follow later. You can get it from here: > > > > http://download.sugarlabs.org/soas/snapshots/2/soas06.iso > > > > Let us know how it goes and help us debugging and fixing the remaining > > bugs here: https://bugs.launchpad.net/soas/+bugs > > > > A last note, if anybody knows what's wrong with Record, Cairo and F12, > > Who is the maintainer of Record? It would be a pity to ship BB without > that working as its one off the Activities that kids seem to love. > What's the issue with Cairo? last time /me patched Record.. and looks like it doesn't work in 0.86 for a long time, so its the right moment to fix 0.86 issues then -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Tue, Nov 24, 2009 at 03:01:07PM -0500, Michael Stone wrote:
> Aleksey wrote:
>
> > To have some implementation mockups for next 0install debates,
> > I've coded how(I'm thinking) 0install integration could be implemented
> > in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned
> > repos[2] and follow simple test case[3].
> >
> > [1] http://wiki.sugarlabs.org/go/Zero_Depend
> > [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope
> > [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test
>
> Aleksey,
>
> I tried out your patches in a Debian Sid chroot with
>
>zeroinstall-injector-0.42.1-1
>
> installed and got the following exception in shell.log when running your test
> case:
>
>Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py",
> line 519, in __button_release_event_cb
>self._activate()
> File "/usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py",
> line 531, in _activate
>self._resume(self._journal_entries[0])
> File "/usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py",
> line 524, in _resume
>shell.resume(journal_entry, self._activity_info.get_bundle_id())
> File "/usr/lib/python2.5/site-packages/jarabe/util/shell.py", line 222,
> in resume
>launch(bundle, handle, get_icon_color(metadata))
> File "/usr/lib/python2.5/site-packages/jarabe/util/shell.py", line 238,
> in launch
>launcher.add_launcher(bundle, activity_handle, color)
> File "/usr/lib/python2.5/site-packages/jarabe/view/launcher.py", line
> 185, in add_launcher
>zdepend.fetch(zfeed, progress, create_activity, cancel)
> File "/usr/lib/python2.5/site-packages/jarabe/util/zdepend.py", line 49,
> in fetch
>downloaded = policy.download_uncached_implementations()
> File "/usr/lib/python2.5/site-packages/zeroinstall/injector/policy.py",
> line 393, in download_uncached_implementations
>assert self.solver.ready, "Solver is not ready!\n%s" %
> self.solver.selections
>AssertionError: Solver is not ready!
>{http://rox.sourceforge.net/2005/interfaces/ROX-Lib>: None,
> : v1
> (/home/sugar/Activities/Terminal.activity/activity)}
>
> The problem seems to be that you haven't told the policy object to solve the
> feeds. You can do that with
>
>policy.solve_with_downloads()
>
> and maybe in other ways too.
yeah, in my testing environment I have remains from previous 0install
sessions
> Anyway, after teaching zdepend.py to solve the policy, I ran into into further
> trouble because my zeroinstall trust-db doesn't contain the ROX keys.
>
> To deal with this, I think you need to construct the policy object with a
> Handler object
>
>
> http://0install.net/python-api/html/zeroinstall.injector.handler.Handler-class.html
>
> and override its confirm_keys method.
I've pushed new commits with fixed these issues and added cancel button
>
> @Thomas, Rene: is this about right?
>
> Michael
>
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Zero-install-devel] 0depend feature request
On Wed, Nov 25, 2009 at 10:27:57AM +, Thomas Leonard wrote: > 2009/11/24 Aleksey Lim : > [...] > > I've just tried simple example[1] with simple feed[2] in system w/o > > any 0install remains and it fails for the first time[3] but runs ok for 2nd. > > > > I missed something in example code or its a unpredictable behaviour > > (since [3] cailms for missed ROX-Lib dependensy but > > solve_and_download_impls() should make all downloads)? > > > > [1] http://pastebin.be/22131 > > [2] http://pastebin.be/22132 > > [3] http://pastebin.be/22133 > > An async task needs to be a Python generator, which means it needs to > include a "yield" statement somewhere (even if it's never called). > > Normally key confirmation has to be async because it has to wait for > the key information to arrive and it has to wait for the user to > confirm. > > I'll update handler.py so that it doesn't need to be async, but > meanwhile just putting yield at the end will fix the problem. thanks, I added yield to confirm_import_feed() and it works fine -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Record rewrite -- was Re: [SoaS] SoaS v2 approaching RC state
On Wed, Nov 25, 2009 at 12:25:12AM +, Aleksey Lim wrote: > On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: > > On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas > > wrote: > > > Hi all, > > > > > > with the next SoaS release coming up really soon (final image is > > > supposed to be composed this weekend, release date is Dec 8), there's a > > > new snapshot ready for you. It includes a lot of fixes and smaller > > > adjustments. It's currently only available as a general .iso build, > > > others will presumably follow later. You can get it from here: > > > > > > http://download.sugarlabs.org/soas/snapshots/2/soas06.iso > > > > > > Let us know how it goes and help us debugging and fixing the remaining > > > bugs here: https://bugs.launchpad.net/soas/+bugs > > > > > > A last note, if anybody knows what's wrong with Record, Cairo and F12, > > > > Who is the maintainer of Record? It would be a pity to ship BB without > > that working as its one off the Activities that kids seem to love. > > What's the issue with Cairo? > > last time /me patched Record.. and looks like it doesn't work in 0.86 > for a long time, so its the right moment to fix 0.86 issues then Sorry, I'm a bit stuck with it, my plans were to rewrite Record-65 and make lightweight Record: * w/o collaboration feature as it was designed in existed Record * it just share records, I'm planing to do the same on Journal level * it just doesn't work well(especially for big files) * w/o gtk.Windows that represent Record's controls, only widgets * using more robust gst scheme I decide to use camerabin[1] gst plugin which is a good option for Record but it doesn't work(stop w/ gst errors on recording) any help from people who are aware of such gst and video recording stuff is appreciated. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-camerabin.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ooo4Kids in several languages - how to let it appear on aslo?
On Thu, Nov 26, 2009 at 10:37:31AM +, Carlo Falciola wrote: > > > > >On Thu, Nov 26, 2009 at 09:48, Tomeu Vizoso >wrote: > > Hi Bastien, > > > > On Thu, Nov 26, 2009 at 09:27, Bastien > > wrote: > >> Dear all, > >> > >> I just uploaded Ooo4Kids 0.5.1 on aslo: > >> http://activities.sugarlabs.org/fr/sugar/addon/4241 > >> > >> There is an spanish version here: > >> http://download.ooo4kids.org/es/descargar-ooo4kids-xo-intel > >> > >> How to host this spanish version on aslo? Should I make another > >> activity, or is it possible to upload several "branches"? > >> > >> Thanks for any hint! > > > > Has the OOo4Kids team considered using gettext or similar so can ship > > a single bundle containing several localizations? > > >Eric has told me in #sugar that the reason for this is because each > >locale takes about 100MB when compressed. If it's not feasible to make > >the locales smaller, then I would recommend creating different > >activities, with different activity ids. > > > >Regards, > > > >Tomeu > > If I remember correctly, we'd discussed similar issue back in Paris with > Bruno about Gcompris additional language packages, those packages where in > the same order of magnitude in size. > > Look a common issue for bigger (in text content) projects not sure if GCompis has the same issue, for now, GCompis activites on ASLO have gettext strings for all langs (I just used activity specific strings from common .po files) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Record rewrite -- was Re: [SoaS] SoaS v2 approaching RC state
On Thu, Nov 26, 2009 at 02:49:31PM -0800, Peter Robinson wrote: > On 11/26/09, Aleksey Lim wrote: > > On Wed, Nov 25, 2009 at 12:25:12AM +, Aleksey Lim wrote: > >> On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: > >> > On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas > >> > wrote: > >> > > Hi all, > >> > > > >> > > with the next SoaS release coming up really soon (final image is > >> > > supposed to be composed this weekend, release date is Dec 8), there's > >> > > a > >> > > new snapshot ready for you. It includes a lot of fixes and smaller > >> > > adjustments. It's currently only available as a general .iso build, > >> > > others will presumably follow later. You can get it from here: > >> > > > >> > > http://download.sugarlabs.org/soas/snapshots/2/soas06.iso > >> > > > >> > > Let us know how it goes and help us debugging and fixing the remaining > >> > > bugs here: https://bugs.launchpad.net/soas/+bugs > >> > > > >> > > A last note, if anybody knows what's wrong with Record, Cairo and F12, > >> > > >> > Who is the maintainer of Record? It would be a pity to ship BB without > >> > that working as its one off the Activities that kids seem to love. > >> > What's the issue with Cairo? > >> > >> last time /me patched Record.. and looks like it doesn't work in 0.86 > >> for a long time, so its the right moment to fix 0.86 issues then > > > > Sorry, I'm a bit stuck with it, my plans were to rewrite Record-65 > > and make lightweight Record: > > > > * w/o collaboration feature as it was designed in existed Record > > * it just share records, I'm planing to do the same on Journal level > > * it just doesn't work well(especially for big files) > > * w/o gtk.Windows that represent Record's controls, only widgets > > * using more robust gst scheme > > > > I decide to use camerabin[1] gst plugin which is a good option for > > Record but it doesn't work(stop w/ gst errors on recording) any help > > from people who are aware of such gst and video recording stuff is > > appreciated. > > You shouldn't rely on any of the plugins in gst-plugins-bad as most > distros won't ship them by default due to either quality or legal > issues. I didn't think to rely on -bad, just make fat bundle or use 0instal. > Can you look at what apps like cheese use for that sort of > thing? since cheese also moving to camerabin... except camerabin, Record is prety simple activity(about collab features, see text above). I posted upstream bug about record errors and going to return to Record developing when at least upstream example will work ok (camerabin bin example from git tree doesn't record as well in my case). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] for Journal Plugins feature
Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Examples in Journal (#1585)
On Fri, Nov 27, 2009 at 02:57:01PM +0100, Sascha Silbe wrote: > From: Sugar Labs Bugs > Subject: Re: #1585 UNSP: need some way to present examples to other > activities > Cc: b...@lists.sugarlabs.org > Reply-To: sugar-devel@lists.sugarlabs.org > Date: Fri, 27 Nov 2009 13:48:57 - > > #1585: need some way to present examples to other activities > --+- > Reporter: dsd| Owner: tomeu > > Type: enhancement| Status: new > > Priority: Unspecified by Maintainer | Milestone: Unspecified by > Release Team >Component: sugar |Version: Git as of > bugdate > Severity: Unspecified| Keywords: > > Distribution: Unspecified| Status_field: Needinfo > > --+- > Changes (by sascha_silbe): > > * cc: sascha_silbe (added) > * version: Unspecified => Git as of bugdate > * status_field: Unconfirmed => Needinfo > > > Comment: > > IMO examples belong into the Journal as much (or as few, depending on your > POV) as activity bundles belong there. > Maybe we should "hide" them in the default view and just show them in > specialised ones. > Splitting up the Journal into Object and Action views (as already in the > designs for a long time) would IMO be a prerequisite for this. > > I'll boldly set NEEDINFO on this as we need further discussion on the > mailing list and designs before we can start working on it. Not sure if its right way to go(some special rules for showing Journal entries), in my mind having common and explicit method is preferable[1]. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: > Hi all, > > Want to know what people think about Journal Plugins feature[1] > and particularly that design team think about UI changes[2] involved > in this feature. > > [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# > [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked "Benefit to Sugar" section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with "Send to" option) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Examples in Journal (#1585)
On Fri, Nov 27, 2009 at 04:23:02PM +0100, Sascha Silbe wrote: > On Fri, Nov 27, 2009 at 02:57:57PM +0000, Aleksey Lim wrote: > > >>IMO examples belong into the Journal as much (or as few, depending > >> on your > >>POV) as activity bundles belong there. > >>Maybe we should "hide" them in the default view and just show them > >> in > >>specialised ones. > >>Splitting up the Journal into Object and Action views (as already > >> in the > >>designs for a long time) would IMO be a prerequisite for this. > > > > Not sure if its right way to go(some special rules for showing Journal > > entries), in my mind having common and explicit method is > > preferable[1]. > Sorry, I don't understand what you're trying to say. Can you elaborate, > please? in [1], "hidden examples" means just some kind of bookmark(which have query terms to hide other/show-only) and having default set to browse all objects > > [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: > On 27.11.2009, at 07:13, Aleksey Lim wrote: > > > > Hi all, > > > > Want to know what people think about Journal Plugins feature[1] > > and particularly that design team think about UI changes[2] involved > > in this feature. > > > > [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# > > [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes > > I like the idea. > > Reminds me of how in OS X, the Finder can be extended to support more file > formats by a plugin stored in an application bundle. The Finder knows how to > show previews for several document types (audio, video, multi-page document). > It recognizes a limited set of formats (like jpg, mov, pdf), and the app's > plugin simply needs to convert its own format into one of these formats. yup, I had the same in mind, API will let Journal plugin to use query (tags(which include MIME types tags) and search string) to restrict final set of objects > That's a lot simpler than having to write an actual viewer plugin (which also > would have to be maintained for every new version of the viewer). E.g., Etoys > stores a thumbnail in its project file which are simply zipped, so the > preview plugin just extracts the thumbnail picture from the project. Tt does > not have to care about the actual UI used to display the thumbnail. there is another benefit for separate plugins - plugins could be out of sugar release cycle(;P to core maintainers) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Zero Install integresion request for inclusion to 0.88
Hi all, http://wiki.sugarlabs.org/go/Features/Zero_Install_integration The reason for this feature is to cover situations * an activity has dependencies that weren't included to the Sugar * Platform * install/build activity specific binaries * run non-sugar applications that are not well packaged to * GNU/Linux distributions Benefit to Sugar * let activity authors use non Sugar Platform dependencies * exclude binary blobs from activity bundles, 0install will let sugar install/build proper blobs for local architecture/OS-environment * having sugar UI to start 0install packages(non-sugar) and having common 0install dependencies, sugar and 0install communities could benefit each other * so, we can replace "sugarized" activities like TuxPaint and GCOmpris on ASLO by 0install packages(that could be useful for non-sugar users as well) New UI intoduced bu feature: * progress bar for launcher window to download dependencies * progress bar in Journal's column for manual 0install downloads * additional activity palette item if activity has not yet downloaded 0install files * new control panel component #Control panel component http://wiki.sugarlabs.org/go/Features/Zero_Install_integration#UI_changes -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Sugar Bundles request for inclusion to 0.88
Hi all, http://wiki.sugarlabs.org/go/Features/Sugar_Bundles One file format to transfer various types of content in/out to/from sugar environment with keeping metadata. In fact, this feature is an end users oriented(technically we not invent super format for various types of content, just unified sugar wrapper). Users all time know that there is only one type of sugar objects, they see it as a Journal item, one file with suffix .xo in non-sugar environments etc. So they need only upload this file to Journal and click to activate it. Benefit to Sugar Out of sugar environment, users know that there is only one type of sugar objects and only thing they should do to activate them is uploading .xo file to Journal and click it. So if one user uploaded Journal object(any type - activity, activity object, content library etc.) to the web, another user can download/transfer-through-many-non-sugar-environments it and open in his sugar environment with keeping all metadata(he will get the same Journal entry). We can also collect users object on public server like ASLO to have server like sharing feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: > It seems time to think about the next _big_ technical issue for > growing Sugar Labs. Clearly articulating the Sugar Stack. For the > last year or so, we have been circling the issue with talk of stable > APIs, Glucose, Fructose, and expected dependencies. > > Last year, we created the release cycle. At first, _everyone_ > disagreed with the idea; Release cycles are perfect for _no_one_. > Defining the Sugar Stack is going to be nearly as painful, because the > 'stack definition' is not going to be perfect for anyone. yeah, but using 0install dependencies[1] should make stack definition issue not so hard(we can include to stack only very common dependencies) > Some reasons for defining a stack: > 1. Statement of quality. One of the most frequently cited reasons for > the glucose, fructose, honey classification is quality. > - Glucose is the core stuff. > - Fructose is the supported stuff. > - Honey is the rest. > This is a very valid method of defining layers of the project; Fedora > had core and extras, Ubuntu has main and universe, Eclipse has various > levels of official-ness, (none of which I can remember) The kernel > simply has 'in-tree' and 'out-of-tree'. > > 2. Statement of synchronisation. In some instances it is desirable > for various parts of a project to be tested and release together. > - Sugar core is developed according to a release cycle. > - Fructose tends to align with the release cycle. > - Honey happens 'when it happens.' > This is also very valid; Distro all have synchronised releases. The > desktop managers all ship a core at distinct release points. Ecplise > has its release train. > > 3. Statement of what is provided. Down streams _need_ to know what > applications they can depend on. > - Core APIs > - Optional things to meet dependencies. > Most languages provide for core functionality which can be extended > with modules. Apache also is organized as http server and installable > modules. > > Many of the discussion about this have stalled because of confusion > over what aspect the stack we are trying to define. > > As a starting point, I would suggest: > 1. That we get rid of the glucose - fructose categorisation. It is > overloaded and confusing yup, I like scheme when new activity developer well understands(from beginning) that there is core and his new activity(w/o "core", since fructose comes from sucrose release) which uses core functionality. > 2. That Quality and synchronisation of activities becomes an > Activities Team issue. and ASLO could be useful on that way(featured activities, editors collections etc) and this process is pretty transparent(e.g. we have public aslo@ ml to discuss editros questions) and well visible(all editors changes are accessible right after changes) on ASLO. So, in comparing with fructose scheme(which e.g. involves all distro packagers, since they should package fructose) in case of ASLO we have more flexible method. > This shifts the discussion back to the hard problem of how to think > terms of 'Sugar-Space' and 'Activities-Space'. > > Long term projects success depends on external organisation knowing > what they can depend on to be part of Sugar. > > Before starting a holy war The process of articulating the Sugar > stack, much the the release cycle, is an evolutionary process. There > is no way the anyone could sit down and declare, 'This is what Sugar > consists of... and will consist of in the future.' > > Instead, the stack is a snapshot of agreed upon APIs, libraries, and > applications on which downstream activities developers can depend. I > suggest that: > 1. The development team and activities team work together to start > defining the boundary between core and activities. well, from tech POV, its pretty clear - there are core packages and activities that use core API/services/resources > 2. All changes to the core and activities boundary should go through > the new features (or similar) process. > > After a few iterations, this process will become as second nature as > the release process. > > david > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Download_dependencies_for_sugar_activity -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 05:56:42PM +, Aleksey Lim wrote: > On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: > > Many of the discussion about this have stalled because of confusion > > over what aspect the stack we are trying to define. > > > > As a starting point, I would suggest: > > 1. That we get rid of the glucose - fructose categorisation. It is > > overloaded and confusing > > yup, I like scheme when new activity developer well understands(from > beginning) that there is core and his new activity(w/o "core", since > fructose comes from sucrose release) which uses core functionality. > > > 2. That Quality and synchronisation of activities becomes an > > Activities Team issue. > > and ASLO could be useful on that way(featured activities, editors > collections etc) and this process is pretty transparent(e.g. we have > public aslo@ ml to discuss editros questions) and well visible(all > editors changes are accessible right after changes) on ASLO. > > So, in comparing with fructose scheme(which e.g. involves all distro > packagers, since they should package fructose) in case of ASLO we > have more flexible method. I guess one of major reasons to keep fructose is localization issue (its much easier for translators to have tough set of activities to localize them at first). In my mind its just remains from OLPC scheme(when where is only one developer/deployer). But now, another deployment could have another priority in choosing activities. So translate.sl.o could have several activity sets for various deployers/deployments such we have now only for OLPC. And in addition to such sets, using "Featured activities" which will be set of featured activities on ASLO(last activity versions). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Sugar Bundles request for inclusion to 0.88
On Fri, Nov 27, 2009 at 06:30:52PM +0100, Sascha Silbe wrote: > On Fri, Nov 27, 2009 at 04:40:00PM +0000, Aleksey Lim wrote: > > > Out of sugar environment, users know that there is only one type of > > sugar objects and only thing they should do to activate them is > > uploading .xo file to Journal and click it. > What about interacting with non-Sugar environments? What are the > workflows for > a) "Tunneling" Journal objects through legacy systems (e.g. USB stick) > and > b) Exporting Journal objects so legacy systems can read them (i.e. as > plain text, HTML, etc.)? thats just a zip with stuctured ascii metadata file(s) so, could be opened and chaged inplace http://wiki.sugarlabs.org/go/Features/Sugar_Bundles#Specification -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
Hi all, While preparing new 0.88 features, I encountered some in consistence in "activities vs. activity bundles" case, so I'm going to reveal "Activity as regular objects"(see [1] ml thread) feature but make it less invasive in case existed user experience. http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object The major reason for this feature is eliminating confusion when: * theres are activities(in Home view) and activity bundles(in Journal) * user can remove bundle from Journal and activity will be preserved(and vise versa) * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal Feature declares: * every activity which is accessible in sugar has Journal entry o for activity came from bundles, entry will have .xo's metadata(timestamp, title etc) o for system wide activities, based of /usr directory properties * there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another o in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home plugin * reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity * reflect on uploading to Journal new .xo version of existed activity, could be: o follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity) o storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start Benefit to Sugar * feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity) * let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal entry to USB source * since all activities have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.) Except opinions about feature itself, I'm especially interested in "reflect on uploading to Journal new .xo version of existed activity" part of it [1] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88
Hi all, http://wiki.sugarlabs.org/go/Features/TableView_Widget GTK widget to replace gtk.TreeView in Journal. Benefit to Sugar Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders(like gtk components), introduced component uses widgets instead(could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us). Benefits we have for such scheme: * coding cells is more useful by using widgets then renders, we can reuse our existed custom widgets instead of coding sugarized cell renders * in some cases its hard to sugarize cells theme(we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar There is an ongoing discussion in gnome community about replacing GtkTreeView, not sure if new widget is ready to use for 0.88 and since Journal's view widget is pretty simple we can use our own simple implementation(360 lines of code). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: > On 27.11.2009, at 17:15, Aleksey Lim wrote: > > > > On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: > >> On 27.11.2009, at 07:13, Aleksey Lim wrote: > >>> > >>> Hi all, > >>> > >>> Want to know what people think about Journal Plugins feature[1] > >>> and particularly that design team think about UI changes[2] involved > >>> in this feature. > >>> > >>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# > >>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes > >> > >> I like the idea. > >> > >> Reminds me of how in OS X, the Finder can be extended to support more file > >> formats by a plugin stored in an application bundle. The Finder knows how > >> to show previews for several document types (audio, video, multi-page > >> document). It recognizes a limited set of formats (like jpg, mov, pdf), > >> and the app's plugin simply needs to convert its own format into one of > >> these formats. > > > > yup, I had the same in mind, API will let Journal plugin to use query > > (tags(which include MIME types tags) and search string) to restrict > > final set of objects > > > >> That's a lot simpler than having to write an actual viewer plugin (which > >> also would have to be maintained for every new version of the viewer). > >> E.g., Etoys stores a thumbnail in its project file which are simply > >> zipped, so the preview plugin just extracts the thumbnail picture from the > >> project. Tt does not have to care about the actual UI used to display the > >> thumbnail. > > > > there is another benefit for separate plugins - > > plugins could be out of sugar release cycle(;P to core maintainers) > > > > -- > > Aleksey > > I'm not sure we are talking about the same thing, though maybe we do - so > I'll be explicit: > > I'm suggesting that activities would contain those plugins for the types they > support. got it, but not sure, we can get the same result with preview feature, in preview() every activity can "convert" its object to image, in my mind its more useful(at least for now) then complicated system with preview plugins. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 04:16:30PM +, Aleksey Lim wrote: > On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: > > On 27.11.2009, at 17:15, Aleksey Lim wrote: > > > > > > On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: > > >> On 27.11.2009, at 07:13, Aleksey Lim wrote: > > >>> > > >>> Hi all, > > >>> > > >>> Want to know what people think about Journal Plugins feature[1] > > >>> and particularly that design team think about UI changes[2] involved > > >>> in this feature. > > >>> > > >>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# > > >>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes > > >> > > >> I like the idea. > > >> > > >> Reminds me of how in OS X, the Finder can be extended to support more > > >> file formats by a plugin stored in an application bundle. The Finder > > >> knows how to show previews for several document types (audio, video, > > >> multi-page document). It recognizes a limited set of formats (like jpg, > > >> mov, pdf), and the app's plugin simply needs to convert its own format > > >> into one of these formats. > > > > > > yup, I had the same in mind, API will let Journal plugin to use query > > > (tags(which include MIME types tags) and search string) to restrict > > > final set of objects > > > > > >> That's a lot simpler than having to write an actual viewer plugin (which > > >> also would have to be maintained for every new version of the viewer). > > >> E.g., Etoys stores a thumbnail in its project file which are simply > > >> zipped, so the preview plugin just extracts the thumbnail picture from > > >> the project. Tt does not have to care about the actual UI used to > > >> display the thumbnail. > > > > > > there is another benefit for separate plugins - > > > plugins could be out of sugar release cycle(;P to core maintainers) > > > > > > -- > > > Aleksey > > > > I'm not sure we are talking about the same thing, though maybe we do - so > > I'll be explicit: > > > > I'm suggesting that activities would contain those plugins for the types > > they support. > > got it, but not sure, we can get the same result with preview feature, > in preview() every activity can "convert" its object to image, in my mind > its more useful(at least for now) then complicated system with preview > plugins. [1] is more about adding special UI components, like for Books plugins, add extra columns to object list(author, date etc) or subwidget with preview etc. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 06:59:51PM +0100, Bert Freudenberg wrote: > On 28.11.2009, at 17:16, Aleksey Lim wrote: > > > > On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: > >> On 27.11.2009, at 17:15, Aleksey Lim wrote: > >>> > >>> On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: > >>>> On 27.11.2009, at 07:13, Aleksey Lim wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Want to know what people think about Journal Plugins feature[1] > >>>>> and particularly that design team think about UI changes[2] involved > >>>>> in this feature. > >>>>> > >>>>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# > >>>>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes > >>>> > >>>> I like the idea. > >>>> > >>>> Reminds me of how in OS X, the Finder can be extended to support more > >>>> file formats by a plugin stored in an application bundle. The Finder > >>>> knows how to show previews for several document types (audio, video, > >>>> multi-page document). It recognizes a limited set of formats (like jpg, > >>>> mov, pdf), and the app's plugin simply needs to convert its own format > >>>> into one of these formats. > >>> > >>> yup, I had the same in mind, API will let Journal plugin to use query > >>> (tags(which include MIME types tags) and search string) to restrict > >>> final set of objects > >>> > >>>> That's a lot simpler than having to write an actual viewer plugin (which > >>>> also would have to be maintained for every new version of the viewer). > >>>> E.g., Etoys stores a thumbnail in its project file which are simply > >>>> zipped, so the preview plugin just extracts the thumbnail picture from > >>>> the project. Tt does not have to care about the actual UI used to > >>>> display the thumbnail. > >>> > >>> there is another benefit for separate plugins - > >>> plugins could be out of sugar release cycle(;P to core maintainers) > >>> > >>> -- > >>> Aleksey > >> > >> I'm not sure we are talking about the same thing, though maybe we do - so > >> I'll be explicit: > >> > >> I'm suggesting that activities would contain those plugins for the types > >> they support. > > > > got it, but not sure, we can get the same result with preview feature, > > in preview() every activity can "convert" its object to image, in my mind > > its more useful(at least for now) then complicated system with preview > > plugins. > > That works only if the activity is running. The bundle-provided converter can > be run any time, like when downloading a file or from a USB stick. but preview image could be embedded[3] to USB file (if we are talking about objects that activity supports, thus about regular activity objects that have preview field, and not about non-sugar objects) [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 06:08:53PM +, Aleksey Lim wrote: > On Sat, Nov 28, 2009 at 06:59:51PM +0100, Bert Freudenberg wrote: > > On 28.11.2009, at 17:16, Aleksey Lim wrote: > > > > > > On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: > > >> On 27.11.2009, at 17:15, Aleksey Lim wrote: > > >>> > > >>> On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: > > >>>> On 27.11.2009, at 07:13, Aleksey Lim wrote: > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> Want to know what people think about Journal Plugins feature[1] > > >>>>> and particularly that design team think about UI changes[2] involved > > >>>>> in this feature. > > >>>>> > > >>>>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# > > >>>>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes > > >>>> > > >>>> I like the idea. > > >>>> > > >>>> Reminds me of how in OS X, the Finder can be extended to support more > > >>>> file formats by a plugin stored in an application bundle. The Finder > > >>>> knows how to show previews for several document types (audio, video, > > >>>> multi-page document). It recognizes a limited set of formats (like > > >>>> jpg, mov, pdf), and the app's plugin simply needs to convert its own > > >>>> format into one of these formats. > > >>> > > >>> yup, I had the same in mind, API will let Journal plugin to use query > > >>> (tags(which include MIME types tags) and search string) to restrict > > >>> final set of objects > > >>> > > >>>> That's a lot simpler than having to write an actual viewer plugin > > >>>> (which also would have to be maintained for every new version of the > > >>>> viewer). E.g., Etoys stores a thumbnail in its project file which are > > >>>> simply zipped, so the preview plugin just extracts the thumbnail > > >>>> picture from the project. Tt does not have to care about the actual UI > > >>>> used to display the thumbnail. > > >>> > > >>> there is another benefit for separate plugins - > > >>> plugins could be out of sugar release cycle(;P to core maintainers) > > >>> > > >>> -- > > >>> Aleksey > > >> > > >> I'm not sure we are talking about the same thing, though maybe we do - > > >> so I'll be explicit: > > >> > > >> I'm suggesting that activities would contain those plugins for the types > > >> they support. > > > > > > got it, but not sure, we can get the same result with preview feature, > > > in preview() every activity can "convert" its object to image, in my mind > > > its more useful(at least for now) then complicated system with preview > > > plugins. > > > > That works only if the activity is running. The bundle-provided converter > > can be run any time, like when downloading a file or from a USB stick. > > but preview image could be embedded[3] to USB file > (if we are talking about objects that activity supports, thus about > regular activity objects that have preview field, and not about > non-sugar objects) but if we are talking about non-sugar objects(e.g. plain video which could be opened in Jukebox), there could be another issue in having preview plugins that come from activities - security reasons. [1] proposes API for plugins that could/should be well checked for malicious code. But if any activity can leave "resident part"(preview plugin) in shell which will be started in shell process... > [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: > On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: > >Once 0install support gets merged, Sugar Platform should be enhanced to > >include build tools (autocrap, c(++) compiler, ...); in that case, > >activity authors can also rely on the corresponding -dev(el) packages > >(i.e. libraries, header files, etc.) to be installed as well. > > I have not followed the discussions on 0install, but it surprises me > that this should be mandatory - I always considered 0install as > comparable to a distribution. afaik there is no plans to "switch" to 0install, in my mind its an edition[1] to existed scheme(but if we accept this feature we should have 0install injector library in SP), so using 0install dependencies we won't extend Sugar Platform too much [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary > > I might loose interest in Sugar if 0install becomes integral part of > core Sugar. But that's another discussion. > > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sharing question
On Mon, Nov 30, 2009 at 08:35:42AM -0500, Walter Bender wrote: > I have a new activity > (http://activities.sugarlabs.org/en-US/sugar/addon/4246) to which I am > about to add sharing. It will hat be pretty straight forward in terms > of simply exchanging game state and mouse clicks, but I want to be > able to let people join in two different ways: as a cooperator or as a > competitor. (We have had a few games where people are automatically > put into observer role, by joining late, but I cannot think of any > instances where we offer this choice when joining.) > Ideally people > should be able to choice what group to cooperate with as they join. I guess we already have such groups - in Net View, users with shared activities. > Seems to be mostly a UI issue, but is there any mechanism in your > recent work that would support this? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 12:34:45PM +, Daniel Drake wrote: > On Fri, 2009-11-27 at 22:16 +0000, Aleksey Lim wrote: > > Hi all, > > > > While preparing new 0.88 features, I encountered some in consistence in > > "activities vs. activity bundles" case, so I'm going to reveal > > "Activity as regular objects"(see [1] ml thread) feature but make it > > less invasive in case existed user experience. > > > > http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object > > I feel that this is quite a fundamental change to the Journal > philosophy. Until now, the Journal is something that record what the > user has done, and it only stores the work (or history) of the users > session within the activities. In tune with this, the Journal is empty > when you start for the same time. This would no longer be the case with > this feature. Well, I'm sure we should start such rethinking sometime since we don't have any native sugar shell workflow for forking/changing activities (imho having such workflow could be very useful to encourage tweaking existed activities in the field). And we can start from small steps like proposed feature. > I think this topic needs larger forward-thinking discussion. Personally, > I prefer the concept of the Journal for what it is now. > > > The major reason for this feature is eliminating confusion when: > > > > * theres are activities(in Home view) and activity bundles(in Journal) > > * user can remove bundle from Journal and activity will be > > preserved(and vise versa) > > * activities could not have bundles in journal(were deleted or its a > > system wide activity), so user can't copy activity(e.g. to share it via USB > > stick) using regular shell workflow(Journal) and should be aware of stuff > > like Terminal > > I guess it depends on the UI, but I worry this would actually add > confusion. Users would be prone to accidentally deleting the activity > installation from their Journal when they think they are just deleting > some work they have done in that activity. I guess it relates to another forkflow which is proposed by [2], bookmarks from [2] is just a set of objects(I think it could be useful e.g. having fast method to access to some tricky query or for sharing objects from bookmarks, to not share all objects), so user can delete/change object from bookmark or from full Journal View and that shouldn't confuse him(I hope) if he will keep in mind that he is working with the same object(but from different views) all time. In that case, having Home view(which is not "just another view") and Journal with bundles could be really confusing. [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 02:54:49PM +, Aleksey Lim wrote: > On Mon, Nov 30, 2009 at 12:34:45PM +, Daniel Drake wrote: > > On Fri, 2009-11-27 at 22:16 +, Aleksey Lim wrote: > > > Hi all, > > > > > > While preparing new 0.88 features, I encountered some in consistence in > > > "activities vs. activity bundles" case, so I'm going to reveal > > > "Activity as regular objects"(see [1] ml thread) feature but make it > > > less invasive in case existed user experience. > > > > > > http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object > > > > I feel that this is quite a fundamental change to the Journal > > philosophy. Until now, the Journal is something that record what the > > user has done, and it only stores the work (or history) of the users > > session within the activities. In tune with this, the Journal is empty > > when you start for the same time. This would no longer be the case with > > this feature. > > Well, I'm sure we should start such rethinking sometime since we don't > have any native sugar shell workflow for forking/changing activities > (imho having such workflow could be very useful to encourage tweaking > existed activities in the field). And we can start from small steps like > proposed feature. > > > I think this topic needs larger forward-thinking discussion. Personally, > > I prefer the concept of the Journal for what it is now. > > > > > The major reason for this feature is eliminating confusion when: > > > > > > * theres are activities(in Home view) and activity bundles(in Journal) > > > * user can remove bundle from Journal and activity will be > > > preserved(and vise versa) > > > * activities could not have bundles in journal(were deleted or its a > > > system wide activity), so user can't copy activity(e.g. to share it via > > > USB stick) using regular shell workflow(Journal) and should be aware of > > > stuff like Terminal > > > > I guess it depends on the UI, but I worry this would actually add > > confusion. Users would be prone to accidentally deleting the activity > > installation from their Journal when they think they are just deleting > > some work they have done in that activity. > > I guess it relates to another forkflow which is proposed by [2], > bookmarks from [2] is just a set of objects(I think it could be useful > e.g. having fast method to access to some tricky query or for sharing > objects from bookmarks, to not share all objects), so user can > delete/change object from bookmark or from full Journal View and that > shouldn't confuse him(I hope) if he will keep in mind that he is > working with the same object(but from different views) all time. > In that case, having Home view(which is not "just another view") and > Journal with bundles could be really confusing. > > [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model In fact it(user all time work with the same object but from different views) is the same intention as [3](user all time work with the same type of files out of sugar environment). [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 05:50:59PM +, Aleksey Lim wrote: > On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: > > On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: > > >Once 0install support gets merged, Sugar Platform should be enhanced to > > >include build tools (autocrap, c(++) compiler, ...); in that case, > > >activity authors can also rely on the corresponding -dev(el) packages > > >(i.e. libraries, header files, etc.) to be installed as well. > > > > I have not followed the discussions on 0install, but it surprises me > > that this should be mandatory - I always considered 0install as > > comparable to a distribution. > > afaik there is no plans to "switch" to 0install, in my mind its an > edition[1] to existed scheme(but if we accept this feature we should > have 0install injector library in SP), so using 0install dependencies > we won't extend Sugar Platform too much > > [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary btw 0install could install native packages as well, the reason to use 0install(instead of another distro agnostic method to install distro packages) is that w/ 0install we can install packages that are not well packaged and activity specific binaries. [2] http://0install.net/tests/Gimp-native.xml > > I might loose interest in Sugar if 0install becomes integral part of > > core Sugar. But that's another discussion. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Mon, Nov 30, 2009 at 03:10:29PM +, Aleksey Lim wrote: > On Sun, Nov 29, 2009 at 05:50:59PM +0000, Aleksey Lim wrote: > > On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: > > > On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: > > > >Once 0install support gets merged, Sugar Platform should be enhanced to > > > >include build tools (autocrap, c(++) compiler, ...); in that case, > > > >activity authors can also rely on the corresponding -dev(el) packages > > > >(i.e. libraries, header files, etc.) to be installed as well. > > > > > > I have not followed the discussions on 0install, but it surprises me > > > that this should be mandatory - I always considered 0install as > > > comparable to a distribution. > > > > afaik there is no plans to "switch" to 0install, in my mind its an > > edition[1] to existed scheme(but if we accept this feature we should > > have 0install injector library in SP), so using 0install dependencies > > we won't extend Sugar Platform too much > > > > [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary > > btw 0install could install native packages as well, the reason to > use 0install(instead of another distro agnostic method to install distro > packages) is that w/ 0install we can install packages that are not well > packaged and activity specific binaries. > > [2] http://0install.net/tests/Gimp-native.xml oops, looks like it only starts applications not install them but imho could be useful too > > > I might loose interest in Sugar if 0install becomes integral part of > > > core Sugar. But that's another discussion. > > -- > Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: > On 11/30/2009 10:00 AM, Bert Freudenberg wrote: > > On 29.11.2009, at 20:50, Simon Schampijer wrote: > >> > >> > >> Well, if an activity will work for an older release is not only > >> determined by the activity version number. For example, activities that > >> moved to the new toolbar design are not working for older releases< > >> 0.86. I don't think we can always avoid breaking backwards compatibility. > > > > But so far we have managed to make is at least *possible* for an activity > > author to have a single activity version run under all Sugar versions. This > > would be the first instance where the author would not have that chance. > > > > I'm pretty sure we can find a scheme that both allows a single activity > > bundle to provide dotted version numbers for new Sugar, but keep working in > > old Sugar. > > > > E.g., we do not have to re-use the "activity_version" field if that breaks > > the parsing in older versions. It could be a new field named > > "dotted_activity_version" or simply "version" or something else. An > > activity author who cared could then provide both, a decimal and a dotted > > activity version. > > > > - Bert - > > Sorry, for the mixup. Yes we could add a way for the dotted version > number, and your idea sounds good. How does Bert's idea from above > sounds to others? +1, but maybe use "activity_release"(or so) instead of "dotted_activity_version", the full version in 0.88+ will be .? > My point was, that we do not have to be backwards compatible at all > costs (this was a general assumption). > > Thanks, > Simon > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] aslo -> CDN
On Mon, Nov 30, 2009 at 02:17:20PM -0500, Bernie Innocenti wrote: > [cc += sugar-de...@] > > On Thu, 2009-11-26 at 08:44 -0600, dfarn...@sugarlabs.org wrote: > > Many people have access to the upload directory. > > We could mitigate this by using separate groups. We already use a soas > group for soas. > > Besides, do the activity authors still need to upload source tarballs > here? Couldn't this be done with Remora? yup, I thought to add such functionality after getting rid of fructose but it could be implemented anyway > If not, couldn't we set release tags on Gitorious and download the > tarballs from cgit? I know release tarballs sometimes contain more files > than just a git snapshot, but it would work for most activities. > > > > My thought is to > > start moving towards a staging directory layer. Individuals will have > > assess to specific staging directories. From there, a cron job can > > sync from staging/ to downloads/ . > > If the script just moves the files over without any additional checking, > security would remain unchanged. > > One possibility is requiring all files to be gpg signed by the author, > but this makes things quite complicated: most developers do not seem to > be familiar with gpg, and we'd still have to come up with some fancy ACL > system based on the gpg key. > > It would be much easier if Remora could be configured or extended to > distribute all our source tarballs too. > > -- >// Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 07:58:57PM +, Daniel Drake wrote:
> 2009/11/30 Wade Brainerd :
> > I disagree that showing activities in the Journal, in addition to
> > activity instances and MIME objects, will cause confusion. Many
> > activities are more like content. Activities can be downloaded,
> > copied, modified, and deleted. In Sugar terminology, Activities are
> > intended to be verbs while Journal objects are like proper nouns. But
> > if an activity is a verb, the object which performs the activity can
> > still be a noun. For example, the word "hammer" is both a noun and a
> > verb. The noun in the Journal ("Hammer.xo") is an object which
> > enables the verb in the Home view ("Hammer Activity"). It's quite
> > simple.
>
> I agree. I find it simple too. I'd have no problem with it.
>
> The problem is when you give it to 6 year olds -- do you also expect
> them to be able to understand this?
>
> Have you followed the number of problems caused to deployments by the
> activity removal feature that was added to sugar-0.82? The children do
> this because they think they are removing work created with the
> activity.
I think it relates to "Low floor no ceiling" but we can try to solve
such issues for example by having profiles for different age ranges.
BTW declaring that "The majority of our users are 12 years old or under"
it could be useful to have a voice from teachers(even rather then
deployers) while discussing users experience invasive features(or add
new features according to teachers feedback).
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 07:18:47PM -0500, Walter Bender wrote: > On Mon, Nov 30, 2009 at 2:54 PM, Daniel Drake wrote: > > 2009/11/30 Walter Bender : > >> This isn't quite accurate. We've been adding some pre-loaded content > >> to the Journal for quite some time now, > > > > Are you sure? Or are you referring to a manual process that you do in > > certain deployments? > > > > I have yet to see a sugar installation that comes with a non-empty > > journal. And also I can't think of any non-horrible way that you'd be > > able to hook into the sugar profile creation stages to pre-provide the > > content, even if I did like the idea. > > Many deployments are doing this in some fashion or another. It is > currently an ugly kludge. This proposal will presumable make it less > ugly and less kludgy, but it is undoubtedly useful. > > >> and some activities (as you > >> noted, Turtle Art) have been adding content to the Journal as well. > > > > This is the only one I'm aware of, and it was a big surprise, to the > > extent that I filed bugs upstream and downstream that were confirmed > > by other people who also didn't realise this. I also got the > > impression from you that you don't feel like it is the appropriate > > place to put it, you just did it because it is the only option. > > On the contrary. I don't like it because it is clumsy to implement and > manage. Again, this proposal will address that. What I don't like is > having to keep my examples in the file system and use a file browser > to retrieve them. It turns out that because they are kept separately, > people don't find them. well, there is another proposal which was already mentioned here http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model so, with this feature implemented, user can create bookmark "My TurtleArt programs"(with query by activity id) > I could implement my only browser, a la Pippy, > but as an activity developer, I would much prefer to use the Journal > and I suspect our users would prefer that as well. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] OLPC updates from ASLO
Hi all, AFAIK OLPC will use 0.84 release and will lack of native sugar updater but it could be useful idea to keep activities repository in one place. So, the question is will html page which lists all ASLO activities in microformat enough for OLPC updater. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OLPC updates from ASLO
On Tue, Dec 01, 2009 at 07:51:32AM +, Daniel Drake wrote: > 2009/12/1 Aleksey Lim : > > AFAIK OLPC will use 0.84 release and will lack of native sugar updater > > but it could be useful idea to keep activities repository in one place. > > We are using the sugar control panel applet for activity updates as we > have done before. > > > So, the question is will html page which lists all ASLO activities in > > microformat enough for OLPC updater. > > Having the microformat on ASLO would be great and I never understood > why this wasn't the approach taken in the first place, rather than the > considerable task of adding some strange XML format support to the > updater applet for later versions. > > The great thing about the microformat is that not only did it provide > an interface for those of us single-users who have fast internet > connections, it was designed inherently for simplicity, scalability > and replication, and came with a decent amount of documentation of how > you would replicate this on a deployment. The XML thing seems to be > lacking in those areas. > > However I think there are 2 additional things that would block moving > the activity group to ASLO: > 1. It's not possible to create a group with specific locked versions, > right? One reason for doing it separately is that we want to control > the flow of activity updates pushed to customers. I'm concerned that > activities are not seeing much QA or testing and regressions are too > easy to come by. I'm also concerned that the amount of testing that > developers do on 0.84 before marking activities as 0.84-compatible > will decrease over the next few months/years. ASLO has several levels of "QA", all public activities(reviewed by editors) should work(w/o obvious faults), public activities could be featured by editor, editor collections of public activities. So, we can utilize this scheme for OLPC needs. > 2. No content bundle support Yeah, but thats the question should we mix activities and other kinds of sugar objects. Different types could require different UI or different uploading scheme. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.87.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.87.1.tar.bz2 == News == * Make reading version file more robust (sayamindu) #1562 * Use gobject_timeout_add_seconds to make power usage more efficient (sayamindu) #1567 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] [REQUEST] Etoys-113
On Tue, Dec 01, 2009 at 09:08:10PM +0100, Bert Freudenberg wrote: > On 01.12.2009, at 21:05, Aleksey Lim wrote: > > > > On Tue, Dec 01, 2009 at 08:54:26PM +0100, Bert Freudenberg wrote: > >> On 01.12.2009, at 20:42, Aleksey Lim wrote: > >>> > >>> On Tue, Dec 01, 2009 at 12:34:35PM -0600, dfarn...@sugarlabs.org wrote: > >>>> On Tue, Dec 1, 2009 at 12:27 PM, Bert Freudenberg > >>>> wrote: > >>>>> On 01.12.2009, at 18:52, Sugar Labs Activities wrote: > >>>>>> > >>>>>> A Sugar Labs Activities Editor requested further information from you > >>>>>> regarding version 113 of your activity Etoys. > >>>>>> > >>>>>> Aleksey Lim wrote: > >>>>>> > >>>>>> "This activity works with 0.82 as well but previous version was only > >>>>>> 0.84. > >>>>> > >>>>> I can't remember releasing the previous version for 0.84 only. > >>>>> > >>>>> And wouldn't marking the new bundle as only for 0.86 give the > >>>>> impression it does not work in earlier releases? > >>>>> > >>>>> OTOH since it is pre-installed anyway it doesn't really matter. If you > >>>>> think marking it for 0.86 only is better, feel free to do so. > >>>>> > >>>>>> And since its only startup wrapper maybe it makes sense to keep this > >>>>>> activity per sugar release(to not confuse users when they see etoys > >>>>>> "last" version in Home view)?" > >>>>> > >>>>> Well I'm confused. Doesn't the updater respect the bundle's update_url? > >>>>> What does the updater have to do with a.sl.o? > >>>> > >>>> As of .86 sugar ships with a aslo-updater. The updater pings a.sl.o to > >>>> see if any new versions of installed activities exist. > >>> > >>> at the end it depends on what the right version of etoys+etoys-activity > >>> (keeping in mind that sugar user can see only etoys-activity version) > >>> e.g. 0.82 user can install(since v133 was marked 0.82-0.86) v133 and > >>> will see Etoys-133 in Home view but etoys will be the same(from > >>> sucrose-0.82). > >> > >> Except neither 0.82 nor 0.84 pay attention to a.sl.o. Only 0.86 does - > >> that's when the new updater was introduced, right? > > > > but user can install activity manually from ASLO > > And ASLO hides versions based on the browser's user-agent? Is this documented > anywhere? it was mentioned in [ASLO] announce email > We should move this conversation to sugar-devel ... the full picture is, there are two methods to install activity from ASLO: * ASLO updater which was introduced in 0.86, it checks all locally installed activities for updates on ASLO by passing bundle_id and sugar version(so ASLO, using activities SP range, returns last versions for proper SP) * any user can manually install activity version * all fast "Download" buttons let user download proper(to his SP, assuming what activity developer filled to SP range for particular version) activity version(ASLO calculates SP version from useragent string) * user can download any version from activity history page (page has relevant warning) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OLPC updates from ASLO
On Tue, Dec 01, 2009 at 09:08:29PM +0100, Bert Freudenberg wrote: > On 01.12.2009, at 18:13, Aleksey Lim wrote: > > > > On Tue, Dec 01, 2009 at 07:51:32AM +, Daniel Drake wrote: > >> 2009/12/1 Aleksey Lim : > >>> AFAIK OLPC will use 0.84 release and will lack of native sugar updater > >>> but it could be useful idea to keep activities repository in one place. > >> > >> We are using the sugar control panel applet for activity updates as we > >> have done before. > >> > >>> So, the question is will html page which lists all ASLO activities in > >>> microformat enough for OLPC updater. > >> > >> Having the microformat on ASLO would be great and I never understood > >> why this wasn't the approach taken in the first place, rather than the > >> considerable task of adding some strange XML format support to the > >> updater applet for later versions. > >> > >> The great thing about the microformat is that not only did it provide > >> an interface for those of us single-users who have fast internet > >> connections, it was designed inherently for simplicity, scalability > >> and replication, and came with a decent amount of documentation of how > >> you would replicate this on a deployment. The XML thing seems to be > >> lacking in those areas. > >> > >> However I think there are 2 additional things that would block moving > >> the activity group to ASLO: > >> 1. It's not possible to create a group with specific locked versions, > >> right? One reason for doing it separately is that we want to control > >> the flow of activity updates pushed to customers. I'm concerned that > >> activities are not seeing much QA or testing and regressions are too > >> easy to come by. I'm also concerned that the amount of testing that > >> developers do on 0.84 before marking activities as 0.84-compatible > >> will decrease over the next few months/years. > > > > ASLO has several levels of "QA", all public activities(reviewed by > > editors) should work(w/o obvious faults), public activities could be > > featured by editor, editor collections of public activities. So, we can > > utilize this scheme for OLPC needs. > > > >> 2. No content bundle support > > > > Yeah, but thats the question should we mix activities and other kinds > > of sugar objects. Different types could require different UI or > > different uploading scheme. > > > > -- > > Aleksey > > This new update scheme came as a surprise to me too. Guess I have not payed > enough attention. > > Does it completely ignore the bundle's update_url? > > Is there any documentation for activity authors besides the feature proposal? > > http://wiki.sugarlabs.org/go/Features/Sugar_Update_Control_ASLO it works how its described on wiki > At least the example given there does not seem to work: > > > http://activities.sugarlabs.org/services/update.php?id=org.laptop.WebActivity&appVersion=0.86 > > It returns a basically empty XML file. oops, sorry - outdated url -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
