Now I know what you’re thinking. This sounds like it’s going to bring in a heck of a lot of red tape. I believe not so. As with some companies and iso9000, this is something which should be done already. Let’s take a few examples. I think my position in the Ubuntu community has been through so many different stages, and I have touched on so many different areas that I’m pretty well qualified to talk about the struggles of beginning in these areas.

The following isn’t meant to offend the Ubuntu community at all. I love the community and a lot of what I describe here, may have already been addressed. I’m hoping more that these comments will help to bring about the thinkings to create the contribution pack, which would be bourne out of the documentation required to gain OSCS. So let’s take a look at the areas I’ve contributed in.

Artwork
I created the Edgy startup login sound, as well as working with AliasVegas on wallpapers for Edubuntu for a couple of releases. Artwork is a tricky one and I found that AliasVegas was rather reluctant to sit in on IRC meetings as she felt they were very technically orientated. Though there is documentation and a mailing list for artwork, the process for creating and submitting artwork wasn’t all that clear. The sounds for Edgy were born out of my desire for something different. There was no documentation on sound submissions at all. I had a great time chatting to fschoep about my sounds and he and Mark Shuttleworth, both gave invaluable input on the direction and shaping of the sounds. However I still believe a document on the process of how artowrk is created, moderated, voted on, accepted, packaged, deadlines, all in one place would have been great. If this exists now, tell me!

Documentation
I was prompted to write some man pages for some of the ltsp programs as one of my first tasks in the Edubuntu community. This turned out to be a very very difficult task for me. Despite asking for help, no one seemed to be able to tell me definitively where to get help on creating a man page. The language itself seems magical and cryptic and not at all intuitive, at least not to me almost 2 years ago. So I think in the end it turned into me writing it in SGML and getting that converted into a man page. How does documentation work. I worked on the Edubuntu Handbook, which at the time seemed to be written in two different places by two different sets of people? Very confusing. It wasn’t clear what tools I should use, or what templates/standards I should adhere to.

Coding
I had an idea that I wanted to help with coding and learn a language that would be helpful to Ubuntu. So I started learning python. I wrote gISOmount in 2 weeks, my first python application. This was the beginnings and I then went on to develop Thin Client Manager further. I had some great help from people in the Edubuntu community on this. But I still managed to make many mistakes that meant I had to rewrite most of my code. Yes, this was a learning experience for me, but could it have been avoided by getting some guidelines from the start. In the end we all agreed it was an unclear specification that led me to make generalisations that weren’t true.

Packaging
Whilst working on gISOmount and thin client manager, I was required to do some packaging. This was well before the mentoring program began, and I was left basically with the Ubuntu packaging guide and some spare time. Eventually I got it working, but how I would have liked some detail on the packaging process. I am a MOTU, but I confess I still don’t know the whole process from start to finish. I make a pacakge, ask in #ubuntu-motu where I should put it, and keep bugging people to find out when it will get approved. Before becoming a MOTU I had the strangest notion that once I was a MOTU I could upload directly to the universe. How wrong I was!

Advocacy
This was one area that seemed to fit together quite well. We had no leaflets for Edubutnu at all, so I created some from some Ubuntu marketing templates, and took them to the BETT show, which I attended with Jono. It was an awesome few days.

Bug Fixing
I worked in the beginning with trying to fix a few bugs, something I think many people are capable of, however, I still don’t know how my patches got applied, and got scolded many times for changing the status of a bug once I’d fixed it on LP. Or indeed changing the status of another bug which I had seen a duplicate of. I think that’s one reason I gave up on bug fixing.

Translations
I submitted a few translations on Rosetta, but did I actually do any good? I have no idea, I have no idea how the process works at all. This isn’t an area that I’ve invested much time in at all.

External Activies
I wrote the Edubuntu chapter in the Official Ubuntu Book, another area that was fairly well defined as to what was required of me and when.

This post is meant to start sparking off ideas in peoples minds for a joint discussion I’m planning to host sometime in the future. Is this a good idea. Creating a small set of documentation that relates to processes and defines, how, who, where and when certain processes take place. To me it seems very important. I thought of perhaps a centralised site for this, but perhaps that’s taking it too far. But what about a standard. What about the OSCS??? Let me know what you think. I’d be looking for a few projects to get together and discuss what documentation they already have to fulfil this, and whether they think this is a good idea.

