Announcing the OLPC OS 10.1.2 final release!
by Chris Ball
Hi,
I'm very pleased to announce build os852 as the final 10.1.2 release
build for XO-1 and XO-1.5 laptops. Here are its release notes:
http://wiki.laptop.org/go/Release_notes/10.1.2
Instructions for installing the release on an XO can be found at:
http://wiki.laptop.org/go/Release_notes/10.1.2#Installation
Many thanks to everyone -- testers, translators, documenters,
developers and others -- who contributed to this release! As I
mentioned when announcing that this release would happen, being
able to release 10.1.2 for both XO-1 and XO-1.5 at the same time
was enabled by a group of volunteers who created XO-1 Fedora 11
builds: our particular thanks to Daniel Drake, Bernie Innocenti
and Steven M. Parrish for their work towards this release.
- Chris.
--
Chris Ball <cjb(a)laptop.org>
One Laptop Per Child
13 years, 8 months
olpc-configure
by Jerry Vonau
I've been using OSBuilder to spin up some custom images, I'm just
wondering if my XO-1.5 is a little strange or if I uncovered a bug.
When olpc-configure is run at first boot and reads the $MFG_DATA in /ofw
the LO tag that is returned has "en_US.UTF8" in it which will never
match:
if ! locale -a | grep -qx "${SYS_LANG/UTF-8/utf8}"; then
echo "olpc-configure: Locale $SYS_LANG is not supported;"
SYS_LANG="en_US.UTF-8" # better fallback than "C"
echo "olpc-configure: Falling back to locale $SYS_LANG"
fi
Then the default language becomes en_US.UTF-8... So my question becomes
do I have a funny tag in ofw or is this a bug? If this is a bug, would
it not be better to source /etc/sysconfig/i18n for a LANG= variable before
defaulting to the above? Is there some sugar specific reason for the above?
Just want to know what others think. I've patched olpc-configure to work
around the issue, but the LANG=C in OSBuilder's base routine should go away
as it's not being used anyway.
Jerry
13 years, 8 months
compcache-take2
by Yioryos Asprobounitis
I'm trying to build compcache on an XO-1 running os850 and I get into troubles.
I know that there is something wrong with my setup since in my F11/2.6.30-running VM, the compcache modules compile without a hitch.
I have rpmed in kernel-headers and kernel-devel from the os850 kernel and due to yum limitations, I manually installed development tools. eg
gcc, make, automake, automake autoconf , bison, m4, elfutils, binutils, gettext, ncurces-devel. flex, libtool, rpm-build, pkgconfig, strace, some_that_I_forget, and their dependencies.
Running make on the XO-1 gives me the attached huge error file that mostly suggests errors in the assembler, missing asm files etc.
Any ideas what I'm missing/did wrong?
Thx.
13 years, 8 months
OLPC 10.1.2 Release Candidate 3
by Chris Ball
http://wiki.laptop.org/go/Release_notes/10.1.2
http://build.laptop.org/10.1.2/xo-1.5/os852
http://build.laptop.org/10.1.2/xo-1/os852
Compressed image size: 604.25mb (+1.50mb since build 851)
This build will become the 10.1.2 release after final testing, we hope.
Changelog:
* bootfw, #9100: New OFW version Q2E45 fixes crash during boot on xo-1
* Disable XO-1 idle-suspend for release due to blockers #10232 and #10233
* bitfrost, #10271: Fix home view update after Software Update
* kernel, #10233: Improve resuming from idle-suspend via touchpad on xo-1
* olpc-utils, #10299: new version of olpc-pwrlog tool
* Speak activity: upgrade to version 18
Package changes since build 851:
+bitfrost-1.0.10-1.fc11.i586
-bitfrost-1.0.9-1.fc11.i586
-bootfw-q2e44-1.olpc2.unsigned.i386
+bootfw-q2e45-1.olpc2.unsigned.i386
-kernel-2.6.31_xo1-20100804.1841.1.olpc.72481b500bcb92f.i586
+kernel-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586
-kernel-firmware-2.6.31_xo1-20100804.1841.1.olpc.72481b500bcb92f.i586
+kernel-firmware-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586
-olpc-utils-1.0.27-1.fc11.i586
+olpc-utils-1.0.28-1.fc11.i586
13 years, 8 months
Re: OLPC 10.1.2 Release Candidate 3
by Chris Ball
Hi,
> In the deployments there are complaints about accidentally
> deleting Activities in Gnome. Can we use the ".hidden" file in
> Nautilus too hide it? Doing echo "Activities" > .hidden in
> /home/olpc/ the directory is invisible in Nautilus.
Yes, you can do that.
I'm reluctant to do that for the build by default, because it has the
unintentional side effect of making it harder to view or edit activity
source code using nautilus and gedit. So, I'd rather see work going
towards a solution that satisfies both requirements. Some candidate
solutions are:
* We could implement a new file attribute, similar to the current
"immutable" attr, that allows modification but not deletion.
We could apply that attribute to the default activities.
It would be possible to override it with "chattr" as root.
* We could have a single "restore my default activities" button,
either in Sugar or GNOME or both, that restores copies of deleted
activities using the /versions/pristine/ hierarchy. This would
also help to restore a laptop that has deleted some of its own
activities in order to recover from being out of disk space.
- Chris.
--
Chris Ball <cjb(a)laptop.org>
One Laptop Per Child
13 years, 8 months
Re: OLPC 10.1.2 Release Candidate 3
by S Page
> Just updated my XO-1.5 to 852 and I now have the battery show up twice in
> the frame...
I didn't notice this on my XO-1 after olpc-update --usb from 802 to
os851, and not in my network olpc-update from os851 to os852.
--
=S
13 years, 8 months
Help testing new sugar packages in F14
by Simon Schampijer
Hi,
to get the new Sugar release 0.90 [1] into shape and make it a stable
release we want people to test the nightly Soas snapshots [2]. In order
to get the new packaged tarballs into those builds they have to meet
certain criteria first [3], hence we need people testing them.
You can simply do this by getting the rpms from koji and install them
into your latest soas snapshot and restart Sugar. What I do in short is:
- open the Browse activity and go to http://koji.fedoraproject.org
- search for the package (sugar, sugar-toolkit...)
- click on the latest F14 version and then right-click on the download
option of the 'noarch' rpm and choose 'copy link' from the palette (if
you download directly it is stored in the Journal)
- then open the terminal activity log in as root and you can copy in the
address here using ctrl+shift+v or the edit tab in the toolbar
- the command for updating the rpm is: 'rpm -U [name of rpm]'
Once you tested the package you can comment on bodhi [4] about your
findings and give karma points. If you have not done so yet, you should
create a Fedora account [5], so your comments have a higher value.
Why not start today? Here are some packages that would need your testing
[6] [7]. Btw, there will be a Fedora testing day [8] this Thursday and
we want to give a go on Sugar, too. More info to come.
If you have questions please feel free to ask. I am as well on irc
#sugar most of the day.
Regards,
Simon
[1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule
[2] http://alt.fedoraproject.org/pub/alt/nightly-composes/soas/
[3] https://fedoraproject.org/wiki/Package_update_acceptance_criteria
[4] https://admin.fedoraproject.org/updates
[5]
https://admin.fedoraproject.org/accounts/user/new?_csrf_token=88fb044408f...
[6]
https://admin.fedoraproject.org/updates/sugar-artwork-0.89.3-1.fc14,sugar...
[7]
https://admin.fedoraproject.org/updates/sugar-toolkit-0.89.2-1.fc14,sugar...
[8] https://fedorahosted.org/fedora-qa/ticket/108
13 years, 8 months
Re: strange behavior of 'rm'
by James Cameron
On Sun, Aug 15, 2010 at 05:46:21PM +0200, Tomeu Vizoso wrote:
> Some git grep turned out this:
>
> def _write_favorites_file(self):
>
> I know this seems counter-intuitive to lots of engineers, but reading
> code actually ends up saving time.
Thanks.
At the time, I wasn't interested in where in Sugar the file was written
or under what circumstances, I was only interested in whether I could
reproduce the problem that Mikus reported.
I don't see how your locating the code, Tomeu, has led to any greater
understanding of the problem that Mikus reported, since you did not
describe the frequency of the method execution.
I'm talking about the problem of the file not being deleted by rm yet
with the absence of Sugar restarts.
On Sun, Aug 15, 2010 at 01:19:00PM -0500, Mikus Grinbergs wrote:
> Since nobody is paying me for my time - and with me wondering WHERE
> the output of such a 'simplejson.dump()' function is being used (and
> WHAT can happen if the result contains multiple entries with the same
> bundle-name) - spending time by reading the quoted code does not
> appeal.
I agree. I'm not convinced reading the code would be useful at this
stage. I'm more puzzled at why repeated rm commands with a 'y' answer
don't work for you.
I'd like to get to the bottom of that if you're willing, but I know you
don't always like diagnosing problems.
The suggestion that language differences are a cause of not deleting a
file can be eliminated by testing with strace. The recognition of the
"y" for confirmation is done by the rm program, not the kernel. strace
allows us to capture the interaction between rm and the kernel:
strace -o rm.strace rm -i favorite_activities
If the output file rm.strace contains:
unlinkat(AT_FDCWD, "favorite_activities", 0) = 0
then it means that the kernel was asked to delete the file, and so
language differences can be excluded. If there is no such line, then
the kernel was probably not asked to delete the file.
> What started this whole pilgrimage was Quozl noticing (I believe in
> shell.log in one of my system dumps regarding a Record problem) a
> reference to an OBSOLETE version of Record.
Oh yes, I remember that. It was puzzling, but I didn't feel it was
worth reporting to Sugar Labs, since it had no effect on the Sugar user.
Have you reported it in a ticket yet?
--
James Cameron
http://quozl.linux.org.au/
13 years, 8 months
