Category: debian

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!

December 6, 2011
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.

November 21, 2011
ncurses library split

The new ncurses library that is currently sitting in the NEW queue will have a significant change that, if we’ve done it right, should be an invisible change. If we’ve got it wrong, then the BTS (and us) may be a little busy.

What has happened is that the low-level terminfo library has been split out from the general ncurses library making a new package called libtinfo5. This also means that there only needs to be one libtinfo5 package because at this low level it doesn’t care about wide characters, so there is no libtinfo5w (and that gets important later). libncurses is linked to libtinfo so from the point of view of using libncurses there should be no major change in how things are done.

So, why bother?

The way ncurses was built before causes a nice long “conga line of trouble”. There really are (was) two main ncurses library packages, libncurses5 and libncursesw5. The w meant it was for wide characters. So anything that uses ncurses needs to decide which one to link to or perhaps both. A problem came up with the readline library that needs to link to ncurses because programs that link to IT (such as python) want a wide library but other programs do not. One solution is to have two readline libraries, but then any other library would need to be compiled and built twice as well and so on and so on.

readline didn’t really want the full ncurses library, it only wants the terminfo part but there was (until now) no way of picking up that bit only. Once this new version of ncurses gets released then readline can link to libterminfo which is agnostic to wide and non-wide characters which means it is as well which them means everything else should, in theory work. If you are using ncurses for some low-level terminfo work only, you may want to have a look to see if you can link to libtinfo5 only which will mean depending on libtinfo5 and not libncurses5 or libncursesw5.

I’m just writing this up mainly and uploading the packages, the bulk of the work was done by Sven and Matthias as well as some help from our ever-helpful upstream Thomas.

September 30, 2011