Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
MythTV won't recompile: how to proceed?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Multimedia
View previous topic :: View next topic  
Author Message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Mon Jan 11, 2016 3:07 am    Post subject: Reply with quote

jamtat wrote:
Analyzing this failure is proving to be a bit over my head. The only thing I could think of that might be revealing was to grep the build log for the word "failed." So, here's the output from that (from cat build.log | grep -B 2 -A 2 failed, to be precise) in case it might be revealing:

Code:
[ -f qjson/include/QJson ] && \
/var/tmp/portage/media-tv/mythtv-0.27_p20140321/work/mythtv-0.27/mythtv/programs/mythavtest/../../libs/libmythtv/videooutbase.h:203: undefined reference to `VideoBuffers::DoneDisplayingFrame(VideoFrame_*)'
collect2: error: ld returned 1 exit status


I've put the full build log at http://chopapp.com/#16hyidom . Further input will be appreciated.


This is a (somewhat) easier fix. I assume you are using gcc 4.9.x? My google-fu led me to this bug report which led to this patch which indicates you need to use mythtv-0.27.5_p20151025 or newer.

I see you are trying to build an old version from 2014. There are newer versions, but you will need to unmask them:
Code:

$ eshowkw mythtv
Keywords for media-tv/mythtv:
                       |                                 | u                    | 
                       | a a   a         n   p r     s   | n                    | 
                       | l m   r h i m m i   p i s   p   | u s                  | r
                       | p d a m p a 6 i o p c s 3   a x | s l                  | e
                       | h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | e o                  | p
                       | a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | d t                  | o
-----------------------+---------------------------------+----------------------+-------
   0.26.0_p20130922    | o + o o o o o o o o o o o o o + | # 0                  | gentoo
     0.27_p20140321    | o + o o o o o o o o o o o o o + | o                    | gentoo
   0.27.5_p20150627    | o ~ o o o o o o o o o o o o o ~ | #                    | gentoo
   0.27.5_p20150904-r1 | o ~ o o o o o o o o o o o o o ~ | o                    | gentoo
-----------------------+---------------------------------+----------------------+-------
   0.27.5_p20150904-r2 | o ~ o o o o o o o o o o o o o ~ | o 0/0.27.5_p20150904 | gentoo
-----------------------+---------------------------------+----------------------+-------
[I]0.27.5_p20151025    | o ~ o o o o o o o o o o o o o ~ | o 0/0.27.5_p20151025 | gentoo


As you can see from my earlier post I unmasked media-tv/mythtv-0.27.5_p20151025 and it builds fine with gcc 4.9.x.
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Tue Jan 12, 2016 4:24 pm    Post subject: Reply with quote

Thanks for the continued input, danomac. Yes, I have gcc 4.9.x--apparently acquired during what I would characterize as a routine system upgrade. I'm trying to determine how to proceed and it seems to me there are 3 possible options, as follows:

1) simply allow mythtv to continue failing to compile, presuming that, at some point, more current masked versions that are compatible with gcc 4.9.x are going to be unmasked, at which point the compilation will succeed.

2) downgrade gcc to a version that will be compatible with my current version of mythtv

3) manually unmask a newer, gcc-4.9.x-compatible version of mythtv and re-compile

Have I correctly understood what are my options?

If so, the main reason I can think of in favor of 1) is that I will be, in a sense, allowing the system to resolve its own issues rather than manually intervening: that keeps responsibility for maintaining sane system updating largely in the hands of gentoo developers/maintainers, as I see it. 2) is a less desirable option but would, in theory, allow me to answer the burning question of whether I can now finally compile mythtv with the vaapi support I've been wanting. The same pretty much holds for option 3): it would allow me to determine whether the vaapi issue is resolved. But both of these latter involve manual intervention in, what it seems to me, is ultimately a sort of distro-maintenance issue. Both these will also entail, if I'm understanding correctly, undoing at some point in the future. All this said, I still don't feel that I have a very good grasp on the masking/unmasking procedures entailed in running this distro.

Further input will be appreciated.
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Tue Jan 12, 2016 4:52 pm    Post subject: Reply with quote

jamtat wrote:
Thanks for the continued input, danomac. Yes, I have gcc 4.9.x--apparently acquired during what I would characterize as a routine system upgrade. I'm trying to determine how to proceed and it seems to me there are 3 possible options, as follows:

1) simply allow mythtv to continue failing to compile, presuming that, at some point, more current masked versions that are compatible with gcc 4.9.x are going to be unmasked, at which point the compilation will succeed.

2) downgrade gcc to a version that will be compatible with my current version of mythtv

3) manually unmask a newer, gcc-4.9.x-compatible version of mythtv and re-compile

Have I correctly understood what are my options?


Yes, those are all viable options - but if you decide to downgrade gcc you will needs to rebuild libtool at the very least.

Keyworded/masked packages work a little differently in gentoo, if something is really, truly broken it would be hard-masked. Packages marked unstable are generally OK to use but they may have other packages that are required that are also marked unstable. Portage will tell you this when you try to emerge it.

In the case of mythtv and your specific case, I would just unmask all mythtv versions lower than 0.28 - this will let you use the newest packages with no issue. This way when a 0.28 build does eventually work its way into the tree it won't be automatically installed during a world update.

It's very easy to do this, just:

Code:

# echo "<media-tv/mythtv-0.28 ~amd64" >> /etc/portage/package.keywords/mythtv


then do a

Code:

# emerge -pv mythtv


...and portage should see the latest 0.27 build.

I've been using the "unstable" mythtv packages for almost as long as I've been using mythtv (~6 years now) with no issues - but I've stayed with the same version. As in, I don't install new version releases ( like 0.28 ) before I can test elsewhere first. :wink:

By the way, after I read your first post and you mentioned that someone stopped responding to your other threads I realized it was me. I got really busy at work and I just plain forgot about the thread. :oops: Sorry...
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Tue Jan 12, 2016 6:15 pm    Post subject: Reply with quote

Thanks again for offering input, danomac. No need for apologies: I realize no one is obligated to help me on these forums and am just appreciative of any assistance rendered, even if it involves sometimes lengthy pauses :)

I understand your directives for enabling mythtv releases lower than .28 and do see the logic behind it. That's probably what I'll wind up doing. But I'd like to ask some additional questions regarding this distro's mode of operation, if I may: knowing answers to these questions should help me learn how to better administer this system.

The thing I find a bit confusing about the present scenario is the following: both my current mythtv version, as well as the version of gcc I've currently got installed are considered stable, if I've understood correctly. If I have, these packages end up being nonetheless incompatible with each other, it seems. This appears odd to me since I would expect, based on experience with other distros (mainly Arch, Debian/Ubuntu) that stable packages should, by definition, be compatible (within a given release in the Debian/Ubuntu case and on an up-to-date system in the Arch case). Do the concepts "stable" and "unstable" carry different connotations in the gentoo world than in the case of these other distros, then? Also, does this sort of scenario, i.e., wherein two stable packages--and especially one as central to system operation as is gcc in the case of gentoo--turn out to be incompatible with one another, occur very frequently under gentoo?
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Tue Jan 12, 2016 7:35 pm    Post subject: Reply with quote

jamtat wrote:

The thing I find a bit confusing about the present scenario is the following: both my current mythtv version, as well as the version of gcc I've currently got installed are considered stable, if I've understood correctly. If I have, these packages end up being nonetheless incompatible with each other, it seems. This appears odd to me since I would expect, based on experience with other distros (mainly Arch, Debian/Ubuntu) that stable packages should, by definition, be compatible (within a given release in the Debian/Ubuntu case and on an up-to-date system in the Arch case). Do the concepts "stable" and "unstable" carry different connotations in the gentoo world than in the case of these other distros, then? Also, does this sort of scenario, i.e., wherein two stable packages--and especially one as central to system operation as is gcc in the case of gentoo--turn out to be incompatible with one another, occur very frequently under gentoo?


What you are experiencing is the chicken-and-egg problem, and the differences between source and binary distros. Mythtv was stabilized against gcc 4.8.x (as an example.) The new version of gcc came out and mythtv had an issue building against it early on. The issue was actually resolved, but the package with the fixes is marked unstable. In gentoo, a user can file a bug requesting a package to be stabilized, it is not necessarily an automatic process. I will be requesting stabilization for amd64 by this weekend as long as no issues crop up (I have 5 frontends and a backend and have seen zero issues since the update the weekend before last.)

In a binary distro, a release always has the toolchain locked down. This means that the gcc/libtool/supporting libraries' versions are locked down and any new updates are always compiled against that toolchain.

Gentoo is a rolling distro, which means that the toolchain can vary, and now it becomes quite a bit more complicated dealing with updates. I personally have been using gentoo since 2003 and while I have experienced major breakage on updates, I've only personally seen it 3 times since then.

Generally speaking, be wary of new toolchain versions. Just because they come out doesn't mean you are obligated to use them right away. When I updated from gcc 4.8.x to 4.9.x I didn't see any issues (mostly because the main packages that had issues I already was using the "unstable" versions.)

So what you've seen can happen. Is it a regular occurence? In my personal experience, no. However, I also have accumulated enough knowledge now that I can usually figure my way around some of these faults.

Quite often you can google and issue (or search gentoo's bugtracker) with build time errors and find workarounds.

Having a source-based distro does have benefits. Gentoo gives you a lot of flexibility in how things are built, provided you know what you are doing. The point of the profiles is to have a "sane" base of things that normally required for software to be built properly. In your case, going from a desktop profile to the multilib profile removed some of the desktop-based USE flags that would have prevented the vaapi build-time error on mythtv you were experiencing. As an example of this, when the heartbleed issue was disclosed, all that was required on gentoo (right away, before a fix was released) was flipping a USE-flag and rebuilding openssl. When the patch was released a few days later you could reverse said USE-flag again and build the new version. You just don't get that kind of flexibility with a binary distro.

If mythtv builds successfully with the newest build, let me know and I'll post a bug referencing the hard dependency that's needed for mythtv to build properly. Most likely the mythtv ebuild maintainer isn't even aware that the issue exists.


Last edited by danomac on Tue Jan 12, 2016 8:14 pm; edited 1 time in total
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Tue Jan 12, 2016 8:02 pm    Post subject: Reply with quote

That's a really helpful explanation, danomac. Much appreciated. I suppose a lesson could be resolved out of this instance, one that could be summarized along the following lines: beware gcc major version updates. Correct? Had I been aware of such potential issues, I suppose I might've "pinned" (think that's Debian/Ubuntu- or Arch-speak) the gcc version at 4.8.x: that would--at least up to a certain point--have been a viable option, right?

As far as USE flags, I assume you refer mainly to the dummy flag discussed earlier, right? I am using the no-multilib profile, btw, which I think you understood but just made an inadvertent error in mentioning the multilib profile.

Still learning--obviously--and still trying to decide how to proceed.
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Tue Jan 12, 2016 8:28 pm    Post subject: Reply with quote

jamtat wrote:
That's a really helpful explanation, danomac. Much appreciated.


No problem! Back in 2003 I came from Redhat, Mandrake, and Debian. At first I was overwhelmed. I actually prefer the way portage works now - I've tried twice (unsuccessfully) to switch to another distro. I always come back, though.


jamtat wrote:
I suppose a lesson could be resolved out of this instance, one that could be summarized along the following lines: beware gcc major version updates. Correct? Had I been aware of such potential issues, I suppose I might've "pinned" (think that's Debian/Ubuntu- or Arch-speak) the gcc version at 4.8.x: that would--at least up to a certain point--have been a viable option, right?


Yes, major version gcc bumps may cause some issues. They don't always happen though, but you need to be aware that something could happen. Usually the resolution is to unmask a specific version of the software that has an issue (as you've seen with mythtv.)

Just because a new version of gcc is built doesn't mean you need to use it. That's what gcc-config is for, use `gcc-config -l` to list what gcc versions are available. Portage will not change this automatically for you. You can also manually mask newer versions gcc yourself so they aren't built until you are ready, as they can take a while.

jamtat wrote:
As far as USE flags, I assume you refer mainly to the dummy flag discussed earlier, right? I am using the no-multilib profile, btw, which I think you understood but just made an inadvertent error in mentioning the multilib profile.


To sum it up in a sentence: USE-flags define optional software support installed with a package.

That is one example. However, when you added 'opengl' to the USE line in /etc/portage/make.conf that is another example. By doing it globally, you've basically instructed all packages to build opengl support if they have it available. On the flip side, if you don't want to deal with ipv6, you add '-ipv6' to the same USE line, and no ipv6 support will be built. My ISP doesn't directly support IPv6 nor does my router and I really don't feel inclined to deal with it now.

What probably happened is that the default USE flags in the desktop profile are quite different than the default flags in the no-multilib profile. Those USE flags define how optional support is built in packages and thusly can majorly affect the outcome of said software when it is installed on your PC.

There are tools that attempt to describe what the USE flags do. If you see a bunch of USE flags for software you're trying to install, use:

Code:

$ equery uses mythtv
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for media-tv/mythtv-0.27.5_p20151025:
 U I
 + + alsa                     : Allows MythTV to directly output sound to ALSA devices, this is needed if you are using ALSA dmix or SPDIF. Note, you will have to physically type your device into the MythTV configuration since it will only give you /dev/dsp devices in
                                the drop down.
 - - autostart                : Uses a custom autostart configuration gleaned from experience with MythTV since its early versions and discussed with other MythTV maintainers and users. Does not rely on KDE being installed like most methods do.
 - - avahi                    : Add avahi/Zeroconf support
 - - bluray                   : Pulls in libbluray for BluRay support.
 - - cec                      : Allows you to control CEC enabled TVs via HDMI. Currently requires a USB based CEC -> HDMI injector between your TV and video card since no graphics drivers support CEC natively.
 - - crystalhd                : Allows you to utilize a Broadcom CrystalHD hardware based video decoder to improve the performance of video decode.
 - - debug                    : Instructs Qt to use the 'debug' target instead of 'release' target. If your MythTV is crashing or you need a backtrace, you need to compile it with this option otherwise the debugging data is useless.
 - - dvb                      : Enables support for Linux DVB cards. These include all cards that work with digital signals such as ATSC, DVB-T, DVB-C, and DVB-S, QAM-64, and QAM-256.
 + + dvd                      : Add support for DVDs
 - - egl                      : Support EGL video output.
 - - fftw                     : Support visualizations via sci-libs/fftw
 + + hls                      : HTTP Live Streaming support
 - - ieee1394                 : Allows MythTV to communicate and use Firewire enabled Cable boxes. These are typically found in the United States, where such support is required by law. This will also install Firewire test programs and external channel changers if the
                                internal changer does not work.
 - - input_devices_joystick   : INPUT_DEVICES setting to build driver for joystick input devices
 - - jack                     : Allows MythTV to use JACK as your sound output device. You will have to manually configure the path to your JACK settings.
 - - lcd                      : Tells MythTV that you have an instance of app-misc/lcdproc configured on your machine and it should output information such as current time, show name, episode name, etc to that LCD.
 - - libass                   : SRT/SSA/ASS (SubRip / SubStation Alpha) subtitle support
 - - lirc                     : Adds LIRC support directly to MythTV allowing for built in control via a LIRC device.
 + + perl                     : Builds the perl bindings for MythTV. Allows you to write scripts in Perl to control your MythTV setup or communicate with it.
 + + pulseaudio               : Add support for PulseAudio sound server
 + + python                   : Add optional support/bindings for the Python language
 + + python_targets_python2_7 : Build with Python 2.7
 + + theora                   : Add support for the Theora Video Compression Codec
 + + vaapi                    : Enable Video Acceleration API for hardware decoding
 - - vdpau                    : Enable the Video Decode and Presentation API for Unix acceleration interface
 + + vorbis                   : Add support for the OggVorbis audio codec
 + + wrapper                  : Use Ubuntu mythtfrontend wrapper.
 + + xml                      : Add support for XML files
 - - xmltv                    : Pulls in the media-tv/xmltv TV listing grabbers for users not using Schedules Direct.
 + + xvid                     : Add support for xvid.org's open-source mpeg-4 codec


The column on the left has two pieces of info, U being what you've requested, and I indicating what the current software was installed with. And as you can see, it shows a short description of what it is supposed to do. On this machine, which is a remote frontend, has no support for dvb tuners, but this is critical support needed for a backend that has tuners installed.

Normally portage abbrievates this in output like so:

Code:

$ emerge -pv mythtv

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ~] media-tv/mythtv-0.27.5_p20151025:0/0.27.5_p20151025::gentoo  USE="alsa dvd hls perl pulseaudio python theora vaapi vorbis wrapper xml xvid (-altivec) -autostart -avahi -bluray -cec -crystalhd -debug -dvb -egl -fftw -ieee1394 -jack -lcd -libass -lirc -vdpau -xmltv" INPUT_DEVICES="-joystick" PYTHON_TARGETS="python2_7" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Tue Jan 12, 2016 11:15 pm    Post subject: Reply with quote

Quote:
Mythtv was stabilized against gcc 4.8.x (as an example.) The new version of gcc came out and mythtv had an issue building against it early on. The issue was actually resolved, but the package with the fixes is marked unstable.


Ah! I have 4.9.3 but there were so many problems that I eselected 4.85. That's why no problems with MythTV. I always keep two versions of gcc and save them as packages as well. Once gcc was inadvertanly erased and I had a heck of a time rebuilding the system.
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Wed Jan 13, 2016 12:22 am    Post subject: Reply with quote

Tony0945 wrote:
Ah! I have 4.9.3 but there were so many problems that I eselected 4.85. That's why no problems with MythTV. I always keep two versions of gcc and save them as packages as well. Once gcc was inadvertanly erased and I had a heck of a time rebuilding the system.


What version of MythTV are you using? You can use `equery list mythtv` to show the version.
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Jan 13, 2016 4:19 pm    Post subject: Reply with quote

danomac wrote:

What version of MythTV are you using? You can use `equery list mythtv` to show the version.


mythtv-0.27_p20140321 Which I beleive is latest stable or should be as I synced two days ago.
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Wed Jan 13, 2016 4:21 pm    Post subject: Reply with quote

Tony0945 wrote:
danomac wrote:

What version of MythTV are you using? You can use `equery list mythtv` to show the version.


mythtv-0.27_p20140321 Which I beleive is latest stable or should be as I synced two days ago.


Ah, that's why. The most recent unstable is the only package with the fix for gcc 4.9.x.
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Thu Jan 14, 2016 10:29 pm    Post subject: Reply with quote

danomac wrote:
No problem! Back in 2003 I came from Redhat, Mandrake, and Debian. At first I was overwhelmed. I actually prefer the way portage works now - I've tried twice (unsuccessfully) to switch to another distro. I always come back, though.

That's about the time I first tried out Gentoo as well, though I'd pretty much settled by that point on Debian as my distro of choice. I ended up trying Gentoo because I'd befriended this 14-year-old kid that I'd introduced to Linux in hopes he'd become someone I could work with on some of my computer projects. I gave him my LFS CD, since I'd not found the time to try out that project, and before I knew it he'd done the project on his own and had even tried out Gentoo. In short order he became a maintainer for a set of Gentoo kernel patches around that time. Needless to say, he more or less left me in the dust. But I did manage to persuade him to install Gentoo for me on a laptop in early 2003. I chickened out fairly quickly though, and went back to more familiar distros later that year.

I'm sort of stalling on making a decision about what to do about re-compiling mythtv, in case that's not clear. Though it would be interesting to know whether I can now finally compile it with vaapi support, I do currently have a working mythtv on this system. So the matter isn't urgent. And I cannot find a compelling reason to do either 2) or 3), so I'm currently going with the default (1)). But that may change soon. I'll be sure to post in this thread the results of any future re-compiling with vaapi support.


Last edited by jamtat on Tue Feb 02, 2016 11:55 pm; edited 1 time in total
Back to top
View user's profile Send private message
wankykootiepooper
n00b
n00b


Joined: 26 Jan 2016
Posts: 4
Location: Calgary, Alberta, Canada

PostPosted: Tue Jan 26, 2016 5:44 am    Post subject: Reply with quote

Danomac,

Thanks for keeping this thread going.

I've been compiling Mythtv for years, and this is the most trouble I've had with it. I'm currently trying to build media-tv/mythtv-0.27_p20140321. I've been running this version for about a year and a half, and the only surprise it had was if you tried to watch something while you were already recording it, you would wind up with a garbage media file which wouldn't play. There was a patch for this and it's run great since.

My only reason for doing this again, is that I'm moving my backend to another box. The current working one is being retired, and no specific timeline involved. I have three diskless boot front ends running minimyth, and gentoo for my backend server. This time, I'm trying to move to ZFS on my backend, to hopefully never deal with upgrading again (famous last words...)

Are you running media-tv/mythtv-0.27.5_p20151025 ? Does it appear to work reliably?
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Wed Jan 27, 2016 4:27 pm    Post subject: Reply with quote

wankykootiepooper wrote:
I've been running this version for about a year and a half, and the only surprise it had was if you tried to watch something while you were already recording it, you would wind up with a garbage media file which wouldn't play. There was a patch for this and it's run great since.


Well, thanks to football delaying the start of X-Files on Sunday, I was watching LiveTV and recording at the same time and the recording wasn't garbled. I also have watched the same recording while watching it a week and a half ago, but I don't remember what it was, and the recording wasn't affected on P20151025.

wankykootiepooper wrote:

Are you running media-tv/mythtv-0.27.5_p20151025 ? Does it appear to work reliably?


So far, I've had zero issues with it. My setup includes a backend with 4 tuners (which is always running on my home server) with tons of storage. I also have 5 remote frontends. I use it daily, and I upgraded Jan 2. I have had 3 recordings at the same time with no issues, no issues with LiveTV, and no issues with recordings or their playback. It's recording 20+ shows since the upgrade too. I've also set up new series recordings (and they did record) so it all appears to work. Seems to be reliable to me. I should probably file a bug requesting stabilization.
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Fri Feb 05, 2016 2:38 am    Post subject: Reply with quote

Last week I finally decided to go ahead with danomac's suggestion of attempting to compile a newer version of MythTV. So I ran the command echo "<media-tv/mythtv-0.28 ~amd64" >> /etc/portage/package.keywords/mythtv, which didn't work. I'm not sure why my system is configured in a different way than this command presumes, but on checking I discovered that there is no /etc/portage/package.keywords/ directory or file on this system. The closest thing I managed to find was the file /etc/portage/package.keywords_accept, so I decided to echo the specified line into that file.

On subsequently running emerge -pv mythtv further problems arose: the system was wanting to install a newer version of MythTV alongside the old one. I assumed this was because I must have specified in some file that a particular version of MythTV was to be installed on this system. I rooted around a bit to discover where that stipulation might have been made and tried a few more experiments. I was unable, before I needed to set the project aside, to determine what the problem was, so I undid the changes I'd made to /etc/portage/package.keywords_accept and other files, with the intention of later getting back to this issue.

Fast forward to this week when, a couple of days ago, an automated process that runs emerge --update --deep --keep-going --ask @world was triggered. There were a couple of errors in the output involving libva and opengl and relevant flags; I managed to resolve those errors. But I was surprised to see, once I'd resolved those issues, that media-tv/mythtv-0.27.5_p20151025 was due to be installed and, furthermore, that there were no apparent issues or conflicts to resolve before the system would compile it.

Prior to going ahead with the planned update/upgrade, I'd just like to ask for some explanation of what I am seeing here. My guess is that, since I undid changes to /etc/portage/package.keywords_accept that would have brought in a newer version of MythTV, this particular newer version must have, in the interim, been marked as stable. Could this, then, be the reason why this newer version of MythTV is now due to be installed on my system?
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Fri Feb 05, 2016 3:26 am    Post subject: Reply with quote

jamtat wrote:
Last week I finally decided to go ahead with danomac's suggestion of attempting to compile a newer version of MythTV. So I ran the command echo "<media-tv/mythtv-0.28 ~amd64" >> /etc/portage/package.keywords/mythtv, which didn't work. I'm not sure why my system is configured in a different way than this command presumes, but on checking I discovered that there is no /etc/portage/package.keywords/ directory or file on this system. The closest thing I managed to find was the file /etc/portage/package.keywords_accept, so I decided to echo the specified line into that file.


Older installations had /etc/portage/package.keywords as a file. Newer stage3 starter tarballs on gentoo.org use it as a directory. I didn't even know package.accept_keywords (according to the wiki) existed until now - I've always used package.keywords as a file.

jamtat wrote:

On subsequently running emerge -pv mythtv further problems arose: the system was wanting to install a newer version of MythTV alongside the old one. I assumed this was because I must have specified in some file that a particular version of MythTV was to be installed on this system. I rooted around a bit to discover where that stipulation might have been made and tried a few more experiments. I was unable, before I needed to set the project aside, to determine what the problem was, so I undid the changes I'd made to /etc/portage/package.keywords_accept and other files, with the intention of later getting back to this issue.


Without seeing the results of `emerge -pv mythtv` I really can't comment on this one. There was a conflict between mythtv's plugins and mythtv on specific versions, and I'm wondering if you hit that.

jamtat wrote:

Fast forward to this week when, a couple of days ago, an automated process that runs emerge --update --deep --keep-going --ask @world was triggered. There were a couple of errors in the output involving libva and opengl and relevant flags; I managed to resolve those errors. But I was surprised to see, once I'd resolved those issues, that media-tv/mythtv-0.27.5_p20151025 was due to be installed and, furthermore, that there were no apparent issues or conflicts to resolve before the system would compile it.

Prior to going ahead with the planned update/upgrade, I'd just like to ask for some explanation of what I am seeing here. My guess is that, since I undid changes to /etc/portage/package.keywords_accept that would have brought in a newer version of MythTV, this particular newer version must have, in the interim, been marked as stable. Could this, then, be the reason why this newer version of MythTV is now due to be installed on my system?


Yes, I noticed last weekend it was stabilized. That's why it wants to install the most recent version on your system. This is the version that has the gcc build errors fixed.

By the way, you can use `eshowkw <package>` to show package keyword information (the '~' is unstable/testing, '+' is stable, and 'o' is not available):

Code:

$ eshowkw mythtv
Keywords for media-tv/mythtv:
                       |                                 | u                    | 
                       | a a   a         n   p r     s   | n                    | 
                       | l m   r h i m m i   p i s   p   | u s                  | r
                       | p d a m p a 6 i o p c s 3   a x | s l                  | e
                       | h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | e o                  | p
                       | a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | d t                  | o
-----------------------+---------------------------------+----------------------+-------
   0.26.0_p20130922    | o + o o o o o o o o o o o o o + | # 0                  | gentoo
     0.27_p20140321    | o + o o o o o o o o o o o o o + | o                    | gentoo
   0.27.5_p20150627    | o ~ o o o o o o o o o o o o o ~ | #                    | gentoo
   0.27.5_p20150904-r1 | o ~ o o o o o o o o o o o o o ~ | o                    | gentoo
-----------------------+---------------------------------+----------------------+-------
   0.27.5_p20150904-r2 | o ~ o o o o o o o o o o o o o ~ | o 0/0.27.5_p20150904 | gentoo
-----------------------+---------------------------------+----------------------+-------
[I]0.27.5_p20151025    | o + o o o o o o o o o o o o o ~ | o 0/0.27.5_p20151025 | gentoo


Hmm, looks like amd64 was stabilized, but not x86.
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Fri Feb 05, 2016 5:16 am    Post subject: Reply with quote

Thanks for continuing to offer support and further tips, danomac. I thought I'd be able to get back sooner to troubleshooting the errors I was confronted with last week, so I didn't bother to document the error messages. But it took longer than I'd hoped and I ended up forgetting exactly what they were about. But it does sound as though it may have been the plugins conflict to which you've referred.

I've gone ahead and tried to run emerge --update --deep --keep-going --ask @world but am running into errors connected with opengl and the X flag, as follows:
Code:
emerge --update --deep --keep-going --ask @world

These are the packages that would be merged, in order:

Calculating dependencies |

!!! Problem resolving dependencies for x11-libs/libva from @selected
... done!

!!! The ebuild selected to satisfy "x11-libs/libva" has unmet requirements.
- x11-libs/libva-1.6.2::gentoo USE="drm opengl -X -egl -vdpau -wayland" VIDEO_CARDS="dummy intel -fglrx -nouveau -nvidia"

  The following REQUIRED_USE flag constraints are unsatisfied:
    opengl? ( X )

  The above constraints are a subset of the following complete expression:
    any-of ( drm wayland X ) opengl? ( X )

(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

I'd enabled the opengl flag globally, which may have been a mistake. I see earlier in this thread that you'd advised compiling x11-libs/libva with opengl support, which does not, I believe, require that the flag be set globally. So maybe I need to backtrack on that? Further input will be appreciated.
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Fri Feb 05, 2016 5:22 am    Post subject: Reply with quote

jamtat wrote:
Thanks for continuing to offer support and further tips, danomac. I thought I'd be able to get back sooner to troubleshooting the errors I was confronted with last week, so I didn't bother to document the error messages. But it took longer than I'd hoped and I ended up forgetting exactly what they were about. But it does sound as though it may have been the plugins conflict to which you've referred.

I've gone ahead and tried to run emerge --update --deep --keep-going --ask @world but am running into errors connected with opengl and the X flag, as follows:
Code:
emerge --update --deep --keep-going --ask @world

These are the packages that would be merged, in order:

Calculating dependencies |

!!! Problem resolving dependencies for x11-libs/libva from @selected
... done!

!!! The ebuild selected to satisfy "x11-libs/libva" has unmet requirements.
- x11-libs/libva-1.6.2::gentoo USE="drm opengl -X -egl -vdpau -wayland" VIDEO_CARDS="dummy intel -fglrx -nouveau -nvidia"

  The following REQUIRED_USE flag constraints are unsatisfied:
    opengl? ( X )

  The above constraints are a subset of the following complete expression:
    any-of ( drm wayland X ) opengl? ( X )

(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

I'd enabled the opengl flag globally, which may have been a mistake. I see earlier in this thread that you'd advised compiling x11-libs/libva with opengl support, which does not, I believe, require that the flag be set globally. So maybe I need to backtrack on that? Further input will be appreciated.


Hmm. In portage's roundabout way, it is saying the opengl flag requires the X USE-flag to be set. I'd set the X USE-flag globally in /etc/portage/make.conf, then run `emerge -auDN world` and rebuild the affected packages.


Last edited by danomac on Fri Feb 05, 2016 7:20 pm; edited 1 time in total
Back to top
View user's profile Send private message
wankykootiepooper
n00b
n00b


Joined: 26 Jan 2016
Posts: 4
Location: Calgary, Alberta, Canada

PostPosted: Fri Feb 05, 2016 5:23 am    Post subject: Reply with quote

Guys,

I compiled media-tv/mythtv-0.27.5_p20151025 last weekend, and it is well behaved. No special effort required.

Eric.
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Fri Feb 05, 2016 5:24 am    Post subject: Reply with quote

wankykootiepooper wrote:
Guys,

I compiled media-tv/mythtv-0.27.5_p20151025 last weekend, and it is well behaved. No special effort required.

Eric.


jamtat is using a nomultilib profile. A little more work to set up... :wink:
Back to top
View user's profile Send private message
wankykootiepooper
n00b
n00b


Joined: 26 Jan 2016
Posts: 4
Location: Calgary, Alberta, Canada

PostPosted: Fri Feb 05, 2016 5:31 am    Post subject: Reply with quote

Jamtat,

Danomac is absolutely correct. You need X. It doesn't have to run at all for a backend, except when you need to run mythtv-setup. But it has to be there for you to setup the system.

Keep at it!
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Fri Feb 05, 2016 5:45 am    Post subject: Reply with quote

danomac wrote:
In portage's roundabout way, it is saying the opengl flag requires the X USE-flag to be set. I'd set the X USE-flag globally in /etc/portage/make.conf, then run `emerge - auDN world` and rebuild the affected packages.

Thanks for the explanation and tip. The process has now been initiated. I guess my thinking in not setting that flag globally when I set up this system was that I feared setting it might cause a lot of extraneous desktop stuff to get dragged in, whereas I wanted this to be a lean, mean MythTV runnin' machine. I was, as with a lot of other things regarding this installation, probably mistaken about the implications of setting the X flag globally.
Back to top
View user's profile Send private message
jamtat
Apprentice
Apprentice


Joined: 09 Aug 2003
Posts: 162

PostPosted: Fri Feb 05, 2016 3:59 pm    Post subject: Reply with quote

Finally, success. I set the X flag globally and ran emerge - auDN world. Everything compiled without errors. After rebooting I tested MythTV and I can now select and use the vaapi playback profile which, up to now, has never worked right for me. Thanks so much for all the help!

Just a couple of further questions. I keep pulling in kernel sources when I do these updates/upgrades. While I may well need these at some future point, my aim at this point is to defer compiling any new kernel for as long as possible--like maybe only when/if some major security flaw in my existing kernel (3.18.7) gets exposed. So, what I'd rather do instead of pulling in new kernel sources when I do my monthly update/upgrade, is to only pull in those sources when I might actually be intending to use them. Sort of on-demand, rather than automatic. How can I configure the system to do that?

Finally, is it merely coincidence that the version of MythTV that went stable for the no-multilib profile in the last few weeks is the very same version we've been discussing in this thread over the last few weeks as having compilation issues with the new stable version of gcc? I mean, like, did some higher-up note this discussion and say "hey, we really should stabilize a version of mythtv that compiles with this newly-stabilized gcc we've got now"? Or are these seemingly-related developments just coincidence?
Back to top
View user's profile Send private message
wankykootiepooper
n00b
n00b


Joined: 26 Jan 2016
Posts: 4
Location: Calgary, Alberta, Canada

PostPosted: Fri Feb 05, 2016 4:39 pm    Post subject: Reply with quote

Portage has a mask function. Be careful to think of this file as more of a "here is what I DON'T want" definition. This confuses some people:

https://wiki.gentoo.org/wiki//etc/portage/package.mask

You can set what kernel version you want to keep.

In my experience, and mythtv setup should only be upgraded when you have a very good reason to. I've built 7 of these now, going on to number 8, and there are a lot of moving parts in this. I use a netboot front end called minimyth2 in 3 places in my house, and mythtv has been a fixture at our place for over 10 years. It's had to disrupt the families viewing times, so when I feel the need to upgrade, I usually do it using a virtualbox or a separate server.

That being said, it is one of the best projects you could ask for to teach you about linux and gentoo.

Enjoy the voyage...
Back to top
View user's profile Send private message
danomac
l33t
l33t


Joined: 06 Nov 2004
Posts: 881
Location: Vancouver, BC

PostPosted: Fri Feb 05, 2016 6:54 pm    Post subject: Reply with quote

jamtat wrote:
Thanks for the explanation and tip. The process has now been initiated. I guess my thinking in not setting that flag globally when I set up this system was that I feared setting it might cause a lot of extraneous desktop stuff to get dragged in, whereas I wanted this to be a lean, mean MythTV runnin' machine. I was, as with a lot of other things regarding this installation, probably mistaken about the implications of setting the X flag globally.


The X flag compiles optional support for packages to use/communicate with the X server. In this case it makes total sense that opengl requires X support. The various desktops have their own USE-flags (like the kde and gnome USE-flags, to name two) that will pull in a lot of extra "desktop crap" that you're thinking of. :wink:

jamtat wrote:
Finally, success. I set the X flag globally and ran emerge - auDN world. Everything compiled without errors. After rebooting I tested MythTV and I can now select and use the vaapi playback profile which, up to now, has never worked right for me. Thanks so much for all the help!


That's great news! All it took was a bit of patience and the time it took for someone to notice he forgot responding to a thread (ahem, me :oops: )...

jamtat wrote:

Just a couple of further questions. I keep pulling in kernel sources when I do these updates/upgrades. While I may well need these at some future point, my aim at this point is to defer compiling any new kernel for as long as possible--like maybe only when/if some major security flaw in my existing kernel (3.18.7) gets exposed. So, what I'd rather do instead of pulling in new kernel sources when I do my monthly update/upgrade, is to only pull in those sources when I might actually be intending to use them. Sort of on-demand, rather than automatic. How can I configure the system to do that?


As wankykootiepooper suggested, you can mask these updates. This will prevent portage from pulling them in. However, it's only installing the sources - it won't build a new kernel until you tell it to.

There's really no right or wrong way to deal with this - just be aware that running `emerge --depclean` can remove kernel sources, including the sources for the kernel in use. As I mentioned earlier, I have a bunch of mythtv "appliances" which I only update periodically, and here's how I deal with it (I use sys-kernel/gentoo-sources, you can swap the examples for whatever you're using):

1. I let portage pull in new kernel sources all the time. I don't bother to mask them, as --depclean removes them eventually. If you have a slow speed connection, you may want to mask them as mentioned earlier. I'm currently on sys-kernel/gentoo-sources-4.1.12, so you could mask newer versions by doing

Code:

$ echo ">sys-kernel/gentoo-sources-4.1.12" >> /etc/portage/package.mask


for package.mask as a file, OR

Code:

$ echo ">sys-kernel/gentoo-sources-4.1.12" >> /etc/portage/package.mask/gentoo-sources


for package.mask as a directory.

2. You need to protect the sources for the kernel in use. The reason for this is that some versions can get pulled from the tree, and if you `emerge --depclean` and remove them you won't be able to reinstall the sources to make changes to your kernel. Now, the kernel sources are all SLOT-ed. If you look at what I have installed:

Code:

$ equery list gentoo-sources
 * Searching for gentoo-sources ...
[IP-] [  ] sys-kernel/gentoo-sources-4.1.12:4.1.12


See after the full colon, the 4.1.12? That's the SLOT that the package has been assigned. By using package 'slots' you can install different versions of the same package at the same time. Which makes sense for things like kernel sources.

Anyway, to protect the sources for my currently running kernel, all you have to do is this:

Code:

$ emerge --noreplace sys-kernel/gentoo-sources:4.1.12


Portage will keep that version around, and if you run `emerge --depclean` that version will show as "protected" and it won't be removed.

3. At some point you'll want to roll a new kernel version. So portage will pull in a new version, you'll build and boot from that version. So now what? You have to protect that new version (step 2, above) then you'll want to tell portage you don't need to keep the old version around anymore. All you have to do is tell portage:

Code:

$ emerge --deselect sys-kernel/gentoo-sources:4.1.12


Portage will remove its protection, and the next time you do `emerge --depclean` the sources for 4.1.12 will be removed. Note: This only removes the sources, it won't remove the actual compiled kernel.

So that's the way I deal with it. I'm sure there are other ways, but this one works for me, as when you once protect something, it stays put until you tell it otherwise.


jamtat wrote:

Finally, is it merely coincidence that the version of MythTV that went stable for the no-multilib profile in the last few weeks is the very same version we've been discussing in this thread over the last few weeks as having compilation issues with the new stable version of gcc? I mean, like, did some higher-up note this discussion and say "hey, we really should stabilize a version of mythtv that compiles with this newly-stabilized gcc we've got now"? Or are these seemingly-related developments just coincidence?


Well, it could be coincidence, or not. :lol: There are a lot of gentoo devs that peruse the forums, and some even post here. So it's not outside the realm of possibility that one of the devs noticed. Or maybe someone filed a bug? As I said in an earlier post it's not always necessarily automatic. In this case, it looks like a bug was filed.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Multimedia All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum