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