One of the many Free Software projects I work on is JFFNMS, which is a network management system written in PHP. In light that the last IPv4 address blocks have now been allocated to APNIC it’s probably timely to look at how to manage network devices in a new IPv6 world.
First you need to get the basics sorted out and for that it is best to use the net-snmp command line utilities to check all is well. Then its onto what to do in JFFNMS itself.
Now fixed with proper markup, I hope.
I’ve been playing text based multi-user games on and off for years, or perhaps that’s decades. When I first started playing them, all you had was telnet. Then this program called TinyFugue appeared which is still shipped by Debian. The generic term for these sorts of games are MUDs, or Multi User Dungeons.
Anyhow, I recently came across a new MUD client called Mudlet. It’s a very slick program and works quite well. The way it does its triggers (reactions to what the mud sends you) and aliases (reactions to what you type) is done well and is fast. For some people you may have 100s of potiential matches on a incoming or outgoing line so you want it to be fast.
After trying it out, my next reaction was “ok, so is it packaged in Debian?”. To my surprise, it wasn’t so the only obvious thing to do was for me to package it. It is now sitting in the NEW queue waiting for our ever-overloaded ftp masters to have a look at it.
While the program is done well, as shipped it doesn’t play too well with a Linux system. The package carries about 4 different other packages around. I’ve changed that now so it uses the system libraries and fonts. All of them are shipped in Debian and I’m sure they individually get more attention and love then I would give them being a sub-part of the main package. It of course cuts down on build times and archive sizes too.
I still play muds, no matter what client. For me there they’re fun on two levels. The first is the puzzles and gameplay of the MUD itself. I play some MUDs run by Iron Realms who continuously update them, giving you new challenges.
The second level is the scripting and customisation you can do. Instead of typing “sip health” you can write some scripts to check your health level and get the script to do it. Mudlet (and a lot of other MUD clients) use the Lua langauge to do this scripting. It’s a little funny language but is easy to learn and use. You won’t be able to build some epic programs with it, but for scripting it is pretty good.
Mudlet uses the hunspell library for spell checking. I have, of course, linked it with the Debian library. The difficulty now is what language? I was surprised that when you intialise the library, you specify what language files to use right there. Now for me its simple, the english dictionaries should be used! What I don’t undertand is if there is a way of determining the right dictionary globally for a user.
I first though it would be one of the locale parameters, those LC_whatever fields. Mine is en_AU.UTF8, which there is no dictionary for as I’d use en_US or en_UK. I could possibly patch Mudlet and find a dialog box somewhere where you can set the language, but to me an environment variable makes more sense. Does anyone use the DICTIONARY variable, for example?
If you use dh-make with CDBS then you need to know that CDBS is no longer a package type, but is a rules format. This is where it should of been in the first place and for a few versions of dh-make there was this half-hearted attempt to change it over.
Version 0.57 has the right fixes and just got uploaded. I’m not sure how many people actually use CDBS on new packages anymore, but it should work fine now.
Oh, and dh-make is now of Alioth git repository instead of subversion.
No real terribly exciting updates lately but all important in their own way.
A new version of ncurses got uploaded into sid. It should hopefully fix the backspace versus delete problem some of the FreeBSD people have been having with some of the terminal emulators.
Oh, and if you are pining for the good old days when 8 colours and 64kB of memory was good enough for everyone, checkout ncurses-examples which have a bunch of interesting things you can do with curses, including some games. Anyone remeber the tower of Hanoi?
dh-make, the tool to take a raw tar (or zip) archive and make a Debian package has been updated too. One of the interesting side-effects of maintaining dh-make is you find out (usually through bug reports) the little changes that happen to the Debian package build process.
Most people, including myself, though the main big thing between versions 1 and 2 and version 3 of the source formats was the inclusion of quilt patches right inside the source files. And probably for the sake of “main things” this is true. What I didn’t realise is that dpkg-source has changed in other ways too.
Bug 580804 tripped this one up. For most people, you run dh_make, fix some things up and use debuild. If you didn’t have the original tar file (perhaps you got the source from git or svn) you just use –creatorig and it copies the current directory into ../whatever-1.2.3.orig
Source format 3 doesn’t like this. Previously it would find that there was no orig.tar.gz archive but there was a orig directory and make the archive from that. Now you have to do it yourself and dh_make does it like that too.
Now this should of been a pretty simple stock-standard upstream upgrade. Download the file, uupdate, debuild and release. The problem is that upstream didn’t fix their po files. These are the translation files that convert the raw english texts in a program into whatever language. This means the first time you run the build process, you have no diff file. However when you run it the second time, part of the install target rebuilds the po files (mainly the line references), you have differences and then a big diff file of these po updates.
The real fix is to make sure your po files are up to date before you release! The trick is that they don’t automatically and I have been caught myself; though it happens in the release testing phase (because my release testing involves usually building the debian archive so I see my own problem).
irc came to the rescue again. Someone there suggested getting dpkg-source to ignore the changes. The way you do that is put parameters into debian/source/options. I wanted to ignore the changes to the po and pot files so my file has:
extend-diff-ignore=po/.*.pot?
I put that in and it works!