Another openSUSE Conference, another Country, but the same awesomeness. I attended the openSUSE Conference in the amazing city of Dubrovnik (more commonly known as King’s Landing), and it was another spell binding experience. Right from the talks, presentations, people (I cant stress on this one enough) to the location, everything was impeccable. I sit down to pen my thoughts at another experience, and memories which I will cherish. There was plenty to enjoy, learn, discuss at the conference, which lived upto its tagline – ‘The Strength to Change’. I highlight some of my experiences in this rather lengthy post.

The Location:

The location was just spectacular. I have been a ‘A Song of Ice and Fire’ and ‘Game of Thrones’ fan for quite some time, and had a vivid image of what King’s Landing would look like. It lived up perfectly to its name. I think Dubrovnik was ‘meant’ to play host to King’s Landing in the series. Visiting the Walls, Fort Lovrijenac (The Red Keep) felt like I had landed inside the world of Westeros.

The Conference was held in the University of Dubrovnik. It was a pretty nice location, very close to Oldtown in a nice, peaceful location.

Video Team:

This was something new to me. I helped around with the video team in mixing videos, and handling the camera for some of the talks. I had never done this before, and Christopher Hoffman gave me a great hands on. It was a pretty nice experience, working with Stephan Barth, Dubravko Jakovljević, Sarah, Jurgen, Marcel. I hope to be helping around with the video team at the next oSC as well.

The Presentations:

As always, the presentations were top notch. Mentioning some which I really liked

• Design and Branding – Kenneth Wimmer. This one cleared up some confusion there was with the openSUSE artwork. I really like the cool and funky new Geekos
• Almost every talk by Jos Poortvliet
• SLE and openSUSE by Jan Weber
• YaST Module from Scratch by Josef Reidinger (This one was cool!!!)
• oSC15 by Bruno Friedmann
• The upstream view of MySQL – Norvald H. Ryeng
• The TSP talks by Izabel and Ancor

The Townhall Meeting:

I missed a part of the townhall partly due  to the incessant rain, but I got in time for the bulk of the discussion. The burning issues in the townhall were related to the openSUSE Release Cycle, and how Factory fits in. The discussion was pretty interesting, though the outcome will probably be clear in the current weeks. As of now, openSUSE 13.2 is slated for a November release.

openSUSE Summit:

At oSC13 in Thessaloniki, I had met Yan Sun, where she had put forth the idea for an openSUSE Summit in Asia. She put forth the proposal to the board in the last conference, though due to some issues, the dates kept shifting, though the event had been approved. Now, it looks like the event would be held in October/November in Beijing. I had a good discussion with her on topics such as talks, presentations and the TSP, which would be a vital cog for the conference. I am hoping to attend the event and give a presentation. Lets see how that works out. Fingers crossed on this one

Anahuac Gil:

Yes…I had to devote a whole section to this amazing person from Brazil, and one who made the conference even more memorable. I first met him at the hotel with Izabel, and we got down to talking. The discussions were amazing on talks from our diverse, but to a certain extent, similar cultures to the evil aspects of Google (and the nexus with the NSA :D). For a whole hour, he shed light on Cuba, which was pretty amazing. Whenever the guy talks, people listen intently. I enjoyed talking to him, and his banter of ‘You are TOO SLOW man!!!’ has stayed with me. Reaffirms my belief that conferences are a great place to meet people and understand different cultures.

The openSUSE Party:

Geekos love to party…plain and simple. After a hard and long conference, we had the main party at Eastwest Beach Club Banje, on the Adriatic shore. It was quite a picturesque place. The food was pretty nice, though I could hardly find stuff I could eat (considering I dont eat meat). Still I had a fun time interacting with people. I met with Peter Czanik, who works with Balabit Security, an organization we are collaborating with in the Google Summer of Code. We had a lengthy discussion on topics ranging from Hungary, Balabit, GSoC to name a few.

The best part of the party was certainly the dedication to Hans de Raadt. He could not make it to the conference, and he is going to organize the next oSC at the Hague. Netherlands. The Geekos gave an awesome tribute to Hans

I got together with a group of Greekos, and talked about the Google Summer of Code. IMO, Greekos are really the most passionate community within the openSUSE Community. I am hoping they participate next year in GSoC

Craziest and most fun part – Geekos exchanging ID Tags in football style. I have no idea who ended up with mine. I now have Tomas Cech’s ID tag instead of mine

Travel Support Program (TSP):

The Travel Support program has been integral for me attending the conference. It is an awesome tool which enables contributors to attend events which help openSUSE as a project grow. Being sponsored to the openSUSE Conference is a great feeling, and urges you to contribute more towards this awesome project. The talk discussing the openSUSE Travel Support Program by Izabel laid out some clear points

• Contribute. It is not a free ride.
• We want to support as many people as possible, but you have to ask for help
• It is not just attending the event in the shadows. Get Involved. It is as much ‘during’ the event, than it is ‘before’
• If you have been sponsored to the conference, remember that it is at the cost of someone else. Make it count…

Prior to the Trip:

