6:45 p.m.
I'm working on getting MythTV packages built for EL6 and wanted to
share my plan in case someone has a better idea.
I did finally get a local build but I had to rebuild several packages
that are not available in EPEL yet:
Missing dependencies for MythTV on EPEL 6.
---
lirc
libfame
mjpegtools
-> libquicktime
-> ffmpeg
-> libvpx
-> x264
-> mplayer/mencoder (runtime)
-> em8300
-> libass
-> twolame
-> y4mscaler (runtime)
-> mjpegtools-devel
-> mjpegtools-libs
transcode
-> pvm
-> libmpeg3
-> v4l (too old)
libcrystalhd (disabled due to below)
-> gstreamer
-> gobject-introspection (needs glib2 > 2.24, EL6 has 2.22.5)
-> cairo
My plan is to submit bugs to the appropriate bugzilla's for each
package and ask the current maintainer to create an EL6 branch and
offer to co-maintain it. I will also offer to maintain the EL6 branch
if necessary but I'd rather have the original maintainer keep things
up to date.
The good news is that all the packages rebuilt without modification so
there should be minimal work on the maintainers end.
Sound like a plan?
Thanks,
Richard
7:20 p.m.
On Sat, Nov 19, 2011 at 11:45 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
I'm working on getting MythTV packages built for EL6 and wanted
to
share my plan in case someone has a better idea.
I tried this during the summer, and while I was able to branch and
push several deps in EPEL, I didn't get it all the way to completion:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-July/00992...
All the same, I'm interested in the effort and I'd like to assist.
-> ffmpeg
-> libvpx
-> x264
The ffmpeg / libvpx thing is going to be tricky, because several
rpmfusion devs want to stabilize on a modern ffmpeg for EL 6, but this
requires a newer libvpx. See:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1250
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-October/01...
I haven't tried lobbying the RH maintainer (I guess it would be Spot?)
for a newer libvpx. And even if it got incremented, I imagine it would
be in RHEL 6.3, which will take a while for that to trickle down
through to CentOS :)
The good news is that all the packages rebuilt without modification
so
there should be minimal work on the maintainers end.
I had to patch MythTV's weather plugin because RHEL 6 has a
perl-Date-Manip that is too old. Upstream didn't take the patch
(http://code.mythtv.org/trac/ticket/9921) but there's nothing keeping
us from using the patch in RPM Fusion.
- Ken
2:34 a.m.
On Sat, Nov 19, 2011 at 1:20 PM, Ken Dreyer <ktdreyer(a)ktdreyer.com> wrote:
On Sat, Nov 19, 2011 at 11:45 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> I'm working on getting MythTV packages built for EL6 and wanted to
> share my plan in case someone has a better idea.
I tried this during the summer, and while I was able to branch and
push several deps in EPEL, I didn't get it all the way to completion:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-July/00992...
All the same, I'm interested in the effort and I'd like to assist.
> -> ffmpeg
> -> libvpx
> -> x264
The ffmpeg / libvpx thing is going to be tricky, because several
rpmfusion devs want to stabilize on a modern ffmpeg for EL 6, but this
requires a newer libvpx. See:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1250
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-October/01...
Strange... When I tried to build I'm pretty sure I got an error saying
libvpx was unavailable, not too old. I pulled all my SRPMS from
current F15 and they all built fine.
I haven't tried lobbying the RH maintainer (I guess it would be
Spot?)
for a newer libvpx. And even if it got incremented, I imagine it would
be in RHEL 6.3, which will take a while for that to trickle down
through to CentOS :)
I didn't look into any of the SRPMS, just tried to rebuild them. I
wonder if it would be simpler to disable vpx in ffmpeg? Is there
anything in Myth that requires it? Or do we just loose a playback
codec?
> The good news is that all the packages rebuilt without
modification so
> there should be minimal work on the maintainers end.
I had to patch MythTV's weather plugin because RHEL 6 has a
perl-Date-Manip that is too old. Upstream didn't take the patch
(http://code.mythtv.org/trac/ticket/9921) but there's nothing keeping
us from using the patch in RPM Fusion.
I haven't tried installing it yet as for the first step I was only
trying to get it to build. I don't have a CentOS 6 box handy so I
guess I'll have to install one in VirtualBox.
Richard
3:17 a.m.
Richard Shaw wrote:
I didn't look into any of the SRPMS, just tried to rebuild them.
I
wonder if it would be simpler to disable vpx in ffmpeg? Is there
anything in Myth that requires it? Or do we just loose a playback
codec?
Actually, you'd just lose an encoder. Current FFmpeg has a builtin decoder
for VP8.
Kevin Kofler
7:53 p.m.
2011/11/19 Richard Shaw <hobbes1069(a)gmail.com>:
I'm working on getting MythTV packages built for EL6 and wanted
to
share my plan in case someone has a better idea.
I did finally get a local build but I had to rebuild several packages
that are not available in EPEL yet:
Missing dependencies for MythTV on EPEL 6.
---
lirc
It should be possible to maintainer lirc for EL-6, jarod have
answeared a bug on this.
libfame
Someone to take over maintainance in EL branch for RPM
Fusion ?
mjpegtools
-> libquicktime
I will care once the dependencies are solved.
-> ffmpeg
-> libvpx
-> x264
ffmpeg/x264 still need to choose which version to
start from.
I would be for using ffmpeg-compat as 0.6 and ffmpeg as 0.8.
Of course using ffmpeg-compat will be for legacy purpose and will not
track security or feature fixes.
choosing 0.7 as legacy version doesn't make sense as it's basically
the same version as 0.8 with the previous ABI.
Unfortunately the two ABI aren't currently parallele installable.
(Requested to upstream via Rathann).
-> mplayer/mencoder (runtime)
-> em8300
^ probably to disable until we get kmod support or that
the support
got backported (recently upstreamed in kernel IIRC).
-> libass
^ Should be in epel-testing.
-> twolame
-> y4mscaler (runtime)
^ need a maintainer in the EL branch for RPM
Fusion (and Fedora ?)
-> mjpegtools-devel
-> mjpegtools-libs
^ need a maitainer in the EL branch
for RPM Fusion.
transcode
I will care once we have solved the dependencies.
-> pvm
Request in EPEL ?
-> libmpeg3
I will care
-> v4l (too old)
v4l1 can be disabled in transcode
with recent version (some of my
patches were accepted upstream).
libcrystalhd (disabled due to below)
-> gstreamer
-> gobject-introspection (needs glib2 > 2.24, EL6 has 2.22.5)
-> cairo
My plan is to submit bugs to the appropriate bugzilla's for each
package and ask the current maintainer to create an EL6 branch and
offer to co-maintain it. I will also offer to maintain the EL6 branch
if necessary but I'd rather have the original maintainer keep things
up to date.
Note, that we still have a bug that build EL-6 for i386 instead of i686:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2044
So I will need to rebuilt most binary packages once the problem is solved.
Nicolas (kwizart)
8 p.m.
On Sun, Nov 20, 2011 at 1:53 PM, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
Note, that we still have a bug that build EL-6 for i386 instead of
i686:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2044
So I will need to rebuilt most binary packages once the problem is solved.
A bug on what? Apparently I'm not authorized to see that bug.
Thanks,
Richard
8:01 p.m.
Update!
I've submitted RFE bugs on the lower level requirements:
Missing dependencies for MythTV on EPEL 6.
---
lirc [1]
libfame [2]
mjpegtools
-> libquicktime
-> ffmpeg
-> libvpx (disabled until newer version available[3])
-> x264 [4]
-> mplayer/mencoder (Requires)
-> em8300 (Do we really need this?)
-> libass [5]
-> twolame [6]
-> y4mscaler (Requires)
-> mjpegtools-devel
-> mjpegtools-libs
transcode
-> pvm [7]
-> libmpeg3 [8]
-> v4l (too old) [9]
libcrystalhd (disabled due to below)
-> gstreamer
-> gobject-introspection (needs glib2 > 2.24, EL6 has 2.22.5)
-> cairo
[1] https://bugzilla.redhat.com/show_bug.cgi?id=755333
[2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2042
[3] https://bugzilla.redhat.com/show_bug.cgi?id=755305
[4] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2043
[5] https://bugzilla.redhat.com/show_bug.cgi?id=755339
[6] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2045
[7] https://bugzilla.redhat.com/show_bug.cgi?id=755342
[8] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2046
[9] https://bugzilla.redhat.com/show_bug.cgi?id=755343
Thanks,
Richard
3:24 p.m.
On Sun, Nov 20, 2011 at 1:53 PM, Nicolas Chauvet <kwizart(a)gmail.com> wrote:
2011/11/19 Richard Shaw <hobbes1069(a)gmail.com>:
> libfame
Someone to take over maintainance in EL branch for RPM Fusion ?
Do I need to go ahead and take this one then?
> mjpegtools
> -> libquicktime
I will care once the dependencies are solved.
> -> ffmpeg
> -> libvpx
> -> x264
ffmpeg/x264 still need to choose which version to start from.
I would be for using ffmpeg-compat as 0.6 and ffmpeg as 0.8.
Of course using ffmpeg-compat will be for legacy purpose and will not
track security or feature fixes.
choosing 0.7 as legacy version doesn't make sense as it's basically
the same version as 0.8 with the previous ABI.
Unfortunately the two ABI aren't currently parallele installable.
(Requested to upstream via Rathann).
Let me know if there's anything I can do to help.
> -> mplayer/mencoder (runtime)
> -> em8300
^ probably to disable until we get kmod support or that the support
got backported (recently upstreamed in kernel IIRC).
Do we know how prevalent these devices are? I'm not sure if there's a
need to support them at all, at least for Myth.
> -> libass
^ Should be in epel-testing.
Thanks.
> -> y4mscaler (runtime)
^ need a maintainer in the EL branch for RPM Fusion (and Fedora ?)
Can this exist in Fedora?
> -> mjpegtools-devel
> -> mjpegtools-libs
^ need a maitainer in the EL branch for RPM Fusion.
I'll take it if the current maintainer doesn't want to.
> -> pvm
Request in EPEL ?
Submitted.
> -> libmpeg3
I will care
> -> v4l (too old)
v4l1 can be disabled in transcode with recent version (some of my
patches were accepted upstream).
Sounds good.
Thanks,
Richard
4785
days inactive
4787
days old
rpmfusion-developers@lists.rpmfusion.org
7 comments
4 participants
participants (4)
-
Ken Dreyer -
Kevin Kofler -
Nicolas Chauvet -
Richard Shaw