3 1

How about a contributors pack? To help give something back to those considering contributing to your project. I envisage having a leaflet, which would take on the form of a generic template, stylable to your project which hold information about every aspect of the project that needs help. For example documentation, packaging, coding, bug fixing, advocacy etc.

The contributors pack could be online, or even include some paper pamphlets on request, printable via lulu for example. It would contain information about processes such as MOTU, and detail the tools people use for tasks, and where to get them, how to file a bug correctly. The possibilities are endless. I know it took me a long time to learn some processes, and the thing is, I was taking up valuable people’s time when if the right resources were available I could have just read them online, or in a leaflet. Each team in a project could have their own leaflet with contact information, processes, etc.

If you think this idea has merit, I urge you to comment here.

On another note, thanks Lugradio. Maybe my place isn’t so much a doer, as a proposer of ideas. That one’s for you Bacon.

1 0

	N800	N810
No of memory slots	2 (sd/mmc)	1(mini-sd/micro-sd)
Hardware keyboard	No	Yes
Memory	256Mb	2Gb
Camera	360°	Fixed
GPS	No	Yes

Overall, though there are some aspects of the N810 that I wish they had stuck to on the N800, I’m so pleased with the N810. Maemo-mapper is great with the GPS. Great work Nokia, and the whole of the maemo team, keep it up.

1 0

I have linked to all my reference documents at the bottom and will try to tell you when I’m switching from one to the other.

So onto the howto:

Background
First things first, a little explanation into what we are actually doing. We want to create an environment to test and compile code on both x86 and ARM platforms. The N800 runs an ARM processor which means you can’t just grab binaries from the net from your popular debs and hope they’ll work. They won’t. Why? Because each processor has a different instruction set. A compiler tells a process what instruction to run when etc. Obviously trying to run an x86 compiled binary on an ARM processor is going to go nowhere so we have to add a layer of abstraction.

Installing Scratchbox
The instructions below will give you a fully working scratchbox (apophis) with the maemo sdk version 4.0. There is a later scratchbox out there, but for now, we’re going to stick with the more stable/documented one. Traversing the list of documents, we take our first set of instructions from [1]. Basically we are going to install a 4.0 maemo sdk. To begin with, we first need scratchbox installed. The following three commands should be run in your home dir and will grab the scratchbox installer, make it executable, and then run it. Beware, this will lead to downloading over 310Mb of data, so make sure you have enough disk space and bandwidth.

wget http://repository.maemo.org/stable/4.0/maemo-scratchbox-install_4.0.sh
chmod +x maemo-scratchbox-install_4.0.sh
sudo ./maemo-scratchbox-install_4.0.sh -d

So now we have scratchbox installed and you should be greeted with a message similar to the one below

Installation was successful!
----------------------------

You now have Scratchbox 1.0.8 'apophis' release installed.

Scratchbox cannot be run as user root. Instead, use your normal login
user account. Add additional scratchbox users and sandboxes with the
following command (outside scratchbox with root permissions):

        # /scratchbox/sbin/sbox_adduser USER yes

Running this command will create sandbox environment for that user and
add user to the 'sbox' scratchbox user group.
You will need to start a new login terminal after being added to the
'sbox' group for group membership to be effective.

Login to scratchbox session using the following command (as user):

        $ /scratchbox/login

Refer to scratchbox.org documentation for more information re scratchbox:
http://scratchbox.org/documentation/user/scratchbox-1.0/

pete@ubunt:~$ 

So we need to add a user for scratchbox. This should be your usual user. What happens is that scratchbox sets up multiple build environments for your multiple processors, and within these has a home directory that has the same permissions etc as your home dir. This means that you can easily copy files into your common scratchbox home dir, without requiring root access.

pete@ubunt:~$ sudo /scratchbox/sbin/sbox_adduser pete yes
Adding user `pete' to group `sbox' ...
Done.
Scratchbox user account for user pete added
pete@ubunt:~$ 

You should now log out of your system and log back in again to allow the permissions to propagate, otherwise you are likely to get a permission denied message when executing the next step. Once logged in again, obtain a terminal and use the following.

pete@ubunt:~$ /scratchbox/login

You dont have active target in scratchbox chroot.
Please create one by running "sb-menu" before continuing


Welcome to Scratchbox, the cross-compilation toolkit!

