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.
Description of problem:
I totally don't know how that happened, but the library built in brew is missing some API symbols. When I build the package myself via `rpmbuild --rebuild`, it is OK. The same applies for the centos-stream build in KOJI -- the build is OK. I have built a scratchbuild in brew and it is OK. So it appears that something must have been broken in brew at the time the build was being built.
Version-Release number of selected component (if applicable):
libtraceevent-1.5.3-1.el9 from brew
How reproducible:
100% -- the library just does not contain some symbols
Steps to Reproduce:
1. readelf -Ws /usr/lib64/libtraceevent.so.1.5.3 | grep tep_filter
2.
3.
Actual results:
no entries are found
Expected results:
10 entries are found:
72: 0000000000014c80 33 FUNC GLOBAL DEFAULT 13 tep_filter_free
73: 0000000000015810 492 FUNC GLOBAL DEFAULT 13 tep_filter_copy
95: 0000000000015e40 260 FUNC GLOBAL DEFAULT 13 tep_filter_match
104: 0000000000012790 200 FUNC GLOBAL DEFAULT 13 tep_filter_remove_event
113: 0000000000013f40 59 FUNC GLOBAL DEFAULT 13 tep_filter_alloc
115: 0000000000012980 354 FUNC GLOBAL DEFAULT 13 tep_filter_compare
122: 0000000000013220 86 FUNC GLOBAL DEFAULT 13 tep_filter_strerror
160: 0000000000015160 1706 FUNC GLOBAL DEFAULT 13 tep_filter_add_filter_str
174: 0000000000012920 85 FUNC GLOBAL DEFAULT 13 tep_filter_make_string
197: 0000000000012860 93 FUNC GLOBAL DEFAULT 13 tep_filter_reset
Additional info:
Link to the broken BREW build:
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=2178971
Link to the correct build in KOJI:
https://kojihub.stream.centos.org/koji/buildinfo?buildID=25343
Link to the correct scratchbuild in BREW:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=48278346
It's also worth of noting that there were some outages in Westford, and also that previous build in brew was unsuccessful, because the i686 variant could not be linked. I was investigating it and was totally out of ideas, so I just kicked off the build again with no source changes. It passed and linked i686 libs well. However, now it seems that this build was also broken, but in a different way.
Let's just bump NVR and rebuild it, since from the scratchbuild above, and from the koji build for c9s, it is highly probable, that correct library will be build this time.
The problem is not in the rebase itself, for me it works on my testing box well:
# rpmquery libtraceevent trace-cmd
libtraceevent-1.5.3-1.el9.x86_64
trace-cmd-2.9.2-9.el9.x86_64
[root@intel-sharkbay-mb-01 ~]# systemctl start trace-cmd
[root@intel-sharkbay-mb-01 ~]# systemctl status trace-cmd
● trace-cmd.service - trace-cmd Flightrecorder
Loaded: loaded (/usr/lib/systemd/system/trace-cmd.service; disabled; vendor preset: disabled)
Active: active (exited) since Fri 2022-10-14 03:21:09 EDT; 16s ago
Process: 125560 ExecStart=/usr/bin/trace-cmd start $OPTS (code=exited, status=0/SUCCESS)
Main PID: 125560 (code=exited, status=0/SUCCESS)
CPU: 54ms
The problem is in brew, since some strange issue has broken the package build. Otherwise, it would normally work.
The example mentioned in this comment works, because the libtraceevent-1.5.3-1.el9 used here is my own local "rpmbuild --rebuild" one.
Comment 4Ziqian SUN (Zamir)
2022-10-14 07:48:57 UTC
Comment 8Ziqian SUN (Zamir)
2022-10-19 01:19:12 UTC
*** Bug 2135774 has been marked as a duplicate of this bug. ***
Comment 9Ziqian SUN (Zamir)
2022-10-19 01:22:31 UTC
For all who have been affected and need to use trace-cmd, you can make trace-cmd work again by temporary downgrade to libtraceevent-1.1.1-8.el9 before a permanent solution is applied.
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 (libtraceevent bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2023:2465
Description of problem: I totally don't know how that happened, but the library built in brew is missing some API symbols. When I build the package myself via `rpmbuild --rebuild`, it is OK. The same applies for the centos-stream build in KOJI -- the build is OK. I have built a scratchbuild in brew and it is OK. So it appears that something must have been broken in brew at the time the build was being built. Version-Release number of selected component (if applicable): libtraceevent-1.5.3-1.el9 from brew How reproducible: 100% -- the library just does not contain some symbols Steps to Reproduce: 1. readelf -Ws /usr/lib64/libtraceevent.so.1.5.3 | grep tep_filter 2. 3. Actual results: no entries are found Expected results: 10 entries are found: 72: 0000000000014c80 33 FUNC GLOBAL DEFAULT 13 tep_filter_free 73: 0000000000015810 492 FUNC GLOBAL DEFAULT 13 tep_filter_copy 95: 0000000000015e40 260 FUNC GLOBAL DEFAULT 13 tep_filter_match 104: 0000000000012790 200 FUNC GLOBAL DEFAULT 13 tep_filter_remove_event 113: 0000000000013f40 59 FUNC GLOBAL DEFAULT 13 tep_filter_alloc 115: 0000000000012980 354 FUNC GLOBAL DEFAULT 13 tep_filter_compare 122: 0000000000013220 86 FUNC GLOBAL DEFAULT 13 tep_filter_strerror 160: 0000000000015160 1706 FUNC GLOBAL DEFAULT 13 tep_filter_add_filter_str 174: 0000000000012920 85 FUNC GLOBAL DEFAULT 13 tep_filter_make_string 197: 0000000000012860 93 FUNC GLOBAL DEFAULT 13 tep_filter_reset Additional info: Link to the broken BREW build: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=2178971 Link to the correct build in KOJI: https://kojihub.stream.centos.org/koji/buildinfo?buildID=25343 Link to the correct scratchbuild in BREW: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=48278346 It's also worth of noting that there were some outages in Westford, and also that previous build in brew was unsuccessful, because the i686 variant could not be linked. I was investigating it and was totally out of ideas, so I just kicked off the build again with no source changes. It passed and linked i686 libs well. However, now it seems that this build was also broken, but in a different way. Let's just bump NVR and rebuild it, since from the scratchbuild above, and from the koji build for c9s, it is highly probable, that correct library will be build this time.