NLUUG Fall conference 2011

So, with NLUUG’s spring conference behind us, it’s time to look to the future. A future that actually started 10 years ago but is only now becoming really darn important except that not everyone’s paying attention.

I’m talking, of course, about IPv6, not the port of KPresenter to KDE3 by Carsten Niehaus (r86549).

The Register has a nice IPv6 WTF article, which in turn points to World IPv6 Day. There’s a Dutch IPv6 event on June 8th, too.

All this run-up is to point out that the NLUUG fall conference 2011 is october 20th (a little earlier in the year than usual) and the theme is "Netwerken: IPv6 en de rest." or, in plain English, "IPv6 and all that Jazz". The posters are printed, the Call for Papers, Abstracts and Vague Statements of Intent will go out sometime soon.

That said, there were various people grumbling about the lack of IPv6 connectivity at the spring conference, so there’s also technical and infrastructure work to be done, not just getting a good conference programme together.

Some things Oracle just doesn’t get

Yesterday at the NLUUG conference I picked up a Solaris 11 Express CD in a nice brownish CD sleeve (I say "nice" because it feels and looks different from the generic white sleeves). Here’s a scan of the back of the sleeve, with a big sticker over the flap (click on image for a larger, readable version).

scan of cd sleeve

I thought shrink-wrap licenses went out with Disco, or something like that?

A little searching gets me to the license text so I can read it before opening the package to get at the license itself. The one saving grace is that the license condition is "opening this sealed software package and using the software" (emphasis mine) so it’s not classic shrink-wrap.

In classic fashion, though, I can’t give away this CD to someone else, not even if they want to use it to develop or demonstrate an application on Oracle Solaris.

If we turn to the license text itself, the section on "Open Source Software" rubs me in every possible wrong way, starting from the definition

"Open Source" software – software available without charge for use, modification and distribution – is often licensed under terms that require the user to make the user’s modifications to the Open Source software or any software that the user ‘combines’ with the Open Source software freely available in source code form.

It’s increasingly difficult to engage with Oracle Solaris except as a commercial entity; increasingly difficult to easily check if the software you produce (you in the sense of "a Free Software community") might work on that OS. Combine that with a compiler that’s also increasingly hard to get and, well .. it certainly seems like there’s no interest in third-party software development except on a commercial basis.

We’ve been keeping Qt on Solaris (with Sun Studio) going for three years now. That has led to many patches in the compiler, many in WebKit, and most of the time we’ve got a good working relationship with upstream (i.e. Nokia / QDF). I still think we can deliver a Qt suitable for other applications’ use (maybe not VirtualBox, but that’s still dreamable). Now the Qt modules maturity list shows that Solaris (along with the proprietary UNIXes that still exist; remember at some point Solaris distinguished itself from those by being reasonably-almost-open) is "done". Needs new maintainer. That bodes ill from an upstream-support perspective.

Note about the compiler: you can’t get patches (beyond the released 12.2 version) without a support contract, as far as I can tell. So there’s no easy way to get a version of Sun’s C++ compiler that has all of the bug fixes prompted by the KDE4-Solaris project. The partly-patched version I still have on my Solaris machines is falling behind, so that I can’t even compile all the stuff I’m trying to package. This is one of the reasons the KDE4-Solaris project is looking hard at both gcc and Pathscale.

NLUUG spring conference 2011

Yesterday (the 12th of May) was the NLUUG Spring conference 2011. The theme was "Open is Efficient" — a theme which can be explained any number of ways. Keynotes were along the theme of the social contract and cooperation, and the technical talks were mostly about cost- and time-savings.

I followed three technical talks (the most I’ve had in years, since usually I’m too busy running around checking on the vendor stands and doing last-minute organizational and board stuff) and quite enjoyed them, although 45 minutes is too short to dive in deep when the speaker starts off unsure of the technical level of the audience. At NLUUG conferences, the range of attendees is pretty big, so it can be difficult to judge where to start.

Mayur Nande talked about systemd, its design and philosophy, compared to other init varieties like SysV init, upstart and launchd. I had the please of sharing a train with Mayur after the conference (all of 12 minutes to Arnhem), so I could ask a few more technical things of him. I don’t mess with init systems very often (limited mostly to scratching my head at what SMF is doing on OpenSolaris) so this was a good introduction so I know what my Linuxes are doing.

I missed Jos van den Oever and his talk on WebODF. Drat.

Micha Kersloot dove into the details of migrating (partially) away from Exchange with the Zimbra suite. This is a talk I went to for work-work purposes, since getting away from Exchange is on the list-of-wishes for work-work. Being able to dump Outlook in the process is just a bonus. Interestingly, Micha said that he preferred Zimbra’s webmail client for ease-of-use of KMail. Inconceivable! I’ll have to look into it.

Magnus Hagander gave a whirlwind talk about Postgres 9.1 beta. I’ve been partial to Postgres forever (over other available Free Software databases) but the last time I installed it was version 8.2 and I’ve never done anything big with it. This overview of cool new features — hot streaming replication, weird-ass subqueries — made me repeatedly scratch my head and go "hey, postgres can do that?" Much appreciated. I’ll probably attend the Postgres Conference in Amsterdam to learn more. I though Magnus’s talk was great: well delivered and technical.

Then bought a book on DTrace, begged a Google Women T-shirt for the MomC, and ran off into the sunset.

