Bobulate

My friend Armijn sent me this, and asked if I would pass it on. He adds as a word of warning “this is a post that can easily ruin your mood“. I’m posting it here as well as on my new blog, as its theme is the future.

Almost all free software developers I have met are always very enthusiastic about their programs and what to add and improve in the future. Very few of them think what happens afterwards. With this I don’t mean what happens after those additions and improvements (your answer would probably be “more additions and improvements”), but I mean when there is no future. When you’re no longer coding. When your uplink is permanently disconnected. When you’re dead.

Planning for the inevitable is not something we want to think about (thinking about your own mortality is not many people do for fun), but it is something we need to do, all of us. I was remembered about this by two recent events. One was when at gpl-violations.org we got a report about a violation in the Apple AppStore. Since I had already dealt with the same developer in the past (it was resolved very amicably) I decided to connect the reporter directly with the developer. The reporter got an unexpected surprise in the form of an e-mail from the developer’s father who said that his son had died half a year ago and he could not get himself to pull the app from the App Store, as a tribute to his son. Eventually we got sources when one of the developer’s friends (another engineer) was involved to lift the sources from the deceased developer’s laptop.

Another example was when a webmaster of a website that my dad regularly contributed to, died in a fire in his house. The website contained many years of research, at least 10 years, but possibly many more. Many people had contributed to this research, but the data was only available through the website. The database itself was hosted on baseportal.com which allows people to have a free database. How to get the data back, especially someone else’s data is completely unclear. At the moment people are trying to reach the heirs of the webmaster so they can salvage the data and make sure the webpage continues as a tribute to the original webmaster.

The common theme is that these people were very passionate about what they did. They truly loved their work and it work was appreciated by many. But when fate struck it turned out that they had not taken care of what would happen after they would pass away. I am very sure that they didn’t expect this to happen so soon, or never realized that this could be an issue. But in the digital world, with lapsing domain name registrations, databases and webspace being deleted because of unpaid bills, offline development trees and uninformed heirs this is becoming more and more of a risk.

So, what can you do prevent this from happening with your code and data? First, move your development as much online as possible. The KDE project has great infrastructure for this. Second, think about assigning your copyright to KDE e.V. with the FLA. If you don’t want to do this, make sure that your heirs know what you have been doing with free software and what they can and cannot do with the code. Show them that you care a lot about this.

Don’t let this story scare you too much. Keep coding, with passion, knowing that if you have taken the right measures your code will live on and will (hopefully) be used, reused and adapted by many people, even after you are no longer here.

— Armijn

(As a closing note, the FLA that KDE e.V. uses was developed by the FSFE.)

KDE 4.5.4 (why wasn’t that codenamed "pound" or such?) was released some time ago, so there’s updated OpenIndiana packages available. You can find them at the KDE 4.5 package repository. The naming is now deceptive: it’s KDE 4.5.4 in the 4.5.3 repo. Use specific FMRIs if you want to stick to the previous version. Only KDE packages were updated, so all the dependencies stay the same.

We have decided to drop OpenSolaris build 134 as a target. You can use these packages on OpenIndiana build 147 or later or Oracle Solaris Express build 151a. Maintaining compatibility with the older OSOL was increasing the complexity of building packages, putting our resources under strain. So we dropped it. We’re also still on the fence regarding Solaris 10 — no one seems to want it, which means that it may be swept under the rug sometime as well.

Last week I tried to ask for hardware — 1GB ECC PC-2700 DIMMs, to be exact — and got no response, while Aaron didn’t call for hardware and got a bunch of offers to buy monitors and such.

Now, Aaron has since explained that the problem holding back the resolution of the bug that triggered his "donation drive" isn’t a lack of hardware, but a lack of a specific setup and workflow. And it looks like the resolution of the bug has been attempted. Pretty cool stuff — but it’s not the bug resolution that I’d like to write about here.

First off, a "hardware pool" for KDE developers has been tried before. Several years ago (I tihnk it was) Scott Wheeler tried to set one up. The idea would be that spare hardware would get passed around or sent to KDE developers who needed something extra. The idea never took off, and eventually the plan shut down. There were three reasons for this, basically:

