| Summary: | xine-lib-1.2.x is available | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Upstream Release Monitoring <upstream-release-monitoring> |
| Component: | xine-lib | Assignee: | Kevin Kofler <kevin> |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | c719711, kevin, rdieter, udovdh, zboszor |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-06-29 23:03:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Upstream Release Monitoring
2012-01-02 12:13:24 UTC
Significant features: VDPAU support, VDR support, following the XDG Base Directory Specification, reduced memory usage, and no internal copies of ffmpeg, libcdio or libvcd. You'll need to recompile your front end to use this if you've previously been using 1.1 (not 1.1.90). Release notes: http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/view xine-lib 1.2 has a hard global dependency on FFmpeg (libavutil is used throughout the library), so it cannot go into Fedora. I updated the regex in: https://fedoraproject.org/wiki/Upstream_release_monitoring#Q_-_Z to only match 1.1.x releases and I'll be importing 1.1.20.1 (the bugfix release) shortly. *** Bug 879342 has been marked as a duplicate of this bug. *** The xine people I got response from in the xine IRC channel think it is not their problem to migrate stuff to rpmfusion (provide rpms etc) This could mean that we are stuck with an outdated xine due to redhat strategy mistakes. How do we get out of this? As I wrote more than once, the whole thing needs to move to RPM Fusion, we need somebody to do the work. (I may eventually do it, but it has a low priority for me. In any case, it's too late for Fedora 18 now, we can target 19 at the earliest.) (And of course it's not upstream's job to do packaging work!) Why does a version upgrade of a mediaplayer have to conincide with a version increase of the distro? Does Redhat have avenues for crowdsourcing stuff like the rpm-building thing? (I guess that more than never, people have priorities in mind that are different from what redhat personnel can dedicate; so the questin of buying time for a certain task comes into view) > Why does a version upgrade of a mediaplayer have to conincide with a version > increase of the distro? Because: 1. This is not a media player, it's a media-playing LIBRARY. Upgrading a library is much more of a problem than upgrading an application due to the many applications that depend on it. 2. We are not just upgrading the library, we are completely removing it from Fedora (to put it into RPM Fusion, a third-party repository not officially endorsed by Fedora for legal reasons). This cannot be done in an update. 3. Upgrading xine-lib 1.1 to 1.2 is also an ABI break (i.e. it breaks binary compatibility, so it's not a drop-in replacement, all software using it needs to be recompiled). This is strongly discouraged in stable releases of Fedora (and Fedora 18 is now in Final Freeze, which means the rules for stable releases already apply). > Does Redhat have avenues for crowdsourcing stuff like the rpm-building thing? There's no requirement for a Fedora packager to be a Red Hat employee, and of course not for an RPM Fusion packager either. (Red Hat does not even officially acknowledge RPM Fusion's existence due to the legal situation.) I am not a Red Hat employee. The Fedora policies make no distinction between Red Hat and community packagers. In any case, Bugzilla is not an appropriate venue for this discussion, please stop spamming this bug report. *** Bug 968885 has been marked as a duplicate of this bug. *** FWIW: ]# rpm -e xine-lib error: Failed dependencies: libxine.so.1()(64bit) is needed by (installed) xine-lib-extras-1.1.21-2.fc17.x86_64 libxine.so.1()(64bit) is needed by (installed) xine-lib-extras-freeworld-1.1.21-3.fc17.x86_64 libxine.so.1()(64bit) is needed by (installed) xine-ui-0.99.7-2.fc17.x86_64 xine-lib(plugin-abi)(x86-64) = 1.30 is needed by (installed) xine-lib-extras-freeworld-1.1.21-3.fc17.x86_64 xine-lib >= 1.1.21-2 is needed by (installed) xine-lib-extras-freeworld-1.1.21-3.fc17.x86_64 xine-lib is needed by (installed) xine-ui-0.99.7-2.fc17.x86_64 xine-lib(x86-64) = 1.1.21-2.fc17 is needed by (installed) xine-lib-extras-1.1.21-2.fc17.x86_64 So xine-lib is used only by xine itself on this box. How common is this situation? Where is the howto for building xine-lib (and xine*) for 1.2? I could have a go because CANTFIX is too weak for a distro that needs a decent MAINTAINED media player. Let's reopen this at least for tracking purposes No. It doesn't make any sense to have this open. It does make sense to move forward to xine 1.2.x and beyond. It happened!!!!1!!! $ rpm -qi xine-lib Name : xine-lib Version : 1.2.4 Release : 3.fc20 Architecture: x86_64 Install Date: ma 17 feb 2014 08:34:10 CET Group : Unspecified Size : 6519507 License : GPLv2+ Signature : RSA/SHA256, wo 06 nov 2013 21:43:49 CET, Key ID 963a8848ae688223 Source RPM : xine-lib-1.2.4-3.fc20.src.rpm Build Date : di 05 nov 2013 19:29:43 CET Build Host : builder1.ovh.rpmfusion.lan Relocations : (not relocatable) Packager : <http://free.rpmfusion.org/> Vendor : RPM Fusion URL : http://www.xine-project.org/ Summary : A multimedia engine Thanks! Yes, we dropped xine-lib entirely from Fedora so that third-party repositories can ship the newer version. A loss for Fedora. |