Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1756170 - [RFE] libcec build for epel8
Summary: [RFE] libcec build for epel8
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: libcec
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-26 23:29 UTC by Gary Buhrmaster
Modified: 2021-01-17 18:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Gary Buhrmaster 2019-09-26 23:29:18 UTC
Please build libcec package for epel8

Comment 1 Fedora Update System 2019-11-06 21:03:23 UTC
FEDORA-EPEL-2019-552403d0b5 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-552403d0b5

Comment 2 Fedora Update System 2019-11-07 03:05:44 UTC
libcec-4.0.4-5.el8 has been pushed to the Fedora EPEL 8 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-2019-552403d0b5

Comment 3 Gary Buhrmaster 2019-11-27 18:22:25 UTC
While the last status update was "ON_QA", I now note the package has been unpushed from testing.  Is there a schedule for a new build?

Comment 4 Peter Robinson 2019-11-27 19:33:18 UTC
(In reply to Gary Buhrmaster from comment #3)
> While the last status update was "ON_QA", I now note the package has been
> unpushed from testing.  Is there a schedule for a new build?

No, people should be using the new kernel based CEC support, it supports a lot more hardware than libcec, is actively maintained and allows use of the standard kernel remote control interface.

Comment 5 Gary Buhrmaster 2019-11-27 19:52:17 UTC
Fair enough, but there are existing projects that still depend on libcec for various reasons.  I will need to poke them regarding their plans.

As the package maintainer, I presume you should close this bug as WONTFIX.

Thanks.

Comment 6 Richard Shaw 2020-06-06 16:47:27 UTC
Peter, I asked about kernel support for cec on the MythTV development list and they have a different perspective. 

http://lists.mythtv.org/pipermail/mythtv-dev/2020-June/078439.html

Comment 7 Peter Robinson 2020-06-06 17:02:38 UTC
(In reply to Richard Shaw from comment #6)
> Peter, I asked about kernel support for cec on the MythTV development list
> and they have a different perspective. 
> 
> http://lists.mythtv.org/pipermail/mythtv-dev/2020-June/078439.html

They have got completely the wrong end of the stick.

Comment 8 Peter Robinson 2020-06-06 17:06:10 UTC
See the CEC stack https://cateee.net/lkddb/web-lkddb/CEC_CORE.html

It already supports and order of magnitude more HW than libcec, and sure they did a release of libcec recently, but prior to that it was limping along and a single release is no proof it's not dead.

Comment 9 Peter Robinson 2020-06-06 17:07:07 UTC
If you want to support it I'll assign you the maintainer for EPEL and you can maintain it, I will not be.

Comment 10 Peter Robinson 2020-06-06 17:10:09 UTC
and on this point:

"Currently no. In the future - my gut feeling is that the way forward
is libcec using the native/kernel interface. That way we get the
benefits of both (device support from the kernel and a useful API from
libcec)."

It probably just works via the Remote Control interface: https://cateee.net/lkddb/web-lkddb/MEDIA_CEC_RC.html

Comment 11 Andrew Bauer 2020-07-10 17:15:53 UTC
(In reply to Peter Robinson from comment #9)
> If you want to support it I'll assign you the maintainer for EPEL and you
> can maintain it, I will not be.

hi Peter - I'll be glad to be the maintainer of this package for EPEL branches. My FAS account: kni

Comment 12 Gary Buhrmaster 2020-07-11 04:45:54 UTC
As I recall from one of the recent pull request merges, with the latest release, libcec is now (sort of) a (legacy libcec) API wrapper around the linux kernel CEC support.  Which means projects can, and because it is the easy path forward today likely will, defer making any underlying changes to use the kernel CEC APIs directly.  For projects that attempt to be somewhat cross platform that may even be a perfectly reasonable choice for the longer term.

btw, when I briefly glanced at the latest libcec I seem to recall the cmake version requirement for libcec has been bumped to a version greater than what epel8 currently provides.  I don't know if that is just the lowest version the project tested with (which would make it fairly easy to just change the level requirement) or whether that bump reflects use of some new construct that will require additional changes to the cmake definitions.

Comment 13 Andrew Bauer 2020-07-11 14:08:03 UTC
Just for the sake of trying, I patched yesterday's release of libcec 4.0.7 to build with cmake 3.11, rather than 3.12. It built just fine. 

For amusement, one can get it here:
https://copr.fedorainfracloud.org/coprs/kni/mythtvdeps-el8/

We are getting ahead of ourselves, however.

Peter has signaled he doesn't want to build libcec for epel. I am hopeful he will follow through with the latter part of his statement and let one of us do the work. 

Peter, we would all appreciate it if you would let one us maintain libcec for EPEL branches.


Note You need to log in before you can comment on or make changes to this bug.