Hanging around on developer IRC channels and quite some mailing lists, I have answered "How do I create driver update disk?" question many times already. Usually a person asking was given RPM package with the fix and was asked to test it by creating driver update disk. Unfortunately, existing documentation leaves that poor fellow pretty helpless as for how it can be done.

There is this (almost) fossil how-to created by Henne and though it still holds up to these days, things were incredibly simplified in the meantime and now anyone can use driver update disk without any advanced technical knowledge. This post is an attempt to make up for missing documentation on the subject.

What is driver update disk and why do I need it?

Driver update disk is a mechanism to add or replace some functionality (binary, library, script, ...) in the minimalistic system of 1st stage of installation (inst-sys). Historically, it was a real physical media (CD/DVD) often used to extend inst-sys by new hardware drivers. Nowadays, its usage is neither limited to physical media, nor to deployment of device drivers.

Usually you would use driver update disk in one of following two situations:

1. Something in inst-sys is broken and you want to replace it with functional version
2. Something is not in inst-sys at all and you want to use it during installation anyway (e.g. a proprietary device driver).

OK, now how do I do it?

We will have a look at two use-cases - creating driver update disk from 1 RPM package (easy) and from two or more RPM packages (a bit more complicated, but still fairly easy), as the procedure slightly differs. We will need:

• replacement/additional RPM package(s)
• HTTP/FTP installation repository (no NFS/CIFS at the moment, sorry)

One package driver update disk

Example: during installation, you want to create /home partition with CrapwareFS which is already supported by YaST, but it fails because of bug in parted. A new parted-x.y-z.rpm seems to contain a fix for the bug. HTTP installation repository is on http://your.server.net/11.2/

1. Place fixed RPM package to HTTP installation repository (e.g. to its root directory)
2. Pass the path to fixed package (which will be one and the only component of our driver update disk) to the installer as follows:
   

   
   dud=http://your.server.net/11.2/parted-x.y-z.rpm
   

   (see picture below where exactly to type it in the installation screen)
3. Launch the installation and enjoy it, provided that updated package really fixes the bug

N packages driver update disk

Example: you have seen package slide show during installation many times already and in order not to be bored while packages are being installed, you would like to play chess (a bit artificially constructed example, but it serves the purpose of showing driver update with more packages fairly well :) ). You have already downloaded xboard-a.b-c, gnuchess-d.e-f and xorg-X11-fonts-g.h-i from contrib or other online repositories. HTTP installation repository is again on http://your.server.net/11.2

1. Place extra RPM packages to the root directory of HTTP repository (you may place it anywhere though, but then modify paths below accordingly)
2. Create a simple text file e.g. info.txt with one package per one line as follows:

   
   dud=http://your.server.net/11.2/xboard-a.b-c.rpm
   dud=http://your.server.net/11.2/gnuches-d.e-f.rpm
   dud=http://your.server.net/11.2/xorg-X11-fonts-g.h-i.rpm

3. Place info file to the root directory of HTTP repository
4. Point the installer to info file:
   

   
   info=http://your.server.net/11.2/info.txt
   





5. Launch the installation
6. As soon as you get bored, open xterm window (Ctrl-Alt-Shift-X), run xboard and play! :)

And we're done. Piece of cake, isn't it? :)

Some more notes: Currently, only HTTP and FTP repositories can handle these simplified driver updated discs. You can use, aside from RPM packages, cpio archives or fs images. If you find this functionality useful, send some beers to Steffen Winterfeld.

As you might know, Contrib is a universal repository for third-party packages. Branching of this repository to openSUSE:11.2:Contrib is going to happen on October, 30, so if you want to have your favorite application or tool included in openSUSE:11.2:Contrib, please submit your request as soon as possible.

If you already maintain some package(s) in Contrib, please spend a few minutes by checking that the package builds fine, has properly set metadata (maintainer, bugowner) etc.

Yes, I am going to Encuentro Linux 2009, and so does openSUSE!. This year the most important Linux event in Chile will be held in Valparaiso and Viña del Mar at the same time. I’ll be giving a presentation on SUSE Studio (if you didn’t already know ) on Saturday 24th, 10:00 – 11:10 AM. Of course I am taking all openSUSE 11.1 DVDs I have left, and will be a great oportunity to show on my notebook  what’s coming for 11.2.

More information (in spanish only) here. See you there!.

Kolab on openSUSE made some very good progress since my last blog update on this topic. The most visible thing to the system administrator is that all Kolab required packages are available on the build service for openSUSE_Factory which will become openSUSE_11.2 very soon and its and predecessors.

In the past Kolab depended on the project c-client for imap annotations, but about a year ago this project became less open source than it used to be. For this reason I started to look for an alternative, which was found by just removing the c-client project as a dependency for Kolab. This forces Kolab to use the php-pear-net_imap annotation code. It is perhaps not as fast as the c-client code, but I assume that this gives no problem on openSUSE based Kolab installations.

