procps-ng 3.3.1 released

Procps-ng, the Debian, Fedora and OpenSuSE fork of procps had another release today.  This is a bugfix release that fixes some important bugs that have cropped up in 3.3.0

pgrep crashes, pgrep -u not finding processes and a problem with top forest view have all been fixed.

An important addition to this release is that test scripts have now been added using the Dejagnu framework.  This framework tests most of the programs that ship with procps-ng.  There is only 100 tests so far and they are only tested for Linux architecture, but we expect to increase this test count and sophistication with each release.

The test scripts even found long-present but unknown bugs in the package. For example, running ps with output flags around the signal masks work as expected in Linux, but fail on kFreeBSD.  This is due to the unusual output of the relevant lines on that architecture. This is not a new bug, bug has been around for quite some time; noone ever noticed (or reported) it.


The Debian package has already been built and uploaded to the master FTP server.

Oh, and it is the first package with my new GPG key!



Enhanced by Zemanta

New procps 3.3.0 for Debian

Coming soon after the upstream procps 3.3.0 being released, the Debian packages have been uploaded tonight.  The Debian packages have had the added benefit of being a day late by having a tiny 2 line patch to stop pgrep from crashing.

One regression that is on purpose, watch is currently not 8-bit clean again until I can sort out how to get the linking right with the new build process.


Testing Systems

The embarrassing problem with pgrep did start a discussion about testing, especially regression testing.  I’ve recently started using unit testing in my python programs and love the level of assurance those tests give me that I haven’t broken anything (to a degree anyhow). I’d really like to be able to type “make test” and have each of the programs run through a series of tests.

The problem with packages like procps (psmisc too) is that you really need to test the entire program, not just a stub, and that the program needs access to a know level of /proc.  The only thing I have seen that is even remotely what is needed is the bunch of scripts that coreutils uses which creates dummy files and directories to operate the commands on.  I expect we could do something similar with some scripts that create a known process but if anyone has a better idea about how to test a command line program let me know.

Enhanced by Zemanta

procps-ng 3.3.0 Released

Tonight procps-ng, a fork of procps by developers from Debian, Fedora and SuSE was released.  The main goal of the team for this release was to reduce the number of patches we all carry in our respective distributions and learn from each other.  As an added bonus, we had one of the original authors of top, Jim, join the team and greatly enhance top.

While the upstream version is now released, the Debian package is not quite ready to go as it involves removing a lot of patches and adjusting some others.  The build system is also now a reasonably standard (but different to previous) setup that means the packing scripts need adjusting.

The best place to find out what is different is the procps NEWS file. The source code is available from Gitorious  at

Enhanced by Zemanta

psmisc 22.14 Released

The upstream and Debian packages for psmisc version 22.14 were released tonight.  This version has a lot of bugfixes.  I’ve also taken some time to clean up some of the minor compile warnings I used to get which were mainly variables set but not used.

Two bugs that I’ll concentrate on getting fixed for the next version are all about the command line.

The first is that the fuser -s flag changes the return code for items found.  It should be consistent so it doesnt matter if fuser displays values or not, 0 means found something and 1 means didn’t find it. I can see why in the code it might be different, because the code follows different paths with the s option, but not exactly where the problem is.

The second bug is the -M flag for fuser only works if it is before the mount points so -M -m /foo works but -m /foo -M does not.  Unlike the -s problem, I can see where it is failing.  Currently fuser scans the options one by one.  If it finds a -m option, it checks at that point if the -M option is set.  The solution is to store all potential targets and only after exhausting the entire command line do we add the potential targets  to our “real” targets.  It means scanning the command line, or a subset of it, twice but the performance penalty is tiny.

Finally, I released there was a rather neat Makefile command “make distcheck”. This target makes a tar.g archive, extracts it, builds then cleans.  It is a very good program for trapping things like a file exists in your local directory but is not included in the tar.gz (lists.h was missing until I ran this).  For some “make distcheck” is something they’re known for years, but if you have an autotools package you develop, have a look at it.

With all the talk about testing and test driven releases, I was going to put some test cases in. The problem is there doesn’t seem to be an easy way to do testing. I might have to just hack up some scripts but surely there is a better way. That would trap, for example that fuser -s returns 1 but fuser returns 0.  I looked at check, but it doesn’t work for single-file programs like psmisc is mainly made of.

Enhanced by Zemanta

Debian Linux on HP DV6-6023TX

It was time to update my creaking old laptop.  I ordered HP6-6023TX online and after a few days it arrived just before a long weekend.

I first backed up Windows 7 onto a set of DVDs and found that either my blank DVDs are old or this new DVD drive is far more fussy. There were quite a few coasters made until I gave up and bought some new ones.

DVDs seemed to be trouble for me that day.  I downloaded the Debian 6.0.4 DVD image but couldn’t burn it. Brasero would just keep saying calculating checksum and go no further.  So after waiting too long, the CD iso was downloaded and installed.

Installation of Debian onto the laptop was straightforward. That is if you used a wired connection. Wireless needs the non-free firmware and I gave up trying to work out how to install it at debian-installer time as it didn’t see the tar.gz full of firmware on the USB stick.  Wireless worked perfectly once I loaded everything on. So at this point with not much trouble I had an almost fully working setup. Even the webcam and sound was working.

Video Fun

The laptop is one of these strange modern ones that has two video cards.  The low-spec one is an Intel Sandybridge while the higher one is an AMD/ATI Radeon HD 6700M. The idea being you use the ATI when plugged in and the Intel on batteries.

Xorg worked first go, but only on the Intel chip.  Trying to force X to use the ATI driver with an Xorg configuration resulted in the Xserver crashing.

Next attempt was the fglrx packages within Debian. aticonfig said it didn’t know about the card. The reason for this is that the Debian packages use fglrx version11.4 and I needed for my card 11.5 So close but so far away.

OK, so building the ATI software can’t be that hard can it?  A nice set of instructions on the Debian wiki and we had… errors. The first problem is that the packaging used is ancient. The second problem is much more serious; it won’t compile.

I was stuck about here until I hopped onto the Debian irc channel and asked about it and someone found a very useful webpage about compiling the ATI drivers on Debian which importantly had information about the patches you need, especially the blk patch.

Success! the program compiled and installed. A small xorg.conf specifying the fglrx driver and the BusID and we were up and running.  I now have accelerated graphics on the laptop.

Ouch, my eyes!

I do actually get outside (one of my hobbies is gardening and that is an outdoor activity) so I don’t need a monitor screen trying to give me a suntan.  The default screen brightness on the laptop could be described as “sub-nova”. I’m sure there is some alien astronomers several light-years away who will in many years time wonder what that flash from the unimpressive end of the milky-way was about. To protect your eyes and keep the neighborhood complaints down you can reduce the brightness to something sane. You do this in the power management settings which for me is System -> Preferences ->  Power Management. I can see again!

Enhanced by Zemanta