This one perhaps warrants a separate blog post, as a guide on how NOT to travel, but I am going with the flow. I made a hash of my reservations, which almost cost me attending the conference.

• I booked flight tickets through Germany, without realizing that I would need at least an airport transit visa. I assumed I would get a German visa, which would allow me to enter Croatia as well. The Embassy of Germany rejected my application, and I was stuck in Limbo for some time. I specially went to Delhi to apply for a Croatian visa, and got it a few days before the trip, leaving me no time to apply for the German visa
• I canceled the tickets through Germany, and in panic, booked tickets going through Austria, without realizing that there is a 20 layover in Vienna, which would have been intolerable, and that I would potentially overstay on my visa.
• I tried looking for an alternative, and was on the verge of booking tickets to Moscow, only to see the price double while I blinked.
• I ultimately ended up canceling the ticket through Austria, and booking through Istanbul, which was a ‘sensible’ route, though it involved a flight plan which went: Bangalore -> Mumbai -> Istanbul -> Zagreb -> Dubrovnik. Travel Hell!!! I am sick of flights…
• I missed the last day of the conference due to these issues, and also ended up spending some more on extending my hotel reservation, which was for a day less.

As the dust settles on the openSUSE Conference, I can only reflect on the awesomeness over the past week. It has really left a lasting impression over me. Thanks to the Geekos around the world, who make the openSUSE Project a success

• The trip is expensive since they come from the other side of the world.
• They come from countries where the cost of the trip or accommodation represent the salary of a year.
• They are students, so they have little income.
• They have family and they cannot afford the expenses derived from being a week far from home.

There comes a time in ever man's life when he says to himself, "there has got to be a better way..."

Set Next Statement

Have you ever been stepping through a method or hit a breakpoint and discovered that variables did not have the expected values? Don't you wish you could go back in time and start stepping through that method from an earlier point to see how things went so horribly wrong? Of course you do.

Last week, with the help of Zoltan Varga (who added the necessary runtime support), I implemented support in Xamarin Studio to set the next statement to execute when you resume execution of your program in the debugger. You can set the next statement to be any statement in the current method; any statement at all. This essentially allows you to jump back in time or completely step over execution of statements after the current position.

Don’t worry. As long as you hit Run To Cursor at precisely the moment the lightning strikes the tower, everything will be fine!

Run to Cursor

If you're like me, you've probably found yourself stepping through some code in the debugger and you get to a loop or something that you know is fine and you just don't feel like hitting Step Over the 5 bajillion times necessary to get past it, so what do you do? Hopefully you don't hit Step Over those 5 bajillion times. Hopefully you just set a breakpoint somewhere after that loop and then hit Continue.

The problem with this solution is that it's tedious.

Soon, however, you'll be able to simply right-click and select Run To Cursor (or just set/use a keybinding) and the debugger will resume execution until it reaches your cursor!

Client-Side Evaluation of Simple Properties

Assuming that you haven't disabled "Allow implicit property evaluation and method invocation" in your Xamarin Studio debugger preferences, whenever class properties are evaluated in the debugger (in the Watch pad, the Locals pad, or when you hover the mouse cursor over a property), in order to get the value, the debugger has to spin up a thread in the program being debugged in order to have it evaluate the property (or other expression) because, unlike fields, properties are really just methods that have to run arbitrary code.

For at least a year or so, now, we've mitigated this somewhat by cheating if the property has the CompilerGeneratedAttribute (signifying that it is an auto-property). When evaluating these properties, we would instead do a lookup of the backing field and get its value since we could do that locally without any need to round-trip to the program being debugged. While this helped a lot, there's a lot of properties out there that effectively just return a field and have no other logic (maybe an auto-property wasn't used because the setter does more than just set the field value?).

To improve performance of this, I started looking into what it would take to interpret the IL locally in the IDE. Obviously this could only really work if the property getter was "simple" enough and didn't have to take locks, etc. I started asking Zoltan some questions on the feasibility of this and he wrote a simple IL interpreter (included in Mono.Debugger.Soft) that I ended up using in Xamarin Studio to try and evaluate properties locally before falling back to having the debuggee's runtime spin up a thread to evaluate the property for us.

Great Scott! When Can I Start Using These Awesome Features?

To use these new features, you will need Mono 3.4.1 (or later) and an upcoming release of Xamarin Studio (5.0.1? It won't quite make it into 5.0).

Well, it's time I get back... to the future! ... And implementing more new features!

openSUSE has made it to yet another Google Summer of Code. This season, we got 14 students who would be contributing code to openSUSE, along with our sister organizations ownCloud, MATE and Zorp. Over the period of four months, students work towards completing their projects under the guidance of their mentors. Specific to openSUSE, we got a host of awesome projects with topics ranging to OSEM(Open Source Event Management), TSP(Travel Support Program application), Snapper, Live Flashing USB, Git Review, libvirt to name a few.

The projects (and their students) selected this season 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

We hope to have an awesome summer of code with a lot of code being integrated into the respective codebases.
Happy Hacking!!!

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