[ANNOUNCE] Sucrose 0.84 Release Candidate 1 (0.83.5)
Dear Sugar Community,
This is Release Candidate 1 for the upcoming 0.84 Release - see [1] for
more details. Only two more weeks to go in this release cycle. Please
test this release and report all the bugs you find that we are able to
fix them in time. A friendly [2] will be available to triage those bugs
accordingly and the developers can never have enough bug food. If you
have non-bug feedback about features you can use the sugar-devel mailing
list to share it with us.
From a user point of view we want to highlight the following changes
that have been made in this release:
=== Journal ===
The translation of the dates in the Journal is working now again. Please
verify with your favorite language that this works for you. A 'Clear
search' button has been added to the 'No matching entries' message,
following Eben's specification. Also the space used and left is now
displayed in the volume palette in the Journal.
Journal entry palette
The journal entry palette has seen some great improvements. We have a
'View Details' option that brings you to the details of the entry
directly. Also the icon for the file transfer was designed and added by
Gary C. Martin. Furthermore you do not need to go to the detail view any
more to select the activity you want to start or resume the entry with -
this option is now available in the palette as well.
=== Naming Alert ===
When you stop an activity from the Frame the activity is resumed and one
can refine the activity metadata in the Naming Alert. As well a saving
error of the activity will not prevent one any more from closing the
activity due to the Naming Alert.
=== Palettes ===
There were some positioning issues of the palette that got fixed. Please
report back any issues you still find. Another palette related fix was
that on right click on an Access Point icon we do reveal the palette as
it is the behavior in all the other places in the UI and do not try to
connect to the Access Point.
=== Keep error when displaying a file in Browse, Read, ImageViewer ===
This is one of my favorite fixes as this has been broken for quite a
while. When trying to display for example an image in Browse or the
ImageViewer there was an keep error when closing the activity.
=== Resume activity ===
Last release we added the ability to resume an activity by default
instead of creating a new instance. The list of the available entries in
the palette when you hover of the activity in the home view is now
updated directly. As this is an interesting new feature, we would like
to hear about any issues you might have with it and positive feedback of
course as well.
=== Control Panel ===
We now hide any OLPC-specific fields on non-xo machines. For example in
the 'About my Computer' section we display the build dependent on the
distribution (i.e. Fedora). As the Power section was only relevant on
the XO, it is hidden in non OLPC distributions.
=== Frame Devices ===
Right-clicking on the speaker device icon does not mute the speakers
anymore.
=== Clipboard ===
Several fixes were made to the detection of images dragged and dropped
to the clipboard in the Frame.
Thanks everyone for your great contributions!
In behalf of the sugar community,
Your Release Team
[1] The Sucrose Release Schedule can be found here
http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap#Schedule
[2] More Info about the BugSquad at
http://sugarlabs.org/go/BugSquad
[3] You can find more details and screenshots at
http://sugarlabs.org/go/DevelopmentTeam/Release/Releases/Sucrose/0.83.5
__
Modules that changed:
== Glucose modules==
* sugar-toolkit 0.83.6:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.83.6.tar.bz2
* sugar 0.83.7:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.83.7.tar.bz2
* sugar-artwork 0.83.4:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.83.4.tar.bz2
* sugar-datastore 0.83.3:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.83.3.tar.bz2
== Glucose news ==
=== sugar-toolkit ===
* Dates in journal are not translated {{Bug|55}}
* Keep error when displaying a file in Browse, Read, ImageViewer, etc
{{Bug|258}}
* Palette positioning fixes {{Bug|298}}
* 'Resume' activity window when NamingAlert is displayed {{Bug|293}}
* Naming alert prevents activity close on keep error {{Bug|224}}
=== sugar ===
* Resume Activity list is not updated directly {{Bug|322}}
* Fix network panel on XO (Sascha Silbe) {{Bug|290}}
* Only show cp power section on xo {{Bug|320}}
* Add logout option to the buddy menu (Sayamindu) {{Bug|207}}
* Launch activity also when clicking on the palette icon {{Bug|335}}
* Use the activity icon for the 'Start new' palette item {{Bug|314}}
* Close the object chooser when the activity is closed {{Bug|329}}
*
Re: power consumption after shutdown
On 15 Feb 2009, at 05:36, Mikus Grinbergs wrote: My apologies for not being clear. I'll try again: I want to feel that the battery that I just put into the XO I'm walking out the door with is as charged up as it normally can be. 1) If that battery came from an XO that was plugged into the AC 24/7 for the past week -- I *think* it is fully charged up. 2) If that battery came from an XO that had been shut down for 48 hours; but then that XO had been plugged into the AC until the 'power' light went green -- I *think* it is well charged up. 3) If that battery had been sitting on the shelf (not in an XO) for a month -- what did I need to do to make it topped off ? What I am now interested in is understanding a correct state of charge value after having my battery out of the XO for one month. Not possible without discharging the battery fully to determine the state of charge it had. The test is charge destructive; once it is completed there is no usable charge in the battery. Sorry - I did not mean that I cared exactly how charged up it was -- what I want to know is how to ensure to myself, without going to extremes, that the battery was well charged up. [Is 94% reported by the pop-up for an on-the-shelf battery believable, or is the 'true' value half that? And if do I see 94%, do I need to worry that this is a battery that requires some more charging?] the software pop-up says 94%. But I notice that after an hour, the software pop-up *still* says 94%. I hope you aren't surprised. No reason it should change. Battery is not being used. I was under the impression that when the battery charge went somewhere below about 97%, the XO would charge it some more. So I was surprised to have it stay at 94%. [If 94% being shown on the pop-up is not low enough for charging some more, then how can I initiate charging being performed by the XO ?] But when the software pop-up is between 90-96% (for a previously out-of-case battery), and despite the AC adapter being plugged in that value does not increase in an hour -- what ought I to do to find the state of charge ? No possible way except a full discharge while measuring the power provided. Apologies for being unclear. I'm not particularly interested in the precision of the state of charge. What I am interested in is is the battery as 'well charged up' as I can make it be by using the XO's 'built-in' charger - I will want to get the most minutes of use of my XO when carried to a place that does not have electricity ? Have you tried either of the tools/procedures at: http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure Either olpc-pwr-log (download and run in terminal) or bat-recover (download a batman.fth file and use from Open Firmware), display actual charge going into (or out of) the battery, so you could use either of them to charge and see when your battery stops getting any more juice. Of course, without testing full discharge/charge cycles occasionally, you could never be quite sure where a batteries max is/ was (but that just takes us back to the email loop on precision). --Gary And if it is not 'well charged up', what do I need to do to make it so? In particular -- if it *were* 90% charged up when I took it off the shelf, would I have to fully discharge it in order to then charge it up (using the XO as the 'charger') closer to 97-99% ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sun, Feb 15, 2009 at 6:36 PM, Mikus Grinbergs mi...@bga.com wrote: I was under the impression that when the battery charge went somewhere below about 97%, the XO would charge it some more. So I was surprised to have it stay at 94%. [If 94% being shown on the pop-up is not low enough for charging some more, then how can I initiate charging being performed by the XO ?] It probably is trying to charge it, but batteries are chemical mixes, so - there is no real 100% or 0% - the software is handwaving to some extent... - the charge and performance of the battery changes with many variables, and generally degrades with use so I have many batteries that after some use I only see reported as 95% charged. Even if they get more charge, the battery doesn't hold it. Or perhaps the software estimated the capacity a bit too high. In short, the % you see is a fiction, a bad simplification. This is increasingly apparent as you use older batteries, and in general as you gain experience with different batteries... m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sun, Feb 15, 2009 at 12:36:36AM -0500, Mikus Grinbergs wrote: My apologies for not being clear. I'll try again: I want to feel that the battery that I just put into the XO I'm walking out the door with is as charged up as it normally can be. 1) If that battery came from an XO that was plugged into the AC 24/7 for the past week -- I *think* it is fully charged up. Yes, 95% likely. 2) If that battery came from an XO that had been shut down for 48 hours; but then that XO had been plugged into the AC until the 'power' light went green -- I *think* it is well charged up. Yes, 95% likely. 3) If that battery had been sitting on the shelf (not in an XO) for a month -- what did I need to do to make it topped off ? Discharge it to 90% capacity, then charge it. (You can do this manually in OFW using the watch-battery command ... or you can periodically attach the AC adaptor until you get an orange LED instead of green.) Sorry - I did not mean that I cared exactly how charged up it was -- what I want to know is how to ensure to myself, without going to extremes, that the battery was well charged up. [Is 94% reported by the pop-up for an on-the-shelf battery believable, or is the 'true' value half that? And if do I see 94%, do I need to worry that this is a battery that requires some more charging?] Given a battery with an unknown history, it is not practical to predict the state of charge. I was under the impression that when the battery charge went somewhere below about 97%, the XO would charge it some more. So I was surprised to have it stay at 94%. [If 94% being shown on the pop-up is not low enough for charging some more, then how can I initiate charging being performed by the XO ?] Discharge it some more. (There is no facility for boost charging ... one reason is that this would shorten the life of the battery.) But when the software pop-up is between 90-96% (for a previously out-of-case battery), and despite the AC adapter being plugged in that value does not increase in an hour -- what ought I to do to find the state of charge ? No possible way except a full discharge while measuring the power provided. Apologies for being unclear. I'm not particularly interested in the precision of the state of charge. My explanation of this precision was so that you would understand why you cannot get what you want. I had tried explaining that you cannot get what you want but you persisted, so I thought you were interested. What I am interested in is is the battery as 'well charged up' as I can make it be by using the XO's 'built-in' charger - I will want to get the most minutes of use of my XO when carried to a place that does not have electricity ? Discharge to 90% and then charge to completion. Power off, then remove the battery. Travel as fast as possible to the place that does not have electricity, do not delay by a month. Insert the battery and power on. You will have the most minutes of use. And if it is not 'well charged up', what do I need to do to make it so? In particular -- if it *were* 90% charged up when I took it off the shelf, would I have to fully discharge it in order to then charge it up (using the XO as the 'charger') closer to 97-99% ? No. Assuming a battery that has only been used in the XO, you need only complete one charge cycle, from orange LED to green LED. Since you cannot cause this cycle unless the state of charge value was low enough, you need to manipulate the state of charge value down, and the only way to do this in the design is to discharge for a short time. Usually about five minutes, but it depends on how busy the XO is. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Unshare an Activity
Hi all, I am doing an activity for blind childrens and I need to know If some one knows if sugar has a way to programmaticaly unshare a shared activity?, and if it has, how can i do that?. If I join a shared activity I can use the leave method from activity object of presenceservice to leave the shared activity, but, if I share how can I stop sharing it? Thanks for the answers. Regards. -- Jorge Saldivar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On Mon, Feb 16, 2009 at 03:05:59AM +, Gary C Martin wrote: Summary: 8.2.1 has regressed relative to 8.2 for WPA access points. You now have to enter the security string; it will fail to associate and prompt you for the security string again; you have to cancel this dialogue; it will start trawling for a mesh; you have to click the AP again; it will now connect. Good simplification of previous workaround, well done. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On 16 Feb 2009, at 03:18, James Cameron wrote: On Mon, Feb 16, 2009 at 03:05:59AM +, Gary C Martin wrote: Summary: 8.2.1 has regressed relative to 8.2 for WPA access points. You now have to enter the security string; it will fail to associate and prompt you for the security string again; you have to cancel this dialogue; it will start trawling for a mesh; you have to click the AP again; it will now connect. Good simplification of previous workaround, well done. Do we have an idea at which build this might have crept in? I'm just downloading 790 for a little regression testing (as it's easy for me to reproduce), I think after that it's out with the snake boots and butterfly net to start hunting through deepest, darkest, http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ Any pointers? --Gary -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On Mon, Feb 16, 2009 at 03:48:17AM +, Gary C Martin wrote: Any pointers? Last I checked, it was either the firmware or the kernel changes that did it. I posted my findings to the mailing list in the past two weeks. If you'd like to try some testing, try swapping the firmware file in /lib/firmware/usb8388.bin from the older build. After that, you could try swapping the old kernel in. I didn't get that far in my tests. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
qu...@laptop.org wrote: 3) If that battery had been sitting on the shelf (not in an XO) for a month -- what did I need to do to make it topped off ? Discharge it to 90% capacity, then charge it. q2e32 can help you out. In q2e32 I've pulled in some of my batman.fth stuff. As James mentions the EC won't try to charge if it thinks the battery is full because the battery full flag is set. I've added some commands that let you reset that flag. ok batman-start ok bg-clr-full-flag ok ec-reboot The EC should then charge your battery. -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results
Hi, Last I checked, it was either the firmware or the kernel changes that did it. I posted my findings to the mailing list in the past two weeks. I think your findings actually say it was either the firmware, kernel, or something else altogether. It'd be good to downgrade both at once, but still on candidate-800, so that we can check that at least *one* of the two is the problem. Thanks, - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XS 0.5.1 RC - Last round of testing...
On Sun, Feb 15, 2009 at 5:50 AM, Jerry Vonau jvo...@shaw.ca wrote: I've done a back2back comparison between revisor and pungi, given the same kickstart file. Pungi creates media which has the needed openssl.i386 file in it's Packages directory, while revisor creates one that excludes the needed file. Think you found a bug in revisor, I feel that this problem will never get corrected in F9. Interesting find. Going forward, if I recall you were using revisor mainly to embed... Yes, but not the only one: Revisor was supposed to fix a couple of other pungi bugs (skipping xorg deps, and grabbing xs-logos instead of fedora-logos). The Fedora 9 revisor has code that tries to fix those issues and fails. Jeroen is aware of it and said it's fixed in F10. I think he builds a spin (sombrero) that shows that those problems are fixed. The pungi maintainer was also hinting at dropping pungi in favour of revisor. The future is revisor was the between-the-lines msg. So I'm on the fence on this one. Let's get a response from Jeroen. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall fails
On Mon, Feb 16, 2009 at 2:42 PM, David Leeming leem...@pipolfastaem.gov.sb wrote: Tried with another USB stick - exactly the same result. Thanks for writing up carefully the steps you followed... I think I spotted the problem... SET UP BOOTABLE USB STICK - insert 2GB USB drive previously formatted with Windows (FAT) - start Partition editor, delete the existing partition Here is where the problem starts... the USB stick is perfectly good with a FAT partition. Repartitioning and formatting it in ext2 is likely to be the source of the problem. Anyone else reading this: do not repartition the USB stick :-) David: you need to re-partition the usb stick in a funny format. - use fdisk to delete the partition, create a new partition of type e (WIN95 16bit LBA), make the partition bootable - use mkfs.vfat with the -F 16 option Once you have done that, you can check that the disk is in good shape and usable trying it on a Windows machine for example. Hope that helps! BTW, where did you see instructions to replace the USB disk partition format? I want to make sure we don't have misleading wiki pages... cheers, , -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall fails
On Mon, Feb 16, 2009 at 3:53 PM, David Leeming leem...@pipolfastaem.gov.sb wrote: - insert in XS machine and boot - get same error as before ugh. There is something going on there... but I am no longer sure if it is a problem in the procedure you are following or just a hardware incompatibility. Overall, USB-based installs are a bit flakey in terms of hardware compat. Some BIOSes don't always work, and I have seen some machines where it starts and does not complete. (This is getting much better in Fedora-10 and 11...) That's why the wikipage says... in case of trouble, fall back on CD-ROM installs. Can you try that? BTW, where did you see instructions to replace the USB disk partition format? I want to make sure we don't have misleading wiki pages... David - should we be fixing wiki pages anywhere? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall fails
On Mon, Feb 16, 2009 at 5:22 PM, David Leeming leem...@pipolfastaem.gov.sb wrote: Pia (very kindly) sent me the hardware with the very same USB stick pre-configured with 0.5.0. It booted and started the installation fine, but failed right at the end with an exception error that we decided was due to hardware. If you've seen that error, it's a good hint that the HW won't like being installed from USB (at least with the 0.5.x images). I've seen it on various machines. Burning CDROMs is the answer :-/ What about the mkusbinstall errors as in the * attached jpeg **? Those errors are coming from a plain old copy file X to the usb disk -- the kernel it's telling that writing to that disk failed. The copies are done using the cp command, as vanilla as it gets. So probably something wrong in the fdisk partitioning and filesystem setup for the usb stick _or_ the usb stick being flakey (but you've said it's not). [ It's unfortunate that USB installs are hit-and-miss with F-9 stuff... ] m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall fails
You got Input/Output error during cp read of /media/cdtmp.Rf6276, which I guess is the loopback mounted ISO 9660 file system image. The most common cause of this is truncation of the image, especially if the files on which it occurs are near the end of the image. checkisomd5 is missing. Install it from package isomd5sum on Ubuntu. There may be other tools missing. Use script command to capture all the output as text, so we can have another look. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] XO School Server Help needed
Hello. I have been trying to configure my school server. The install is fine, but I am having trouble with ejabberd. When I try to register a user, I get the following: RPC failed on the node register at schoolserver http://lists.laptop.org/listinfo/server-devel: nodedown What can I do? Thanks. Gerald ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall fails -SUCCESS
OK it worked thanks to all of you. You were all right. A combination of weird small errors with hardware and sum packages that weren't installed on Ubuntu... Firstly I installed isomd5sum. It now checks the USB... Despite my earlier attempts, and the fact that the stick was working when I first tried (with 0.5.0), and that it appeared fine in partition editor, files visible etc, there WAS a USB hardware problem - a bad fragment that persisted. I tried with another USB stick, simply formatted FAT using a Windows machine which left it already bootable, and YES it all works. No errors with mkusbinstall and booting up nicely into anaconda etc. HOWEVER - the installation fails right at the end when performing post-installation config - installing bootloader: An unhandled exception occurred. This is most likely a bug. Please save a copy of the detailed exception and the bug report against anaconda at your distribution provided bug reporting tool I think this IS a hardware problem, it is reproducible. Any ideas? David Leeming Technical Advisor, People First Network, Honiara, Solomon Islands Alternative email address: leemingda...@yahoo.com.au -Original Message- From: qu...@us.netrek.org [mailto:qu...@us.netrek.org] On Behalf Of qu...@laptop.org Sent: Monday, 16 February 2009 3:35 p.m. To: David Leeming Cc: 'Martin Langhoff'; server-devel@lists.laptop.org Subject: Re: [Server-devel] mkusbinstall fails You got Input/Output error during cp read of /media/cdtmp.Rf6276, which I guess is the loopback mounted ISO 9660 file system image. The most common cause of this is truncation of the image, especially if the files on which it occurs are near the end of the image. checkisomd5 is missing. Install it from package isomd5sum on Ubuntu. There may be other tools missing. Use script command to capture all the output as text, so we can have another look. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall fails -SUCCESS
On Mon, Feb 16, 2009 at 8:40 PM, David Leeming leem...@pipolfastaem.gov.sb wrote: OK it worked thanks to all of you. You were all right. A combination of weird small errors with hardware and sum packages that weren't installed on Ubuntu... Good to hear you found the way to get it started... HOWEVER - the installation fails right at the end when performing post-installation config - installing bootloader: An unhandled exception occurred. This is most likely a bug. Please save a Yes, I've seen this on various hardware. It's not really a hw bug, it's just some odd incompatibility with the installer sw (anaconda). Can you get your hands on a USB-CDROM? If not, the next step to study is starting up the install from that USB stick, and then telling it it's an NFS-based installation, and pointing it to an NFS server... ... it's a hard road if you don't have a CDROM... :-/ cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
