Next for newlib?

Hi All,
  There are two "nexts" that need to happen shortly for procps newlib.

1) The first is, making a procps 4.0.1 The biggest change is the used =
total - available memory calculation.  I think its ready to go and would
like to get this uploaded to Debian experimental as well as anywhere else
people would like to try it.

2) The second thing is when to make newlib the main one. With two things to
sort.

2a) First, is the includes path. For procps binaries it is <proc/pids.h>
For old libprocps it is <proc/readproc.h> and for non-procps binaries that
use libproc-2 it is <procps/pids.h>
That's right, libproc-2 uses procps as an include directory and libprocps
uses proc.
I'm thinking that possibly moving the includes in both the git archive and
install directory should be proc-2 so both procps binaries and external
ones do a #incude <proc-2/pids.h>

2b) The second newlib issue is the dependent projects which I have listed
in https://gitlab.com/procps-ng/procps/-/issues/239

Most of these are fine and I have locally a set of patches that will cover
both libprocps and libproc-2, its how I found out about the back-to-front
include directories.

The craziest one is veyon which has a foreach method with a visitor
function as its first parameter. The foreach function is called with a PID
and some flags and finds the children of the process and runs the visitor
function for each; all using the proc_t structure to pass information. I'm
not really good on C++ but I suspect changing the proc_t to a pids_stack
will do the trick.

These all tie together, I don't want to start sending patches until there
is landing on the includes files.

 - Craig

-- 

Craig Small             https://dropbear.xyz/  csmall at : dropbear.xyz
Debian GNU/Linux        https://www.debian.org/
<http://www.debian.org/>  csmall at : debian.org
GPG fingerprint:     5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5