Dropbear

Tag: Operating system

  • procps 3.3.11

    I have updated NEWS, bumped the API and tagged in git; procps version 3.3.11 is now released!

    This release we have fixed many bugs and made procps more robust for those odd corner cases. See the NEWS file for details.  The most significant new feature in this release is the support for LXC containers in both ps and top.

    The source files can be found at both sourceforge and gitlab at:

    My thanks to the procps co-maintainers, bug reporters and merge/patch authors.

    What’s Next?

    There has been a large amount of work on the library API. This is not visible to this release as it is on a different git branch called newlib. The library is getting a complete overhaul and will look completely different to the old libproc/libprocps set. A decision hasn’t been made when newlib branch will merge into master, but we will do it once we’re happy the library and its API have settled. This change will be the largest change to procps’ library in its 20-odd year history but will mean the library will use common modern practices for libraries.

  • Debian's procps 3.3.9

    While the upstream procps which was released last week has a new pidof, the Debian package will continue to not have that binary and the

    Debian sysvint-utils package will continue to have that file. That stops any messy procps splits and putting one part into Essential etc.

    This may mean that one distributions pidof doesn’t quite work like anothers, but that has been like that already; which is why when I discussed the change as upstream I wondered where they found some of those flags I don’t have.

     

    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