Yeah the GNOME Team is already working hard on the 2.25.90 release. It will be a long day and we expect to end it with all the release done.
Vincent mentioned us (me, Magnus and Suman) but he is also doing an excelent working reviewing packages and upstreaming lot's of old patches.

After today (if everything went as expected) i'm going to make a SUSE Studio image so you can boot it as a livecd and VMware appliance. So you can test GNOME 2.25.90 on your desktop.

Come join us at #opensuse-gnome @ irc.freenode.net

PS: You can even get there and just say "Hi" or "How GNOME is cool!"

Spent the last days fixing Wine issues after a new Coverity run. Submitted ca 35 patches in a hack frenzy, but only 14 got in for now. But Wine is at 0 UNINSPECTED issues now!

GPhoto hacking wise not much work done.

Oh, and I bought a Nikon D90 (to upgrade the D70s) and a 50mm/1.8 lens (for better photos). Hopefully better photos will happen. :)


I will be on FOSDEM 2009 on the weekend, hold a talk on Wine and hang around the openSUSE booth. If you have cameras able to remote control drop by for debugging :)

Desktop files contain a lot of information about KDE/Gnome/X11 applications (e.g. names, icons).

Displaying this data in the package selector allows to provide a more detailed package description. The user can easily see which applications are included in an installed package.

Running these applications via mouse click is technically possible, but unfortunately security concerns don’t allow it. Please let me know if you have an idea how to solve this issue.

Today, I’d like to mention another rather hidden feature of openSUSE 11.1. The package management is finally able to keep multiple versions of packages, if they support installation of parallel versions. A typical example of this is of course kernel. A lot of people want to keep the old, functional, kernel around when installing a kernel update and now there is a way to do it.

Open /etc/zypp/zypp.conf in your favorite editor and change this value:

multiversion = kernel-default,kernel-default-extra,kernel-default-base,kernel-source

The list contains names of packages to be installed via ‘rpm -i’ instead of ‘rpm -U’. Just adopt it to your the kernel flavor you are using.

Of course, there is a catch – there are no means to limit the number of package versions to be installed this way. The reasoning is that there is no automatic way to guess which versions to remove (in case of kernel, everyone has its own definition of working kernel) So you have to uninstall additional kernels you don’t need anymore manually.

Enjoy!

Aim

First of all we want to provide an general web based interface with the
functionality which is already provided by the YaST command line interface.

This API is based on the REST (Representational state transfer) architecture. This is a
simple interface which transmits domain-specific data over HTTP.
Please have a look to

http://en.wikipedia.org/wiki/Representational_State_Transfer

for more information about REST.

The second aim is to provide a YaST Web UI which can be used by every
web browser.

The current state of the project is an existing YaST-Webservice on the
host side which provides the REST based interface.
On the client side we have the concerning YaST-Webclient which can be
used be any web browser.

YaST-Webservice and YaST-Webclient are running as a webserver
(currently lighttpd) on different or even the same computer.

So the aim is to configure a host via the internet in a simple and
safety way.

How does it work ?

The YaST Webclient communicate via HTTP(s) with the YaST Webservice. The
user has to authenticate ( username, password ) to the host via PAM
(Pluggable Authentication Modules) which is available on every linux system.

The YaST Webclient sends requests ( e.g. create a user, install patch) to
the YaST Webservice. This service checks if the user has the right to
execute this request via PolicyKit. For each kind of request there is
PolicyKit rule defined. These rights has to be granted to the concerning user.

After permission check the request will be send via DBUS to the SCR agent of
YaST. The return value will be given back to YaST-Webclient in XML or JSON
format.

Patches will be handled by PackageKit. These requests will also be sent from
the YaST Webservice to PackageKit via DBUS.

How to get it ?

Have a look the openSUSE buildservice project

YaST Webservice (home:schubi2)

There are all needed packages for version openSuSE 11.1 and above.

As some additional packages (e.g. lighttpd) are needed which are not on openSuSE 11.1 you should add a
repositories ( e.g. factory ) in order to provide these packages.
The simplest way for installation would be to use zypper:

zypper in yast2-core-2*.rpm
zypper in ruby-dbus-*.rpm
zypper in yast2-webservice-*.rpm
zypper in yast2-webclient-*.rpm

How to use the YaST-Webservice

After you have installed these packages you can start the YaST-Webservice-Server with

rcyastws start

The server is running as “localhost:8080” with which you can connect with a web browser:

http://localhost:8080

This “pure” web page shows the available modules which can be used via the REST interface.

This REST API is described under

http://localhost:8080/doc_interface.html

Additional configuration stuff like

– setup Hostname and Port
– setup HTTPS connection
– granting permissions for an single user
– AVAHI support