Use 'sb-menu' to change your compilation target.
See /scratchbox/doc/ for documentation.

sb-conf: No current target
[sbox-: ~] > 

Installing Maemo
Having the sbox prompt means you have successfully installed scratch box. We need to now install the maemo SDK into our build environments. Also, it should setup all our build targets during this point. Setting these up manually can be time consuming and annoying, so it’s great to have a script to do it for us. So we first need to exit our scratchbox root, by typing Ctrl+D and then start the sdk installing by;

wget http://repository.maemo.org/stable/4.0/maemo-sdk-install_4.0.sh
chmod +x maemo-sdk-install_4.0.sh 
./maemo-sdk-install_4.0.sh

Notice how I haven’t needed to put a sudo in front of the maemo sdk install script. This is because the build dir is set up to be in your name, and so you will always have privileges to write to it.

During the course of this install script, you will be asked what type of development environment you wish to install. For now, we’re going to go with the default installation type 3. If you’re curious as to what the different types of install are, I have listed them below from resource [1].

• Minimal Rootstrap only. Choose this only if you are going to install all packages you need from repository.
• Runtime Environment. Use this to install and run software inside Scratchbox. Cannot be used for building software.
• Runtime Environment + All Dev Packages. Choose this to get a full development environment.
• Runtime Environment + All Dev and Dbg Packages. You will get a full development environment plus debug symbols for many system components.

You will also be asked to accept the license agreement for the Nokia Binaries. If you object to this, I can’t help you If you agree hit space a few times to read the liecnse agreement and then type I accept before hitting enter.

The great thing about the new installer is that it does most of the work for you. In the old installer there was a lot more to setup, and there were a few problems with getting apt-get updates to work inside the scratchbox environment.

After the installtion has completed, we should be presented with a message similar to the following

Nokia EUSA binaries
-------------------

The package maemo-explicit is a metapackage of Nokia EUSA licensed
binaries which can be installed to scratchbox targets. It is highly
recommended to install this package on both targets to ensure a fully
working system.

If you want to install these, login to scratchbox (see commands above)
and run the command 'fakeroot apt-get install maemo-explicit' for both
armel (CHINOOK_ARMEL) and i386 (CHINOOK_X86) targets.

Happy hacking!

We’d better do what it says. To do this, we need to enter our scratchbox environment again.

pete@ubunt:~$ /scratchbox/login

Welcome to Scratchbox, the cross-compilation toolkit!

Use 'sb-menu' to change your compilation target.
See /scratchbox/doc/ for documentation.

[sbox-CHINOOK_ARMEL: ~] >

Now we need to install the maemo-explicit package as instructed, by running the following.

fakeroot apt-get install maemo-explicit

Once the upgrade has finished, you should switch to the other build target by invoking the sb-menu command. This will yield a menu system, using the arrow keys, select the option Select : Activate a target, and choose the environment you haven’t yet updated, in our example CHINOOK_X86. Now just run the above command again and we should have both environments setup ready to go.

Testing it graphically
Ouch, we’re almost there I promise, switching to [2]. We’re now going to load up another terminal in order to test the graphical running of the maemo system, and to compile a test program and run it in the ARMEL target. In this new terminal window, we simply need to run two things, first;

sudo apt-get install xserver-xephyr

This will install the nested X server that is required to test the graphical running of the N800 emulation. The second is to actually start the Xephyr server by invoking this command.

Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac -extension Composite

This starts a new nested Xephyr server on display :2, which is actually a new window. You can move this to one side for the time being as we have yet to pipe anything to it. Start up a new terminal window because we require the creation of a file to test the compilation. We’re going to create it in your home directory and then copy it to your build environment, so that you get used to where files in your build environments are placed. Create a file and copy and paste in the following;

#include <hildon/hildon-program.h>
#include <gtk/gtkmain.h>
#include <gtk/gtkbutton.h>

