Bobulate

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

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

The OSOL appliance released by Jignesh Shah is 2009.6 — nearly a year old now. Since then the packaging tools for OpenSolaris have made great strides. IPS remains .. interesting. I’m not entirely convinced that it was worth the effort of not using some of the existing package formats. However, by now I understand the API it brings in as well as the various uses of the tool, (and it crashes no more) so I’m starting to like it.

Anyway, the point of this particular appliance is to host KDE4 packages for OpenSolaris in an IPS repo. To do that means running the IPS pkg.depotd. I have a port of an older version of pkg(5) to FreeBSD, but it all seems a little klunky and hard to maintain. So using an OpenSolaris VM seems the right approach.

Except that the OSOL VM from Jignesh is kind of old, isn’t it. So I ended up looking into upgrading the OSOL VM after installation, and ended up with the following steps:

1. Set the publisher to the dev branch: pkg set-publisher -O http://pkg.opensolaris.org/dev/ opensolaris.org . This means that future packages will come from the dev branch, not the released branch.
2. pkg refresh --full to fetch all the new package references.
3. pkg image-update -f (I have to force it, because something’s wrong with cherrypy and the image will not update otherwise) and wait a while while 138MB of package updates are downloaded.
4. Reboot into the new boot environment (VOSApp-1). This will fall into a root shell for fixit-purposes, because the filesystems are messed up.
5. Fix mountpoints for those messed-up filesystems and reboot again; I recall I needed to re-set a number of zfs mountpoints to get the correct organization for regular system operation. Bear in mind this isn’t needed with normal OSOL upgrades, just for this slightly peculiar application setup. I think I had to set the new rpool/ROOT/VOSAPP-1/opt/ (and var and root) to mount in the right places and move the older rpool/ROOT/VOSApp/ filesystems to somewhere in /mnt.
6. Reboot, possibly fix up remaining mountpoints, then zfs destroy the old ones.

There’s a useful HOWTO entry on updating OSOL to a specific build which I might otherwise have used, but the appliance image does not have an entire package installed which could be used to drive the upgrade. Hence this slightly klunkier approach.

Since Jignesh has left Sun, I’m not sure if there will be any future growth in these appliance builds. They were popular enough in Nigeria, where I distributed verbatim copies of the original (probably still in violation of the license terms though) to people interested in running OSOL at all.

For some of the things I would like to do with the EBN code-quality checking machine — things outside the immediate realm of quality checking — I need some VMs beyond what FreeBSD’s jails give me.

In particular, I need Solaris running on the machine as well as FreeBSD, so I looked into VirtualBox. I’ve used it on Solaris for various purposes (including running FreeBSD) so it seemed appropriate. There’s no binary version of VirtualBox for FreeBSD, but you can compile the Open Source Edition from ports, so that’s what I did. The results — missing USB passthrough and no RDP — are things I can live with, as it just means I’ll do most of my work on the VMs through ssh.

Installation (of VirtualBox OSE 3.1.6) is pretty non-eventful, the remember-to-load-the-kernel-driver reminder at the end of installation useful, and it just works.

For testing purposes and to satisfy some curiosity on my part I decided to install the Maemo development environment provided by Nokia (hey, maybe I’ll write my first GTK+ program like that). This turns out to be a VMDK (VMWare) file, not a OVF file, so a little bit of fiddling about was necessary. There are installer scripts available with lots of disclaimers for VBox 2, but none for version 3. So I tweaked and twiddled a little, and ended up with this installer script that calls VBoxManage a bunch of times to set up the machine. This is largely cribbed from Nokia’s script, adapted for new syntax in version 3.

One thing to note here is the invocation with –usb on. That could be combined with other calls to VBoxManage, but since the OSE has no USB passthrough, this will fail. For those using the non-OSE version, the call will succeed. Run the script with either –add or –remove from the directory containing the .vmdk file and it’ll set things up or tear them down.

In the resulting VM I haven’t gotten any further than starting esbox and quitting it again — but it shows that the VM works, that the apps work. I can ssh in for whatever command-line work I need to do.

The upshot — after all, the Maemo dev environment is just an experiment — is that a Solaris VM will happen real soon now. I was hoping for something jeos-like, but I hear that the people responsible for that have left Oracle now (this looks like a common theme: all the nifty Open Source but non-revenue projects are bailing out). So I’ll have to find another means of installing a fairly-minimal OpenSolaris version into the VM (which, thanks to Jignesh, is a matter of VBoxManage import). For my purposes no X is needed, so that saves us at least one (if not two) desktop environments in the disk image.

Credits where credit is due: to Jignesh Shah for the OSOL image and to Miwi for not only porting KDE4 to FreeBSD but also acting as source of information for VirtualBox.

A while back I mentioned OpenSolaris packages for KDE 4.3.2, and while strictly true, they weren’t anything to write home about particularly. Some time — and some weekends at home, which is the critical bit — has passed, leading to improved specfiles; I have not published a full package set anywhere public yet.

Main issues that were gotten out of the way: nepomuk-rcgen was crashing on runtime-linking because of bad library order. Minor compile error in kdenetwork, already committed in trunk. That gives us all the regular KDE SVN modules again, plus konversation. I haven’t tried Qt creator this time around. Remaining obvious runtime problem is Akonadi, which doesn’t find the MySQL server (in /usr/mysql/bin, but then I can’t find a way to configure that at all, and all the akonadi tools segfault on startup anyway).

In any case, one step forward, meaning it might be almost done by the time KDE 4.4 comes out.