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:
Failing in the CI, /rpminspect/runpath test.

I'm not sure exactly, how the flag is set, but it's probably auto-detected in exconf.rb - 
https://github.com/brianmario/mysql2/blob/ca883e1a359a10f48ac5d0ce649827b424110cd7/ext/mysql2/extconf.rb#L253

Either it's a false positive (/usr/lib64/ looks ok to me), or the RPATH is not supposed to be set at all.


Version-Release number of selected component (if applicable):
rubygem-mysql2-0.5.3-9.el9


Actual results:
```
4) /usr/lib64/gems/ruby/mysql2-0.5.3/mysql2/mysql2.so has an invalid-looking DT_RPATH on x86_64: /usr/lib64/

Result: VERIFY
Waiver Authorization: Anyone

Suggested Remedy:
Either DT_RPATH or DT_RUNPATH properties were found on ELF shared objects in this package.  The use of DT_RPATH and DT_RUNPATH is discouraged except in certain situations.  Check to see that you a disabling rpath during the %build stage of the spec file.  If you are unable to do this easily, you can try using a program such as patchelf to remove these properties from the ELF files.
```
Same for all architectures.

Expected results:
No DT_RPATH, probably.


Additional info:

This was introduced in Fedora-
https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild

Corresponding test run:
https://dashboard.osci.redhat.com/#/artifact/brew-build/aid/38136267?focus=id:ef4b7e83ebaf59ebeb1785de4d2ce349fa765d81baf850a15e8db8d657b4d24c

Just FTR, there was already previous instances of this issue:

bug 1715073
bug 1572172

But IMHO, it'd be better if the RPATH was removed.

(In reply to Vít Ondruch from comment #2)
> Just FTR, there was already previous instances of this issue:
> 
> bug 1715073
> bug 1572172

Thanks, I forgot to look here in bugzilla.

> 
> But IMHO, it'd be better if the RPATH was removed.

Agreed. Unless it breaks something, there's no need for exception.
There's option to unset it during build, but I think it's worth asking first:
https://github.com/brianmario/mysql2/issues/1201

> Agreed. Unless it breaks something, there's no need for exception.
> There's option to unset it during build, but I think it's worth asking first:
> https://github.com/brianmario/mysql2/issues/1201

I would like to avoid an exception.
How can we work with this ticket? Do we change this ticket's status to NOTABUG or something[1]?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1572172#c3

I think this should be addressed in Fedora first. And once it is fixed there, we can address in c9s.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.