Wind of change…

5 11 2008

Hello world,

Just to let you know, I’ve changed by blog to

Feeds can be picked up from


Official drink for openSUSE addicts

19 10 2008

Seems openSUSE addicts now have an official drink. In Australia, we currently enjoy an Ad like this:

Howto: Turn a 2 hour meeting into a 14 hour work day

18 10 2008

This is an howto for those of you with too much spare time. I will show you how to turn a 2 hour meeting into a 14 hour workday.

1. Move to Sydney
2. Get a job with a company that forces you to use the worlds most useless travel agency
3. Make sure you arrange a meeting with a customer in Melbourne
4. Use said travel agency to book your flight from Sydney to Melbourne at 7.15am. Also make sure to tell them that you want to return that same day at 2am
5. Order a taxi for 5.45am to go to the airport
6. At the airport, try to check in electronically (which, off course, will fail)
7. Queue up to check in
8. Board the plane by going to your gate. Make sure to pass through the security checkpoint
9. Arrive in Melbourne (this should happen automatically if you boarded the right flight) at around 8.45am
10. Queue up for a taxi (this can take somewhere between 5 and 30 minutes)
11. Arrive at destination 45 minutes later (if you are lucky, time is now 9.45 so you could go for a quick coffee)
12. Have meeting with customer
13. Leave customer and try to get a taxi. This, again, is somewhere between 5 and 30 minutes
14. Arrive at airport around 1.30pm
15. Try to check in electronically, which again will fail
16. Queue up to check in (although step 15 and 16 seems repetitive, it’s necessary)
17. Arrive at counter only to be told that there you have no flight booked for the day
18. Go online to frequent flyer members page to find out that the return flight was booked for tomorrow
19. Back to counter only to be told that they can not changed it there. Have to go to their Sales inquiries for that
20. Queue up for their Sales counter
21. Talk to Sales rep, only to find out that they can not change it. Only the travel agency that booked it can
22. Ring travel agency, tell them that you actually wanted to go home the same day. Listen to apologizes while the rep changes your flight. Pay attention when they let you know that you got the last spot on the 3.30pm flight. Make sure you thank them for their efforts.
23. Queue up to check in for your 3.30pm flight
24. Enter the airport (via security check point). Get asked for permission to sweep you for drugs (this step is sort of optional. You can actually refuse, but then you are not allowed to fly)
25. You now have an hour for lunch so eat something (you will need this)
26. At 3.10pm, listen to the announcement that there is a problem with your plane. They will update you as soon as they know more
27. Keep wondering what’s happening (the airline will try to keep you in the dark as much as possible)
28. Listen to several more announcements about how they are trying to fix the issues with your plane. Also watch the boarding time moving forward all the time (3.40pm, 4.10pm, 4.40pm etc)
29. Now, and this is very important, listen to the final announcement where they tell you that the aircraft can not be fixed, but they allocated another one at a different gate.
30. Once you arrive at the gate, listen to the next announcement and laugh to yourself about those poor travelers who’s flight was canceled so that you could get an aircraft. You will feel even better knowing that most of those passengers will not be able to fly to Sydney that Friday night.
31. Finally get on plane and wait for 30-45 minutes while they try to find some missing passengers
32. You should now be on your way back home to Sydney
33. Arrive in Sydney at 6.45pm
34. Line up for taxi (this time, it’s a minimum of 30 minutes wait time)
35. Arrive back home at 7.45pm

For what it’s worth, the meeting was great 🙂

Updated; Build Service Collaboration

9 08 2008

The new openSUSE Build Service collaboration mechanism rocks. I’ve been playing
with it for a couple of days, and thought I blog about my findings, incase
someone finds them useful.

How to get started
Create yourself an OBS account by going to, then click “Register | Login”
Install the osc package. Easiest way to do that, is by browsing to, search for osc, then use the 1-Click Install for the  openSUSE:Tools:Devel repository.
Find a package that you want to contribute to, in my case, I use which contains all GNOME packages that needs to be updated.

