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

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!