Home Home > 2009 > 01
Sign up | Login

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

Archive for January, 2009

Writing wrapper packages for server applications or a generic YaST module?

January 27th, 2009 by

As we get more and more PHP-, Perl- and other applications like openSIS, Koha, Moodle, … in the Education repository, the question turns up, how to package those applications “the right way”.

A normal user, who wants to use one of these apps, might just choose to install the package and has the problem how to proceed afterwards. openSUSE sadly has no “post config” scripts like Debian based distributions – even the SuSEconfig scripts are deprecated. So all a packager can currently do is:

  1. write a README.SuSE (which is already the case for many packages) and place it in /usr/share/doc/packages/<packagename>/README.SuSE explaning how to proceed
  2. sugget what the user always wants to do and do it via %post-script after the installation of the RPM
  3. combine 1&2 and point the user to a script in the README.SuSE 🙂
  4. write a YaST module which can be started during installation or afterwards
  5. any other option I missed (please inform me!)

For the Education project, I’m currently thinking about two ways to make the life of the admins easier.

First: think about “wrapper packages” around the normal packages. I’ll take moodle as example. The normal moodle package installs the php-scripts, an apache configuration and some other config stuff – but will not setup the complete moodle instance. So the user has to install the mysql database himself. An additional wrapper package can do this for him. This package comes with a SQL-Dump of the current moodle version (therefore requires the exact moodle version), and uses a stored mysql-root password to create a new database and insert the database-dump. If needed (for example: the user enables the “user LDAP-Auth wherever possible” checkbox in a (to be written) yast-edu module), additional tasks can be triggered by the wrapper package.

We can also think about calling a “generic” YaST module after installation of such a “needs postconfiguring” package. If we define a place (say: /var/adm/YaST/postinstall/) where packages can place a file containing some important questions to configure the application, and someone writes a YaST module which can be started, this would perhaps be “very cool”. If the user has entered his values, the YaST module can start one or more scripts (coming with the package) and feeds it with the entered values. The biggest questions for this solution:

  1. When should this YaST module be started? IMO it could be enough to let the user start it manually and select the package he wants to configure. => No adaptions of the current workflows is needed. But perhaps there are other options (like calling it via “SuSEconfig”)?
  2. Who can write such a module?
  3. Who defines the config syntax?

Think about a file like this:

<package name=”moodle”>
<questionpack type=”string” action=”/usr/share/moodle/scripts/install_database”>
<question arg=”1″ type=”string”>What’s the database password?</question>
<question arg=”2″ type=”string”>What should be the name of the new database (suggest: moodle)?</question>
<question arg=”3″ type=”string”>What’s the username of the new database user?</question>
<question arg=”4″ type=”string”>What’s the password of the new database user?</question>

<questionpack action=”/use/share/moodle/scripts/configure_auth_backend” type=”selectbox”>
<question arg=”1″>What auth-backend should be used?</question>
<answer value=”1″>ldap</answer>
<answer value=”2″>mail</answer>
<answer value=”3″>passwd</answer>

I think, there’s room for many enhancements in this area – what do you think ?

Should/Could we produce something like a “Windows-Installer” for openSUSE? Or is it enough to provide special “wrapper packages”? Or is “what was hard to write, should be hard to install” still a valid answer?

Build maemo-apps with openSUSE BuildService ? – It works !

January 27th, 2009 by

build serviceThe openSUSE Build Service is an open and complete distribution development platform. It’s the infrastructure for a development of the openSUSE distributions. But this powerful tool can do much more! The upcoming version 1.5 will also have cross-build support and thus be able to build e.g. ARM packages on x86 hardware .

maemo.org loko Maemo is the platform for mobile devices like the N810 and has been developed by Nokia in collaboration with many open source projects such as the Linux kernel, GNOME and many more. (more…)

Tabbed Browsing for Packages – Follow-up

January 27th, 2009 by

In last Friday’s blog entry about tabbed browsing for packages, I had asked for comments and opinions. There were quite a number of them, all of them very constructive. Thanks to all who participated!

The overall feedback was positive, welcoming the change. To us, this means that we will indeed merge that code branch (yes, it’s largely working already, it’s not just a mock-up) to the main development line, and you will see that new user interface appear in the next versions of the yast2-qt-pkg package on FACTORY.

There were a number of concerns and side issues that I’d like to summarize here:

100 packages in Contrib

January 26th, 2009 by

Last month we started a new project called Contrib. It’s a shiny new community repository for openSUSE. In opposite of specialized repository (eg. Security:), Contrib is universal. It doesn’t matters if your package is a desktop application, or a network tool. Every type of package is welcome.

Today, we celebrated a package number 100 (gparted)! Thanks to all involved folks!

One hundred packages doesn’t look like a big repository, but consider we are active about a month and half and this is an important milestone for us. The bigger repository should be more attractive for end users, and a package maintainers too.

Users wanted
Contrib release cycle is same as Factory, but we want to help users to use it now. So Contrib is also available for 11.1. So just add the repository and start to use it! It help us!

zypper ar http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib/openSUSE_11.1/ openSUSE_Factory_Contrib

Package/rs wanted
If you maintain some interesting package in your home: project (or elsewhere), please follow instructions – New packages to Contrib and add your package to Contrib, so many users of openSUSE would use it!

