MythTV 0.24 was releases with many interesting features! Is someone already working on an ebuild? Reproducible: Always Steps to Reproduce: 1. open browser 2. enter www.mythtv.org 3. see release announcement Actual Results: No ebuild for 0.24 in portage Expected Results: An ebuild for mythtv 0.24
There are also bumps for MythWeb, and the plugins, of course.
Created attachment 254263 [details] 0.24 ebuild I've been using this for truck and now with the 0.24 release. The crystalhd USE flag depends on #344877, but if that doesn't get accepted then it can be cut out, obviously.
the ebuild complains for a missing gentoo-myth-config-fix.diff file
Created attachment 254497 [details] missing patch This is from MarcT's live ebuild, I had forgotten about it.
(In reply to comment #3) > the ebuild complains for a missing gentoo-myth-config-fix.diff file > The only other "missing" patch is mythtv-0.21-ldconfig-sandbox-fix.patch. I had renamed the original mythtv-0.21-ldconfig-sanxbox-fix.patch thinking the original author just made a typo.
(In reply to comment #5) > (In reply to comment #3) > > the ebuild complains for a missing gentoo-myth-config-fix.diff file > > > > The only other "missing" patch is mythtv-0.21-ldconfig-sandbox-fix.patch. I > had renamed the original mythtv-0.21-ldconfig-sanxbox-fix.patch thinking the > original author just made a typo. Just as a feedback: Successfully merged your ebuild and also a newer revision by cp-ing your file to mythtv-0.24_p27300.ebuild Thanks, Stefan
Created attachment 255539 [details] Slightly updated ebuild, corrects file permissions This fixes the permissions for the extra scripts. I had tried to use multiple instances of fperms, but found Kormoc's method simpler.
I have filed bugs against the plug-ins that I had to modify from the existing 0.23.1 ebuilds to install. Everything else appears to be a simple copy/rename. The plug-ins that I had to modify to install are: mythgallery #346923 mythnetvision #346913 mythvideo #346915
Created attachment 255557 [details] correct version of the updated ebuild
BTW, looks like faad is not an option in 0.24 # emerge -a --resume These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-tv/mythtv-0.24_p27364 [0.23.1_p27077] USE="alsa css dvb faad fftw mmx perl python tiff vdpau (-altivec) -autostart -bluray% -crystalhd% -dbus -debug -directv -ieee1394 -jack -lcd -lirc -pulseaudio -xvmc" VIDEO_CARDS="nvidia -via" 0 kB [0=>1] Total: 1 package (1 upgrade), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /usr/local/portage Would you like to resume merging these packages? [Yes/No] *** Resuming merge... >>> Verifying ebuild manifests >>> Emerging (1 of 1) media-tv/mythtv-0.24_p27364 from unknown repo * mythtv-0.24_p27364.zip RMD160 SHA1 SHA256 size ;-) ... [ ok ] * Package: media-tv/mythtv-0.24_p27364 * USE: alsa css dvb elibc_glibc faad fftw kernel_linux mmx perl python tiff userland_GNU vdpau video_cards_nvidia x86 * This ebuild now uses a heavily stripped down version of your CFLAGS >>> Unpacking source... >>> Unpacking mythtv-0.24_p27364.zip to /var/tmp/portage/media-tv/mythtv-0.24_p27364/work >>> Source unpacked in /var/tmp/portage/media-tv/mythtv-0.24_p27364/work >>> Preparing source in /var/tmp/portage/media-tv/mythtv-0.24_p27364/work/branches/release-0-24-fixes/mythtv ... * Applying gentoo-myth-config-fix.diff ... [ ok ] * Applying mythtv-0.21-ldconfig-sandbox-fix.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-tv/mythtv-0.24_p27364/work/branches/release-0-24-fixes/mythtv ... * Running ./configure --prefix=/usr * --mandir=/usr/share/man * --libdir-name=lib --disable-altivec --enable-libfaad --enable-libfftw3 --disable-audio-jack --enable-vdpau --disable-xvmc-vld * --enable-dvb * --disable-firewire * --disable-lirc * --disable-directfb * --dvb-path=/usr/include * --enable-opengl-vsync * --enable-xrandr * --enable-xv * --enable-x11 --enable-mmx --with-bindings=perl,python --compile-type=profile --cpu=k8 --disable-distcc --disable-ccache Unknown option "--enable-libfaad". See ./configure --help for available options. * ERROR: media-tv/mythtv-0.24_p27364 failed: * configure died * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 5515: Called die * The specific snippet of code: * sh ./configure ${myconf} || die "configure died" * * If you need support, post the output of 'emerge --info =media-tv/mythtv-0.24_p27364', * the complete build log and the output of 'emerge -pqv =media-tv/mythtv-0.24_p27364'. * This ebuild is from an overlay: '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/media-tv/mythtv-0.24_p27364/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-tv/mythtv-0.24_p27364/temp/environment'. * S: '/var/tmp/portage/media-tv/mythtv-0.24_p27364/work/branches/release-0-24-fixes/mythtv'
Created attachment 255783 [details] Updates dependancies As the previous comment noted, faad isn't an option anymore. I noticed that earlier this morning and was hoping to sneak in an update before anyone noticed. :) libfaad - support removed, replaced with native ffmpeg capabilities This is my final tweak to this ebuild. Dependencies updated, configure options appear to be correct.
I havent installed mythtv 0.24 yet, but after upgrading to python 2.7 I had to emerge pyxml in order to get jamu.py to work with mythtv/mythvideo 0.23, should this be added as a dependency for 0.24 or is jamu.py no longer used with mythtv/mythvideo? Too lazy to file a bug for 0.23 since I plan on installing 0.24 soon.
(In reply to comment #12) > I havent installed mythtv 0.24 yet, but after upgrading to python 2.7 I had to > emerge pyxml in order to get jamu.py to work with mythtv/mythvideo 0.23, should > this be added as a dependency for 0.24 or is jamu.py no longer used with > mythtv/mythvideo? > > Too lazy to file a bug for 0.23 since I plan on installing 0.24 soon. > jamu is still used, but it gets installed with mythvideo.
I think it's also notable that MythTV is switching to Github: http://www.mythtv.org/news/145 I know they'd like to phase out SVN, but it will be left available (with no new updates) for some time. I don't know if the ebuild's current Trac-based download URLs will continue to work, however, so an ebuild pointing to github instead would be very good for the future, and 0.24 might be a good place to introduce this (seeing as it's not in tree yet).
(In reply to comment #14) > I think it's also notable that MythTV is switching to Github: > http://www.mythtv.org/news/145 > > I know they'd like to phase out SVN, but it will be left available (with no new > updates) for some time. I don't know if the ebuild's current Trac-based > download URLs will continue to work, however, so an ebuild pointing to github > instead would be very good for the future, and 0.24 might be a good place to > introduce this (seeing as it's not in tree yet). > See Bug 347750. MarcT has an overlay on github for live builds and has updated his eclass to support the git change. As I understand it, Gentoo's revision scheme for Myth is going to have to be updated because Git doesn't tag revisions like SVN does. There were a few ideas on the mailing list to change this to a date-based ebuild vs revision. I trust our devs to come up with a brilliant method just like what was implemented for SVN. :)
Latest ebuild appears to have an invalid dependency: dbus? ( >=x11-libs/qt-dbus-4.5:4:4 )
Any chance mythtv 0.24 is gonna show up in portage anytime soon? I only ask cause last time I added 0.23 to my local repo and the next day it was in portage. Go figure :D
Created attachment 257357 [details] Updated for git Slightly updated for git. I have two working possibilities. This version relies on an updated mythtv.eclass. The second omits the need for the primary mythtv.eclass and moves the fetching to the individual ebuilds. I think I prefer the second option. This is a date-based ebuild that relies on the user/dev's preferred commit found on GitHub. An upshot of moving to GitHub is that app-arch/unzip isn't a requirement as they provide either .zip or .tar.gz snapshots. In this ebuild, I rely on MYTHTV_COMMIT to define the desired commit. In this case, it's c548468c45f14df050e75696345966f8375df26c. The provided archive truncates it to c548468. To provide consistency and and ease in tracking different daily snapshots, the archive is saved as mythtv-0.24_pDATE-abbreviatedcommit.tar.gz. Bumping the revision isn't quite as easy as just renaming and doing a manifest, but I think modifying the commit line isn't too much extra.
(In reply to comment #18) > An upshot of moving to GitHub is that app-arch/unzip isn't a > requirement as they provide either .zip or .tar.gz snapshots. > A downside to making an scm-based ebuild is that it can never be unmasked, per Gentoo QA policy - even if it references a fixed commit. The reason for this is that there is no manifest signature of the downloaded code, which makes it impossible to detect changes. Sure, in theory there shouldn't be any, but we don't have control over that. So, this approach would be great for a mythtv-9999 live ebuild for anybody who wants to use the latest and greatest, but it probably won't work out for actual versioned releases.
(In reply to comment #19) > A downside to making an scm-based ebuild is that it can never be unmasked, per > Gentoo QA policy - even if it references a fixed commit. > > The reason for this is that there is no manifest signature of the downloaded > code, which makes it impossible to detect changes. Sure, in theory there > shouldn't be any, but we don't have control over that. This follows the existing template for incrementally updating the Myth ebuilds. Previously, the revision was found within the name itself. Given git's appearance to use alphanumerics instead of subversion's increasing numerical revision, I didn't think it would be possible to keep the same schema in place without violating naming policy. Basically, I don't see this as too much of a change from what we're already using.
(In reply to comment #20) > (In reply to comment #19) > > A downside to making an scm-based ebuild is that it can never be unmasked, per > > Gentoo QA policy - even if it references a fixed commit. > > > > The reason for this is that there is no manifest signature of the downloaded > > code, which makes it impossible to detect changes. Sure, in theory there > > shouldn't be any, but we don't have control over that. > > This follows the existing template for incrementally updating the Myth ebuilds. > Previously, the revision was found within the name itself. Given git's > appearance to use alphanumerics instead of subversion's increasing numerical > revision, I didn't think it would be possible to keep the same schema in place > without violating naming policy. > > Basically, I don't see this as too much of a change from what we're already > using. > As well, the specified commit gets downloaded as a tarball, which is manifestable and perfectly mirrors the old ebuild (which just downloaded a zip of a specific revision from the mythtv trac's view of svn, which is an exact analog to github's view of their git repo). This really is exactly the same method as the old ebuild, and the downloaded file gets hashed into the manifest and properly mirrored, just like before.
Agreed on all points - missed that this is downloading a snapshot and not just fetching the individual files using git/etc. It would work fine.
(In reply to comment #18) > Created an attachment (id=257357) [details] > Updated for git Sorry to say, doesn't even digest here. Stuff like: Connecting to code.mythtv.org|184.106.209.209|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://github.com/MythTV/mythtv/commit/27364/branches/release-0-24-fixes/mythtv [following] --2010-12-19 22:30:17-- http://github.com/MythTV/mythtv/commit/27364/branches/release-0-24-fixes/mythtv Resolving github.com... 207.97.227.239 Connecting to github.com|207.97.227.239|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://github.com/MythTV/mythtv/commit/27364/branches/release-0-24-fixes/mythtv [following] --2010-12-19 22:30:17-- https://github.com/MythTV/mythtv/commit/27364/branches/release-0-24-fixes/mythtv Connecting to github.com|207.97.227.239|:443... connected. ERROR: certificate common name `*.github.com' doesn't match requested host name `github.com'. To connect to github.com insecurely, use `--no-check-certificate'. !!! Couldn't download 'mythtv-0.24_p27364.zip'. Aborting. !!! Fetch failed for mythtv-0.24_p27364.zip, can't update Manifest
(In reply to comment #23) > (In reply to comment #18) > > Created an attachment (id=257357) [details] [details] > > Updated for git > > Sorry to say, doesn't even digest here. > Stuff like: It doesn't look like you were using the mythtv.eclass found in bug 347750 and the mythtv-plugins.eclass found in bug 346927? While it was mentioned in a comment, it's not listed as a dependency and it doesn't look like I can add it as such. Second, it looks like you may have other issues with downloading from an https server. Was wget emerged with the ssl USE enabled? It might be prudent to modify the eclass to point to http instead of https given your example.
(In reply to comment #24) > It doesn't look like you were using the mythtv.eclass found in bug 347750 and > the mythtv-plugins.eclass found in bug 346927? While it was mentioned in a > comment, it's not listed as a dependency and it doesn't look like I can add it > as such. Correct, I don't use them yet. And I have to figure out how to do so ;-) > Second, it looks like you may have other issues with downloading from an https > server. Was wget emerged with the ssl USE enabled? Yes.
(In reply to comment #25) > (In reply to comment #24) > > It doesn't look like you were using the mythtv.eclass found in bug 347750 and > > the mythtv-plugins.eclass found in bug 346927? While it was mentioned in a > > comment, it's not listed as a dependency and it doesn't look like I can add it > > as such. > > Correct, I don't use them yet. And I have to figure out how to do so ;-) That's the easy part. Save both if them to /use/local/portage/eclass. If you run into the same problem, modify the mythtv.eclass and change the src_uri from https to http.
(In reply to comment #26) > That's the easy part. Save both if them to /use/local/portage/eclass. If you > run into the same problem, modify the mythtv.eclass and change the src_uri from > https to http. Did that, doesn't work for me. These SRC_URI-dirs don't exist, I can't browse them with my web-browser .. no such "tarball"-subdirs. Might that be the problem?
(In reply to comment #27) > (In reply to comment #26) > > > That's the easy part. Save both if them to /use/local/portage/eclass. If you > > run into the same problem, modify the mythtv.eclass and change the src_uri from > > https to http. > > Did that, doesn't work for me. These SRC_URI-dirs don't exist, I can't browse > them with my web-browser .. no such "tarball"-subdirs. Might that be the > problem? The problem to responding from a phone is the auto-correct "fixes" things that I don't always notice. That should have read /usr/local/portage/eclass You're not going to be able to browse https://github.com/MythTV/mythtv/tarball/ or https://github.com/MythTV/myththemes/tarball/. Try hitting https://github.com/MythTV/mythtv/tarball/3cf32e89b6cad9f915bda1820ecc0b94fd6f0cdb . This is the newest as of an hour ago. This might be better discussed on the forums as to not spam the buglist.
(In reply to comment #28) > The problem to responding from a phone is the auto-correct "fixes" things that > I don't always notice. That should have read /usr/local/portage/eclass Sure, I read it this way anyway (didn't even notice the "use" ..) > You're not going to be able to browse https://github.com/MythTV/mythtv/tarball/ > or https://github.com/MythTV/myththemes/tarball/. > > Try hitting > https://github.com/MythTV/mythtv/tarball/3cf32e89b6cad9f915bda1820ecc0b94fd6f0cdb > . This is the newest as of an hour ago. > > This might be better discussed on the forums as to not spam the buglist. ok ...
Created attachment 257727 [details] Fixed version description Fixed version description. This depends on an updated eclass; bug 347750 has some examples. Everything else from comment #18 comment #4 and comment #5 still applies. This now outputs something along the lines of: mythfrontend --version Please attach all output as a file in bug reports. MythTV Version : 3cf32e8-dirty MythTV Branch : fixes/0.24 Network Protocol : 63 Library API : 0.24.20101129-1 QT Version : 4.7.1 Options compiled in: <stuff>
(In reply to comment #30) > Created an attachment (id=257727) [details] Aside from the download-issues we discussed this new ebuild built fine here. Thanks.
Trying to build mythtv with perl support using mythtv-0.24_p20101220.ebuild. Looks like USE="perl" should depend on dev-perl/libwww-perl: * --enable-firewire * --disable-lirc * --disable-directfb * --dvb-path=/usr/include * --enable-opengl-vsync * --enable-xrandr * --enable-xv * --enable-x11 --enable-mmx --with-bindings=perl,python --compile-type=profile --cpu=core2 --disable-distcc --disable-ccache WARNING: disabling Perl bindings; missing HTTP::Request WARNING: disabling Perl bindings; missing LWP::UserAgent
Created attachment 258147 [details] updated dependencies (In reply to comment #32) > Trying to build mythtv with perl support using mythtv-0.24_p20101220.ebuild. > Looks like USE="perl" should depend on dev-perl/libwww-perl: D'oh! I missed this. I usually install genlop as on of my first utilities in my chroot, which pulls libwww-perl and dev-perl/DateManip. Added both as dependencies. Thanks for pointing that out. In changing my chroot's build order, I noticed a warning stating "yasm not found, performance will suffer", so I've added yasm as a dependency. I removed a lingering dependency on app-arch/unzip and modified (again) the version descriptor. Instead of ${commit}-dirty, it shows ${commit}-gentoo. I felt it was more appropriate. For anyone interested in SSA/ASS subtitle support, there is a USE flag for that. The patches can be found on the MythTV ticket #9294 as well as http://www.gossamer-threads.com/lists/mythtv/dev/460711. It appears to work for me, so I've left this in as it might benefit others.
Forgive me if I am not fully up to speed with this bump request but I have found this link on github... https://github.com/MythTV/packaging/tree/master/Gentoo Is anyone else aware of this overlay? Should we be using this or the ebuild reference in this bug??
The ebuild in this bug doesn't manifest due to the wget not accepting the *.github.com cert for github.com The git overlay you found doesn't contain myththemes-0.24 as far as I can see?
(In reply to comment #35) > The ebuild in this bug doesn't manifest due to the wget not accepting the > *.github.com cert for github.com > > The git overlay you found doesn't contain myththemes-0.24 as far as I can see? > The cert error is on your side somewhere; it works fine for me. You can copy/paste the url in a browser and save the resulting file in distfiles and manifest from there. 0.24 appears to have basic support for downloading themes within the UI. I believe this will be firmed up in the 0.25 release with some more backend changes. There is a thread on the user list describing it far better. This could explain Kormoc's eclass. Either this, Kormoc's or MarcT's ebuild should work. I like this one though. :)
(In reply to comment #35) > The ebuild in this bug doesn't manifest due to the wget not accepting the > *.github.com cert for github.com (In reply to comment #23) > Sorry to say, doesn't even digest here. You will need to emerge =net-misc/wget-1.12-r3. Bug 344939 corrected this issue on 11/26. With the new wget built, you'll be able to manifest my ebuild above. :)
Any word on when we can get 0.24 in the tree?
(In reply to comment #37) > > You will need to emerge =net-misc/wget-1.12-r3. Bug 344939 corrected this > issue on 11/26. With the new wget built, you'll be able to manifest my ebuild > above. :) Great - thanks for the tip. The digest process attempts to get http://svn.mythtv.org/trac/changeset/20101220/branches/release-0-24-fixes/mythtv?old_path=%2F&format=zip Which ultimately 301s to https://github.com/MythTV/mythtv/commit/20101220/branches/release-0-24-fixes/mythtv Which returns a 404. It is their own redirect, so perhaps they have changed the way they are addressing the commits?
(In reply to comment #39) > (In reply to comment #37) > > > > You will need to emerge =net-misc/wget-1.12-r3. Bug 344939 corrected this > > issue on 11/26. With the new wget built, you'll be able to manifest my ebuild > > above. :) > > Great - thanks for the tip. The digest process attempts to get > http://svn.mythtv.org/trac/changeset/20101220/branches/release-0-24-fixes/mythtv?old_path=%2F&format=zip > > Which ultimately 301s to > https://github.com/MythTV/mythtv/commit/20101220/branches/release-0-24-fixes/mythtv > > Which returns a 404. It is their own redirect, so perhaps they have changed > the way they are addressing the commits? > They switched to Github a bit over a month ago. You need to be using an updated mythtv.eclass. You can find a working ebuild at bug 347750. As mentioned earlier in this bug, there is now an ebuild and eclass that can be found in the official MythTV repository as well.
MythTV has support for crystalhd cards now. There is an ebuild for the crystalhd libraries and kernel module here: http://bugs.gentoo.org/show_bug.cgi?id=344877 Maybe we should have a "crystalhd" use flag (xbmc could use this too) and depend on the ebuild if it is set.
(In reply to comment #41) > MythTV has support for crystalhd cards now. There is an ebuild for the > crystalhd libraries and kernel module here: > > http://bugs.gentoo.org/show_bug.cgi?id=344877 > > Maybe we should have a "crystalhd" use flag (xbmc could use this too) and > depend on the ebuild if it is set. The USE flag is already in the above ebuilds. :)
(In reply to comment #42) > (In reply to comment #41) > > MythTV has support for crystalhd cards now. There is an ebuild for the > > crystalhd libraries and kernel module here: > > > > http://bugs.gentoo.org/show_bug.cgi?id=344877 > > > > Maybe we should have a "crystalhd" use flag (xbmc could use this too) and > > depend on the ebuild if it is set. > > The USE flag is already in the above ebuilds. :) > OK. Did a quick grep but mistyped crystalhd. Sorry.
(In reply to comment #40) > They switched to Github a bit over a month ago. You need to be using an > updated mythtv.eclass. You can find a working ebuild at bug 347750. As > mentioned earlier in this bug, there is now an ebuild and eclass that can be > found in the official MythTV repository as well. Just for the records: that updated eclass now also solved my wget-problems. Thanks!
It looks like mythtv 0.24 has php bindings as well as the perl and python ones previously. https://github.com/MythTV/mythtv/tree/master/mythtv/bindings/php These are necessary for mythweb, perhaps others too. This would mean a php use flag?
(In reply to comment #45) > It looks like mythtv 0.24 has php bindings as well as the perl and python ones > previously. > > https://github.com/MythTV/mythtv/tree/master/mythtv/bindings/php > > These are necessary for mythweb, perhaps others too. This would mean a php use > flag? Those are new for 0.25, which is still under development. This bug is for 0.24 only. The ebuild will work with a few modifications for 0.25, but let's not worry about that just yet.
Created attachment 260314 [details] Updated, minor modifications Updated to a current commit, removed patches for SSA support. While the patches continue to (mostly) work on my builds, I don't know that the ebuild would be accepted with them.
There appears to be a set of ebuilds on the mythtv github: https://github.com/MythTV/packaging/tree/master/Gentoo
(In reply to comment #48) > There appears to be a set of ebuilds on the mythtv github: > > https://github.com/MythTV/packaging/tree/master/Gentoo A bit OT here maybe, but I run mythtv-0.24_p20110201 from that overlay now.
(In reply to comment #49) > (In reply to comment #48) > > There appears to be a set of ebuilds on the mythtv github: > > > > https://github.com/MythTV/packaging/tree/master/Gentoo > > A bit OT here maybe, but I run mythtv-0.24_p20110201 from that overlay now. > Me too.
mythtv-0.21-ldconfig-sandbox-fix.patch is still absent. I have used this patch from google: diff -ruN a/programs/mythfrontend/mythfrontend.pro b/mythtv.new/programs/mythfrontend/mythfrontend.pro --- a/programs/mythfrontend/mythfrontend.pro 2009-06-07 12:32:17.000000000 -0700 +++ b/programs/mythfrontend/mythfrontend.pro 2009-06-07 12:34:45.000000000 -0700 @@ -16,6 +16,9 @@ setting.files += MFEXML_scpd.xml setting.extra = -ldconfig+# Gentoo sandbox-2.0: +setting.extra -= -ldconfig + INSTALLS += setting QMAKE_CLEAN += $(TARGET) however i get the following error: http://ompldr/vN2hleA privatedecoder_crystalhd.o privatedecoder_crystalhd.cpp privatedecoder_crystalhd.cpp: In function 'QString bcmerr_to_string(BC_STATUS)': privatedecoder_crystalhd.cpp:864: error: 'BC_STS_CLK_NOCHG' was not declared in this scope make[2]: *** [privatedecoder_crystalhd.o] Error 1 make[2]: *** Waiting for unfinished jobs.... tv_play.cpp: In member function 'void TV::ProcessNetworkControlCommand(PlayerContext*, const QString&)': tv_play.cpp:4569: warning: 'tmpSpeed' may be used uninitialized in this function make[2]: Leaving directory `/var/tmp/portage/media-tv/mythtv-0.24_p20110119/work/MythTV-mythtv-90fe13c/mythtv/libs/libmythtv' make[1]: *** [sub-libmythtv-make_default] Error 2 make[1]: Leaving directory `/var/tmp/portage/media-tv/mythtv-0.24_p20110119/work/MythTV-mythtv-90fe13c/mythtv/libs' make: *** [libs] Error 2 emake failed [31;01m*[0m ERROR: media-tv/mythtv-0.24_p20110119 failed: [31;01m*[0m emake failed this is with crystalhd USE flag enabled for mythtv and modules USE flag disabled for crystalhd package as i use the in kernel module. any ideas?
Created attachment 263093 [details] CrystalHD patch This fixes the previous comment when using the CrystalHD commits after 23 Jan.
Created attachment 263111 [details, diff] another missing patch
(In reply to comment #52) > Created an attachment (id=263093) [details] > CrystalHD patch > > This fixes the previous comment when using the CrystalHD commits after 23 Jan. > yep - compiled fine. thx
(In reply to comment #48) > There appears to be a set of ebuilds on the mythtv github: > > https://github.com/MythTV/packaging/tree/master/Gentoo > I use the 'Graphite' theme. A couple of fonts are not installed by media-tv/mythtv-0.24_p20110219. media-fonts/droid media-fonts/liberation-fonts You might consider adding dependencies or a message in the ebuild. My experience with this version: I am using media-tv/mythtv-0.24_p20110219 from this overlay. It solved a problem with video recording stopping on a slave mythbackend with two tuners. When recordings completed on two channels, it failed to start recording on a third channel although there were no conflicts. The slave got very busy. The stream being watched from that backend on another computer froze for a couple of seconds too. Now occasionally there is a very short pause in the stream being watched when the backend completes recordings and starts new ones at the same time. No recordings are lost. I find this version stable and use it every day. It is superior to mythtv 0.23 in responsiveness and fixes problems with spdif audio being slow to sync when skipping around in a recording. I only use it for ATSC over the air HD recordings. I have found no regressions.
It's time this gets committed, what's left to resolve so that this can be in portage? We should do this before upstream leaves us behind.
(In reply to comment #56) > It's time this gets committed, what's left to resolve so that this can be in > portage? We should do this before upstream leaves us behind. Upstream hasn't left us behind. There is the upstream-maintained overlay that many are using for 0.24 and 0.25pre. Instructions found here: https://github.com/MythTV/packaging/tree/master/Gentoo Apparently Cardoe has been AFK for a while. http://forums.gentoo.org/viewtopic-p-6591657.html#6591657
I'm interested in trying to make 0.24 a reality. We actually need to stabilize 0.23+ anyway, and at this point it probably makes more sense to just skip 0.23 and invest our effort on 0.24 so that we're not always one behind. Things have just been crazy personally, and since my MythTV setup needs a high WAF I try to fiddle with it only when absolutely necessary (plus I use a minimyth front-end and hate having to fiddle with it). I also will probably find it difficult to personally test all the plugins. My general thinking was that I'd go ahead and do some quick tests on a virtual PC on the 0.24 setup and make sure that it looks basically usable. The fact that the overlay has some eclasses/etc in it concerns me a little - we'll just have to see if those can be integrated into the main tree (unless they are just copies without significant changes). If it looks good I'll add the packages to the tree masked for brave testers to try (again, I'll avoid reinventing the wheel and stay close to the overlay), and I'll migrate to them myself. If there are no issues we can proceed to unmasking and stabilizing (which needs a 30 day wait). What I can't promise is that I'll be able to personally test all the plugins, which could result in some of them not making it to stable. If anybody wants to proxy-maintain those that is something we can consider. If anybody has objections to this path forward let me know...
Sounds good. From what I hear of the people already testing the overlay builds, I have enough courage to do some testing. Would do it anyway on principle, can't poke the bear without wanting results whatever the consequence.
I used to have a really annoying problem when using PulseAudio where the volume would shoot up to 100% every time I played a recording. It was acknowledged by a developer who then refused to fix it because it was PulseAudio. *sigh* Fortunately that now seems to be fixed in the current 0.24 ebuild. What isn't fixed is DVD playback with PulseAudio. When using the internal player (which they recommend), the audio lags just like it did in 0.23. I haven't been able to find any reports of this problem elsewhere but I doubt I'm alone. BBC iPlayer also doesn't work in MythNetvision. Someone raised the problem at http://code.mythtv.org/trac/ticket/9357 and it was swiftly dismissed, closed and locked. Yet again, a great attitude. I've discovered that iPlayer works when browsing to the site with MythWeb and I gather MythNetvision uses MythWeb so this is very interesting. Unfortunately I can't mention this on the ticket as it is locked. I was ignored on IRC. I may raise it on the mailing list soon. So is it ready for the tree? Perhaps. For PulseAudio users, 0.23 is worse.
(In reply to comment #60) It isn't good that you feel like your requests have been ignored at Gentoo. Gentoo can't correct upstream's behavior, sadly. Having said that, Gentoo (and Linux) is about choice. So why do you *need* PulseAudio? ALSA works well for me. Is there some odd gadget or chipset that *only* works with PulseAudio?
> It isn't good that you feel like your requests have been ignored at Gentoo. > Gentoo can't correct upstream's behavior, sadly. Sorry, to clarify, I was referring to the MythTV devs and their IRC channel. > Having said that, Gentoo (and Linux) is about choice. So why do you *need* > PulseAudio? ALSA works well for me. Is there some odd gadget or chipset that > *only* works with PulseAudio? Trust me, I was very resistive towards PulseAudio to begin with. My ancient Creative Audigy 1 was fine with ALSA as it had hardware mixing but my new ASUS Xonar D2X didn't have that. Most cards don't. dmix is alright for basic usage but it won't, for example, mix a stereo and surround stream together. I've seen a couple of asoundrc hacks that are supposed to do this but I couldn't get these to work and if I couldn't, I certainly wouldn't expect anyone else to. PulseAudio also fills some useful feature gaps that ALSA never will because it's just too low-level. I did try JACK first, which was an improvement, but wasn't really appropriate for general desktop use.
I started doing some regression testing with the new eclasses, and I can already see some problems. The old ebuilds are not compatible with the new eclasses. Upstream has no issues with this since they don't support the older ebuilds. We can't make them disappear overnight, and I was hoping to make this a gradual transition (update the eclasses, introduce new builds as masked, unmask, etc). So, it seems like there are few basic approaches that could be taken: 1. Update the eclasses with version-specific conditional logic (old behavior for older ebuilds). This will involve quite a bit of conditional logic, unfortunately, as 85% of the eclasses are about fetching/etc and that is what changed. 2. Update the eclasses, and at the same time commit updated versions of the old ebuilds. This might involve QA issues since we can't allow a testing period without breaking the stable tree. 3. Create new eclasses, with the old ones eventually being retired. 4. Don't touch the eclasses - merge the code into the ebuilds for 0.24+ until we can get things back to a sane state. Actually, the eclasses have a moderate amount of version-specific conditional logic so I'd be half-tempted to do this anyway. Note - you won't notice the problems unless you force the ebuild to fetch from upstream. I'm open to suggestions - especially by the other maintainers. #2 just seems out to me, and I don't really like #1 (I can imagine 500 comments during review). #3 may be the cleanest at this point, and if there isn't much noise here I'll probably see what the sense on gentoo-dev is and if there is strong objections I'll probably fall back to #4.
Sounds like a good plan to me. I vote for #3.
Today MythTV 0.24.1 was released. So it would be great to add a working ebuild to portage.
Just curious, is anybody still working on an official Gentoo ebuild or should we just use the overlay from MythTV? If someone is working on an official ebuild: Thanks! Care to share your status?
(In reply to comment #66) > Just curious, is anybody still working on an official Gentoo ebuild or should > we just use the overlay from MythTV? > > If someone is working on an official ebuild: Thanks! Care to share your status? http://rich0gentoo.wordpress.com/2011/06/18/whats-up-with-mythtv-on-gentoo/
As a follow up to Rich's post. We're working with upstream to integrate with their upstream repo for future support. I unfortunately (for everyone, not for me) am going on vacation starting tomorrow. Once I return however, I intend on pushing into Gentoo a 0.24.1 version and getting that to stable very quickly. Upstream is in the process of applying a series of changes I sent to them to their repo and we'll be working to stay in sync.
Thanks for your much appreciated work. Have fun on your vacation.
Updates on MythTV 0.24.1 official ebuild? Thanks you.
Any progress on this? MythTV ebuild is about to fall 3 stable versions behind.
No kidding! This version bump request is 10 days shy of a year old. At least put what you have in the ~ tree.
*** Bug 388909 has been marked as a duplicate of this bug. ***
I've been using the ebuilds from the overlay (comment #37), and they've been working great.
So, is this now "maintainer-needed"?
Not sure - if nobody else is maintaining this package I'd probably take it a different direction. The current eclass won't work with the git repos so I'm running off of my own overlay based on upstream's builds. Cardoe mentioned a few months ago that he had plans to update the eclass and bump this, and if he still plans to do so I'm fine with letting him stay the course. If nobody is is going to maintain this then I don't mind doing so. I'm tempted to just stick a 0.24.1 ebuild in the tree that just declares the functions in the ebuild to eliminate the compatibility issue. I've been running it for months without issues...
Why not just add a mythtv-2.eclass? Would that cause any problems?
That was my original idea, and I'd probably consider this approach. However, eclasses by their nature are hard to change, and upstream is maintaining their eclass in an overlay which is easy to change - so that creates a lot of potential pain if upstream changes. Overlays aren't subject to QA rules around compatibility, since they aren't part of Gentoo. In any case, if you're suffering with the current state of affairs feel free to use the upstream overlay. Somewhere in bugzilla I had posted a working snapshot of that ebuild as well. To be honest, at least the mythtv non-plugin eclass doesn't really rise to the level that I would bother with an eclass with in the first place - it basically sets a few variables and most of the code is per-package anyway. The plugins eclass is more useful, and you could merge the two and only use it for the plugins I suppose. The original eclass made more sense as an eclass.
Created attachment 295811 [details] 0.24.1 ebuild to go into portage soon Feel free to test out this ebuild, which will be going into portage in a few days. You'll note that it does not inherit the mythtv eclass. At least during a transition period I won't be using the eclass. We'll have to see how stable the upstream eclass remains and figure out if we want to update the one in portage. Also, feel free to checkout: http://rich0gentoo.wordpress.com/2011/12/14/another-mythtv-update/ I'm also going to update mythweb and will commit both at the same time. Other plugins may follow over time, but I'm looking for volunteers willing to proxy maintain as I don't use plugins much at all on Gentoo.
Ok, it was a bit of a journey, but I think we've finally arrived. The ebuild itself needs a little work, but nothing that will impact end-users.
How much longer until official plugin ebuilds as well? If I attach an updated ebuild in their bug reports how long before devs commit it into the tree?
(In reply to comment #81) > How much longer until official plugin ebuilds as well? If I attach an updated > ebuild in their bug reports how long before devs commit it into the tree? The key to getting plugins into the tree will be having somebody commit to maintain them long-term. I probably won't commit ebuilds without at least an informal agreement from volunteers willing to look after any issues that arise with them. If the quality is good there shouldn't be many, and of course I'll look at anything before committing it. However, if somebody is willing to care for them long-term I would review them and commit or return with comments within a few days most likely. The biggest issue with the plugins is that they either need to use the existing mythtv eclasses without modification, or they need to not inherit them at all. Long term we can potentially update the existing eclasses. I'm not quite ready to stick a -2 version of them in the tree and until we retire the existing ebuilds we can't touch the ones we have. Feel free to contact me by email/irc to discuss. If there is interest I don't mind keeping the plugins, but only where they are getting use and where others are willing to test/etc.
I can't speak for everybody else but I myself utilize the plugins heavily, mythtv feels somewhat incomplete without mythvideo. I'll look at the existing ebuilds and see if I can hack them into working with the eclasses.
(In reply to comment #83) > I can't speak for everybody else but I myself utilize the plugins heavily, > mythtv feels somewhat incomplete without mythvideo. I'll look at the existing > ebuilds and see if I can hack them into working with the eclasses. mythgallery is quite useful as well. By the time we get myth plugins updated mythvideo will no longer be necessary since it's now integrated in mythtv as of 0.25.
(In reply to comment #84) > mythgallery is quite useful as well. By the time we get myth plugins updated > mythvideo will no longer be necessary since it's now integrated in mythtv as of > 0.25. Tend to agree. I plan to get 0.25 in the tree shortly after upstream declares it stable.
For those using Gentoo's official ebuilds + plugins, will there be a clean upgrade path to go to .23.1 - .24.1 - .25 with all the plugins?
(In reply to comment #86) > For those using Gentoo's official ebuilds + plugins, will there be a clean > upgrade path to go to .23.1 - .24.1 - .25 with all the plugins? There will most likely be a clean upgrade path for any plugins that remain in the tree. See: http://rich0gentoo.wordpress.com/2011/12/14/another-mythtv-update/ In short unless somebody steps up to maintain them most plugins will be going away in the portage version.
Plugins or no. Many thanks for your efforts Richard. I really appreciate you bringing Mythtv back into the official Gentoo tree. It feels like my Wife Appreciation Factor has been on a knife edge.