can be found here:
http://localhost:8080/doc_config.html

How to use the YaST-Webclient

After you have started the YaST-Webservice-Server you also can start the YaST-Webclient:

rcyastwc start

Now you can use any browser and connect with http://<name of your computer> to your
computer.
The default rights of the YaST Webservice are set to root only. So you can login with the root password
of that machine.

Following features are implemented:

– setting languages
– setting system time
– setting user permissions
– installing patches
– managing local users
– export user SSH-keys
– starting,stopping,status,… of services
– configuration of ntp server

Have a look to the following screen shot it order to give an overview how it looks like:

Known Bugs
-The first call of an menue entry will be slow cause an additional process will be started.
The second one should be much more faster
-Permissions will sometime not be shown correctly (just click “search” again) Bug 470645

Next Thursday 5th February openSUSE GNOME team will have a packaging day to celebrate the GNOME 2.25.90 release. It's a good oportunity to learn more about GNOME on openSUSE and to get involved with this awesome team.
Just join us at #opensuse-gnome @ irc.freenode.net and learn how to get involved with the GNOME team.

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>

<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>
</questionpack>
</package>

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?

The 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 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.

Today I succeeded in building a package of csync (the new file-sync tool) for maemo/diablo inside a local instance of the openSUSE Build Service using the cross-build and download-on-demand support. To make this happen, I imported the diablo/sdk repository from repository.maemo.org as download-on-demand target.

Then I had to write the project configuration (osc prjconf) and add some missing pieces.

In the end, I was able to build iniparser, samba and cmake as dependencies of csync. Last step was csync itself. The packages are available here …

Use: deb http://www.csync.org/maemo/diablo/n810 ./ as source for apt.

More information about the cross-build support can be found on this page and here on lizards.opensuse.org [1], [2] .
There will be a talk about cross-build and download-on-demand at FOSDEM 2009.

OBS rocks !

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:

1. We should not use tabs here because what goes on is not parallel. Well, this is an issue that could be debated for a long time. It’s not parallel in the same sense as multiple sessions in separate KDE konsole tabs. But it’s at least as parallel as different settings in settings dialogs in a zillion of applications: More or less unrelated stuff that would clutter the screen too much if displayed all at ounce, but that makes sense to be grouped together. In tabs. We do respect others seeing this differently, but weighing the pros and cons carefully we found that this rather abstract concern does not outweigh the benefit of migrating to tabs.
2. Missing keyboard shortcuts. Right: Each tab and each menu entry should have one. I added them to the code this afternoon.
3. Duplicate View menu, one in the main menu bar and on that new View button. That was an oversight; the label on that button was New in the first version, but that didn’t look too obvious to us, so we changed it to View, not realizing that we already had a View menu in the main menu bar. That menu in the main menu bar contained view options, so it is now renamed to Options and moved to the right. It’s not truly a traditional View menu anyway. It contains menu entries like Show -devel Packages and Show -debuginfo Packages.
4. Consuming screen space for the tabs. Right, this is a tradeoff.
5. Less surprise to first time users. That combo box was unusual, and some of you replied that they had to point first time openSUSE users to that combo box so they could switch views.
6. Don’t change for the sake of changing. No, we are not doing that. You’d be amazed how many times we had to defend our design. There were a number of attempts to radically dumb it down for the sake of newbies, but the voice of reason had always won. The world does not consist of newbies only. We also have to cater for expert or intermediate users. We came up with the simple Patterns dialog during installation for them, moving the full-fledged package selector one more mouse click away (with the Details button) for the experts. Each time we improve the usability of the package selector, there is one less arguments for dumbing it down. We believe that using tabs is a step towards that direction.
7. Nobody commented on the position of that View button. The majority of internal people here (including our usability experts) said they preferred it on the left side where it isn’t easily overlooked (unlike on the right side).
8. The current settings (which tabs are open) should be saved upon exit and restored when the user enters the dialog the next time. I hadn’t explicitly mentioned this, but this was always our intention. It’s not in the code yet, but this is the next thing on the “to do” list.

There were also some side issues that were not entirely on topic, yet worthwhile to mention:

1. Don’t quit the package management workflow after package installation is finished. There was a long discussion about that in Bugzilla why that “Install more packages?” pop-up was introduced in the first place (because of slow start-up times of the package management stack) and why we removed it when that was no longer the case. For those of you who want that question pop-up back, look here how.
2. Some users complained that the new flat list in the Package Groups filter view is confusing – too many packages are listed in each category. They want the old tree back. Well, here it is – it’s the RPM Groups filter view I had briefly mentioned:
   

   The other view (the flat PackageKit groups list) is still there, of course: