
jrw3319 at gmail
Oct 23, 2009, 5:48 AM
Post #9 of 9
(1148 views)
Permalink
|
First, thanks to everyone who responded. All the answers were helpful. On Thu, Oct 22, 2009 at 10:51 PM, Axel Thimm <Axel.Thimm [at] atrpms> wrote: > Hi, > > On Tue, Oct 20, 2009 at 03:00:49PM -0400, John Welch wrote: >> 2) libmyth Packages - On my MythTV back-end system I had installed the >> 'bijou' packages for the HDHR multi-rec capabilities. Because the >> 'regular' 0.21 packages in the stable repo eventually superseded the >> 'bijou' packages I had been blocking 'yum' from upgraded the MythTV >> packages on this system. I thought this would be taken care of when I >> upgraded to 0.22, but when I went to install the 0.22 packages yum >> still wanted to install the latest 0.21 'libmyth' packages. I blocked >> these packages and upgraded to 0.22 without any issues (at least none >> that I am aware of yet), however now even when I run a regular 'yum >> update' on this system it still wants to install/upgrade the 0.21 >> 'libmyth' packages. Any one have any ideas what's going on here? > > This sounds like what you asked yum to do: You locked the version of > some packages to a specfic one and yum tries to fulfill your wish :) > > Just remove any locking/filtering etc. and yum will behave normaly again. I never specifically "locked" the MythTV packages using yum configuration. After the 'bijou' updates stopped being in sync with the stable MythTV packages I just ran yum using the "--exclude=\*myth\*" option. I guess I was surprised to see that even after I updated to the 0.22 packages and stopped using any exclude options yum still wanted to "upgrade" libmyth packages from the 0.21 series. Additionally, on another system where I never had the 'bijou' packages installed and never did any command line excludes the 0.21 libmyth packages showed up as upgrades when I enabled the 'testing' repo in order to upgrade to 0.22. On both systems I decided to just let yum do it's thing. The 0.21 packages were installed and I haven't noticed any issues so far. > >> 3) Latest NVidia Packages - Not specifically a MythTV 0.22 question, >> but somewhat related, especially with regards to VDPAU. I'm having >> problems figuring out what the latest NVidia packages are currently >> available through ATrpms. > > Just install nvidia-graphics. > > Other than that all nvidia packages that build are there. > >> So, if I want the "latest and greatest" packages >> which ones should I be using? > > "Latest & greatest" and stable: Use nvidia-graphics. > > "Latest & greatest" and beta: Use nvidia-graphics with > testing/bleeding turned on. > Simply running 'yum install nvidia-graphics' doesn't seem to work for me anymore. I'm sure it is something I've messed up because I switched back and forth between using the official NVidia installer and the ATrpms packages. I have also manually installed some of your packages by downloading them and using rpm to install. >> Am I just being too impatient on the 190.40 packages? Actually, I guess I was just impatient because I now see that the 190.40 packages are in the repo. Of course now 190.42 is the latest RC from NVidia :) > > It depends - if this is a production system, then don't use beta > drivers. Otherwise if this is for experimenting with 0.22 as a tech > preview on one of your systems you can keep testing/bleeding enables > 24/7 - and while on the experimental side, you could even go F12 - > there are packages for F12 at ATrpms now as well, including beta 0.22 > and beta nvidia drivers to maximize the betas in the equations. :) > > (Actually I'd love if there were people willing to test all the betas > and would find out that most of it is already working). I don't really consider any of my home systems to be "production" systems. I wouldn't be too happy if I was without the use of MythTV for too long, but my thinking is if I do the proper planning and take the necessary precautions (backups, etc.) there isn't any reason I shouldn't be able to go backwards if an upgrade goes wrong. That said, I wouldn't want to run any software where serious issues and bugs are known to exist (not just with ATrpms packages, but in general). > -- > Axel.Thimm at ATrpms.net > Thanks again, John _______________________________________________ atrpms-users mailing list atrpms-users [at] atrpms http://lists.atrpms.net/mailman/listinfo/atrpms-users
|