W dniu 14.06.2012 18:41, Nicolas Chauvet pisze: > 2012/6/14 Julian Sikorski <beleg...@gmail.com>: >> W dniu 14.06.2012 09:39, Nicolas Chauvet pisze: >>> 2012/6/14 Julian Sikorski <beleg...@gmail.com>: >>>> W dniu 13.06.2012 00:11, Julian Sikorski pisze: >>>>> W dniu 12.06.2012 23:55, Julian Sikorski pisze: >>>>>> W dniu 27.05.2012 12:46, Nicolas Chauvet pisze: >>>>>>> 2012/5/27 Julian Sikorski <beleg...@gmail.com>: >>>>>>>> Dear RPM Fusion developers, >>>>>>>> >>>>>>>> ffmpeg-0.11 was released a few days ago. Do you think we should try to >>>>>>>> push it to Fedora 17? >>>>>>> >>>>>>> I'm not against having it as an update, but: >>>>>>> - Is the ABI the same ? >>>>>>> - does dependants package build fin ? >>>>>>> - Can we make the update to settle in rawhide first, and then to >>>>>>> evaluate the update in F-17 (if relevant) ? >>>>>>> >>>>>>> I also wonder if it won't be more relevant to wait for a new 0.10.x >>>>>>> release that might be done at a later point. >>>>>>> >>>>>>> Nicolas (kwizart) >>>>>>> >>>>>> After finally getting CVS access back I was able to finish the rebuild. >>>>>> Results are as follows: out of 34 dependencies, 5 worked out of the box, >>>>>> one required libquicktime to be built first, one needed BR fix and >>>>>> mplayer worked when updated to 1.1. I think we should still go on and >>>>>> let the maintainers fix their packages. Details: >>>>>> >>>>>> acoustid-fingerprinter failed >>>>>> alsa-plugins-freeworld failed: 'MREMAP_MAYMOVE' undeclared >>>>>> (first use >>>>>> in this function) >>>>>> audacious-plugins-freeworld failed >>>>>> bino worked >>>>>> bombono-dvd failed: glib headers >>>>>> chromaprint-tools failed >>>>>> cmus failed >>>>>> dvbcut failed >>>>>> dvdstyler needs wxsvg, still fails afterwards >>>>>> ffmpeg2theora worked >>>>>> ffmpegthumbnailer failed >>>>>> gpac failed >>>>>> gstreamer-ffmpeg failed >>>>>> guvcview failed >>>>>> k3b-extras-freeworld requires vlc >>>>>> kdemultimedia-extras-freeworld requires vlc >>>>>> kmediafactory requires mencoder, vlc, mlt and >>>>>> libquicktime >>>>>> libquicktime worked >>>>>> lightspark worked >>>>>> minidlna failed >>>>>> miro failed >>>>>> mlt needs libquicktime, then OK >>>>>> motion failed >>>>>> mpd needs pulseaudio-lib-devel → >>>>>> pulseaudio-libs-devel BR fix, works >>>>>> afterwards >>>>>> mplayer updated to 1.1 works, did not check >>>>>> otherwise >>>>>> picard-freeworld requires vlc >>>>>> qmmp-plugins-freeworld failed >>>>>> vbam failed >>>>>> vlc failed: free: command not found >>>>>> wxsvg worked >>>>>> xbmc failed >>>>>> xine-lib-extras-freeworld failed >>>>>> xmms2-freeworld failed >>>>>> >>>>>> Regards, >>>>>> Julian >>>>>> >>>>> To be clear: go on in rawhide and then see where we stand once >>>>> everything is patched up. >>>>> >>>>> Julian >>>>> >>>> Dear package maintainers: updated ffmpeg is available here: >>>> http://lesloueizeh.com/belegdol/ffmpeg/ >>>> Please try to fix your package to build against it. >>> Hi >>> >>> Can you verify that this package match what's in our cvs ? >>> >>> I would prefer the package to be built within the infra. >>> That's because it will be easier for a maintainer to enable the >>> unpushed 'plague result' repository that is already referenced in the >>> mock-rpmfusion_free configuration files, instead of adding various >>> alternate repository. >>> >>> Also It will also to build a first level dependency (such as >>> libquicktime) there and allow the local test of a second level >>> dependency then. >>> >>> Now I will be away this week-end and busy next week, so I would prefer >>> to schedule the update starting from the next week-end. >>> Does that sounds good ? >>> >>> >>> Nicolas (kwizart) >>> >> OK, I forgot that I can build the package within the infra and still >> don't break the buildroots. > You can't, but you can commit it in devel without building. > That way every packager can rebuild locally test theird packages. > (even using a --with suffix option to make a parallel installable > ffmpeg-libs). > >> By scheduling the update for the next weekend, would you prefer me to >> wait with with building ffmpeg until then? Or would you prefer me to >> build it right away to give the maintainers more time to test? > There is a certain number of package to build in order to bootstrap a > ffmpeg update (likely x264) this probably needs maintainer > coordination. > (BTW, there is a RFE for x264 that needs to be adressed about 10bit option) > > Nicolas (kwizart) > I see. I can commit it without building then. When it comes to x264: I have absolutely no experience on the matter, all I can say is that ffmpeg-0.11.1 builds fine against what is in the repos now. I'll let more knowledgeable people to pick the snapshot we would like to ship.
Regards, Julian