I used fresh install of slackware-13.1.
Well yes - by bittorrent. Anyway - don't bother with downloading. Here's the filelist:

Attached Files

amarok_tree.txt (58.0 KB, 21 views)

Problem partially solved. I was puzzled why every other package built completely but not Amarok. I kept comparing the compile results in 12.2 and 13.1. Something kept telling me the makefiles were not building correctly in 13.1. Finally I remembered I had a one-line sed patch directly in the build script to fix the broken sym links in the HTML help files. For whatever reason that one-liner worked in 12.2 but not in 13.1. Perhaps some subtle difference between the versions of the autotools.

Now the package builds with a complete file tree. Yet when I start Amarok I get a segmentation fault error and the app fails to run.

Aren't you just patching to hard?

I'm running the same patches as you.

What about that "one-line sed patch"? Didn't you make any other changes? Did you try compiling on fresh slackware install?

Sigh. Looks like this was a pebkac error.

The one-liner problem was real. Commenting out that patch allowed amarok to compile completely.

The segfault problem was me.

I have two 13.1 systems installed on my hard drives. One contains the build system and the other is where I methodically install and test the new packages. The 13.1 system with the chroot build environment uses the KDE 3.5.10 packages from 12.2. The chroot environment contains KDE packages built for 13.1. I was trying to run the new amarok package in the non-chroot environment. That is, I was trying to run the new amarok package in the wrong KDE environment. Hence, no wonder I saw the segfault error.

The new amarok package works just fine in the testing environment.

I'm posting this message from 13.1 with all the newly built KDE packages.

Not a total waste of time. I learned a wee bit about using gdb.

I'm still seeing these errors:

libpng warning: Application was compiled with png.h from libpng-1.4.3
libpng warning: Application is running with png.c from libpng-1.2.44
libpng error: Incompatible libpng version in application and library

I don't see the KWikDisk icon in the system tray. Likely related to the libpng errors.

Edit: Some housecleaning and reinstalling a few packages seems to have solved the libpng error messages.

Anybody notice that superkaramba doesn't compile in kdeutils? I tried patching to no avail.

Here's a universal patch for kdeutils and kdebindings. It fixes Python-2.6 and automake-1.11 recognition by configure script, and fixes building with newer automake.
This fixes the superkaramba and python bindings problem.

To compile kdeutils I had to remove kdeutils_ark_xz_lmza_support.diff
Have fun.

Attached Files

python_and_automake.patch.txt (2.0 KB, 13 views)

I will test the patch.

I discovered another bug. In KMail, when I compose an email and then select the Send button, the entire app evaporates. A solid crash. Oddly, the email gets placed into the Out box, so the crash occurs somewhere thereafter. I would be grateful if somebody would verify the bug.

Correction: Seems that any option with the compose window causes kmail to crash and disappear. Save as draft, send later, etc., doesn't matter, boom. Gone. KMail acts as if opened with the "kmail --compose" option. The compose window closes and that's the end.

A note about the python/automake patch: should be applied to almost all packages. I noticed the Trinity packages all have that patch, not just kdebindings and kdeutils. I will be updating my build set accordingly.

Yes, you can patch all the packages, but only kdebindings and kdeutils use python. Also it broke compilation of kdebase (if used with ksmserver patch).

Unsure then why Trinity has all the packages patched that way.

Do you use KMail? Still can't find the problem with the app closing.

I'm working on both issues. Do you know if ksmserver-3.5.9-ksmserver_suspend.diff is merged with trinity source code?

Me too. I ran a gdb trace and saw the following:

Program received signal SIGSEGV, Segmentation fault.
0xb6491dc3 in DCOPObject::~DCOPObject() () from /usr/lib/libDCOP.so.4

libDCOP.so.4 is a sym link to libDCOP.so.4.2.0, which is installed by the kdelibs package.

I'm going to rebuild kdelibs with the python/automake patch. Who knows?

Yes. Merged.

Confirmed.