“Put it there and wait for users to break” isn’t a valid QA method

So it seems like Jeremy feels we’re asking too much of maintainers by asking them to test their packages. As I said in the comments to his blog, picking up poppler as a case study is a very bad idea because, well, poppler has history.

Historically, new upstream poppler releases in the recent times have been handled by guys working on the KDE frontends, when they suited their need, rather than being coordinated with other developers. This isn’t much of a problem for them because binary distributions have no problem with shipping two version of the same library on different ABI versions, and even building packages against different versions is quite okay for them — it definitely isn’t for us.

In turn, within Gentoo, in the recent times, poppler has been maintained by the KDE team; mostly by the one developer who, not for the first time, wanted to bump to 0.16.0 a couple of days ago, without adding a mask first and ensuring that all the packages in tree that use poppler would work correctly with it. Jeremy states that doing such a test would make ~arch akin to stable; I and I’m sure other of my colleagues, rather see it as “not screwing users up”.

First of all, it’s not like bumping something that you expect not having trouble; bumping grep and finding out that half the packages fail whose tarballs were built with Gentoo and a very very old version of our elibtoolize patches is unexpected. Finding out that, once again, the new minor version of poppler has API breakage is not surprising, it’s definitely expected, which means that when committing the version bump you can have either of two thoughts in mind “I don’t care whether GNOME packages break” or “Ooh shiny!”. In either case, you should learn that such thoughts are not the right state of mind for committing something to the tree. I said that before of other two developers, I maintain my opinion now.

And just to be clear, I’m not expecting that we spend months in overlays before reaching the main tree, I’m just saying that if you know it’ll break something, you should mask it beforehand, and give a heads’ up to the developers maintaining the other packages to due their job and fix it.

Now, in the comments of that post, Jeremy insists that factoring in my tinderbox is not an option for him, because it is “counting on a single developer cpu/time”. Right, because there is no other way to test reverse dependencies, uh? The tinderbox is meant to help the general situation, but it’s definitely not the only way; even though I’d have been glad to run it for poppler to find and report the problems, the task of checking its reverse dependencies is far from impossible to deal with for a single developer. There are a grand total of … thirty-nine (39!) packages with reverse dependencies on poppler! So it’s not a “can’t be done” situation, it’s a “can’t be arsed”. This also brings Jeremy’s ratio of “7/14000” packages with a problem to a more worrisome 739. See the difference?

Simply put, do your own homework: learn about the package you’re maintaining, try hard not to break reverse dependencies; if it happens that you break a package unexpectedly, hey, it’s ~arch, we can deal with it. But do not commit stuff that you know will break a good deal of the packages depending on yours. Especially if you’re not out there to fix them yourself.

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 😉