Now that you found a package, do the following (I will use cheese as an example package. Also, whenever you see “MBoman”, it should be replaced with your OBS user name);

1. Create a branch where you can work on the package

> osc branch openSUSE:Factory cheese

Note: The branch has been created of a different project,
which is the primary location of where development for
that package takes place.
That’s also where you would normally make changes against.
A direct branch of the specified package can be forced
with the –nodevelproject option.

A working copy of the branched package can be checked out with:

osc co home:MBoman:branches:GNOME:Factory/cheese

2. Check out the package

> osc co home:MBoman:branches:GNOME:Factory/cheese
A home:MBoman:branches:GNOME:Factory/cheese/cheese-2.22.3.tar.bz2
A home:MBoman:branches:GNOME:Factory/cheese/cheese.changes
A home:MBoman:branches:GNOME:Factory/cheese/cheese.spec
A home:MBoman:branches:GNOME:Factory/cheese/ready

3. Download the latest package (most of the GNOME packages can be found at to home:MBoman:branches:GNOME:Factory/cheese

4. Change to the package directory

> cd home\:MBoman\:branches\:GNOME\:Factory/cheese/

Let’s say that the package in GNOME:Factory was cheese-2.22.3.tar.bz2 and we downloaded cheese-2.23.6.tar.bz2

1. We need to delete the older version from this project (note! *Never* use rm when deleting files here)

> osc del cheese-2.22.3.tar.bz2
D cheese-2.22.3.tar.bz2

2. Then add the new version

> osc add cheese-2.23.6.tar.bz2
A cheese-2.23.6.tar.bz2

3. We then need to change the .spec file to reflect this new version
Open up cheese.spec in your favorite editor, then find the line starting with “Version:”
For this example, you should see something like this;
Version:        2.22.3

Replace the above version with the version of the new package, so it looks like this;
Version:        2.23.6

4. Next, we need to find out what changed between 2.22.3 and 2.23.6. There are a couple of ways to do this, and not all of them works for every package :-/

1) See if you can find a news file for all versions between 2.22.3 and 2.23.6 on the ftp server where you download the package from
2) See if there is a usable NEWS file in svn (
3) Unpack the tar ball and see if there is a usable NEWS and/or ChangeLog file in there

5. Once you found out what changed, open up cheese.changes in your favorite editor
Couple of things to remember;

