PlanetKDE

Status Update: KDE Partition Manager

Good things first: Using the KDE Partition Manager version from svn is safe.

There hasn't been any substantial development work being done on KDE Partition Manager for quite some time. This is indeed very deplorable and mostly owed to the fact that I am so far the only developer working on the project. The time I was able to devote to open source work has been severely limited over the last couple of months due to, as they say, circumstances beyond my control.

So the project has remained in a rather dormant state since my series of blog entries about the upcoming featurs in version 1.1 and the post about the new partition widget design that had been so magnificiently done by Hugo.

As an aside, this design has again been improved quite a bit after that post, so here's a current KDE Partition Manager screenshot (also, everyone likes screenshots):

KDE Partition Manager 1.0.60 screenshot

Meanwhile, the GNU Parted devs have released a new version of libparted, 3.0, that does away with its former support for resizing FAT-based file systems (and a few other special cases that libparted used to cover for historical reasons). This version is now the only one shipping with a few distributions, among them Gentoo.

In KDE's subversion, I have at one point last year actually added support for the new libparted 3.0 version to KDE Partition Manager (support being an euphemism for: remove FAT16 and FAT32 resizing and a few other things when building against libparted 3.0). Gentoo have then proceeded to ship (as much as Gentoo can be said to ship anything) an svn-snapshot of KDE Partition Manager that has the version number 1.0.60 (denominating it as an alpha release in KDE's version number scheme). Other distributions have followed or will probably do so in the near future.

Now using a subversion snapshot for an application that is supposed to perform potentially destructive actions on your important data sounds like an unwise choice, does it not?

To put it briefly: Version 1.0.60 is no more dangerous to your data than 1.0.3 is. The code involved performing the potentially hazardous actions is mature and thoroughly tested. There's no guarantee in either versions and there have indeed been modifications to code areas that deal with moving data within file systems for 1.0.60, but it's not like this has all been rewritten from scratch with totally unexplored code-paths now being let out into the wild sans any prior testing. The code works, is safe and I have used it numerous times myself on my disks, not just for testing.

Making backups before touching your file systems with any tool is still the diligent thing to do.

If and when KDE Partition Manager will see a 1.1 release is still not certain; I'm trying to figure out what I can do to accelerate matters a bit.

tl;dr Using KDE Partition Manager from subversion (with a version number of 1.0.60 or higher) is no more dangerous to your data than using 1.0.x.

Blog Moved From WordPress To Drupal

In an ongoing attempt to streamline and consolidate the multitude of technologies in use on my server I've moved this blog from WordPress (which I really liked) to Drupal (which is also great).

I hope I didn't break too many things in this process. One thing that apparantly hasn't gone 100% smoothly is the threading of comments: It appears all comments have made the transition ok, but the threading seems broken, at least in parts. Apologies for that to all who have commented in the past.

Let me know if anything else broke really badly.

Instant Crash Of Any Self-Built KDE Trunk Application

After upgrading, rebuilding and reinstalling the whole of my Qt/KDE devel installation last night I found any application I was trying to run to instantly segfault. It took my a moment to realise that even qt-only apps like qtconfig exhibited this behaviour:

$ gdb qtconfig
...
[Thread debugging using libthread_db enabled]
Qt: gdb: -nograb added to command-line options.
Use the -dograb option to enforce grabbing.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff41c8bf2 in QScopedPointer<QBrushData , QBrushDataPointerDeleter>::data (this=0x1)
at ../../include/QtCore/../../../../src/qt-kde/src/corelib/tools/qscopedpointer.h:135
135 return d;

The backtrace gives a first hint at what might have gone wrong:

(gdb) bt
#0 0x00007ffff41c8bf2 in QScopedPointer<QBrushData, QBrushDataPointerDeleter>::data (this=0x1)
at ../../include/QtCore/../../../../src/qt-kde/src/corelib/tools/qscopedpointer.h:135
#1 0x00007ffff41c8f2e in operator==<QBrushData, QBrushDataPointerDeleter> (lhs=..., rhs=...)
at ../../include/QtCore/../../../../src/qt-kde/src/corelib/tools/qscopedpointer.h:176
#2 0x00007ffff41c4e3d in QBrush::operator= (this=0x993678, b=...) at /home/kde-devel/dev/kde/trunk/src/qt-kde/src/gui/painting/qbrush.cpp:630
#3 0x00007fffed47b32d in KStatefulBrushPrivate::operator= (this=0x993678)
at /home/kde-devel/dev/kde/trunk/src/kdelibs/kdeui/colors/kcolorscheme.cpp:547
#4 0x00007fffed47aeec in KStatefulBrush::KStatefulBrush (this=0x993808, other=...)
at /home/kde-devel/dev/kde/trunk/src/kdelibs/kdeui/colors/kcolorscheme.cpp:609
#5 0x00007fffedacaf19 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#6 0x00007fffedacb044 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#7 0x00007fffedacb286 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#8 0x00007fffedadaaea in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#9 0x00007ffff40b68a9 in QWidget::event (this=0x8f8c90, event=0x7fffffffb500)
at /home/kde-devel/dev/kde/trunk/src/qt-kde/src/gui/kernel/qwidget.cpp:8286

