Description of problem: Mythtv can be installed without a database, mysql or mariadb. Could the installation script install a database with urpmi, start it, and configure it with, "mysql -u root /usr/share/mythtv/initialdb/mc.sql" or what ever is appropriate. Perhaps just a warning message that says, "You need a database". Version-Release number of selected component (if applicable): Mageia 2 beta 3 i586 DVD How reproducible: Very, it is an old bug. Steps to Reproduce: 1. urpmi -a mythtv 2. mythtv-setup
Assignee: bugsquad => mageiaSource RPM: mythtv-common => mythtv
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Mythtv is still missing dependencies in Mageia 2. I forgot to check about mariadb on this istall. (I installed the database then mythtv.) libcec-devel seems to be necessary, and is not installed automatically. After installing libcec-devel it still seg-faulted, but for some other reason. :-( [psd@test bin]$ mythtv-setup 2012-05-28 15:15:16.125355 C mythtv-setup version: [0.25-20120418.3.mga2] www.mythtv.org 2012-05-28 15:15:16.125383 N Enabled verbose msgs: general 2012-05-28 15:15:16.125415 N Setting Log Level to LOG_INFO 2012-05-28 15:15:16.125480 I Added logging to the console 2012-05-28 15:15:16.125490 I Added database logging to table logging 2012-05-28 15:15:16.125635 N Setting up SIGHUP handler 2012-05-28 15:15:16.125809 N Using runtime prefix = /usr 2012-05-28 15:15:16.125833 N Using configuration directory = /home/psd/.mythtv 2012-05-28 15:15:16.126038 I Assumed character encoding: en_AU.UTF-8 2012-05-28 15:15:16.126835 E Unable to read configuration file mysql.txt 2012-05-28 15:15:16.127098 N Empty LocalHostName. 2012-05-28 15:15:16.127109 I Using localhost value of test.home.invalid 2012-05-28 15:15:16.165009 N Desktop video mode: 1920x1080 60.000 Hz cannot find libcec.solibcec.so: cannot open shared object file: No such file or directory Segmentation fault [psd@test bin]$
I just tried a 64 bit install. "ps -A" shows that mysqld is running, without me explicitly installing or starting it, although MCC does not show it as running. Initialising the database did not work, but I suspect that this is a mariadb problem rather than a mythtv problem. [psd@test ~]$ cd /usr/share/mythtv/initialdb/ [psd@test initialdb]$ [psd@test initialdb]$ mysql -u root < mc.sql ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) [psd@test initialdb]$ cd /var/lib/mysql/ [psd@test mysql]$ ll -a total 16 drwxr-xr-x 4 mysql mysql 4096 May 28 16:24 ./ drwxr-xr-x 47 root root 4096 May 28 17:10 ../ drwxr-xr-x 2 mysql mysql 4096 Apr 28 13:32 mysql/ drwxr-xr-x 2 mysql mysql 4096 Apr 28 13:32 test/ [psd@test mysql]$
As mysql/mariadb is a network accessible system, I don't think it's appropriate that mythtv *requires* a database. It is entirely possible that the database will be on a totally different machine to that on which the frontend or backend runs. As this is a non-trivial system to configure I don't think it's beyond the scope of the installation task to expect someone to install the relevant database package. It is also not really feasible to automatically install a database as many system administrators will change the root password for mysql immediately after installing (I know I do) and thus any automated installation would likely not work. Add to that, if we automate too much, people following installation guides and similar will have half the steps done for them, but be somewhat unaware as to what steps were done and what ones were not etc. So IMO, I think we leave the install stage to the user, but I'm willing to be convinced otherwise. As for the db, it appears that mysql was not running or not listening on the relevant socket when you executed the setup command. I'll see if I can reproduce the segv, but it works fine here - although it does look like the libcec packaging is perhaps not perfect if it needs the .so at runtime, it should be in the main package, not the -devel.
CC: (none) => anssi.hannula
Keywords: NEEDINFO => (none)CC: (none) => sander.lepik
I've had another similar report here so it looks like you are not alone! Just for clarity, is the output in comment:2 the failure you get when libcec-devel is NOT installed? I think so, but just wanted to double check. If you can install the debug package and get a backtrace from the crash you do get that would be great.
Hi, Can you try the latest mythtv packages in the updates_testing repo? Having worked with someone who was also having similar problems, this build seems to have helped them. Cheers Col
Sorry for the delay. Real life has been interfering with my computer time. :-( Comment #2 was a cut and paste from the terminal running mythtv-setup. The seg fault was reported after the cec error, so I assumed that one caused the other, but things might have been asynchronous. The terminal output was from before installing libcec-devel. The libcec error seems to have been about something that MythTV expected rather than needed. At the time I didn't know what CEC was. It turn out that there are no CEC devices here. Maybe some functionality should be moved from the devel package to main package. I did not realize that the database could be on a different machine. Urpmi has a "suggests" feature. That might be the thing to do with mariadb; MythTV is very complex and serious users will want to do their own thing, but I suspect that most Mageia users have single box systems and like to have things work "out of the box" as much as practical. Your call. Where would the backtraces have appeared? Nothing showed on the terminal. The updated 32 bit version is better behaved now. The 32 bit machine has some problems with its tuner, so it has not been thoroughly tested. And the 64 bit machine is usually being used, so I don't want to take it off line more than I have to. Both the updated 32 bit versions of MythTV-setup and the 64 bit release version seg faulted when it came time to select the language. My choices were "Australia" and "US-English".
It seg faulted on the first run, but not the second. Here is a line from syslog on the 32 bit machine, after the language selection. Jun 4 14:26:25 test kernel: [ 468.400118] mythtv-setup[3063]: segfault at 0 ip 080548fd sp bfd8f5e0 error 4 in mythtv-setup[8048000+4c000] And from the terminal... [psd@test ~]$ mythtv-setup 2012-06-04 14:26:02.226981 C mythtv-setup version: [0.25-20120602.0.1.mga2] www.mythtv.org 2012-06-04 14:26:02.227107 C Qt version: compile: 4.8.1, runtime: 4.8.1 2012-06-04 14:26:02.227132 N Enabled verbose msgs: general 2012-06-04 14:26:02.227259 N Setting Log Level to LOG_INFO 2012-06-04 14:26:02.227524 I Added logging to the console 2012-06-04 14:26:02.227550 I Added database logging to table logging 2012-06-04 14:26:02.227950 N Setting up SIGHUP handler 2012-06-04 14:26:02.228275 N Using runtime prefix = /usr 2012-06-04 14:26:02.228341 N Using configuration directory = /home/psd/.mythtv 2012-06-04 14:26:02.229114 I Assumed character encoding: en_AU.UTF-8 2012-06-04 14:26:02.239348 E Unable to read configuration file mysql.txt 2012-06-04 14:26:02.239740 E DBHostName is not set in config.xml 2012-06-04 14:26:02.239864 N Empty LocalHostName. 2012-06-04 14:26:02.239904 I Using localhost value of test.test.invalid 2012-06-04 14:26:02.405978 N Setting QT default locale to en_AU 2012-06-04 14:26:02.406033 I Current locale en_AU 2012-06-04 14:26:02.406259 E No locale defaults file for en_AU, skipping 2012-06-04 14:26:02.431252 I Starting process signal handler 2012-06-04 14:26:02.431819 I Starting process manager 2012-06-04 14:26:02.432148 I Starting IO manager (read) 2012-06-04 14:26:02.432448 I Starting IO manager (write) 2012-06-04 14:26:02.648670 I ScreenSaverX11Private: DPMS is active. 2012-06-04 14:26:02.959105 E X11 ModeLine query returned zeroes 2012-06-04 14:26:02.959679 N Desktop video mode: 1024x768 60.000 Hz 2012-06-04 14:26:03.313042 I Loading en_us translation for module mythfrontend 2012-06-04 14:26:03.318734 E LIRC: Failed to connect to Unix socket '/var/run/lirc/lircd' eno: No such file or directory (2) 2012-06-04 14:26:03.318931 E JoystickMenuThread: Joystick disabled - Failed to read /home/psd/.mythtv/joystickmenurc 2012-06-04 14:26:03.493290 E CECAdapter: Failed to find any CEC devices. 2012-06-04 14:26:03.493956 I CECAdapter: Closing down CEC. 2012-06-04 14:26:03.591161 I Binding to UDP 127.0.0.1:0 2012-06-04 14:26:03.591534 I Binding to UDP 192.168.1.3:0 2012-06-04 14:26:03.591948 I Binding to UDP [::1]:0 2012-06-04 14:26:03.592309 I Binding to UDP [fe80::220:edff:fe2f:9deb%eth0]:0 2012-06-04 14:26:03.592760 I Binding to UDP 192.168.1.255:0 2012-06-04 14:26:04.177554 I Using Frameless Window 2012-06-04 14:26:04.177800 I Using Full Screen Window 2012-06-04 14:26:04.237170 I Using the Qt painter 2012-06-04 14:26:06.238912 I System Locale (en_AU), Country (AU), Language (en) Segmentation fault [psd@test ~]$
Actually it seems libcec is a bit daft.. it implements a dynamic loader that uses the .so file not .so.MAJOR. This scheme also means that we need to add manual requires to all packages that want to use it to ensure it is installed. I'll sort this out but it seems a totally separate issue. Either way this is a separate issue. So it seems things are still breaking for you :s Can you get a backtrace from this? See the mythtv docs about how to get a backtrace (http://www.mythtv.org/wiki/Debugging#Getting_a_Backtrace), but you'll have to remove the set-args line in the gdbcommands file as this no longer applies on mythtv >= 0.25
FWIW, I've submitted this upstream report regarding libcec: https://github.com/Pulse-Eight/libcec/issues/30
*** Bug 6063 has been marked as a duplicate of this bug. ***
CC: (none) => derekjenn
This is a bit messy, there seem to be multiple bugs in the same bug report - which is generally "a bad thing". The tally seems to be; libcec is irrelevant, but messy and should be tidied up for its own sake. IMO urpmi could suggest mariadb with mythtv, but that is a very minor point. The i586 specific seg fault seems to be fixed, at least it has not bitten me lately. The language and location selection seg fault is still there. I have seen it on both 32 bit and 64 bit versions. It only occurs on the first run of an installation. After that it behaves itself. Attached below should be the gdb output on a 64 bit system. I modified the set args line rather than removing it. I hope that I did the right thing. It looks like this now. [psd@test ~]$ cat gdbcommands handle SIGPIPE nostop noprint handle SIG33 nostop noprint set logging on set pagination off set breakpoint pending on break qFatal set args --logpath /home/psd -v important,general run thread apply all bt full set logging off [psd@test ~]$
Created attachment 2425 [details] debug log file for mythtv-setup language selection
Created attachment 2426 [details] gdb.txt for mythtv-setup language selection
Yup the gdbcommands file looks good to me. The backtrace is interesting. Can you describe what you do to make it crash? Do you create a blank database and populate it manually, or just run mythtv-setup and let it do it for you? I tried wiping my db and just ran mythtv-setup. It seemed to work OK even if I picked an Australian locale. Is this the same procedure as you? Or does it require wiping more stuff to create the conditions where the problem could occur? Perhaps I need to install a test VM that has a different system locale?
It is a once per installation error, so it is a right royal PITA to reproduce. The relevant bits seem to be; fresh install mysql -u root < /usr/share/mythtv/initialdb/mc.sql mythtv-setup select a language select a place save After that, running mythtv-setup immediately again does not give a problem. Unfortunately it was not a totally clean install because I had run my initialization script that does things like add local repositories of previously downloaded rpms, install my favorites, and do some configuration, but I can not see anything that looks pathological.
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
(In reply to comment #6) > Can you try the latest mythtv packages in the updates_testing repo? This one 0.25-20120602.0.1.mga2.tainted works for me.
CC: (none) => hc
Closing per comment #18. Please reopen another bug if needed, because this one has become impossible to follow (multiple issues in one).
Status: NEW => RESOLVEDResolution: (none) => FIXED