openSUSE welcomes Google Summer of Code 2014 participants. Thanks to Google, openSUSE has an excellent number of slots and an equally excellent number of mentors and students for Google Summer of Code 2014. Throughuout the summer, students participanting in this program will code for openSUSE and its sister organizations ownCloud, MATE and Zorp and help them move forward. The best part of GSoC is that most of the code written by students will go upstream and will benefit openSUSE in general also. Along with this, we have an equally good range of projects that will improve
the existing openSUSE architecture.

The list of successful students are :

1. Travel Support Program application –     Karthik Senthil
2. Playlist Functionality for ownCloud Music App –    Volkan
3. ownCloud Calendar Application in angularJS –    Raghu Nayyar
4. openSUSE GSOC ideas: Cool live flash –    Zsolt Peter Basak
5. Open Source Event Manager (OSEM): Refactor user management model –  Stella Rouzi
6. Open Source Event Manager (OSEM): Implemention Organizer Dashboard –    cbruckmayer
7. MATE: Port from deprecated GStreamer 0.10 –    Michal Ratajsky
8. Integrate Snapper Snapshot browsing into openSUSE Desktop tools –  Oguz Kayral
9. Implement an application-level LBaaS driver for Zorp –    Péter Vörös
10. Extend Git-Review to support BitBucket –    xystushi
11. Event Splash page for Visitors In Open Source Event Manager Application. –    Gopesh Tulsyan
12. ePub support in Atril (MATE) –    Avishkar gupta
13. Add Snapshot management API to libvirt Xenlight driver –    David Kiarie
14. Improving the functionality of the extensions system in Caja  – Alexandervdm

In the following weeks I will talk a lot more about these projects and get to know these students well.

Lets brew some code now.

Requests to unlock KWallet automatically on login (assuming the wallet password and user password are the same), like gnome-keyring can do, have been going on for years: in fact, bug reports requesting this feature are quite old.  Recently, thanks to the efforts of Alex Fiestas, a PAM module, which interfaces KWallet to the system authentication methods, has been developed. In parallel, the necessary glue code has been also added to the various parts of the KDE workspace so that it could make use of it.

While the module itself has not been released yet officially, it’s been used already by some distributions (Kubuntu). However documentation is lacking, so it could be hard to set it up for anyone else.  This post provides some indications on how to set KWallet up with PAM.

Before we begin, a disclaimer: ** as we’re deailng with pre-release software, do everything at your own risk! Errors with PAM can lock you out of your system!**

Also, ther’s no guarantee that these instructions, although they worked for me, will work for you. YMMV.

Prerequisites

**EDIT: You will need a more recent startkde script than the one shipped in Workspace 4.11.8: ask your distro for a back-port of the latest commits to it (last 3 since 4.11.8). ** Thanks to Rex Dieter (Fedora) for letting me know.

You need to have libgcrypt and its development headers installed, and at least version 1.5.0 (earlier versions won’t work), along with the PAM development headers. Before beginning, change your wallet password to be the same as your login password (you chose a strong password, didn’t you ;).

EDIT: You wll need also socat, because it’s used to inject the right environment when the KDE workspace session is starting.

Building pam-kwallet

Clone the git repository holding pam-kwallet (NOTE for posterity: the URL may change in the future once the code moves properly inside KDE’s official modules):

git clone git://anongit.kde.org/scratch/afiestas/pam-kwallet.git

Then compile:

mkdir build; cd build
cmake -DCMAKE_INSTALL_PREFIX=$(kde4-config --prefix) ../
make

You may have to add -DLIB_SUFFIX=64 if you are using a 64 bit system or the library may get installed in the wrong path.

Install either as root or using sudo:

make install

Hooking pam-kwallet to PAM

Once this is done, we need to hook pam-kwallet to PAM proper. These instructions have been made with inspiration from the Arch Linux Wiki entry on GNOME keyring and should be your reference in case of issues.

We’ll have to tell PAM that it can use our freshly built module as an authentication mechanism. We will be doing so by editing specific files under /etc/pam.d. All operations should be done as root or using sudo.

First, we edit /etc/pam.d/login (added lines are with). This is how it looks in my system (note: depending on your distro, it may and will look different)

#%PAM-1.0
auth requisite pam_nologin.so
auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
#session optional pam_lastlog.so nowtmp showfailed
session optional pam_mail.so standard
-session optional pam_kwallet.so auto_start #### Add this line

Then we change /etc/pam.d/passwd. Notice that there is a caveat described below:

#%PAM-1.0
auth include common-auth
-auth optional pam_kwallet.so ### add this line
account include common-account
password include common-password
session include common-session

It is essential now that you notice whether you are using a default .kde for your KDE applications settings, or another name (for example .kde4 in openSUSE). If it is different from .kde, you must add an option which tells the PAM module where it is (it only involves modifications in /etc/pam.d/passwd):

-auth optional pam_kwallet.so kdehome=.kde4 # for .kde4

Alternative setup

While the setup above should work, it may not. In this case, you will need to edit the PAM files used by your display manager. In the case of KDM, they may be _/etc/pam.d/kdm _or /etc/pam.d/xdm. For LightDM, you should edit both /etc/pam.d/lightdm and /etc/pam.d/lightdm-greeter.

Either case, put both the auth and the session line in the files, as such (example from my setup)

#%PAM-1.0
# LightDM PAM configuration used only for the greeter session
auth required pam_permit.so
-auth optional pam_kwallet.so kdehome=.kde4 ### added
account required pam_permit.so
password include common-password
session required pam_loginuid.so
session include common-session
-session optional pam_kwallet.so auto_start ### added

