RPM Fusion (EL - free) Package Build Report 2014-03-05
Packages built and released for RPM Fusion (EL - free) 6: 2 NEW dhewm3-1.3.1.1304-21.git6d8108c.el6 : Dhewm's Doom 3 engine vlc-2.0.10-1.el6 Packages built and released for RPM Fusion (EL - free) testing/6: 3 ffmpeg-0.10.11-1.el6 NEW libbdplus-0.1.0-2.el6 : Open implementation of BD+ protocol NEW libmimic-1.0.4-6.el6 : Encoding/decoding library for Mimic V2.x Changes in RPM Fusion (EL - free) 6: dhewm3-1.3.1.1304-21.git6d8108c.el6 --- * Mon Dec 02 2013 Simone Caronni negativ...@gmail.com - 1.3.1.1304-21.git6d8108c - Review fixes. vlc-2.0.10-1.el6 * Fri Feb 21 2014 Nicolas Chauvet kwiz...@gmail.com - 2.0.10-1 - Update to 2.0.10 * Wed Nov 06 2013 Nicolas Chauvet kwiz...@gmail.com - 2.0.9-1 - Update to 2.0.9 - Move crystalhd to extras - rhbz#2835 Patch from Sergio Durigan Junior sergi...@riseup.net - Fix ca cert path on fedora - Add missing libgcrypt-devel Changes in RPM Fusion (EL - free) testing/6: ffmpeg-0.10.11-1.el6 * Tue Mar 04 2014 Nicolas Chauvet kwiz...@gmail.com - 0.10.11-1 - Update to 0.10.11 libbdplus-0.1.0-2.el6 - * Wed Jan 08 2014 Xavier Bachelot xav...@bachelot.org 0.1.0-2 - Add version to libaacs BuildRequires:. - Remove Group: tags. - Use %make_install macro. - Minor specfile fixes. libmimic-1.0.4-6.el6 * Sun Mar 03 2013 Nicolas Chauvet kwiz...@gmail.com - 1.0.4-6 - Mass rebuilt for Fedora 19 Features
Re: x264 so bump
Hi, On Seg, 2014-03-03 at 14:42 -0600, Richard Shaw wrote: Some problem with the nodebug repo... Ohwell I disabled it but I guess you have to bootstrap x264 and ffmpeg... Too much trouble. I say go ahead and I'll fix any problems with avidemux and mythtv as needed. OK , x264 versions still 0.x , ABI changes are very small , normally doesn't break anything, I doesn't have much time to analyze it with abi-compliance-checker , but I can assure that changes are small. So I'm submitting x264 for rawhide. Best regards -- Sérgio M. B.
Re: FFmpeg bundling exception for XBMC
On Qua, 2014-02-26 at 00:32 +, Sérgio Basto wrote: On Seg, 2014-02-24 at 10:17 -0700, Ken Dreyer wrote: On Mon, Feb 24, 2014 at 12:30 AM, Ralf Corsepius ralf.corsep...@gmail.com wrote: On 02/24/2014 07:20 AM, Ken Dreyer wrote: Hi folks, Alex Lancaster recently pointed out that XBMC upstream has completely removed the option to use an external FFmpeg. https://github.com/xbmc/xbmc/pull/4005 FFmpeg has been a long ongoing saga with XBMC. The XBMC developers develop their own patches to their private FFmpeg fork, and Alex and I have had various success or failure over the years with unbundling FFmpeg in the past. Unfortunately XBMC has recently taken steps in the direction to make this harder, at least for the v13 Gotham release. The summary is that Alex and I need a bundling exception from the RPM Fusion developer community in order to keep XBMC in RPM Fusion. -- From what I can tell, the three reasons that the XBMC developers bundle FFmpeg are: There are 2 strong reasons to not bundle FFMPEG: * Users (eg. me) rebuild rpmfusion's ffmpeg with options not supported by rpmfusion: = rpmfusion bundling xbmc's ffmpeg would void this undertaking and reduce rpmfusion's usability. * ffmpeg is quite security sensitive (AFAICT, e.g. Google recently reported (IIRC), ca. 1000 bugs, which reportedly were incorporated into upstream ffmpeg) = XBMC's bundling imposes severe security risks on both XMBC and rpmfusion That said, I am quite opposed to let rpmfusion bundle ffmpeg and am in favor of staying hard for didacitcal, to teach upstream XBMC that their undertaking is counterproductive. One could say that the issue which prompted my bundling exception proposal, https://github.com/xbmc/xbmc/pull/4005, is a direct consequence of teaching upstream. They've made it more difficult to unbundle with the express purpose of influencing downstream distributors of XBMC. You can see where that trajectory leads. Yes, it's all open source, and the GPL technically allows RPM Fusion to do what we want, etc, but Alex and I are heading down a path of maintaining an increasingly-diverging XBMC fork at this point, and no one else has committed to becoming a full co-mainatainer of the package in order to share the workload, particularly the workload associated with downstream patches. Alex and I know firsthand that this is not a good situation, and in fact I don't know any of the upstream developers who are rabidly enthusiastic about the bundling situation either. If the issues I outlined in my previous email could go away or be reduced, I'm confident that they would pull FFmpeg from their tree right away. They've certainly pulled bundled libraries out over the years when it's made sense to do so. https://github.com/xbmc/xbmc/pull/1450 is one example. I'm all for Fedora's strong package guidelines - it's why I use and contribute to Fedora. Please believe me that I wouldn't go the bundling exception route if I felt that another choice was truly feasible. After working on this package for years, I believe this is the least-worst option available. Looking at it from another angle, it's important that our relationship with upstream XBMC involve give-and-take. If we don't allow the specific exception here for FFmpeg, we are certainly teaching them something: we're souring Fedora's name with upstream and making them care even less about our platform. I'm not yet at the point where I want to pull XBMC from RPM Fusion altogether, but version 13 final will have that pull request in the codebase, and we need to decide what to do. One thing that would really help to smooth over the relationship is if we had a patch to XBMC that allowed us to add a large caveat to their branding. It would be wonderful if we had some sort of XBMC, modified by bugzilla.rpmfusion.org splash screen or logo. One of the XBMC developers pointed me at Debian's effort with this. Debian has started down this road, in large part because of these issues: http://balintreczey.hu/blog/introducing-xbmc-from-debian/ . This would be a great area of work for someone reading this discussion who could become a potential contributor to XBMC/RPM Fusion. It would be even better if the solution could be something extensible enough that upstream would accept into their codebase. Another thing to consider Ralf is that I intend to maintain the package in such a way that it will be trivial to switch between using the bundled FFmpeg and the non-bundled version using a build conditional. It should be simple for you to continue building against your own custom FFmpeg package - you will just need to flip the without external_ffmpeg conditional to with external_ffmpeg when you rebuild your XBMC. See the ongoing work at
Re: Packaging 3-rd party repositories in rpmfusion
Hi, On Qua, 2014-01-29 at 12:12 +0100, Alec Leamas wrote: Formally, this is about review request 3152 for dropbox-repo [1]. From a more practical POV, it's about users being able to install software like dropbox more or less out of the box, an area where I think we really need to improve (as can be seen in all those Fedora XX post installation guide out there). My basic understanding is that current Fedora guidelines needs a interpretation in the rpmfusion context. Those brand new GL for 3-rd party repos are in [2] (discussions in [3]). For now, I think they can be abridged to: - Non-free repos can not be part of Fedora yum configuration. - In some cases free repos can be part of the configuration after FESCO/Fedora legal approval. Now, IMHO this doesn't really make much sense for rpmfusion for three reasons: - rpmfusion does not ban non-free software, it's one of the very reasons it exists. - FESCO/Fedora legal cannot approve anything in rpmfusion. - We already have a list of endorsed 3-rd party repos [4]. To handle this, my simple proposal is that we handles packaged yum repositories like this: - It's ok to package yum repositories listed in [4]. - If anyone wants to change the list in [4] this should be announced here on rpmfusion-devel, and not done until we agree on it (similar to how we handle bundling exceptions). Thoughts. out there? hum unfortunately I don't had much time for this subject , I don't read carefully all thread, going straight to the point I think you could use yumex instead the tool you are making (I don't find name right now) to manage repos. But I'd like to insist in putting a system depends on 3rd party repos (adding 3rd party repos) is bad, and I prefer a solution like a proxy repo that we talk in package review [1]. Almost all 3rd party repos don't have mirrors. Recently when download1.rpmfusion.org was down (for a moment, in that moment ) yum hanged for very long time and doesn't update anything . So if a 3rd party repo goes down yum update will fail . If a 3rd party repo is very slow yum update will be very slow . Maybe in yum.conf for this 3rd party repos use skip_if_unavailable=True https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152#c30 --alec [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152 [2] https://fedoraproject.org/wiki/Third_Party_Repository_Policy [3] https://fedorahosted.org/fesco/ticket/1201#comment:32 [4] http://rpmfusion.org/FedoraThirdPartyRepos -- Sérgio M. B.
Re: Packaging 3-rd party repositories in rpmfusion
On 03/05/2014 08:05 AM, Sérgio Basto wrote: So if a 3rd party repo goes down yum update will fail . If a 3rd party repo is very slow yum update will be very slow . Maybe in yum.conf for this 3rd party repos use skip_if_unavailable=True +1, skip_if_unavailable=True should be a prerequisite to any added 3rd-party repos -- Rex
Re: RPM Fusion server maintenance
Hi, old03.ovh.rpmfusion.lan seems have the clock delayed more than 4 hours ... Received: from hv02.ovh.rpmfusion.net (HELO old03.ovh.rpmfusion.lan) (188.165.226.50) by serjux.com with SMTP; 5 Mar 2014 17:36:50 + Received: from old03.ovh.rpmfusion.lan (localhost.localdomain [127.0.0.1]) by old03.ovh.rpmfusion.lan (Postfix) with ESMTP id 9080D1A3763 for ser...@serjux.com; Wed, 5 Mar 2014 15:02:13 +0100 (CET) On Sex, 2014-02-28 at 20:00 +0100, Matthias Saou wrote: Quick update : The main downtime is now over. There will be another much shorter downtime shortly, since there is still a failing disk from a software RAID-1 array to replace. But this time it should be a matter of minutes. (as a side note : this was a close one, since the server's RAID-1 had one completely failed disk and the other with some reallocated sectors, read pending sectors and offline unrecoverable ones! the local dd took some time, but restoring 8 VMs and 500+GB of data from remote backups would have taken much longer!) Matthias On Fri, 28 Feb 2014 16:27:36 +0100 Matthias Saou matth...@saou.eu wrote: Hi everyone, Some hardware is being replaced on the main RPM Fusion physical server, and I'm going to be moving some data around in rescue-ish mode during the next few hours. Many (most) services will be down for a while. Sorry for the inconvenience! Matthias -- Sérgio M. B.
Re: Packaging 3-rd party repositories in rpmfusion
On 3/5/14, Rex Dieter rdie...@math.unl.edu wrote: On 03/05/2014 08:05 AM, Sérgio Basto wrote: So if a 3rd party repo goes down yum update will fail . If a 3rd party repo is very slow yum update will be very slow . Maybe in yum.conf for this 3rd party repos use skip_if_unavailable=True +1, skip_if_unavailable=True should be a prerequisite to any added 3rd-party repos -- Rex Agreed, will fix before importing. Nice catch! --alec
little mass rebuild required Re: x264 so bump
Hi, with x264 submitted into rawhide we need rebuild * List what requires x264: (build in first place) * ffmpeg * libquicktime (others) * avidemux * mplayer * ffmpeg-compat * gstreamer1-plugins-ugly * gstreamer-plugins-ugly * mythtv * vlc Reference : http://rpmfusion.org/ImportantDependencyLists (updated) -- Sérgio M. B.