1. Sending hardware around is really darn expensive. By the time you’ve covered postage and insurance, it can be nearly as expensive as just buying something locally. So it’s expensive to send stuff.
2. Customs are a nightmare. Switserland doubly so. I remember long ago someone sent me a spare Palm Vx from the US. It was a used device, and the Vx at that point was already no longer on the market here. Dutch customs assessed me around 50 EUR in import duty. So it’s expensive to receive stuff.
3. There are remarkably few hardware requests. Apparently KDE developers work within the constraints of what they have, rather than what they would like. A few times I’ve blogged about left-over hardware that I would give away (in spite of points 1 and 2) and got no response. Maybe my leftover hardware (usually around 3 years old) is just too crappy even to give away.

There are a few exceptions to #3. There was a donation drive to get Krita developers some specific hardware. Maemo devices have been distributed to the KDE community at various events in order to drive enthusiasm and interest for the devices. Those are unusual cases, though.

Now, there is an organization that can help with hardware needs. It’s KDE e.V. The association’s mandate is to support the community. That includes providing hardware if needed. Let’s look at this from two sides:

For the potential hardware donor, KDE e.V. accepts donations in cash (tax-deductible in Germany) and in special cases could receive hardware, too. There are two ways to help KDE e.V. You could donate directly to KDE e.V. and add a note describing what the donation is for. (For legal and tax reasons there is no guarantee that the donation will be used as requested) You could also join the game and systematically support KDE e.V. in its work. Resources that KDE e.V. gathers (e.g. money) are put to work supporting the community. That is usually in the form of travel and lodging for events and workshops, but could cover other forms of support as well.

For the potential hardware recipient there are standard procedures for requesting support. There are forms on the KDE e.V. website. If you need something special (e.g. a second video card and a monitor) then you can ask the board beforehand if that falls within the mandate and if so, request reimbursement afterwards. As a general rule, I think that peculiar or special hardware has a better chance of being supported than general upgrades and hardware requests with a strong and specific KDE purpose are more likely to go through, too. Ask first.

So yeah, if you need a bi-polar defrobnicator to bobulate your Plasma widgets, then by all means do two things: ask if KDE e.V. will help you out there, then blog that you need such a thing and encourage people to donate to KDE e.V. for one. Then wait, buy the stuff yourself, and do cool things.

As far as my desire for more memory for my SPARC workstation for KDE package builds on that platform, well, I think the board of KDE e.V. (myself included!) would answer "too niche, too expensive for the projected benefit of all two KDE4-on-SPARC users."

The first beta of KDE 4.6.0 has rolled around, pretty much on schedule. In the KDE4-OpenSolaris community we’ve been following closely, building trunk as much as possible and upstreaming those patches that make sense. So we’re happy to announce that for the first time there are 0-day packages available for OpenSolaris-type systems using Sun Studio (I’ve got to add that last proviso because the Belenix guys do a good job of producing packages with gcc).

The packages can be had from the 4.6.0 package repository and include Plasma Desktop Workspace, KDE sdk, Konversation and Amarok along with a bunch of other things. There’s no KDE PIM, edu or KOffice because of various compilation problems that we have not yet been able to solve or functionality issues (e.g. KMail crashes in all of its GPG handling in a way that makes me suspect a compiler bug, but I haven’t been able to track it down well enough yet). The specfiles repository from which these packages are built is available too.

Supported Platforms: the packages are currently available for x86 only. In a poll we did some time ago there was little enthusiasm for specific 64-bit packages, so we have not been building them. Anyway, the Solaris kernel can mix-and-match 32- and 64-bit applications and libraries, so there’s not much lost. There’s no SPARC packages, in spite of some recent success in getting things to build. Here’s the list of supported platforms:

• OpenSolaris build 134, x86 Edit: while the repo should build on 134, these packages will not install there because dependency names have changed.
• OpenIndiana build 147, x86

Just those two, hunh. Later builds of either should work, but have not been tested. Oracle Solaris Express 2010.11 should work (it names itself build 151) but has not been tested. Solaris 10 is not supported, as it uses a different packaging system and needs lots of other updated software.

How to get it: set your kdeips-dev publisher to the new repository URL, refresh and install. Something like this should do:

