The gpodder project introduced its new major release 3.0.0 today and, unfortunately, it seems like I didn't pay attention to the complete change announcement, as I just bumped the gpodder package in Packman to 3.0.0 (from 2.18).

Now, gpodder 3.0.0 does introduce a lot of changes, notably in the UI but also regarding its database format and requires migrating the database from 2 to 3. It doesn't seem to have all of the features of 2.20 either. So what happens is that when you just upgrade the gpodder package, you end up with something you don't necessarily want to use. At least as of now.

Upstream will still maintain the 2.x branch for quite a while, and gradually port features from 2 to 3 and, hence, it actually makes sense to do it differently. What I have done now is to revert the gpodder package at Packman to the 2.xx branch (and upgrade to 2.20 at the same time).

If you want to use gpodder 3.0.0, then just install the package gpodder3 instead: zypper or YaST2 will tell you to remove gpodder in order to do so, as you cannot have both installed at the same time (they have file conflicts).

Now, if, in between those changes, you already did the upgrade, do one of the following:

• if you want to keep using 3.x: then run rpm -e gpodder && zypper install gpodder3 (as root)
• if you want to go back to 2.x: then run rpm -e gpodder && zypper install gpodder (as root)

On a side note, please wait a couple of hours (after this blog post) before doing so, as our main repository server is only synced to some mirrors after 4 hours (after 1 hour for most though).

Sorry for the inconvenience.

• My router IP is 192.168.11.1


• DHCP daemon is giving out IP address starting from 192.168.11.51 to 192.168.11.60. You can adjust this setting to provide more IP addresses. The important part is to assign IP addresses outside the range of any other existing DHCP server (either in the router or in another environment where you do not have access to the official DHCP server).


• server-name and next-server points to the IP address of the network installation server (ie pointing back to the openSUSE server that is running DHCP server, TFTP server, Apache2 server with binaries)

WebYaST 0.3 is out

“We have doubled the speed and have halved the memory usage”

The latest version of WebYaST has many improvements regarding speed, memory usage, usability and developing environment:

• Speed
  Due a new caching mechanism the startup time of each module has been decreased to a maximum of 1-2 seconds. So the user is able now to click through WebYaST without any notable waiting time.
  We have made a video which shows the speed improvement: WebYaST Comparison VideoFor more technical information have a look to: WebYaST Caching Howto
• Memory Usage
  Former versions of WebYaST were split into a service and into an UI part. Each part has run in a own HTTP server. We have decided to bring these parts together in order to save one HTTP server which halves the memory usage.
  One additional benefit is that the architecture of WebYaST has simplified a lot:
• Simplifying WebYaST architecture
  Due the use of one HTTP WebYaST server only the development environment has been simplified very much:
  1. Setup an environment system is much more easier now. Even a setup based on the GIT repository is quite easy.
     For more information have a look to : WebYaST Installation
  2. Writing an own WebYaST plugin has been reduced to a minimum effort. Everyone who has read a Ruby on Rails tutorial is now able to write a plugin.
     You do not believe ? Then have a look to the Example plugin .

How to get:

• All needed packages can be downloaded from OBS
• The source code can be found in Github

Available for…

.Sadly it is too late for 12.1 but you can install the packages from the repository described above for 11.4 and 12.1

The additional repository devel:languages:perl has quite a slew of Perl module packages in it (over 2000 at the time of writing).

Hence, if you are often using and requiring Perl modules, it makes a lot of sense to add it to your list of repositories, which you can do with the following command (as root):

zypper addrepo http://r.opensu.se/devel:languages:perl.repo

(if you wonder what r.opensu.se is, read up on it here: r.opensu.se).

A little known fact is that when building RPM packages, there is a post-build script that analyzes the files that are part of the resulting package in order to scan for Perl modules. For each of those Perl modules, it adds a Provides with the Perl name of that Perl module, with a specific notation which is like this: perl(Name::of::the::Perl::package).

As an example, if you need the Perl module Net::SMTP::SSL, you just need to do this:

zypper install 'perl(Net::SMTP::SSL)'

Note that you should indeed put that parameter to the zypper install command into quotes, as if you don't, bash will attempt to interpret the braces and give a syntax error.

Now, in this case, it is fairly simple, as the Perl module Net::SMTP::SSL is provided by the RPM package perl-Net-SMTP-SSL (at least on openSUSE/SLE), so you might have been able to derive the name of the RPM package from the name of the missing Perl module on your own. But that Perl module could very well be part of a package with a different name: for example, the Perl module Class::MOP is not in the RPM package perl-Class-MOP but in the RPM package perl-Moose (because it's part of the Moose CPAN module).

And a last little trick: if you only want to find out which RPM package(s) provides specific Perl modules, you may also use this:

zypper what-provides 'perl(Class::MOP)'

(Note that this one only works on repositories that you have in your list of active repositories, which you can see with zypper repos or zypper lr.)

There is a rather convenient way to mount ISO files (CD/DVD images) onto a directory on Linux, which goes as follows:
mount -o loop,ro /path/to/image.iso /path/to/mountpoint
(where the mountpoint is a directory).

This method works very well, but has one essential drawback: you must be root in order to do that. So how do I get to do so as a regular user ?

A barely known alternative lies in fuseiso, which uses the FUSE filesystem in user-space layer to accomplish that.

In order to use it, you must install the package fuseiso, which is available with the openSUSE distribution, and from the release repository (e.g. for 11.4) as well as from the filesystems repository and OBS project:
zypper install fuseiso

Once that has been done (as root ;)), you can simply mount ISO files like this, without being root:
fuseiso /path/to/image.iso /path/to/mountpoint

Note that as an additional benefit, fuseiso also supports images in NRG, BIN, MDF and IMG (dd) format, as well as zisofs.

In order to unmount, simply use fusermount -u, e.g. like this:
fusermount -u /path/to/mountpoint

Last week I updated the libvirt package for openSUSE12.1 RC1 / Factory to version 0.9.6. The package was also submitted for SLE11 SP2 Beta8. Changes since last update include backporting of AHCI controller patch for qemu driver. With this patch it is possible to use SATA drives with qemu instances. The following controller device XML is used to specify an AHCI controller

<controller type='sata' index='0'>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</controller

The libvirt qemu driver supports many AHCI controllers, each with one bus and 6 units. To attach a SATA disk to a unit on an AHCI controller, use the following disk device XML

<disk type='file' device='disk'>
  <driver name='qemu' type='raw'/>
  <source file='/var/lib/libvirt/images/test/disk0.raw'/>
  <target dev='sda' bus='sata'/>
  <address type='drive' controller='0' bus='0' unit='0'/>
</disk

Also new to this libvirt update is opt-in for Apparmor confinement of qemu instances. /etc/libvirt/qemu.conf has been patched to explicitly set the security driver to ‘none’. If Apparmor is enabled on the host, libvirtd is generously confined since it needs access to many utilities and libraries, but users must opt-in to also have qemu instances launched by libvirtd confined. Simply edit /etc/libvirt/qemu.conf and change security_driver to ‘apparmor’. Of course, selinux is also available if users prefer it over Apparmor.