This NLUUG conference marks the end of my involvement with the NLUUG as part of its board. I joined the board 4 years ago, and as my term expired I found I just didn’t have the time — what with working a regular job outside of the Free Software world and being involved with KDE and other things — to participate properly in this particular association. Pieter-Paul Spiertz and Marcel Nijenhof have joined the board (come to think of it, I should update the board webpage) so it’s at full strength.

Open Source alternatives for Skype

So with Skype — already proprietary software, already dubious — probably going to Microsoft (as I read via Simon Phipps to the Grauniad and Johan Thelins) there’s an extra impetus to find something else.

I’ll just highlight Blink, a Python/Qt4 application for VoiP calls, video and chat (the latter I believe only on Mac and Windows right now, but the application runs on Linux, FreeBSD and I think I had it on OpenSolaris briefly, too) and SylkServer, a SIP server and conferencing solution.

Both are simple to set-up, are packaged for Debian, easy enough to get for other distro’s and give you a complete, Free Software, SIP server and client infrastructure.

It’s easy enough to escape from Skype to an open-standards-based world.

Get on Git

(This post has nothing to do with Aaron’s gitit post – different topic altogether) I was building OpenIndiana packages of KDE 4.6.2 (the plasma workspace and some of the application bundles, to start with) when I encountered a compile error. Simple enough fix, too: add a single newline to a file in plasma-addons. That’s a little oddity in C++ source files, they must end with a newline, and it is particularly important if the last line is #include.

Hence. motivation to actually get git, get a checkout, and commit the fix back to upstream. I know I’m set up for all that, through identity.kde.org (register for developer accounts), and I know KDE SVN well enough. But never git.

So where to start? That was the question for me. And I found that the existing documentation leaves something to be desired in terms of discoverability. Here’s a first shot at some extra tekst to document it a little better.

The question I have is "how can I get KDE source, make a change, and commit it?" This presumes a properly set-up KDE developer account via identity.kde.org and working SSH with that developer account. A scripted build is not what I want (even if doing one would probably get me the required files behind-the-scenes).

My starting point is KDE TechBase. Good thing: there’s a "setting up a KDE development environment" right on the front page. (Please note that the TechBase pages are always being updated and there’s some work going into documenting these things better already, so some of my issues may go away — maybe go away faster if someone cuts-and-pastes some of this into TechBase itself).

Clicking through the Getting Started bit, I end up in the section Obtaining the Source Code, which forwards me on to projects.kde.org. There’s mention of source snapshots, but those are for SVN, not git.

I find the front page of Projects a bit intimidating, but that’s because it’s such a big list, and some projects have descriptions and last-modified information and some don’t. Calligra could definitely use a better description — "we do stuff with things" is not a successful tagline for projects, even when Paul Adams is involved.

OK, so "obtaining the source" sent me here, and I can find the repository I know I’m interested in, namely KDE Plasma-addons. That page doesn’t tell me a whole lot, but I can click on the "Repository" link as a best guess. Once there, the "SSH" button gives me the git command to enter (in a terminal) to actually get the clone of the repo. That command looks like so:

git clone git@git.kde.org:kdeplasma-addons

Having reached this point, I can take the command apart and presume that "kdeplasma-addons" is the name of the repository. Other repo names are "kdelibs" or "kde-baseapps" or "kde-workspace" or "kdepim" — there’s dozens, but having the scheme clear once helps.

So here’s my additional blurb for the "obtaining the source" section:

To get the source of a particular (sub-)project from git, find the name of the git repository at projects.kde.org. The name can be found by clicking on the "repository" button once you have navigated to the page for a given project.

For read-only access (e.g. to keep up-to-date but not to push your own changes), use the URI git://anongit.kde.org/<project> . For read-write access, use the URI git@git.kde.org:<project> . In both cases, the command to get the sources is then git clone <URI>, e.g. for the plasma-addons project the complete command for read-only access is

git clone git://anongit.kde.org/kdeplasma-addons

I believe that adding some text like that so that it’s clear where you’ll be navigating to would make things a bit less intimidating to folks just starting with the git infrastructure for KDE.

Anyway, once you’ve got the source code you still have to deal with the rest of the git workflow, but I imagine that will be documented at some point (I seem to remember someone on planetkde pointing to several tutorials recently). I just pushed my first ever change to KDE git (less daunting than I expected). If Lancelot is now broken, you know who to blame 🙂

PS: and if you’re wondering why I didn’t just go and add that to TechBase, it’s because I’m not sure that it’s entirely (a) technically accurate (b) appropriate at that place in TechBase. I’ll leave it to TechBase editors to think about that.

Quassel bump on OpenIndiana

Folk — ok, just Johannes — showed up in #kde4-solaris asking about Quassel packages for OpenIndiana. Quassel is a disconnected IRC client, useful if you move from computer to computer regularly and want to take your IRC session with you. We have a specfile, but it isn’t built as part of our usual KDE consolidation. The specfile was also still version 0.3, which is pretty darn old.

With that as motivation I’ve bumped Quassel to 0.7.1. It compiles, without much patching (available in the Mercurial repo), just one gcc-linuxism related to stacktrace C++ name mangling. Easy to replace with the code we already use in kdelibs, or for simplicity with backtrace(int fd). Packages will be available shortly.