Google Summer of Code 2014 reached its mid term last week and I am proud to announce that all of the students from openSUSE have successfully passed their mid term evaluations

In other news, the openSUSE Project will be holding its first openSUSE Summit in mid-october. It is an exciting news, and anyone who is willing to contribute can do so.

On a personal front, the last 2 weeks have been very laid back and I need to improve on my management skills, lets see.

PS : Writing regular blog posts, is leading me to a place where I dont know what else can I share, maybe a few ideas can help.

Recently, I discovered BitTorrent Sync, which seems to satisfy most of my file syncing demands. It's encrypted client-side, cross-platform and works behind NATs and firewalls. While it is currently still proprietary (who cares, really), it is available for many devices. Besides the usual Windows / Mac binaries, you can find it on Android's Play Store. … Continue reading BitTorrent Sync on openSUSE

End of last week, we have released version 1.6.1 of the ownCloud Client, the desktop tool that does file syncing with your ownCloud. Read on the Desktop Client page how to get and install it.

The recommendation is to update your installation to this version. The previous version 1.6.0 had great new features, first and foremost the parallel up- and download of files and a way more performant handling of the local sync journal. That required a lot of code changes. Unfortunately that also brought in some bugs which are now fixed with the 1.6.1 release.

On the windows platforms, we experienced a memory leak that over time let the memory consumption of the client grow. Also, a problem in the Qt5 library that we ship for windows caused the problem that under some circumstances the wrong encryption lib was loaded, so that some people saw SSL problems on Windows.

And there were crashes. Users kept on reporting that the client was crashing after some time on windows, without a special reason. None of the developers was able to reproduce that or ever saw that. We asked for backtraces, which also can be produced on windows. Even though the backtraces looked similar, we did not find an obvious reason for the crashes. Finally, by reading through all involved code levels again and again, Olivier was able to spot some code in libneon that, again under special circumstances, could cause crashes on win.

It was a one line fix, we quickly built test packages, people tested, and finally the crashes were gone (the patch to libneon is on its way to upstream of course).

All that is now fixed in 1.6.1.

What does that show? There not very much little “easy” bug findings any more. That is similar to the soccer world championship, where the coaches keep telling that there are no “easy opponents” any more nowadays, which is also true. These tricky problems we face in the client are hard to find, require time, often special setups if they are reproduceable at all, and advanced debugging skills. Very challenging, very much fun. But that also requires very much patience from the people who suffer from that bugs. We keep on asking questions, ask to test new daily builds and need time to investigate stuff, and more time to release once we have the fix.

Thank you all for helping in this situation, not giving up, for again testing another daily build, reporting back, trying again. That is really big.

Although the IMF 2014 already took place over a month ago, it is still time to mention the publication which has been presented there:

Post-Mortem Memory Analysis of Cold-Booted Android Devices

Both the paper and the corresponding presentation slides are online (click links or see publications).

The paper was created in cooperation with the Department of Computer Science at the Friedrich-Alexander-University of Erlangen-Nuremberg. I herewith thank the other authors Christian Hilgers, Tilo Müller and Michael Spreitzenbarth. Especially for presenting the paper at the conference during my absence.

Since a couple of weeks the packages offered by openSUSE in the  KDE:Unstable:Frameworks repository have undergone a series of changes. In particular, the packages now install to /usr. For the libraries (KDE Frameworks 5) this will mean a transparent change for the userbase as they are expected to be co-installable, but the workspace components (Plasma 5) will confict with the existing Plasma 4.11.x installation.

What does this mean in practice? If you want to use Plasma 5 you will not be able to use a 4.11.x Plasma Workspace.  The move was made to ease maintenance and packaging, as it meant dropping a number of hacks, and also to make KF5 + Plasma 5 packages suitable for inclusion in openSUSE Factory.  At the same time, the 4.11.x workspace packages were adjusted to reduce the number of components conflicting, so that applications depending on workspace libs (such as KDevelop) would remain on the system also with P5 installed.

We’ve also said this many times but it’s worth repeating: Plasma 5 will not be the default in openSUSE 13.2; the stable, LTS release 4.11.x will (as a note: 4.11.x because the workspace did not increase its version number since becoming LTS, while the Development Platform and the Applications are at 4.13 at the moment).

That said, if you are feeling brave, feel free to try out Plasma 5… and don’t forget to report bugs!

P.S.: Most thanks go to Hrvoje “shumski” Senjan, who did most (if not all) of the packaging work.

P.P.S.: If you like what KDE is doing, please consider supporting the Randa Meetings 2014.

We are happy to announce coming of Scilab to openSUSE Factory. This means that Scilab will be included into standard repository of next openSUSE release – 13.2.

If you want to use Scilab right now, you need to add science repository or use Scilab 1-click install.

Many thanks to Atri Bhattacharya and  Ibrahim Erturk for great work!

Scilab is a scientific software package for numerical computations providing a powerful open computing environment for engineering and scientific applications which includes hundreds of mathematical functions with the possibility to add interactively programs from various languages (C, C++, Fortran…). It has sophisticated data structures (including lists, polynomials, rational functions, linear systems…), an interpreter and a high level programming language. Matlab and Maple files can be converted.

Hi,

recently, I pushed a commit that speeds up the update of an osc project
working copy, if most of the packages in the working copy are already up to
date (that is no update has to be performed).
The following table shows the improvements of the new code (in terms of
wall-clock time). Both project working copies were already up to date
and the packages in the home:Marcus_H project were unexpanded.

project       # number of packages  #    old code # new code
home:Marcus_H                   66        51.135s    10.653s
d:l:r:e                       1245     7:07.07min    17.804s

(the numbers for the devel:languages:ruby:extensions (d:l:r:e) project
were kindly provided by darix – thanks!).

Technically, we just reduced the number of http requests for packages
that are already up to date by using the backend’s getprojectsourceinfo
call (/source/project?view=info&package=pkg_1…&package=pkg_n).
Note: currently, such a reduction is not possible for packages that have
a _service file, because a small change in the backend is needed (see [1]).
Consequently, there are no time improvements for such packages.

If you want to test the new code, use the osc package from the
devel:tools:scm repo (http://download.opensuse.org/repositories/devel:/tools:/scm/).
Feedback is always welcome!

Next, my plan is to improve the speed of an update of a single package
working copy (again by reducing the number of http requests).

[1] http://lists.opensuse.org/opensuse-buildservice/2014-06/msg00067.html

Because of its endless awesomeness, I'm running an ownCloud instance on my server at home.
What I'm actually using of it is the WebDAV frontend to up/download stuff from Android (the native ownCloud App seems to have problems with really big files, such as several hundred MB) and the "instant upload" feature for the android camera, to automatically upload photos for easy reusing on the PC.

Today I wanted to configure some stuff and found out that I had totally forgotten the admin password, simply because I never needed it after the initial setup.

Modern applications no longer just store the passwords in the database, so it's not as simple as it could be. Additional problems arise from the fact that I have basically zero database knowledge.
Fortunately, I still knew that I'm using a mariadb on the server...

So that's what I did to restore admin access:

• cat config/config.php, note values of "dbuser" and "dbpassword"
• mysql -u <dbuser> -p;
• paste <dbpassword>
• show databases;
• note that there is a database called "owncloud", which is probably the one I need...
• use owncloud;
• select * from oc_users;
• Oh! My admin user is called "root", not "admin" as I would have guessed... Important information. So I try to use the password reset from the web form for user "root", however, it does not work...
• select * from oc_preferences;
• Oh! "root" has no email address configured, no wonder the password reset does not work.
• After some searching, I found the way to the solution in the ownCloud forum:
• INSERT INTO `oc_preferences` ( `userid` , `appid` , `configkey` , `configvalue` ) VALUES ( 'root','settings','email','root@localhost' );

Its been almost a fortnight I guess without a blog post, so continuing with the series, I have a couple of updates.

From tomorrow, Google Summer of Code Student Evaluations will start tomorrow on wards, so all the best to all the students who have worked hard over the summer and helped open source organizations grow. An extra applause for the mentors who have really worked hard over the summers and have contributed their personal time to get these students involved. Specifically, from an openSUSE point of view, I hope everyone passes these evaluations.

Apart from these things, I have also hit a couple of realizations over the past fortnight,

• I have gone worse in programming, something that I intend to improve upon in the next six months
• I waste a lot of time, I really need to optimize time so that I can work much more efficiently.

And then as news, humblefool one of India’s top programmers died of a car crash. There is an excellent eulogy written by Animesh on quora, I urge you to read it and take inspiration from it.

 

 

After some LDAP-related experimentation I was unable to log in to my workstation, which uses sssd to implement a setup where the users are identified by LDAP and authenticated by Kerberos.

In the log (/var/log/messages) I was seeing messages like these:

login: FAILED LOGIN SESSION FROM tty3 FOR smithfarm, System error
pam_sss(login:auth): received for user smithfarm: 4 (System error)
pam_sss(xdm:auth): received for user smithfarm: 4 (System error)
sshd[6004]: error: PAM: System error for smithfarm from ws.farm.cz

This was mysterious. Since I knew it was Kerberos-related, I raised the debug level in the Kerberos section of the sssd configuration file /etc/sssd/sssd.conf:

[domain/default]
debug_level = 0x07F0
enumerate = false
id_provider = ldap
...

After restarting sssd and trying to login again, the sssd log file (/var/log/sssd/sssd_default.log on my system) had something interesting to say:

(Tue Jun 17 10:56:22 2014) [sssd[be[default]]] [cc_residual_is_used] (0x0200): Cache file [/tmp/krb5cc_17006_M5
1GxZ] does not exist, it will be recreated
(Tue Jun 17 10:56:22 2014) [sssd[be[default]]] [check_old_ccache] (0x0400): Saved ccache FILE:/tmp/krb5cc_17006
_M51GxZ doesn't exist.
(Tue Jun 17 10:56:22 2014) [sssd[be[default]]] [krb5_auth_send] (0x0200): Ignoring ccache attribute [FILE:/tmp/
krb5cc_17006_M51GxZ], because it doesn't exist.

17006 is the uid I always get when I login via LDAP/Kerberos. So I tried the following command:

# rm -rf /tmp/krb5cc_17006*

Then after restarting sssd I was able to log in.