photo credit: James Nash (aka Cirrus)

I got a new N96 a couple of weeks ago, as my old Nokia was barely functional any more. No backlight and ~8 hours battery life is not good, I tell you now.

The good:

• Build quality is nice. Some people might say it's a bit big, but I like it. Despite its size, it's still quite light - I weighed it against an iPhone and it came out lighter.
• Huge, excellent quailty screen.
• 16GB of storage, for plenty of music. Goodbye iPod.
• FM Radio(!)
• Uploading geotagged pictures to Flickr works a treat. You do have to remember to have Location Tagger running though.
• BBC iPlayer, not that I've used this much yet (see below).
• Tonnes of apps thanks to Symbian. Decent ones include:
  • PuTTY for Symbian OS
  • Opera Mini
  • Google Maps for your phone
  • ??? (I'm sure there are more good ones that I don't know of yet, please let me know)

The bad:

• The firmware that it came with is, quite frankly, shocking. Crashes and bugs galore. The worst part of it seems to be the accelerometer - the screen redrawing when it detects a rotation is awful. Seeing half drawn applications in each orientation is not what you want to see on your expensive new phone. There's also some general slowness with apps taking a while to initialise, but I suspect this is inherent.
• The camera, despite being touted as excellent, seems to produce pretty grainy pictures to me. I hope it's just the way I'm using it, because I'm getting the feeling that "Carl Zeiss optics" aren't as good as Nokia try and make you think they are.
• iPlayer works great on wifi, but the videos never start over 3G.
• If you actually do stuff with it, the battery life can be quite terrible - just doing a bit of 3G internet use (SSH or WWW) is enough to drain the battery to nothing in a few hours.
• Closing applications on a phone is odd, and I keep forgetting to do it. Some applications close when you hit the red button, and some don't. I need to get used to this. Annoying the "Log" application doesn't close after you use it to make a call.
• Shutting the slider while on a call doesn't end it.
• I've had it freeze up while a call is coming in and refuse to answer it, causing me to miss the call. It was from a withheld number too, so I couldn't call back (not that I should have to).

There was a letter in the box apologising for the quality of the intial firmware so I'm quite hopeful that a lot of these issues will be fixed when an update is release. I don't know how good Nokia's track record is on this, but we'll see. All in all, I'm fairly happy with it, and when the bugs get ironed out it'll be awesome.

photo credit: Tambako the Jaguar

Well, hello Planet! Since I've been approved as an Ubuntu member, I figured this is as good a time as any to post some drivel. I'm Laney, and I am very pleased to have your attention. I am 22 years young and in a small number of weeks will be a PhD student at the School of Computer Science, University of Nottingham.

I might as well use this platform to ask for your help. No, not for myself, for the Intrepid Ibex. Look at the picture up there, he needs you to help him. You couldn't say no to that, could you?

James Westby has made a much more comprehensive post on this, but I'd just like to retierate the testing part. If you feel you're able to recover from any problems that might occur (should not be too severe now we're in feature freeze) and your system is not mission critical then please do consider helping out. It was with some hesitation that I made the switch a week or so ago, and I've certainly found my fair share of bugs and have to live with a slightly more unstable system (particularly audio-wise), but it'll be worth it in the end when we ship an excellent Ubuntu 8.10. If you do test, I urge you to get involved in bug reporting, otherwise you're just putting yourself through pain for no gain. When you come across a problem, search Launchpad and the affected program's upstream bug tracker for the issue and see if you can add any more information. If there is no bug, or if you just don't have the time to be searching bug trackers then please do still file the bug on Launchpad and a triager will deal with it for you (maybe asking you for more information). As the ever wise Tesco say, "Every little helps". I've definitely come across a few bugs (probably some I've forgotten here):

• Banshee crashes on Last.FM login
• terminator crashed with AttributeError in get_first_notebook_page()
• seahorse crashed with SIGSEGV in IA__g_object_set_valist()
• file-roller crashed with SIGSEGV in find_image_offset()
• tracker-applet crashed with SIGSEGV in signal_emit_unlocked_R()
• Can no longer configure keyboard shortcuts for switching tabs

A lot of the bugs have a similar format: "x crashed with y in z". This is apport at work, an excellent tool which takes a lot of the work out of reporting crash bugs. Even just reporting these bugs helps to stabilise the system.

So, I urge you, please do run update-manager -d (Ubuntu users) or adept_manager –version-upgrade (Kubuntu), and get involved!

In order to get at your currently playing song on Banshee from a SSH connection into your box, just run the following script:

#!/bin/bash

PID=$(pidof banshee-1)

if [ -z $PID ]; then
    echo "Banshee doesn't appear to be running"
else
    export DBUS_SESSION_BUS_ADDRESS=\\
        \$(cat /proc/\$PID/environ | xargs -0 -n1 \\
            | grep ^DBUS_SESSION_BUS_ADDRESS= | cut -d= -f2-)
    banshee-1 –query-artist –query-title | cut -d ' ' -f 1 –complement | \\
        sed -n '1h;2,$H;${g;s/\n/ - /g;p}'