int main(int argc, char *argv[])
{
    /* Create needed variables */
    HildonProgram *program;
    HildonWindow *window;
    GtkWidget *button;

    /* Initialize the GTK. */
    gtk_init(&argc, &argv);

    /* Create the hildon program and setup the title */
    program = HILDON_PROGRAM(hildon_program_get_instance());
    g_set_application_name("Hello maemo!");

    /* Create HildonWindow and set it to HildonProgram */
    window = HILDON_WINDOW(hildon_window_new());
    hildon_program_add_window(program, window);

    /* Create button and add it to main view */
    button = gtk_button_new_with_label("Hello!");
    gtk_container_add(GTK_CONTAINER(window), button);

    /* Connect signal to X in the upper corner */
    g_signal_connect(G_OBJECT(window), "delete_event",
      G_CALLBACK(gtk_main_quit), NULL);

    /* Begin the main application */
    gtk_widget_show_all(GTK_WIDGET(window));
    gtk_main();

    /* Exit */
    return 0;
}

Save the file as maemo_hello.c. We will now close the editor down and copy the file. In this example the file is in my home directory and I’m using a new terminal window to copy because I want to leave our scratchbox terminal window in scratchbox, and our Xephyr window ready for use.

cp maemo_hello.c /scratchbox/users/pete/home/pete/

Notice where your scratchbox home dir is now. If you run a ls command in your scratchbox window, you should see the maemo_hello.c file appear in your home dir.

[sbox-CHINOOK_X86: ~] > ls
MyDocs                           maemo-sdk-rootstrap_4.0_armel.tgz
maemo-sdk-nokia-binaries_4.0     maemo-sdk-rootstrap_4.0_i386.tgz
maemo-sdk-nokia-binaries_4.0.sh  maemo_hello.c
[sbox-CHINOOK_X86: ~] > 

So, now using the sb-menu command from before, make sure you are in the ARMEL target. This means that any binaries we compile at the moment are going to be made speficially for the N800 and without the help of scratchbox, we couldn’t run them on our x86 processor.

gcc -o maemo_hello maemo_hello.c `pkg-config --cflags gtk+-2.0 hildon-1` -ansi -Wall `pkg-config --libs gtk+-2.0 hildon-1`

This will compile the maemo_hello.c file to the binary file maemo_hello. Please note that this binary file can now be copied across to any N800 machine and run without any problems. Now all we have to do is test it in our scratchbox environment. The following few commands will do that. Still in our scratchbox terminal, first we export the DISPLAY variable to have a value of :2, which will point to our Xephyr server, next we run the startup script for the maemo testing environment.

export DISPLAY=:2
af-sb-init.sh start

Here you should see some text whizz by and it’ll appear that you can’t use that window as it’s occupied. Wait till it’s finished, probably with a line like;

hildon-desktop[6545]: GLIB WARNING ** default - Plugin desktop file not found, ignoring plugin
hildon-desktop[6545]: GLIB WARNING ** default - Plugin desktop file not found, ignoring plugin

Then press the enter key and you’ll get your scratchbox prompt back. Notice also that our Xephyr window now has graphical goodness. This means that the scratchbox instance is correctly running on ARMEL and is piping it’s output to the Xephyr server. We shall now invoke our testing line.

run-standalone.sh ./maemo_hello

The run-standalone.sh script sets up some important environment variables and themes.

Signing off
You should end up with an app that takes up the whole available window and says Hello in the middle.

There you have it. A dev environment set up and ready to use. Only took an hour From talking to some people in the #maemo channels, most don’t even bother with the x86 build environment. As the installer provides it, I feel it useful to set it up and get it running as well. Please read the links cited, and look at the maemo.org website. I hope this has helped people out. Took me several days to get a working system initially, but in doing this tutorial, took me a little under and hour.

References
[1] http://repository.maemo.org/stable/4.0/INSTALL.txt
[2] http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html
[3] http://www.progbox.co.uk/wordpress/?p=351

4 1

So…..Since I’ve been playing round with webdav the last few days, I figured a webdav system may be cool. Just to drag and drop the occasional file. Like a network file server. So…..cadaver is a great command line tool for accessing webdav and it’s already available on Maemo. My idea….wrap a python/other GUI around it and have nice tree like structures to move files too and from the system. All those in favour…..say EYE!

Or if you have a better idea. Let me know. WebDAV seems to be a good idea, as it’s web based and the whole idea of the N800 is to be an internet tablet.

But what do I know :p

3 0

My problem now is, can anyone tell me is this just a kernel fix, or do I have to reflash my entire N800, thereby losing all the programs I have been installing over the last few months. Also do I just leave it for a while as it seems to be working fine on these cards, or am I tempting fate, not that I believe in fate per se.

0 1

