Bug 2078929 - failing devel man pages for rhel 9
Summary: failing devel man pages for rhel 9
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 2135322 2071943
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-26 14:00 UTC by Petr Menšík
Modified: 2022-10-17 09:42 UTC (History)
7 users (show)

Fixed In Version: unbound-1.15.0-3.fc37 unbound-1.16.0-3.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2071943
Environment:
Last Closed: 2022-06-20 01:08:35 UTC
Type: Bug


Attachments (Terms of Use)

Description Petr Menšík 2022-04-26 14:00:03 UTC
+++ This bug was initially created as a clone of Bug #2071943 +++

Description of problem:
devel manpages are present both with .3 suffix and without it.

Version-Release number of selected component (if applicable):
unbound-1.13.1-13.el9_0

How reproducible:
always

Steps to Reproduce:

/manpage check
Actual results:
rpminspect version: 1.9-0.1.202203012203git.el9 (with data package: 1.7-0.1.202203241750git.el9)
rpminspect profile: rhel-9-devel
new build: unbound-1.13.1-13.el9_0
old build: unbound-1.13.1-12.el9 (found in rhel-9.0.0-pending brew tag)

Test description:
Perform some checks on man pages in the RPM payload. First, check that
each man page is compressed. Second, check that each man page contains
valid content. Lastly, check that each man page is installed to the
correct path.

======================================== Test Output ========================================

manpage:
--------

1) Man page /usr/share/man/man3/ub_cancel.gz has incorrect path on aarch64 in unbound-devel

Result: VERIFY
Waiver Authorization: Anyone

Suggested Remedy:
Correct the installation path for the man page. Man pages must be installed in the directory beneath /usr/share/man that matches the section number of the page.


2) Man page /usr/share/man/man3/ub_ctx.gz has incorrect path on aarch64 in unbound-devel

Result: VERIFY
Waiver Authorization: Anyone

Suggested Remedy:
Correct the installation path for the man page. Man pages must be installed in the directory beneath /usr/share/man that matches the section number of the page.


3) Man page /usr/share/man/man3/ub_ctx_add_ta.gz has incorrect path on aarch64 in unbound-devel

Result: VERIFY
Waiver Authorization: Anyone

Suggested Remedy:
Correct the installation path for the man page. Man pages must be installed in the directory beneath /usr/share/man that matches the section number of the page.


Expected results:


Additional info:

--- Additional comment from Petr Sklenar on 2022-04-05 11:48:42 CEST ---

found by osci.brew-build.rpminspect.static-analysis

Comment 1 Petr Menšík 2022-04-26 16:09:45 UTC
This were caused by commit 8580858b [1], which added devel man pages in 1.4.x version. I think it contained bug, which went unnoticed for several years.

It seems minor issue, would fix it just in rawhide and f36.

1. https://src.fedoraproject.org/rpms/unbound/c/8580858b0c5a7e70c8dfca6c56fd09808ca74c84

Comment 2 Petr Menšík 2022-04-26 16:55:43 UTC
Interesting, builds on f37 passed, but matching build on f36 failed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=86259367

There seems to be something wrong with linker or similar gcc tools.

Comment 3 Petr Menšík 2022-04-27 16:43:32 UTC
the issue on f36 might be related to https://bodhi.fedoraproject.org/updates/FEDORA-2022-bc51e23571

I have found this is crash in unittest, related to openssl.

(gdb) bt
#0  __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:140
#1  0x00007ffff78d9104 in evp_pkey_name2type (name=name@entry=0x55555565a331 "RSA") at crypto/evp/p_lib.c:1019
#2  0x00007ffff78dbd0b in int_ctx_new (libctx=libctx@entry=0x0, pkey=pkey@entry=0x0, e=e@entry=0x0, keytype=keytype@entry=0x55555565a331 "RSA", 
    propquery=propquery@entry=0x0, id=id@entry=-1) at crypto/evp/pmeth_lib.c:203
#3  0x00007ffff78dc1c9 in EVP_PKEY_CTX_new_from_name (libctx=libctx@entry=0x0, name=name@entry=0x55555565a331 "RSA", propquery=propquery@entry=0x0)
    at crypto/evp/pmeth_lib.c:369
#4  0x00005555556082b0 in sldns_key_rsa2pkey_raw (
    key=0x55555569a89e "\001\003\251m\212\324\065\250P\001^\177\301\060\211\367\374\033H\317\336W\343~\215\206@2b\n\237\244\005ݞ{\a\253\251\201\310\325\034C\262\026@7a\302-\344\\\376Z\252\035\n\260\001\237\212\222\205ު%\204|\210\375\322\351\370\315\350\365i\226\063#\256\033)\377\254\225s}\002\351\316\317ٿ\346\201fb\346&\002\347\251dz", len=<optimized out>) at sldns/keyraw.c:486
#5  0x00005555555c24a9 in setup_key_digest (keylen=130, 
    key=0x55555569a89e "\001\003\251m\212\324\065\250P\001^\177\301\060\211\367\374\033H\317\336W\343~\215\206@2b\n\237\244\005ݞ{\a\253\251\201\310\325\034C\262\026@7a\302-\344\\\376Z\252\035\n\260\001\237\212\222\205ު%\204|\210\375\322\351\370\315\350\365i\226\063#\256\033)\377\254\225s}\002\351\316\317ٿ\346\201fb\346&\002\347\251dz", digest_type=<synthetic pointer>, evp_key=<synthetic pointer>, algo=5) at validator/val_secalgo.c:545
#6  verify_canonrrset (reason=0x7fffffffdbe8, keylen=130, 
    key=0x55555569a89e "\001\003\251m\212\324\065\250P\001^\177\301\060\211\367\374\033H\317\336W\343~\215\206@2b\n\237\244\005ݞ{\a\253\251\201\310\325\034C\262\026@7a\302-\344\\\376Z\252\035\n\260\001\237\212\222\205ު%\204|\210\375\322\351\370\315\350\365i\226\063#\256\033)\377\254\225s}\002\351\316\317ٿ\346\201fb\346&\002\347\251dz", sigblock_len=<optimized out>, sigblock=<optimized out>, algo=5, buf=0x55555569a7e0) at validator/val_secalgo.c:687
#7  dnskey_verify_rrset_sig (region=<optimized out>, buf=<optimized out>, ve=ve@entry=0x7fffffffdc70, now=now@entry=1651073963, 
    rrset=rrset@entry=0x555555690a70, dnskey=dnskey@entry=0x55555568ec90, dnskey_idx=0, sig_idx=0, sortree=0x7fffffffda18, buf_canon=0x7fffffffda14, 
    reason=0x7fffffffdbe8, section=LDNS_SECTION_ANSWER, qstate=0x0) at validator/val_sigcrypt.c:1591
#8  0x00005555555c3461 in dnskeyset_verify_rrset_sig (qstate=0x0, section=LDNS_SECTION_ANSWER, reason=0x7fffffffdbe8, sortree=0x7fffffffda18, sig_idx=0, 
    dnskey=0x55555568ec90, rrset=0x555555690a70, now=1651073963, ve=0x7fffffffdc70, env=0x7fffffffdce0) at validator/val_sigcrypt.c:664
#9  dnskeyset_verify_rrset (env=0x7fffffffdce0, ve=0x7fffffffdc70, rrset=0x555555690a70, dnskey=0x55555568ec90, sigalg=0x7fffffffdfa0 "\005", 
    reason=0x7fffffffdbe8, section=LDNS_SECTION_ANSWER, qstate=0x0) at validator/val_sigcrypt.c:558
#10 0x000055555557dcf2 in verifytest_rrset (qinfo=0x7fffffffdbf0, dnskey=0x55555568ec90, rrset=0x555555690a70, ve=0x7fffffffdc70, env=0x7fffffffdce0)
    at testcode/unitverify.c:190
#11 verifytest_entry (ve=0x7fffffffdc70, env=0x7fffffffdce0, dnskey=0x55555568ec90, pkt=0x55555569a7e0, region=0x555555691a60, alloc=0x7fffffffdc10, 
    e=0x555555690ee0) at testcode/unitverify.c:224
#12 verifytest_file (fname=<optimized out>, at_date=<optimized out>) at testcode/unitverify.c:322
#13 0x000055555556bf62 in verify_test () at testcode/unitverify.c:510
#14 main (argc=<optimized out>, argv=<optimized out>) at testcode/unitmain.c:896

Comment 4 Fedora Update System 2022-06-04 14:17:50 UTC
FEDORA-2022-065250af77 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-065250af77

Comment 5 Fedora Update System 2022-06-05 02:20:09 UTC
FEDORA-2022-065250af77 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-065250af77`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-065250af77

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2022-06-20 01:08:35 UTC
FEDORA-2022-065250af77 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.