Like many other smart phones, the Samsung Galaxy S9000 has the annoying habit of playing a very loud sound on startup -- and another one on shutdown. It's hard to imagine anyone actually preferring this behaviour to what would be the most sensible: Quietness during either process.

To make the phone shut up, you can do this (provided you have rooted the phone already; note that we've go no tab-completion on the phone, so better cd to the respective directory before moving the files):

1. ssh to the phone
2. Remount the system partition as read-write:
   

   # mount -o remount,rw /dev/block/stl9 /system
   

3. Move the startup sound away:
   

   # cd /system/etc
   # mv PowerOn.wav PowerOn.wav.orig
   

4. Move the shutdown sound away:
   

   # cd ../media/audio/ui
   # mv shutdown.ogg shutdown.ogg.orig
   

5. Reboot.

You should not hear the sounds anymore.

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.

I recently found out that on one of my machines the entries in my KDE Application Launcher weren't at all in sync with the installed WINE applications. That hardly surprised me: The WINE installation is kept between OS upgrades (which are always clean installs) and thus tends to degrade more and more over time.

So I was looking for a way to re-create the entries in the KDE Application Launcher (which follows the freedesktop.org Menu Specification) from the installed WINE applications. After having cleaned up the WINE install dir in my home a little, I was ready to go. Of course, I did not want to manually create desktop files for each Start Menu entry present under WINE.

Turns out there's an automatic way WINE itself uses when an installer writes entries to the WINE Start Menu: It comes with a helper app called winemenubuilder.exe to convert .LNK files to .desktop files -- clean and simple.

So I ran this helper for each subdir in $WINEPREFIX/drive_c/windows/profiles/*/Startmenü (these directory names are localised and the WINEPREFIX on this machine dates back to a time when I was using a German locale):

$ wine winemenubuilder.exe [subdir]/*

Finally call kbuildsycoca4 to make sure the changes get propagated to the KDE4 system configurtion cache and that's all.

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
• Keep the current UUID when resizing a swap partition
• Fix the build by explicitly linking the partition manager executable against the KDE libs it uses
• Do not allow pasting a source partition on a bigger target partition when the source partition's file system cannot be grown to fill the target partition

The new release is available from the KDE Partition Manager page at SourceForge or from kde-apps.org. Binary packages are available if you cannot wait for your distribution to pick up version 1.0.3.

Of course, work on the next feature release, KDE Partition Manager 1.1, continues.