Bug 1935390
Summary: | Need to fix gnuradio on EPEL8 | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Orion Poplawski <orion> |
Component: | gnuradio | Assignee: | Jaroslav Škarvada <jskarvad> |
Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel8 | CC: | edward.vielmetti, fedora, jskarvad, lucilanga, marcus |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 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: |
Description
Orion Poplawski
2021-03-04 19:35:01 UTC
(In reply to Orion Poplawski from comment #0) > Description of problem: > > The current gnuradio package in EPEL8 has a couple issues. Unfortunately, I > never submitted my changes back when I first made them last August - so I'm > not sure the best way to proceed. > > My changes were to: > - update to 3.8.1.0 > - Add Requires on python3-qt5-base and python3-pyqt5-sip > - add an upstream patch for sip support > - Undefine __cmake_in_source_build for Fedora < 33 and EPEL 8 compatibility > No problem to update. Could you provide link to the sip patch? > most of these have already happened in the mainline branch except for the > added requires. > > In the meantime, mainline has updated to 3.9.0.0, added BRs on volk which is > not in EPEL8 > > So: > - is it appropriate to update to 3.9.0.0 in EPEL8? > - if so, should we get volk into EPEL8? > > otherwise we could update just to 3.8.2.0 in EPEL8. I don't think that rebasing to 3.9.0.0 in EPEL is a good thing at the moment. I had very hard time with the rebase in f34/f35 and it is still not finished. At the moment I am debugging some obscure crashes of gr-funcube on ppc64le/s390x which replaced gr-fcdproplus, some other packages got very experimental patches which are not yet upstreamed. It can break a lot of things. (In reply to Jaroslav Škarvada from comment #1) > (In reply to Orion Poplawski from comment #0) > > Description of problem: > > > > The current gnuradio package in EPEL8 has a couple issues. Unfortunately, I > > never submitted my changes back when I first made them last August - so I'm > > not sure the best way to proceed. > > > > My changes were to: > > - update to 3.8.1.0 > > - Add Requires on python3-qt5-base and python3-pyqt5-sip > > - add an upstream patch for sip support > > - Undefine __cmake_in_source_build for Fedora < 33 and EPEL 8 compatibility > > > No problem to update. Could you provide link to the sip patch? > > > most of these have already happened in the mainline branch except for the > > added requires. > > > > In the meantime, mainline has updated to 3.9.0.0, added BRs on volk which is > > not in EPEL8 > > > > So: > > - is it appropriate to update to 3.9.0.0 in EPEL8? > > - if so, should we get volk into EPEL8? > > > > otherwise we could update just to 3.8.2.0 in EPEL8. > > I don't think that rebasing to 3.9.0.0 in EPEL is a good thing at the > moment. I had very hard time with the rebase in f34/f35 and it is still not > finished. At the moment I am debugging some obscure crashes of gr-funcube on > ppc64le/s390x which replaced gr-fcdproplus, some other packages got very > experimental patches which are not yet upstreamed. It can break a lot of > things. It's also worth to mention that volk API is broken on ppc64le/s390x https://github.com/gnuradio/volk/issues/442 Just a side note on this: I'm working on a pull request again the rpm main branch, which for the 3.10 release series sets the dependency versions correctly, so that moving forward, it's at least clear which dependencies are permissible; this should help future redhatoid portings. |