12.1.0

12.1.0 an in-development OLPC OS release, focusing on shifting parts of the Sugar UI to the GTK+ 3 toolkit and to new system technologies present in Fedora 17. The target platforms are Target platforms::XO-1, Target platforms::XO-1.5 (including XO-1.5 High School Edition) and Target platforms::XO-1.75.

The release plan can be found at /Release plan.

Status

Status: Status::in development (see /Release plan and Release Process).

To be released on: Release date::2012-07-09

Release notes: Release notes::Release notes/12.1.0

Download and installation

Development builds are available here:

• http://build.laptop.org/12.1.0

New builds are announced on the devel mailing list.

XO-1.75 and XO-1.5

To install from Open Firmware on an unlocked XO-1.5 or XO-1.75, download a .zd file to a USB drive.

Insert the USB drive into the XO, get to the Ok prompt and type:

fs-update u:\X.zd

Where X.zd is the file you downloaded, for example 21008o1.zd (for XO-1.5) or 21008o2.zd (for XO-1.75).

XO-1

To install from Open Firmware on an unlocked XO-1, download the .img and .crc files to a USB drive.

Insert the USB drive into the XO-1, get to the Ok prompt and type:

copy-nand u:\X.img

where X.img is the .img file you downloaded, for example 21008o0.img.

Online upgrade

For updating from a previous release to a 12.1.0 development build, or from one 12.1.0 development build to another, you can use olpc-update. For example, to update to build 9, run one of the commands below in the Terminal activity, depending which laptop model you are using:

sudo olpc-update 12.1.0d_xo1.75-9
sudo olpc-update 12.1.0d_xo1.5-9
sudo olpc-update 12.1.0d_xo1-9

Note that the fast, "pristine" upgrade method will not work on 12.1.0 builds 1 through 8 inclusive. In this case, the system will automatically fall back on a slower upgrade method and the upgrade will complete anyway. Build 9 has broken olpc-update due to a /bootpart mounting problem (#11849). Build 10 and onwards has a working pristine upgrade.

Developers

The release is built with Build system::OS Builder version Build system version::5.0.x (master) under Build platform::Fedora 17, using f17-xo1.ini, f17-xo1.5.ini and f17-xo1.75.ini at this point in the development process. The f17, f17-xo1, f17-xo1.5 and f17-xo1.75 RPM dropboxes are used.

Fedora package inclusion process

For contributions in the form of updated RPM packages that are part of Fedora, the process is a little complicated due to the fact we work with multiple architectures and ARM is not yet a primary Fedora architecture.

The entire process is explained below. However, only the first and last steps are required. Feel free to skip some or all of the remaining steps - just make sure you leave a note on an "add to build" ticket noting which steps you have done. Daniel and Peter are more than happy to take on the packaging work on your behalf, and they can lump it into batches.

1. Produce source tarball, upload to relevant place.
2. Commit spec file to Fedora git, push and build for x86
   • Commit your change on both the f17 and master branch. Suggestion: commit on F17 branch, then use git merge to fast-forward master to the same commit.
   • Ensure you are on the f17 branch.
   • fedpkg push
   • fedpkg build
3. Submit an update for F17.
   • fedpkg update
4. When bodhi emails you saying that your F17 update can be pushed to stable, push it.
5. Put the relevant trac ticket in "add to build" state, noting which of the above steps you have completed.

ARM is intentionally left out of the picture here. Your package will be built automatically on ARM, but only once it gets pushed to stable (updates-testing does not currently get built for ARM). To avoid the delay of several days before this happen, Peter Robinson will make an ARM build based on what was pushed to updates-testing and maintain it in his dropbox until it is officially built for Fedora-ARM. Please leave these builds to Peter so that it can be managed in a central place.

Activity inclusion process

Now that we are in bug-fixing stages, activities have been frozen. However, we will take activity updates where they fix important bugs. The process is:

1. CC 'dsd' on a relevant ticket
   • This can be on SL or OLPC trac, and it can either be in a ticket where an activity bug was found and fixed, or it can be in a dedicated "Please update HelloWorld to v4" type ticket.
2. Add a comment on the ticket requesting inclusion in 12.1.0.

As for which fixes we want to include:

• We should focus on fixing clear, interesting and important bugs.
• The activity and the relevant functionality must already be tested by you on the most recent build
• The code change, and all other code changes between the current version and the new one must already be reviewed by you
• The release manager will repeat the testing and code review
• It's fine (at this stage) if the activity has changes unrelated to the interesting bug in question, but (in the case where you are the maintainer) its preferred (not required) to limit changes to only the bug in question.
• Please keep our workload down - focus on important bugs only, we're not looking to incorporate every single bug fix produced by the community at this stage. Every change requires review and testing and requires effort from multiple people, and (being honest programmers) our bugfixes introduce new bugs on a regular basis, further increasing the workload.

Bug reports

We are now looking for bug reports on all levels - system, Sugar, activities, ...

Sugar-specfic bugs and activity issues should be filed at http://bugs.sugarlabs.org. System-related bugs should be filed at http://dev.laptop.org. If in doubt, ask on the mailing list first, or file at OLPC and let us take care of it for you.

For OLPC tickets, leave the milestone field blank but mention clearly that you are testing 12.1.0, your bug report will then be triaged into the appropriate place.