So, seems like my system is now stuck in a rebuild loop :)

Two days ago KDE 3.5.2 was released for packagers, and thanks to danarmak who updated the split ebuilds, I started building it, so to spot possible problems with it before user release (and in particular I had to update KPDF's poppler patch,a s a one-line change in KPDF's configure.in.in made the patch unusable as it was, the new version now is for poppler 0.5.1 only).

After upgrading KDE (only one night!), I had to rebuild almost all of it as Thursday I bought a second monitor to help me while working on UML diagrams and code, or with debug and code (Samsung 730BF with DVI input, really nice, and more or less cheap ;) neat to combine with a Samsung 710V that's the other monitor I have), so I had to enable xinerama on the whole system to have it working, as I had it strictly disabled. I launched the rebuild overnight, but had a bit of troubles because of local ebuilds for kio_slp and kerry, and because of ktechlab not building because of a missing dependency in gpsim...

Also, last morning, after waking up quite earlier than usual -as I was waiting for a friend of mine to talk about a job- while working on the UML diagram with Umbrello, I found a problem with Xorg7 and kdelibs... basically in the colour chooser dialog, if you select the "Named Colors" category, it will tell you that it can't find rgb.txt, and that's right as it looks for it in the wrong place. I solved this by editing configure.in.in and adding a new parameter to ./configure: --with-rgbfile, now kdelibs 3.5.2 (and 3.5.1-r1) will pass that parameter when using x11-apps/rgb (that's a dependency OR-ed with virtual/x11), to fullfill the new position of the file. Too bad I didn't spot that problem before or I could have pushed it in KDE 3.5.2 release... the fix is already committed in SVN anyway. If you're upgrading from Xorg 6.8 to 7.0 modular, you'd have to rebuild kdelibs in order to get the new location working, I'm sorry but I can't make it better than this :(

Also seems like CIA stats were reset, all my projets are gone, and now only KDE and Gentoo figures (because I committed to both today).

Adding to the rebuild list, today exg bumped expat to version 2.0.0, that has ABI changes and gets a soname change between libexpat.so.0 to libexpat.so.1. Unfortunately expat links against lots of stuff, starting from fontconfig that's linked on by most of KDE and GNOME packages... and in usual conditions libexpat.so.0 ends up in almost all binaries, leading to an almost complete world rebuild...
Luckily for me, by using --as-needed most of the stuff was clear: I had to rebuild neon and subversion, hal, dbus (for one of the support programs, but the main dbus daemon and library were fine), and of course fontconfig, this one I did for first as after rebuilding that my KDE was stable again. Oh of course I had to rebuild the stuff that can't use --as-needed: wxGTK and users of it, like vlc and mkvtoolnix, but that's an unfortunate thing... I should probably try to investigate the problem in bfd and fix it sooner or later..

Okay, today Kopete developers released version 0.12_beta2, last beta before 0.12.0 final.
I have to say, it's a big improvement since 0.11 (KDE 3.5.1), but there are still quite a few unresolved issues.
The MSN file transfer issue is finally resolved, for the joy of many (me between them), the Adium styles support for chats works fine and is way faster than the old XSLT stuff, and also ICQ protocol is improved where it was a bit lost...
But the build system is still quit messy: there's no way to disable most of the plugins (yeah there's a bug in bugzilla with an hacked ebuild to do that, but no, I'm not going to do that just now, I tried contacting Matt Rogers (kopete's main dev) asking him if I can try to get a ./configure parameter to disable at least some of them but he never replied me.
Also, to enable Jiggle (GoogleTalk) support you still need a specific version of speex and ortp, that is not the last one and it's not slotted, so unless someone updates it to use last versions of them, it's unlikely that the support will be added to portage.

I don't have the physical time to work on this, too... if anyone wants to see GoogleTalk support or to disable plugins like the LaTeX one, then please try to fix the API issue and send the fixes to Kopete developers, or just ask Matt if he can reply to my mail and I can provide a few ./configure switches, or fix that yourself :P

So, also if I'm still feverish so on low profile on Gentoo, I got today some infos about a job that awaits me, that is going to be fine actually, as I really needed one right now :)

But if I can work on a single mental idea when I'm working on a relatively pointless project for myself, when I have to work for someone else I try to provide as much documentation of what I do and decide, for two main reasons: it's more professional and they can't tell me I never documented some design choice that they don't like :P
For this reason I always liked using UML when designing how stuff should work... the class diagram is useful when modelling data-centric stuff, the activity diagram is useful when modelling function-centric stuff. My current work is in the second category.

So an activity diagram is basically an old flow chart under steroids, no? It should be easy to draw one without even using specific UML tools, but I also think that CASE tools are created for a reason and should be used whenever possible, so that they can also be extended and completed... call me a visionary, I like to do the less work possible about what my job is, also if that ends up adding more work on something else.

So I excluded DIA, KChart and OpenOffice Draw for the diagram creation because they are not CASE tools properly told.. I decided to go with Umbrello, that should be a full-featured UML tool for KDE... Unfortunately, it's not that full featured it seems. The default 3.5.1 version has a big problem that made me unable to complete the diagram as I wanted: the "fork" widget wasn't allowing more than one outgoing association with an activity... wait but that's what forks are for, isn't it?

I found the problem in the source and I've fixed it right now, but it took me a while to understand the problem. Add to that the fact that Umbrello used to crash pretty often, and that its XMI files are incompatible with poseidonCE's ones (intersting tool, too bad it's closed source, proprietary, and not exactly cheap when you need to use it for work), and you know why I usually ended up working on my graphs with paper, pencil and a ruler...

Anyway, I'll see to hack at Umbrello a bit more now and tomorrow so maybe I can have it working for what I need and I can apply the fixes upstream.

Okay, today was a very bad day for me, and I'm sorry to all the people I treated badly on IRC, wasn't my intentions, just sometimes you're so tired that repeating the same thing as usual becomes a problem.

Just to say what happened, as that might be of interest, I spent two days rebuilding world because with last upgrade from gcc 4.1.0_pre20060227 to gcc 4.1.0 final stuff started crashing down, but that didn't solve, this morning when I returned to my desk I found konversation and kopete still crashing and that was annoying enough by itself. Add to that about 80 bugmails mostly caused by ffmpeg's update, plus another 17 comments just for the kpdf and poppler bug, and the fact that one of Level3's routers which carries data for my ISP to America seemed to be having problems, making unreachable to me both bugzilla and cvs, and you have a good situation of what I faced today.

Little note for people who wants to know what might annoy maintainers often: changing API in a non-compatible way in a micro release is something that people won't like that much....

Anyway, KPDF is fixed now, and builds with poppler 0.5.1. It took me a while because not only because I had the connection trouble, but also because I wanted to provide a true solution instead of a dirty hack.

Then, amaroK 1.4 beta2 was released, enjoy! :D I've bumped it in portage less than half an hour after official release as I was idling in #amarok at the time ;) My overlay also started carrying the rc1 version in mid afternoon, I didn't know portage now handles names like 1.4_beta2_rc1... that comes handy for these kind of releases ;)
I think there are a few changes in amaroK that are worth noticing, the first is that the GStreamer 0.8 engine is no more, and amaroK now supports only GStreamer 0.10, so if you're still using GStreamer 0.8 you have to stick with amaroK 1.3, then also arts engine is no more, and this has another side effect: we were installing amaroK in KDE's prefix to let aRTs find the plugins it was installing -and because of splash screen in 1.3, but that's already solved as it uses KDE's resources system now- so I did two versions of amaroK 1.4_beta2 ebuild... the first one is a "classic" one, that installs in KDE's prefix, the -r1 instead installs in /usr, without the hacks for moving around amaroK's .desktop and icon files. Please give it a try and report if there are troubles.

Another update instead for Kopete users: as the obnoxious bug with MSN filetransfer has now a resolution upstream, I've applied the patch to net-im/kopete-0.12_alpha-r1, kde-base/kopete-3.5.1-r1 and kde-base/kdenetwork-3.5.1-r1. I tried this with a friend and it works fine indeed :)

Oh a little end note for the people asking for rsibreak and katapult on x86. I'm on AMD64 arch team, and I only have an AMD64 at hand (well no, ok, I have the iBook that's actually not yet completely updated, but I never asked to be able to mark ~ppc and that wouldn't help either ;)), so for the ~x86 keywording you have to ask the x86 arch team by filing a bug asking for the keyword to be added. Please don't ask me, I can't do much about that.

I was lately thinking that the quantity of extra KDE applications in portage is really low. There are lots of tiny programs that might be of help to users, but for a reason or another they are not in portage.
Some of them can't be added in portage because they have problems: crashes, security issues, automagic dependencies; others simply because we have not enough man power to handle all of them, although most of them just requires a bump from time to time.

So what I'm doing? Well after adding RSIbreak yesterday, today I'm going to add Katapult 0.3.1.1. I wish to thank Mez for his help :)

Unfortunately the main problem is that these applications really needs to be checked and verified to be working with latest versions of KDE, so I can't just add things I'm not going to use. I've added RSIbreak because I'm trying to avoid remaining all the day long at the keyboard never stopping, and Katapult because Mez asked me (and I started using it, and it's quite interesting :) ), but most of the stuff I won't use and won't find its way in portage through me... so you have to find someone else to add them or become a dev yourself ;)
I'm really hoping to be able to improve the KDE experience in Gentoo, as lately it has become a bit of a problem. The 3.5 series is not good enough to get into stable, and the 3.4 has its share of problems right now. Yesterday I added to KWin the patch that solves the problem with systray icons at login moving into the left-top corner of the screen.

Sometimes I wonder what will happen if I take a "normal" job and I have to drop some of the Gentoo stuff I do :P

Donnie already written quite a lot about porting applications yet to be ported to modular X, but there is something that is probably difficult for many people to see as a problem.
Porting applications that usually inherits X11 dependency from other libraries.

KDE is a big example of that: most of it uses Qt abstractions instead of accessing X11 directly, so after Qt is ported there was no need to port all KDE packages. Unfortunately this isn't always the case.
When I started dropping support for things like xcomposite and xscreensaver, I added a few dependencies for Modular X to some packages like kdesktop and kwin, but probably many are still missing.

Today I fixed net-im/kopete to have a xscreensaver useflag to enable idle detection, as I added RSIBreak to the tree with libXScrnSaver as an hard dependency, and then I found that it was linking to lot more stuff... I had to rebuild Kopete 4 times today then, and that quite sucks because it takes a lot of time to build :( I should probably ask Matt if it's possible to add a few --disable parameter to configure so one has not to build things like the latex plugin, all the protocols like gadugadu and so on, trying to minimise both the build time and the stuff that can break (remember: more code, more stuff that can break).

This is what I like of Gentoo mainly. I can choose what I want and what I do not want to compile. Not even use, compile. The less libraries I link against, the less chance to soname changes to break my system, the less code I build, the slighter the chances of having security problems.

Anyway, starting tomorrow I'll try to continue fixing the modular x dependencies of KDE, hopefully that will mean that it would be possible to install kde without having to merge xorg-x11 at all :P
And of course where it makes sense, for extensions that people might not want at all, I'll try to provide useflags :)

I'm happy to see that Matt decided to go with a new release of kopete out of KDE's release cycle.
This is probably going to help quite a bit the development IMHO, as there won't be any more 3.x series releases a part bugfixes, but Kopete really need more work on features and protocol support, not just bug fixing.

The new release, 0.12-alpha1, really impressed me: the new chat window engine, using CSS instead of XSL is way faster, although I had to edit the style I choose (from AdiumXtras, that I already knew as I use AdiumX on OSX) to remove my own icon from appearing, this because every time I sent a message it appeared to take my avatar image, and scale it down to what the skin required... pretty CPU intensive, especially as it wasn't caching at all.
Well not a big deal, I don't like watching those avatars anyway :)

Anyway for who wants to test the ebuild is in in my overlay. I'll wait a bit more before looking into adding this in portage, just to solve the possible big issues with it.

I'm anyway good impressed with the work that's being done. Although I didn't enable the jingle (Google Talk's talk support) as it requires an old version of oRTP (0.7.1) that would create a new dependency up-downgrading, and I'd rather wait to see if somebody is going to make it work with the current 0.8 series.

This version seems really to improve the responsiveness of the application in its entirety, so it's a good step forward. Only thing I found strangely long was the shutdown... and I have no idea why, it starts a long series of munmap, takes a long time before it actually closes...

Oh well, I'm really looking forward to beta1.. and I really like being able to use Adium's styles.

Okay so a new amaroK is coming: the release candidate of the first beta of 1.4 series of amaroK (how many 'of' are too many in a single phrase?) was released yesterday, and I strangely enough not blogged about that yet :)

The ebuild for such a version, that I named 1.4_pre1 as I couldn't name it 1.4_beta1_pre1 (maybe using redhat-style 1.3.90_rc1 would have helped :P), is currently in my overlay, if you want to try it out.

Note: Ruby is now an hard dependency, as without it you won't get lyrics support, and maybe other in future.

I also dropped the extra use flags for gstreamer's plugins, I was finding that too confusing and the same was for at least a couple of users I heard from. If you want to use gstreamer, please at least learn how to install its plugins :) This might also solve some of the problems I heard of like "gee I unmerged amaroK, ran depclean, and now ｢put some gstreamer app here｣ does not play ｢put some format here｣".

I must say, if you just want amaroK to work smoothly, don't try this yet. While markey solved my issue with module files appearing as "No track playing" in OSD (thanks markey :) ), there are a few things I find a bit of regression (trying to get a hold of some dev on #amarok right now to tell them): the randomness is not so random anymore, and the "previous" button while playing a randomised playlist does not return to the last played track, instead it moves to the previous track in the sequential playlist open in amaroK in that moment.

Still, amaroK 1.4 is very well promising, and I'm sure that before the release those glitch will be fixed :) Thanks for all the work, amaroK devs!

I already blogged some time ago about the importance of using external shared libraries as much as possible instead of internal duplicated code.

One of the code most subtle because duplicated in a lot of packages is xpdf's code, that's also known more for its security problems than for its features. Luckily, FreeDesktop started the poppler library to provide shared access to the code, fixed and updated to avoid duplicating always the same code in different projects and then having to patch all of them if a vulnerability is found.

Unfortunately, not all the software is already updated to use this code. In particular KPDF, also 3.5, still duplicates the code, and this requires bumps and fixes every time a security update is released (for this reason kpdf is always the most revbumped KDE package).

But thanks to jriddell, the problem is partly solved :) He prepared for KUbuntu a patch that uses poppler instead of the internal copy of xpdf; patch that I've updated a bit to fix the autofoo support (never hardcode /usr in a distribution that is working for prefix support ;) ), and then applied to kpdf and kdegraphics 3.5.1-r2. This does not only mean that finally with new security vulnerabilities there's no need to patch kpdf/kdegraphics and let the users rebuild them, but it also mean that kpdf is lighter, because the code from xpdf is now removed. In my system, with splitdebug, -g -ggdb, the version using poppler was 3MB smaller.

So Ian, now you see why downstream has this strange passion for dynamic linking? :)

Update: I've seen that by using +cairo on poppler, the performance of KPDF _really_ improves sensibly, also compared to original KPDF with internal xpdf code. Good thing, eh? :)
Update 2: tsdgeos (KPDF maintainer) let me know that KPDF still don't use cairo also if poppler is being built with +cairo... so I'm not really sure about the boost above stated, it's really there, I double checked it, but might be triggered by something else, no idea about that... the strange ways GCC creates code..

Okay it's sunday night, and I'm at home. I don't have anything to do a part the infamous paid job that's driving me crazy and I'm waiting new info for. So what can I do? I can try to fix one of the KDE bugs I suffer from! :)
In particular, I gone for a KMail bug I encountered while replying to a mail of a friend of mine who's using an Italian webmail (not the provider she's connected with, or I'd have configured a Thunderbird on her box). Basically it does not accept some email/realname combinations if the realname contains @s .

Well the code where the problem was seemed to be KPIM::EmailParseResult KPIM::isValidEmailAddress(), that's a quite complex stateful parser, which flow took me some time to understand. How could I fix the problem in such a messy (IMHO) code?

I opted for a rewrite, so I started, and rewrote the function replacing the stateful parser with a series of regular expressions and string checks. This makes it simpler in terms of LOC (61 insertions(+), 157 deletions(-)) and also, always IMHO, easier to read.
This time I didn't work directly on KDE's SVN as this change is not exactly small (while also kxkb fixes for KDE 3.5.1 were mostly a rewrite), and it might have some problems right now (I'm still compiling KMail to see if it works fine). It also does not consider a couple of error situations that it was considering before, that might be a showstopper (basically I don't bail out if ',' is present or if \ is at the end of the string. It shouldn't be difficult to fix in case, tho.

Now does this mean I'm actually bored? Yeah it means that, but not only that, it also means that my personal life really needs a shock to change, shock that's not going to happen in the next century or so...

Update: I've actually rebuilt KMail and my patch does work for most of the cases, actually it works for the \ present at the end of the string because of the way I structured it, returns a different error but it does not allow the wrong address to pass through. I checked with a forged To line with my email address and then tried also replying to my friend's last mail. I attached the patch on the aforementioned bug and committed an ebuild using that patch in my overlay, but it's using 3.5.1 version that's still unreleased so people are not going to just emerge it to have the patch for now ;)
Should work with 3.5.0 too anyway.

Okay so I'm continuing working on taglib's bindings for Ruby, using the C++ interface. My M4 file now is able to generate most of the structure code that I need by providing it the basic informations about the classes and the methods I want to bind. Unfortunately, this is not yet enough to get something working: I have yet to generate the constructors, that are the most important part of all of that, and I'm having trouble to assess if an alloc function is needed for the classes that cannot really be created by users, as they are only returned by TagLib itself.

I think I'll try to concentrate on having something that loads on Ruby soon, and then start having something that works later. Right now I have also put in place autotools' support so that it goes looking for Ruby and TagLib. The main problem is that to create a shared library I'm using libtool, and that don't allow me to call the library "rubytagpp.so", but wants to call it "librubytagpp.so". I have to find how to get around that.

Leaving for a while RubyTag++ alone, I've been pleasantly surprised by Google's decision to open Google Talk to the other Jabber servers. The first thing I've done after that was to move all my contacts from Talk to Jabber, so that I don't need an extra account to talk with some friends. I think this is really going to improve Jabber's appeal: while some of us has access to decent servers (like im.gentoo.org, thanks infra again ;)), jabber.org is somewhat unreliable and many other public jabber servers seems to have similar problems (I can name for example jabber.linux.it that was having more problems than working support), with Google Talk, part of the problem is solved, who can't find a decent Jabber server can use Google Talk and stick with that, others can still reach him :)
I really hope this is going to change the distribution of users in the IM services, especially I'd like to get rid of most of my ICQ contacts if they move somewhere else.

Okay, just a few things again on the Ruby bindings for Taglib's C++ interface. M4 is really helping out, it has a quite steep learning curve but when you know how to use it, it's really simple to let it write the code. Basically I just have to engineer the macros one time, and then I can reproduce it for the infinity.
I'm also trying to make it generic enough so that it can be easily used to write other kind of bindings.

What I have to do now is to allow defining classes inheriting from parent classes and then allow to reorder the classes in modules (miming the namespaces in TagLib). It's giving me headaches to think how to do that from outside, but the same happened for the rest before I got into it to start coding it out. The C++ code I've been able to generate right now does not yet compile, also because I'm missing the functions that "bridges" the TagLib's types with Ruby's internal representations.

The road I have to follow is still long, but considering I started yesterday night, I can say I'm happy with it.

As I said, there's currently no good TagLib bindings that I can use for the tagging program I'd like to write, as the only ones available (ruby-taglib and rtaglib) are using the (very limited) C interface.

So I've decided to start working on new ruby bindings using the C++ interface. The extension API of Ruby is not the worst I've seen: when I tried writing bindings for Python in my UO Server Emulator, I _really_ was being driven crazy.

What I'm still looking for is if there's a way to get something called when an instance has to be disposed by the garbage collector (so that I can delete it). For the rest, it's mainly requiring work on the code to compile, as that's what the bindings consist of: lots of functions that just calls the true function.

I think I can "simplify" the work by using some M4 magic (the idea came from ciaranm and his bragging around about the M4 macros he wrote to avoid rewriting the same thing over and over), but that surely requires lot of refinements, because of course without having the code it's also difficult to design the interface.
Anyway, this thing is actually interesting me because it's something different from what I've done in the past and it seems like it can be of help :)

If somebody wants to see what I'm talking about the M4 things, I've used bazaar again: http://dev.gentoo.org/~flameeyes/bzr/rubytag++ . The version (1.4) is related to the API version of the library, it will proceed like 1.4.1, 1.4.2, and so on and bump to 1.5 following taglib.

Update
Thanks to Caleb who replied me as usual really quickly, now I know what I have to do :)
I'm working on the actual code that generate implementation (it's M4 code, thanks again to Ciaran for giving me the idea), and I already have something done. The road to work is really long but it's a starting point :)

As I said today the option to recode tags in amaroK is now gone and it wants that the tags are filed with valid UTF-8 support. EasyTag, while seemed to work originally, seems not to work on the long run, it crashes on its own processed files!
And there are currently no good choices for KDE/Qt based software for tagging that I know of (okay amaroK has support for some tag editing but it's not the same of EasyTag.

So I'm tempted to start a tag editor written in Ruby, using Korundum. Why Ruby and not native C++? It's because of a series of reasons: there are already bindings for freedb access and taglib, Ruby is natively UTF-8 compliant and I don't have to deal with that myself, I don't even have to care about endianness.. Then there's the thing that I'm being a completely Ruby freak lately that _might_ make me biased :D

I think JulTagger can be an interesting name (you have to guess the reason of such a name tho :D); I'll give that a shot now, I have some free time and I want to take a bit of work on something for a while non-gentoo-related.

Update
Okay, I started working on it, it's not difficult at the end to at leat mock the design up when using Korundum. I've placed it as usual in KDE's SVN, playground/multimedia module, so whoever wants to get it and start looking around.. it's only barbone right now.
Unfortunately this barebone is enough for me to see that ruby-taglib is not powerful enough for what I need to do, it only provides basic API support because it uses the TagLib's C interface.
I'd have to write something more complex if I really want to continue this way, and I want, but that might take some more time...

Continuing the I'm out of cool titles saga, this is mainly a changelog entry for myself that I want to put some lights on :)

I think I already wrote about amaroK's team way to inform packagers of new versions of amaroK. And who idles around in #amarok @ freenode, probably already knows that before the actual release there are usually one or two (or more) release candidate releases. Last time I put them directly on portage, under p.mask, but I wasn't happy enough of that solution because the SRC_URI was broken and I was really expecting bugs about that.
This time, as yesterday I made public my overlay, I pushed those ebuilds directly there so people can get them when they want. If you want to be updated when push something there, the changes appear in my CIA page (sorry yesterday the commits appeared on Gentoo project, now I changed them to flameeyes project anyway).

The current version available is 1.3.8_rc1 as the rc2 in #amarok's topic was foobar and was code of 1.4 series instead ;) Well this mistake was actually useful to me as I could take a look at the new deps at least. Unfortunately, it's probably going to be an headache, especially for me. The new (optional) deps are mostly missing in portage: libifp is completely missing, a bug is filed about that, but it's in maintainer-wanted and the ebuild does not work as intended anyway; libgpod is handled by joem, and I'm not even sure if it's the right version, the dependency over sys-apps/unieject is a problem for me as I'm using unieject here, I think it can be changed to virtual/eject but I want to hear from joem about that; exscalibar is not even reported on bugzilla.

What does that mean? Well it means mainly that amarok 1.4 on Portage won't have the useflags to enable ifp and exscalibar support and _might_ have libgpod support but that would be untested by me at least (I don't have neither an iRiver nor an iPod). Gentoo developers that might want to add and manage them and test amaroK's features related to thos are obviously welcome to step up; non developers wanting to join Gentoo are welcome, too. For the ones who are not developers and don't want to become, and still wants amaroK ebuild to support libifp and libgpod and the features to be tested working.. find someone else to take care that has the hardware, or donate the hardware, that's a solution too.

Okay and as I said "ebuilds" in the title, I actually have an interesting change to 1.3.x series ebuilds, too... from 1.3.8, the $LINGUAS variable will be respected, so it won't install lots of locales and build documentation for all the languages it supports. In my case, it just built Italian language and documentation as I have LINGUAS="it en" (I actually have that only to get Italian spell checker, as I use the entire system in English, but anyway).
That is probably going one of the main reasons to update to 1.3.8 as the changes from 1.3.7 are actually bugfixes, most of which we don't really care about (NMM and HelixPlayer backends are disabled in Portage) and the important one (lyrc's change) is already applied in 1.3.7-r1 (thanks Ian again :) ).

Yeah if you can't tell, I'm running out of cool titles for blogging.
Anyway this is quite self-explaining. Tonight I spent some time, after a careful emerge depclean, patching KDE to remove some stray linking to libXcomposite and libXscreensaver in kwin, kdesktop and kicker.
The patches consisted mainly of configure.in.in mangling to remove the reference, and I committed them on upstream SVN so that they are available for next versions, too.
I just hope we'll have someone handling KDE bump to 3.5.1 with split ebuilds because I'm mostly scared of doing it again.

Okay, I think I'll go back looking for what links to xinerama, maybe I'll find something that can be patched to get rid of that one form my system as I don't use it.
The first target is gxine, as usual ;)

Update: okay I ended up adding a few more patches and xinerama useflag then. Gxine, Kaffeine and KSplashML are honouring --without-xinerama in main portage now (and with the exception of Gxine they are also upstream). I have a local modified ebuild for x11vnc and tvtime, both submitted upstream and waiting for them to see if I should send the patches to swegener and obz. I'm rebuilding GTK+ now but I might have hit an issue with --as-needed due to test programs linking to installed libraries instead of the ones just built, waiting now to see if it's a trivial fix as I hope.

VLC is the last package I have on the system that links against xinerama (well ok there's still wxGTK here but it's probably a consequence of GTK+ as it does not support --as-needed), but I have yet to try preparing a patch for it as I wanted to leave it as last.

If I'm able to fix these three remaining packages, I should be able to get rid of xinerama altogether! Yeah! Obviously it would be more complex if I wasn't using --as-needed as in that case libXinerama.so.1 was linked in most of my system.

I'll be back tomorrow with more status updates.

Today I woke up earlier than usual (no well, to be honest, I wasn't able to sleep decently during all the night), so I wanted to spend the time working on something that would make me ignore what I have in mind. As I was there, I wanted to get kxkb working right, as I needed krdc to send the correct keycodes to the Windows box I have to work on, I couldn't continue using only alt-intl variant, that wasn't sending the keycodes right.

The issues were at least two: the first was that kxkb wasn't playing fine with alt-intl variant, the second is that, not having two different layouts anymore (us and us_intl) as was up to 6.8.99.15 at least, kxkb wasn't allowing me to put the two different keyboard layouts in a selection cycle (when you added a layout, it was removing it from the list of choices).

I then started working on the second issue first, allowing to add the same layout more than one time, and saving/loading the variant with it. The issue wasn't trivial, but it wasn't so difficult either, the only problem is that, to store the variants no more indexed by layout, but rather by entries, I had to use, as index, the string containing the hex representation of the pointer of the instance of QListViewItem that represents the single entry. Quite an hack, but worked.
After fixing this, I stumbled across the other problem, that resulted quite trivial, when I found it: basically the regular expressions used to load layout and variant were using [a-z0-9_] as specification for valid characters, this wasn't obviously working for us(alt-intl). Adding - to the list, solved the problem.

So the result is that now in 3.5 branch in KDE's SVN you can find a kxkb capable of adding the same layout more than one time, choosing different variants, and then allowing to use us and us+alt-intl replacing the old us and us_intl behavior. As the patch is quite intrusive, I've rather not put it on Gentoo's ebuild for kxkb and kdebase, so people would probably have to wait till 3.5.1 to be released to have that fixed. I've, though, fixed the alt-intl problem with the -modularxkb patch you can find in kxkb and kdebase 3.5.0, so you can just re-emerge them to make use of alt-intl if you want. I've not revbumped as xorg modular is still experimental so it's not like everyone using ~arch would like to rebuild kdebase for something they don't care at all.

Oh, on a side note, ALSA 1.0.11_rc2 is in tree. The changes to drivers mostly interest emu10k1/2 users, the rest are mainly side issues. The ppc/bigendian issues are fixed upstream, but they were fixed on Gentoo already.

Okay, just for the sake of telling everybody that, I've imported the code I started for atmosphere2 (rewrite of ATMOSphere as Framework instead of a all-in-one program) in KDE's SVN repository. It can be found in /trunk/playground/network/atmosphere .
I hope people can take a look to it and maybe help with it.

This follows my plans of making public all the sources I was working on locally, so that if I'm going away someone else can take care of my old projects :)

Now I just need to write maintainers' guides for xawdecode, adding notes about zvbi and alevt that I'm going to take care, too.

Okay, tonight trying to clean my backlog I'm also blogging quite a bit.

I want to ask something to all the SVN guru out there ;)

I have some packages in KDE's svn, KNetLoad in extragear/utils and KDigest in playground/utils. The way KDE's svn is handled, I need a checkout of the files inside extragear/utils and extragear/utils/admin (the same for playground) plus the whole subtree for my package; I don't really care about the rest of the subtrees.

There's a way to tell svn to locally ignore all the subdirectories of a checkout a part the ones I tell it not to ignore? :)

I really hope there's such a feature or updating those trees would be reaaally hard... and I was considering importing into playground a few more projects to avoid stucking them locally...

Well if somebody has a solution, leave a comment :) thanks!

I'm wondering about this. In the past I wrote about the problems between KWord and OpenOffice.org about ODT handling.
Basically, a list created with KWord does not get loaded correctly with OpenOffice 2. The issue was identified before the final release, but was postponed to 2.0.1 release.
Okay, today I found OpenOffice 2.0.1 in portage, updated and tried, almost sure it was going to work...

Well it didn't. OpenOffice.Org 2.0.1 is still unable to load KWord's ODTs correctly, although they are compliant documents and they should be loaded fine. The issue in their issuezilla was verified and closed, but the problem persists.

This makes me think of two things: a) ODT is not a true solution at the moment, because its implementations does not really conform to a single standard, lists are handled in two different ways, and OpenOffice.Org, that should be the major ODT consumer and producer, is not able to manage one of the two b) the way OpenOffice.org issues are handled is faulty, they "verify" and "close" issues before the actual release, and then they are not actually fixed, it would be simpler if people could build some experimental version and verify and close bugs by themselves after the fix has been committed, but the way OpenOffice.Org is designed, it takes too much time to build to check that for a normal user, and it has to wait for the actual release.

Not like Gentoo's way to handling bugs is perfect, sometimes I'd simply like to tell people to set verified all the bugs I resolve, so that I can close them later, but that's probably not going to work that well :|

Anyway, OpenOffice.Org still has troubles handling that particular feature, that's not exactly a "small" feature; ODT is not yet ready to be the perfect interexchange format for every office suite.
And the ironic thing is that if Microsoft would have supported ODT, maybe they could have found a way to make them incompatible with everything else like they did with HTML.. are we going to use their format in the future, as actual working interexchange format, similarly how we currently use Samba to share data between Linux, FreeBSD and other L/OSS operating systems?