Diego Petten

My hopes to have a smooth transition seems to be vain.
A part a linking problem (basically, you upgrade glib2, everything breaks, whooh!), gnome-vfs 2.11 has other problems a part the ones already spotted in 2.10, I'm trying to see if I'm able to provide patches to upstream in time for the codefreeze but it's planned in three days and it takes time to test the patches...

I hope that next gnome release can be tested more on Gentoo/FreeBSD, as seems like ports simply doesn't tests the prereleases, not just of gnome but of quite everything.

By the way, about the big sys-freebsd move, remember to run scripts/move.sh script to fix your system.. it's really really really important!

It should have been, eh.. another hack that GLIBC has but it's transparent on FreeBSD... ok let summarize for who doesn't know.
On 32-bit systems (the ones that used to be the most common, like x86 and ppc, and spac32), you can open a file just if it's smaller than 2GiB, that because the offset in the file is represented by a long, so it's 32-bit and so maxes out at 2GiB. To avoid this, there's the "largefile" support, that should break binary compatibility but let opening files bigger than 2GiB.
Today is quite usual yo have files bigger than 2GiB... we have DVDs of (about) 4GiB and HDDs up to 320GB, so largefile support is logically enabled quite everywhere, but .. glibc doesn't enable it by default, as FreeBSD does.

The result is that programs must enable it by themselves defining _FILE_OFFSET_BITS=64, usually calling AC_SYS_LARGEFILE in a configure.ac script to let the configure find out what is needed.
Unfortunately, not all the programs do this, and also when they do, there are cases that makes them broken anyway.

amne yesterday made me notice that flac, lame and oggenc doesn't use largefile.. and this is bad. flac is now fixed, I just needed to add AC_SYS_LARGEFILE call and a little hack to make sure that config.h is included everywhere. lame is fixed, too, also if it made me wondering for a bit because the call was already there, and the config.h was already included... it turned out that lame was using a custom config.h.in without adding largefile definitions. From lame to toolame, the step was great... the latter doesn't use autoconf, so I just worked that around appending flags in the ebuild.

Also, alsa-utils, that was already worked around in 1.0.9-r1, have now a proper fix for 1.0.10_rc1 (yeah I added all the 1.0.10_rc1 ebuilds yesterday, hardmasked for now), that I sent upstream and I hope it will be fixed for next version.

This is going to be a long day, a long day for sure.

... it started!
The problem was wrong permissions on /var/tmp, so I prepared a new freebsd-baselayout that takes care of fixing /tmp and /var/tmp permissions to be safe.

Note: you cannot just emerge gnome right now, until bug #103124 is closed or I'll get around adding all the ebuilds to the overlay... that would require a bit of time.

Tomorrow is time of Gnome 2.11.. I hope it will work!

All following cshields's entry, being 0-talented with graphics, and not wanting to bother the (two) graphics-skilled people I know...

Proudly done with Krita, you can then see my face (as the GWN carried a photo from my back :P)...

Ok stop screaming, stop running away, it's small... no I'm not going to kill you or anybody else. No need to take the pitchforks...
Please don't stop reading Planet for this...

Ok a status update for my work on Gnome run on Gentoo/FreeBSD.
I was finally able to get to the end of emerge gnome process (actually skipping a few things like evolution and cdparanoia). Unfortunately this doesn't work. Black screen on start, gnome-session seems to freeze. I'll trace that down later.

I must say that Gnome upstream devs are quite responsive, and I want to thanks the ones that looked at my patches on gnome's bugzilla to make gnome packages compiling on FreeBSD.
As soon as I have Gnome 2.10 working, I'll move to 2.11 hoping to be able to see if the beta works fine out of the box, so that 2.12 won't need a complete re-patching of everything again (thing that seems quite normal for ports).

