Home Home > 2009 > 01 > 08
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 8th, 2009

RPMLINT Wiki Side overworked

January 8th, 2009 by

I’m an new Packager in OpenSUSE BuildService, and i like this work. But if i would like to package for Factory, RPMLINT gives me any Errors or warnings. But these things to fix, are very difficult. Our Wiki Side for RPMLINT doesn’t contain many Error or Warningcodes.

But yesterday i’ve found an Side, with other Errorcodes from RPMLINT. Today i imported these Codes to our Wikiside http://en.opensuse.org/Packaging/RpmLint. I think it is not possible to list all codes on the Side. But i wish, that the side includes more Codes in the future.

No i would like to make an Call for contribution. If every Packager insert the codes, that he knows, we have an good library soon.

And on this Moment i would like to make an request about helping- Thank you all for the hard Work.

Kernel Of The Day Build Service Projects

January 8th, 2009 by

People interested in openSUSE and kernel development probably know about the existence of the Kernel Of The Day (KOTD). This is the latest and greatest code from the internal kernel source repository that is build once a day and synced out to ftp.suse.com. The intention of the KOTD is to ease the testing and running of development snapshots that likely become the next maintenance update.

Some people might have noticed the Kernel: projects that produce a quite heavy load on the build farm. These are KOTD projects that are mirrored to the openSUSE Build Service every night around 4pm CET if there are changes in the internal source repositories.

Currently the following KOTD projects exist:

Additionally there are two projects that are related to upstream kernel development:

  • Kernel:Vanilla includes the latest sources from Linus Torvalds’ linux-2.6 GIT tree
  • Kernel:linux-next includes the latest sources from Stephen Rothwell’s linux-next GIT tree

With the help of the openSUSE Build Service running the KOTD became even more convenient since the project repository can be added to zypper. Besides that it is now very easy to build external kernel modules (KMP) matching the KOTD.

Integration of YaST Server Modules to YaST System Services

January 8th, 2009 by

Today, I’ve played a bit with an idea to allow starting of YaST Server module from the YaST System Services module.

YaST System Services (Runlevel) Editor

The only visible difference is the additional “Configure…’ button at the bottom of the dialog. This button would be active only if there is a YaST module associated with the entry. After clicking it, the respective YaST module would be started:

YaST Firewall module invoked from YaST System Services module

With this simple principle, the YaST control center ‘Network Services’ section would be reduced to:

YaST Control Center, Network Services section

And all those YaST modules would be available from ‘System’ section:

YaST Control Center, System section

This approach could be used even further. You can see that the ‘Network Services’ section contents do not really match the section name anymore. In fact, most of the items could be moved to other modules as well. E.g. introducing a module for authentication/authorization, which would cover Kerberos client, LDAP client, etc. The NFS client is in fact a part of the new Disk Partitioning module already. So, the section could vaporize completely.

However, there are drawbacks. The biggest one I see is a ‘starting point’ problem. Just imagine you want to have a Apache2 running in your system. Until now, the YaST HTTP module is installed and can be used to bootstrap your configuration – it will install the packages and help to set up the basics. But with the new approach, the apache2 package is not installed, therefore System Services module would not see the apache2 service (init script) and does not show it at all! I’m not sure how to address this. Maybe the best would be to attach the YaST  module to apache2 package or HTTP server pattern and the Software Management module would become such starting point. Would it be better? I don’t know.

Then, there is an issue of a quick access – if you are moderately experienced user, you know what you are looking for and you start a proper module right away. But to figure out what is the configuration starting point if it’s hidden in another module, that might be a blocker.

I’m sure there are more problems. Anyway, I find the idea quite useful for reducing the number of YaST modules. What do you think?