Bobulate

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).

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.

I recently mentioned that Plasma Desktop and KDE applications 4.5.2 was building. It’s done now and the repository has been put up on solaris.bionicmutton.org. This uses a Linux port of pkg.depotd, rather crudely hacked together by myself. That should ease up some package downloading issues.

So, users of KDE4 on OpenSolaris and OpenIndiana, it’s time to update. Remember to file bugs at bugs.kde.org with the OS set to Solaris, and drop by #kde4-solaris on Freenode.

PS. There was an article up on a Dutch website with “5 best things Oracle did for Open Source” and one of them was “Kill OpenSolaris”. Hm. PPS. Konqueror does crash on Flash games sites, somewhere in kjs. On the plus side, DrKonqui now produces nice stack traces with dbx.

Now that the october updates for all the software shipped by the KDE community — that is, Plasma Desktop and the applications — has been released, it’s time to bump versions, etc. and kick off a bunch of builds. This follows the tried-and-true approach of replacing the version number (i.e. it now reads ‘%define kde_src_ver 4.5.2’), running make, waiting for the pkgbuild tool to report failures, fix, rinse, repeat. Usually the things we fix are just new or removed files. In this release, for instance, KHelpCenter has a new documentationnotfound/ directory and some files there.

During this period, our so-called stable (-450) repository is not stable. Fixes to the packages get pushed as and when they are found. Once the builds are stable (i.e. a few of us have managed to get everything to build), then Hajma kicks off a clean build on our build server, waits about six hours for that to finish, then uploads the whole darn thing to the actual binary IPS package server. And then people can update as they like.

I won’t vouch for the stability of updating. We usually take the ‘pkg uninstall -r hier-kde4-deps ; pkg install KDEconsolidation’ route, which is also known as ‘log into JDS, rip out all of KDE, install a new one’. One day we hope to look at that more closely.

Our IPS package server runs in OpenSolaris in a VirtualBox on an OpenSuSE machine. There’s issues with networking in that setup; I’m a little hazy on the details but it means that downloads often crap out. There’s 1226 TCP connections in FIN_WAIT2 state right now. That’s also a sign that people are actually using Plasma desktop and KDE applications on OpenSolaris and OpenIndiana. Apparently folks are overrunning the OI IRC channel asking what’s wrong with our package server — ask in #kde4-solaris, folks.

Since the server setup has been giving us some problems, I cloned the pkg source code repository from Oracle and now have a copy available in our Mercurial repository. The purpose of the clone is to hammer the system into shape so it can run on Linux. It seems Onno M. has done something similar, to the point of producing packages of same via the OpenSuSE build service. In any case, the idea is to drop the VM and additional OS from the equation and make pkg.depotd serve packages directly from Linux. This needs some testing, but I imagine we will be switching over for serving up 4.5.2.

Finally Michael will be able to install KDE software without a week’s worth of disconnects.

[[ While I typed this story, I built the KDEsdk, KDEtoys and KDEutils packages; changes here reflect the renaming of kdesvn-build to kdesrc-build. KDEtoys has no changes, and KDEutils incorporated one of our patches from 4.5.1, so there was a patch to remove. ]]

Two last tidbits: I managed to utterly break my OSOL VBox, so I now do builds on OpenIndiana virtually and on physical hardware running OSOL. Packages are produced in OSOL b.134 and work unmodified on OI b.147 and later. The -460 repository is in the throes of a massive cleanup since the range of supported platforms has shrunk recently: it’s either Solaris10 (untested except by the hardiest of souls) or OSOL b.134 or OpenIndiana, pkgtool 1.3.102 or later. That means cleaning up tons of cruft and special-cases. Once that’s done, there looks to be a bump to Boost (to 1.44) and some Qt mucking about.

[[ OSOL-only entry here, with interest for KDE only from the perspective of “it’s a package server that will be serving up the KDE packages for OSOL”. ]] There’s some bits and pieces involved in setting up an OSOL appliance to be actually useful for serving up packages, so I thought I would document them here.

Adding a user and configuring ssh access: The adduser command in OSOL is a little arcane compared to the interactive versions available on FreeBSD and GNU/Linux, so may as well: useradd -s `which bash` -m username and remember to set up ssh access for that user. This user is also going to have the pkg repository available.

Making sure that the user can ssh login: On my OSOL appliance, /dev/ptmx is missing (which is a known problem, see this forum thread with the always-helpful Alan Coopersmith on it), so I followed the instructions there.

Setting up static IP: The appliance is configured to use DHCP from the local network. For my later use I need a static IP, so I picked 10.0.0.26 and solaris.bionicmutton.org as hostnames (there’s already a host with that name, elsewhere, which is the current FreeBSD-based package server for KDE’s OSOL packages). I added the hostname and IP in /etc/hosts, checked that /etc/nsswitch.conf was using files and dns, edited /etc/nwam/llp to set the interface to static IP (as described here), and added an /etc/hostname.e1000g0 matching one of the hostnames I had just set up. One reboot later (presumably svcadm restart would do, but it didn’t work for me in my haste), things were working and I could ssh in. While I was at it, I also modified /etc/nodename to use the new name of the machine (see, for instance, this thread on changing the hostname).

Setting up pkg.depotd space: As root, I ran pkg.depotd once to set up the repository space before setting it up to auto-start. /usr/lib/pkg.depotd -d /export/home/pkg -p 10000 --set-property publisher.prefix=solaris.bionicmutton.org starts the server. I checked that it was working at all by visiting 10.0.0.26:10000 from the host machine and then I stopped the server again.

Further configuration of pkg.depotd: Next, I use the Service Management Facility (SMF) to configure the package server further. svccfg -s application/pkg/server starts a command-line for configuration purposes. I set the port and root directory for the pkg.depot server here:
setprop pkg/port = 10000
setprop pkg/inst_root = /export/home/pkg
After that bit of configuration was done, I used svcadm refresh svc:/application/pkg/server ; svcadm restart svc:/application/pkg/server to start up the package server by hand, and checked once again that it was actually running. Then I rebooted, and checked that it was running still, just to be sure it will come back under a reboot of the host.

Minor remaining configuration issues: I switched off atime on the filesystem hosting the package respository, so that those are not updated on every package view (zfs set atime=off rpool/export, which reminds me I could have gone for a finer-grained setup by creating a filesystem for the packages first). I also set the read-only flag so that people can’t just publish into this repository — the KDE4-OpenSolaris people use tarballs + ssh for that. I also modified some settings in /export/home/pkg/cfg_cache to reflect the purpose of the repository better.