Re: [Sugar-devel] [SoaS] The next Step: v2 Roadmap
On Sun, Jul 05, 2009 at 12:51:22AM +0200, Sebastian Dziallas wrote: > Hi everybody, > > so here it is, the Sugar on a Stick v2 Roadmap: > > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Roadmap > > Feedback is appreciated, and as we've just entered brainstorming phase, > please go ahead and shoot your ideas! :) More to come... For F12 (not beyond), what is the advantage of using RPMs to distribute Fructose[1], given OLPC is not[2]? > --Sebastian Martin 1. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Fructose_modules_.28F11.29 2. http://www.mail-archive.com/de...@lists.laptop.org/msg19673.html pgpYHOC0doeow.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
On Sat, Jul 04, 2009 at 05:43:38PM +0200, James Michael DuPont wrote: The report is with jhbuild on debian jaunty. I built it from scratch. Started with jhbuild run I guess you mean Ubuntu Jaunty. How did you build? Can you give the exact commands you used to build and run, please? What does "./sugar-jhbuild depscheck" say? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
Sascha, It build and installed all according to the instructions. I dont have this all here at the moment as I said. If you have any questions, you can see my build snapshot, that contains everything. I have put 2 days of work and finally got it running on ubuntu, you can see the patches. You can find many bug reports of sugar on ubuntu and others. I dont know of anyone who sugar works. Everyone who tried the packages complained of problems. How come this is so difficult? How come you guys dont test the packages yourself? Installing ubuntu takes about 30 minutes. You can run it it on a virtual machine. Can you tell me of sugar working on any distro out of the box? are there any success stories? I really cannot find anything on ubuntu except wiki pages that are out of date. Sorry, but this is very frustrating. thanks mike On Sun, Jul 5, 2009 at 6:20 PM, Sascha Silbe < sascha-ml-ui-sugar-de...@silbe.org> wrote: > On Sat, Jul 04, 2009 at 05:43:38PM +0200, James Michael DuPont wrote: > > The report is with jhbuild on debian jaunty. I built it from scratch. >> Started with jhbuild run >> > I guess you mean Ubuntu Jaunty. How did you build? Can you give the exact > commands you used to build and run, please? What does "./sugar-jhbuild > depscheck" say? > > > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKUNK5AAoJELpz82VMF3DaLTEH/16qsq91tQXDkjEXqDZNyZ64 > vtVfD/4qw2DYLQXrXyAnnTyng0JiS7jUGrktPeD2bh5K+pGWuMv+K7f9wEP1l8t8 > lztCXwx/bquw/5h3N7my/ERPNa4pCyiflwLNuHSnnFNv39WEt49Jazfz3eGZFOJp > 3g7dk+Aw1NVW32Sxk4obvy7ZzEBK78kuDdgd9pe8PcXkQ4js58GDjKWVgYeWu257 > FNnrPsJQtCaPLamdmHmcznExO/NAJCBp1X9/fqDTcc6cQ5xGpbIxCEug0Op/qaM3 > 4/gp7CLPDVmV5uJdeycAO1J2CrpMCSqGZGhzclTcOixA0NbBXysg3u7ei67NMrI= > =0g20 > -END PGP SIGNATURE- > > -- James Michael DuPont Founding Board Member Free/Libre Open Source Software Kosova FLOSSK ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
On Sun, Jul 05, 2009 at 08:25:16PM +0200, James Michael DuPont wrote: Sascha, It build and installed all according to the instructions. Which instructions specifically? I dont have this all here at the moment as I said. If you have any questions, you can see my build snapshot, that contains everything. Unfortunately a build tree is a bit unwieldy to examine manually and also does not show the commands you used. I could at least verify you're using the right version of sugar-jhbuild, though. I have put 2 days of work and finally got it running on ubuntu, you can see the patches. That is _way_ too much. sugar-jhbuild should work exactly as described on [2] for any of the supported distros (Debian squeeze/sid, Ubuntu Intrepid/Jaunty, Fedora 10/11/12). I regularly check this myself, in addition to the buildbots [1] doing automatic builds. There's something seriously wrong with your installation, so please let's find the problem before you waste another day encountering bugs that are caused by the same root issue. I'll try to be on IRC (#sugar on irc.freenode.net) tomorrow, so maybe we can figure it out interactively. You can find many bug reports of sugar on ubuntu and others. I dont know of anyone who sugar works. Everyone who tried the packages complained of problems. Sorry, I'm confused now. Are you talking about sugar-jhbuild or about the Sugar packages included in Ubuntu? Those are two entirely separate things (and shouldn't be mixed). Is it possible you installed both in parallel? If you did that might very well be the reason for your problems. How come this is so difficult? How come you guys dont test the packages yourself? Installing ubuntu takes about 30 minutes. You can run it it on a virtual machine. I do test sugar-jhbuild on all of the supported distros. I even use sugar-jhbuild on Debian squeeze regularly myself (as a user). What I don't do is testing the distro-supplied packages as that's the respective distro maintainers job. Can you tell me of sugar working on any distro out of the box? You might want to try Sugar on a Stick [3]. I really cannot find anything on ubuntu except wiki pages that are out of date. Where did you find those out of date pages? I tried to clean up all sugar-jhbuild related pages but have obviously overlooked some. [1] http://buildbot.sugarlabs.org/ [2] http://wiki.sugarlabs.org/go/Development_Team/Jhbuild [3] http://wiki.sugarlabs.org/go/SoaS CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugarcamp - November 7th-12th 2009 ?
On 07/01/2009 05:38 PM, David Farning wrote: > On Wed, Jul 1, 2009 at 6:41 AM, Simon Schampijer wrote: >> On 07/01/2009 12:49 AM, David Farning wrote: >>> On Tue, Jun 30, 2009 at 5:45 PM, Simon Schampijer >>> wrote: On 06/29/2009 10:09 PM, David Farning wrote: > On Mon, Jun 29, 2009 at 9:55 AM, Simon Schampijer > wrote: >> Hi, >> >> the SFScon 2009 will be held in Bolzano [1]. As part of that the TIS[2] >> would be willing host a Sugarcamp. The camp would be part of the free >> software week [3], where a GNOME Hackfest will happen as well. >> >> It fits quite well in our release cycle (0.88 planning/hacking) and >> having the GNOME Hackfest next door would create nice synergies. We >> would start on a weekend to have better chances on getting (students >> and >> people who have to work during the week) everyone a chance to attend. >> >> How does that sound? > Sounds good. > > Any one in mind to champion the event? > Do you have a point of contact with event organizers so we can start > working on the admin? >>> I'll help. But based on LinuxTag you seem to have event organization >>> pretty much figured out. >>> >>> david >> The Sugarcamp will be a different event than Linuxtag. Linuxtag was a show >> where you have to setup gear and get promotion material together, the camp >> is more planning what you want to discuss during those days. > > Having participated in SugarCamp Paris and some FudCons. How do you > feel about the participant led format of the event? > > FWIW, SugarCamp Paris was intentional in it's lack of pre-organization > to break from the 'Sage on Stage' broadcasting to the unwashed masses > nature of previous Sugar Labs meetings. I like how Fudcon handles it - that would be a good way to go for me. It is good to announce some topics - so interested people have the possibility to join. And - we should see what the GNOME people are up to, too. http://fedoraproject.org/wiki/FUDCon/Organization Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Read Activity question (single page view)
Hi Sayamindu, Saw some of your Read roadmap items today, and just wanted to ping and ask how viable you think it would be for Read to support a single page by page view for PDFs (rather than current continuous scrolling mode)? I've been thinking it would be better for memory consumption (continuous scrolling has to have both pages rendered in memory as you scroll over page boundaries), and also would be better for page by page reading for many books, presentations (Sameer Verma mentioned this in an IAEP mail today), and I'm working on some pdf materials like the old adventure book stories, where you traverse different pages in a non-linear way (works a bit like a point and click adventure/escape-the-room type thing). Does evince support single page render mode? If you think it's viable, but don't have the time yourself, let me know and I'll see if I can get something working here (never used evince myself so wanted to check with you first before I head off down a blind alley). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
Ok, I mean the ubunutu and fedora packages are broken. Jhbuild, we will have to go through this together when I am online. this latop cannot even begin to use jhbuild, it is an aspire one. 512 mb or ram and no space left. I am sorry to be so frustrated, but it is too much to ask normal users to use jhbuild. I hope to help clean up the packages and as soon as we figure out the problems, I will help patch the errors. It is just interesting that the errors with the icons are showing up on all systems, the errors are not seriously wrong, it is a simple patch. more tomorrow, I look forward to working with you to make sugar run out of the box on ubuntu. that will help get more users and will help the project in the long run. thanks, mike On Sun, Jul 5, 2009 at 9:56 PM, Sascha Silbe < sascha-ml-ui-sugar-de...@silbe.org> wrote: > On Sun, Jul 05, 2009 at 08:25:16PM +0200, James Michael DuPont wrote: > > Sascha, >> It build and installed all according to the instructions. >> > Which instructions specifically? > > I dont have this all here at the moment as I said. If you have any >> questions, you can see my build snapshot, that contains everything. >> > Unfortunately a build tree is a bit unwieldy to examine manually and also > does not show the commands you used. I could at least verify you're using > the right version of sugar-jhbuild, though. > > I have put 2 days of work and finally got it running on ubuntu, you can >> see >> the patches. >> > That is _way_ too much. sugar-jhbuild should work exactly as described on > [2] for any of the supported distros (Debian squeeze/sid, Ubuntu > Intrepid/Jaunty, Fedora 10/11/12). I regularly check this myself, in > addition to the buildbots [1] doing automatic builds. > There's something seriously wrong with your installation, so please let's > find the problem before you waste another day encountering bugs that are > caused by the same root issue. > I'll try to be on IRC (#sugar on irc.freenode.net) tomorrow, so maybe we > can figure it out interactively. > > You can find many bug reports of sugar on ubuntu and others. I dont know >> of >> anyone who sugar works. Everyone who tried the packages complained of >> problems. >> > Sorry, I'm confused now. Are you talking about sugar-jhbuild or about the > Sugar packages included in Ubuntu? Those are two entirely separate things > (and shouldn't be mixed). > Is it possible you installed both in parallel? If you did that might very > well be the reason for your problems. > > How come this is so difficult? How come you guys dont test the packages >> yourself? >> Installing ubuntu takes about 30 minutes. You can run it it on a virtual >> machine. >> > I do test sugar-jhbuild on all of the supported distros. I even use > sugar-jhbuild on Debian squeeze regularly myself (as a user). > What I don't do is testing the distro-supplied packages as that's the > respective distro maintainers job. > > Can you tell me of sugar working on any distro out of the box? >> > You might want to try Sugar on a Stick [3]. > > I really cannot find anything on ubuntu except wiki pages that are out of >> date. >> > Where did you find those out of date pages? I tried to clean up all > sugar-jhbuild related pages but have obviously overlooked some. > > > [1] http://buildbot.sugarlabs.org/ > [2] http://wiki.sugarlabs.org/go/Development_Team/Jhbuild > [3] http://wiki.sugarlabs.org/go/SoaS > > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKUQVlAAoJELpz82VMF3Da/1IH/3C7up8MRNUyhvskaPYhGQMg > cQoo5/QTyk5WGZH/Cp1MA6nO7S9V0gkXa54j/xI0iZ+waQJSMrP1Sw/Q9qU7XJbY > APT12LF3FpsFPbk+ctRq078Nm4UarrkYbODUdkjX2SgWq9U4da/APB5/DtkvrWVq > QtOQ7rA77fIq6xfUKDt0A/rgIZFi+DttHhwNwJfLZNkls3edcdYH+1JWRlw3SzY9 > bfa4qoHvdGg5VpYZ7mD+PiGNPaWLKaxzJTZjNGuTCcyGYZcBeZPtVrHF0Zif7kIu > AuoQFx9h5Z3X5cdwBaMOTXh7fzMCntGQWXQn9OQvWWgSvvXyEOtYCJwq5VIgj7A= > =mMfq > -END PGP SIGNATURE- > > -- James Michael DuPont Founding Board Member Free/Libre Open Source Software Kosova FLOSSK ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Trimming down long wiki names
To continue trimming long wiki names, I propose to shift the Human Interface Guidelines branch, http://wiki.sugarlabs.org/go/Design_Team/Human_Interface_Guidelines, to the wiki root, http://wiki.sugarlabs.org/index.php?title=Human_Interface_Guidelines&redirect=no . This will help to make the http://wiki.sugarlabs.org/go/Design_Team#Subpagessection more usable. I'll keep key redirect pages for external links. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Datastore redesign
Hi! After reading the recent threads about Journal / data store and the IDs used by them the big picture is much more clear now, thanks! I've adjusted by datastore redesign proposal [1] accordingly and would like to submit it for review now. It's not clear a full redesign is The Right Thing to do now, but I'd rather like to specify what it should look like, not what steps to take next towards it. There's an important design decision that's still open: Is the asynchronous API design useful enough to warrant more complex implementation? - DBus operations can be run asynchronously so UI responsiveness shouldn't be an issue - For save() calls activity needs to wait for result (containing new version_id) before it can invoke save() again for the same object which can take quite some time if save() is sync - especially if other activities are saving at the same time. Making the API fully asynchronous is the cause for much of the complexity of my proposal, but if we eliminate the queueing the response times for write accesses and checkout() can be very long even for unrelated operations. [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
On Sun, Jul 05, 2009 at 10:19:51PM +0200, James Michael DuPont wrote: Ok, I mean the ubunutu and fedora packages are broken. OK, cannot say anything about that as I've stopped using distro packages quite some time ago. 0.82 never really worked for me and 0.84 wasn't available as distro packages back then. AFAIK SoaS uses the distro packages from Fedora 11 so those should be working fine, though. Jhbuild, we will have to go through this together when I am online. this latop cannot even begin to use jhbuild, it is an aspire one. 512 mb or ram and no space left. None of the hosts I'm running sugar-jhbuild on has more than 512MB of RAM, whether physical (my non-XO Laptop) or simulated (for the virtual machines I use for testing). The XO (running sugar-jhbuild on Debian squeeze) even has only 256MB, a slow processor (AMD Geode) and is running from a 16GB SDHC card (the card itself is quite fast, but the SD interface in the XO is abysmally slow). The last rebuild that included xulrunner (we now use the distro package instead) took a full night. I am sorry to be so frustrated, but it is too much to ask normal users to use jhbuild. Ideally normal users would use the distro packages. That these are outdated and/or don't work is something that needs to be and AFAICT is in the process of being fixed, e.g. Sugar 0.84 has now entered Debian squeeze thanks to Jonas. OpenSuSE should have recent, working packages as well (thanks to David van Assche). more tomorrow, I look forward to working with you to make sugar run out of the box on ubuntu. Looking forward to that as well. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore API changes
On Sat, Jul 04, 2009 at 03:44:05PM +0200, Tomeu Vizoso wrote: The client side can know which python exception was raised in the server side and do whatever it can to best handle it. How does this work? I can't image DBus to transparently pass through Python exceptions. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sucrose 0.85.1 Tarballs Due
Dear Sucrose Maintainers, please provide source tarballs for the Sucrose 0.85.1 Development Release [1] by the end of the 9th of July and announce them as explained here at [2]. Thanks, Your Release Team [1] http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap#Schedule [2] http://wiki.sugarlabs.org/go/Development_Team/Release#Module_release ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore API changes
On Sat, Jul 04, 2009 at 03:53:32PM +0200, Tomeu Vizoso wrote: Another risk could be leaking inodes if we get a too complex hard-link structure. This should only happen on crashes as we're only keeping the VCS "copy" of the files, everything else is ephemeral. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Trimming down ling wiki names
On 07/04/2009 12:40 AM, Frederick Grose wrote: > On Thu, Jul 2, 2009 at 9:06 AM, Frederick Grosewrote: > >> On Thu, Jul 2, 2009 at 7:45 AM, Simon Schampijerwrote: >> >>> Hi Fred, >>> >>> it might makes sense to trim down our long wiki names. As we heavily use >>> categories now - this might not be an issue. How about we do: >>> >>> http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 -> >>> http://wiki.sugarlabs.org/go/0.84/Roadmap >>> >>> and >>> >>> >>> http://wiki.sugarlabs.org/go/Development_Team/Release/Releases/Sucrose/0.84-> >>> http://wiki.sugarlabs.org/go/0.84/Notes >>> >>> same for 0.82 and 0.86. >>> >>> What do you think? Can you do this without breaking current links? >>> >>> Regards, >>>Simon >> >> That should be possible and fits with the idea that DFarning reported of >> broadening the involvement in the platform development. >> >> I'll start with 0.82, http://wiki.sugarlabs.org/go/0.82, and leave wiki >> redirects to catch those linking from off-site links in blogs and other >> references. >> >> --Fred >> > > I've moved the Development Team/Releases branch to branches beginning with > 0.82, 0.84, 0.86,& 0.88 (the stable branches). See now that > http://wiki.sugarlabs.org/go/Development_Team#Platform_Release_Cycles and > #/Subpages are a bit more readable. > > I seem to have lost > http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 (notice > that it redirects to 0.86/Roadmap). Perhaps it was never saved, but only > transformed into the 0.86 roadmap. > > --Fred Hmmm, I think I have saved it :/ The history of the file does not show any sign of being overwritten. I guess we lost it. The rest - does work all fine. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick - and OLPCsound/Csound
As mentioned by a member of the sugar-devel list, it seems that a csound (5.10) install (yum install csound), does not install several crucial site-specific and library packages (csnd, _csnd, libcsnd and perhaps libcsound). Having to erase olpcsound before installing csound deletes these files and they don't get restored/reinstalled. So, to the procedures described below, before erasing olpcsound, I saved the above-listed files (there were 5 or 6), and once csound was installed, added them back where they came from. This crude procedure didn't work, and the following error log is quite like the one I started with: /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha Traceback (most recent call last): File "/usr/bin/sugar-activity", line 21, in main.main() File "/usr/lib/python2.6/site-packages/sugar/activity/main.py", line 105, in main module = __import__(module_name) File "/home/liveuser/Activities/OurMusic.activity/ourmusic.py", line 41, in import csndsugui File "/home/liveuser/Activities/OurMusic.activity/csndsugui.py", line 36, in import csnd File "/usr/lib/python2.6/site-packages/csnd.py", line 7, in import _csnd ImportError: /usr/lib/libcsnd.so.5.1: undefined symbol: csoundGetInputBuffer I'd appreciate any suggestions as to how to get this all working. Thanks. Art Hunkins - Original Message - From: Art Hunkins To: pbrobin...@gmail.com Cc: cso...@lists.bath.ac.uk ; sugar-devel@lists.sugarlabs.org Sent: Friday, July 03, 2009 7:57 PM Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound I've just noted that the /usr/lib/python2.6/site-packages folder does not include csnd.py. That folder also contains many fewer files that the corresponding one in python2.5. As a matter of fact, python2.5 seems about a third the size of 2.6. Is all this correct? Art Hunkins - Original Message - From: Art Hunkins To: pbrobin...@gmail.com Sent: Friday, July 03, 2009 6:13 PM Subject: Fw: [Cs-dev] Sugar on a Stick - and OLPCsound Hello, Peter, Do you know what may be happening here? (Please see error log below.) I've no idea why the module referenced (csd.py) is not found. Please also compare the log at the very bottom of this mail; this latter log was generated when running Csound*5.08*, also with python2.6. Thanks for any insights. Art Hunkins - Original Message - From: Art Hunkins To: Developer discussions Cc: cso...@lists.bath.ac.uk Sent: Friday, July 03, 2009 5:36 PM Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound Here's the *next* chapter in the saga. Please note that this is not the *Windows* installation saga; it's the *Linux/Sugar* installation saga. In our last episode, we noted that Csound5.08 was (apparently?) incompatible with python2.6. At least this seemed a plausible explanation from the error log we saw. So, now Csound5.10 is available on Fedora(11) for download to SoaS. First, I try update csound; "can't find any csound". Second, install csound; it tries, but then says, "can't because it interferes with olpcsound" (OK, different name!) Third, erase olpcsound; good Fourth, install csound; good Then I run my Activity; it now crashes with the similar, but not exact, error log below. I thought perhaps I'd better start from scratch and did (reformat USB drive, etc). Thought probably the new SoaS iso incorporated Csound5.10. But no, I needed to essentially repeat the above steps, and ended with the same crash. The log: (any new ideas please?) /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha Traceback (most recent call last): File "/usr/bin/sugar-activity", line 21, in main.main() File "/usr/lib/python2.6/site-packages/sugar/activity/main.py", line 105, in main module = __import__(module_name) File "/home/liveuser/Activities/OurMusic.activity/ourmusic.py", line 41, in import csndsugui File "/home/liveuser/Activities/OurMusic.activity/csndsugui.py", line 36, in import csnd ImportError: No module named csnd Art Hunkins - Original Message - From: victor To: Art Hunkins ; Developer discussions Sent: Wednesday, July 01, 2009 1:36 PM Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound Because the 5.10 rpm has a python2.6 dependency. But that might be the case for 5.08 too (I am not sure). - Original Message - From: Art Hunkins To: Developer discussions Sent: Tuesday, June 30, 2009 2:22 AM Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound I just noticed that the current OLPC build includes Python 2.5, whereas SoaS
Re: [Sugar-devel] Trimming down ling wiki names
On Sun, Jul 5, 2009 at 5:17 PM, Simon Schampijer wrote: > ... I guess we lost it. > Reconstructed from the Google cache for 16 June 2009, http://wiki.sugarlabs.org/go/0.84/Roadmap. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 04:19, Eben Eliason wrote: > I'll throw this idea back out there for fun, too. I don't know if > there's a way to do even this without adding too much complexity, but > we did make some mockups of an "advanced" sort bar, which instead of > sorting on columns allowed creation of hierarchical sorting by > metadata. For example, I could use the "what" filter to select "audio" > files, and then use the sort bar to say: "sort by artist, then by > album, then by track". Any Journal entries which had metadata keys for > "artist", "album", and "track" would then appear sorted accordingly, > and the section dividers would show the values for the various keys so > that the hierarchy was logically browsable. > > It's a powerful idea, but so far we just haven't thought it to be > worth the added complexity. Keeping the Journal as simple to use as > possible is paramount. I'll maybe try have a go at a simple mock-up. Could either be part of a row titling the current columns, as in a subtle little arrow button with several sort by options in it – "sort by modified", "sort by created", "sort by size". Or perhaps as a regular button & palette in the toolbar (though toolbar is filling up fast with icons and is likely too 'featureitus' scary already in my mock-ups). > Something I would like to explore, > though, is exposing metadata within the detail pages of Journal > entries. It would be neat, for instance, if photos taken in record > actually had a "photographer: " label in the details, to > make the detail view more useful and to enhance the detail view for > specific kinds of objects. I have some neat mockups showing a possible > UI for this. I'll try to dig them up. +1, the details page is out of the way and could do with some more actual details (entry file size being the currently most useful I've seen go by so far). > Perhaps we could somehow represent "type" by showing a stack of the > generic type > documents. Maybe it would have the "data" icon on the front page, but > visually have a few documents in the stack. I'll play with it. Fab, thanks. > These are still separate in the current mockups, right? Yes. > There's basically an icon for each "key", where the possible keys > are "who", > "what", and "when", plus the generic search field. It's nice that all > of these filtering options are lined up at the top, and that it's > possible to add to the filter to narrow down on the search results by > adjusting more of the filters. Yep (though I'd like a quick way to clear a search rather than the current trawl through each filter). > PS. Gary, the mockups are looking good so far. I'll give some thought > to the icons, and try to dig up some of my past designs for bits and > pieces of this. Thanks. Having a bit of trouble with the when/anytime palette. If we want each toolbar icon to visually represent the filter, it means we need a series of icons for today, since yesterday, past week, past month, past year (have a few misc. icon ideas but not a sensible set to cover all). http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#When.2FAnytime_palette FWIW: There's also another shot at a possible tag cloud treatment: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Show_frequency_as_proportional_size Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 1 Jul 2009, at 11:36, Tomeu Vizoso wrote: > On Tue, Jun 30, 2009 at 19:02, Gary C Martin > wrote: >> Being Mr ActivityTeam at the moment, I do really worry about the >> amount of work this is going to be to get Activities updated and >> complying to a large toolbar redesign. Supporting both toolbar API >> styles will help, but I think we'll end up with multiple toolbar >> styles in different Activities for perhaps 6 months to a year or >> more. >> That's a bad backward step for usability. Just look at the amount of >> time/effort it is taking to migrate Activities over to SL >> infrastructure, let alone making anything but minor maintenance code >> changes to them. > > True, so what do you suggest here? No magic answers I'm afraid. I'm just saying... One thing we could do to try to move forward on the new toolbar concept is to build svg icons for as many of the tabs that are already in use. We need to come up with clear and identifiable icon for each **before** moving forward (not just the few obvious common cases view/edit/image/text/format/ colour/etc). Here's a quick trawl, not a full list. If we can't manage these, it would be unfair to expect Activity Authors to have any more success. Note: that some of these may need Activity specific variants, though we may be able to drop some if we are willing to redesign some Activities current UI: Algebra Audio Books Boolean Browse Chat Collaboration Comment Create Edit Effects Face Format Game Graph Help Image Learn Lessons Library Miscellaneous Montage Video Paint Photo Plain Play Project Read Robot Save/Load Shapes Slides Sort Tab Table Text Tools Trigonometry View Voice Watch I'm thinking the toolbar design as specced does not seem viable for the 0.86 time scale. Leaving us with the nasty issue trying to solve what I see as a current worst toolbar usability offender, "Stop button must be visible at all times." Perhaps a stop gap measure of placing the Activity stop button permanently in the sacrosanct top right corner? Can't believe I suggest that, but it's the best suggestion I have... Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] DNS Mischief
As many of you know, I've been fascinated for some time by Scott's Network
Principles [1].
Several weeks ago, I outlined in a lightly-circulated patch how one might hack
up libc's getaddrinfo() implementation to do the DNS resolution work described
in Scott's paper.
Here is a second copy of that patch, which I have improved to the point where I
am willing to recommend it for further testing, adaptation, and exploration.
(This new version uses libcrypt's MD5 implementation in favor of pulling in
chunks of libtomcrypt and it includes the minimum knowledge of "gaih_service"
structs necessary to work with ssh, wget, etc.)
To build it, grab your distro's libc6 packaging, apply the patch to
sysdeps/posix/getaddrinfo.c, and make sure that you define
"crypt-in-libc = yes"
in an appropriate configuration file. Then build normally. Some tests for
getaddrinfo() will fail but you should wind up with a fully functional
libc.so.6 which you may install or use via LD_PRELOAD like so:
# calculate an address for "sonipes"
LD_PRELOAD=/path/to/libc.so.6 python -c 'import socket; print
socket.getaddrinfo("sonipes", None)'
# suppose we get fe80::b3da:e0e7:3bd7:278d%eth0
# on sonipes:
sudo ip addr add fe80::b3da:e0e7:3bd7:278d%eth0 dev eth0
# elsewhere, on another computer on the same link as sonipes
sudo env LD_PRELOAD=/path/to/libc.so.6 ping6 sonipes
LD_PRELOAD=/path/to/libc.so.6 ssh sonipes
(rsync, wget, nc6, ...)
Enjoy,
Michael
[1]: http://wiki.laptop.org/go/Network_principles
P.S. - Improvements are definitely welcome -- I found the code very satisfying
to use on a local wireless network.
a) provide a cute one-liner for assigning appropriate addresses to interfaces
based on the machine's desired hostnames
b) check the code for endian-neutrality
c) figure out how to fully build and package the result for easier testing
d) rewrite as an NSS module?
e) rewrite in an external DNS resolver?
diff -u eglibc-2.9/debian/changelog eglibc-2.9/debian/changelog
--- eglibc-2.9/debian/changelog
+++ eglibc-2.9/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.9-13.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/rules.d/build.mk: build libcrypt into libc
+ * debian/patches/any/hack-up-getaddrinfo.diff: install getaddrinfo hack.
+
+ -- Michael Stone Sat, 04 Jul 2009 19:06:59 -0400
+
eglibc (2.9-13) unstable; urgency=low
* debian/debhelper.in/nscd.init: fix return code when querying status
diff -u eglibc-2.9/debian/rules.d/build.mk eglibc-2.9/debian/rules.d/build.mk
--- eglibc-2.9/debian/rules.d/build.mk
+++ eglibc-2.9/debian/rules.d/build.mk
@@ -52,6 +52,7 @@
rtlddir="$(call xx,rtlddir)" ; if test -n "$$rtlddir" ; then \
echo "rtlddir = $$rtlddir" >> $(DEB_BUILDDIR)/configparms ; \
fi
+ echo "crypt-in-libc = yes" >> $(DEB_BUILDDIR)/configparms
# Prevent autoconf from running unexpectedly by setting it to false.
# Also explicitly pass CC down - this is needed to get -m64 on
diff -u eglibc-2.9/debian/patches/series eglibc-2.9/debian/patches/series
--- eglibc-2.9/debian/patches/series
+++ eglibc-2.9/debian/patches/series
@@ -210,0 +211 @@
+any/hack-up-getaddrinfo.diff
only in patch2:
unchanged:
--- eglibc-2.9.orig/debian/patches/any/hack-up-getaddrinfo.diff
+++ eglibc-2.9/debian/patches/any/hack-up-getaddrinfo.diff
@@ -0,0 +1,111 @@
+From 55208c43bbd9ce5e21b7c9b77db6526e688ce612 Mon Sep 17 00:00:00 2001
+From: Michael Stone
+Date: Thu, 11 Jun 2009 21:04:18 -0400
+Subject: [PATCH] Hack up getaddrinfo().
+
+---
+ sysdeps/posix/getaddrinfo.c | 74 ++
+ 1 files changed, 74 insertions(+), 0 deletions(-)
+
+Index: eglibc-2.9/sysdeps/posix/getaddrinfo.c
+===
+--- eglibc-2.9.orig/sysdeps/posix/getaddrinfo.c 2009-07-04 19:14:10.0 -0400
eglibc-2.9/sysdeps/posix/getaddrinfo.c 2009-07-05 13:52:29.0 -0400
+@@ -62,6 +62,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #ifdef HAVE_LIBIDN
+ extern int __idna_to_ascii_lz (const char *input, char **output, int flags);
+@@ -251,6 +252,81 @@
+ } \
+ }
+
++static void
++hack_dns (const char *name, const struct gaih_service *service,
++ const struct addrinfo *req, struct addrinfo **pai,
++ unsigned int *naddrs, int *ret)
++{
++ /* XXX: Service processing! */
++ if (name == NULL
++ || (service != NULL && service->num < 0)
++ || ( req->ai_family != AF_INET6
++ && req->ai_family != AF_UNSPEC))
++ return;
++
++ char buf[16];
++
++ __md5_buffer(name, strlen(name), buf);
++
++ struct ifaddrs *ifaddr, *ifa;
++
++ if (getifaddrs(&ifaddr) == -1)
++return; /* Should we set *ret? */
++
++ unsigned int old_naddrs = *naddrs;
++
++ for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next)
++{
++ if (ifa->ifa_addr->sa_family != AF_INET6)
++continue;
++
++ struct sockaddr_in6* sa6 = (struct sockaddr_in6*)ifa->ifa_addr;
++
++ /* XX
Re: [Sugar-devel] Journal feature request--more data in main display
Hi James, On 3 Jul 2009, at 19:29, James Zaki wrote: > Perhaps this is a late reply, (I am yet to read the last 6 or so > digests of to 20+ that were in my inbox) No not late at all! :-) > But I am always sensitive of little incremental additions that seem > like it would be useful. > > I always try to think about the first time I used sugar. In > particular, what helped by being very simple. We see sugar evolving, > and perhaps forget what it was like that first time. Perhaps we > should harass some friends and families' kids who've not seen it, > and get their feedback. +1 > If a child new to the sugar interface (XO or otherwise) feels > bombarded with options, it could make things harder. +1 > In particular to the pictures, there are lots of activities in that > dropdown. Has that always been so big? To me that would be > intimidating for the first user experience. Just to check you're referring to: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#What.2FAnything_palette Yes this mock-up is currently showing the 33 Activities as shipped in the Sugar on a Stick Strawberry release from week or two ago. There's lots of discussion about what Activities a distribution should ship pre-installed, but this is something a school deployment, or parents group would want to be involved in. If I was introducing this to a child for the first time, I'd only install a small number of Activities to let them get comfortable. FWIW: I think the original G1G1 image installs about 27 Activities. With the currently shipping Journal, there is a text menu called "Anything", when you click on it, it drops down a single vertical column list of everything you see in the above mock-up. The list is much larger than the height of screen, so you only see the first 14 or so items. To see the others, you have to scroll the menu using a small arrow at the bottom of the screen. When you want to undo your filter, you have to open the menu again and scroll it all the way back up again to find the "Anything" entry to click on. It's quite a fuss once you have many more than 9 Activities installed (the menu also holds 5 generic file type filters for text/image/audio/video/link). The multi-column approach is an attempt to reduce the need to scroll through tall menus. If the Uruguay deployment has shown us anything, it's that kids love installing lots and lots of Activities :-) At http://activities.sugarlabs.org/ there is already over 150 available for them! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 03:36, Eben Eliason wrote: > That said, I'm actually thinking that the tag > dropdown should be an extension of the search field itself. Perhaps > it's just to the right, and only needs to be a little down arrow that > reveals the tags (or perhaps we even modify the search entry to have > this button). Yes, if the toolbar tag button is deemed another scary button too many, and we still want the functionality, it could be placed in the search field magnifying-glass with minimum impact for a novice user (they just wouldn't find it until shown, or curious). See the Safari browser search field for reference. Apple use a magnifying-glass with a very small disclosure triangle that reveals the search history, we could have the same in Journal reveal a sorted tag list/cloud. > Previous mockups I'd worked on were based on the idea > that a tag suggestion window would popup beneath the search field > while typing to show possible tags. I guess you could have the same sorted tag list/cloud palette appear for either a click of the magnifying-glass, or when typing, as you typed you'd get the auto-complete suggestion, and the tag list would visually filter the matches shown. That would really be quite some serious coding effort though! > The thought for the explicit > dropdown arrow would be to choose tags without having to start typing. Yes, browsing/navigation of existing tags without typing will go a long way to getting folks to actually use them, especially out target demographic. Though this feature can initially be left off and, added at a later date. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jul 5, 2009 at 8:33 PM, Gary C Martin wrote: > ... One thing we could do > to try to move forward on the new toolbar concept is to build svg > icons for as many of the tabs that are already in use. We need to come > up with clear and identifiable icon for each **before** moving forward > (not just the few obvious common cases view/edit/image/text/format/ > colour/etc). > > Here's a quick trawl, not a full list. If we can't manage these, it > would be unfair to expect Activity Authors to have any more success. > Note: that some of these may need Activity specific variants, though > we may be able to drop some if we are willing to redesign some > Activities current UI: > > Algebra > Audio > Books > Boolean > Browse > Chat > Collaboration > Comment > Create > Edit > Effects > Face > Format > Game > Graph > Help > Image > Learn > Lessons > Library > Miscellaneous > Montage > Video > Paint > Photo > Plain > Play > Project > Read > Robot > Save/Load > Shapes > Slides > Sort > Tab > Table > Text > Tools > Trigonometry > View > Voice > Watch Perhaps Gaurav Bhushan could help with icons. He seems to have a knack for expressing abstractions in icons, see http://wiki.sugarlabs.org/go/File:Social_Communication_System.png. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Background Screen Color for SoaS Activity
The default color for the Sugar Activity screen seems to be set to light gray. I'd like mine to be white. Is there any way to change this in my activity script? I tried: import gtk win = csndsugui.CsoundGUI(self) ibox = win.box(False) ibox.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(0x, 0x, 0x)) where ibox = the entire screen. However this changed nothing. Anything fairly straightforward I could try? Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
