Duncan Mac-Vicar P.

As you may know, are working on making YaST functionality accessible via the web. With this we mean not only browser. The current prototype has two parts: a generic web service (REST like API) and a web browser client.

Stefan Schubert announced last week a new snapshot for developers. You can find packages in the build service project. The packages are named yast2-webservice and yast2-webclient.

This is very early code. It is not fast, and the web client is not yet using all user interface possibilities that ajax gives, but there are we going .

If you are an experienced user, and you get it running, you may be interested in getting it running from source code by reading our development web page. Both the webservice and the webclient are rails applications. Developing modules is also easy! Just show up in irc (freenode) #yast.

Two weeks ago I posted about making aria2c the default transfer mechanism for our software management stack.

With libzypp 6.1.0 in Factory, this is already the case. With the first community round of testing, we got quite a lot of bug reports and feedback. Some stuff did not work because the implementation was wrong, while others just showed us that aria2 worked differently as we thought.

The upcoming 6.2.1 addresses the following issues:

• implemented speed indicators (bnc#475506). You should see transfer speed in applications that report it (like zypper).

• implemented progress indicators correctly (bnc#473846). You should see progress reporting now in a consistent basis.

• fixed broken pipe when looking for aria2c which caused a fallback to curl. (bnc#480930)

• implement saving and reading mirror stats data in /var/cache/zypp/aria2.stats. This means libzypp now learns which mirrors are faster and more reliable for you and remembers it. Every usage adds more information to the “learning”.

• handle failover correctly (bnc#481115). This means libzypp tries harder to get the file from alternate mirrors.

• various improvements in error and report handling. General code review and minor fixes.

How to test?

Peter added an interesting “test feature”. If a request happens with a header X-Broken-Mirrors then the openSUSE redirector will send you broken mirrors. So edit your root’s aria2.conf:

cat ~/.aria2/aria2.conf
header=X-Broken-Mirrors: true

And observe zypper.log. Even if errors are reported, libzypp should try other mirrors and get the file successfully.

You can go more extreme, and use “X-Broken-Mirrors: only”, which will give you only bad servers. Even in this case you will see libzypp try hard to get the file before giving up. How hard to try is configurable, see last post for more information.

Big thanks to Peter Poeml and Tatsuhiro Tsujikawa for all the feedback and support, and of course

And with this, feature 302923 is done and the rest is tracked as bugs.

You may remember, openSUSE 11.1 shipped with experimental (and by default disabled) software management stack improved HTTP download support, based on aria2c, which gives additional capabilities to take advantage of our famous download infrastructure, on which Peter has been working on.

The ultimate goal of this is to provide a pleasant experience to our advanced users tracking Factory and doing frequent dist-upgrades (feature 305634), and this includes other cool improvements, like the one announced some days ago, based on Stephan Kulow and Michael Matz’s build compare techniques, and of course the one I describe here: robust mirror handling and improved download experience (feature 302923).

The next step for the aria2c backend is to enable it as a default. Everything was working more or less smooth, except file existence detection, which is needed for the repository probing components. This part of the code was implemented as a “always true” stub.

As the MediaCurl code was already a bit messy, duplication was started to be everywhere, and actually MediaAria2c already had quite a lot of code duplicated from MediaCurl. However, a big refactoring required studying the code in deep.

Thanks to the Asian restaurant near the office, which did not clean their surroundings from the ice created from the past snowy days in Nürnberg, I had to stay some days at home (medical order) due to a very ugly fall that made my left arm useless (except for some typing), which gave me the quiet opportunity to study/read that code and figure out a solution.

I tried tons of different things. Even using curl command line from the aria backend only to check file existence, but at the end the problems I encountered (and figuring out some missing features from aria2c) pushed me in the direction of making the aria2c backend a particular case of the curl backend, and therefore I could reuse features from curl, without worrying about reentrant access to media attach points or other stuff. This reduced the code of the aria2c backend considerably. MediaCurl is now much smaller (about 200 lines of duplicated code removed), so we can add range support (I will explain this in a future post) to the API.

On the way to this refactoring, the following features/options (zypp.conf) got implemented:

##
## Maximum number of concurrent connections to use per transfer
## This setting is only used if more than one is possible
## Setting it to a reasonable number avoids flooding servers
##
# download.max_concurrent_connections = 2

The option above only works with the aria2c backend. Not with pure curl.

##
## Sets the minimum download speed (bytes per second)
## until the connection is dropped
## This can be useful to prevent security attacks on hosts by
## providing updates at very low speeds.
##
## 0 means no limit
##
# download.min_download_speed = 0

The option above can be used to prevent a (very theoretical) attack described in this report, where the bad guys will send data very slowly to the client to keep it unpatched. This option should work with both aria2c and curl backends.

Also, we implemented the following options for those people sharing a connection or needing to limit the connection usage somehow:

## Maximum download speed (bytes per second)
## 0 means no limit
# download.max_download_speed = 0

Also, the following option is useful for people doing the dist-upgrade unattended, so they can set it to try hard, or just to keep trying without interaction:

## Number of tries per download which will be
## done without user interaction
## 0 means no limit (use with caution)
# download.max_silent_tries = 5

These features are in libzypp 6.1.0, Factory has 5.11.0 right now. I plan to submit to Factory in the following days (after basic testing). Once aria2c is the default, it can be disabled using ZYPP_ARIA2C=0 which will give you the basic curl back.

Of course, this may result in new bugs or problems. So be prepared!

The last weeks I heard twice about the idea of having something like debconf to configure package default settings. Now I just notices a blog post from Lars about it.

When such ideas appear, I always pay attention, because there we may miss some points:

• Look out of the box. We end with our own custom way to do things, sometimes really coupled with YaST (which is very different to integrated with YaST).
• No research is done about existing solutions, their mistakes and advantages.
• One weakness is not enough to invent something new. People forget the missing feature fast. Compatibility brings more value than one missing feature: You gain tools and existing knowledge. ** For example, we switched to the updateinfo.xml format, which does not support dependencies. People complained, but till now nobody has missed them. However the value is that you can use tools like Bodhi with openSUSE.
• You can still innovate, and add value, by integrating it with your already valuable stuff.

So lets put this feature in perspective. The main use case (extracted from Lars post is):

• Allow the package to define settings
• Ask for those settings at installation (or later).

There is even a “mockup” or how it could look like in a new xml format.

Lets look at debconf, just an overview, to see what it does:

• It supports questions with the following types: string boolean select multiselect note text password
• The myth that it break non-interactive install is not completely true. There is a noninteractive “frontend”.
• It has frontends for command line, KDE, Gnome, and a ncurses/dialog like.
• Packages provide templates, like:

Template: foo/like_debian
Type: boolean
Description: Do you like Debian?
 We'd like to know if you like the Debian GNU/Linux system.

Template: foo/why_debian_is_great
Type: note
Description: Poor misguided one. Why are you installing this package?
 Debian is great. As you continue using Debian, we hope you will
 discover the error in your ways.

• Packages provide scripts. Script get a minimal and simple API to get the values of the answered templates, and apply them. So you can write them in sh and perl (and may be others).

#!/bin/sh -e

# Source debconf library.
. /usr/share/debconf/confmodule

# Do you like debian?
db_input medium foo/like_debian || true
db_go

# Check their answer.
db_get foo/like_debian
if [ "$RET" = "false" ]; then
    # Poor misguided one..
    db_input high foo/why_debian_is_great || true
    db_go
fi

• There is even the concept of “shared settings”:

Template: shared/window-manager
Type: select
Choices: ${choices}
Description: Select the default window manager.
 Select the window manager that will be started by default when X
 starts.

So, the question is, if till now nobody has additional requirements, why invent a new xml format, or force people to code wizards in ycp?

• Why not use exactly the SAME template format. Hey packager! You can copy the templates from Debian, just as you copy patches from Gentoo today
• Why not add the glue with YaST in the script part (so the scripts would be sh, perl or ycp with a MINIMAL api)

If the template format is the same, we could also expect Fedora people could also start using it (of course we haven’t yet talked to them, and then we ask ourselves why every distribution has its own

If the scripts are integrated with YaST, other distributions can implement them in a different way, but with the same minimal API.

Also, hiding the whole YaST infrastructure keeps the concept simple and prevent packagers to start doing evil stuff from these scripts, and even better: the templates are not programs, or ycp maps, but documentation/knowledge which happens to be read from YasT code.

You may have noticed (or not?) that svn.opensuse.org/svn/zypp is now read-only

Since a couple of weeks the ZYpp project repository is now hosted on git.opensuse.org. Please read the official announcement here.

Now you can fork and develop much easily without needing access to the “official repository”. Developers can work disconnected, enjoy the git features to handle merges and branches, oh, and you can keep your forks in git publishing sites like the cool GitHub

We updated the following pages to reflect the move:

• ZYpp Development page
• sat-solver homepage

Those also link to the new pages, written as a starting point:

• General git information and useful links
• git hosting (including git.opensuse.org) information

One of the challenges of the migration was continuous integration. We needed to replicate the automated building/testing process, which is a core part of the ZYpp team development model.

The process has been migrated from cruisecontrol.rb to Hudson ( Extensible continuous integration engine, https://hudson.dev.java.net/) which provides better job handling support, plugins and it is not tied to svn.

Some new features:

• We now build zypper automatically over the rest of the ZYpp stack.
• We publish the last successful build that passes the testsuite automatically to zypp:Head project. This one will obsolete zypp:svn.
• We are working to build other pieces of the stack automatically, like PackageKit.
• We are working to also build and test the whole YaST stack, so it can also be published automatically. So expect a YaST:Head project soon too, to obsolete YaST:SVN (outdated).

I would like to thank R. Tyler for his help with Hudson plugins, Jens Daniel for his original automation scripts we used, which are still the base for the Hudson build scripts , Stano for adding on-request features to y2makeall, and the Hudson developers for such a amazing piece of software.

This experiment is an idea from Stano. When he saw us hacking and trying new approaches for the control center code base (in order to allow a different design) he sent me this ycp snippet.

{
  import "Mode";
  Mode::SetMode( "autoinst_config");

  string m = (string) WFM::Args(0);
  string p = (string) WFM::Args(1);

  y2milestone( "Writing the result of '%1' to '%2'", m, p);
  any a = WFM::call( m, ["Read"] );

  any res = WFM::call( m, ["Summary"] );
  y2milestone( "%1", res);

  SCR::Write( .target.string, p, res);
}

This snippet would called with two parameters, A and B, would run a ycp client in “auto” mode and write a summary of the configuration in file B.

This would allow in the control panel to display “status” information about the modules before launching them.

To test the concept, I hacked a quick YModuleInfoProvider class that hooked into the Qt::Tooltip role of the YQModulesModel. I filled the implementation of this class with a hacky call to yast2, calling the ycp snippet and reading back the temporal file.

Ideally, the status should be shown in the icon itself or in a “Dolphin” like status bar. However, I just wanted to see it, so I put them in tooltips for now (Not that I want to keep them there).

And yes!, it works, you can see the status of some modules just h-overing them with your mouse:

I would like to replace the implementation of YModuleInfoProvider with code using the YaST2 component API instead of an external call, just to see if it is cleaner, faster and whether we have more control. Stano helped me making this snippet work:

using namespace std;

int main()
{
    Y2Component *c = Y2ComponentBroker::createServer("wfm");

    if ( ! c )
    { cout << "error talking to wfm" << endl; return 1; }
    
    Y2Component *mode = Y2ComponentBroker::getNamespaceComponent("Mode");

    if ( ! mode )
    { cout << "error finding component" << endl; return 1; }

    Y2Namespace *ns = mode->import("Mode");

    if ( ! ns )
    { cout << "error importing Mode namespace" << endl; return 1; }

    Y2Function* fnc = ns->createFunctionCall("SetMode", Type::fromSignature("void(string)") );

    if ( ! fnc )
    { cout << "error calling SetMode" << endl; return 1; }

    fnc->appendParameter( YCPString( "autoinst_config" ) );    
    fnc->finishParameters();    
    fnc->evaluateCall();
    
    cout << "Done call!" << endl;
    fnc = ns->createFunctionCall("mode", Type::fromSignature("string(void)") );
    if ( ! fnc )
    { cout << "error calling mode" << endl; return 1; }

    YCPValue res = fnc->evaluateCall();    
    cout << res->toString() << endl;
    
    return 0;
}

However, for this to work, it requires a small bug to be fixed in core. So I guess I will replace the implementations once this patch is in.

Comments

After posting A refactoring journey: the control center yesterday, I got some comments quickly.

Of course I got some comments like “The category icons are too small” “Spacing is wrong”. When it was clearly stated at the end of the post:

Note that none of these screenshots mean “this is how the control center will look”. The focus is still on the infrastructure that enables us to try more radical approaches. For example, the old control center look and feel is trivial to emulate.

However, there was another series of comments:

Why don’t you add the yast options into the KDE settings?

I think the answer to this question is the same as the inverse. Why should we?

ls /usr/share/applications/YaST2/  | wc -l
85

There are 85 modules in my system. Well, not all visible. I don’t have all available installed either. But, would you like to have suddenly 85 icons in this view?

What do others do?

Now, Marçal Juan comment:

Just think in Apple and Microsoft approach… it’s all in the “System settings” not two independent apps.

This is simply not the case. I wonder why Marçal thinks they are mixed.

I think there is a simple reason why they are separate. If you had to put so many items, the control center can’t be read by our brain in one shot anymore . “but lets create sub-items”"… yeah, and then you are again back in the kcontrol tree times, where finding something was hard if you don’t know at which deep-level it was. Yeah, our readers/commenters solve any usability problem by making things a tree or adding tabs .

Actually, Apple has a System Preferences panel:

For server related settings, they have a separate console (Still note how User accounts is present on both):

Not only Apple. Marçal is also wrong with Microsoft, which has a control panel:

And also a server console (this time with a completely different look:

Why?

I think the temptation to merge them comes from two sources:

• The fact that most Linux user tend to mix the server/advanced administration and basic tasks a lot, and therefore they think their usecase is the common one.

• This makes them think that everyones wants to go trough the basic settings when configuring some advanced service.

• Actually the last YaST survey revealed that the only tasks an user does often is software management and in second place, network management. All the rest is done seldom.

• The fact that Linux lacks some basic administration tools upstream or integrated in the desktop, which YaST provides right now.

I think the last two ponts are relevant. The real problem is not whether you have all icons in one control panel, but where are those icons. Is software management a basic task or it goes together with virtualization settings? That is the problem. Windows and Apple provide software management and network management in the basic settings. However, I think this is only a problem for those specific YaST modules that are used to often, and both cases have a solution.

In the case of Software Management, PackageKit already offers basic software management integrated with the desktop. I do have an icon “Add/remove software” in my KDE System Settings (KPackageKit provides it). The case of networking is also solved since long time, and most desktop users configure their network in the system tray with knetworkmanager.

Any other configuration that becomes common for a desktop user has to be integrated with the desktop in the basic settings, or even further, in the right context (for example, enabling sharing a folder by right clicking the folder instead of going to the system settings ).

Right now we have some technical limitations. We can’t just put the YaST modules in system settings without doing some changes in that code, and we can’t offer all functionality so it can be integrated in the right context. But we are moving into that direction, and that really does not means we have to go and put 80 new icons and ruin the KDE4 control center concept or reintroduce hard to remember categories.

We will do some experiments about it anyway.

Update 1: As Stano points out, it may make sense to offer access to YaST in the “Computer Administration” category of the System Settings, not module per module, but as one icon. (then launch YaST control center, or embed it). What we can’t do is to embed the modules themselves in the system settings (we did this in the past and was problematic as modules have wizard semantics).

It is almost Christmas and things are getting more quiet and there is now some time to look at pending TODOs. I mean all those things that did not make into 11.1 because priorities.

The problem

The Qt control center is an ancient piece of code, and it still is a Qt 3.x application.

You may know how it looks:

We already have a feature for a reorganization of the control center. Thomas Göttlicher, Jens Daniel Schmidt, Jörg Kress and Martin Schmidkunz worked last year on proposals. I want to leave look and feel out of this post for now. (When it comes to which color to use to paint the walls, everyone has an opinion). I wanted to focus on:

• The fact that it still is a Qt 3.x application
• The code is not easy to port to Qt 4.x, even more difficult to change the look and feel (which would help for the feature mentioned above )

The main reason of why the code became so inflexible is the mixing of presentation with data items everywhere. Yes, not only the control center suffers from this problem but also the Qt package selector.

Qt 4.x has, among a lot of unmatched features, the ability to use a Model/View paradigm. This means, you describe a model, and then you just plug it into a view, and it will be displayed according to the widget’s context, instead of sub classing widgets just to hold data on the user interface.

I have to admit that it is not the first time I look into Qt’s Model/View, but in order to understand it, one needs to dig in some real life problem because it has some concepts like indexes, views, delegates, etc, which start to make sense once one adapts it to the specific problem.

So, my challenge was to add a model architecture to the control center in order to make then trivial to let other people choose the wall color and also enable other innovations. For example Stano hacked a ycp script to retrieve summary information from the configuration (I can’t wait to integrate that).

Step 0. Find out where are we.

Thomas Göttlicher already did some research on using the KDE4 system-settings style views. This shown that some widgets could be reused (like KCategorizedView), but also showed that pieces like the SystemSettingsModel are too complex for what we need.

Step 1. Compile old control center on Qt 4.x

I took the old control center, branched it and started the boring work to getting it to compile with Qt 4.x. This involved setting cmake up as I did not wanted to waste time figuring how to convert an autotools project to Qt 4.x.

In this stage one sees much design decisions that either help or hurt when porting. Also opportunities, for example the control center had its own .ini file parser, which I replaced with the QSettings class. Note, QSettings is there since Qt 3.3.

At the same time I got it compiling in Qt 4.x, I extracted some of the module listing code to an QAbstractItemModel and created a small test program for it that I could run in parallel.

My model could be plugged into a view and display the groups, with one line of code:

After getting familiar with the code, and learning it, I decided it was almost impossible to plug my model in the current code. Why did I tried then? Because reading code is always harder than writing it, therefore there is always a tendency to rewrite from scratch, and I wanted to be really sure it was not the “reading code effect”.

Step 2: start with a cleaner base

I took Thomas codebase and compiled it. I realized it was easier. I only needed to get rid of the systemsettings code. I only needed the KCategorizedView part, or even a plain QListView if I had the right model.

Once the code was removed, I needed a modules model (analog to the groups model). After writting some code, I felt like I was writing the same thing again: a model that lists what it is in .desktop files. Closed both models and focused on a DesktopFilesModel as a base. Once this was done, the groups and modules model was a few lines of code (mainly setting the right configure time YaST paths). So I had a modules model too:

Step 3: KCategorizedView

This component worked out of the box when I plugged my model:

Except that it only displayed a hardcoded category. One needs to enhance the model to reply to the CategoryDisplayRole, which required to start thinking better about the structure of the models and add utility methods to query groups for modules given an index and similar methods.

At the same time once you see it on the screen you get a feeling when the view is querying the model (speed and debug lines), which resulted in a basic cache infrastructure for the base .desktop files model.

The result:

Step 4: Profit from the new structure

At this point I realized there were too many items on the screen, but also I realized how trivial was to add a docking at the right with the group list, or how trivial it would be to set the proxy model to filter certain groups. Just for playing, I added a search bar:

and then a groups list dock (which you can move around the main window):

.

Now what?

Note that none of these screenshots mean “this is how the control center will look”. The focus is still on the infrastructure that enables us to try more radical approaches. For example, the old control center look and feel is trivial to emulate.

Will it be the old? the new? configurable? We don’t know yet. There is still work to do before we focus on the look and feel.

Morning

Did not start the day in a good way. I buy mobicards every month so I have full access to the public transport system. I buy them via the internet, so I get an email when it is about to run out, and with one click I get the form to order another one by mail (even with the date range pre filled).

Today I took the straßenbahn (tram), and suddenly the guy next to me transformed itself in 1 second from a civilian to a public transport control employee, and asked me for my ticket. I took my mobicard from my pocket and showed it to him. He nods but after a second he comes back and ask “let me see it again”. He looks again and points out it starts on 12.11 and today was 11.11. No problem, last month one is behind that one (the whole year cards are there). He looks the old one and points out “This one ends at 10.11″. I could not believe it, I did not even realize. Usually I just click OK-OK when buying them. I got a ticket. Luckily the checkbox marked was not “pay 40€” but “Go to the headquarters to clarify” (which still means they could fine me). Of course that means wasting half a morning not counting the time I lost already over the tram (not being able to get out in the right station). If I get fined after buying mobicards every month for years it would be really ironic.

ZYpp

In the office we had the typical “first media” blocker. Luckily Michael found the bug really quickly. Later I wanted to test the fix using linuxrc magic driverupdate tricks I have learned in the past weeks. However it did not work: Linuxrc can use rpms as a container format, but still expects the driverupdate directory structure. Bah, world was not that cool as I thought. Met with Michael and Steffen about it. Steffen realized that it would not be a bad idea to try the rpm first as a driverupdate, and if no driverupdate is there just unpack it in the system (and promised to implement it) That sounds good, easy testing. Happy.

YaST

autoYaST

Katarina wrote a really nice tutorial that explains how use autoYaST to apply a configuration to a running system. Uhm. Looks like an XML API. Wow. Couldn’t we use it for our YaST web service?. Talked with schubi about it. While the command line interface has higher level, exposing this interface would make sense too, because it will offer automatically almost all autoYaST power.

Partitioner

The new YaST partitioner, on which Katarina, Arvin, Matthias and Martin worked really hard during the Code11 cycle got a pretty nice review here. Give it a look. And give the guys feedback. I am sure lots of things can still be improved!.

YaST releases

Stano is reviving the discussion about whether to make independent of openSUSE YaST releases. I talked about this topic with Zonker just after he started as community manager.

I think it would be a pretty good move. Also a big challenge. It would mean a challenge not only for us the YaST teams but also for other internal and external stakeholders.

Right now a new YaST package submission (same with libzypp) is more or less tied with the development of features or some project manager sitting next to your chair to get a blocker fixed for an openSUSE release. Things would change if the distribution’s team would need to take the last released YaST and take patches, forward ports, backports, etc.

Also it would be a challenge for us. Most of YaST testing happens on a openSUSE release. We have lot of ideas on how to improve our automated testing and this would require develop them further. Also I think an approach like this would facilitate making YaST less distro-dependent.

Another point I like of the approach is that it would force us to have a better process to define our core-platform (ir order to be able to release it separately). Right now I see it a bit chaotic: APIs are born in modules, and as soon as they are used by more than one module, they land in the wildcard yast2 package. Something I really don’t find very convenient. APIs should be reviewed with more care and packaged by the area the API covers.

Still and interesting topic and material to innovate!

Background

My colleagues use awesome tricks to do nfs boots with custom inst-sys and other magical procedures in order to test a modified installation. I find those tricks cool but that I tend to forget them after a few days.

During 11.0 release cycle, Coolo had to test the new installation theming. He explained me his method, using update disks.

Update disks exist since longs time. AFAIK they were originally designed for drivers, but today they can insert almost any kind of file to the instsys. That was what coolo did: had his own tree, with an updated installation css theme, packed it, and then run qemu, passing the updatedisk url (which he served from his own machine) IIRC he passed an iso as a cdrom to qemu.

I find this method pretty cool. But I still had the feeling it could be automated more:

• qemu supports booting directly from a kernel and initrd, so I could use the http repositories and download those instead of needing a iso.
• I could append kernel parameters telling qemu about them
• I could automatically repack my local directory with updated files and avoid running mkcramfs by hand (latter Steffen told me I could even use cpio)
• Why bothering with apache in my machine? As qemu can’t access the driverdisk image from my local disk, I could start a embedded web server on demand and tell linuxrc about it.

So after lot of questions to Steffen and some code reading of Ludwig awesome “setupgrubfornfsinstall”, here is the first version that works:

git clone git://git.opensuse.org/people/dmacvicar/startinstall.git

Usage

The structure of the driver update disk is something like this:

./linux/suse/i386-11.0/dud.config
./linux/suse/i386-11.0/inst-sys
./linux/suse/i386-11.0/inst-sys/usr
./linux/suse/i386-11.0/inst-sys/usr/share
./linux/suse/i386-11.0/inst-sys/usr/share/YaST2
./linux/suse/i386-11.0/inst-sys/usr/share/YaST2/theme
./linux/suse/i386-11.0/inst-sys/usr/share/YaST2/theme/openSUSE
./linux/suse/i386-11.0/inst-sys/usr/share/YaST2/theme/openSUSE/wizard
./linux/suse/i386-11.0/inst-sys/usr/share/YaST2/theme/openSUSE/wizard/logo.png
./linux/suse/i386-11.0/inst-sys/usr/share/YaST2/theme/openSUSE/wizard/installation.qss

In this case, I only want to replace the logo and css file. The important part is the directory with the architecture and version. dud.config has:

UpdateName:     openSUSE 11.0 DUD
UpdateID:       193a399fca4b4da9
UpdatePriority: 100

Which I guess are random values for our specific case This directory tree is available at /foo/driverupdate on my machine.

Now you need a http or ftp repository (I will add more features later…). In the example, it will be http://distros.foo.com/openSUSE-11.0-RC4-DVD/i386/DVD1

Now just run it:

ruby startinstall.rb --tree /foo/driverupdate http://distros.foo.com/openSUSE-11.0-RC4-DVD/i386/DVD1

startinstall.rb will download the kernel, initrd, pack the driverdisk, start a (webbrick based) webserver offering this driverdisk and launch qemu with the right parameters:

qemu -kernel /tmp/kernel20081030-5149-1yn5upf-0
 -initrd /tmp/initrd20081030-5149-uquvmh-0
 -append 
   "install=http://distros.foo.com/openSUSE-11.0-RC4-DVD/i386/DVD1
    driverupdate=http://mymachine.suse.de:9999/updatedisk20081030-5149-ogaqpl-0 "
 -hda /dev/zero
 -no-reboot
 -net nic,macaddr=00:BE:C3:B9:4C:BD,model=pcnet
 -m 666
 -net user
 -usb -usbdevice tablet

After booting, you will see your modified (see the logo) installation:

I will keep a small page for this tool here.