Home Home
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Jan-Christoph Bornschlegel

Some facts: - Born in Lichtenfels / Germany in 1976. - First own computer was Amiga 500 (somewhat around 1989 or so, but only if we don't count the Z80 based SEGA) - First "programming language" was "AMOS" - First _serious_ programming language was C I studied Electrical Engineering at Fachhochschule München.

Author Archive

Product Creation with the openSUSE Build Service

February 11th, 2009 by


First of all, what is a “Product”? The openSUSE Wiki has the following statement on the Product Definition Article:

“A product is a defined set of packages plus extra information”

In the most simple interpretation this means a set of RPM files plus a set of metadata which contains the installation kernel, information about the installation work flow, hardware detection, languages, licenses, slide shows and the like.

Thus the most simple product imaginable is a basic set of RPM files for the system to be installed and a minimum set of metadata: an installation system consisting of kernel, initrd and the packages necessary for installation.


Funny Output For Some

September 3rd, 2008 by

Last week (aka Hackweek 3) I worked on a Linux From Scratch system.

A colleague dropped by and asked me what kind of power supply were sufficient for a certain machine. I thought “ok, let’s just ask lshal|grep battery
My hope was that the hardware would not only measure the voltage of the battery but also the current drained from it.

What I found was kinda funny from an Electrical Engineer’s point of view:

lshal output for laptop battery

So what? “voltage.current”? Voltage? Or current? Or multiplied?

After laughing a bit I thought seriously about bug report, but it isn’t a bug apparently.
I find those things funny, can’t help it. I therefore consider this an Easter Egg of HAL.

Still, if anyone knows if a laptop can tell me the current current (SCNR), let me know.


Installation Source creation status

June 6th, 2008 by

There is some work going on to put installation source creation functionality into kiwi.
At the moment kiwi can use prepared installation sources such as:

  • BuildService Repositories
  • mounted DVDs
  • FTP trees

But what if you have a local Build Service building some binary only packages and you wish tp make a installable media set from, say, “SLES + binary only drivers”?
You can use the inter-BS-Connectivity feature to only build the drivers (and not the whole distribution) in your BS and then create an installation source from your main BS project.

This is possible since release of the package kiwi-instsource which extends the functionality of the config.xmlfile to allow the compilation of an installation source from scratch.
Hereby “scratch” means directories containing .rpm and .spm files. Of course some information must be provided for the metadata creation — but this is also all in the config file (with one known exception — the PDB data).

The rest is figuring out which packages must be on the installation source.
Since it is perfectly ok to have conflicting packages in instsources, there is no dependency check or package resolving in this stage. The information must come from the user.

Therefore the package list may become rather long and I already plan to implement some simplification.
These plans include:

  • allowing more than one <repopackages> section
  • implement outsourcing blocks in separate files using XML functionality