| Summary: | xine-check does not find plugins | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
| Component: | xine-ui | Assignee: | Michael J Gruber <mjg> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | kevin, mjg, rdieter, susi.lehtola |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | xine-ui-0.99.7-7.fc17 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-06-07 02:59:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Looks like xine-check should be split into a subpackage. The .pc file is in the -devel package. Any progress? Still collecting input, move of xine to rpmfusion still pending. The choices are - require the devel package (not good) - put xine-check into devel (who else needs it) - put xine-check into a subpackage (looks like overkill) - ignore the issue (maybe document it) I changed the severity to low because of the little impact this has. If there's no more input I'll look into the split. Isn't xine-check a tool to simply show the installation is OK? At the present time it doesn't. So it doesn't belong in -devel. It needs to work for a mere user. If xine-check doesn't do what it is supposed to do, why even include it? And then: how esle can we simply verify that stuff is in the right spots after which we can claim bugs in whatever part of xine-/lib? THAT was the reason that the severity was NOT low: xine-check is a very necessary diagnostic tool; it is the start of all xine bug reports. Why oh why does it take so long? There's not even a workaround that's waiting for inclusion in some rpm. The workaround is to install the devel package, of course. xine-check is a tool to verify and "debug" a xine setup in case it doesn't work, so it doesn't necessarily belong into the main package. Choices are still as in comment #3, I'll ping the xine-lib maintainers for their input. A first aid tool to verify an installation does not belong in a devel package. It does belong in the 'main' package as that is what users install. Did we think about the xine-lib issue? (xine-lib has outdated software so we miss out on fetaures and bugfixes!) A tip was to move to rpmfusion. Just don't ship xine-check: * xine-ui is the wrong place for it. * The script is broken, it does not make sense to assume a .pc file to be installed on an end user machine. As for the move to RPM Fusion and upgrade to 1.2, how about the folks who actually care about this do the work? I can live just fine with having 1.1 in Fedora forever, or at least as long as there aren't any security issues left unfixed by upstream that I can't easily backport the fix for. xine-ui-0.99.7-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xine-ui-0.99.7-7.fc18 xine-ui-0.99.7-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xine-ui-0.99.7-7.fc17 Package xine-ui-0.99.7-7.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xine-ui-0.99.7-7.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-3665/xine-ui-0.99.7-7.fc17 then log in and leave karma (feedback). xine-ui-0.99.7-7.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. xine-ui-0.99.7-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. It does NOT fix the issue. It simply removes the cause. There is no workaround offered. So I am not yet a happy camper. (In reply to udo from comment #14) > It does NOT fix the issue. > It simply removes the cause. It fixes the root cause. > There is no workaround offered. The workaround was in comment #5. I implemented the suggested solution after the discussion with xine-lib folks, who know best and were constructive. I don't see any alternative suggestions here (besides the split which is clearly something for post-rpmfusion-move). > So I am not yet a happy camper. I'm sorry I can't help with camping. You could help with fixing a bug, though, by making constructive suggestions and reconsidering the tone of your posts. The reason that xine-check was in the user package as just that. If xine doesn't work one user can check why. That is not development. It might be packaging, It might be a hardware related issue. Commenting about tone leads me to ask about your first language or whether you checked my bugzilla front page as it diverts from the core issue: Actual support that aims customer satisfaction. Yes, you will say that we are not customers but you do understand what I mean. Do you get that when most stuff that I enter bugs for is treated in a way that is not making me slightly happy I migth stop doing the effort and see around for other solutions? So, no thanks. And I cannot do here anything else. The workaround fails: # yum install xine-devel Loaded plugins: local, presto No package xine-devel available. Error: Nothing to do or: # yum install xine-ui-devel Loaded plugins: local, presto No package xine-ui-devel available. Error: Nothing to do So the problem has worsened. |
Description of problem: xine-check does not find plugins Version-Release number of selected component (if applicable): $ rpm -qf `which xine-check` xine-ui-0.99.6-27.fc16.1.x86_64 How reproducible: See below Actual results: See below Expected results: Found plugins etc. Additional info: $ xine-check Please be patient, this script may take a while to run... [ good ] you're using Linux, doing specific tests [ good ] looks like you have a /proc filesystem mounted. [ hint ] ummm, you're running a strange kernel version. Your kernel says, it's version 3.3.1, but I don't know anything about this version. That probably means You should either upgrade your kernel or upgrade this script. press <enter> to continue... [ good ] intel compatible processor, checking MTRR support [ good ] you have MTRR support and there are some ranges set. [ good ] found the player at /usr/bin/xine [ good ] /usr/bin/xine is in your PATH [OUCH!!] no libxine.pc on this machine. This means that xine-lib is either not installed or it is installed in a very unusual place. So you should probably install xine-lib before running xine-check... press <enter> to continue... [ hint ] unable to determine plugin directory I could not determine your plugin directory. That would be much easier if you had libxine.pc installed (see message above)... Note that I could not check your xine plugins. press <enter> to continue... [ good ] /dev/cdrom points to /dev/sr0 [ hint ] /dev/dvd is /dev/dvd, not a DVD device /dev/dvd is the default device that xine uses for playing DVDs. You could make your life easier by creating a symlink named /dev/dvd pointing to your DVD device (something like /dev/scd0 or /dev/hdc). If your DVD-ROM device is /dev/hdb (slave ATAPI device on primary bus), rm /dev/dvd ln -s hdb /dev/dvd typed as root will give you the symlink. Alternatively, you can configure xine to use the real device directly, using the setup dialog within xine, but I can't check your DMA settings in that case... press <enter> to continue... [ good ] found xvinfo: X-Video Extension version 2.2 [ good ] your Xv extension supports YV12 overlays (improves MPEG performance) [ good ] your Xv extension supports YUY2 overlays [ good ] Xv ports: YUY2 YV12 I420 UYVY BTW: See https://bugzilla.rpmfusion.org/show_bug.cgi?id=438 Nobody ever does anything about xine bugs...