Updating to KDE SC 4.13 from KDE:Current

In the next hours KDE:Current will publish KDE 4.13 SC. As that this release comes with a big change (Nepomuk -> Baloo), we would like some simple steps in order to perform the right upgrade.

Before the upgrade

In order to migrate data automatically from the Nepomuk store to the new format (used by Baloo), you will need Nepomuk up and running, and just for the time needed for the migration. Ensure that Nepomuk is running before the update (in System Settings > Desktop Search). This is only necessary in case Nepomuk is in use on the system.

The upgrade itself

• If you are already using KDE:Current then the upgrade should be a simple “zypper up” or upgrade packages through YaST Software Management.
• If you are not yet using KDE:Current, then please follow the instructions on https://en.opensuse.org/KDE_repositories#Current_KDE_SC_release on how to add the necessary repositories. After adding them, a zypper dup is required to ensure that all the KDE packages are coming from KDE:Current.

Please do not remove nepomuk, as that otherwise the migration to baloo will fail !! Also after the upgrade please make sure that the following package is installed “baloo-file”. After this check, log off and back on. The migrator will then run and move all the data that can be migrated to the new system. It will also turn off Nepomuk at the end of the migration.

At this moment it would be safe to remove the nepomuk related packages like nepomuk-core, libnepomukwidgets, soprano*, strigi, virtuoso and shared-desktop-ontologies. There are only a few packages left that are still

requiring the nepomuk-framework (like bangarang, kweshtunotes, etc).

Using Baloo

Unlike the ‘include folders to be indexed’, Baloo prefers to index everything and exclude unwanted folders explicitly. With the standard setup, Baloo will index all files and directories below the home-directory. All other filesystems are indicated as omitted. This can be changed by deleting the respective entries. Unfortunately it is not possible to switch baloo off through systemsettings. If baloo is not wanted on the system, then the package “baloo-file” needs to be removed to prevent files being indexed. The package “baloo-pim” (only present when kdepim is installed) can be removed if no search capabilities are required for kmail.

The only search client currently available for baloo, is the package called milou. Milou can be placed in the panel for easy access and the usage is quite simple. The search term is indicated and search results are shown for files, emails, etc. In the Milou settings, the categories from which results are shown can be selected. Milou can NOT be placed in the systray, as that this would cause the plasma desktop to crash upon login.

Tags on files are no longer stored inside the database, but stored in the extended file attributes (xattr), which are stored in separate files on the filesystem.

Known issues with KDE 4.13

• The initial indexing can be heavy on I/O especially if there are large text files: either one waits till the indexing is complete (this step is done only once), or the folder containing such files is excluded using System Settings.
• Some data will be lost during the migration: in particular, emails will have to be re-indexed, and file<->activity associations, if used, will not be preserved.
• Milou causes the Plasma-desktop to crash if it is placed in the systray !!

Homerun-kicker (A new application launcher)

Homerun-kicker

 

Homerun is a fullscreen launcher with content organized in tabs. A tab is composed of several “sources”. A source can provide one or more sections to a tab. Homerun comes with a few built-in sources, but custom sources can be written using libhomerun.

The main addition in Homerun 1.2.0 is a second interface built atop Homerun’s collection of data sources, theHomerun Kicker launcher menu shown below.

Homerun Kicker is a more traditional launcher menu design optimized for efficient use by mouse or touchscreen when placed on a panel.

The use of traditional, cascading popup menus is complemented by a sidebar strip in which application favorites and items related to power and session handling may be placed. Both types of items can be added, removed and reordered at will via mouse and menus.

Compared to Kickoff we see the following differences:

* Single level menu, so therefore no sub menus

* Two additional menu entries in the main menu to show recent used documents and applications

* Favorite applications directly besides the main menu (left-hand side)

* Does not have a separate part for Places and Administration like Kickoff has

* Better integration with the plasma theme.

* Less intrusive on the desktop and suitable for smaller screens

With the openSUSE KDE theme, the desktop would look like this

Based on the indicated differences, the openSUSE KDE community team would like to propose to make it the default Application Launcher.

For more information, see the original blog post from the Author at http://blogs.kde.org/2014/01/29/homerun-120. For those interested to give it a spin, you can find the latest released version of homerun in the KDE:Extra repository. Install the package and then add the homerun-kicker plasmoid to your panel.

KDE:Unstable:SC is moving forward