pfexec pkg set-publisher -O http://solaris.bionicmutton.org/pkg/4.6.0/ kdeips-dev
pfexec pkg refresh
pfexec pkg install KDEbase-apps

PS. I’d like to welcome Onno Molenkamp to the fold. He’s been doing 64-bit builds for us and tackling some long-standing annoyances (in Virtuoso and Qt) that make the build less pleasant than it might. The #kde4-solaris channel now has random bits of Dutch on it, too.

PPS. KDE4-OpenSolaris acts as an "upstream" for OpenIndiana. We’re "downstream" from the work done by the KDE community, and massage the code a little and send it off again. There is plenty of scope for cooperation, and we’ve seen recent conversations about having various parties interested in stuff to work together more effectively. (Here "stuff" is Qt and KDE frameworks as well as KDE applications and Plasma workspaces).

PPPS. Solaris 10 isn’t dead as far as we are concerned, just very much unsupported and uninteresting as a target (even if it has a decent installed base of corporate use). Some people try building our specs every now and then and we do try to avoid actively breaking stuff for S10.

PPPPS. We know not all of our patches are acceptable for upstreaming. Some actively break stuff for other systems. Those are the kind that don’t go anywhere else. Sometimes we massage things until they are acceptable. It’s a bit of a trade-off. A shout-out to the author of Sentinella, Carlos Olmedo Escobar, for contacting me about the Solaris packaging we’ve tried to do and the patches that required. I hope to have Sentinella running on OpenSolaris pretty soon.

I feel so conflicted. Just look at that screenshot.

I was considering starting this blog post in a mad-scientist fashion, “mad, was I? they said I was mad to try! haha! and now I shall unleash my creation upon the world and show them all! hahaha!” but I’ve probably done that before. So what you see there in the screenie is probably the first WebKit browser running on Solaris on SPARCv9 hardware. It is the demo browser from Qt 4.7.1. Compiling Qt took just under six hours, I think, but I went shopping in the meantime.
So this is ultimately futile: SPARC hardware just doesn’t get used for the desktop, does it. However, the KDE4-OpenSolaris has had requests from various folks about Qt on SPARC, built with our optimizations and with the Sun Studio compiler. So now it’s here. That is to say, it compiles and some bits run. We still need to figure out how to merge packages so that the IPS repository will spit out a suitable Qt package (either x86 or SPARC). The pkg(5) and pkg.depotd(5) programs know how to handle multiple architectures, I just don’t know how to move the files around to achieve that.
But this exercise isn’t pointless. It shows up how portable Qt is (within the X11 world, anyway). It shows that the packaging setup that the KDE4-OpenSolaris group has set up actually targets the things we said we wanted to hit (which, even after revising away Solaris 10, still includes SPARC). It might help a teensy bit with code quality to consider the warnings a different compiler throws out — although stuff like "textedit.cpp", line 154: Warning: tb hides TextEdit::tb. isn’t useful in my book.
Another thing this experiment shows is that there is more work to be done in catching CStd-based firefox plugins. The Qt demo browser cheerfully tries to load the flash plugin and then falls over because of bad library initialization (when mixing different STLs, see this post of mine for some details) if there’s any interesting media on the page. In the screenshot, we see www.kde.org, which doesn’t do anything fancy.
So there you go. One more platform Konquered (er .. it’ll take another week to get through to KDEbase).

Oracle has released Solaris Express 11. That’s a binary-only preview of Solaris 11, which picks up somewhere after OpenSolaris was killed. The kernel identifies itself as snv_151a. As an exercise in futility, I decided to install this on my Sun Ultra 45 workstation — a SPARC machine. Of course I’ll be doing so only to evaluate the software I am creating (or packaging) for the Operating System, not putting the machine into production use — which is what the onerous license agreement (it’s even difficult to find the URL to link to!) demands.

I have a SPARC-based workstation under my desk, from the time that we in the KDE4-Solaris project actively targeted SPARC; that’s some time ago. The machine is still there and I like the architecture, so I try to use it every now and then. With OSOL this was always problematic. Solaris 11 seems to change that a little.

