Created attachment 579808 [details] mythtv-30.0.ebuild media-tv/mythtv is updated to v30.0 upstream. Initially, I copied the v29.1-r1 ebuild, bumped the version and fixed some DEPEND versioning issues. In doing some reading, I discovered that v30.0 adds support for "xNVCtrl" which is evidently a new nVidia feature, but I don't run any nVidia hardware, so I can't test it. I also couldn't find a system-wide USE flag for the feature, so I just added one 'xnvctrl' which is disabled by default. They removed the mythlogserver feature upstream, along with removing configure options to disable theora and vorbis, and consequently I removed the USE flags and the no-longer-available configure options. I also added support for x265 alongside x264 and vpx since there's a configure flag for it. They are all activated with the 'hls' USE flag, as previous. I attached the updated v30.0 ebuild, which worked for me. I also noticed a maintainer is needed for this project too. I can help with occasional updates if nobody steps up for a while, but my available time tends to be rather short. In reading the attachment notes, I'll just comment that this file is based on Gentoo's previous ebuild, which I think is either GPL or LGPL, so my improvements are also provided under whatever licensing Gentoo normally uses for ebuilds.
Thanks for your work! Does it indeed still depend on QtWebKit though?
Actually, xNVCtrl is nothing new at all. That's just the nVidia libXNVCtrl library that gets installed with nvidia-settings. That's always been in MythTV and is actually in the mythtv source under mythtv/external/libXNVCtrl. The change in 30.0 is that they use the systems libXNVCtrl in place of the one built into their. I believe that you really need that when using nvidia at all, so I don't think a use flag is really appropriate here. The configure script already handles a case (in suse apparently) where the libXNVCtrl library is not available, using the one built into MythTv instead. In order for this to all work correctly in Gentoo in cases where nvidia-drivers are being used without the tools USE flag (where no nvidia-settings or the libXNVCtrl gets installed) the configure actually needs a patch like the one I attached to bug 674216. Thanks for the work for sure! While I understand the motivation to have the plugins in the same ebuild as mythtv itself (as with the ebuild attached to bug 674216) it makes for a really complex ebuild, so I opted for one similar to this this one.
As to the question on QtWebkit, MythTV can work fine without it as long as you're not using any plugins (or at least any that require it). However the current MythTV configure script from upstream still requires it, and has no option to exclude it. That is, it links all that in as long as the headers are there. I've been using MythTV without it for some time but currently it takes some doing, as I just explained here: https://forums.gentoo.org/viewtopic-t-1098036.html
I'm going to post a version of the ebuild that I've used, with some of my own custom modifications reversed (my changes to exclude qtwebkit as well as changes I use to exclude qtdbus and udisks2). The only reason I've never posted this before was that bug 674216 with the version including plugins seemed to be the way everyone wanted to go. Note that I have no way to test this ebuild as it stands. I'll also post a patch to handle the libXNVCtrl issue discussed above, however note that this ebuild doesn't automatically apply that. Actually there are a few issued with the original ebuild here that are addressed in the one I'll attach: Version 30 has some new requirements (that used to be built into MythTV) as noted in the release notes including these: >=media-libs/libbluray-0.9.3 media-libs/libsamplerate media-libs/libhdhomerun dev-libs/lzo I wanted to make that >=media-libs/libbluray-0.9.3 conditional based on the existing bluray USE flag, however oddly the main configure script has no option to exclude this as far as I can see. Also note that the libhdhomerun requirement should probably be based on a USE flag and currently it isn't. HDHomeRun tuners won't work without that. Also, the zlib requirement now needs the minizip USE flag: sys-libs/zlib[minizip] My version also has the virtual/mysql requirement removed, as mysql itself is no longer required unless you're installing for a backend. The only actual requirement there now are the mysql client libraries which are already handled by virtue of dev-qt/qtsql:5[mysql]. However also note these other differences: My version has BACKPORTS set to a version of 30/fixed from 4/26/2019 when I created it. If the BACKPORTS in the original here is newer than that, you could surely change it to that. Mine doesn't have the h265 support added.
Created attachment 579902 [details] MythTV 30.0 ebuild with additional requirements
Created attachment 579904 [details, diff] Patch to use MythTV built-in libXNVCtrl when nvidia-drivers tool USE isn't set
Also, just to clarify the insanely confusing bug history here, bug 676952 was originally entered as a version 30.0 version bump, and was marked as a duplicate of bug 674216, which was originally around reinstating the mythtv plugins in 29.1, and then this was was entered. In fact the ebuild posted to the original bug wasn't too much different from mine here...so this has sort of come full circle. With QtWebkit becoming deprecated, I'd say that whole plugin situation is tenuous at best unless upstream replaces it with QtWebEngine at some point.
I find it interesting that there are so many bug reports regarding this package version bump. I searched for "media-tv/mythtv" bugs before creating this one, so I'm surprised I didn't find one of the other bugs to join that discussion. Given the amount of external discussion on the topic, perhaps this bug report should be closed and merged with one of the others? @Andreas: I didn't pay attention to QtWebKit specifically, but after this latest update which included the MythTV update, I was finally able to rid my system of all its legacy QT4 dependencies, and I didn't see a notice that anything was pulling in masked/deprecated packages at this point. I run KDE/Plasma 5 desktop on the system, so I likely had it already installed. To confirm, I looked for qtwebkit and found this: # equery l -poi dev-qt/qtwebkit * Searching for qtwebkit in dev-qt ... [I-O] [ ] dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212 # So I suppose I do still have it installed, but looking at "equery d", mythtv is not the only installed kde/qt package that requires it. Tom correctly pointed out a few oversights in my ebuild, so its probably not ready for prime time just yet. Based on the simplicity of my changes, I would probably suggest taking some of my improvements and selectively applying them to a more complete solution. If you need something specific from me, let me know. @Tom: You seem to have a lot more effort invested in your ebuild than I do, and I would hate to derail your progress, so please take this and run with it. If you need something specific from me, let me know. My level of concern to this package in general is minimal these days, especially regarding features I'm not using, so you can take any useful pieces of my ebuild to embed them into yours, or not, as you see fit. In general I think simpler ebuilds are a good thing for long term ease of maintenance, so just having USE flags which translate into configure functionality (either by passing configure flags or otherwise) is ideal. Considering that this package is already in need of a maintainer, I think ease of maintenance is a key consideration to any enhancements. I do recall around the 0.20.x days that there were many independent plugin ebuilds, which was fine at the time. It seems that upstream mythtv includes the plugins though, so maybe it makes sense to have a USE-expand or some set of local USE flags to indicate which plugins to build along with the core. If the plugins were not included upstream, I would definitely say they should be their own ebuild, or potentially even multiple ebuilds, as it used to be. I understand the preference to have a "mythtv-plugins" ebuild that builds the plugins independently from the core, but the plugins are part of the upstream core build process, so creating a separate plugins ebuild amounts to splitting a monolithic package into components across separate ebuilds, which can be much messier and harder to maintain. If it is only some of the plugins requiring QtWebKit, and not actually mythtv core, then that requirement should be specific to the plugins in some way, not universally demanded by the core. Regarding the mysql dependency, I do run a backend on another Gentoo system, but I haven't migrated that to 30.0 yet. There used to be a "frontend" or "backend" USE flag (I forget, its been a while), which would avoid building the other half of the system. Maybe it would be worthwhile to re-introduce that and include the mysql server dependency as dependent on that USE flag? On that, I would think there must be more frontend-only setups than backend-only ones. And there are likely more combination (frontend + backend, all-in-one) boxes than backend-only boxes due to the simpler system setup involved. So overall more systems have frontend than backend components. So perhaps that helps to identify the default inclusion and naming that should be used in the USE flags. Other thoughts: I believe I had libbluray already installed for something else, so that's probably why I overlooked that dependency. I agree it should be dependent on the existing bluray USE flag though. I don't intend to do any more enhancement on this unless I run into an issue, or unless someone needs me to do something specific. Has anyone made an overlay for mythtv with some variant of these ebuilds? I think that would make it easier to collaborate than posting bug reports with seemingly divergent approaches.
Thanks for the reply Brian...I didn't see this until today (forgot to add myself to the cc list). Yea, I'm not at all sure what direction any of this should take frankly. I understand the attraction of having the plugins in the same ebuild for anyone who uses them, as well as the difficulties of having them separate. For my own purposes given that I don't use them, I can't imagine using anything that complex unless it was really solid and maintained. A few thoughts on things you've brought up: As for the mysql dependency, as far as I recall, that "frontend" and "backend" use flag never really worked, and I'm not sure MythTV supports anything of the sort...at least not that I'm aware of. Personally I'm not sure anything is really needed here except possibly error handling in pkg_config() if MySQL isn't installed. The client library dependencies are of course already handled by dev-qt/qtsql:5[mysql]. My biggest problem with all this is that the complexities of the configuration and build process are WAY out of my area of expertise...and that's where most of the complex issues are right now. I really don't fully understand how tell from the source what configuration options will or won't work in a manner that would be needed by Gentoo USE flags. Here are some examples: The big one is qtwebkit. I have my own configure script patched to remove that requirement and to just do "disable qtwebkit". However (and I only know this based on testing using ebuild compile), while MythTV works fine without it, the only way I'm aware of to prevent QtWebkit from getting linked in is to NOT have it installed. That is, there's currently no means of telling the build to ignore it even if it's installed. I have no idea what changes in MythTV would be required to add that. Without it of course, and attempt at a USE flag could result if your newly compiled MythTV getting broken by "emerge --depclean". The qtdbus and udisks2 requirements are another example. I'm not using that (or dbus itself) either. That's apparently only used for auto detection of DVD drives etc. I think the dbus stuff can be used for screen saver control(?) though I'm not clear. I use xscreensaver and MythTV's built in support for that works perfectly for me. Yet I've gotten conflicting information as to whether the configure even supports --disable-qtdbus, let alone whether it works in a way that would work as needed by the Gentoo dbus USE flag. I brought this up on the mythtv-dev mailing list, but here's a post that conflicted with everything discussed there: https://lists.gt.net/mythtv/users/614197?search_string=mythtv%20under%20Gentoo%20Linux%20;#614197 For the same reasons I'm not sure as to libbluray. Up until 29.1 that was built into MythTV regardless. To further complicate things for my situation, I actually ended up reverting back to 29.1 because 30.0, specifically on 32 bit x86, can't decode some h264 videos using vdpau...ones that work perfectly in 29.1. I'm concerned that that's one that may never get resolved. So for now I'm sort of stuck with my own "works for me" version unfortunately, though I'm glad to help where I can. Thanks again!
Created attachment 586766 [details] Latest fixes/30 ebuild This patch uses the latest commit from the fixes/30 branch. This branch now contains fixes for a build failure issue related to >=exiv2-0.27, and it supersedes the patch "mythtv-30.0-configure-nvctrl-internal.patch" [ as that fix is included upstream in that branch ]. It also has a new use flag to enable a workaround patch for UK dvb-t/t2 tuning issue, `uk_tuning_workaround`. Please see https://code.mythtv.org/trac/ticket/13292#no1
Created attachment 586768 [details, diff] Patch for Latest fixes/30 ebuild Patch for Latest fixes/30 ebuild containing the UK tuning issue patch
For information on the exiv2 build breakage, please see https://code.mythtv.org/trac/ticket/13452 ``` imagemetadata.cpp: In constructor ‘PictureMetaData::PictureMetaData(const QString&)’: imagemetadata.cpp:303:19: error: ‘Error’ in namespace ‘Exiv2’ does not name a type catch (Exiv2::Error &e) ^~~~~ In file included from imagemetadata.cpp:3: imagemetadata.cpp:305:74: error: ‘e’ was not declared in this scope LOG(VB_GENERAL, LOG_ERR, LOC + QString("Exiv2 exception %1").arg(e.what())); ^ ../libmythbase/mythlogging.h:44:34: note: in definition of macro ‘LOG’ QString(_STRING_).toLocal8Bit().constData()); \ ```
Thanks for the updates! Just to avoid confusion, you've mentioned ">=exiv2-0.27". This issue is actually with >exiv2-0.27 (that is 0.27.1) correct? Thanks again.
Yes, you are correct Tom. Sorry for mis-information :) I had that in my head as the exiv2 version bump for my upgradesin gentoo went from 0.25.x to 0.27.2 or something like that, and I just assumed it was 0.27 thing.
I think the perl use flag might need to require dev-perl/XML-Simple. An error is raised right after configure that suggests this. Adding dev-perl/XML-Simple to my system makes the message go away when using your ebuild. media-tv/mythtv-status needs the perl use flag on media-tv/mythtv. Not all features of mythtv-status worked when mythtv was built without dev-perl/XML-Simple. Thanks for creating this ebuild!
Created attachment 587148 [details, diff] exiv2-0.27 patch for mythtv Patch for mythtv-30.0 to fix the exiv2-0.27.x compiler error.
@<Brian McKee> The exiv2 issue is fixed upstream. If you use the latest ebuild I added here, it uses a ref from fixes/30 that includes the fix. Therefore your exiv2.patch should not be required.
With the latest ebuild I get an error XNVctrl not found >>> Configuring source in /var/tmp/portage/media-tv/mythtv-30.0-r1/work/mythtv-30.0-r1/mythtv ... * Running ./configure --prefix=/usr --libdir=/usr/lib64 --libdir-name=lib64 --mandir=/usr/share/man --enable-audio-alsa --disable-audio-jack --disable-altivec --disable-dvb --disable-firewire --disable-lirc --enable-libxvid --dvb-path=/usr/include --enable-xrandr --enable-xv --enable-x11 --enable-nonfree --enable-libmp3lame --disable-libcec --disable-libdns-sd --enable-libx264 --enable-libvpx --disable-libass --with-bindings=perl,python --python=python2.7 --compile-type=release --disable-stripping --enable-vdpau --enable-vaapi --disable-crystalhd --disable-joystick-menu --enable-symbol-visibility --enable-pic --cpu=host --disable-distcc --enable-systemd_notify --enable-systemd_journal ERROR: XNVctrl not found
Strange one. I'm assuming you mean the newest one above from jcat. I just checked out the commit version used by that ebuild that should work. See the lines starting at line 6654 of the configure script. That assumes you have a /etc/os-release file containing ID=gentoo. Note that the code makes a check for an executable /usr/bin/nvidia-settings file. If it's NOT there it uses "disable xnvctrl_external" which causes MythTV to use it's own built in xnvctrl. This is what happens in my case as I have nvidia-drivers installed with -tools. While I've had to revert to 29.1 for other reasons, this did work for me for sure. If you do have nvidia-settings then it's checking for the headers etc. I'm not sure why that would be broken. That's the line doing this: require XNVctrl "X11/Xlib.h NVCtrl/NVCtrl.h NVCtrl/NVCtrlLib.h" XNVCTRLIsNvScreen -lXNVCtrl It would be interesting to see if anyone else using this uses nVidia with the nvidia-settings installed. Tom
Yes I meant the latest one from jcat
I do have a /etc/os-release file containing ID=gentoo and the /usr/bin/nvidia-settings file
I don't seem to have NVCtrl/NVCtrl.h NVCtrl/NVCtrlLib.h headers installed by x11-drivers/nvidia-drivers-418.88
That's pretty strange. Unfortunately I have no way to test any of that here. I'm using -tools because nvidia-drivers now requires dbus etc. I can clearly see where that gets built by the nvidia-drivers-418.88.ebuild ebuild starting at line 209 (the make with build-xnvctrl) and appears to get installed starting at line 378...hard to imagine that wouldn't install headers. No clue on any of that. A work around would be to patch the configure to force it to act as it would without nvidia-settings thus using "disable xnvctrl_external". That works fine and simply uses the MythTV built in one as it did in 29.1.
I got it now. It seems that if static-libs use flag is not enabled in nvidia-drivers you don't get the headers.
Wow...good catch. Would have never thought that. Seems odd as the headers obviously apply to the dynamic libraries as well.
*** This bug has been marked as a duplicate of bug 676952 ***
