Dropbear

Category: procps

  • procps-ng 3.3.3 released

    top
    Top in colour mode

    This weekend procps-ng version 3.3.3 was tagged and released for distribution.  There have been many patches and fixes involved in this release as we move from an unchanging static sort of code into something that is easier to maintain and build on various architectures.  The good thing is I’m down to 1 or 2 patches in the Debian archive which is a big change from the 30 or 40-odd I used to carry.  For the sole metric of getting that number down, the project fork has been a success.

     

    There were some post-release bugs I found and these were more to do with the various options turned on or off rather than what you’d see if you did the basic ./configure && make.  One of them was how the version numbers are defined in git, but would only appear if certain files were older than others (such as aclocal.m4 versus config.h.in)  Others were when certain features were turned on.  The make check doesn’t see all of this because it uses the default configure flags.

    One annoying thing of the autotools is conditionally installing man pages. This is where you don’t or cannot compile a binary so you don’t install the corresponding man page.  The automake documentation is of course obscure about this but I cannot see a way of distributing only a man page, so we have this fiddle where a file goes into dist_man_MANS or EXTRA_DIST depending.

    Interestingly, there has been some bike-shedding around Fedora-land (see the link below) regarding the name procps-ng versus procps.  Debian is lucky that we do have different upstream and package names (though not ideal) so apt-get install procps still gives you procps.  There also has been discussion about merging procps-ng into util-linux whichin the short-term won’t be happening.

    Related articles
    Enhanced by Zemanta

  • procps 3.32 Debian packages

    Following up from the upstream release of a new procps, the Debian packages have also been updated. This upload has a significant change in that, I hope, procps is now multi-arch compliant. To make this happen, the libprocps library is now in it’s own package, separate from the binaries. It also means that if you have programs not from procps that link to this library they are now broken. I put in a Breaks: line for the three I know about (xmem, guymager and open-vm-tools) which will need a recompile with a small tweak in the control file and linked statements.

    As suggested in the multi arch implementation wiki page, I tested the libprocps0-dev package by compiling something against it, in this case another Debian package xmem. Doing this was very useful for teasing out some bugs on the dev package itself that did not appear while linking the library to the procps binaries.

    In short, the new procps has a lot fewer patches than the old ones and the next version will have less as I have already included the current changes into the upstream git repository. The main differences are now

    • freebsd linux version is read from a file not from uts
    • includes use __restrict not the auto make defined restrict which may not be present in third party packages
    • libnucrsesw conditionally linked with watch for 8bit watch

    The three are really bugs, especially the last, which is why the patches will disappear next release.

    Related articles
    Enhanced by Zemanta

  • procps-ng version 3.3.2 released

    procps-ng version 3.3.2 was released today.  This version fixes some bugs introduced in version 3.3.1 as well as a number of enhancements. Below is the most significant set of changes that 3.3.2 brings.

    NLS

    The most visible change is that procps-ng is now international.  The NLS changes took a long windy path but we got there in the end. This means all procps-ng programs can now use standard gettext PO files to output in any supported language.  While the programs have been enabled for translations, there are no po files as yet but we expect them to follow soon.

    Library Changes

    procps always had a “closed” library, meaning that it wasn’t supposed to be used for other non-procps programs.  This meant the library was always called libprocps-(version) rather than using a SONAME. Procps 3.3.2 now uses a SONAME of version 0.0.0 The API hasn’t changed but it will be in subsequent versions.

    Patch Backporting

    Due to the stagnant natute of procps development in the past, there have been a large number of patches each distribution carries for procps. A significant number of patches have been incorportated into procps-ng, giving a more consistent look across the distributions and meaning any subsquent fixes or enhancements are done in one place.  A major goal of procps-ng was to reduce the number of distribution specific patches which this change has helped greatly.

    Debian Packages

    The Debian packages will be worked on soon and will clear up some confusion about the procps binaries and library packages as this will now be split into two.  It also means that some programs that depend on libprocps will break, but going on from this point will be able to use the normal shlibs process to manage that, rather than the ugly crunch we will have now.

     

    Enhanced by Zemanta

  • When a dynamic library and program share functions

    This is about making procps have a proper library but it really is a generic sort of question.  Say you are making a library and a program that uses that library.  Now at times you may have convience type functions; procps has them for things like escaping command names or allocation different sorts of memory.  Both the library and the programs use some of these functions.

    Now, there seems only two approaches to this setup.  The first is to have the function stay in the library and for the program to call this function, just like all the other library functions.  But this means the library has exposed for all other programs that link to it and that doesn’t really make a lot of sense.

    The second method is to have the functions defined in both places, perhaps in a file that is linked with the program and the library.  That seems to be duplicating the code in two different places.  Namespace collision could be a problem but that easily fixed with using some unqiue prefix.  I really don’t think having procfs_malloc, procfs_calloc and procfs_strdup are that useful.

    I’m sure this sort of problem has been solved elsewhere.  Has anyone else come across this? The functions are simple utility type functions such as malloc a block of memory, if there is a problem print to stderr.

     

    Enhanced by Zemanta

  • 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 https://gitorious.org/procps

    Related articles
    Enhanced by Zemanta