Description of problem: $ radare2 -e bin.cache=true -e bin.demangle=true /lib64/libc.so.6 [0x000276d0]> asl ftruncate 77 [0x000276d0]> asl 77 ERROR: Unknown syscall number Version-Release number of selected component (if applicable): radare2-5.8.2-1.fc38.x86_64 How reproducible: Always Steps to Reproduce: 1. See above 2. 3. Actual results: 'asl ftruncate' works and returns 77, but 'asl 77' does not work Expected results: 'asl 77' returns ftruncate Additional info: This seems to be some issue around generation of /usr/share/radare2/5.8.2/syscall/linux-x86-64.sdb . Workaround: If I replace even only linux-x86-64.sdb with the one from the github linux-static build, this does work. Other related stuff: With fedora sdb: $ radare2 -e bin.cache=true -e bin.demangle=true /lib64/libc.so.6 [0x000276d0]> k syscall/*~^0x|grep ftruncate [0x000276d0]> With github sdb: $ radare2 -e bin.cache=true -e bin.demangle=true /lib64/libc.so.6 [0x000276d0]> k syscall/*~^0x|grep ftruncate 0x80.77=ftruncate [0x000276d0]> I tried comparing how they are built. Fedora is built in [1]. Can't see how exactly to find the github action for building a specific tag, so took randomly one of the latest builds there [2]. It seems like fedora is building with meson, and github with make. The specific commands: fedora: [399/1188] /builddir/build/BUILD/radare2-5.8.2/x86_64-redhat-linux-gnu/sdb libr/syscall/d/linux-x86-64.sdb == ../libr/syscall/d/linux-x86-64.sdb.txt github: 2023-02-08T19:48:06.8914288Z "/bin/sh" gen.sh < linux-x86-64.sdb.txt | ../../..//libr/../shlr/sdb//sdb linux-x86-64.sdb = I didn't (yet?) dive into the specifics, try to build locally and compare, understand why fedora uses meson and github does not (at least for linux-static), gen.sh, etc. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=97322791 [2] https://github.com/radareorg/radare2/actions/runs/4127735691/jobs/7131308671
Hello, thanks for the excellent bug report. I guess this could be because of the sdb version. Upstream build is using the online git version of sdb to sync. Fedora has strict packaging rules that every source needs to be in the package so the process is repeatable. Let me check. Michal Ambroz
Hmph ... the version of sdb embedded in the radare2 5.8.2 release is not significantly different to what is in the current git. It should be allright. But there is something strange, now it even segfaulted to me on /bin/false and the segfault is also in the sdb code: Starting program: /usr/bin/radare2 /bin/false [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [Detaching after fork from child process 637038] Program received signal SIGSEGV, Segmentation fault. sdb_hash_len (len=0x0, s=0x1a0 <error: Cannot access memory at address 0x1a0>) at ../shlr/sdb/src/util.c:76 76 while (*s) { (gdb) bt #0 sdb_hash_len (len=0x0, s=0x1a0 <error: Cannot access memory at address 0x1a0>) at ../shlr/sdb/src/util.c:76 #1 sdb_hash (s=0x1a0 <error: Cannot access memory at address 0x1a0>) at ../shlr/sdb/src/util.c:89 #2 0x00007ffff72f2d8c in hashRBinElfSymbol.lto_priv.1 () at ../libr/bin/format/elf/elf.c:3607 #3 0x0000555555565563 in hashfn (k=0x5555557d8f70, ht=0x5555557292a0) at ../shlr/sdb/src/ht.inc:20 #4 bucketfn (k=0x5555557d8f70, ht=0x5555557292a0) at ../shlr/sdb/src/ht.inc:24 #5 reserve_kv (ht=ht@entry=0x5555557292a0, key=key@entry=0x5555557d8f70, key_len=0, update=update@entry=false) at ../shlr/sdb/src/ht.inc:186 #6 0x000055555556589a in insert_update (ht=0x5555557292a0, key=0x5555557d8f70, value=0x5555557d8f70, update=<optimized out>) at ../shlr/sdb/src/ht.inc:226 #7 0x00007ffff72f989e in Elf64__r_bin_elf_get_symbols_imports (bin=0x55555578a6b0, type=3) at ../libr/bin/format/elf/elf.c:3824 #8 0x00007ffff72b4000 in Elf64_r_bin_elf_get_symbols (bin=0x55555578a6b0) at ../libr/bin/format/elf/elf.c:3963 #9 entries (bf=<optimized out>) at ../libr/bin/p/bin_elf.inc:687 #10 0x00007ffff72a47b7 in r_bin_object_set_items (bf=bf@entry=0x555555792970, bo=bo@entry=0x555555787850) at ../libr/bin/bobj.c:305 #11 0x00007ffff72a5147 in r_bin_object_new (bf=0x555555792970, plugin=0x5555555f51e0, baseaddr=18446744073709551615, loadaddr=0, offset=0, sz=33248) at ../libr/bin/bobj.c:169 #12 0x00007ffff7295434 in r_bin_file_new_from_buffer (pluginname=<optimized out>, fd=<optimized out>, loadaddr=<optimized out>, baseaddr=<optimized out>, rawstr=<optimized out>, buf=<optimized out>, file=<optimized out>, bin=<optimized out>) at ../libr/bin/bfile.c:610 #13 r_bin_open_buf (bin=bin@entry=0x5555555f08f0, buf=buf@entry=0x555555787470, opt=opt@entry=0x7fffffffd400) at ../libr/bin/bin.c:284 #14 0x00007ffff7295b13 in r_bin_open_io (bin=0x5555555f08f0, opt=opt@entry=0x7fffffffd400) at ../libr/bin/bin.c:347 #15 0x00007ffff7577e26 in r_core_file_do_load_for_io_plugin (loadaddr=0, baseaddr=18446744073709551615, r=0x7ffff619e010) at ../libr/core/cfile.c:437 #16 r_core_bin_load (r=r@entry=0x7ffff619e010, filenameuri=0x5555557873e0 "/bin/false", baddr=baddr@entry=18446744073709551615) at ../libr/core/cfile.c:647 #17 0x00007ffff7e24445 in binload (baddr=18446744073709551615, filepath=<optimized out>, r=0x7ffff619e010) at ../libr/main/radare2.c:468 #18 r_main_radare2 (argc=<optimized out>, argv=<optimized out>) at ../libr/main/radare2.c:1389 #19 0x00007ffff7c4e510 in __libc_start_call_main (main=main@entry=0x555555561840 <main>, argc=argc@entry=2, argv=argv@entry=0x7fffffffd718) at ../sysdeps/nptl/libc_start_call_main.h:58 #20 0x00007ffff7c4e5c9 in __libc_start_main_impl (main=0x555555561840 <main>, argc=2, argv=0x7fffffffd718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd708) at ../csu/libc-start.c:381 #21 0x0000555555561a85 in _start ()
dnf reinstall radare2 rpm -Va radare2 $ rpm -qi radare2 Name : radare2 Version : 5.8.2 Release : 1.fc37 Architecture: x86_64 Install Date: 2023-02-19T22:52:53 CET Group : Unspecified Size : 21706216 License : LGPLv3+ and GPLv2+ and BSD and MIT and ASL 2.0 and MPLv2.0 and zlib Signature : RSA/SHA256, 2023-02-06T06:11:05 CET, Key ID f55ad3fb5323552a Source RPM : radare2-5.8.2-1.fc37.src.rpm Build Date : 2023-02-06T00:08:49 CET Build Host : buildvm-x86-27.iad2.fedoraproject.org Packager : Fedora Project Vendor : Fedora Project URL : https://radare.org/ Bug URL : https://bugz.fedoraproject.org/radare2 Summary : The reverse engineering framework Description : The radare2 is a reverse-engineering framework that is multi-architecture, multi-platform, and highly scriptable. Radare2 provides a hexadecimal editor, wrapped I/O, file system support, debugger support, diffing between two functions or binaries, and code analysis at opcode, basic block, and function levels. ... all clean $ radare2 /bin/bash WARN: run r2 with -e bin.cache=true to fix relocations in disassembly [0x00032ed0]> asl 77 ftruncate [0x00032ed0]> asl ftruncate 77 [0x00032ed0]> [0x00032ed0]> k syscall/*~^0x|grep ftruncate 0x80.77=ftruncate $ radare2 /lib64/libc.so.6 WARN: run r2 with -e bin.cache=true to fix relocations in disassembly [0x000276d0]> asl 77 ftruncate [0x000276d0]> asl ftruncate 77 [0x000276d0]> k syscall/*~^0x|grep ftruncate 0x80.77=ftruncate [0x000276d0]> $ radare2 -e bin.cache=true -e bin.demangle=true /bin/false [0x00002960]> asl 77 ftruncate [0x00002960]> asl ftruncate 77 [0x00002960]> k syscall/*~^0x|grep ftruncate 0x80.77=ftruncate [0x00002960]> [0x00002960]> I am sorry I am not able to reproduce with the fresh install from the Fedora repository for F37. Are you doing the tests on F38 ? Michal Ambroz
(In reply to Michal Ambroz from comment #3) > dnf reinstall radare2 Please note that the sdb files are part of radare2-common. Not sure that's relevant here. [snip] > I am sorry I am not able to reproduce with the fresh install from the Fedora > repository for F37. > Are you doing the tests on F38 ? Sorry, I lied, or at least, let's say, wasn't specific enough... I never tried radare2 yet on fedora, any version. We have .gitlab-ci.yml that has (simplified, skipping hopefully-irrelevant stuff): ======================================================================== --- stages: - test Fedora Latest: image: fedora:latest stage: test tags: - docker before_script: - dnf install -y --setopt=install_weak_deps=False git meson gcc glibc-devel python3-pip python3-devel graphviz-devel radare2 # Other stuff to prepare the test env and actually run the tests ======================================================================== This failed, so I started investigating. What eventually fixed it (a workaround for current bug) is to replace linux-x86-64.sdb with a copy from the github linux-static build. I also tried this locally on my (RHEL 8) laptop, with a container. I now verified again with something minimal: ======================================================================== $ more * | cat :::::::::::::: Containerfile :::::::::::::: FROM registry.fedoraproject.org/fedora as fedora-latest RUN sudo dnf install -y radare2 CMD ["bash"] :::::::::::::: run-build-podman :::::::::::::: #!/bin/sh script="$(readlink -f "$0")" scriptdir="$(dirname "${script}")" podman build \ -f "${scriptdir}/Containerfile" \ --security-opt label=disable \ -t radare-fedora-latest :::::::::::::: run-podman :::::::::::::: #!/bin/sh podman run \ -it \ --security-opt label=disable \ localhost/radare-fedora-latest \ "$@" ======================================================================== And it behaves exactly the same: ======================================================================== $ /path/to/run-build-podman STEP 1/3: FROM registry.fedoraproject.org/fedora AS fedora-latest STEP 2/3: RUN sudo dnf install -y radare2 Fedora 37 - x86_64 3.1 MB/s | 82 MB 00:26 Fedora 37 openh264 (From Cisco) - x86_64 2.2 kB/s | 2.5 kB 00:01 Fedora Modular 37 - x86_64 2.1 MB/s | 3.8 MB 00:01 Fedora 37 - x86_64 - Updates 7.2 MB/s | 23 MB 00:03 Fedora Modular 37 - x86_64 - Updates 1.6 MB/s | 2.9 MB 00:01 Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: radare2 x86_64 5.8.2-1.fc37 updates 4.5 M Installing dependencies: capstone x86_64 4.0.2-11.fc37 updates 859 k libuv x86_64 1:1.44.2-2.fc37 fedora 151 k libzip x86_64 1.9.2-2.fc37 fedora 65 k radare2-common noarch 5.8.2-1.fc37 updates 1.8 M xxhash-libs x86_64 0.8.1-3.fc37 fedora 41 k Transaction Summary ================================================================================ Install 6 Packages Total download size: 7.4 M Installed size: 42 M Downloading Packages: (1/6): libzip-1.9.2-2.fc37.x86_64.rpm 229 kB/s | 65 kB 00:00 (2/6): xxhash-libs-0.8.1-3.fc37.x86_64.rpm 134 kB/s | 41 kB 00:00 (3/6): libuv-1.44.2-2.fc37.x86_64.rpm 422 kB/s | 151 kB 00:00 (4/6): capstone-4.0.2-11.fc37.x86_64.rpm 774 kB/s | 859 kB 00:01 (5/6): radare2-common-5.8.2-1.fc37.noarch.rpm 1.5 MB/s | 1.8 MB 00:01 (6/6): radare2-5.8.2-1.fc37.x86_64.rpm 3.3 MB/s | 4.5 MB 00:01 -------------------------------------------------------------------------------- Total 3.1 MB/s | 7.4 MB 00:02 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : capstone-4.0.2-11.fc37.x86_64 1/6 Installing : xxhash-libs-0.8.1-3.fc37.x86_64 2/6 Installing : libzip-1.9.2-2.fc37.x86_64 3/6 Installing : libuv-1:1.44.2-2.fc37.x86_64 4/6 Installing : radare2-common-5.8.2-1.fc37.noarch 5/6 Installing : radare2-5.8.2-1.fc37.x86_64 6/6 Running scriptlet: radare2-5.8.2-1.fc37.x86_64 6/6 Verifying : libuv-1:1.44.2-2.fc37.x86_64 1/6 Verifying : libzip-1.9.2-2.fc37.x86_64 2/6 Verifying : xxhash-libs-0.8.1-3.fc37.x86_64 3/6 Verifying : capstone-4.0.2-11.fc37.x86_64 4/6 Verifying : radare2-5.8.2-1.fc37.x86_64 5/6 Verifying : radare2-common-5.8.2-1.fc37.noarch 6/6 Installed: capstone-4.0.2-11.fc37.x86_64 libuv-1:1.44.2-2.fc37.x86_64 libzip-1.9.2-2.fc37.x86_64 radare2-5.8.2-1.fc37.x86_64 radare2-common-5.8.2-1.fc37.noarch xxhash-libs-0.8.1-3.fc37.x86_64 Complete! --> 6b414943e61 STEP 3/3: CMD ["bash"] COMMIT radare-fedora-latest --> 94b7bf9b2df Successfully tagged localhost/radare-fedora-latest:latest 94b7bf9b2df66263bcfe8a145c0e9f66c1ae221918ad4165d4d12bc4412e4191 $ /path/to/run-podman [root@3d0837c045fa /]# radare2 /bin/bash WARN: run r2 with -e bin.cache=true to fix relocations in disassembly [0x00032ed0]> asl 77 ERROR: Unknown syscall number ======================================================================== Is it possible that such a trivial behavior will work fine on a real machine and fail in a container? Weird. I also note that the fedora build sdb is ~ half the github one: ======================================================================== [root@3d0837c045fa /]# ls -l /usr/share/radare2/5.8.2/syscall/linux-x86-64.sdb -rw-r--r--. 1 root root 16099 Feb 5 23:09 /usr/share/radare2/5.8.2/syscall/linux-x86-64.sdb $ ll usr/share/radare2/5.8.2/syscall/linux-x86-64.sdb -rw-r--r--. 1 ybardavi ybardavi 30168 Jan 23 13:04 usr/share/radare2/5.8.2/syscall/linux-x86-64.sdb ======================================================================== Perhaps you can check yours? Perhaps you have a custom R2_PREFIX or something like that? Thanks!
I built radare2 locally with sys/install.sh and can verify that indeed this works: "/bin/sh" gen.sh < linux-x86-64.sdb.txt | ../../..//libr/../shlr/sdb//sdb linux-x86-64.sdb = As in, generates the same file as in linux-static, but this "fails", as in generates the fedora file: ../../..//libr/../shlr/sdb//sdb linux-x86-64.sdb == linux-x86-64.sdb.txt See also e.g.: $ "/bin/sh" gen.sh < linux-x86-64.sdb.txt | diff -u linux-x86-64.sdb.txt - | head --- linux-x86-64.sdb.txt 2023-01-19 15:41:42.486679816 +0200 +++ - 2023-02-22 05:43:00.866363531 +0200 @@ -1,363 +1,725 @@ _=0x80 +0x80.0=read read=0x80,0,3,ipi +0x80.1=write write=0x80,1,3,izi +0x80.2=open open=0x80,2,3,zxx Checking some more, mainly grep+git log, I wonder if it was broken by this patch: https://github.com/radareorg/radare2/commit/657524aabca350db00f3bfdbf46afa587254c5b9 If so, perhaps it should be partially reverted. The parts removed by it, if I got it right, seem similar to the functionality of gen.sh. I know python and shell, but not meson, and so do not propose a patch by myself (yet?). Sorry.
21375 is essentially a duplicate of current.
> Please note that the sdb files are part of radare2-common. Not sure that's relevant here. Relevant and my fault. I didn't reinstall clean radare2-common when purging my testing environment. Indeed the 16k is problem /usr/share/radare2/5.8.2/syscall/linux-x86-64.sdb
Thanks for reporting it upstream - I see that pancake already fixed 21375 - https://github.com/radareorg/radare2/issues/21375 I will try to cherrypick the patch
FEDORA-2023-712c15b3c9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-712c15b3c9
FEDORA-EPEL-2023-51a5d1a54e has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-51a5d1a54e
FEDORA-2023-18471b6297 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-18471b6297
FEDORA-EPEL-2023-572c213a03 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-572c213a03
FEDORA-2023-712c15b3c9 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-712c15b3c9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-712c15b3c9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-06f86f0ae3 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-06f86f0ae3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-7591be3f72 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-7591be3f72 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-572c213a03 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-572c213a03 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-18471b6297 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-18471b6297` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-18471b6297 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-51a5d1a54e has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-51a5d1a54e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-06f86f0ae3 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-712c15b3c9 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-18471b6297 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-572c213a03 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-51a5d1a54e has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
Michal - this issue is not completely resolved yet - please see https://github.com/radareorg/radare2/issues/21375#issuecomment-1445926582 . Not sure how best to handle this either there or here. I don't mind opening another issue/bug if you want. Thanks!
FEDORA-2023-7591be3f72 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
Sorry I have not found any arm-based machine to check.
(In reply to Michal Ambroz from comment #26) > Sorry I have not found any arm-based machine to check. Me neither, and you do not need one - just download the arm rpm, extract it, run radare on the .so file. radare does not need to run on arm for this to work.
At least from the SDB point of view it looks ok for arm64: $ sdb linux-x86-64.sdb |grep ftruncate 0x80.77=ftruncate ftruncate=0x80,77,2, $ sdb linux-arm-64.sdb |grep ftruncate ftruncate=0,46 0.46=ftruncate The linux-arm-32.sdb looks much smaller and is missing the ftruncate [/usr/share/radare2/5.8.2/syscall] 2023-03-16 11:33:33 +0100 $ ls -la -rw-r--r--. 1 root root 33876 2023-02-26_15:39:52 darwin-arm-32.sdb -rw-r--r--. 1 root root 33876 2023-02-26_15:39:52 darwin-arm-64.sdb -rw-r--r--. 1 root root 41670 2023-02-26_15:39:52 darwin-x86-32.sdb -rw-r--r--. 1 root root 47021 2023-02-26_15:39:52 darwin-x86-64.sdb -rw-r--r--. 1 root root 10870 2023-02-26_15:39:52 dos-x86-16.sdb -rw-r--r--. 1 root root 6447 2023-02-26_15:39:52 freebsd-x86-32.sdb -rw-r--r--. 1 root root 33876 2023-02-26_15:39:52 ios-arm-32.sdb -rw-r--r--. 1 root root 33876 2023-02-26_15:39:52 ios-arm-64.sdb -rw-r--r--. 1 root root 27446 2023-02-26_15:39:52 ios-x86-32.sdb -rw-r--r--. 1 root root 4696 2023-02-26_15:39:52 linux-arm-32.sdb -rw-r--r--. 1 root root 23216 2023-02-26_15:39:52 linux-arm-64.sdb -rw-r--r--. 1 root root 4707 2023-02-26_15:39:53 linux-mips-32.sdb -rw-r--r--. 1 root root 3474 2023-02-26_15:39:53 linux-sparc-32.sdb -rw-r--r--. 1 root root 30242 2023-02-26_15:39:53 linux-x86-32.sdb -rw-r--r--. 1 root root 30116 2023-02-26_15:39:53 linux-x86-64.sdb -rw-r--r--. 1 root root 1865 2023-02-26_15:39:53 netbsd-x86-32.sdb -rw-r--r--. 1 root root 15441 2023-02-26_15:39:53 openbsd-x86-32.sdb -rw-r--r--. 1 root root 15468 2023-02-26_15:39:53 openbsd-x86-64.sdb -rw-r--r--. 1 root root 15194 2023-02-26_15:39:53 s110-arm-16.sdb -rw-r--r--. 1 root root 137617 2023-02-26_15:39:53 windows-x86-32.sdb -rw-r--r--. 1 root root 137617 2023-02-26_15:39:53 windows-x86-64.sdb
there is new release - lets try to upgrade first
Please rebase the fedora build on some upstream version that includes https://github.com/radareorg/radare2/pull/21508 . Thanks!
Thanks for the help. I have pushed the updated package to rawhide. 5.8.4 contains some serious segmentation fault parsing elf files, and cherrypicking became problematic so I rather took whole git snapshot. I would rather push 5.8.6 release than 5.8.5 snapshot ... I hope it will be coming soon.
Makes sense. Thanks for the update! (I already have the mentioned workaround applied to my CI flow, and a PR ready to revert that once current bug is fixed... So not in a hurry, personally)
(In reply to Michal Ambroz from comment #31) > Thanks for the help. I have pushed the updated package to rawhide. > 5.8.4 contains some serious segmentation fault parsing elf files, and > cherrypicking became problematic so I rather took whole git snapshot. > I would rather push 5.8.6 release than 5.8.5 snapshot ... I hope it will be > coming soon. Did you actually mean "5.8.6 release than 5.8.5 snapshot", or "5.8.5 release than 5.8.5 snapshot"? Anyway, 5.8.6 was released upstream a few days ago. I can confirm that radare2-5.8.6-static.tar.xz from [1] seems to work well enough for me (using only rather little functionality). [1] https://github.com/radareorg/radare2/releases/tag/5.8.6
FEDORA-2023-5d5aa8b27a has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5d5aa8b27a
FEDORA-EPEL-2023-423bcaf739 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-423bcaf739
FEDORA-EPEL-2023-e6d2f056c2 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e6d2f056c2
FEDORA-2023-ded3d48ebc has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ded3d48ebc
FEDORA-EPEL-2023-3dd846c7ab has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-3dd846c7ab
FEDORA-EPEL-2023-423bcaf739 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-423bcaf739 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-3dd846c7ab has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-3dd846c7ab See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-e6d2f056c2 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e6d2f056c2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-5d5aa8b27a has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-5d5aa8b27a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5d5aa8b27a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ded3d48ebc has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ded3d48ebc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ded3d48ebc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-e6d2f056c2 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-423bcaf739 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-3dd846c7ab has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-ded3d48ebc has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-5d5aa8b27a has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.