Getting rid of the c-client project has another very big advantage as it now no longer required to rebuild the php module php5-imap. This was always very very problematic, especially for the x86_64 architecture. So the current setup is really nice.

As usual with building packages, getting rid of the c-client looks easier than it actually was, as a bug in the php-pear-net_imap project resulted in a non working setup. It took quite some time, before the solution was found and Kolab started to behave correctly again

For openSUSE_11.2 the php package php5-pear-log was removed from the base distribution, which prevented many Kolab required php5-pear modules to be build. Once the package was added to the server:php:applications build repository all the required Kolab required php5-pear modules started to build properly.

So for the brave at heart, give Kolab on openSUSE-11.2 a try. For the less brave ones try Kolab on openSUSE-11.1.

Oh and don’t forget to vote for Kolab in openSUSE’s feature tracking system openFATE!

 First of all i didn't post a long an entry for a long time, so it's time to do it.  Today because it's my 25th birthday.
This is a special birthday for me because i feel my life changing constantly (which is awesome). I finished my degree in Physics Engineering last month and in 3 weeks i will deliver my masters thesis in Physics Engineering too, before the end of the year i will do the final presentation and get the masters degree. This is taking me lot's of time, so no time for contributing for GNOME and other projects (sorry last year will be better i hope). 

So for now, you can see some news from me on twitter or facebook (yes i ended up being a facebook addict mostly to get some fun around with my friends)


PS: Gwibber developers, please fix 100% CPU bug that is preventing me from running gwibber all the time

kthxbye :)

Yes, it's been a month since openSUSE Conference 2009 took place. And yes, I've been buried in other work to write my account of it any sooner. So - here it finally is. As there has already been a lot of posts like this, I'll just cherry-pick the things that were the most interesting for me.

I gave  "Libyui - three interfaces for the price of one code" talk and received some valuable feedback (on the conference and later too, as I reiterated the talk for SUSE Prague employees) on making the library even better - how to improve packaging (from Pavol and Martin) and how to modify event handling (from Reinhard). As evaluating myself and the things I do objectively has never been my strength (which means, in other words, that I really suck at it), I'll deliberately not say anything more on topic :) ;) Enjoy libyui slides

Software portal in new costume

I was really looking forward to Benji and Pascal's talk on Software portal as I'm YaST webpin frontend maintainer (which is, contrary to some beliefs, not a beta version anymore - it has its own package and also a brand new chapter in openSUSE 11.2 docu :) ) They introduced concept and architecture of new improved software portal and also described some issues they face. Too many package repositories, lot of package duplication and lack of concise rating system were among the most prominent ones. I was also happy to learn that susetags repo parsing and indexing is on the way, so soon also Factory will be webpin-searchable.

Cute (Qt) community

I couldn't have missed Alexandra Leisse's presentation on Qt community and contributions as it's always delighting to find some of one's own species among tech conference speakers and not to be the only one standing out in the crowd.
Alexandra is web community manager and we learned that even though uploading videos to youtube, tweeting and feeding news to Facebook looks like funny job, it can be hell of a hard work :) She explained how they manage public relations with wannabe developers (in a sense of well accessible developer documentation, contribution how-to, tutorial and feature videos etc.), which ways they took in opening up the code to public (their cooperation with gitorious.org was especially interesting bit) and how they handle community contributions and code reviews. She also described some of the problems they had to tackle.

opensuse.org in the eyes of eye-tracking device

With software usability being my area of interest, I decided to pick one of unconference tracks led by SUSE's usability expert Sigi Olschner. I've never seen usage of eye-tracking device in practice, so I was really curious what feedback it can provide to user interface designer (oddly enough, I couldn't be the guinea pig myself, as I wear contact lenses and the device just failed to calibrate my pupils with lenses on :) ). As sophisticated as eye-tracker is, it can record eye movement, mouse pointer movement and keyboard focus movement and later present data in various forms - such as heat maps, or "movies" (where one can replay the sequence of how user moved the mouse and where s/he looked during the test).

Test tasks this time were really simple. "Go to openSUSE forums and try to find some information on driver for Radeon gfx card" and "Go to openSUSE wiki and find out the date of 11.2 GoldMaster release".

Weeeell ... one does not need an expensive device to find out how much opensuse.org (in a sense - "anything on opensuse.org beyond the title page") sucks^W improvement would be needed and how cumbersome it is to find what you're looking for in there (you're far better off googling for "$searchphrase site:opensuse.org"). But seeing the final video of an attempt to find openSUSE 11.2 GM release date, with user's eye focus running chaotically up and down on the page in combination with mouse pointer zig-zag track revealed opensuse.org's bad usability in its essence (at the end, he was unable to find the date at all - from the title page he correctly navigated to the page announcing milestone7, but couldn't spot the link to full release schedule at its very bottom).

Suggestion: could Pascal's next release countdown applet be moved to some more prominent place e.g. to the opensuse.org title page?

Moreover, in the light of previous talk on Qt community I surfed on Qt community pages later at home and their proffesional appearance, easily accesible information and intuitive navigation were really in sharp contrast with our pages. I wonder how many more users would improved navigation and look&feel of opensuse.org (wiki and forums) win us ...

A movie with package dependencies as main stars

Everyone knows package dependency browser in YaST Qt package manager. So I was rather curious what more on visualizing package dependencies Klaus Kaempf has to show. And that was really something. More sophisticated 2D graph, 3D graph and even a movie, visualizing how GNOME basesystem is being installed and how packages are gradually pulled in (as it really looked like a star galaxy, we can say that GNOME packages were the main stars of the talk :)).
Klaus however left ideas where to use package dependencies visualizations up to the audience and at the end of the brainstorming, there were quite some useful proposals. I really liked one of the build service integration ideas, where I could view which packages block the build of my package when I see its status as "blocked".

