netresolve failed to build from source in Fedora rawhide/f34 https://koji.fedoraproject.org/koji/taskinfo?taskID=60911101 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild Please fix netresolve at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, netresolve will be orphaned. Before branching of Fedora 35, netresolve will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 1753480 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 1753481 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1753482 [details] state.log
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Dear Maintainer, your package has an open Fails To Build From Source bug for Fedora 34. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. If you have already fixed this issue, please close this Bugzilla report. Following the policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks (not sooner than 2021-03-29). A week before the mass branching of Fedora 35 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 33 will be retired regardless of the status of this bug. [1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
Mark -- I've cc'd you into this bug because I think a valgrind failure is what is ultimately causing netresolve to fail its testsuite on aarch64. In particular we see this in the log: FAIL: tests/test-netresolve.sh ============================== + DIFF='diff -u' + NR='libtool execute valgrind --leak-check=full --error-exitcode=1 ./netresolve' + DATA=./tests/data + diff -u /dev/fd/63 ./tests/data/any ++ libtool execute valgrind --leak-check=full --error-exitcode=1 ./netresolve ==10394== Memcheck, a memory error detector ==10394== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==10394== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==10394== Command: /builddir/build/BUILD/netresolve-0.0.1/.libs/lt-netresolve ==10394== valgrind: m_debuginfo/readdwarf.c:2819 (copy_convert_CfiExpr_tree): Assertion 'Unimplemented functionality' failed. valgrind: valgrind host stacktrace: ==10394== at 0x58042C80: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x58042DD7: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x58042F43: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580C6D8F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580C6CE7: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580C6CAB: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580C72EF: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580CC97B: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x5807D323: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x5807273F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580A2F23: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580AF9EB: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x5809EC03: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x5809A093: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x5809C847: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0x580E931F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==10394== by 0xFFFFFFFFFFFFFFFF: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 222 (lwpid 10394) ==10394== at 0x401A720: mmap (in /usr/lib64/ld-2.33.so) ==10394== by 0x4007A47: _dl_map_object_from_fd (in /usr/lib64/ld-2.33.so) ==10394== by 0x4008AAF: _dl_map_object (in /usr/lib64/ld-2.33.so) ==10394== by 0x400CD8F: openaux (in /usr/lib64/ld-2.33.so) ==10394== by 0x4A4FAFF: _dl_catch_exception (in /usr/lib64/libc-2.33.so) ==10394== by 0x400D2E3: _dl_map_object_deps (in /usr/lib64/ld-2.33.so) ==10394== by 0x401288B: dl_open_worker (in /usr/lib64/ld-2.33.so) ==10394== by 0x4A4FAFF: _dl_catch_exception (in /usr/lib64/libc-2.33.so) ==10394== by 0x40123C3: _dl_open (in /usr/lib64/ld-2.33.so) ==10394== by 0x4AC5307: dlopen_doit (in /usr/lib64/libdl-2.33.so) ==10394== by 0x4A4FAFF: _dl_catch_exception (in /usr/lib64/libc-2.33.so) ==10394== by 0x4A4FBD3: _dl_catch_error (in /usr/lib64/libc-2.33.so) ==10394== by 0x4AC5C77: _dlerror_run (in /usr/lib64/libdl-2.33.so) ==10394== by 0x4AC53BF: dlopen@@GLIBC_2.17 (in /usr/lib64/libdl-2.33.so) ==10394== by 0x488A62F: load_backend (context.c:120) ==10394== by 0x488A927: netresolve_set_backend_string (context.c:180) ==10394== by 0x488D057: netresolve_query_new (query.c:238) ==10394== by 0x488D207: netresolve_query (query.c:269) ==10394== by 0x488D3A7: netresolve_query_forward (query.c:304) ==10394== by 0x10AD67: main (netresolve.c:402) client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFE5F0 valgrind stack range: [0x1002CB8000 0x1002DB7FFF] top usage: 17936 of 1048576 If you could take a look, it'd be appreciated. Thanks, Jeff
Yes, that is definitely a valgrind bug. This function (copy_convert_CfiExpr_tree) is not implemented for arm64. I am surprised this is the first time we have hit this. It shouldn't be that hard to implement, it should be a simple mapping from DWARF register numbers to arm64 registers. But I am away for a couple of days. So it might take a bit.
FEDORA-2021-239f5f1028 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-239f5f1028
Sorry, was on vacation for a couple of days and it took a while to get back to this issue. But I think it has been resolved with valgrind-3.16.1-20.fc34. A local build of netresolve succeeds with all testcases run under valgrind.
FEDORA-2021-239f5f1028 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-239f5f1028` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-239f5f1028 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The netresolve package is now orphaned.
FEDORA-2021-239f5f1028 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.