Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
One more thing that ought to be fixed in the man page, see point (4) in comment 0:
(4) ... all users which have a icastats shared memory segment ...
^^^^^ (should be 'who')
Just noticed one more typo in the very introduction. If planning to respin RHEL-7.2 man-pages-overrides, please consider fixing this one as well:
Libica is a cryptografic library ...
^^^^^^^^^^^^ (should be 'cryptographic')
(In reply to Jan Chaloupka from comment #10)
> Martin, can you check the typo with upstream? Or report it so it is fixed in
> upstream as well? Thanks.
I've just sent it to upstream mailing list. The old fixes are still waiting for reaction :-(
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-2353.html
Description of problem: I found a few typos on the brand new icastats manual page: (1) For the cipering methods the invocation counter is further divided ... ^^^^^^^^ (should be 'ciphering') (2) ... and persists until it is explicit removed (see the -d option) ... ^^^^^^^^ (should be 'explicitly') (3) ... or system shutdown. This also means that the statistical data ... ^^^^^^^^ (the verb is 'shut down'; 'shutdown' is a noun) (4) ... all users which have a icastats shared memory segment ... ^ (should be 'an') (5) ... show statistic values from the give user ... ^^^^ (should be 'given') Also, there is this one little thing which might be of marginal importance but I would like to point it out here anyway. The sample output of icastats shown on the man page looks like this: function | # hardware | # software --------------+-----------------------+------------------------- | ENC CRYPT DEC | ENC CRYPT DEC --------------|-----------------------|------------------------- SHA-1 | 0 | 0 SHA-224 | 0 | 0 SHA-256 | 0 | 0 SHA-384 | 0 | 0 SHA-512 | 0 | 0 P_RNG | 0 | 0 RSA-ME | 0 | 0 RSA-CRT | 0 | 0 DES ECB | 0 0| 0 0 DES CBC | 0 0| 0 0 DES CBC CS | 0 0| 0 0 DES OFB | 0 0| 0 0 DES CFB | 0 0| 0 0 DES CTR | 0 0| 0 0 DES CTRLST | 0 0| 0 0 DES CBC MAC | 0 0| 0 0 DES CMAC | 0 0| 0 0 3DES ECB | 0 0| 0 0 3DES CBC | 0 0| 0 0 3DES CBC CS | 0 0| 0 0 3DES OFB | 0 0| 0 0 3DES CFB | 0 0| 0 0 3DES CTR | 0 0| 0 0 3DES CTRLIST | 0 0| 0 0 3DES CBC MAC | 0 0| 0 0 3DES CMAC | 0 0| 0 0 AES ECB | 0 0| 0 0 AES CBC | 0 0| 0 0 AES CBC CS | 0 0| 0 0 AES OFB | 0 0| 0 0 AES CFB | 0 0| 0 0 AES CTR | 0 0| 0 0 AES CTRLIST | 0 0| 0 0 AES CBC MAC | 0 0| 0 0 AES CMAC | 0 0| 0 0 AES CCM | 0 0| 0 0 AES GCM | 0 0| 0 0 AES XTS | 0 0| 0 0 CCM AUTH | 0 0| 0 0 The zeros are crammed as far to the right as possible, which makes the table a little bit hard to read: in fact, the zeros from the ENC column almost look as though they belonged to the CRYPT one. Not only is such a formatting confusing, but it also does not reflect the actual layout used by icastats output (no matter the terminal width): [root@localhost ~]# icastats function | # hardware | # software --------------+--------------------------+------------------------- | ENC CRYPT DEC | ENC CRYPT DEC --------------+--------------------------+------------------------- SHA-1 | 0 | 0 SHA-224 | 0 | 0 SHA-256 | 0 | 0 SHA-384 | 0 | 0 SHA-512 | 0 | 0 P_RNG | 0 | 0 RSA-ME | 0 | 0 RSA-CRT | 0 | 0 DES ECB | 0 0 | 0 0 DES CBC | 0 0 | 0 0 DES OFB | 0 0 | 0 0 DES CFB | 0 0 | 0 0 DES CTRLST | 0 0 | 0 0 DES CMAC | 0 0 | 0 0 3DES ECB | 0 0 | 0 0 3DES CBC | 0 0 | 0 0 3DES OFB | 0 0 | 0 0 3DES CFB | 0 0 | 0 0 3DES CTRLIST | 0 0 | 0 0 3DES CMAC | 0 0 | 0 0 AES ECB | 0 0 | 0 0 AES CBC | 0 0 | 0 0 AES OFB | 0 0 | 0 0 AES CFB | 0 0 | 0 0 AES CTRLIST | 0 0 | 0 0 AES CMAC | 0 0 | 0 0 AES CCM | 0 0 | 0 0 AES GCM | 0 0 | 0 0 AES XTS | 0 0 | 0 0 CCM AUTH | 0 0 | 0 0 Please consider fixing this table's formatting in the man page as well. Version-Release number of selected component (if applicable): libica-2.4.2-1.el7.s390x libica-2.4.2-1.el7.s390