.... and that's all, folks. I had to leave early on Saturday. But not early enough to miss out lunch, which was really excellent. Praise goes to conference catering.

After another 4.5 months development, including contributions from 51 people, we have released Banshee 1.5.1! Shuffle Modes Shuffle by artist or album let you listen to everything by an artist or on an album before jumping to a new random artist or album. Shuffle by rating or score lets you shuffle through your songs, with higher rated or scored tracks being more likely to play. Thanks to Elena Grassi for her patch for the rating shuffle mode that got the ball rolling. Alexander Kojevnikov wrote more about the new shuffle modes on his blog. Auto DJ This new feature gives you the option to keep your Play Queue filled with endless music. It builds on the shuffle modes work, letting you fill the queue randomly in artist, album, song, rating, or score mode. As ever, you can manually add, remove, and reorder songs in the Play Queue — even while in Auto DJ mode. Alexander, the mastermind behind this new feature, wrote more about the Auto DJ on his blog. More Info Other notable new features include keeping the playing song visible, showing tooltips for ellipsized text in the main grid view, and support for WebOS and Samsung Galaxy devices. There were over 130 bugs fixed and 20 other enhancements added since 1.5.0. Read about them on the release notes. Visit our download page to try it out!

Motivation
Sometimes, there is a need to check some patch in the installation system. Of course, we have an article that describe how to Create a Modified Installation System but this one takes a lot of time to prepare, you need a remote server and several things can break.

You can also use Driver Update, but that expects you are able to build RPM with the changes you want to test.

Here you can see the simplest way...

Starting-Up
Start installation from media by adding startshell=1 to the Linuxrc commandline. This will make installation open a shell window before starting YaST/Installer.

You can also boot directly to the installation without adding startshell=1 to the command line but it that case you can't change files that are loaded when the installer starts. Your choice :)

Preparing Installation System
By default, the installation system is read-only but we can cheat it ;)! Let's assume we want to change some YaST script in /usr/share/YaST/clients/ directory in this example.

# The only writable directory is /tmp (and /var...)
cd /tmp
# Copy all clients to /tmp
mkdir clients
cp -ar /usr/share/YaST/clients/* /tmp/clients/
# Bind the writable directory to the original location
mount --bind /tmp/clients /usr/share/YaST/clients

Now you can edit, extend, remove, compile ... etc. the writable clients directory. Hint: If you want to start network (and your network supports DHCP) to copy the patched sources using network, just simply enter dhcpcd eth0 (or similarly according to your current setup).

And ... that's all folks!

Continuing with the Installation
If you have used startshell=1, just simply enter exit command or press Ctrl+d.

"The researcher, Jim Salinger, concluded:

It will mean either there will be pubs without beer, or the cost of beer will go up.

If that sentence doesn't sharpen the focus on the climate change debate, frankly, I don't know what will."


http://www.guardian.co.uk/environment/blog/2009/sep/16/climate-change-beer-quality

(Yes, dear planet reader, this is opensuse-related ;-) )

Amazon's Product Advertising API (PAA) lets you search pretty much everything they offer. But on August 15 they started requiring that all requests to the API be signed with the developer's Private Key. Any client-side software using the PAA directly, including website scripts, Firefox extensions, and desktop applications, would have to distribute their Private Key to all their users to sign the requests. But as you would expect, the license agreement for the API states

a private key...is for your personal use only and you must maintain its secrecy and security.

Others have written about how the PAA license agreement bars its usage on mobile devices. But in fact, it bars it from any client-side software on any device. Or at least from software you want to distribute. You can work around this by hosting a server to sign requests for your users, keeping your Private Key private. But anybody could use your service, pretending to be your client software if necessary. And you could wind up signing requests for half the Internet. The signing requirement benefits nobody. It impedes developers, turning them off from creating applications to serve users and send customers Amazon's way. Amazon should acknowledge its mistake with this policy and reverse it. Thanks to James Vasile for reading drafts of this.