* Follow the same format as previous entries
* Wrap lines that exceeds 76 characters
* Don’t use more that 40-50 lines to describe the changes as rpm copies the entire changelog to rpmdb.
* If there are bug entries (ie, #123456), figure out what bugzilla the bugentry comes from, and then change from #123456 to bgo#12346. Note that bgo should be replaced with the proper bugzilla entry from the list at

6. I found it very useful to run ‘osc st’ at this stage. It’ll list all changes you’ve done. For a version upgrade, we will want to see 1 or more adds, 1 or more deletes and both .spec and .changes files modified;

> osc st
D cheese-2.22.3.tar.bz2
A cheese-2.23.6.tar.bz2
M cheese.changes
M cheese.spec

7. Commit your changes and see if the package builds. Describe what you’ve done with the -m switch;

> osc commit -m “Updated to 2.23.6”

8. Check the status to make sure the package builds;

> osc r

9. Once the package builds, submit it to the GNOME maintainers (again, use the -m switch to describe your changes);

> osc submitreq create -m ‘Updated to 2.23.6’

The GNOME maintainers will get a notification that you submitted this request.
Once they act upon it, you will get an email back. Basically, it’ll be approved or declined.

You can list existing submissions using this command;

> osc submitreq list GNOME:Factory
666 new (mboman) home:MBoman:branches:GNOME:Factory/cheese -> GNOME:Factory
‘Updated to 2.23.6’

Other things to note;
If you delete or add patches, make sure that you note that in the .changes file as well. Clarify why a patch was deleted.

openSUSE 11.0 Pre-Beta3 Screenshots

10 05 2008

Here’s some screenshots from the Pre-Beta3 GNOME LiveCD.

Upgrading 10.3 to 11.0 (Factory)

28 03 2008

I’ve started testing 10.3 to 11.0 upgrades to make sure that the Desktop doesn’t break etc.

For my first go, I used a backported version of zypper, since it handles dup (Distribution Upgrade).

In case it’s of interest to other people, here are the steps;

1. Install 10.3
2. Add oss, non-oss and update repos
* zypper sa updates
* zypper sa oss
* zypper sa non-oss
3. Run the following twice (First run will update a few packages which are required to properly apply the rest of the patches) then restart the computer
* zypper up
4. Add the libzypp/zypper backport repository
* zypper sa zypp
5. Run the following (Note! This will ask you to remove some YaST packages etc from your install. Answer Yes)
* zypper up -t package
6. Remove all repositories (Repeat the command until zypper tells you there are no repository to remove)
* zypper sd 1
7. Add the Factory repositories
* zypper sa oss
* zypper sa non-oss
8. Run the following command;
* zypper dup

During Step 8, I got two errors. First one was that it couldn’t find yast2-trans-en_US on the media (the version I had was older than the one it tried to install), so I simply removed the package with ‘rpm -e yast2-trans-en_US’ then run zypper dup again. I got the same error on opensuse-manual_en so removed it with rpm and restarted zypper dup.

Please be advised that the above procedure is not supported and should only be done on non-production installs.

Do you want fries with that?

19 03 2008

I was idling in the #opensuse-gnome channel on IRC today when a user came in, asking for help. We managed to sort his issue out in 10 minutes. He then asked another question, which again didn’t take to long to answer. But then…

user: is there a gnome ppp for gnome?
user: the only thing i found is the source to compile which would be a real hassle for me because of all te dependecies that i will need
captain_magnus: Source for?
user: gnome-ppp
captain_magnus: Hang on... Lemme have a look
user: k thnx
captain_magnus: Sorry, can't find a pre-built one.. Do you have a url? Perhaps we could add it to our build service
user: sure hold on
user: from that site you can download the source code
user: you will need gtk++ 2.4.x to compile it correctly and gtk needs files, etc. etc.
captain_magnus: Ok... I'll see if it's somewhat easy to compile and if so, I'll build an rpm... Are you hanging around for a bit?
user: yes
captain_magnus: Ok, it was easy to compile and install... I'll try to create an rpm for it now...
captain_magnus: Btw; Are you on 10.2 or 10.3?
user: 10.3
user: ive got an i686 btw
user: please dont upload any viruses in the rpm
user: will i be able to install it via rpm if i dont have gtk++?
captain_magnus: You should not have any issues installing the rpm... You will add a repo from the openSUSE buildservice and install it from there, which will then install any dependencies
user: so you've already uploaded the rpm onto
captain_magnus: No :-) I must first build a .spec file for it... Almost done
user: ok dont mean to bug you
user: take ur time i got a couple hours
captain_magnus: Yeah, I'm no expert when it comes to packaging... But hopefully we get it to work on the first go...
captain_magnus: It's building in build service now... Will have to wait for that to complete...
user: k
captain_magnus: You should be able to add my repository and install gnome-ppp now:

I’m sure the .spec file I created when I built the package for this user wasn’t the best one but it worked for him/her. After this, I started thinking about those users who don’t have experience with compiling packages etc, and why should they need it? Sure, they can always come to IRC and we build it for them but… 🙂
I’m thinking that we should allow users to upload tar balls to our execellent build service and it will automatically create a spec file and build the package for it. This, I’m guessing, is of course not possible for every package out there, but really, it should be possible to unpack the tar ball, figure out it’s dependencies etc, and create a spec file automatically.

Perhaps this is even a good idea for openSUSE Summer of Code?