fi

It will produce output like so:

laney@chicken:~$ banshee-np.sh
Rancid - Corazon de Oro

Now to get it working remotely, just follow Theory's instructions, replacing

command="dcop --user `whoami` amarok player nowPlaying"

with

command="/path/to/banshee-np.sh"

and you should be good to go!

This post brought to you by my burnt hand, which I have to return to the ice pack every 20 seconds or so. Ouch.

Roll on September, when I get to learn about the real stuff that they don't teach you.

If you haven't heard, today at 1700 UTC, Firefox 3 will be released. The Mozilla foundation are celebrating this with a cute marketing campaign, to try and break the Guinness world record for the most downloads of a piece of software in 24 hours. If they've got the bandwidth to burn, and it helps get some coverage of FOSS, why not? I'll certainly be getting it.

Yay!

This article describes the process for merging a package from Debian to the development version of Ubuntu, currently the Intrepid Ibex. If you want to see how I generally go about doing this, follow the jump.

There's a lot of background on what a merge is, and how to go about performing one at this document on the Ubuntu wiki. To some extent I will repeat the same information here, but presenting it as a walkthrough. Essentially a merge is required when a newer version of a Debian package than the one in Ubuntu is released, and the Ubuntu version has local changes that have been made. The process involves checking the Ubuntu changes, and incorporating them into the new Debian package if they are still relevant. I'm going to outline the way I work with a simpleish merge that I recently did, for the package battleball.

Find a package to merge

The first thing to do is to check either DaD or MoM for the lists of packages for which a merge is currently required. I prefer to use DaD as it has convenient links to the Debian PTS and Launchpad pages for all listed packages, as well as a comment field which can be used by people to indicate that they are working on a package, for example.

Once you've found a package to merge, you should ask the uploader of the last Ubuntu version if they mind you working on the merge this time around. They will be able to tell you if there's anything you need to know about the package or if they plan on working on the merge themselves:

<Laney> norsetto: May I merge battleball?

<norsetto> Laney: pls. do

Once the uploader has OKed you continuing on the merge, you may now start to do the actual work.

Paperwork

We (as a non-MOTU) need a Launchpad bug filed for your merge. This is the place where sponsors will look to check your work. Here is the bug I filed for the battleball merge. The title is the most important part - I usually paste the new Debian changelog entries into the bug description for convenience, but this isn't really required as the bug is mainly just for tracking. Set the status to "In Progress" and assign to yourself. You'll also get a bug number when you file the bug. This is needed later in the process.

Performing the merge itself

DaD and MoM both provide a script, grab-merge.sh, to automatically try to perform a merge by combining the changes in Ubuntu and Debian. I prefer not to use this method, however, as often Debian incorporates Ubuntu changes in a different way which can lead to duplications or omissions in the resulting merged package. This is only a personal preference, and I'm sure that many people get by with the scripts just fine.

Download the Debian package from the PTS page and the Ubuntu package from the LP page and unpack these into their own directories. As we're dealing with the same upstream version (only packaging changes in Debian), I'll use Meld, a really cool graphical diff viewer, to do the bulk of the changes.

Red files have changes, green are new and strikethrough are deleted. The next phase is to inspect each changed file to see if it is still required. Throughout this phase it is essential to refer back to the changelogs to see what changes were made in Ubuntu and Debian. We see that the Ubuntu .desktop file change hasn't been implemented in Debian, so carry this change forward. Inspect each file and see if it refers to this change. It turns out that the changes for this are in battleball.desktop and rules. Use Meld to copy the changes over.

In the screenshot above, we can see the changes between the debian/rules file in the Ubuntu version (left) and the Debian version (right). Changes in blue are in the Debian version but not Ubuntu, and don't require you to do anything. Changes in green are in the Ubuntu version but not Debian. These are the ones we need to pay attention to. Figure out why each of these changes is in the old version but not the new. If they are a result of a Ubuntu change that we still need in the new version, then copy them over by clicking the black arrow in the middle. In this case, both changes are to effect the installation of the desktop file, so are copied.

The debian/changelog file should always be merged. Keep the changelog entries from Ubuntu in the correct place order to preserve the history of the package.

Each change that is kept in the Ubuntu version should be forwarded to Debian using the submittodebian tool to send a patch, as long as it is relevant there too. In this case the .desktop file change has already been reported, so we don't need to do anything further. I like to add a bug watch to my merge bugs with the changes that I've reported as part of that merge. That way the person that comes to merge the package next can easily see if the changes have been adopted in Debian or not yet.

Final housekeeping

Once all changes have been accounted for, and copied over if necessary, it's time to perform the housekeeping tasks that keep our upload tidy and compliant with policy. First we need to update the maintainer to be the Ubuntu MOTU team. This is achieved by simply running the update-maintainer program from a shell within the package's directory. Second we need to add a new changelog entry which details what has gone on. In this case the only change that remains from Ubuntu is the adding of a .desktop file. We also need to mention somewhere in this changelog entry the number of the merge bug that we're closing, in the form (LP: #nnn). Using the command dch -i, we will be presented with an editor which has all of the important stuff (version number, timestamp, distro) inserted automatically. The entry that we come up with is:

* Merge from Debian unstable (LP: #239218), remaining changes:
- Add .desktop file
* Modify Maintainer value to match the DebianMaintainerField
specification. (added automatically by update-maintainer)

Testing

Now it is crucially important to test the package. Build a source package by executing the debuild -S command from within the package directory. This will spit out a .dsc and .diff.gz file in the parent directory, which you can use to build the package. I'll not go through the setting up of sbuild here, but you should follow these instructions to get it set up for building packages. This (or pbuilder) is the cleanest and most accurate way of test building. Issue the command sbuild -d intrepid-i386 battleball_2.0-17ubuntu1.dsc to do a test build, and watch the output for any errors. Providing the package builds OK on the current development distro (it does), we can move onto testing. Copy the resulting .deb package onto a VM running the development distro and install it, checking for any errors here. There are none, so we move onto testing the application, in particular looking for the Ubuntu fixes that remain in our merge to ensure that they are still present. In this case the .desktop file is working properly and the program appears to function well after using it for a little while, so we are ready to ask for sponsorship.

Generating files for sponsorship

As a final step before uploading, we need to generate two sets of diffs for uploading: between the debian version we based our changes on and the new version, and between the previous Ubuntu version we took the changes from and our new version. The two commands we need are:

debdiff battleball_2.0-17.dsc battleball_2.0-17ubuntu1.dsc > debian-ubuntu.debdiff
debdiff cur/battleball_2.0-16.1ubuntu1.dsc battleball_2.0-17ubuntu1.dsc > ubuntu-ubuntu.debdiff

Check the changes in both of these debdiffs with diffstat to see that they are all intentional, and verify the diffs manually in a text editor to see that all of the changes you need are present, and all are documented in the changelog.

As they are, we can proceed to uploading and asking for sponsorship.

Uploading and requesting sponsorship

This is the last and possiblly simplest part of the process. Visit the bug's page on Launchpad and upload the two debdiffs you just added, checking the patch box for both of them. I like to paste my new changelog entry to give sponsors a clue as to what's going on in the diffs. Then set the status to confirmed and unassign yourself. From the "Subscribe someone else" page, subscribe ubuntu-universe-sponsors (ubuntu-main-sponsors if this were a package in main), and that's it. Someone will review the patch in good time and upload, thanks to Luca Falavigna for doing this for me here :D.

Links

• List of commands executed during this merge.
• Bug report for this merge.

I managed to sort myself out a job for the Summer which will allow me to stay in Nottingham, which I really want to do. It's weird how for half of my University life I considered home to be back in Alconbury, but then something changed and now I feel more at home here than back there. Perhaps it's because most of my friends have moved on, or maybe I've simply become more used to life here. I'm definitely not going to complain. Notts may have its problems, but it feels like it's on the up to me, and is definitely somewhere I'm happy to stay. That's not to say that the choice between York and Nottingham for my PhD wasn't one of the hardest I've had to make. It really tore me up for a number of weeks, but for a few reasons which I won't go into here I plumped for Nottingham in the end. I'll probably keep wondering how different it would have been had I chosen York though.

Anyway, enough about life. What about nerdy stuff?

The Hardy Heron was released not long ago, and I'm very proud to be able to say that I played a tiny role in its development. My goal is to up my participation levels for the Intrepid Ibex. After my exams are over in a few weeks, I'll find myself with a lot more free time which I'll be able to spend working on the distro. My beady eye is already on a few merges to get the ball rolling, and then who knows? I'd say my goal for this cycle is to get to "Contributing Developer" status, once I've learned enough.

Overall Hardy seems like an incremental improvement over Gutsy. I upgraded (using update-manger) to the beta during development, so the major changes aren't that visible to me sadly. Perhaps a fresh install is in order to see the major changes stand out. It's good to have newer versions of most software too, even if there are some regressions that I've found thus far. Such is life. My linux-fu has definitely increased since I started using it 100% of the time. Prior to using Ubuntu, I'd been using Linux on-and-off every few months but always returning to Windows after some annoying problem forced me to give up. Not so this time; my new PC was (almost) fully compatible from the get-go, and I'd decided to have the resolve to see any problems through. It's been a blast so far.

An early version of the service is available from 9 April.

Woohoo! I'll be trying this. The only downside is that it's apparently only available in the internet channel. It would be much cooler to have an iPlayer icon on the Wii's dashboard. Can't have everything I guess.

I can only laugh at how the ISPs will moan about the increased bandwidth from this. Seriously, it seems that they're only going after the BBC on this one because they have an identifiable target; with filesharing there's no one individual to go after. Shut up and start improving your networks, please. There are only going to be more and more bandwidth-intensive applications like this coming out and ISPs are not going to stop this. They need to roll with it.