• Youtube - Well, this is a toughie. I guess I visit YouTube to see clips of favourite videos, to see video demos of new technology, and often to see instructional videos about things I’m interested in. I’ve also used it occasionally to post to in order to get a video in a nice format I know people will be able to use. I’ve used YouTube over GoogleVideo, purely because of the quality of the resulting uploaded video.
• GoogleVideo - Google Video seems to be geared towards more commercial usage, rather than just posting a video of your and your mates destroying a bin in your garden, a la Youtube. I have a few videos posted up here of my talks at HantsLUG. If I can’t find what I want at YouTube, I normally will go to google video as my second choice. Google also seems to have a much longer clip length available, which makes it excellent for some applications
• Stage6 - The Stage6 site is awesome, most noteably because of it’s high-quality videos, which are just staggering. Last time I used it, it worked well with Totem, which should please most open source enthusiasts. I go there primarily for the high-quality videos which sometimes is a must for my work. DivX also provide a web player, which at the moment is only windows and mac supported.

So I guess my questions are what should we be expecting and demanding from the next generation of video sites and video players? Are there aspects of a web player which would make it viable to download? If people started making Linux versions to these players, why would we want them? Now that handheld devices like the Nokia N800 are out and using Linux, I thought it was about time we put down some ideas.

Some people like the community side of things. Sharing videos with others.
Some people like the quality side of things. Getting the most for your buck.
Some people like features. Just having the most fun things available.

What do you want in a video site, what interests you?!?

0 0

Guess it’s time for another C++ porting project.

1 0

It basically works like so, the samples variable holds the start/end nano second markers for each of the sample files. These hold 5 notes from each string, and basically….make the sound.

The GUI will obviously need work, it’s just a test base right now. The problem is that when pressing any button in quick succession, the program crashes. If you wait about 3-4 seconds before pushing each button, it’s generally ok. Please can someone help me out here. I can’t wait to start polishing this app.

Code and samples available here.

2 0

A little background, scratchbox ships with python already installed. Once inside you scratchbox environment, just run;

which python

and you’ll see the following;

[sbox-SDK_ARMEL: ~] > which python 
/scratchbox/tools/bin/python
[sbox-SDK_ARMEL: ~] > 

This causes us a bit of a problem as the version of python installed is 2.3. Which is not really suitable for our needs. Adding the following to your sources.list file, will enable you to install the python2.5 package, which is what we will be developing in.

deb http://repository.maemo.org/extras/ bora free

I installed python2.5 and all related dev bindings by running the following command;

apt-get install python2.5*

Now running applications as you normally would, will still fail because the SB environment is still using the old python. I don’t want to change this behavior yet, as I have seen it cause issues on other people machines. Instead, we will run our code with the python version prefixed to the command line, as demonstrated below

/usr/bin/python2.5 gst_test.py

However, this will fail if you’re trying to use gtk at all. I was using gobject for a timeout. Since gobject relies on gtk, and gtk wasn’t working I was in a bit of trouble.

Searching around on the net, I found an interesting forum post about this. It seems that the environment variable DISPLAY, needs to be pointing to a running X session, before the gtk library can be imported. If you don’t do this, you get the following;

[sbox-SDK_ARMEL: ~] > /usr/bin/python2.5 gst_test.py 
Traceback (most recent call last):
  File "gst_test.py", line 7, in <module>
    import gtk
  File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 83, in <module>
    
  File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 70, in _init
    
NameError: global name '_gtk' is not defined
[sbox-SDK_ARMEL: ~] > 

Which stumped me for a while. Reminding ourselves of the process we used in my previous tutorial, it’s now relatively easy to get python, gstreamer and gtk working. We first need to start Xephyr outside of the scratchbox environment, using something similar to the line below.

Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac

This will start our X server on screen 2, so we can now connect to it in our maemo environment. Back in our SB environment, start with exporting the DISPLAY variable, and then running the start up script, followed by pressing enter to get our prompt back, once the script has finished executing.

export DISPLAY=:2
af-sb-init.sh start

Now all we need to do is run our python program with the right command line. As mentioned before, the run-standalone.sh script sets up various environment variables etc, which are useful to have.

run-standalone.sh /usr/bin/python2.5 gst_test.py 

Now we can get gtk apps running properly, in python. Now I just need to get gstreamer doing what I want.

Enjoy.

Thanks to the Maemo guys, this is my first post on planet Maemo too!

14 0