MythTV has released version 0.26. Would somebody be kind enough to make an ebuild for this? Reproducible: Always
A 0-day bump request. You're more than welcome to take a gander at this and attach your results to this bug.
Got it to install. Haven't had a chance to test (need to update the whole setup / backup / etc). Used the 0.25.2 ebuild. The ldconfig backport is still required. A patch is needed for external/Makefile on amd64 - libdir is ignored. Patch attached.
Created attachment 325824 [details, diff] patch per my comment.
Created attachment 325826 [details] ebuild for 0.26 Note that this ebuild is really illustrative. It would be cleaner to merge the patches into the backports. I do not know which if any of the backport patches are in 0.26 beyond the two build fixes.
Ok, that build seems to work for me. I can't say it has gotten the most rigorous testing, but I plan to use it for daily use.
Thanks for the work Rich. I can track these down with upstream to get them added to backports and make an ebuild from backports and add that to the tree if you'd like. Otherwise you can add yours to the tree.
Unless you're busy and think it will take weeks/etc probably cleanest for you to just merge these in so that it stays consistent. Otherwise we have backports split between our web spaces. That said, long-term I should be able to increase my activity level - I'm finally running pure Gentoo on my Myth setup and upgrades are shockingly easy now. Turns out my problems were with the embedded ffmpeg code and 0.25.2+ must have finally backported something that worked (otherwise my next step was to try to update that code myself). I assume they must have done something to ffmpeg that keeps them from just using external libs?
Mythtv's internal copy ffmpeg is called by calling mythffmpeg instead of ffmpeg. They use it so that they do not need to troubleshoot every random breakage between the different mythtv and ffmpeg revision mash-ups and when the mythtv devs are troubleshooting a user's problem there is a single revision of ffmpeg being considered. Your scripts do not need to prefer mythffmpeg over ffmpeg, but you have to reproduce the problem with mythffmpeg before the mythtv devs will look into a problem related to ffmpeg. To the best of my knowledge it is a vanilla ffmpeg branch, they only regulate the revision. (as in test a new ffmpeg, then if needed rebase mythtv to use it reliably, and push the changes to git) In any case, this is the wrong place to continue this tangent and I apologize for digressing from the topic.
This ebuild fails when gdb is not installed.
There's a missing libx264 dependency. * mythtv-0.26.0.tar.bz2 SHA256 SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking mythtv-0.26.0.tar.bz2 to /var/tmp/portage/media-tv/mythtv-0.26.0/work >>> Source unpacked in /var/tmp/portage/media-tv/mythtv-0.26.0/work >>> Preparing source in /var/tmp/portage/media-tv/mythtv-0.26.0/work/mythtv-0.26.0 ... * Applying patch.txt ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-tv/mythtv-0.26.0/work/mythtv-0.26.0 ... * Running ./configure --prefix=/usr --libdir=/usr/lib64 --libdir-name=lib64 --mandir=/usr/share/man --enable-audio-alsa --disable-audio-jack --disable-audio-pulseoutput --disable-altivec --enable-dvb --disable-firewire --enable-lirc --enable-libxvid --dvb-path=/usr/include --enable-xrandr --enable-xv --enable-x11 --enable-nonfree --disable-libcec --disable-libdns-sd --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-libx264 --enable-libvpx --enable-libfaac --with-bindings=perl,python --python=python2.6 --compile-type=profile --enable-vdpau --disable-joystick-menu --enable-symbol-visibility --enable-pic --cpu=core2 --disable-distcc --disable-ccache ERROR: libx264 version must be >= 0.118. If you think configure made a mistake, make sure that you are using the latest version of MythTV from git. If the latest version fails, report the problem to the mythtv-dev@mythtv.org mailing list or IRC #mythtv on irc.freenode.net Include the log file "config.ep" produced by configure as this will help solving the problem.
Richard's ebuild works for me on x86.
MYthtv 0.26 requires IPv6 to be enabled. Should this be checked?
(In reply to comment #9) > This ebuild fails when gdb is not installed. You'll need to give me full details on that. I can't reproduce this from a clean stage3.
Created attachment 328340 [details] updated ebuild Updated x264 dependency.
Created attachment 329344 [details] mythtv-0.26.0_p20121107.ebuild Updated with backports. Note that I renamed the patch it references as well.
Is there a corresponding ebuild for media-plugins/mythplugins available? I couldn't find a separate bug report for it, and we really need both ebuilds together.
(In reply to comment #17) > Is there a corresponding ebuild for media-plugins/mythplugins available? I > couldn't find a separate bug report for it, and we really need both ebuilds > together. That's the whole reason this isn't in portage. I'm contemplating committing this and masking it though so that those who don't use plugins can still get use out of it. If I get time I might look into the plugins, but feel free to post an updated ebuild.
(In reply to comment #18) > > I'm contemplating committing this and masking it though so that those who > don't use plugins can still get use out of it. If I get time I might look > into the plugins, but feel free to post an updated ebuild. Added to portage, but masked. I'll continue to update it there. Will leave this open until plugins are bumped and all is unmasked.
(In reply to comment #19) > (In reply to comment #18) > > > > I'm contemplating committing this and masking it though so that those who > > don't use plugins can still get use out of it. If I get time I might look > > into the plugins, but feel free to post an updated ebuild. > > Added to portage, but masked. I'll continue to update it there. Will leave > this open until plugins are bumped and all is unmasked. I'll bump the rest and unmask if you'd like when I return from dev away in December.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > > > > I'm contemplating committing this and masking it though so that those who > > > don't use plugins can still get use out of it. If I get time I might look > > > into the plugins, but feel free to post an updated ebuild. > > > > Added to portage, but masked. I'll continue to update it there. Will leave > > this open until plugins are bumped and all is unmasked. > > I'll bump the rest and unmask if you'd like when I return from dev away in > December. By all means - I don't actually use plugins right now, and it hasn't quite made it to the top of my to-do list. So, whoever gets to it first... Rich
The libdir.patch file is missing from portage.
(In reply to comment #22) > The libdir.patch file is missing from portage. Well, at least I masked it, so I can skip the full flogging. Fixed in portage, just wait an hour for mirrors to propagate.
the logrotate script for 0.26.0 needs updating too due to the new mythtv logging server -- see the 0.26 version at: http://www.mythtv.org/wiki/Logrotate_-_all_applications
Wanted to give 0.26 a go, but also needed mythplugins and mythweb for my setup. So after playing around with the existing ebuild I ended up with a set of ebuild that can install and run on my systems. As you may find these script do not use a magical tarball, but simply uses the git repository. One side effect of this are the ~244MB "distfiles" space required vs the ~8.5MB tar.gz version, so it may take a bit of time for the initial fetch, but that's like a 10min recording. Up side are that it is rather easy to update the ebuild when a new commit are made on the fixes/0.26 branch - copy ebuild and update the git hash. Happy new year everyone
Created attachment 333772 [details] mythtv-0.26.0_p20121228.ebuild
Comment on attachment 333772 [details] mythtv-0.26.0_p20121228.ebuild Git based mythtv ebuild
Created attachment 333774 [details] mythplugins-0.26.0_p20121228.ebuild Git based mythplugins ebuild
Created attachment 333778 [details] mythweb-0.26.0_p20121228.ebuild Git based mythweb ebuild
(In reply to comment #25) > Wanted to give 0.26 a go, but also needed mythplugins and mythweb for my > setup. > > So after playing around with the existing ebuild I ended up with a set of > ebuild that can install and run on my systems. As you may find these script > do not use a magical tarball, but simply uses the git repository. One side > effect of this are the ~244MB "distfiles" space required vs the ~8.5MB > tar.gz version, so it may take a bit of time for the initial fetch, but > that's like a 10min recording. Up side are that it is rather easy to update > the ebuild when a new commit are made on the fixes/0.26 branch - copy ebuild > and update the git hash. I will give it a try, thanks for the ebuilds. Is upgrading from the v0.25 ebuild in portage easy going? > Happy new year everyone Same to you, thanks! Stefan
(In reply to comment #27) > Comment on attachment 333772 [details] > mythtv-0.26.0_p20121228.ebuild > > Git based mythtv ebuild Anyone is of course welcome to use these, but scm-based ebuilds can never be unmasked in portage. FYI - latest fixes are now in portage. I'll see if I can look at the plugins - I don't run them so I'll probably leave them masked for a bit for testing, but once everything is in place we can probably unmask 0.26.
Created attachment 333900 [details] logrotate script for 0.26
Thanks for these!! I will also try them out and comment back (I use mythtv and mythweb on my funtoo myth master backend, mythbuntu on all my frontends and slave backends). I changed my copy of the p20121228 mythtv ebuild slightly to use the logrotate config attached here.
(In reply to comment #33) > Thanks for these!! I will also try them out and comment back (I use mythtv > and mythweb on my funtoo myth master backend, mythbuntu on all my frontends > and slave backends). I changed my copy of the p20121228 mythtv ebuild > slightly to use the logrotate config attached here. Yup, I'm testing out the new logrotate - I plan to fit it in to the next release. Hopefully I can mess with the plugins as well by then.
Ok, mythplugins is in the tree. I'm still hitting my head against a wall with mythweb. Does it actually work out-of-the-box for anybody? It seems like the install requires a LOT of tweaking, and that may apply to 0.25 as well. If so, I'm not sure it makes much sense to have this as an ebuild unless it can be cleaned up so that it "just works." Anybody can extract a tarball into htdocs and spend two hours hacking at it.... If somebody has tips for getting mythweb working I'm all for unmasking them all together. If not this should be a working 0.26 set, including all patches to-date.
(In reply to comment #35) > Ok, mythplugins is in the tree. > > I'm still hitting my head against a wall with mythweb. Does it actually > work out-of-the-box for anybody? It seems like the install requires a LOT > of tweaking, and that may apply to 0.25 as well. If so, I'm not sure it > makes much sense to have this as an ebuild unless it can be cleaned up so > that it "just works." Anybody can extract a tarball into htdocs and spend > two hours hacking at it.... > > If somebody has tips for getting mythweb working I'm all for unmasking them > all together. If not this should be a working 0.26 set, including all > patches to-date. With 0.25 stuff I just emerge it and use webapp-config to install it to my htdocs then all I need to do is edit the config file which is CONFIG_PROTECT. Last step is to include the Apache or Lighty config file it ships with into my web server.
I can confirm that MythWeb 0.24 and 0.25 worked fine for me.
I'm getting a ton of php errors - often around translations, and sometimes around timezone settings (ie none defined explicitly). I've tried installing it under my main host and under a virtual host. I'll keep messing with it. In the meantime feel free to test out mythplugins. I was getting some issues with mythweather but that could be from configuration cruft, and it always seemed like mythweather never quite worked right in the past. Once I get mythweb working I might post on the blog to get more attention for testers, but if things seem quiet for a few days it can be unmasked, and we'll be up-to-date again. Now if I can figure out why mythtranscode occasionally drops the video bitrate to a few hundred kilobits for an entire program I'll be happy, but I'm sure that is an upstream issue...
Ok, oddly enough I fixed my errors by turning on error reporting. Yes, it makes no sense. All ears if anybody knows why (just email me off-bug about that). So, mythweb is now in portage. Please test away. If all is well for a few days I'll remove the masks.
Thanks all for your contributions! 0.26 is unmasked. I plan to commit patchsets from time to time...
mythplugins-0.26.0_p20130121 fails to build while applying the 0012-Updated-Italian-MythMusic-translation.patch. Workaround: Deleting the patch file and issuing ebuild directly builds without errors. # emerge -pqv =media-plugins/mythplugins-0.26.0_p20130121 [ebuild N ] media-plugins/mythplugins-0.26.0_p20130121 USE="cdda exif mythbrowser mythgallery mythgame mythmusic mythnetvision mythweather -cdr -fftw -mytharchive -mythnews -raw"
Created attachment 337246 [details] emerge --info for the 0012-Updated-Italian-MythMusic-translation.patch problem
Created attachment 337248 [details] build log for the 0012-Updated-Italian-MythMusic-translation.patch problem
Created attachment 337250 [details] patch output for the 0012-Updated-Italian-MythMusic-translation.patch problem
(In reply to comment #41) > mythplugins-0.26.0_p20130121 fails to build while applying the > 0012-Updated-Italian-MythMusic-translation.patch. > Workaround: Deleting the patch file and issuing ebuild directly builds > without errors. > > # emerge -pqv =media-plugins/mythplugins-0.26.0_p20130121 > [ebuild N ] media-plugins/mythplugins-0.26.0_p20130121 USE="cdda exif > mythbrowser mythgallery mythgame mythmusic mythnetvision mythweather -cdr > -fftw -mytharchive -mythnews -raw" Go ahead and log a bug for this. I'm not quite sure what is going on there. Works for me, but I don't have much experience with binary patches so maybe there is some kind of odd behavior going on. The file obviously exists.
(In reply to comment #45) > (In reply to comment #41) > > mythplugins-0.26.0_p20130121 fails to build while applying the > > 0012-Updated-Italian-MythMusic-translation.patch. > > Workaround: Deleting the patch file and issuing ebuild directly builds > > without errors. > > > > # emerge -pqv =media-plugins/mythplugins-0.26.0_p20130121 > > [ebuild N ] media-plugins/mythplugins-0.26.0_p20130121 USE="cdda exif > > mythbrowser mythgallery mythgame mythmusic mythnetvision mythweather -cdr > > -fftw -mytharchive -mythnews -raw" > > Go ahead and log a bug for this. I'm not quite sure what is going on there. > Works for me, but I don't have much experience with binary patches so maybe > there is some kind of odd behavior going on. The file obviously exists. Ok, found the issue buried in your log, it appears that your patch does not support git binary diffs. I couldn't find much documentation on this, however. Do you have git installed? If not try installing that and see if it works, but let me know so that I can add that as a build dependency. Or I could just drop the translation patch - I had to drop others as they mix plugins vs base files and they don't apply cleanly to either as a result.
The "git --diff" format was added to patch in patch-2.7: https://lwn.net/Articles/515796/ It actually says that "Binary diffs are not supported yet; patch will complain and skip them." So... this being Gentoo, shouldn't the binary .qm files be generated during build-time? :) The .qm files can be built from .ts using "lrelease".
(In reply to comment #47) > The "git --diff" format was added to patch in patch-2.7: > https://lwn.net/Articles/515796/ > > It actually says that "Binary diffs are not supported yet; patch will > complain and skip them." So... this being Gentoo, shouldn't the binary .qm > files be generated during build-time? :) The .qm files can be built from .ts > using "lrelease". I'm just bundling the output of git --format-patch from upstream - they apparently bundle the qm files, and they're using binary patches for both anyway. Perhaps my version of patch is just silently failing. I'll go ahead and drop the language patches for now.
Just to follow-up on https://bugs.gentoo.org/show_bug.cgi?id=437140#c46 [ebuild R ] dev-vcs/git-1.8.1.2 USE="blksha1 curl gpg iconv nls pcre perl python threads webdav -cgi -cvs -doc -emacs -gnome-keyring -gtk -highlight (-ppcsha1) -subversion {-test} -tk -xinetd" [ebuild R ] sys-devel/patch-2.7.1-r1 USE="-static {-test} -xattr" [ebuild R ] sys-apps/diffutils-3.2 USE="nls -static" I tried to apply the patch with 'git apply' instead of 'patch', obviously it works: # pwd /var/tmp/portage/media-plugins/mythplugins-0.26.0_p20130121/work/mythplugins-0.26.0 # git apply -p 2 patches/0012-Updated-Italian-MythMusic-translation.patch patches/0012-Updated-Italian-MythMusic-translation.patch:1631: trailing whitespace. <translation>Definisce la posizione/nome delle nuove canzoni. Elementi validi sono: warning: 1 line adds whitespace errors.
I pulled the language patch from the tarball and updated the manifest. Anybody who got the build to work doesn't need the change so no revbump. Those with issues can just do another sync and they'll get the new patch set. I'll keep this in mind in the future when creating patches.
Any chance of another patchset sync to capture the Live TV and in-progress recording of analogue channels bug(s)? This appears (to me) to be the only show stopper from mythtv-0.26.0_p20130121.ebuild Thanks
(In reply to comment #51) > Any chance of another patchset sync to capture the Live TV and in-progress > recording of analogue channels bug(s)? This appears (to me) to be the only > show stopper from mythtv-0.26.0_p20130121.ebuild > Sure - I'll work on that. Just a general request - no more comments on this bug. 0.26 is in the tree and I'd like to put this one to rest...