Solaris 11 comes with a text-based installer for SPARC, which is good enough. It doesn’t seem to come with a graphics driver for the XVR-2500 card that’s in the workstation, though, as the boot process tells me that the pciegfx domain will not be used.

For me it was a little confusing that some GNOME packages were installed — like gnome-audio — but no X server or display manager. Text logins are fine, but in order to test my software at some point I’m going to have to actually run X on it. Given the speed at which this machine compiles (random hardware begging: anyone have 2x1GB DDR PC2700 ECC DIMMs left over? Or four of them, for that matter? How about an UltraSPARC IIIi CPU @1.6GHz?) I’ll be happy to get through to Qt sometime in the next seven days. And let’s face it, Qt 4.7 keeps trying to outsmart the KDE4-OpenSolaris team by saying that it’s partly incompatible with Sun compilers — but in the case of Sun Studio 12 on SPARC it might be right 🙂

Turning the SPARC machine into a usable GNOME box took steps like these:

pkg install xorg evince gnome-terminal gdm
pkg install xorg-video kfb xorg-kfb fbconfig-kfb
pkg uninstall xorg-video xorg-video-wsfb

That last uninstall was to get rid of the wsfb driver which crashes Xorg. After mucking about a bit I got some advice on IRC, from the indomitable Alan Coopersmith in particular. You can find some of his work (newer Xorg) on the OpenSolaris forums. So two essential things: "fbconfig -dev kfb0 -defaults" and "pkg install slim_install", then reboot. So thanks, Alan.

The machine will come back but still be in text mode. SSH is enabled by default, so you can SSH in from another machine on the network and start the gdm service to get a login prompt. with “svcadm enable svc:/application/graphical-login/gdm:default“. If you watch the console, after about 15 seconds you get a gdm login screen. On the one hand, it’s tastefully done with some transparency applied around the session and language selectors; on the other hand there’s this giant Oracle logo on there like “abandon all hope ye who enter here.” And a kind of icky hex grid background and default wallpaper, as if drone-like creatures are going to lay their proprietary eggs in your brain and cause you to surrender your will. Ugh.

Why does the Oracle logo look so out of place on a GNOME desktop where the OpenSolaris one didn’t? Seems strange to me.

Anyway, it seems that Oracle have delivered a technically sufficient OS release for SPARC workstations. I can start compiling stuff on it now (some setup scripts will surely be added to the -460 repo as I carry on with that). Making a SPARC machine a usable development workstation takes another whole bunch of packages, just some of which are the Mercurial and the C++ compiler (you could choose gcc instead, but that’s not the mandate of the KDE4-OpenSolaris project). The Sun compiler is not available from the Solaris 11 package repository right now, so get it from the older OSOL repo:

pkg install mercurial
pkg set-publisher --non-sticky \
  -g http://pkg.opensolaris.org/release/ opensolaris.org
pkg install sunstudio12u1

Dion Moult has just called for people to help out with fighting the wall of text that is www.kde.org. I just started with ev.kde.org for somewhat the same reasons. The KDE e.V. website explains what the e.V. does. You can find blog items about KDE e.V. here and there — for instance, from Sebas regarding the recent board meeting or the previous meeting in may, or from myself on the november meeting or regarding the -vorstand list or mentioning it in passing around Akademy. And our president, Cornelius Schumacher, wrote a nice what-is-KDE entry in October of this year. Frank and Celeste don’t tend to write about KDE e.V. business as far as I know, but I’m tired of searching right now.

So every now and then we try to explain what KDE e.V. is, what it does, how it’s run and what the KDE community can expect from it and how the KDE e.V. membership can contribute to the success of the association. I often liken KDE e.V. to a city’s amateur soccer association. You can play soccer without being a member, but if you want to support soccer in the city in a general fashion — for instance lobbying to make sure that the city keeps playing fields accessible — then being part of the association becomes important.

Anyway, that kind of stuff needs to be on the KDE e.V. website without being a wall of text.

The KDE e.V. website has an additional challenge right now: it switched its look from the older KDE 4.0 look to the latest "Chihuahua" technology produced by the KDE web-team. It looks much nicer now — even if it is width-limited to 800px. However, navigation has suffered because the e.V. site has a bunch of specific documents that are most useful, together with a deeper tree of stuff.