For some time now, the KDE:Unstable:SC repository for openSUSE did not offer any new snapshot due to the work that was going into getting KDE 4.10 into the upcoming openSUSE 12.3 release. Now that the latest KDE 4.10 Release Candidate (RC2) was placed into the correct repositories, I found some time again to update the KDE:Unstable:SC to a new snapshot from KDE git-master (KDE 4.11). Of course at this moment not many changes are happening in git-master due to the polishing of the KDE 4.10 release (beginning of February). 

Happy Testing…..

brBoard Elections: openSUSE Release Strategy

As also indicated on my Board Election Platform page (http://en.opensuse.org/openSUSE:Board_election_2012_platform_rwooninck), one of the topics that I would like to change is the strategy plan/release goals for the upcoming openSUSE releases.

The issue as seen by me. 

Currently the strategy plan for the distribution is seen from the outside as handled only by developers or people working with the development version. Although this is not wrong, it ultimately leads to a lack of communication on why certain decisions were taken, or why defaults were changed, and so on. Of course the discussion appear in the open, like in mailing lists, but other forms of communication, like a wiki page describing the goals set for the next release, including the rationale for the changes, is missing. Ultimately this leads to confusions among end-users, and even among contributors, as endless discussions appear often on the mailing lists.

My proposal on how to improve the process

The strategy process can be improved in two areas. The first area is the simpler one, where we should utilize wiki pages to describe the goals set for the next release. Similar to what the KDE organization is doing. On the main wiki page, the teams can list their plans on what they want to achieve or improve in the next openSUSE release. The team could create detailed wiki pages behind those goals and track the progress on the main wiki page. Major changes within the distribution should always have a detailed page where the change is described in more detail and also indicating how it would impact other areas and/or the user.

The second area is how to get to the right strategy plan for the next openSUSE release. We have openFATE where users are registering their requests for changes, but I see no real official follow-up on this. There are quite some discussions per requests, but in the end it is not clear if a request is being implemented or not. Also the requester will never know exactly in which openSUSE release his request might get implemented. Especially in this area a bigger change is required. In a kind of strategy round the outstanding openFATE requests should be evaluated and classified. Classification could be consisting out of:  “Next Release”, “Future Release”, “Rejected”, “Info required”. Those classified as “Next Release” will be implemented in the upcoming openSUSE release. Those classified as “Future Release” have been accepted, but due to several reason, they can not be implemented in the upcoming release. Similar approached are also being followed by the other distributions.

Let the openSUSE Board campaign begin.

This afternoon the official start of the Campaign week for the openSUSE board was given. In total there are 8 candidates with all good credentials. 

I would like to kick-off my campaign with the following: 

Introduction and Biography 

Most of you will know me as tittiatcoke, but my real name is Raymond Wooninck, 47 years young, holding a Dutch nationality and since 2001 living with my wife and 2 children in Vienna, Austria. 

Professional live

I have been working since 1990 in the IT area. Started out as an Application Manager and climbed up to departmental manager to SAP Technical Consultant. In 2001 I moved to Austria to start working for the second largest Coca-Cola bottler in the world and to support them during the implement of the SAP system. Now 11 years and diverse positions later, I have been assigned to the function of Application Portfolio Manager within the Strategy & Architecture department. While shaping this new role, I found quite some interesting similarities with the role of the openSUSE board as I see it. 

Unix and I

I had my experience with running Minix, SCO Unix and Linux (since kernel v0.12). Got into the distributions and played around with Red Hat, Mandrake and SuSE, but always came back to the SuSE distro. Shortly after that the openSUSE OBS opened (2009) the possibility to create your own packages, I started packaging a couple of KDE utilities and this brought me an invitation to push them to an official KDE repository and to start working together with the openSUSE KDE team (Many thanks to Dirk Mueller and Stephan Binner (Beineri) for that). 

openSUSE work

After my first experiences with the openSUSE OBS, I got more and more involved. Since end 2009 I took the maintainership for the Google opensource browser Chromium. Tried my luck with the integration of Plymouth (bootsplash) into the openSUSE Distro and got rewarded by having Plymouth as the default bootsplash in openSUSE 12.2. Due to reassignments within the official SuSE/openSUSE teams, I became one of the main maintainers of the KDE repositories and am currently maintaining these repo’s together with a great team. One of the last major activities was to ensure that both the Gnome and KDE desktops would function based on the new systemd-logind session manager and remove the ConsoleKit dependency. This work was done in cooperation with the Gnome team, which was another proof that within openSUSE both teams can work together and make great things happen. 

My view

In my view, there is need for improvement in the areas of user-friendliness (including not only use itself, but easiness of adoption, development, and so on) and access to information. Currently the strategy plan for the distribution is seen from outside as handled inly by developers or people working with the development version. Although this is not wrong, it ultimately leads to a lack of communication on why certain decisions were taken, or why defaults were changed, and so on. Of course the discussion appear in the open, like in mailing lists, but other forms of communication, like a wiki page describing the goals set for the next release, including the rationale for the changes, is missing. Ultimately this leads to confusions among end-users, and even among contributors, as endless discussions appear often on the mailing lists.

Role of the board

At the moment the board is hardly visible. Everybody knows that it is there, but we hear or see only very little of it. Also other candidates have already indicated this. 

In my view, the board should become more active in a number of areas. The most profound one being to set the goals/strategy for the next openSUSE release. This is can be easily done by creating the wiki-pages outlines above where based on the openFATE requests, the feature plan is shown. If this is done early enough, our users would have the opportunity to react on it and to increase the usability of the next release. 

Another area is the interaction with the community and to stimulate its members. With the changing role of the openSUSE boosters, some of the major projects (KDE, Gnome, etc) are now 100% depending on community members. This on itself is already a big change and to find enough community members to help out. Together with the new “rules” being setup regarding packaging, patching, etc, it becomes almost impossible to find new people as that people are volunteering for tasks, seeing what is involved and what rules to follow and they disappear. The openSUSE board should take here a more active role in promoting the active participation and rewarding the work that is being done by the community. 

A third area is the involvement of the board in the discussions on the mailing-lists on topics that concerns part of the strategies or decisions around the openSUSE release/distro. Discussion why a certain item was changed or not changes is now done between users and the responsible maintainer. The maintainer currently defends his position and community members are jumping in on either side. I believe that with a different setup of defining the strategy for the next release, the number of these type of discussions should go down. But in the case they still occur the board should intervene and indicate what the agreed/aligned strategy was regarding the topic. This should move the discussion away from a technical point to a strategic discussion. 

Why you should vote for me?

I believe that my strengths lies in my professional background where I am dealing with Application Strategies, Usability, Accessibility every day. Together with my willpower to bring things to an end, would be very beneficial for the board. I believe that I have proven my strengths in the past with my work on the openSUSE KDE desktop experience, the Chromium web browser as part of the standard openSUSE distribution and the integration of plymouth. 

Aims/Goals

If elected to the board

* I will strive to define, align and implement a new strategy process for the openSUSE releases together with the other board members

* I will try to find ways in which the openSUSE board can establish a better communication with its community

Regarding the KDE team

* I will continue to support the team in the best way I can

* I will strive and drive the team to make the best openSUSE KDE desktop experience ever

Chromium moves out and back into the openSUSE OBS

The last week it was a little hectic around the Chromium webbrowser. Initially I announced that the Chromium webbrowser would move from the openSUSE OBS to Packman due to dependencies on ffmpeg. Shortly after my announcement I was contacted by Ludwig Nussel from SUSE with the question what exactly the issue was and if it was not possible to find another solution in order to keep it part of the openSUSE Distribution. 

After my indications Ludwig talked to some SUSE colleagues and the indication was that Chromium had indeed a chance to come back to the Distribution if we just build the opensource ffmpeg codecs. These are the ones that are activated with a standard Chromium browser.  In the past we had this particular library build on Packman, with both the Chromium and Chrome supported codecs. 

The new version of Chromium passed legal review and I am glad to see that Chromium is building and publishing in his old repositories (network:chromium). Due to the changes a new sub packages (chromium-ffmpegsumo) was added that contains the required multimedia library. However to support also the full range of codecs, we still have the chromium-ffmpeg package building on Packman. When you install the chromium-ffmpeg package, the chromium-ffmpegsumo will be deinstalled. 

I know that people might have switched repositories based on my first announcement and that they have to switch back again. But at least this would guarantee updates through the standard maintenance track of the openSUSE Distribution.

Running for the openSUSE Board

Maybe some people already expected this to happen, but for me it is still a surprise that I actually did it. I put myself up as a candidate for the openSUSE Board. 

I started working with Linux since the early days (Kernel v0.12) and have been using openSUSE since 2003.  I joined the openSUSE project about 4 years ago when I submitted my first KDE package. From that moment things went very fast and I am currently the main maintainer for the KDE repositories and maintaining Chromium and the Plymouth bootsplash. One of the next things I want to tackle (package wise) is Dracut 

as an alternative initrd builder. 

My current “day job” is Application Portfolio Manager for a well-known bottling company that focus on the Central and Eastern Europe market. If you look closely at my IRC nick, then you could guess which company it is  In this job I am responsible for setting out the strategy of all Applications used within the company. This ranges from our main Enterprise System (SAP) to desktop tools like collaboration, email, etc. The strategy should e.g. enable Business opportunities to exploit the main Enterprise system further.

If I am elected to the board, then my day job and past IT experience would be a good use. I would like to see the board to set out a new strategy for the openSUSE distribution which makes it possible to enhance our strengths and values. In the past SuSE has established a name for itself and it created some 

great tools, which even now are unmatched. 

Nowadays everything is about Usability and Accessibility. How usable is the software, how accessible is the information, how can I use this program, etc. I would like to extend this principles to the openSUSE project,  

On one hand we need to strengthen the relationship and the communication between the openSUSE community, including people working for SUSE. Only together we can accomplish great things. 

On the other hand we should value our end-users. These users are giving valuable feedback about how they see openSUSE with regards to Usability and Accessibility and their feedback should be incorporate into the final product. This drives the success of a distribution. Too many things out there are already being decided by a handful of people without listening to others. 

It is my opinion that the board should play a big role in both areas and to enable openSUSE to grow. 

My promise to you is that I will do my best to establish the above, If I would be elected. 

Release of openSUSE 12.2 (Plymouth)

IopenSUSE 12.2 got released some days ago and it seems that the plymouth integration is received very well. Even the openSUSE theme got good comments and is seen as sophisticated. This to my big surprise. 🙂  But i am very happy about it as that it proofs that we all did a good job. Unfortunately it seems that plymouth in combinztion with NVIDIA chipset can sometimes cause some unpleasant surprises. But lets hope we cn sort this out with the next release.

As that the pressure ix off again, i started to work on updates of KDE:Unstable:SC again. Yesterday kdegames was moved from svn to git and split out in seperate repositories. So a lot of new packages have to be created. Hopefully i can finish this soon, so that i can create a new snapshot this coming weekend.

Also Chromium saw a big chance recently. A couple of builds ago we noticed that chromium started to behave rathar crashy. Investigations showed that the our attempt to build with as much system libraries as possible failed. The chromium developers seemed to hsve r3ached the point where the system libraries are no longer compatible with the ones shipped with the chromium source. So as of two build, Chromium is now switched to utilize its full sourcecode. This resolved the issues and also the wotk required in keeping the opensuse patches up to date.

Plymouth in openSUSE Factory

As some of you know, I have been working on plymouth support in openSUSE. This was a feature that was requested already some time ago, but nobody found the time to actually implement it. 

Since a couple of weeks I have been working on getting plymouth to work and to resolve the known issues. This can be tracked on the following link :  http://en.opensuse.org/openSUSE:Plymouth&nbsp;

With the help of teammembers of the openSUSE KDE team (tigerfoot, einar77), the issues were resolved and Plymouth got accepted in openSUSE:Factory

To get full support for password requests and displaying text, the initrd was enhanced with some additional libraries and fonts. The luks initrd script was reworked to get plymouth support for the password requests and a patch was submitted to the maintainer of the package cryptsetup. 

The full set of packages (including all the latest patches, etc), can be obtained from the OBS project home:tittiatcoke. Plymouth of course can be directly obtained from Factory. 

I would like to ask everybody to test the new Plymouth packages and to fill bugs for things that are not working or to indicate these on the webpage : http;//en.opensuse.org/openSUSE:Plymouth. 

Currently we are working on the openSUSE branding for Plymouth, so that we can complete the new boot experience. 

KDE:Unstable:SC has become alive again

I know that for quite some time the KDE:Unstable:SC repo didn’t contain any recent snapshots. The repo was used to test the 4.8.0 tarballs and since then no more updates took place. 

However since today that has changed. As of now KDE:Unstable:SC contains a very recent snapshot of the KDE SC 4.9 and the packages got published. As always the target is to provide weekly snapshots of the KDE SC 4.9 and other packages. 

At this moment the kdemultimedia packages (juk, kmix, kio_audiocd, etc) are still on the 4.8.2 level as that the main KDE repository is moved from SVN to GIT. As soon as this has been completed, the packages in KDE:Unstable:SC will be updated with the next possible snapshot. 

I have been running snapshots of KDE 4.9 and I have to say that the stability is quite good. Most of the changes are the rewrite of plasmoids, etc to the new QML language. 

Enjoy!