New ebuild for MythTV, a very nice suite to watch, record and archive shows from analog sources. It's not very well tested, indeed I still have a problem with the MySQL database. Furthermore, one of the dependencies is xmltv, which I commit on another bug. Xmltv is a backend to grab programming info in xmltv format for mythtv to use. I have just finished the ebuild for it, a few things sure need polishing. But most important is that I can't really test its funcionality since I couldn't find any provider with Spanish TV listings in xmltv format at the moment. Any help and testing from people from the US, UK, Germany or any other directly supported country would be nice :)
Created attachment 5541 [details] mythtv ebuild, place under media-video
I see the name's been lost in the attachment. It's mythtv-0.7.ebuild
Nice, I was working on a ebuild for 0.6 a few days ago, but didn't finish. You going to make ones for MythMusic and the others?
I get this when its installing: make[1]: Entering directory `/var/tmp/portage/mythtv-0.7/work/mythtv-0.7/themes' cp -f -pR "blue" "/var/tmp/portage/mythtv-0.7/image//usr/share/mythtv/themes/" strip "/var/tmp/portage/mythtv-0.7/image//usr/share/mythtv/themes/" strip: /var/tmp/portage/mythtv-0.7/image//usr/share/mythtv/themes/: Is a directory make[1]: *** [install_themes] Error 1 make[1]: Leaving directory `/var/tmp/portage/mythtv-0.7/work/mythtv-0.7/themes' It continues on, and the ebuild finished, but it doesn't install the rest of the themes directory. If I remove lines 122, 124, 126, and 128 from themes/Makefile it installs properly. And instead of putting setup in /usr/share/mythtv, would putting it in /usr/bin/ with the rest of the executibles be better? It could be called mythsetup.
Thanks for the ebuild! I haven't tested it yet, but I saw that some dependancies were missing when reading the ebuild... You should also depend on: media-libs/flac media-libs/libvorbis media-libs/libcdaudio media-sound/cdparanoia media-sound/mad
Please grab the updated and fixed xmltv ebuild, which should fix some problems within MythTV. As I said on bug #10536, it seems to work now but I haven't found xmltv info providers of Spanish TV channels. Also MythTV works better with a computer for its own, which I do not have now. I wanted to use as I do with VDR (for DigitalVideoBroadcasting TV), which lets you use it as a a daemon in the background while you continue to use the computer. MythTV is also quite slow for that, as some Gentoo users told me by e-mail. There's at least one other project going on with which you can use the dual-head cappability of at least the Matrox G400, so that you have in the first head your desktop, and on the second head, the TV output. It doesn't let you record shows yet, though, and it's written in python which I don't know if it's somewhat slow for the task... Maybe the best route is finally integrating an analog_TV->PES to integrate in VDR.
Created attachment 6890 [details] mythtv-0.7.ebuild (updated) Added in dependency to dev-perl/xmltv
Created attachment 9860 [details] upgraded and cleaned mythtv ebuild (now with more fiber) This ebuild is an update to MythTV 0.8. This one also comes with an rc script for mythbackend (will be posted shortly). I also made ebuilds for MythGallery, MythMusic, and MythWeather which I'll post as separate bugs. (I'm still working on MythVideo, MythGame, and MythWeb).
Created attachment 9861 [details] rc script for mythbackend Place this in mythtv/files for the ebuild to work (ebuild installs this as /etc/init.d/mythbackend). This also has an optional conf file which goes into /etc/conf.d (see below).
Created attachment 9862 [details] mythbackend conf file for the rc script
man, just when I go and make ebuilds for myth* someone beats me to it by a few hours. This happened for the last 2 releases too. Oh well...I have a cron script that I wrote that you can add to you ebuild to update the db, I'll attach it.
Created attachment 9886 [details] mythdbupdate.cron pretty simple cron job. Prob put in cron.weekly since it pulls a weeks worth of listings.
I'd like to help in the bug squashing process but when i do an 'emerge -s myth' i get nothing. accept keywords are x86. am i doing something wrong? (yes, i've emerge sycned within the last 5 minutes)
added MythGame bug 18276 and MythVideo bug 18275. to comment 13: these ebuilds aren't in portage yet, so you have to download the attatchments and put them in your portage dir or portage overlay dir manualy. When they do make it into portage they will probably be ~x86 for a while too.
oh and while I'm thinking about this...perhaps /usr/share isn't the best place for the config files for myth* since theres no config protection there, and config files are usualy in /etc. I thought of this cuz all the installing and reinstalling of the different ebuilds clobbered my configs.
I think mythtv will only look in /usr/share or $home for config files. $home over rides the ones is /usr/share. It may be good to run mythbackend as user mythtv and drop the config files in the /home/mythtv. This probabley is also more secure. Thanks for the help guys, I've been kinda busy lately.
Sorry, haven't checked my email in a few hours, so I'm going to reply to all the things posted in the meantime... Regarding the cronjob: I don't know if it is such a hot idea to add the cron script during the ebuild because if you're installing for the first time, you don't have a database yet (and may not have one for a while). How about a note in pkg_postinstall() that tells the user to copy /usr/share/mythtv/mythfilldatabase to /etc/cron.weekly? Aside from this, I think the script should look like this: #!/bin/bash QTDIR=/usr/qt/3 /usr/bin/mythfilldatabase --quiet Reguarding running as mythtv user: I'm all for this and actually thought of this as well. I first wanted to get the new ebuilds done. I'll look to adding runas support. Thanks for reminding me!
oh ya thats a good point about the cronjob. a pkg_postinstall() would be a good idea.
Created attachment 9958 [details] new new ebuild changes: 1) creates /var/{log,run}/mythtv and set nobody:nobody ownership 2) mythbackend now starts as nobody (may want to make this configurable in the future 3) comes with a working example mythfilldatabase.cron script and a suggestion in pkg_postinstall() as to where to copy it it
Created attachment 9959 [details] updated rc script now starts as nobody:nobody
Created attachment 9960 [details] updated conf file defaults log/pid to /var/log/mythtv and /var/run/mythtv respectively
Created attachment 9961 [details] example cron script needed for the ebuild
one note that probably needs to be added somewhere about running mythbackend as nobody: *the nobody user needs to be added to the audio and video groups*
Created attachment 10172 [details] a more flexible backend rc script ok here's another (and hopefully last) backend rc script with the following changes: 1) allow the start-as user to be configurable 2) change "need mysql" to "use mysql" so that database can be separated to a different machine (as I have it now for mythweb -- to be posted shortly)
Created attachment 10173 [details] updated conf file add a big fat note on permissions and allow perm warnings to be turned off
Will "need net" affect dialup users? I don't know know much about the "use" and "need", but you probabley should not force a dial up user to start his link. The link only needs to be up when the database is being updated.
I think _a_ network connection is pretty much required: what if the database is on a different machine? what if the backend machine is a standalone master that frontends need to connect to? Besides, I think with RC_NET_STRICT_CHECKING="no" being the default in /etc/conf.d/rc any network interface being up will satisfy this depend. Also, mysql itself has a "need net", so if you have the database on the same machine, networking will be started for you, otherwise you will _have_ to have networking enabled to allow the backend connect to the db.
I don't actually all the init dependency checking. I had a flaky dhcp server which 2 out of 3 times would fail to give me a lease. I had to manually start all the services once I got the lease. Just my experience no big deal. Maybe zapping the log everytime it is started could be made optional. Probably you shouldn't normally zap the log on startup but then in this case there is not a lot of usefull info logged anyway. The other thing is an ebuild is meant to run and install. Any setup needs to be done after installation and not part of the ebuild process. I don't think we are allowed to do this in and ebuild doexe "${S}/setup/setup"
the problem is that mythbackend puts some really funky permissions on the log file (i.e. doesn't make it writeable) when it first creates it. so that the next time you go to start it, it fails with "can't open log file" error. this just works around that. with regards to "doexe ${S}/setup/setup".... I think we're on a different page with this. doexe doesn't actually run it -- it installs it and sets proper permissions. from ebuild(5): doexe <executable> [list of more executables] Installs a executable or a list of executable into EXEDESTTREE. This function uses install(1).
I have had a lot of trouble with the rc-script, it doesn't seem to launch mythbackend on my machine. After a reboot I manually have to start it. It thinks it is started since it I try to stop it, it complains with an error "start-stop-daemon: warning: failed to kill 3357: no such process". Other than that, ebuild and conf file worked ok. When nobody was created it wasn't put into groups audio or video, I don't know if that was a feature or a bug. Could all of the setup be added to the ebuild as "ebuild mythtv.ebuild config". The other problem I had and I don't know if this could/should be added anywhere, I had old permissions lying around that I needed to wipe out before I could run it, none of the config for mysql would take care of it and I thought it could be added here to avoid confusion.
If mythbackend seg faults you will get the problem you describe. You can reset things by doing /etc/init.d/mythbackend zap. rc-update add mythbackend default should make it start automatically at boot. There are different ways you can run mythbackend. Some people may not want to run it as a daemon and in that case there is no need to modify the group file. Maybe a use flag to indicate you want to run as a daemon and modify the group file could be a way to go. It can wait anyway, I would rather get some feedback on whats holding this back from being in portage. I have YAPLPT to maintain until then. YALPT=Yet Another Public Local Portage Tree :)
Created attachment 13028 [details] media-video/mythtv-0.9.ebuild Bumped version and (cleaned to a bright shine) the mythtv ebuild.
Created attachment 13029 [details] mythtv/ChangeLog Initial changelog for the mythtv ebuild (currently only shows entries for versions 0.8 and 0.9).
Created attachment 13036 [details] media-video/mythtv-0.9.ebuild i will test *thoroughly* before posting ... i will test *thoroughly* before posting ... i will test *thoroughly* before posting ... i will test *thoroughly* before posting ... ... install mysql.txt config file *CORRECTLY*
the currently posted 0.9 ebuild will upgrade just fine if copied to mythtv-0.9.1.ebuild therefore, I won't post a new version just yet.
Upgrading mysql database with 0-8-to-0-9.sql probabley needs to be taken care of now. Maybe done automatically with a local use flag. ie "use=mythtvBackEnd" emerge mythtv or maybe if the "mysql" flag is present just do it. I guess the local use flag is better as you need to have "mysql" set even if there is no mysql on the box to build the qt plugin.
Sorry, but I have to strongly disagree. Aside from all the security implications, I wouldn't feel comfortable doing (or even allowing someone to do) a production db upgrade without first reviewing the contents of the upgrade and not giving a chance to backup the current contents of the db. This also becomes especially problematic if someone has multiple backend/frontend machines that point to the same db. Granted one can argue that the local use flag should be used to prevent the db upgrade from happening more than once, but that is not sufficient: what if you install the same version more than once on the same machine? The potential for running amock is far to great. (I'll stop ranting now -- sorry) :-) I think a note during pkg_postinst() about how to upgrade the db should suffice. Or maybe even leaving the note as is because it points the user to the UPGRADING doc which explains what to do.
Yeah, I know what you mean, but the simple fact is the thing is going to very broken without the DB upgrade. I guess in a sense it doesn't matter as the devs haven't put mythtv into portage yet, despite indications that it was next kid off the block. I am now pretty pissed off with the treatment this project is getting from devs and will upgrade the local portage tree with some sort of DB upgrade, maybe as a separate script that can be run if the user desires, he has too really for the system to continue working correctly.
hi, listen I am sorry for the delays in this. I have hesitated because I can not test this at all. I am trying to find a dev who is willing to handle this
Jeremy Johnson had an idea (off list) to use pkg_config() as a means of upgrading the db. This is a nice clean way of handling such a thing. What do you all think? Basically, it would include a pkg_postinst() message like: If you need to update your database please run: ebuild /var/db/pkg/${CATEGORY}/${PF}/${PF}.ebuild config This can be done for all myth projects that need a db upgrade. Of course special care has to be given to mythmusic (bug 18254) because it requires a tweak to the upgrade sql script.
I'm all for the config idea
Technically mysql doesnt need to be a dependancy. MythTv will work as long as it can access mysql, it doesnt have to be on the same machine. Maybe a local use flag should be used to control if mysql is to be compiled on the local machine.
mysql needs to be installed on the machine when you build QT otherwise the mysql_qt plugin doesn't get built, which is needed. Is there is a way around this let?
Yes, mysql isn't technically needed for mythtv itself, but, like Tony said, it _is_ needed for QT, so this dependency doesn't really hurt. It can certainly be removed as well -- I can go either way. as far as automatic db updating goes...I thought about this some more and I have to say that I'm leaning more and more toward leaving it as is. There are just too many questions with too many answers that can potentially break things far worse then leaving the database un-upgraded: - is this a new installation or an upgrade? - if it is an upgrade, what was the previous version? - if it is new, the proper install script needs to be run which requires mysql root privileges (to create the db and user/pass) Aside from this, I saw a change going into mythtv that tag the database with a version which the binaries check against their own version and if the two mis-match, the binary will exit with an error. This is enough to prevent running mythtv with an un-upgraded db and will quickly let the user know that something needs to be done. I'm pretty sure this feature made it into the 0.9 release (could be wrong though).
Created attachment 13250 [details] media-video/mythtv-0.9.1.ebuild from the changelog (will be posted shortly): Bump to 0.9.1. Drop the sed fix for config file in /etc/mythtv and use a patch instead which also fixes another file. This allows mythgallery to show up on the main mythfrontend screen.
Created attachment 13251 [details] mythtv/files/mythtv-gentoo.patch the patch mentioned in the above attachment.
Created attachment 13252 [details] mythtv/ChangeLog and the most recent ChangeLog
The latest ebuild does not work for me. The patch did not work and the build failed. Both hunks failed on the patching.
could you please post the log epatch produced, your emerge --info output and the actual error you got from the ebuild? it'll help track this down. thanks.
It worked ok for me. Did you install the patch file in the right place? /your_portage_local/media-video/mythtv/files
The rc mythbackend script hangs for me. ewarn "" produces a yellow "*" and then hangs. Removing the line works fine.
Scenairo: mythbackend is configured for user nobody and is in group video. mythbackend starts fine on boot, and waits to record before accessing /dev/v4l/*. User logs in with gdm as some other user. gdm chowns /dev/v4l/* to the user and chmods /dev/v4l/* to 0600. When mythbackend tries to access the device it fails, because group permissions are no longer sufficent. In pariticular, gdm will change /dev/v4l/* ownership to user and chmod to 0600 on login if it is not already owned by the user. On logout, it will change group to sys. The group should become video.
You should probably disable pam_console support in devfsd.conf so that permissions of your devices don't change whenever someone logs on. look for these lines in /etc/devfsd.conf # Uncomment this to let PAM manage devfs REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so pam_console_apply_single $devpath Aside from this, I already have an outstanding bug about the inconsistancies in default console.perms file (bug #18599). I have yet to post a patch though -- been busy with other things.
Created attachment 13438 [details] mythtv/files/mythfilldatabase.cron here's a new example cron script that uses new parameters (--no-delete and --update) for mythfilldatabase.
Created attachment 13476 [details] media-tv/mythtv/mythtv-0.9.1-r1.ebuild updated to move to media-tv
Created attachment 13477 [details] Changelog
Created attachment 13503 [details] media-tv/mythtv-0.9.1-r2.ebuild Just a bump with a smaller DEPEND list -- no dev-db/mysql (there might be a future version of mythtv that is backend independant. i.e. whatever is supported by QT). Also this moves it to media-tv.
Created attachment 13504 [details] ChangeLog Document the DEPEND reduction and the category change.
I don't agree with the last change. While it's true it is not dependant on a running local version of mysql, it is dependant on mysql running somewhere. It is also dependant on having QT built with mysql support. Maybe a use flag to enable/disable it locally. The other thing is if your installing from scratch if you don't have mysql dependant here and the USE="mysql" isn't set, it won't work AFAIK. What would be nice is if we could build the mysql-qt plugin here rather than have to rebuild QT.
detecting mysql support really should be the function of the upstream package build process, but until that is in place we can try this: if [ ! -e "${QTDIR}/plugins/sqldrivers/libqsqlmysql.so" ] during the unpack stage and die out with a note if true. I'm mildly against this because, as I said, mythtv can potentially be made to work with different backends. And AFAIK, there's no simple way to build just the mysql plugin. Opinions?
There is no upstream package that is dependant on mysql, which is the problem really. mythtv is dependant on QT being built with mysql support. QT doesn't give a damm. We could add an ewarn at the end of the build or do as you suggested, which I think is maybe better as they can rebuild QT in the same merge then.
*** Bug 23164 has been marked as a duplicate of this bug. ***
For those interested, I have new cvs ebuilds for the following ready: mythtv-cvs mythgallery-cvs mythgame-cvs mythmusic-cvs mythvideo-cvs mythweather-cvs mythweb-cvs I don't think I want to post all these ebuilds+changelogs to bugzilla, so if you want them get them from my local portage cvs tree. Instructions are located here: http://marc.theaimsgroup.com/?l=gentoo-dev&m=105648371100634&w=2 Please be aware that these are for *CVS*. Therefore at any given point, things may be broken. Also make sure you update your database accordingly. Have a look at http://www.mythtv.org/docs/mythtv-HOWTO-1.html before proceeding. Also, I haven't really done a great deal of .... what's that called? .... oh yes, *testing* on these. So feedback is greatly appreciated. Thank you.
max, did some testing of your cvs-ebuilds... two things: 1.) need to add a line that clears contents of /usr/local/include/mythtv/ if they exist in the main mythtv-cvs ebuild (will only affect upgrades) read this thread for info: http://www.gossamer-threads.com/perl/mailarc/gforum.cgi?post=68878;search_string=;guest=710915&t=search_engine#68878 2.) add a comment at the end of the main myth ebuild to remind people to edit the new files in /etc/conf.d otherwise if they reboot without doing it and have mythbackend already added to the default runlevel then they will hang on boot and have to boot to liveCD to fix it... (learned that one the hard way) other than those minor things it works great so far... i of course had to do some sql updates... one would require some prior knowledge of mythtv' motus operandi for releases unless the script did it... but i understand that its difficult to check the current status of the mysql database... although the login info needed could be found in the mysql.txt file... if that is found you could assume a previous version, just not know which one! Sean.
Hi. 1) I think it would be very inappropriate for an ebuild to touch files other than the ones it knows about. Since the ebuilds themselves don't put anything in /usr/local, clearing things from there is something best left to the user. 2) Hmm... I'm not sure that basic troubleshooting tips is also the right place for a postinst() message. There are many things one can do to prevent such things from happening -- (i.e. restart mythbackend before rebooting to see if it works). Of course things like this can happen to the best of us, but going to the livecd is also not the only way to fix it (what about booting to single-user mode? I've fixed many-a-problems with a simple -s as a kernel parameter). The real problem is why your mythbackend hung and why fixing /etc/conf.d would have any effect? If the permissions are wrong, it shouldn't have been able to start. Could you provide more information on this? This sounds similar to comment #52 -- can you try what I suggested in comment #53? As for the database updates between upgrades....Like I said in comment #44, there are too many questions. I tried to whip up a choice-based update procedure, but there are still some issues: - do you show all *.sql files or just *-to-*.sql files? - if all, then do you prevent user from running cvs.sql or mc.sql? - if not then why not just stick with a message urging user to upgrade db him/herself? - how do you take care of the situation in mythmusic where you have to change the sql file before running it? - if you allow the user to choose mc.sql, then you have to ask for the mysql root login and password. So I think these questions are outside the scope of the ebuild and should be left for the user to decide what to do. Hopefully the database schema changes will slow down in mythtv upstream development which will make this whole thing a non-issue.
Hello all. I committed the new mythtv (0.10) and xmltv (0.5.14) ebuilds to my local tree. There are some rather big changes upstream so be sure to check out www.mythtv.org for info. There are also some moderately big changes with the mythtv ebuild. Here's my change log: Bump version to 0.10. Drop all patches -- just move config to /etc/mythtv and link to /usr/share/mythtv. Change xmltv depend to >= 0.5.14. Move /usr/share/mythtv/setup to /usr/bin/mythsetup and add note on pkg_postinst(). Drop permission change of /var/{log,run}/mythtv -- do it as part of the rc script. Change startup script config file to start mythbackend as root -- will still warn about root not being part of the video group and gives the user an option to change to a non-root user; helps with hanging mythbackend on startup as reported on #10533. Add a note about the importance of upgrading the database. also: Fix up mythbackend start up script: reset permissions on pid and log directories, change MYTH_NOWARN to MYTH_WARN and reverse the functionality, other cleanups. Please let me know if you have any problems.
Hi Max, Can't seem to checkout portage from your cvs. tony@power cvs $ cvs -d :pserver:cvs@68.6.36.243:/home/cvs login Logging in to :pserver:cvs@68.6.36.243:2401/home/cvs CVS password: tony@power cvs $ cvs co portage cvs checkout: cannot find module `portage' - ignored
max, hmm... ok i agree with you on your second point... that was my fault for forgetting that i had an old script in there and not checking for the new file in conf.d for sure, the hang was caused by the fact that i had not edited the conf.d/mythbackend file... but i must stick with my guns on the first point. If it impairs my ability to compile the add-ons then it should be tossed, i could care less if the ebuild deletes some files or however you wanna deal with it, its just mythtv ya know... its not my production webserver or whatever. A good portion of the people installing the ebuilds (even in there current "beta" form) will be upgrading from a previous version of mythtv that was installed from regular source and will hit the same wall i did... i assumed (bad move i know) that the ebuilds files would go in the same directories that myth puts em and thus get overwritten and all would be well, but never would have suspected that the add-ons wouldnt compile because of some files left behind. really im just trying to give you a newbs perspctive and let you know what you may run into with the other newbs out there. i'll leave the "ebuild ethics" up to you ;-) Sean btw, thanks for the ebuilds, im grateful someone takes the time to make and post them!
oh and i almost forgot... about all the questions you were thinking about coding into it. an interactive install would be really cool but probably a big pain, how about we just write up a README.gentoo and have it referenced in the postinst() ? then theres just one postinst() message telling me in big letters to check out the new readme file before myth will work and we put a real basic FAQ and the answers to the questions in there, most of it would just be a few myth specific things and the how to on the database entries and the rest is already in myths UPGRADING text. i'd help if you need it. lemme know. Sean
Tony: your second command doesn't specify a CVSROOT so whatever is in the environment is probably taking over and you're trying to check out the portage module from some other server. Try running it as cvs -d :pserver:cvs@68.6.36.243:/home/cvs co portage Sean: with regards to the "first point", I really have to disagree. It is very much against policy for an ebuild to go outside of its scope. What if a user is testing something and places it in /usr/local? The standard operating procedure for resolving these kind of problems is to ask on the forums or file a bug which will quickly lead to an answer -- and after fixing them one time (i.e. removing the /usr/local stuff out yourself) your problems are fixed for future installations. As far as a README.gentoo goes...That's probably a good idea -- we can move most of postinst() message to that.
Just to clarify the "first point", this whole thing is a non-issue because there's a global search/replace for /usr/local so this problem shouldn't happen to others. Sean, you might have gotten my cvs ebuilds before their "final" version. Just to confirm: dozer mythtv # emerge mythgallery 2>&1 | grep usr/local dozer mythtv # As you can see, usr/local isn't mentioned at all in any of the compile commands.
Thanks Max, I'm a little neutral on the subject under debate, I think probably the cvs ebuilds should automatically update the database as it is pretty easy to miss the update otherwise and if you play with cvs then you have to expect that your system will get stuffed up sooner or later. :) Thats the main reason why I like to work directly with cvs so I can see the changes before blowing the system away. The other thing I think the ebuild needs is a local use flag for a frontend only. ie use="mythtv-frontend" Just installs the frontend stuff use="mythtv-backend" Installs front and back end but no database stuff. The is no reason to install all the other stuff with databases and backend. The default would be to install the lot. I can have a go at this on the weekend if you like.
Maybe a variable instead of a use flag. ie MYTHTV_OPTIONS? Thats could be placed in make.conf
It would be even more difficult to update the database for cvs ebuilds because there's no guarantee that the current database snapshot is compatible with the cvs.sql file (as that file changes quite frequently, you may already have part of it integrated). It is also assumed that if you're running the cvs builds, you have an understanding of how things work and therefore can do the updates yourself. (I've been doing this with mythtv-cvs, kopete-cvs, php-cvs, horde-cvs and others -- maintaining configs/databases). As far as separating front/backend, wouldn't that just add extra bloat and maintainability problems? Besides, I believe the standard in Gentoo is to install most of the package when it comes to frontends/backends -- think mysql, openssh, openldap -- (all install client and server). Heck, even rsync installs an /etc/init.d/rsync startup script.
I think in this case, at least a frontend only solution, is quite good as it avoids all the xmltv dependicies. Things like mozilla allow you to disable a lot of normal features. ie mail irc etc, so I don't think there is a Gentoo standard except to build everything by default. Maybe Seemant can comment on this?
now incorporated. Enjoy :)
