Maemo 5 Alpha SDK (also known as Fremantle Alpha SDK) was released in maemo.org on monday. We are happy to announce that the Maemo 5 Alpha rootstraps are now also available for Maemo SDK+ development environment.

Those developers who are already using SDK+ to compile their source code can now start porting their code also to Fremantle without moving back to Scratchbox-1.

If you have installed SDK+ already to your machine you should run the command “$ maemo-sdk reload catalogue” to get the Maemo 5 Alpha rootstraps visible to your SDK+ rootstrap menu. To install Maemo 5 Alpha rootstraps just say “$ maemo-sdk install rootstrap” and a menu is provided to you where you can selected the rootstrap you want to start using. Maemo 5 Alpha rootstraps that are made availabe are: “fremantle5.0alpha_armel” and “fremantle5.0alpha_i386”.

Maemo SDK+ project provides alternative cross-compiling environment for Maemo developers. SDK+ is based on Scratchbox-2 instead of Scratchbox-1. To learn more about the SDK+ itself, how to use it and how to do software development in this environment please follow the link below.

This RC2 release includes bug fixes and provides better tools to setup the CPU-transparency method when working with the device. In addition, the “maemo-sdk-installer.py” script has also been improved and it now also provides a GUI option.

We are happy to report that the maemo SDK+ Beta-2.5 is released. Click yourself to http://maemo-sdk.garage.maemo.org to learn more how to develop maemo applications without Scratchbox-1.

Maemo SDK+ is an alternative (and currently unofficial) way to develop software for Nokia Internet Tablets.

This release has lots of bug fixes and much better support for X86 architecture than the previous release. We also introduced new command line tool called “maemo-sdk” that acts as a wrapper to the multitude of services the SDK+ offers. We now recommend using this new maemo-sdk command line tool for all SDK+ related maintenance work (like installing rootstraps, tools, compilers, starting the Hildon UI etc) instead of using the separate maemo scripts and tools. This tools frees the developer from doing many mundane daily tasks manually. It also takes care of the many configuration and initialization steps that previously you had to do manually.

After releasing the previous beta we were contacted by many people who requested wider distro support than just Ubuntu Hardy so this release is available for the following distros:

Last time I introduced sp-error-visualizer and sp-rich-core. Now it’s time to take a look at a couple of the other sp-tools in Chinook.

sp-endurance

The sp-endurance suite provides tools to save and analyze data from endurance testing. Endurance testing could be defined as repeated testing over a long(er) period of time. This kind of testing usually reveals memory and resource leaks. Due to the nature and requirements of endurance testing, it is usually done once the application is nearly complete. In my opinion it is one of the most important steps when moving from beta to release quality.

The sp-endurance suite consists of two packages; sp-endurance and sp-endurance-postproc. The first one is meant to be installed on the device and provides helper scripts for data collection. The second one provides data post-processing tools for data manipulation and report generation and it’s meant to be used on the PC.

You still need to do the hard work of actually designing and executing the endurance tests, sp-endurance is there to help you analyze the results. The Chinook toolset also contains some tools for test automation and you could consider using those when designing your test cases.

sp-stress

Ever wondered how your program behaves under a heavy CPU load or how it handles itself when memory is low or unavailable? sp-stress provides you with utilities to easily put the system under different kinds of stress and thus let you test your application in these scenarios.

The sp-stress package provides three utilities; cpuload, ioload and memload. Their names are already indicative of their purpose.

cpuload will generate the given background CPU load, which you can select from 1% to 100% or have it generated randomly.

ioload will perform read and write operations on a given file generating a lot of I/O load on the filesystem.

memload will allocate a given megabyte size chunk of memory.

Depending on your program, it may be a good idea to test how it behaves with a constant or varying load of one or more of the sp-stress utilities.

More about tools

See maemo.org for usage examples and to learn more about these and other tools:

The Chinook SDK has been out now for a while and it feels like a good time to highlight some of the tools that were released with it.

Like mentioned earlier, a set of previously closed tools was made open source with the Chinook SDK release. These tools were made in-house by and for our developers. Now they’re also available for you through the Chinook SDK repository.

This time I’m going to talk about sp-error-visualizer and sp-rich-core.

sp-error-visualizer

The error visualizer tool pops up a notification banner every time something matching a pattern gets written to the syslog. It’s a simple idea that will help you notice those sporadic errors that you just can’t reproduce reliably and otherwise might go unnoticed in the log writings. You can naturally define the match pattern to whatever you are looking for.

This tool is especially useful on the device where you often can’t view the logs while running an application.

sp-rich-core

The rich core is one of my favorites. The idea is to provide a better view of the whole system’s state at the time your program happens to crash.

Normally when a program crashes it will produce a core dump file, which is the run-time memory and state dump of the program. The developer can then open this core dump with a debugger (gdb) and observe the state of the program at the time it crashed. Many times this is enough to reveal the reason to the crash, but sometimes it can be difficult to understand why the program ended up in that state. At those times any extra information is a blessing.

With the sp-rich-core installed, when a program crashes it will not only produce the core dump file, but it will also take a snapshot of many things in the system. Then all these files are compressed together with the core dump to a rich core (.rcore) package.

The developer can now open up this package with the rich-core-extract utility and have all the extra information of the system’s state available along with the normal core dump file.

I wanted to write a few words about the tools released last week with the Chinook SDK.

The Chinook SDK is a collection of libraries, tools and resources that enables you to develop new applications and port existing ones to the IT OS2008.

With the SDK we wanted to release tools that are known to work and that are also used internally for software development in order to provide a verified set of utilities for you developers in the maemo community.

The tools and the SDK are now in the same repository and this has created a situation where the omission of certain library -dev packages has raised some eyebrows. The reason for this omission is that those libraries are only needed as a run-time dependency for one or more of the tools that are in the same repository. It is also an indication that if your application needs to use that library, you need to make sure it’s available for the non-developers from some other repository than the SDK, preferably from the Chinook extras repository. Your application should not depend on something that’s only available in the SDK repository.

There’s a plan to provide a separate tools repository the next time we publish an SDK. This will hopefully make the separation of the tools and the SDK more clear. This will also make it safer to activate just the tools repository on the device without having to worry about all the ‘noise’ the SDK repository creates in the Application Manager.

From Bora to Chinook

In Bora SDK the included tools were a small collection of standard Linux tools. This time with Chinook we’ve released more well known tools and also some that were developed internally and haven’t been available to the open source community before.

Oprofile is now available accompanied with a graphical user interface. Valgrind has been updated to a new version along with gdb in order to better support glibc2.5.

Most of the internally developed tools and helper scripts are in packages named “sp-something”. These utilities help in tasks like simulating different kinds of system load or collecting and analyzing debugging data or just provide help in starting up the various other debug tools correctly. The main goal of these “sp-tools” is to offer a variety of utilities to help you increase the quality of your applications by facilitating easier and more powerful testing.

The tools documentation pages were updated and the tools were categorized by task to help new developers easily see what’s available. Each tool that got categorized has its own subpage with a description, usage examples and links to other sources of information.