+++ 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
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
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.
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
FEDORA-2022-065250af77 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-065250af77
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.
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.