Description of problem: The package contains translated man pages, but not the *.mo or *.gmo files for UI translations. Version-Release number of selected component (if applicable): 3.3.10-1 Jaromir, I know about the current i18n issues in upstream development. But try to fix at least the Fedora package. BTW, I assume you will backport it also to the upcoming f21...?
Hi Mario. The translations are in a separate sub-package called procps-ng-i18n. Please, install and test again. Regards, Jaromir.
... and the f21 upgrade is a bit complicated as we changed the API and doing it after the Alpha is not very welcome. I'll have to ask whether we still can do it or not ...
(In reply to Jaromír Cápík from comment #1) > Hi Mario. > > The translations are in a separate sub-package called procps-ng-i18n. > > Please, install and test again. > Why do you keep the translations off the main package? They don't eat up lots of disk space, given the nowadays' disk sizes, and they have no other recognizable dependencies than the main package itself: [mariobl@localhost Downloads]$ rpm -qpR procps-ng-i18n-3.3.10-1.fc22.x86_64.rpm procps-ng = 3.3.10-1.fc22 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Have a look at other collections of basic command line tools, such as coreutils, util-linux, psmisc or findutils. No one of the Fedora packages ships translations in an extra package. Moreover, if procps-ng gets installed, it can happen that users are not aware of the presence of translations at all. To summarize, I don't see any advantages in having a sub package. (In reply to Jaromír Cápík from comment #2) > ... and the f21 upgrade is a bit complicated as we changed the API and doing > it after the Alpha is not very welcome. I'll have to ask whether we still > can do it or not ... OK, it's the decision of the "other ones" but would be fine to have it in F21 anyway. We are in Alpha stage, not after the first RC. Otherwise we have to wait again at least half a year - or even longer... Just another issue: the package owns the (empty) directory /etc/sysctl.d which is already owned by systemd, and it pulls systemd-libs as a runtime requirement. Just use "Requires: systemd" and you don't have to mkdir that directory during the build. Or are there any disadvantages to pull systemd directly?
Hello Mario. > > The translations are in a separate sub-package called procps-ng-i18n. > > > > Please, install and test again. > > > Why do you keep the translations off the main package? They don't eat up > lots of disk space, given the nowadays' disk sizes, and they have no other > recognizable dependencies than the main package itself: I decided to put the translations in a separate sub-package for two reasons. 1.) They cause regressions in user scripts as the output of procps-ng tools is widely used for scripting and often parsed expecting the english layout only. 2.) The translations are not stable yet and break the layout in some cases. > Have a look at other collections of basic command line tools, such as > coreutils, util-linux, psmisc or findutils. Most of the mentioned tools have no translatable strings in their output (if we don't count help and error messages) and therefore don't break user scripts. But some of them do have translatable strings and the translations cause problems in cases where the users count with english only and don't override the LC_* / LANG variables. This is unacceptable in the enterprise world as our policy doesn't permit regressions, but I'm willing to give it a chance in Fedora once the translations get stable. I created the sub-package just for you and the rest of the translation team, so that you could test and fix. It's possible I'll release the translations in the main package with the next release or backport your possible fixes to 3.3.10 prior finishing the next procps-ng release. > No one of the Fedora packages > ships translations in an extra package. Moreover, if procps-ng gets > installed, it can happen that users are not aware of the presence of > translations at all. That was my biggest dilemma, but like I stated above - It's just a temporary solution till the translations become stable. > > ... and the f21 upgrade is a bit complicated as we changed the API and doing > > it after the Alpha is not very welcome. I'll have to ask whether we still > > can do it or not ... > > OK, it's the decision of the "other ones" but would be fine to have it in > F21 anyway. We are in Alpha stage, not after the first RC. Otherwise we have > to wait again at least half a year - or even longer... > > Just another issue: the package owns the (empty) directory /etc/sysctl.d Funny. Nobody from the systemd team told us about that. The directory was first created and owned by the procps package. procps 2011-03-02 ... 48853e17b2d451f92c11804db307d44e82114a8d (Jan Gorig) systemd 2011-04-01 ... 7ec857ebed9780585a9f3156d5510fb91c8eeaf9 (Lennart Poettering) As you see above, Lennart didn't follow the guidelines by introducing the /etc/sysctl.d directory in systemd one month after Jan did in procps. > which is already owned by systemd, and it pulls systemd-libs as a runtime > requirement. This has already been resolved in the enterprise products and was in my TODO also for Fedora, but I forgot to remove it. Will do shortly. > Just use "Requires: systemd" and you don't have to mkdir that > directory during the build. Or are there any disadvantages to pull systemd > directly? I hope any explicit systemd requires are not needed.
I discussed the F21 upgrade with Richard Jones and he's ok with the libprocps soname bump. I'll rebuild all the required stuff then.
procps-ng-3.3.10-2.fc21, open-vm-tools-9.4.6-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/open-vm-tools-9.4.6-4.fc21,procps-ng-3.3.10-2.fc21
(In reply to Jaromír Cápík from comment #5) > I discussed the F21 upgrade with Richard Jones and he's ok with the > libprocps soname bump. I'll rebuild all the required stuff then. Great! I'll test it next days.
Hi Mario. I had to delete the update due to unexpected conflicts with multiple man-pages-* packages. These need to be resolved first. Please, stay tuned. Regards, Jaromir.
(In reply to Jaromír Cápík from comment #8) > Hi Mario. > > I had to delete the update due to unexpected conflicts with multiple > man-pages-* packages. These need to be resolved first. > > Please, stay tuned. OK, the man-pages-de and man-pages-fr packages have been rebuilt without procps man pages and are in f21 updates testing. Once they are in stable, you might get procps-ng-3.3.10 back. Just another hint: The i18n packages are both in i386 and x86_64, but should be noarch, because the don't contain any binary or arch-dependent stuff.
open-vm-tools-9.4.6-4.fc21,procps-ng-3.3.10-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/open-vm-tools-9.4.6-4.fc21,procps-ng-3.3.10-3.fc21
procps-ng-3.3.10-4.fc21,open-vm-tools-9.4.6-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/procps-ng-3.3.10-4.fc21,open-vm-tools-9.4.6-4.fc21
Package procps-ng-3.3.10-4.fc21, open-vm-tools-9.4.6-4.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing procps-ng-3.3.10-4.fc21 open-vm-tools-9.4.6-4.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13392/procps-ng-3.3.10-4.fc21,open-vm-tools-9.4.6-4.fc21 then log in and leave karma (feedback).
procps-ng-3.3.10-4.fc21, open-vm-tools-9.4.6-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.