Wrapping it up

After these changes, log out and back in. If everything is correct, you will not see password requests from KWallet, but you will see your wallet properly unlocked!

And if it doesn’t work?

I warned you. ;) More seriously, look in the authentication logs for clues to see whether there were PAM errors. My suggestion would be to wait for distros to figure this out, or hope that a real PAM expert steps in, as debugging is very difficult (at least for me) at such a low level.

EDIT: As pointed out by Rex Dieter (Fedora), putting a - in front of your PAM entries will make PAM ignore them if unavailable, reducing the amount of logging sent to your syslog.

This is a guest post by Raymond “tittiatcoke” Wooninck, with contributions from myself and Hrvoje “shumski” Senjan

In the next hours the [KDE:Current]({{ site.url }}/2014/03/being-current/) repository will publish the latest release from KDE (4.13). As that this release comes with a big change (the new semantic search), 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, 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 the wiki  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 baloo-file package is installed (it is required for indexing). After this check, log off and back on. The Nepomuk 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 stillrequiring the Nepomuk framework (like bangarang, kweshtunotes, etc).

Using the new search system

Unlike the ‘include folders to be indexed’ used with Nepomuk, the new search backend prefers to index everything and exclude unwanted folders explicitly. With the standard setup,  all files and directories below the home-directory will be indexed. All other filesystems are indicated as omitted.

This can be changed by deleting the respective entries in System Settings. To turn indexing off completely, add your home directory to the excluded folder list (bear in mind that this will prevent search from working). To remove the components completely, remove the baloo-file package. The package baloo-pim (only present when kdepim is installed) can be removed if no search capabilities are required for KMail.

Aside from Dolphin, the only search UI  available is the package called milou. Milou can be placed in the panel for easy access and its usage is quite simple. The search term is indicated and search results are shown for files, emails, and so on.  You can pick which categories to use in the settings.  At the moment you should not put Milou in the system tray, because it will cause Plasma to crash at login.

Tags in the files are now stored using extended attributes (xattrs) instead that in the database.

Known issues

• The initial indexing can be heavy on I/O especially if there are large text files: either wait till the indexing is complete (this step is done only once), or exclude the folder containing such files.

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

Reporting problems

As usual, use Novell’s Bugzilla if you find issues pertaining to the specific packaging used in openSUSE: otherwise, report bugs directly to KDE.

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 !!

Para deixar o sua área de trabalho com openSUSE ainda mais bonita, que tal instalar o Conky que é um monitor do sistema leve e poderoso que pode mostrar várias informações sobre o seu computador.

O Conky está disponível no repositório Packman. Se você ainda não configurou seus repositórios abra o YAST e selecione Software e depois Gerenciamento de Repositórios. Em seguida selecione Adicionar Repositórios e depois selecione Repositórios da Comunidade. Uma lista de repositórios vai aparecer e, então escolha os que você deseja, principalmente o Packman que contém o Conky e muitos outros programas quase que essenciais.

Depois de atualizada a lista de repositórios, cliue no Yast em Gerencimento de Software. Faça a busca por Conky. Selecione e clique em instalar. O Conky é bem pequeno e instala rapidinho.

Para facilitar a configuração do  Conky vamos instalar o Conky-Mannager que até pouco tempo não existia em nenhum repositório (pelo menos que eu saiba), mas aque agora possui um repositório que facilita muito a nossa vida sem precisar fazer “gambiarra”com pacote .deb. Vamos lá…

Você pode instalar o novo repositório através do 1 Click Install, basta acessar esse link para configurar o repositório e instalar automaticamente: http://software.opensuse.org/download.html?project=home:DarkSS&package=conky-manager

Depois clique no botão com símbolo openSUSE.

Na próxima página selecione a versão do openSUSE que está usando:

É só esperar um pouquinho que o Conky-Mannager estará instalado em seu computador. Depois de instalado vá no seu Menu Iniciar  >> Utilitários >> Área de trabalho e clique em Conky Mannager.

Uma janela com o gerenciador do Conky vai abrir, basta agora você escolher um tema que mais lhe agrade. No meu caso eu gosto muito do Gotham que eu acho simples e bonito.

Agora vamos ajustar a posição que o conky vai aparecer na tela e também configurá-lo para iniciar juntamente com o sistema para não precisarmos fazer toda vez que iniciamos a máquina. Clique em Edit e conforme a imagem posicionei o Conky aonde eu gosto, ou seja, na parte inferior esquerda da tela, mas isso pode variar conforme o gosto de cada um e também com o papel de parede, para ficar bem legal…rs.

Agora clique em Options e selecione a caixa de seleção conforme imagem abaixo. Depois é só fechar e curtir sua área de trabalho. Adoro o Conky, pois acho que dá um charme a mais ao meu openSUSE. Veja como ficou:

Agora é com você. Escolha o seu tema preferido e configure-o a seu gosto. Espero ter ajudado. Um abraço!

We are happy to announce that the LibreOffice project has 10 Google Summer of Code projects for this 10th edition of the program. The selected projects and students are:

We wish all of them a lot of success and let the coding start!

• I have a problem with e.g. xfce4-power-manager, which I'm unable to fix right now


• I check out some random other package (let's call it "yerba-power-manager") to check if it can replace xfpm for me


• I find it has a bug. Or two. Actually caused by broken openSUSE patches trying to implement new APIs


• Because it is "an interesting problem", I fix it them just for fun


• Later I find that I have no use for this package as (for unreated reasons), it does not fix any of my original problems