Bobulate
Home [ade] cookies
Extended downtime for EBN
May 11th, 2010
Overconfidence goeth before a fall, they say. The software upgrades on the EBN machine are taking a good deal longer than intended. Part of this is some unexpected trips I had to make, but mostly it’s just that 6.2-6.4-7.4-8.0 is a lot of buildworlds (which take surprisingly long!) and reboots, followed by the realization that the jails need upgrading too to work at all (although the ports may continue to work, the base system doesn’t).
All in all it’s just taking a lot longer than intended, but it’s coming back bit-by-bit, rest assured.
Also, I should say that Sun’s ILOM really rocks for remote management, since I needed a great deal of console access to get this done, and I don’t feel like sitting in a cold and drafty datacentre to do so — not with this ongoing hacking cough and headache, no sirree.
Running a local pkg.depotd in an OSOL appliance
May 6th, 2010
[[ 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
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.
Updating OSOL Applicance to b.134
May 5th, 2010
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:
- 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.
- pkg refresh --full to fetch all the new package references.
- 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.
- Reboot into the new boot environment (VOSApp-1). This will fall into a root shell for fixit-purposes, because the filesystems are messed up.
- 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.
- 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.
Planned downtime on the EBN
May 5th, 2010
The server running the EBN (a Sun X4200 running FreeBSD — soon to be running OpenSolaris in a VM) is getting a bit long in the tooth, software-wise, and it turns out that it can no longer even run all of the software needed for improvements to the EBN. Bertjan has been bugging me to update it, which I can’t until I update the whole machine from 6-CRUFTY to 8-STABLE, so I’m going to plan some downtime for the EBN machine: this weekend, 8 and 9 may 2010, from 12 noon (GMT) on the 8th until midnight (GMT) on the 9th. That should give me enough time to bring the machine down, make additional backups, upgrade the heck out of it (all except hardware, unless someone cares to donate a pair of ECC Registered DDR2-800 DIMMs) and bring it back up. There may be some additional downtime on Monday (but only brief) as some disks are swapped and I correct some historical mistakes in the machine’s hardware configuration regarding disk layout and management.
Sites affected: the EBN itself (www.englishbreakfastnetwork.org) and the KDE4-OpenSolaris package site (solaris.bionicmutton.org) and some personal sites, including Sebas’ vizzzion.org, bionicmutton.org and euroquis.nl.
Back on the Mainland
May 5th, 2010
After a week in Kano, Nigeria — where I picked up my awesome cold again, the same one that has been keeping me low since January — I spent a few days on the Dutch island of Terschelling with the family, to get back into the swing of things. Let me tell you, trading 40 degrees and dust for 12 degrees and rain doesn’t help much. Not much actual KDE coding planned this week, partly because of the NLUUG spring conference on Systems Administration (where I’ll meet up with Rainer from the FSFE and Donna from the Amsterdam Girl Geeks).
FOSS Nigeria 2010 report
April 27th, 2010
It’s a cold and windy day here in Kano; that’s comparable to a nice warm day in summer in Nijmegen, so I keep explaining, and sitting around in shorts on the steps in front of the university guest house at BUK old campus this morning was very nice.
Frederik has already blogged a bit about the conference and talks and added some pictures — pictures which are quite similar to last year’s bunch, which you can see at a-ig’s blog from last year. I will try to write about the way we prepared for the conference and what our contribution is. We sort of go to the conference as rock stars, but in all honesty there is a great deal we don’t know (and we say so). Just last night, over a fanta at the CS student’s joint here at BUK, I learned a great deal more about Debian packaging and how to effectively share packages when only limited bandwidth is available. Something to add to my trove of knowledge and to share when someone needs it.
So in a sense we (Frederik and myself) act as catalysts, triggering other people to come forward and share their knowledge.
In these past two editions of the FOSS Nigeria conference, the conference schedule has not been fixed beforehand except in the broadest terms (Friday the whole day except for Juma’a prayers, Saturday afternoon, Sunday the whole day until 4 for the closing ceremony) and it hasn’t been clear just how much we’d be speaking anyway. So we prepared some introductory talks on Free Software: what is it; what do software licenses do; what is Linux; what is GNU; how do Free Software projects work; why (and how) you can contribute. For these introductory talks we had slides prepared beforehand; on the evening before the conference we discussed with Mustapha what the schedule should be and how long the talks would go on.
During the conference itself we take questions on paper. The conference writing pad is heavily used for that. The reason we don’t take the questions at the end of each talk from the audience is that that takes too much time to do right — it would mean more mikes, walking into the audience, etc. Also, some of the questions take some serious thought before answering. So we take notes. All the questions are collected and we type them up into slides during breaks or during each other’s talks. Then whenever convenient we do a Q&A session where we go through the question slides and answer them as best we can. Typically that gives us a 45-minute session right after lunch and one at the end of the day. Some questions we got this year:
- Can you tell us about some Free Software application for agriculture?
- Can VirtualBox access my Windows partition directly?
- Can I have your autograph?
- Is there a Free Software replacement for SPSS?
- Please demonstrate some 3D and animation tools under Linux
- Is there a good forms and reports generator for MySQL?
Dear Lazyweb: do you have good answers for these questions? Because we could say “umm .. maybe” ; “probably, but I think it requires guest additions” ; “yes, see me later” ; “I think R does the stats part but I don’t otherwise know” ; “there’s Blender, but I don’t know how to use it” ; “I don’t know”. Really makes you feel useless going over answers like that.
Fortunately a local business is specialized in using Blender for architectural modeling and walkthroughs, so they gave a presentation on the third day of the conference on how they use a Free Software tool (Blender, of course) in their business. “Using FOSS to be your own BOSS”. They said they decided to give their talk after hearing our rather limited answer about 3D, so that was a great catalytic moment.
After day 1 we sat down to plan day 2: who else is talking, how long, what makes the most sense for the audience based on the questions we have had now. So day 2 got a bit more of a practical slant for the afternoon — the morning was taken up by LPI exams. At the end of the day we still had 30-odd questions left in the queue to answer, and not much material for the next day, so we spent the evening writing up slides for new topics and dealing with the bits of paper we’d been handed.
Day 3 turned out to have no slots for us except Q&A sessions, because there were four other speakers including the Blender guys. That’s a great sign, so we skipped our KDE multimedia and Javascript and Python talks to listen to what was happening in Free Software in Kano and surroundings. Blender; databases and web portals; how to make money with Free Software.
There was also an announcement of a Kano Python users group (PyKano) in an effort to get some more Python development off the ground here. I dare say that was one of the best moments of the conference, the launch of a concrete, short term project to improve the software development and ICT community in Kano and promote Free Software at the same time.
A number of translation efforts have been pushed forward as well during these three days. The keyboard stuff I’ve written about is part of an effort to make it easier for everyone to type translated strings. I believe that we’ll get a big influx of Hausa translations over the next few months — probably by email through me, so I’m going to end up as translation coordinator for a language I don’t speak — as well as new work on Kanuri, where first we’ll have to figure out what the language code for it even is.
Next day or two I need to get a translation environment set up here so I can explain better how to begin doing the translations, including tools for testing and whatnot. That means running Lokalize and figuring out how it works. It looks rather intimidating compared to vi applied to the same data.
Anyway, returning to conference planning and the like: the schedule here is a living, changing thing that requires plenty of flexibility, but that makes speaking here such fun. It’s also a broad conference and a great chance to learn many new things — not in the least because we get asked about everything so we have to research a little about everything as well. Expect the unexpected, I guess.
Planning is underway for next year, probably in a different city and with any luck there will be some satellite events as well in outlying towns; if that means traveling around for a few days extra to help ICT in Kano and other states and to spread Free Software (low-cost, freedom-granting, straightforward and by-the-rules Software) then I’m looking forward to FOSS Nigeria 2011 already.
Kanuri and Hausa Keyboards, part 2
April 26th, 2010
Thanks to the comments on my previous blog entry about Hausa and Kanuri keyboard layouts, I’ve looked into the topic a little more, adding yet more options for typing.
Dead keys: the keyboard may have “dead keys” for accents. A dead key does not print anything when pressed, but combines with whatever you type next. For instance, you could have a dead accent acute key that combines with a, so you hit dead-acute followed by a and get á. In Kubuntu 9.04 (which is the OS I have at hand during this trip, so some of the advice offered in comments previously doesn’t apply) dead-acute k combines to ḱ. But this does offer a possible solution: using dead-acute with b, d, k, r and e. These will produce the Hausa b, d and k with a hook and the Kanuri r with a line and upside-down e.
First, I had to find a key on my keyboard to define as dead-acute, since I don’t have one otherwise. I used the strange key squashed between enter and the arrow keys, keycode 94.
xmodmap -e "keycode 94 = dead_acute"
From then, I could immediately use the dead-acute key for combinations that are already defined in X, like á, é, ń and others. But it doesn’t help me type Hausa all that much.
Next stop, .Xcompose. This is a file I create in my home directory. Reading it in seems to require an X restart, so log out and log in after creating the file. You will note that it uses the new dead-acute key to create all of the Hausa and Kanuri and the Naira symbol out of existing keys. The Naira is already pre-defined as multi-N-equals, but that is equally hard to type.
So I put this into my .XCompose. It takes the current configuration and then adds the dead-acute key combinations just described. Of course this is no official keyboard layout, but it may help some people type Hausa at speed when no other keyboard is available.
# Import default rules from the system Compose file:
include "/usr/share/X11/locale/en_US.UTF-8/Compose"
# Hausa definitions
<dead_acute> <k> : "ƙ" U0199 # HAUSA k
<dead_acute> <K> : "Ƙ" U0198 # HAUSA K
<dead_acute> <b> : "ɓ" U0253 # HAUSA b
<dead_acute> <B> : "Ɓ" U0181 # HAUSA B
<dead_acute> <d> : "ɗ" U0257 # HAUSA d
<dead_acute> <D> : "Ɗ" U018A # HAUSA D
<dead_acute> <e> : "ə" schwa # KANURI e
<dead_acute> <E> : "Ə" SCHWA # KANURI E
<dead_acute> <r> : "ɍ" U024D # KANURI r
<dead_acute> <R> : "Ɍ" U024C # KANURI R
<dead_acute> <n> : "₦" U20a6 # NAIRA SIGN
<dead_acute> <N> : "₦" U20a6 # NAIRA SIGN
I think an advantage of a dead-key approach is that you don’t have to hold anything down and the symbols on the keyboard still resemble what you’re typing. Of course, getting a dead-acute key to stick across sessions is the next issue to deal with, or perhaps I should set up something like super instead (that can be done with the KDE keyboard layout tool) so that super-b is ɓ.
In any case, it goes to show that there’s many ways to do it — whatever it is. In the end the KDE UserBase Compose Key tutorial has been vaguely helpful, but mostly the links at the bottom of that page.
[[ One might wonder why I’m blogging this kind of thing, but that’s because I promised some people here in Kano that I would look some things up for them, and the most effective way to get the information back to them — and back to their students — is to bung it on the internet, so that searching for Nigerian keyboard layouts for Hausa turns this information up (as well as useful things like the OLPC layout). ]]
Hausa and Kanuri Keyboards
April 26th, 2010
To type Hausa and Kanuri letters like ə, Ɓ or ƙ you will need to modify your keyboard layout. A keyboard layout maps the buttons on the keyboard to symbols which are displayed — you do not have to look at the letters painted on the keyboard and the computer doesn’t know what’s painted there anyway. Let’s look at three (and a half) ways of putting these letters into your document.
KCharSelect: the application ‘kcharselect’ helps you pick characters from the entire range of Unicode characters — if there’s a letter for something, then kcharselect can help you find it. On my KUbuntu 9.04 installation it is not installed by default, so I used the package manager to add it first (I used sudo apt-get install kcharselect but the graphical manager can do it as well). If you like GNOME apps, it looks like ‘gucharmap’ is the one you want.
Once kcharselect is started it presents you with a page full of characters. You can click on any character to obtain information about it, or double click on it to add it to the little text box at the bottom of the window.
At the top of the window there is a search bar; type part of a description or character name and the displayed characters will be filtered. For instance, I typed in “Nigeria” and that slims the display down to the letters I’m interested in (no capital ƙ though?) as well as a Naira sign. Good!
After double-clicking the characters I am interested in into the text bar below, the “to clipboard” button puts them on the clipboard so I can paste them into the document I’m writing. Bit of a round-about way to do it and not fast when typing long documents, but it works.
Using xmodmap: Each key on the keyboard has a number. To find out which number, start the “xev” program from a terminal window (in KDE, start konsole; in GNOME, start gnome-terminal; then type xev). A small window with a box will appear. Move the mouse over the window. Notice that lots of output appears in the terminal from which you started xev.
Next, hit a key on your keyboard. You will see more output, which looks something like this:
KeyPress event, serial 30, synthetic NO, window 0x1600001,
root 0x13c, subw 0x1600002, time 21276913, (48,63), root:(53,895),
state 0x0, keycode 51 (keysym 0x1000259, schwa), same_screen YES,
The important number is the keycode (51 in this example). That is the number of the key you just pressed.
It is convenient to find four different keys on your system, one for ə, one for ƙ, one for ɓ and one for ɗ. On my keyboard, I used the keys [, ], \ and \ (I have two \ keys) which have keycodes 34, 35, 51 and 94.
The next step is knowing what the keyboard symbols are that you want for each key. The ə is called schwa, but the other Hausa letters don’t have a name in the standard X keysym table. I looked them up with kcharselect so I could use their Unicode names, and found the following:
Khook Ƙ 0198
khook ƙ 0199
Bhook Ɓ 0181
bhook ɓ 0253
Dhook Ɗ 018A
dhook ɗ 0257
The final step is to assign these keyboard symbols to the key codes, so that when you press the key the right symbol appears. I’m going to put ƙ on my [ key (key code 34, key symbols U0199 and U0198). To do this, use xmodmap. This utility can be used to remap your keyboard, and can also hopelessly mess the keyboard up until you logout — so be a little careful.
xmodmap -e "keycode 34 = U0199 U0198"
This maps keycode 34 to U0199 (ƙ) when pressed normally and to U0198 (Ƙ) when pressed together with shift — just like normal lowercase- and uppercase letters. The next three commands assign the other keys:
xmodmap -e "keycode 35 = U0253 U0181"
xmodmap -e "keycode 51 = U0257 U018A"
xmodmap -e "keycode 94 = schwa SCHWA"
After these four commands, when I run my finger across the top row of letters on my keyboard, it produces qwertyuiopƙɓɗ; the ə is a strange key sandwiched between enter and the arrow keys. But the result is that I can type Hausa and Kanuri in a sensible way.
xmodmap revisited: instead of picking separate keys for each Hausa letter, you could add them to the existing keys for b, k, d and e. For that, we’ll need to make sure there is a Mode_switch key set. I used the AltGr key on my keyboard, and found out that it had keycode 108. So I set it to be the mode switcher with
xmodmap -e "keycode 108 = Mode_switch"
Then I set up the b key (for instance) with the symbols for b, B, ɓ and Ɓ. These will appear when the key is pressed normally, when it is pressed with shift, pressed with AltGr and when pressed with shift and AltGr.
xmodmap -e "keysym b = b B U0253 U0181"
Using keyboard layouts: I have tried the Nigerian keyboard layout, Hausa variant, but there I couldn’t find the ƙ at all, so I think that layout is broken in some way. I selected it from KDE’s systemsettings / Language & Region module under keyboard, but it’s no success. I can type lots of strange characters, but not the ones I need in Hausa.
On Source Signing
April 22nd, 2010
Brian Gough (a gentleman with whom I’ve stood in a room at one point, but I don’t think we’ve ever spoken) points out that KDE (that is, the release team for KDE) doesn’t GPG sign the source packages that it releases. Hm, interesting, as it’s true that the recent KDE SC 4.4 source tarballs don’t come with an MD5SUMS file or anything else. Going back in history, I find Attic/3.5.9/src which has an MD5SUMS file or the older Attic/3.5/src directory which has an MD5SUMS and an .asc file. Hunh, come to think of it I don’t even know how to check if the .asc file matches the MD5SUMS.
So clearly the source-signing and integrity-checking has decreased over the years. Not sure why — are we (KDE) relying on the packagers to (re-)host the sources and sign them themselves? Have we realized that no-one except the core of the gpg web of trust is checking these things and that it’s not worth spending release team time on? I don’t know.
I do know that the last time I posted a KPilot source tarball — we’re talking five years ago here, at least — I did gpg sign it with the KPilot key. Goodness knows where that thing has gotten to.
And on a related note, I wandered off to look at the OpenSolaris packages to see if they are signed in a meaningful way. The manifests include hashes of all the files in a package, but I don’t see the manifest itself protected or signed in any way. That leads to the same issues that Brian points out again — but it’ll be an interesting day wrt. porcine aviation when Oracle starts using a well-connected gpg key, methinks.
As far as KDE goes: I’ll ask the sysadmins; it might just be an oversight.
[ade] — bridging planetkde and planet.fsfe since 2009.
Heat it Up
April 22nd, 2010
With highs below 40 degrees it’s hard to know if it’s Minnesota in November or Kano this week. Scale is the thing here, and I do hope to be hotting it up in Kano for the second annual FOSS Nigeria conference this week. Akademy 2008 in Mechelen brought us Mustapha Abubakar and he went back home and set up a conference for Free Software in the north of Nigeria. I’m pleased and honoured to be going back for a second round. As in previous years, talks will include Free Software background, some legal stuff, C++, python, and whatever else strikes the fancy of the speakers (some of whom are me and Frederik). I think this year I’m better prepared for the destination — although I’m still looking for my Hausa hat, it’s gotta be in the house somewhere. Sinasiri, here I come! Also, I’m looking forward to seeing how the guys from Hutsoft are doing, which way IT in Kano is growing, meeting up with Mr. Tata again and once again contemplating Free Software under a breadfruit tree.