No real terribly exciting updates lately but all important in their own way.

ncurses

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

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.

 

pidgin-musictracker

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!

 

Sven has been very busy getting a new Debian ncurses packages into order.  With the multiple changes made and the fact that so many things depend on the shared libraries, we decided that it is best to put the first cut of these packages into experimental.

We’re now using the Quilt 3.0 source format for our packages, which means that we should have a better handle on the patches, especially as they all now have Dep-3 patch tags .

So what has changed, why should you go over and try the experimental packages?

• First, it will help us with checking the packages actually work, Sven has tried them out (I will be soon) but the more testing the better.
• We’ve updated the upstream patch level (basically the upstream version) on this set of packages.
• New package! ncurses-examples which are all the example programs that shows you what ncurses can do.

 

Most of the time you can trust the times you see in programs such as ps and top within Linux, but there are those other times where you just want to check what is going on.

First up, if you’re using a FreeBSD system and the procps Linux tools, you’re out of luck because a lot of the procfs is broken.  You’re almost guaranteed to get wierd results.

Jiffies and Hertz
The first thing to find is your jiffies.  This is the number of clock ticks per second.  There are two main ways of doing it.

The first, and more difficult way is to add up the cpu numbers in /proc/stat, divide it by the first number in /proc/uptime and divide it by the number of cpus.

My cpu line in /proc/stat looks like:

cpu  1267430 145826 552700 137029699 905086 8295 17885 0 0

and my /proc/uptime is:

695317.99 1370303.58

I’ve got 2 cpus on this system so the calculation is:

(1267430  + 145826 + 552700 + 137029699 + 905086 + 8295  + 17885 + 0 + 0 )  / 695317.99 / 2

which equals 100.

The second way is to use getconf, with the command “getconf CLK_TCK” which again on this system gives you 100.

We call this value “Hertz” and is usually 100 or 1024 though for some architectures it is other values.

Start Time
For each process the procfs has the start time, but it is expressed as the number of jiffes since the computer was booted.  If we want to know the real “wall clock” time a process is started we have to start with number of seconds since epoch (for example using the time() function) subtract the number of seconds since the computer was booted and add the process start time from procfs.

The seconds since boot is the first value in /proc/uptime:

696141.85 1371857.53

The 22nd item in a procfs PID stat file is the number of jiffes since boot when the process started. We have to divide it by Hertz to calculate the number of seconds.
27139 (bash) S 11942 27139 27139 34821 5200 4202496 5500 25537 0 14 40 16 18 15 20 0 1 0 69446639 23433216 1378 18446744073709551615 4194304 5082140 14073724008 6512 140737240085456 140127945249678 0 65536 3686404 1266761467 0 0 0 17 1 0 0 0 0 0

To get the start time, take the current time, subtract the boot time and add the process start time.

perl -e ‘$nowstr = localtime(time() – 696141.85 + 69446639 / 100); print $nowstr, “n”;

Mon Jul 12 22:20:07 2010

Unless you are very quick, you will have to take a few seconds off because the time() function will be now, while the values from the proc files will be a few seconds earlier as it takes time for you to cut and paste.

Well the latest version of PSmisc is almost finished, so I pushed the tar archive up to the spot for the translators, waiting for the updates before it gets released.

It reminded me that perhaps a lot of people don’t know how their programs get translated. Perhaps there are some that could even contribute.  The nice thing about the translation systems is that you don’t need to know programming to help.

PSmisc uses the translation project as its method.  The program itself uses gettext for the translation part which makes a single text file called a POT file.  A translator takes this text file and makes a po file, such as it.po for the Italian translation and then translates, which basically means editing the file, reading each first line of a set and writing the translation on the second line.

For the programmer, once it is setup it is pretty simple to use, just mark your translatable lines and follow some simple rules, mainly about not embedding too much in a string.  I’ve used this system for years for quite a few of my programs and there is little added work for me.

Unfortunately,  translating is hard work and should be a long-term commitment.  Having a look at the translation project’s Translation Matrix and you can see that some languages do suffer, though there are some very good results there too.  Particular kudos goes to the Vietnamese group which I think is just Clytie who does a marvellous job and is often the first translation file I get.

For the Debian project, there are many places where translations can occur.  There doesn’t seem to be a centralised place for this, but some of the places they use translation work are:

• Translating The Debian website
• Debian Description Translation Project
• Debian debconf (configuration questions when you install packages)
• Translating Debian News

Well I suppose its a bit heretical running something such as VMware, but its an important piece of software at my workplace, it also allows me to run some important VMKs or modules.  But at first it just wouldn’t compile.

And then I found this wonderful blog about Installing VMware on Ubuntu and it worked wonderfully. The author patched the code and it all installed nicely.

The next problem was one of the services would not start. Port 8308 would refuse to work and when I went to the management screen and said Service Unavailable.  I tracked this down to the Java program dying at socket binding time.

The absolute first thing you should check if you are having TCP/IP problems with Java is the sysctl path net.ipv6.bindv6only which you can check with
sysctl net.ipv6.bindv6only.

If it is 1, it might mean bad Java code network problems. And in fact this time it was the problem, changing it to 0 and the Java daemon started and stayed running and all was good.

Incidently if you use the Cisco ASA firewall Java client and it dies, use this trick for it too.  On Debian systems, edit the file /etc/sysctl.d/bindv6only and set that option to 0.  I don’t think its the fault of the key, but bad Java code (but is there anything but bad Java code?)