Automatic Import Calendar news.opensuse.org > KOrganizer

January 24th, 2009 by

I’m very happy. Regularly i’m checkin the Calendar from news.opensuse.org for my work in OpenSUSE Weekly News. It is possible to Download the actual Calendar as *.ics File. But as i understand this, this is a Snapshot. The Calendar not updated himself regularly. So i tried this:

First of all we go to the KOrganizer. Click on the green Cross, left from the Calendararea. Add Calendar. Then we find an Menu similar this:

List of Resources

Then we klicking on “Filecalendar from Remote Computer” (I had translated this on the fly, i’m not shure, that it called so in english). After them we see the next Field:


In this Field i edited :”http://news.opensuse.org/?ec3_ical”. I choosed regularly updating, but no Saving on the Remote Computer.

Now we have the Community Entrys in our Calendar. We see:


If i have understood all right, we have an automatic Calendar. Have fun…

Tabbed Browsing for Packages

January 23rd, 2009 by

There are many approaches to managing software packages. Some users like to use command line tools like zypper. Others prefer a GUI tool like the YaST2 package selector. And even within such a GUI tool, there are many ways to deal with the packages you’d like to install, update or remove: Install a bunch of packages that make up a functionality like “KDE desktop” or “web development”, find one specific package with a known name, or just look through packages that are available. That’s why there are different filter views for those different approaches.

How do you select any of those filter views? In previous versions of the (Qt) package selector, we used to have a combo box to do that:

That’s somewhat unusual, and there have always been critics who claimed that we should use tabs instead. Our standard reply was always that this would not really be helpful because there are so many of them; you’d run out of screen space quickly, and with the number of filter views we have, this would look overwhelming and confusing:

Ugh… not good. Not even at this screen resolution. Now think about 800×480 netbooks and more verbose languages like German, French or Hungarian. No way to make this fit on the screen. And left/right scroll buttons are the last thing you want for tabs.

So, what else could we do?

Smolt Popup

January 23rd, 2009 by

kupdateapplet shows a popup that asks the user to send his/her hardware profile to the smolt project.

I think kupdateapplet isn’t the appropriate application for showing this notification because smolt has nothing in common with update installation.
I’ve written a tiny python-qt script that shows the smolt popup.

You can find a package called smolt-qt in my build service home. Feel free to test and comment!

Novell Teaming on SLES

January 21st, 2009 by

As per the request of Andrew Wafaa, I thought I’d set up a quick guide to how I got teaming running on SLES.  The documentation for Teaming on the administrative end was relatively sparse, but the installation guide was sufficient for most purposes.

Read on to learn more about Teaming and SLES…


Controlling your minions with Ruby and Capistrano

January 21st, 2009 by

Welcome to yet another installment of our Ruby mini-series.  Capistrano (http://capify.org/) is a DSL written in Ruby for automating common tasks.  While Capistrano is more often used for Rails deployment, it can easily be used for system automation as well.

A while back, I put together a presentation for the local Ruby user’s group.  The presentation covers a very brief intro to Capistrano for simple system automation.  You can download it here.  I’m aware of at least one typo (a missing single quote) in the slides, there may be others.

Rather than repeat myself here, I’ll let the PDF do the talking.  For the official documentation, see http://capify.org/getting-started

Flashrom Utility for LINUX (part1)

January 21st, 2009 by

This blog entry is a little bit OffTopic. I’m writing not about an openSUSE Theme, but about
Linux. Last week i’ve chatted with the guys in #coreboot @ freenode and it was very
interesting. This article based on an collaborative PR Project from Carl-Daniel Hailfinger. This first Part of the Article presents Flashrom. The next Article presents Coreboot. The web site of that project is:


The flash utility is known as “Flashrom”.

Flashrom is a universal flash programming utility used to detect, read, erase, or write BIOS
chips (parallel, LPC, FWH and SPI technologies) in various packages (DIP, PLCC, SOIC).
It can be used to flash firmware images such as traditional BIOS or coreboot or to back up
the existing firmware.

Everybody who does not want to boot DOS or Windows just to perform a BIOS update can use
flashrom. It does not require a graphics card, monitor or keyboard and can even be used
over SSH on a remote machine. You do not have to reboot to run flashrom, but it is recommended
to reboot after a successful update. Many people are using flashrom as a replacement for
the various AMI/Award/Phoenix BIOS flashing tools out there.

Flashrom supports over 100 flash chips and it is really easy to add support for a new chip
if your board happens to have an unsupported chip.

Flashrom has its own home page: http://www.coreboot.org/Flashrom

It is free software released under the terms of the GNU General Public License version 2.

Flashrom is a “normal” user space application, but it requires superuser privileges.
Some hardened kernels (which deny access to physical memory) do not support flashrom, but
most distributions out there work fine.

Of course, the usual requirements for BIOS updates apply here as well. You should have a
stable power supply. Switching the machine off during flashing will make your machine
unbootable. Since flashrom treats BIOS files as opaque blobs, you usually do not get any
of the failover/dual BIOS features advertised on some boards.

Backup the current BIOS image into a file:

$ flashrom -r backup.bin

For other usage instructions, please refer to the flashrom home page or the man page.

In case something goes wrong, do NOT reboot, but join #coreboot @freenode and tell the
flashrom developers about it. As long as the machine is still running, there is a good
chance that everything can be fixed.