Today in Gentoo’s KDE land

And here I am, blogging about a a long day that made me feel so tired I’m knocked out on my bed, longing for reading some Peanuts strips. Today was almost entirely dedicated to KDE, so here I’ll try to point out the changes.

The first and surely biggest difference comes into KPDF handling. If you didn’t know, up to today we used a patch originally coming from KUbuntu and JRiddell, to make it use Poppler. The reason for this were that integrating xpdf code in KPDF meant having to bump it multiple time per release every time a new XPDF vulnerability was discovered (and this still happens, one was discovered just last week), and often we were already late on the patches train, plus the slowdown coming from arches taking time to mark stable, and at the time there was little or no downside to do this: no feature loss, and very little incompatibilities quickly fixed.

Today I was contacted by pinotree of the KDE team, KPDF developer, asking me again if I could drop the patches or at least add a vanilla useflag; I say again not because he asked me before, but KPDF’s main developer tsdgeos, criticised both us and KUbuntu a lot because of the patching, although at the time there were very little problems; this time I started thinking over this a bit more.

Many things changed since we started applying that patch: the focus on XPDF is now less than before, because Poppler already passed through most of the code, which means that the most stupid vulnerabilities were found already, there has been some little feature loss in the 3.5.7 version too, because the title of the postscript file queued for printing couldn’t be kept while using Poppler, and newer versions of Poppler also started behaving slightly differently from before, to the point that there are some major problems. Also I got a report of another PDF that is showing fine on KPDF’s code, but leaks memory when used on Poppler; outside that, Ioannis joined the KDE team, which is no more just me and Carsten, and I got kde-packager access, which means I can see the vulnerabilities as soon as they are discovered rather than when the advisory is released — You might not tell, but this is a great improvement. Pinotree also agreed to inform me, if possible, as soon as they discover something that has to be fixed, so that I can respond to it as soon as possible.

With the current situation, it was time to test an alternative. Right now there are two new revisions of KPDF in the tree, 3.5.5-r1 and 3.5.6-r1, they both are the same as their -r0 predecessor, but without the Poppler patch; in the case of the 3.5.5 version, also the security fix is applied. They should resolve quite a bit of problems, and they should be clean without further security issues up to now. Please test them, and report any possible issue you find. I haven’t applied the same to kdegraphics, because that’s way more massive to compile, so I left that one using the Poppler patch to have a single point of failure.

If you didn’t get the news, it’s no more true that split and monolithic ebuilds have the same exact features: as no developer seems to care enough for those, I’ve been merging to them only important changes and fixes, while I apply experimental or improvement patches to split ebuilds, or I remove them, like this time. I already did that with Lubos Lunak’s xinerama patches that are available on kwin and kdesktop but not on kdebase. Which means that if you want upstream support for KPDF, you need the split ebuilds.

Another drift between the two versions is with kdepim, that today, beside a revision bump to apply two hotfixes to KMail coming from its developers, lost the pda useflag for the monolithic version. The reason for this is that the new KPilot requires a pilot-link package that we don’t have, and thus I had to mask it entirely, until someone in PDA herd can get a hold of that. In the mean time if you need KPilot you need to use KPilot 3.5.5 and kdepim-meta.

Even more changes: KDVI got an emacs useflag, thanks to Sebastian Shubert, to enable search forwarding to emacs. I hope I got it right though, it’s the first time I add an emacs useflag to a package, I never used elisp.eclass before.

And again with something important, KDevelop 3.4 is in the tree, the new branch with about 500 closed bugs against the older 3.3 branch. This version not only features fixes by upstream, but also got the correct configuration for our ctags (named as exuberant-ctags), so that new installations will have it working out of the box (I maintain that packages that requires configuring tools’ paths should be pre-configured by ebuilds so that users don’t have to change them manually). Old installations will unfortunately have to fix the path from the configuration if it’s not already set correctly, sorry for that, I’ll be working on it maybe.

And for external software releases, Tom Albers released Mailody 0.4.0_rc2, that is also in the tree: his lightweight IMAP client improves with every release, with this series it also got signature support. I’ll probably use it as my main client on Intrepid’s installation, rather than KMail; after all right now I don’t have GPG support in either Operating system. Basically the only thing stopping me from using Mailody as my main mail client everywhere is GPG support… but I trust Tom to get it sooner or later 🙂

Another release, but this time not yet in the tree, has been TorK 0.13; unfortunately when I tried, it didn’t work; but Robert diagnosed the problem right away: this version requires the alpha development version of Tor, which means it wouldn’t work with what we had in Portage till now, but Gustavo (HumpBack) now committed under package.mask a new alpha version of Tor that I’ll depend upon tomorrow, when I’ll commit TorK 0.13, also under package.mask.

Another thing I’ll have to fix tomorrow even if it would be part of Gentoo KDE’s day, is the new handling of XDG environment variable on system level rather than KDE session level: Christoph Brill reported it and Pacho Ramos found the problem yet again 🙂 One of the two variables is misplaced, and should return to be a session-only variable; I’ll fix that first time tomorrow.

This should cover all the work done for KDE today, and it’s not bad, I have to say. Of course, I also spent some time on Serielle Konsole: last night I was able to finally get it working almost perfectly and configurable: now by default it starts with a session opened on /dev/null – to avoid keeping a device that shouldn’t be opened – and you can start a session to a given device with given parameters by configuring a session, in the same way you configure the sessions for standard Konsole! The configuration of the schemas, the extra icons, the wallpapers, and the terminal profiles are also shared by the two, to the point that one of Serielle Konsole’s dependencies will be for sure Konsole.

I plan to add a few more things before the first release, like a command to send the Break signal (already present in the code, just need to be shown on the menu, on the popup, and get a shortcut assigned), support for resuming Serielle Konsole from a saved KDE session with the devices as were open before – like Konsole does for the directories – and a way to specify on command line the device to open (this was on request by Marco Gulino, who would like to use it for KMobileTools debugging 🙂 ).

Now I could be talking about Amarok, about xine-lib not crashing anymore when you try to open a smb URL, about the new VLC snapshot in Portage from the bugfix branch of the guys at VideoLan, about my plans for ALSA in the next future and the new breakages introduced in 2.6.20 kernel and later, but I’m too tired and I’ll leave most of that for tomorrow. I’ll have a full day again.

Goodnight everybody, and enjoy today’s, tomorrow’s and next month’s fixes, so that I don’t apply them for nothing 😉