Yes, some debug symbols missing, but still obvious something's trying to load the globally installed oxygen style here. Obviously not such a good idea.

Unfortunately it was not really obvious to me how that could happen:

$ echo $QT_PLUGIN_PATH
/home/kde-devel/kde/lib/kde4/plugins

This appears correct. So how else could the wrong path enter the picture here?

Strace to the rescue:

$ strace qtconfig
...
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat("/etc/xdg/Trolltech.conf", {st_mode=S_IFREG|0644, st_size=43, ...}) = 0
stat("/etc/xdg/Trolltech.conf", {st_mode=S_IFREG|0644, st_size=43, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat("/usr/lib/kde4/plugins/styles/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/kde4/plugins/styles", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8
statfs("/usr/lib/kde4/plugins/styles", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=8256988, f_bfree=5124408, f_bavail=4704978, f_files=2097152, f_ffree=1757544, f_fsid={-2007331828, 496054031}, f_namelen=255, f_frsize=4096}) = 0
getdents(8, /* 3 entries */, 32768) = 80
stat("/usr/lib/kde4/plugins/styles/..", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/lib/kde4/plugins/styles/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(8, /* 0 entries */, 32768) = 0
close(8) = 0
stat("/usr/lib/kde4/plugins/styles/oxygen.so", {st_mode=S_IFREG|0755, st_size=796192, ...}) = 0
stat("/usr/lib/kde4/plugins/styles/oxygen.so", {st_mode=S_IFREG|0755, st_size=796192, ...}) = 0
...

A-ha!
So what's the content of /etc/xdg/Trolltech.conf?

$ cat /etc/xdg/Trolltech.conf
[qt]
4.7\libraryPath=/usr/lib/kde4/plugins

That looks dangerous (and not just because it's using a backslash as a path separator...)

Quickly googling a bit for meaning or intention of this file reveals no definitive answer. XDG of course suggests some freedesktop.org connection, but that's not saying all that much, really.

Fortunately, the setting can easily be overwritten with a local config addition. After simply adding

4.7\libraryPath=/home/kde-devel/kde/lib/kde4/plugins

to the [Qt] section in the (already existing, in my case) file $HOME/.config/Trolltech.conf, the segfaults were gone.

Workout Imported Into KDE Repository

The Workout source code is now available for you to checkout and build from the KDE subversion repository. Like all new projects it has for now been imported into KDE's playground. It will soon move to KDE review and then, if the review goes well, to KDE extragear.

Until then, get it from here:

$ svn co svn://anonsvn.kde.org/home/kde/trunk/playground/edu/workout

Do not forget to set HAVE_KDE to 1 in your cmake command line when building the KDE version.

Release: KDE Partition Manager Live CD 1.0.3

Hard on the heels of the release of KDE Partition Manager 1.0.3 follows the new version of the KDE Partition Manager Live CD, now also featuring version 1.0.3.

Release: KDE Partition Manager 1.0.3

A new release in the stable branch of KDE Partition Manager is out. Version 1.0.3 brings minor fixes and improvements:

  • Make sure available and used capacity are not printed in a partition's properties dialog if they are not known
  • Make sure fsck.msdos does not want to modify a file system when it is being called to read the file system usage
  • Warn the user when trying to overwrite an existing partition with another or an image file
  • Clear the clipboard if undoing an operation deleted the partition that was in it

Workout on Windows

Over the last couple of days I've been experimenting with getting Workout to work on Windows. With the help of some tricks borrowed from the Marble and Quassel teams (and even, *blush*, lifting a few lines of code from the Quassel sources), I got it to work.

It's not 100% done (configuration does not yet work and neither does hardware discovery, which will require some extra effort on Windows due to the absence of Solid), but it's running and mostly working:

Workout: Integrated Map View

Playing around a bit with MarbleWidget and MarbleModel and fixing a few bugs in Workout's (Workout is an activity and sports tracking application I am currently working on) KML exporter to make the interface actually work got me this:

A Name Is A Name

As a followup to my post on finding a name for the until then unnamed sports and activity tracking application I have been writing I'd like to thank all commenters on the blog entry for their valuable input, their ideas and suggestions and of course for their kind words. It sure has been uplifting to read so much enthusiastic posts in response to an application that has not even been released yet.