By the way I want to thanks egore (on #gentoo-bsd) for the box he's donating :). As soon as I'll have it here and working, I'll start the parallel work on Gentoo/FreeBSD 6.

Now I'm thinking about doing sys-freebsd category (on overlay for now) a reality, as we are gaining users, and sooner is fixed, the better.

Oh for who wants to hear something about the big syntax bugs (enewuser called with /bin/false as shell, cp -a and chown root:root .... This is going to be the record of bigger bugs, and many devs are going to hate me forever :P
But at least now we're getting a bit of attention about these topics that I already tried to show on gentoo-dev time ago :)

Ok I know I'm being quite an ass for posting so much blog entries in a short time, but I had part of them already in mind in the last days and I just hadn't had time to actually write them.

This entry has a title that would probably be misleading at the end as I'm going to summarize a couple of things here...

Starting from the topic in the title, I'm really loving UTF-8 these days. With the surname I have ("Petten

Quilt a tool from package maintainers for package maintainers. Tony Vroom told me of it two days ago on #gentoo-dev, and I started using it right after having read a short introduction by one of the authors, Andreas Gr

As most of you already know I'm not exactly a GNOME fanatic, rather, I at least used to be a KDE developer (only extragear, and lately I haven't had time to work on anything KDE-related). Unfortunately as now I'm the Deputy Lead of Gentoo/BSD project (thanks Stephen, Seemant and Grant for this opportunity), I can't just say "GNOME is not my stuff" and I started looking to have it working on Gentoo/FreeBSD.

The first problem was with glib itself, as there were problems with threading, so I took some patches from FreeBSD's ports and now *should* be working fine, at least on my system, until this is committed on official portage tree.

What stopped me quite immediatly was a problem with docbook-related stuff, that today - thanks to Riccardo "mala" from VElug who helped me tracking down files on his Gentoo system that had already GNOME installed - turned out to be an error in the sgml-catalog eclass (it use seq command, that's not available on BSD userlands, while is available on GNU and Darwin userlands). Unfortunately the error was quite criptic, and I had problems trying to check it on my machine as opensp emerge process ICEd out (systematically, so it's not a problem with my machine, but probably with the code and GCC4).
Now that is solved on my local tree and I filed bugs for the SGML-related ebuilds to fix this problem and an ebuild that was using cp -a (thus breaking on BSD userland).

Then the turn was of the most stupid bug I could find, but a quite annoying one, with scrollkeeper. But we need a bit of history for this.
The nls useflag is usually expanded in --enable or --disable-nls parameter to configure, that are managed by gettext M4 library to enable or disable i18n support in applications. GNU libc (glibc) provides gettext functions inside libc, while on BSD and Darwin you must use libintl to have them, linking to it explicitely; Gettext takes care of defining LTLIBINTL variable when --enable-nls (the default) is passed. Software should then disable NLS support checking for ENABLE_NLS preprocessor macro on config.h file generated by configure, but ....
But on Linux systems you usually use glibc, so you don't see errors while using the gettext functions with --disable-nls, as they are in the libc as we said; instead on a FreeBSD system, the package fails to link because of unsatisfied references to libintl_* functions.
This was what happened to scrollkeeper. What really surprised me is that scrollkeeper is not exactly a mostly-unused program, it's present on FreeBSD ports (who just forced --enable-nls) and it's released quite often. There was bug #4071 that reported problems while building with -nls, but that was worked around with touch of a false empty header. Also if -nls was asked, scrollkeeper always built with nls support.
I've patched scrollkeeper and posted the patch upstream, I've opened a but to get it in portage (as it's required for Gentoo/FreeBSD to work well). When that will be done, if you want to get rid of nls on scrollkeeper, rebuild it, and it will be ok. While this seems to be a minimal overload as glibc still get linked, there's a little slowdown when starting an NLS-enabled program, as it has to load the locale data.. and scrollkeeper is run by many GNOME-related ebuilds... so maybe this can affect slighly users...

For who wants to see when GNOME will work out of the box on Gentoo/FreeBSD, there's a tracker bug #103124, where I'm adding all the bugs that breaks GNOME on Gentoo/FreeBSD. The key of this process is "push upstream" as usual, I also registered to GNOME Bugzilla to submit patches when needed, as was for ORBit (that's now fixed upstream).

On a side note: I always hear people saying that KDE takes an hell of time to build completely and so on... while it's true that qt and kdelibs takes a lot of time to build, I'd like to say a couple of things about this on my first gnome emerge that's running on Gentoo/FreeBSD.
First of all, KDE library deps are a bit less invasive... I got pango or some other library changing its soversion lately on the G/FBSD box and I had to rebuild the entire XFCE4 (that was already installed), while only minimal breakage came up on the Linux box with KDE. That's not good.
Second, while QT and kdelibs are slow to compile, "emerge gnome" requires me to build Mozilla... and this has a big disadvantage: you need to rebuild it every time a security problem is found, and this is not exactly a "2 minutes" compile...

Ok another blog entry caused by a bug report.. this time bug #102843's reporter is safe, to be honest, he was quite friendly...

What really pissed me off is Carsten telling me to use shared libraries. Carsten I don't want to rant about you, it's just that I know the problem of internal libraries, and I'm doing all the reasonable steps to avoid them. If you really want to talk about them, take gstreamer and mplayer, and let their maintainers to disagree with upstream and use external libraries....

I know that usually shared external libs are *better* than internal libs. One central way to fix bugs, no need to rebuild the user project when something changes, no code redundancy and so on. I was the one pushing for external ffmpeg in xine (that now is no more possible as we need a newer ffmpeg snapshot, I hope to re-add ffmpeg useflag for 1.1.0-r2), I was the one (before being a dev) that tried to use external libdvdnav with it (and that was an unfortunate choice, xine started crashing too often with DVDs), so I know that shared libs are preferable.

In particular, about mad and a52, I wrote the patches to enable external libraries based on changes done on FreeBSD's ports.. I though of doing a slow migration from internal library to external, seeing if it was working well. It's not something that you can simply say "Damn you, use the external library!", as libdvdnav case shown.
Also external ffmpeg had slight problems, for example it took priority on wmv3 decoding over win32codecs, but this was easily solvable.

Although xine's upstream is way friendlier than mplayer's, our package is not exactly "vanilla": my configure.ac patch is 13KB worth of patches, plus 6.3K from PIC/__PIC__ changes and now another 7.4K of external libraries. I can't forward bugs directly to upstream because of that, so I refrain from changing things "on the fly" just because someone say that to me.. I must manage the bugs by myself, at least until the changes are backported upstream, and also then, the external libs makes me unable to tell "the problem is xine's"...

So, I'm sorry, but the next time someone will tell me to use external libraries somewhere, it will just be ignored without answer, I know we should use them, but such a change is never trivial.

At the end, remember to enable mad support if you want be able to play single mp3 files, FFMPEG is able to decode audio tracks in video files but seems unable to play single mp3 files right now. If you want to watch DVD is also the case that you enable a52 and dts useflags. If you don't have a DVD reader, you can safely disable dts, although it's not always the case to disable a52 (there are divx/video files that uses a52 audio encoding, but I think nobody is using dts as it requires proprietary codecs that doesn't seems to be available at all).

Now I just need to find how to avoid the plugins to link to freetype and similar libraries ...

Okay, lately I thought as I was being a bit "stuck" on my usual programming languages, C, C++, Python, ...
Discarded Java as one alternative for me, I though I should have started learning a new language. My choice got to Ruby.. a bit because I heard a lot of good impressions about it, a bit because I know it has good Qt/KDE bindings.

So I started one of the things I planned some time ago but wasn't going to do at all.. as Ruby is good at strings parsing, I'm trying to get a little analyzer to find out the ebuilds that uses features not compatible with Gentoo/FreeBSD.

Unfortunately, also if it started good, I'm now stuck during ebuild parsing as I don't really know how to get a good way to search for such cases and report them.
Oh well, at least I started learning how Ruby works.

Now, the syntax is almost as messy as perl's (that I don't like at all), but being object oriented makes it more interesting for me. The string parsing is really lovely, but I found a couple of regexp able to crash ruby interpreter, and at one time it tried an illegal operation, too.
I think I'll try in the next days to improve my knowledge of it to get to a point where I could make use of it in case I need it.

I also though of rewriting flamebot (that you find on #gentoo-dev and other #gentoo channels on freenode as ServoFlame, the backup bot in case jeeves and GenBot takes holiday :)), and I found rbot project as a framework for IRC bots, but.. FlameBot started as something scratchy, I wrote it on a couple of days when I wasn't in the mood of doing anything, and it does its work (parsing bugzilla's reports and so on), I think I'll just add a couple more things (like being able to intercept urls for *certain* bugzillas -- useful to display data from KDE or GNOME or FreeDesktop's bugzillas but not for Gentoo's as there's already GenBot doing so -- or being able to show the supported bugzillas).

Oh by the way, my personal life is more or less getting more stable, although it seems strange also to me ;)

Ok today is Monday, and as usual, Mondays are more evil than me...

I woke up, good day, the last night it rained and there was a thunderstorm, something that makes me actually happy. My personal life is not so bad, too, lately, so I was in the right mood to do a bit of work.
As usual turned on the monitor, the amplifier, enabled the front speakers (the only speakers right now), and started amaroK (I love the multimedia keys on the keyboard). New mails, new RSS news from akregator, de-awayed on Konversation and started looking.. "oh wow, a new amaroK version", from KDE-Apps, time for a bump ..
So I take time to wake me up, and then fire up a Konsole to rename the ebuild and compile amaroK ...

Strike one!

Ok I was still downloading amaroK (that wasn't released too much time before, so it wasn't on many SF mirrors, and kent's mirror is quite slow) and bug #102581 get assigned to KDE.. ok.
Completed download, completed emerge, started amarok, tested that works, removed betas' ebuilds, committed, bug closed.

Everything is fine till after lunch...

Strike two!

Bug #102592 is filled and assigned to sound, closed with a dry comment as dupe of the first one. Did the reporter search for opened bugs? amaroK's ebuild should have already hit mirrors at this time, but well..

Everything is fine, I'm here wondering if I should start studying ruby when...

Strike out!

Patrick tells me to look at bug #102600.
Now, I can understand people wanting amaroK in portage as soon as possible. I can somewhat understand filing a bug as soon as it's out and wait for response. What I cannot understand is *not looking for previous bugs*.

And really how can you say "almost a day", when the RSS Feed of KDE-Apps is dated during the night (UTC/CEST), and the announce on kde-extra-gear mailing list is dated 10 hours later, too?
I don't really think any other distribution was able to carry out an amaroK package in less time (well no, maybe they could if they have an american maintainer, that could have been awake when it was released).

Anyway, I think is good to remember this to users: Gentoo's maintainers usually knows when their packages' are released; if they are KDE maintainers, they probably have KDE-Apps subscribed; in any case, please don't fill 0days bugs, if you don't know that the maintainer is a dev who use to not bump packages at all. amaroK is maintained by kde and sound, I'm in the latter (and help on the first), I'm subscribed to KDE-Apps and to kde-extra-gear mailing list (because I maintain KNetLoad on KEG), when amaroK is released, I usually know. Please please please *wait* before submitting bugs.. please.

A couple of days ago I was asked by brix if I was going to EuroBSDCon 2005. Unfortunately the answer is a safe 'no' :/

While Switzerland is not so far as destination (from Italy), and also if the conference is a bit near to my birthday (28 November) so it would have been a bit strange going away in that time frame (mainly because of habits), I really wanted to go.

Unfortunately the problem is another one: Italian Linux Society scheduled the Italian Linux Day 2005 on 26 November.. and I really think I'd be more helpful here than on EuroBSDCon.

Well if somebody is interested, on 26 November I'll be on VELug's LinuxDay, somewhere in Venice (in-land, I hope, but there's no clue right now on where to prepare it so...). If you are around here and want to know me (yeah I don't think this will happen, eh? :P) I'm usually at VELug's meetings.

New update on Gentoo/FreeBSD status: the first important news is that we have a sys-apps/freebsd-rescue now, that populates the /rescue directory as in a vanilla FreeBSD!
I had to hack it a bit but now works fine. remember that nis and atm needs to be enabled also for other part of the system or they'll kill you :)

FWIW, now libarchive installs a dynamic library, too, this should simplify the upgrade process in the future.

About Java, instead, after my yesterday rant, I started looking at what we can do and I found patches for FreeBSD support with the source build of Sun's JDK. This ebuild was gone out of the tree some time ago and Java herd confirmed that working with them is a no-go as they have a bad viral license that nobody wants to deal with.

Following Betelgeuse and compnerd suggestions, I'm waiting for gcj to be able to build openoffice and I'm going to try kaffe as java provider for Gentoo/FreeBSD users. The problem with disabling Java support entirely is that OpenOffice for example requires it and for an user-oriented FreeBSD distribution it's not so good not having OpenOffice at all :/

Regards the profiles, instead, I did a big cleanup of all of the ones in the overlay. I removed the old artifacts due to the overlay nature of g/fbsd 5.3, and I've merged most of the 5.4 data into the fbsd parent profile to be shared with the future 6.0.
I've removed the provided packages, all the packages that tries to install one of the Linux-specific packages have broken depends and instead of being fooled needs to be fixed. You'll find a couple of ebuilds on the overlay to avoid having errors for packages such as xorg with depends on util-linux and so on. The patches for all them are on bugzilla but are not merged in tree for now, as soon as they are merged the ebuilds in overlay are going to fade away.

Already someone wrote about the Java Trap, but what I'm going to say here is not about the trap, but about the crap.

It's my own, personal opinion about Java and why it should always be avoided when possible, as usual it has nothing to do with Gentoo, it's just me, got that?

First of all, I must to say I love OOP, C++ is my main language if I want to write something complex, but Java is too much cruft for me. I don't like the syntax, the missing features such as operators' overloading and the partial inheritance. And I don't like the speed decrease that it adds to your program.

Now, this decrease was always advertised as a derived problem due to the platform independence of Java: you write and compile it once, and you run it everywhere... Yeah sure, keep on trying...
Let face the reality: a good written C or C++ program is more multiplatform than Java, if you write it with QT or even GTK+ it will be more portable than something in Java.

The first problem is that quite every Java software out there requires Sun's version of Java, and this means that you are limited to one implementation, which is released just for a few systems: Sun's Solaris, obviously, Linux i386 and amd64, Windows, OSX. There are a few other implementation such as blackdown and ibm that covers ppc and ppc64 machines and IBM's operating systems, but this is still limited: there is no Java version native for FreeBSD for example, and you need to build it using unofficial patches.

Also, recent programs started using SWT for the GUI, that binds itself to a native GUI framework such as GTK+, thus requiring access to native libraries to do the work. This means that you don't have anymore a "no need for native libraries" program, because it really requires them anyway... it's simpler to just use GTK, isn't it?

As final note, the "it's java, it's in a sandbox, it won't kill your system" assert is no more valid: using native libraries (such as SWT) let java get outside the sandbox, and SWT is enough to do so. Azureus, for example, can kill your system eating CPU continously, as it goes out of the sandbox.

Be nice, don't let anyone fall over the java crap, it smells bad :)

Yesterday I felt a bit useless, so I started working on some minor problems on Gentoo/FreeBSD. One of them was revdep-rebuild not working (that now is going to be fixed as with a couple of changes is fixed) and the missing libGL.so.1.
While the first problem was easy to resolve, the second is a bit more complex: libGL.so.1 links to libGL.so.1.2... that doesn't exists at all on xorg-x11 as installed on G/FBSD. I'll wait for modular X to compile on G/FBSD and then I'll try to fix that if the problem is not getting fixed by itself.
To resolve it for me (and Alberto who asked me for it), I though of hacking a bit on nVidia drivers, as there are drivers for FreeBSD, too.

The result of this is a modified nvidia-glx that works on Linux and FreeBSD without problems, and an nvidia-freebsd ebuild for the kernel-level driver. At this point if you want OpenGL acceleration on Gentoo/FreeBSD with a nVidia card, you just need to do this (make sure you have an enough up-to-date overlay):

emerge nvidia-glx
echo 'agp_load="NO"' > /boot/loader.conf


so that it will install both the kernel driver and the Xorg drivers, extensions and the rest (note: linux emulation support is still unsupported right now, as for everything), and then disable loading FreeBSD's AGP support (nVidia suggest to use their implementation on FreeBSD, so the driver is built without FreeBSd's AGP support... I'll add an useflag later to enable FreeBSD's AGP support in case).
Reboot and you'll have OpenGL acceleration.

Ok as QEmu seems to work better now with kqemu on AMD64, so I'm working on Gentoo/FreeBSD for AMD64. Unfortunately seems like there's something not really good with it.

The first problem is that openssl needed a patch to compile, and also if it compiles it fails tests (SpanKY say the problem can be with the compiler, and as I'm using FreeBSD's gcc, the problem is very likely). I need to complete the build so I disabled tests at all and I'll wait to have a gentooified toolchain before going on with the tests.
The other problem is with libstand in freebsd-lib, that doesn't seem to compile, linker complain about an invalid BFD, and I noticed it passes -m32 to GCC. This means that AMD64 profile must be forced with multilib on, but I don't know how to do that right now :/ also because it doesn't seem to compile freebsd-lib two times, so I just need gcc (and ld) to compile for 32-bit target.

Other than that, I started working on freebsd-rescue ebuild for G/FBSD x86, a static version of the base system's utilities.. unfortunately it doesn't like my libarchive and says that it can't find zlib's functions, while zlib is present in the link commandline :/

Also, I need help from someone who knows GLIB/GTK/Gnome internals as there are too many things that needs to be fixed and that FreeBSD's maintainer seems to not send upstream.
It's also bad seeing that FreeBSD's ports are currently frozen for 6.0 ongoing release, as it could have been interesting to see what was going to happen with xine stuff.

Remember: patch your upstream!

Ok as I already said, for Gentoo/FreeBSD I need another machine to work with 6.0-BETAs as 5.4 is still the main supported version for now. As I don't have another one, I've just added a mobile disk rack to that one and moved the old 20G drive in one of the racks, where I already had a 40G disk. I haven't moved the stuff yet, but when I'll feel like doing it I can build a 6.0-BETA version of Gentoo/FreeBSD there.

On the other hand, thanks to Luca I have a working 64-bit QEMU using the accelerator, and I'm trying to get Gentoo/FreeBSD there to prepare the first amd64 profile. Unfortunately the 5.4-RELEASE FreeBSD doesn't support the ed network driver that is the one for the nic emulated by QEMU. To work around this I've hacked the kernel using more recent versions of the ed driver's sources, so to let it compile on amd64 fine. Unfortunately it was my first attempt to change FreeBSD kernel and was quite a pain initially... now I found how to build just a single module, and it's way faster than building the entire kernel :)

I don't think I'll be able to work on many different version of Gentoo/FreeBSD, as I don't really have enough machines.. a couple of x86 could help but I don't really have the way to buy them right now... but the future is unpredictable, who knows if tomorrow I'll have an entire rack of x86 machines to work with? Or if the most beautiful girl on the world (who I know, I can ensure you all) will start considering me something more than a friend?
Ok both the above statements are clearly impossible, and if I had just one wish to express, I'll go on the latter for sure.. but I'll try to do the best for Gentoo/FreeBSD at least, as the other is really impossible.

First of all, I want to thank Patrick for the developer of the week :)

Then, FreeBSD announced 6.0-BETA2 release... this means that we should be moving to that with G/FBSD, too, but it's not the case for now. At least not for me. The reason is simple: I don't have another machine to work with, and I need a 5.4 at hand.
I'm actually thinking of mounting on defiant the rack disk support and use a spare 40GB hdd as "second machine".

About pmake, it seems to being a bit of a problem right now, mainly because it doesn't seem to accept $S as a good variable name...and this behavior is shared by gmake. I'm unsure on what to do about this, pmake code is cleaner than bsdmake and it's otherwise completely compatible, so I think I'll just sed-out all the broken makefiles if I'm able to come up with a good rule.
In the mean time, I'll just change pmake to not install itself as 'make' and re-add make to freebsd-ubin.

One of the most fiery opinion about FreeBSD is that BSD tools are usually difficult to use interactively... that's true: BSD commands are more strict than the GNU equivalents, but this is not a problem in scripts (mostly).
While Gentoo/FreeBSD wants to be as far as possible FreeBSD-like, I'm thinking of a quick hack that could help bypassing this problem.

Mainly, the difficulty of BSD tools is the fact that they accept options just and only in the right order: you can't do "mkdir /some/strange/dir -p" as -p is *after* the name of the directory to create. But this happens only when running the commands from a shell. While we already have bash shell instead of tcsh (that I can't really stand), we can't install GNU utils right now..

The problem is not compiling them, as they should be portable enough to work fine on non-GNU libcs, but is with the name, they must g-prefixed to be installable there, and this makes them useless for most people.

What I have in mind now is this: let coreutils and the other *utils install with g-prefix on non-GNU userland... then, add an ebuild 'userland-gnu' that depends on all GNU's tools, and then creates symlinks between the g-prefixed tools in /usr/bin, to something like /usr/libexec/gnu... add that to your user's path and you'll be using gnu tools instead of FreeBSD's ones :)
Such a thing should *never* be done on root, tho.

I think i'll start this later, it's really really interesting, imho, to get a better user-friendly FreeBSD distribution...

I know this is going to be a flamebait, but for this time I'll try to be as objective as possible. You all know that I started having KDE working on Gentoo/FreeBSD before any other window manager, but that was just because I use it and I feel comfortable with it.
Now it's time to get everything working on Gentoo/FreeBSD, but there are a couple of problems.

First of all, we do have too much GTK1.2 stuff in portage, and it's really really hard to make 1.2 work as there are lot of changes needed, and upstream is now dead. Also, it's not possible to just use.mask "gtk", and force G/FBSD users to use just GTK 2 (not that this is immune to problems, see later), as "gtk" useflag can enable gtk2 support if it's the only GTK support a program provide, while "gtk2" useflag must be used with "gtk" flag, too. Also if this could seem absurd (why limiting Gentoo/FreeBSD while ports provides both 1.2 and 2 support), it's an interesting experiment, as there are just too many GTK1.2 packages that just don't work as they should and are dead upstream. GTK2 packages like beep media player are replacing old GTK1's like xmms.

About GTK2, it's true that the situation is surely better (as upstream is alive and kicking), but there are tons of patches in Ports that was never merged (probably never submitted upstream) and I can't really stand all of them because I just really don't know GTK2 and I have no contact with upstream to ask them to merge the patches.
At this point, I'd really like some help from a gnome herd dev to join Gentoo/FreeBSD and start looking at the patches to merge :)

From another side, I really want to thank Alberto Zennaro for the help with amaroK testing, that now works fine. If anyone tried it and it was crashing, the problem was that libtunepimp linked to libthr for threading support, but amaroK used libpthread, and the result was a not-good-at-all crash.