9:26 p.m.
Instead of bouncing back and forth between bugs, I was hoping that
things could be hashed out here instead.
Here's my current status, please let me know if there's something I
need to update:
Missing dependencies for MythTV on EPEL 6.
---
lirc [1] (built, pending for testing)
libfame [2] (built)
mjpegtools [13] (which version to build?)
-> libquicktime [12] (closed as invalid)
-> ffmpeg [11] (closed as invalid)
-> libvpx (dead, upstream will not update) [3]
-> x264 [4]
-> mplayer/mencoder (Requires)
-> em8300 (Do we really need this?)
-> libass (in epel-testing)
-> twolame [6] (built but not available?)
-> y4mscaler (Requires) [10]
-> mjpegtools-devel
-> mjpegtools-libs
transcode
-> pvm [7]
-> libmpeg3 [8]
-> v4l (too old) [9]
-> mjpegtools-devel (et al.)
-> libquicktime-devel (et al.)
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
[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
[10] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2050
[11] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2129
[12] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2130
[13] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1846
9:45 a.m.
On 05/01/12 08:26, Richard Shaw wrote:
Here's my current status, please let me know if there's
something I
need to update:
Missing dependencies for MythTV on EPEL 6.
---
lirc [1] (built, pending for testing)
libfame [2] (built)
mjpegtools [13] (which version to build?)
-> libquicktime [12] (closed as invalid)
-> ffmpeg [11] (closed as invalid)
-> libvpx (dead, upstream will not update) [3]
-> x264 [4]
-> mplayer/mencoder (Requires)
-> em8300 (Do we really need this?)
-> libass (in epel-testing)
-> twolame [6] (built but not available?)
-> y4mscaler (Requires) [10]
-> mjpegtools-devel
-> mjpegtools-libs
transcode
-> pvm [7]
-> libmpeg3 [8]
-> v4l (too old) [9]
-> mjpegtools-devel (et al.)
-> libquicktime-devel (et al.)
libcrystalhd (disabled due to below)
-> gstreamer
-> gobject-introspection (needs glib2> 2.24, EL6 has 2.22.5)
-> cairo
Are some packages redhat ones ?
some fedora-epel ?
and eg ffmpeg etc are RPM Fusion
If redhat aren't willing to update, you might be screwed. EPEL still
might take convincing and reject (for those, would we use an internal
lib instead to work around the problem ?, or disable that functionality
in the packages, with a notes to say why ?).
Hopefully not to much problems within RPM Fusions EL6 packages and
people wanting to stick with a tried and true version ?
2:49 p.m.
On Thu, Jan 5, 2012 at 3:45 AM, David Timms <dtimms(a)iinet.net.au> wrote:
Are some packages redhat ones ?
some fedora-epel ?
and eg ffmpeg etc are RPM Fusion
Well, we don't actually need ffmpeg since MythTV (for better or worse)
bundles it's own, but it is currently a requirement of some of the
other packages that MythTV is dependent on, so we'll have to work
around those.
If redhat aren't willing to update, you might be screwed. EPEL
still might
take convincing and reject (for those, would we use an internal lib instead
to work around the problem ?, or disable that functionality in the packages,
with a notes to say why ?).
Yes, we are running into a bit of that and since the policy of Fedora
and RPM Fusion to not provide packages that are available in RHEL we
could very well be screwed, but I'm going to keep trying. Since ATRPMS
provides an EL version of Myth I'm assuming they do not share that
policy.
I think the biggest roadblock at this point is "v4l" where the RHEL
version is quite old, however, Hans[1] is trying to appeal to the RHEL
QA gods to see if he can convince them.
Hopefully not to much problems within RPM Fusions EL6 packages and
people
wanting to stick with a tried and true version ?
I think we'll get there eventually but I have no idea how long it will
take. I was hoping to convert my F14 MythTV box to CentOS 6 but I may
have to do one more Fedora upgrade before that's an option.
Richard
[1] https://bugzilla.redhat.com/show_bug.cgi?id=755343#c6
3:02 p.m.
On Jan 5, 2012, at 9:49 AM, Richard Shaw wrote:
On Thu, Jan 5, 2012 at 3:45 AM, David Timms
<dtimms(a)iinet.net.au> wrote:
> Are some packages redhat ones ?
> some fedora-epel ?
> and eg ffmpeg etc are RPM Fusion
Well, we don't actually need ffmpeg since MythTV (for better or worse)
bundles it's own, but it is currently a requirement of some of the
other packages that MythTV is dependent on, so we'll have to work
around those.
Most of those aren't hard deps. Way back when, they were required for non-recordings
video playback, but the internal player can handle all (or at least most) of that now,
so they're really just supplemental bits, for the most part.
> If redhat aren't willing to update, you might be screwed.
EPEL still might
> take convincing and reject (for those, would we use an internal lib instead
> to work around the problem ?, or disable that functionality in the packages,
> with a notes to say why ?).
Yes, we are running into a bit of that and since the policy of Fedora
and RPM Fusion to not provide packages that are available in RHEL we
could very well be screwed, but I'm going to keep trying. Since ATRPMS
provides an EL version of Myth I'm assuming they do not share that
policy.
Another for better or worse case, ATrpms plays by its own rules. It does provide some
newer packages of things already provided by the distro, among other diversions
from both upstream Fedora packaging guidelines and the RPM Fusion ones.
I think the biggest roadblock at this point is "v4l" where
the RHEL
version is quite old, however, Hans[1] is trying to appeal to the RHEL
QA gods to see if he can convince them.
Hm. There's newer v4l-utils in EPEL... But no libv4l. Looks like its been packaged to
have a private libv4l copy or some such thing. Was thinking that could be used, but
maybe not.
-j
3:17 p.m.
On Thu, Jan 5, 2012 at 8:53 AM, Jarod Wilson <jarod(a)wilsonet.com> wrote:
On Jan 4, 2012, at 4:26 PM, Richard Shaw wrote:>>> Instead
of bouncing back and forth between bugs, I was hoping that>> things could be hashed
out here instead.>>>> Here's my current status, please let me know if
there's something I>> need to update:>>>> Missing dependencies for
MythTV on EPEL 6.>> --->> lirc [1] (built, pending for testing)>> Yeah,
the Fedora maintainer has been slacking... ;)
Eh, no biggie, it will not be the last requirement resolved, so it
wasn't the hold-up :)
> transcode>> -> pvm [7]>> ->
libmpeg3 [8]>> -> v4l (too old) [9]>> There's a newer v4l in
epel that is designed to co-exist with the distro-provided> v4l, if I'm thinking
clearly.
Yup, see below :)>>> -> mjpegtools-devel (et al.)>> ->
libquicktime-devel (et al.)>> libcrystalhd (disabled due to below)>>
crystalhd support isn't worth the effort, its fairly useless these
days. I'd mostly only> be worried about vdpau and va-api.
Yup. That's the plan.
On Thu, Jan 5, 2012 at 9:02 AM, Jarod Wilson <jarod(a)wilsonet.com> wrote:
On Jan 5, 2012, at 9:49 AM, Richard Shaw wrote:
> I think the biggest roadblock at this point is "v4l" where the RHEL
> version is quite old, however, Hans[1] is trying to appeal to the RHEL
> QA gods to see if he can convince them.
Hm. There's newer v4l-utils in EPEL... But no libv4l. Looks like its been packaged
to
have a private libv4l copy or some such thing. Was thinking that could be used, but
maybe not.
We may be able to, I just having figured out how to yet. When I try to
use that version the transcode build fails because of missing headers
which the new package does not provide. If someone knows a way around
that then we may be back in business.
Or do we just build transcode without v4l support?
See here for the details:
https://bugzilla.redhat.com/show_bug.cgi?id=755343
Thanks,
Richard
3:24 p.m.
On Thu, Jan 5, 2012 at 8:17 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Or do we just build transcode without v4l support?
See here for the details:
https://bugzilla.redhat.com/show_bug.cgi?id=755343
I was wondering why I didn't see this during my rebuild efforts on
el6. I see I had grabbed 1.1.5-6, which had v4l disabled re:
https://bugzilla.rpmfusion.org/1700
- Ken
3:42 p.m.
On Jan 5, 2012, at 10:17 AM, Richard Shaw wrote:
On Thu, Jan 5, 2012 at 9:02 AM, Jarod Wilson
<jarod(a)wilsonet.com> wrote:
> On Jan 5, 2012, at 9:49 AM, Richard Shaw wrote:
>> I think the biggest roadblock at this point is "v4l" where the RHEL
>> version is quite old, however, Hans[1] is trying to appeal to the RHEL
>> QA gods to see if he can convince them.
>
> Hm. There's newer v4l-utils in EPEL... But no libv4l. Looks like its been
packaged to
> have a private libv4l copy or some such thing. Was thinking that could be used, but
> maybe not.
We may be able to, I just having figured out how to yet. When I try to
use that version the transcode build fails because of missing headers
which the new package does not provide. If someone knows a way around
that then we may be back in business.
Or do we just build transcode without v4l support?
For mythtv, I don't think its critical. The transcode bits are only used optionally,
and
they operate on already-recorded files, not directly on v4l devices. So you could
just build without v4l support and not miss out on much of anything, as far as mythtv
is concerned.
-j
3:59 p.m.
On Thu, Jan 5, 2012 at 9:42 AM, Jarod Wilson <jarod(a)wilsonet.com> wrote:
On Jan 5, 2012, at 10:17 AM, Richard Shaw wrote:
> On Thu, Jan 5, 2012 at 9:02 AM, Jarod Wilson <jarod(a)wilsonet.com> wrote:
>> On Jan 5, 2012, at 9:49 AM, Richard Shaw wrote:
>>> I think the biggest roadblock at this point is "v4l" where the
RHEL
>>> version is quite old, however, Hans[1] is trying to appeal to the RHEL
>>> QA gods to see if he can convince them.
>>
>> Hm. There's newer v4l-utils in EPEL... But no libv4l. Looks like its been
packaged to
>> have a private libv4l copy or some such thing. Was thinking that could be used,
but
>> maybe not.
>
> We may be able to, I just having figured out how to yet. When I try to
> use that version the transcode build fails because of missing headers
> which the new package does not provide. If someone knows a way around
> that then we may be back in business.
>
> Or do we just build transcode without v4l support?
For mythtv, I don't think its critical. The transcode bits are only used optionally,
and
they operate on already-recorded files, not directly on v4l devices. So you could
just build without v4l support and not miss out on much of anything, as far as mythtv
is concerned.
I tried doing a build without it but of course it fails because
libquicktime isn't available and libquicktime wants ffmpeg. I did a
build of libquicktime without ffmpeg but I'm not sure what we loose
with that. I'm thinking transcode without ffmpeg, even if possible,
would be pretty useless. So I guess that's the new roadblock. I know
Nicolas is working on it but his usual terse responses don't allow me
to see the big picture, hopefully he'll expound here.
Richard
2:53 p.m.
On Jan 4, 2012, at 4:26 PM, Richard Shaw wrote:
Instead of bouncing back and forth between bugs, I was hoping that
things could be hashed out here instead.
Here's my current status, please let me know if there's something I
need to update:
Missing dependencies for MythTV on EPEL 6.
---
lirc [1] (built, pending for testing)
Yeah, the Fedora maintainer has been slacking... ;)
transcode
-> pvm [7]
-> libmpeg3 [8]
-> v4l (too old) [9]
There's a newer v4l in epel that is designed to co-exist with the distro-provided
v4l, if I'm thinking clearly.
-> mjpegtools-devel (et al.)
-> libquicktime-devel (et al.)
libcrystalhd (disabled due to below)
crystalhd support isn't worth the effort, its fairly useless these days. I'd
mostly only
be worried about vdpau and va-api.
-j
4505
days inactive
4506
days old
rpmfusion-developers@lists.rpmfusion.org
8 comments
4 participants
participants (4)
-
Agnes Jones -
Jarod Wilson -
Ken Dreyer -
Richard Shaw