procps newlib ready?

Craig Small <[email protected]> Tue, 22 Mar 2022 20:44:46 +1100
Newsgroups gmane.linux.procps.devel
Message-ID <CALy8Cw5LCWHbiq64f_yPNEYw6_dgL4Gyd7R4BLB9QpTs5SG--A@mail.gmail.com>
On Mon, 21 Mar 2022 at 22:15, Jim Warner <[email protected]> wrote:

> On 3/21/22 5:47 AM, Craig Small wrote:
> > If you think newlib is ready I can make a rc1 version to send to the
> > translators. I might have to talk the the coordinator as we might have
> > an issue with two versions of the same pot files (oldlib and newlib)
>
> Yea, let's do a rc1 (whoopee).
>
I talked to the translation project. It's actually much easier not to send
the translations in and just wear the lack of translation for experimental
packages. The reason is for it to work, we would have to make some sort of
strange text domain. Our current test domain is whatever PACKAGE is defined
as which comes out of automake "procps-ng".

It's also used for the tar file name so there would be some sort of strange
hackery to get the textdomain to use something different. Then some strange
folding back once newlib is the main one.
So for me, that's a no to fiddle with the translations.

I've already mentioned that it complies with the kFreeBSD Debian systems.

How difficult is it to make Debian packages?
$ dpkg -l procps | grep procps
ii  procps         2:4.0.1-1    amd64        /proc file system utilities
$ ps -V
ps from procps-ng 3.3.11.1055-ad51-dirty
$ ps -o pss,uss
  PSS   USS
 2633  2244
 2056  2012

Obviously, the version number and the package number need to line up. The
current version is 3.3.17 so what should newlib some out as? 4My temporary
on my system packages use an untagged release and 4.0.1 but that was just
to make the build happen.

I think it is definitely time for a major number update, so my vote is for
4.0.0

 - Craig