Bug 1180838
| Summary: | broken package dependencies | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Wade Berrier <wberrier> |
| Component: | lirc | Assignee: | Richard Shaw <hobbes1069> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel7 | CC: | hobbes1069, jarodwilson, ktdreyer, leamas.alec, pb |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | lirc-0.10.0-3.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-09-08 23:48:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Ok, I've worked on this off and on but I can't seem to make rpmbuild realize there's a dependency there. Something isn't working quite right. Also, as of 0.9.2, the python dependency has changed to python3 which does not exist in epel7. fixed (finally!) in 2:1.1.0-9 I think this issue is still not fixed, because EPEL7 has still only lirc-0.9.1a-4.el7.x86_64 in repository, where is 1.1.0-9 for EL7? @richard: This is all my fault. The mess comes from (trying to) change the deps. "Old" lirc had iguanaIR as a dep, while the new is the other way around: iguanaIR depends on lirc. This reflects the change from a built-in iguanaIR driver to a plugin. To make this change more interesting,in the same cycle upstream iguanaIR changed the soname without actually changing the sources (they changed from autotools to cmake, which generated a new soname from same source). This basically got me stuck in a bad dependency circle, the loophole was to add the evil soname patching to iguanaIR + an epoch. BTW: isn't python3 available in epel-7 these days? Hope this helps... Yes, as python34 it seems. I haven't had much time lately between $DAYJOB and $HOMELIFE but I'll see if I can dig into this. lirc-0.10.0-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b29bef7216 lirc-0.10.0-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b29bef7216 lirc-0.10.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b29bef7216 lirc-0.10.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b29bef7216 lirc-0.10.0-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b29bef7216 lirc-0.10.0-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b29bef7216 lirc-0.10.0-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: installing lirc via yum results in a binary that can't be started because of missing libraries. Version-Release number of selected component (if applicable): lirc-0.9.1a-4.el7 How reproducible: Every time Steps to Reproduce: 1. yum install lirc 2. /usr/sbin/lircd --nodaemon Actual results: /usr/sbin/lircd: error while loading shared libraries: IGUANAIR_0: cannot open shared object file: No such file or directory Expected results: It should load and be able to resolve all libraries. Additional info: ldd /usr/sbin/lircd shows: linux-vdso.so.1 => (0x00007fffbc3fe000) libasound.so.2 => /lib64/libasound.so.2 (0x00007f3162017000) IGUANAIR_0 => not found libirman.so.0 => /lib64/libirman.so.0 (0x00007f3161e10000) libportaudio.so.2 => /lib64/libportaudio.so.2 (0x00007f3161be1000) libm.so.6 => /lib64/libm.so.6 (0x00007f31618df000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f31616db000) libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f31614d5000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f31612b9000) libsystemd-daemon.so.0 => /lib64/libsystemd-daemon.so.0 (0x00007f31610b4000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3160e9e000) libc.so.6 => /lib64/libc.so.6 (0x00007f3160add000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f31608d8000) librt.so.1 => /lib64/librt.so.1 (0x00007f31606d0000) /lib64/ld-linux-x86-64.so.2 (0x00007f3162565000) libjack.so.0 => /lib64/libjack.so.0 (0x00007f3160477000) libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f3160263000) libopus.so.0 => /lib64/libopus.so.0 (0x00007f3160021000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f315fd1a000) Something isn't quite right there with IGUANAIR_0. Turns out there's a package that resolves this: iguanaIR Installing that package fixes it. But, I imagine the package dependency wasn't created automatically because of the weird iguanaIR library packaging: ldd /usr/sbin/lircd <snip> IGUANAIR_0 => /lib64/IGUANAIR_0 (0x00007f1d9de77000) <snip>