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:

   

There have been some very important Tomboy and Tasque releases in the past month or so that I have neglected to share. I think it's true that Twitter removes a lot of the motivation to blog. Here are the takeaway points:

• Tomboy 0.12.2, an update to the stable series, fixes a nasty bug that could cause notes to be mistakenly deleted during synchronization. Versions of Tomboy affected by this bug are: 0.12.0, 0.12.1, 0.13.0, 0.13.1. If you are using any of these versions, and you like to use sync (or set note contents via the dbus interface), please upgrade now! Note that this was fixed in the unstable series in Tomboy 0.13.2.
• Yesterday I finally made new Windows/Mac builds. You can get binaries for Tomboy 0.13.3 at our download page.
• Last month we released Tasque 0.1.8. It fixes problems communicating with RememberTheMilk.com and a kabillion other bugs. Windows and Mac binaries are available at the download page.
• Ankit Jain has started reviving Giver development. For one thing, he has Windows builds available for download (an obviously useful feature for a file sharing tool).
• I've discovered the best theme for openSUSE: Shiki Colors with the Shiki-Wise color scheme and the GNOME-Colors icon set.
  

So what else is going on? Tomboy 0.13.3 features some fixes that cut down my memory usage by 25% (with ~200 notes). It should also speed up start-up time if you have a big note collection. One user with 621 notes reported a change from 11 seconds to 4 seconds when he upgraded! The fixes were almost all related to extra work done on a per-note basis, so the memory and performance wins are most significant on these large note collections.

That being said, there is a lot more work to do on memory and performance. Ruben Vermeersch blogged about adapting Federico's timeline tracing tools to chart Tomboy start-up performance. This is going to be extremely helpful in figuring out where we're slowing things down. And as for memory usage, I have only fixed the low-hanging fruit; there are more wins to be had! If this is an area of computer science that you find fun, all help is welcome. :-)


My day job of working on the Mono Accessibility team has kept me pretty busy, and it's been hard lately to find time to work on Tomboy and Tasque. Sure, my team understands when I take a few hours every couple of weeks to prepare a Tomboy release, but that doesn't provide enough time for big feature work or difficult bug fixes. For example, we knew about the problems with Tasque and RememberTheMilk.com for a month before we were able to fix it and get a release out. Fortunately, Novell has its cool "ITO" (Innovation Time On) program. I accumulate 4 hours of ITO every week; that's basically the equivalent of 10% time! As I used up all of my regular time off with hospital visits last year, I scheduled four days of ITO during the week of Christmas. I was able to use that time to review a ton of outstanding patches for Tasque, fix the bugs in the RTM and SQLite backends, and make it easy to build on Windows and Mac OS X. This is also when I did all of the memory fixes for Tomboy. So a big thanks to Novell for supporting me in this work.

Lastly, I'm really excited about Ankit Jain's work on Giver. I never worked on Giver, unless you count the moral support I lent during that first Hackweek. :-) But I am amazed at how many people are asking for updates, Windows and Mac versions, etc. As somebody who works from home, Giver isn't that useful to me, but apparently it is very popular and more people are learning about it every day. With Ankit's help, this project may not be so dead after all. You can help him out by testing his Windows builds, trying latest SVN, filing issues, and hanging out in #giver on GIMPNet.

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?

Reduce the number of filter views? Well, we’ve been down that road for a while. But new ones come along all the time, and it always hurts some users when we throw out their favourite one. The “RPM groups” (the one with a tree) was such a case; it had to make way for the newer PackageKit groups. A number of users complained.

And we have more filter views in store. There are many more cool things we could do. But this should not add to confusion, so right now, we avoid to add more views.

But how is everybody else doing it? Let’s have a few looks at that.

What is it we are doing here? We are browsing for and through packages. So, let’s compare it with other kinds of browsers. Let’s look at Konqueror:

In Konqueror, you can use tabs. Once you got used to it, that’s a powerful and efficient way to avoid cluttering your screen with multiple browser windows. They are all neatly tucked away in that row of tabs.

Another application that uses a similar approach is Konsole, the KDE terminal emulator:

While in Konqueror you use the middle mouse button to open a link or a bookmark in a new tab, there is a limited number of options in Konsole. You select a session type from a pop-up menu on a special button on the bottom left corner:

So, let’s try someting similar with the YaST2 Qt package selector. Let’s try to use tabs, but not in an overwhelming number. Let’s open only a few of them right away. The user can open more if he likes.

First try:

Hm – or maybe put that “View” button in the top left corner?

Of course, the user can close any of the open tabs (except the last one) again – just like in Konqueror or in Konsole:

If we really do that, that means that the door is now no longer closed for new filter views. Some that could be added immediately are:

• Show all available (not installed) packages (yes, available via “Installation Summary”, but not that obvious to novice users)
• Show all installed packages (also available via “Installation Summary”)
• Keywords / tag cloud (“KDE application” (linked against KDE libs), “GNOME application”, “mail client”, “Java application”)

We don’t want to overdo it, of course.

So… what do you out there think? Do you like it? Should we use tabs there? If yes, where to put that “View” menu? Left? Right? Elsewhere? Use a toolbar button with just an icon (like in Konsole) instead? Add it to the main menu, too?

Comments? (on topic please, there are other tools and forums for support or bug reports)

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!

I just released libgphoto2 2.4.4, after fixing some small bugs I missed previously.

So get it while it is hot. :)

- Improved Canon and Nikon remote capture, lots more to configure.
- Lots of bugfixes in the ptp driver.
- Faster startup in the ptp driver (but not as fast as it should be able to get).

And last but not least, translation updated, so you can say:

"Фотоаппарат не обнаружен" or "无法检测到任何相机" or "Impossible de détecter aucun appareil" or "Konnte keine Kamera finden", which hopefully all mean something like "Could not detect any camera".

And after 1 hour of uploading and updating news sites, I go to bed now. :)

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…

Documentation

Most of the Teaming documentation can be found here:  http://www.novell.com/documentation/team_plus_conf/

Prerequisites

• SLES (our server platform)
• OES2 (not entirely important, but it knocks out a lot of the pre-reqs and gives you LDAP support if you have eDirectory running)
• Teaming Licenses (a “starter pack” of 20 free licenses is available, contact your Novell vendor for more information)
• I’m assuming you’re running the setup from a Linux box, but this isn’t 100% necessary

Preparing your installation

There are a few things you need to do before getting started.  First being to install mysql:

# zypper in mysql mysql-client mysql-shared perl-DBD-mysql perl-DBI perl-Data-ShowTable libmysqlclient-devel

# chkconfig –add mysql

# /etc/init.d/mysql start

# mysql_secure_installation

Next, you’ll need to edit your /etc/my.cnf to change the default character set support.  Add the following lines to /etcmy.cnf:

[mysqld]
character_set_server = utf8
[client]
default_character_set = utf8

Additionally, you’ll need to increase your open file limits in /etc/security/limits.conf:

• hard nofile 65535
• soft nofile 4096

Installation

I like to run everything from a single location, so to kick things off, I created the directory ‘/incoming’.  Once there, you’ll need to download your copy of Teaming and extract it into this directory.

Once you’ve gotten everything extracted, download your license file and copy it to the same directory, but make sure that you rename it to “license-key.xml”.  The Teaming installer will complain to no end if it’s unable to find this exact file in the install root.

Next, you’ll need to make the installer executable:

# cd /incoming && chmod 755 installer-liferay.linux

Now it’s time to run the installer.  The installer comes as a GUI package, but can be run via a text interface as well.  If you’re ssh’ing into your server to set up Teaming, you’ll want to forward X to allow the GUI to open (ssh -X -C user@server.com).  Otherwise, use the ‘-console’ knob to initiate the text based installer.

# ./installer-liferay.linux

-or-

# ./installer-liferay.linux -console

I recommend choosing advanced options for install as it allows for greater flexibility in options.  Once you’ve followed through the installation steps (note, I installed mine copy into /opt/icecore), liferay/Teaming should be successfully installed.  Now you’ll need to start the server:

# /opt/icecore/liferay-portal-tomcat-5.5-jdk5-4.3.0/bin/icecore start

To ensure that Teaming starts on boot, issue the following commands:

# cp /opt/icecore/liferay-portal-tomcat-5.5-jdk5-4.3.0/bin/icecore /etc/init.d

# chkconfig –add icecore

After that, you should be able to start, stop, and restart ‘icecore’  using the /etc/init.d/icecore script.

At this point, Teaming should be up and running.  To access it and get started, open your browser and navigate to http://yourserver.com:8080 and log in as user admin with the password ‘admin’ (no quotes).

Once logged in, you’ll need to pull the administrative modules down to your view by selecting the ‘Add Content’ option in the upper right hand corner.  I like to use the shotgun method and add all of the administrative modules for my admin user.

So there you have it, a fresh Teaming install.  Enjoy!

Morten, Indeed it was a bug on some gtk2 patch.
It seems the fix already went to updates (btw i recommend enabling 11.1-test updates) because the openSUSE people is taking a long time to get updates pushed from developers, who already fixed lots of bugs.

So grab the fixed packages from federico home.

Voi lá!

18-1-2009 Brasero 0.9.1

Main highlight is the new libbrasero-media which results from the splitting brasero
Some more work was done to make brasero work with other apps like totem, rhythmbox and sound-juicer
Nautilus extension was updated (new hint, uses libbrasero-media).

+ some unreported bugs fixed


Reported bugs fixed:
#566721 – Wrong LDFLAGS introduced into BRASERO_*_LIBS
#567582 – Fails to burn a DVD iso
#561451 – Cannot burn CDs with brasero
#564748 – Brasero fails to burn DVDs


Updated translations:
* es.po: Jorge Gonzalez <jorgegonz@svn.gnome.org>
* fi.po: Ilkka Tuohela <hile@iki.fi>
* de.po: Mario Blättermann <mariobl@svn.gnome.org>
* ca.po: Updated Catalan translation by Joan Duran.
* fr.po: Claude Paroz <claude@2xlibre.net>
* zh_CN.po: 甘露(Gan Lu) <rhythm.gan@gmail.com>
* nb.po: Kjartan Maraas <kmaraas@gnome.org>
* sv.po: Daniel Nylander <po@danielnylander.se>
* it.po: Updated Italian translation by Milo Casagrande.
* pt_BR.po: Updated Brazilian Portuguese translation. Contributed by César Veiga.
* hu.po: Gabor Kelemen <kelemeng@gnome.hu>.
* da.po: Updated Danish translation by Mads Lundby

Thanks to all the people who contributed to this release through patches, translations, advices, artwork, bug reports.

Homepage: http://www.gnome.org/projects/brasero

Please report bugs to: http://bugzilla.gnome.org/browse.cgi?product=brasero

Mailing List for User and Developer discussion: brasero-list@gnome.org

Svn Repository: http://svn.gnome.org/viewcvs/brasero/

Thanks to all the people who contributed to this release through patches, translation, advices, artwork, bug reports.

PS: For the next release, since Brasero got accepted on Gnome Desktop platform for 2.26, Brasero versioning will be like other GNOME modules.

I'll blog about the inclusion later.