I have started by adding a "quick links" box to the front page, pointing to specific contact information, members and the most interesting forms and events things. Note that we don’t have a really good setup for the forms and events right now, that’s something to be partly automated and generally improved in the next weeks.

What I’m looking for is people who will go over the e.V. site checking links, double-checking texts, pointing out ambiguities and missing information, suggesting navigation improvements etc. etc. Throw stuff in the comments on this blog or send them to kde-ev-board (in the domain of KDE). Most important though is probably getting some nice graphics for various bits and pieces. I’d like the quick links box to have some cutesy icons (Eugene, this means you!). Some identifying graphics elsewhere as we run into identified needs. Perhaps a little CSS spice here and there.

The KDE www team lives in #kde-www on Freenode, and the KDE e.V. website lives in /home/kde/trunk/www/sites/kde-ev on KDE’s SVN server.

I really like it when new software packages are mentioned in blogs or on the dot. Those — based on a combination of personal interest and seeing how the community reacts — drive my selection of packages for OpenIndiana and OpenSolaris (such as it was). Something like the dot story on Sentinella says to me “this is interesting software.”

So I’ve started to package Sentinella, and you can find progress in the -460 repo. What progress? You ask. Yeah, it’s not trivial and the code shows some gcc-isms, for which I have filed bug reports. So as of this writing, there’s no Sentinella spec file in there. It’ll come.

I spotted a new poppler release (1.5.2) in its work towards a 0.16 version. I think I spotted that in a Freshmeat RSS feed somewhere. Packaged most of that up, although it too has some gcc-isms. Balked at registering for the FreeDesktop bugzilla, here are the patches. A gcc-ism for variable-length arrays, introducing a Solarisism for RPATH, using the <ios> header to get std::hex and std::dec, and a gcc-ism around unicode strings. Simple.

Speaking of unicode strings, it seems that gcc will take “\u0161″ as a unicode string and encode it in UTF-8 as two bytes. The Sun compiler doesn’t like that as it interprets \u0161 as a UTF-16 character, which doesn’t fit in a char. On the other hand, U”\u0161”, a unicode character string, is not a char * but a short *. I ended up using gcc to determine that “\u0161” is the same as “\305\241” (octal!) and patched poppler to use that.

But while searching for some information on unicode strings, I found Lukas Lalinsky (see, no unicode for me; sorry Lukáš) blogging about taglib releases, so I bumped that one as well.

I guess the summary answer to “how does software end up in the KDE4-Solaris specfile repository and package server?” is “it’s a crap-shoot depending on what I notice.” That’s not entirely good, but it also means that we’re largely driven by KDE needs.

In closing, a shout-out to Jarosław and the KOffice folk for providing some really useful information for packagers. That deserves a whole separate post (e.g. when KOffice is indeed packaged for OpenSolaris and OpenIndiana).

As Sebas has already noted, there was a KDE e.V. board meeting over the weekend. I had Claudia, our business manager, over on wednesday and we had a good thursday at the NLUUG Fall Conference on Security (where Claudia ran the booth and I was acting as part of the NLUUG board). I think there’s a real advantage to getting together before a board meeting and spending some time chatting and whatnot — it takes those topics out of the meeting time and allows us all to synchronize a little on what the current issues are.

You might claim that the main issue was horrific weather, with storm, rain, more rain and cold going on in the city of Nijmegen. I might claim that the main issue was how to eat all the food.

Another issue we ran into was the visible lack of visibility (!?) of the documentation for Sprints and developer events. Sjors is the catalyst here. I think we spend about half of the total KDE e.V. budget on sprints (the rest is Akademy and office and personnel costs), and you can find plenty of mention of events in the quarterly report (PDF) or on the Dot once they’ve happened. So the board thought that the sprint organization mechanism was pretty obvious, and it turns out it’s not.

But thanks to that realization, we now have Sjors being all enthusiastic about a KMess event, and I’m starting to plan an KDE4-OpenIndiana event and there’s something I need to cook up further with Celeste, too. So expect more entries in the upcoming-sprints department soon. One of the tasks I’ve taken away from the board meeting is to improve the sprint HOWTO with perhaps some more fine-grained instructions or checklists. But I’ll give my own interpretation of what a sprint is and what it’s for first:

A sprint is a single event, highly focused on technical results, in one location with a short time frame (a week or less) and a single topic; the topic is most often development of an application or library. A sprint is organized by an existing development community, and has a small core group of attendees (six to ten people). A sprint is 80 percent sweat (e.g. getting work done and of that, let’s say 60/40 for doing stuff and planning future doing) and 20 percent social.

You’ll note that some things we call sprints aren’t, by this personal definition. Those events are swept up by the more general term “developer events.” It’s not like we hold up events plans to this simple descriptive yardstick — feel free to come up with something else.

KDE e.V. supports the organization of these events — financially, sometimes administratively, and rarely (simply because it’s almost never needed) organizationally. However, KDE e.V. doesn’t come up with its own sprint ideas, nor will it (generally) approach people saying “you should do a sprint.” It waits for (sub)communities within KDE to come up with something and to show off a plan — or even a sketch of a plan — before starting to act.

So, to paraphrase the A-Team: if you (collective, addressing a developer community) have a problem, and no one else can help, maybe you should get together to solve it — and then you can ask the K-team (KDE e.V.) to support your efforts by covering the costs of getting together to solve that problem. ( — Ed: that’s not a very good paraphrase at all.)

Thanks to the fine folks at Belenix and OpenIndiana, the package serving mechanism for the KDE4 OpenSolaris packages has changed. Changed for the better, because we now use Apache HTTPD to serve up the files themselves. This removes one of the big issues with our earlier package-serving setups, which was that connections and downloads were unreliable and it could take many many attempts to get a large file.

The trick is to use Apache with a reverse proxy (ProxyPass directive) to pass on some requests to an internal pkg.depotd and to use a rewrite rule to modify other requests to match the on-disk layout of the repository. Sriram N, Shawn W and Alastair helped out in finally pushing this out the door.

As a side effect, the correct publisher to use for KDE 4.5.3 packages — including the Plasma Desktop, KDE Platform and KDE applications — has changed. We will no longer be futzing with port numbers in public, but instead have a human-readable URL. To set up your system to use the latest KDE packages, use

pkg set-publisher -O http://solaris.bionicmutton.org/pkg/4.5.3/ kdeips-dev

That particular URL will only serve 4.5.3 packages and such updates and additional applications as slip in. Eventually, we will get a /4.5.4/ package repository as well. We’re still debating a little on how to do a “4.5” or “latest everything” repository. Some measure of deduplication would be nice if we’re going to be serving up multiple repositories.

SysV packaging: On a vaguely related note, I’ve regularly had to battle SysV packaging on OpenSolaris. The legacy packaging system (pkgadd, pkginfo) and the new package system (IPS, with pkg as the main tool) are usually well-integrated, but there are edge cases that break stuff — usually the legacy bits. However, the build system (pkgbuild, which is pretty much rpmbuild for Solaris as I understand it) uses the legacy package system for information even while it builds modern packages. So that means I sometimes have to fool pkginfo(1) into thinking that a particular package is installed (or not).

To fool pkginfo(1), you need to manipulate the directories in /var/sadm/pkg. There is a directory there for every package on the system that is known to the legacy packaging system. To hide a package, just thrown away the directory (probably tar it up). Each directory holds a pkginfo file, which is a straightforward key=value file; to tell pkginfo that a package exists, just create a directory of the appropriate name and copy an existing pkginfo file in there, then adjust the contents so it vaguely makes sense. The important settings seem to be PKG and PKGINST. The rest is important only if you’re dealing with officially supported software.

Future of Solaris10 packaging: The specfile repository that we maintain has a lot of material that is there specifically to support Solaris 10. The people who are active in the repository don’t use S10, and I think the complexity imposed by supporting OSOL and S10 is starting to hurt. If we’ve got a complexity budget, it would be much better spent in supporting OSOL and OI (e.g. the future) instead of the past. No concrete plans yet, but I can imagine us tagging the repo at some point with eol-s10 and then ditching all the Solaris 10 support. Thanks to repository history, it’s not really gone, but won’t burden us in the future.