Hi list, ffmpeg-2.1 is out. preliminary rebuild shows 21 successes and 8 failures - and 4 of those are due to vlc's libfreerdp issues. I think we should branch first in any case: $ find -name success | sort ./audacious-plugins-freeworld-3.4.1-1.fc20/success ./chromaprint-tools-1.0-2.fc20/success ./dvbcut-0.6.1-14.svn179.fc20/success ./dvdstyler-2.6-0.1_rc2.fc20/success ./ffmpeg-2.1-1.fc20/success ./ffmpeg2theora-0.29-7.fc20/success ./gpac-0.5.0-7.20130914svn.fc20/success ./guvcview-1.6.1-6.fc20/success ./libquicktime-1.2.4-12.fc20/success ./lightspark-0.7.2-4.20130827git.fc20/success ./minidlna-1.1.0-2.fc20/success ./moc-2.5.0-0.10.beta1.fc20/success ./mpd-0.18-0.1.git0e0be02.fc20/success ./mplayer-1.1-14.20130811svn.fc20/success ./mpv-0.1.7-4.fc20/success ./openmw-0.26.0-6.fc20/success ./qmmp-plugins-freeworld-0.7.2-2.fc20/success ./wxsvg-1.2.1-1.fc20/success ./x264-0.136-1.20131005git3361d59.fc20/success ./xbmc-13.0-0.1.Gotham_alpha8.fc20/success ./xine-lib-1.2.4-2.fc20/success $ find -name fail | sort ./acoustid-fingerprinter-0.6-5.fc20/fail ./bino-1.4.2-4.fc20/fail ./bombono-dvd-1.2.2-4.fc20/fail ./ffmpegthumbnailer-2.0.8-6.fc20/fail ./ffmpegthumbs-4.11.1-1.fc20/fail ./kmediafactory-0.8.1-9.fc20/fail ./mlt-0.9.0-1.fc20/fail ./vlc-2.1.0-2.fc20/fail

W dniu 29.10.2013 21:11, Sérgio Basto pisze: > On Ter, 2013-10-29 at 20:21 +0100, Julian Sikorski wrote: >> Hi list, >> >> ffmpeg-2.1 is out. preliminary rebuild shows 21 successes and 8 failures >> - and 4 of those are due to vlc's libfreerdp issues. >> I think we should branch first in any case: >> >> $ find -name success | sort >> ./audacious-plugins-freeworld-3.4.1-1.fc20/success >> ./chromaprint-tools-1.0-2.fc20/success >> ./dvbcut-0.6.1-14.svn179.fc20/success >> ./dvdstyler-2.6-0.1_rc2.fc20/success >> ./ffmpeg-2.1-1.fc20/success >> ./ffmpeg2theora-0.29-7.fc20/success >> ./gpac-0.5.0-7.20130914svn.fc20/success >> ./guvcview-1.6.1-6.fc20/success >> ./libquicktime-1.2.4-12.fc20/success >> ./lightspark-0.7.2-4.20130827git.fc20/success >> ./minidlna-1.1.0-2.fc20/success >> ./moc-2.5.0-0.10.beta1.fc20/success >> ./mpd-0.18-0.1.git0e0be02.fc20/success >> ./mplayer-1.1-14.20130811svn.fc20/success >> ./mpv-0.1.7-4.fc20/success >> ./openmw-0.26.0-6.fc20/success >> ./qmmp-plugins-freeworld-0.7.2-2.fc20/success >> ./wxsvg-1.2.1-1.fc20/success >> ./x264-0.136-1.20131005git3361d59.fc20/success >> ./xbmc-13.0-0.1.Gotham_alpha8.fc20/success >> ./xine-lib-1.2.4-2.fc20/success >> $ find -name fail | sort >> ./acoustid-fingerprinter-0.6-5.fc20/fail >> ./bino-1.4.2-4.fc20/fail >> ./bombono-dvd-1.2.2-4.fc20/fail >> ./ffmpegthumbnailer-2.0.8-6.fc20/fail >> ./ffmpegthumbs-4.11.1-1.fc20/fail >> ./kmediafactory-0.8.1-9.fc20/fail >> ./mlt-0.9.0-1.fc20/fail >> ./vlc-2.1.0-2.fc20/fail > > acoustid-fingerprinter > bino > bombono-dvd > ffmpegthumbnailer > > Already doesn't compile for ffmpeg-2.0, so IMHO you can submit it. > > Thanks, > There is still time needed to queue the rebuilds. I am happy to wait post-branch, but if others disagree I can submit it now. Best regards, Julian

If we push ffmpeg 2.1 before we branch, we would ship F20 with a broken VLC, in that case? I vote that we branch sooner than later, since Beta is scheduled to ship in a month. Pushing back the branch date even further seems risky. - Ken

On Ter, 2013-10-29 at 14:32 -0600, Ken Dreyer wrote: > If we push ffmpeg 2.1 before we branch, we would ship F20 with a > broken VLC, in that case? No, of course we won't ship VLC broken . We just ship F20 in day of release or very closer until then we have time to fix VLC .

On Qua, 2013-10-30 at 07:22 +0100, Julian Sikorski wrote: > W dniu 29.10.2013 22:11, Sérgio Basto pisze: > > On Ter, 2013-10-29 at 14:32 -0600, Ken Dreyer wrote: > >> If we push ffmpeg 2.1 before we branch, we would ship F20 with a > >> broken VLC, in that case? > > > > No, of course we won't ship VLC broken . > > > > We just ship F20 in day of release or very closer until then we have > > time to fix VLC . > > > I have just confirmed that VLC is not broken, it builds. I have cooked > up a mock config containing a mix of F20 fedora repos and rawhide > rpmfusion ones, and VLC was built successfully. I am rebuilding > everything else as we speak. The results are likely to be even better > than before, but I would like to be absolutely certain. Hi x264 stable git version just updated, some minutes ago , so I have x264-0.138-1.20131030gitc628e3b.fc19.src.rpm to submit . May be do all mass rebuild together we will have less work , what do you think ? About if we submit or not ? , don't want sounds rude, but my opinion is : what we are waiting for ? :) May I bootstrap x264 ?

W dniu 30.10.2013 22:18, Nicolas Chauvet pisze: > 2013/10/30 Sérgio Basto <sergio(a)serjux.com > <mailto:sergio@serjux.com>> > > On Qua, 2013-10-30 at 07:22 +0100, Julian Sikorski wrote: > > W dniu 29.10.2013 22:11, Sérgio Basto pisze: > > > On Ter, 2013-10-29 at 14:32 -0600, Ken Dreyer wrote: > > >> If we push ffmpeg 2.1 before we branch, we would ship F20 with a > > >> broken VLC, in that case? > > > > > > No, of course we won't ship VLC broken . > > > > > > We just ship F20 in day of release or very closer until then we have > > > time to fix VLC . > > > > > I have just confirmed that VLC is not broken, it builds. I have cooked > > up a mock config containing a mix of F20 fedora repos and rawhide > > rpmfusion ones, and VLC was built successfully. I am rebuilding > > everything else as we speak. The results are likely to be even better > > than before, but I would like to be absolutely certain. > > Hi x264 stable git version just updated, some minutes ago , so I have > x264-0.138-1.20131030gitc628e3b.fc19.src.rpm to submit . > > May be do all mass rebuild together we will have less work , what do you > think ? > > About if we submit or not ? , don't want sounds rude, but my opinion > is : what we are waiting for ? :) > > May I bootstrap x264 ? > > I'm not against it, but I should mention that there are few runtime > issue that can arise even if the package is building fine. (such the one > described in the ffmpeg2theora bugreport). > > There is also an issue with gpac that trigger a patch in x264. I really > think gpac is culpid here (and shouldn't rely on libpng or else). Any > chances to fix it on your side ? > > Beside that I'm fine with the update. > Vlc 2.1.1 should rise-up soon, but the rdp API issue that is only in > rawhide will not be fixed. librdp failed to version it's api appropriately. > > Thx for the hard work. > > > Nicolas (kwizart) > With librdp out of the way, it looks as follows: $ find -name success | sort ./audacious-plugins-freeworld-3.4.1-1.fc20/success ./chromaprint-tools-1.0-2.fc20/success ./dvbcut-0.6.1-14.svn179.fc20/success ./dvdstyler-2.6-0.1_rc2.fc20/success ./ffmpeg-2.1-1.fc20/success ./ffmpeg2theora-0.29-7.fc20/success ./ffmpegthumbs-4.11.1-1.fc20/success ./gpac-0.5.0-7.20130914svn.fc20/success ./guvcview-1.6.1-6.fc20/success ./libquicktime-1.2.4-12.fc20/success ./lightspark-0.7.2-4.20130827git.fc20/success ./minidlna-1.1.0-2.fc20/success ./mlt-0.9.0-1.fc20/success ./moc-2.5.0-0.10.beta1.fc20/success ./mpd-0.18-0.1.git0e0be02.fc20/success ./mplayer-1.1-14.20130811svn.fc20/success ./mpv-0.1.7-4.fc20/success ./openmw-0.26.0-6.fc20/success ./qmmp-plugins-freeworld-0.7.2-2.fc20/success ./vlc-2.1.0-2.fc20/success ./wxsvg-1.2.1-1.fc20/success ./x264-0.136-1.20131005git3361d59.fc20/success ./xbmc-13.0-0.1.Gotham_alpha8.fc20/success ./xine-lib-1.2.4-2.fc20/success $ find -name fail | sort ./acoustid-fingerprinter-0.6-5.fc20/fail ./bino-1.4.2-4.fc20/fail ./bombono-dvd-1.2.2-4.fc20/fail ./ffmpegthumbnailer-2.0.8-6.fc20/fail ./kmediafactory-0.8.1-9.fc20/fail If we do this, we should definitely do x264 first to save time. I think runtime issues can be taken care of later, given they don't break our buildroot.

On Qui, 2013-10-31 at 07:45 +0100, Julian Sikorski wrote: > we should definitely do x264 first to save time. OK!, x264 built with bootstrap , we can follow, this wiki page http://rpmfusion.org/ImportantDependencyLists first paragraph Mass rebuild when bumping SO version of x264 and ffmpeg . Thanks and best regards,

On Sáb, 2013-11-02 at 20:01 +0100, Julian Sikorski wrote: > W dniu 02.11.2013 02:52, Sérgio Basto pisze: > > On Qui, 2013-10-31 at 07:45 +0100, Julian Sikorski wrote: > >> we should definitely do x264 first to save time. > > > > OK!, x264 built with bootstrap , we can follow, this wiki page > > http://rpmfusion.org/ImportantDependencyLists first paragraph > > Mass rebuild when bumping SO version of x264 and ffmpeg . > > > > Thanks and best regards, > > > ffmpeg build submitted. I will update mplayer later. Hi, seems to me , ffmpeg doesn't bump so ! may I submit mjpegtools ? to update 2.0.0 to 2.1.0

On Sáb, 2013-11-09 at 09:07 +0000, Sérgio Basto wrote: > On Qui, 2013-11-07 at 16:58 +0000, Sérgio Basto wrote: > > On Sáb, 2013-11-02 at 20:01 +0100, Julian Sikorski wrote: > > > W dniu 02.11.2013 02:52, Sérgio Basto pisze: > > > > On Qui, 2013-10-31 at 07:45 +0100, Julian Sikorski wrote: > > > >> we should definitely do x264 first to save time. > > > > > > > > OK!, x264 built with bootstrap , we can follow, this wiki page > > > > http://rpmfusion.org/ImportantDependencyLists first paragraph > > > > Mass rebuild when bumping SO version of x264 and ffmpeg . > > > > > > > > Thanks and best regards, > > > > > > > ffmpeg build submitted. I will update mplayer later. > > > > Hi, seems to me , ffmpeg doesn't bump so ! > > > > may I submit mjpegtools ? to update 2.0.0 to 2.1.0 > > OK please rebuild for F20 > gstreamer-plugins-bad > gstreamer1-plugins-bad-freeworld > transcode > y4mscaler > > > The repoquery for what requires mjpegtools : > repoquery --whatrequires `repoquery --provides mjpegtools\* | grep so | > perl -pe 's/(.*?)-.*/\1*/'` --alldeps --source | sort -u | perl -pe > 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | grep -v mjpegtools > > I will update wiki http://rpmfusion.org/ImportantDependencyLists Hi, just check mjpegtools-2.1.0 integrate y4mscaler , I just diff the code between mjpegtools-2.1.0 and y4mscaler and they are equal so I think the best solution for bug https://bugzilla.rpmfusion.org/show_bug.cgi?id=3022 is Obsoletes: y4mscaler anyone against it ?

On Ter, 2013-11-19 at 22:13 +0100, Nicolas Chauvet wrote: > 2013/11/19 Sérgio Basto <sergio(a)serjux.com&gt; > On Sáb, 2013-11-09 at 09:07 +0000, Sérgio Basto wrote: > > On Qui, 2013-11-07 at 16:58 +0000, Sérgio Basto wrote: > > > On Sáb, 2013-11-02 at 20:01 +0100, Julian Sikorski wrote: > > > > W dniu 02.11.2013 02:52, Sérgio Basto pisze: > > > > > On Qui, 2013-10-31 at 07:45 +0100, Julian Sikorski > wrote: > > > > >> we should definitely do x264 first to save time. > > > > > > > > > > OK!, x264 built with bootstrap , we can follow, this > wiki page > > > > > http://rpmfusion.org/ImportantDependencyLists first > paragraph > > > > > Mass rebuild when bumping SO version of x264 and > ffmpeg . > > > > > > > > > > Thanks and best regards, > > > > > > > > > ffmpeg build submitted. I will update mplayer later. > > > > > > Hi, seems to me , ffmpeg doesn't bump so ! > > > > > > may I submit mjpegtools ? to update 2.0.0 to 2.1.0 > > > > OK please rebuild for F20 > > gstreamer-plugins-bad > > gstreamer1-plugins-bad-freeworld > > transcode > > y4mscaler > > > > > > The repoquery for what requires mjpegtools : > > repoquery --whatrequires `repoquery --provides mjpegtools\* > | grep so | > > perl -pe 's/(.*?)-.*/\1*/'` --alldeps --source | sort -u | > perl -pe > > 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | grep -v > mjpegtools > > > > I will update wiki > http://rpmfusion.org/ImportantDependencyLists > > > Hi, just check mjpegtools-2.1.0 integrate y4mscaler , I just > diff the > code between mjpegtools-2.1.0 and y4mscaler and they are equal > so I > think the best solution for bug > https://bugzilla.rpmfusion.org/show_bug.cgi?id=3022 > is Obsoletes: y4mscaler > anyone against it ? > Nope, > > > Can you make the changes from the mjpegtools side ? Done , thks BTw,

On Ter, 2013-11-19 at 23:10 +0100, Nicolas Chauvet wrote: > 2013/11/19 Sérgio Basto <sergio(a)serjux.com&gt; > On Ter, 2013-11-19 at 22:13 +0100, Nicolas Chauvet wrote: > > 2013/11/19 Sérgio Basto <sergio(a)serjux.com&gt; > > On Sáb, 2013-11-09 at 09:07 +0000, Sérgio Basto > wrote: > > > On Qui, 2013-11-07 at 16:58 +0000, Sérgio Basto > wrote: > > > > On Sáb, 2013-11-02 at 20:01 +0100, Julian > Sikorski wrote: > > > > > W dniu 02.11.2013 02:52, Sérgio Basto pisze: > > > > > > On Qui, 2013-10-31 at 07:45 +0100, Julian > Sikorski > > wrote: > > > > > >> we should definitely do x264 first to save > time. > > > > > > > > > > > > OK!, x264 built with bootstrap , we can > follow, this > > wiki page > > > > > > > http://rpmfusion.org/ImportantDependencyLists first > > paragraph > > > > > > Mass rebuild when bumping SO version of x264 > and > > ffmpeg . > > > > > > > > > > > > Thanks and best regards, > > > > > > > > > > > ffmpeg build submitted. I will update mplayer > later. > > > > > > > > Hi, seems to me , ffmpeg doesn't bump so ! > > > > > > > > may I submit mjpegtools ? to update 2.0.0 to > 2.1.0 > > > > > > OK please rebuild for F20 > > > gstreamer-plugins-bad > > > gstreamer1-plugins-bad-freeworld > > > transcode > > > y4mscaler > > > > > > > > > The repoquery for what requires mjpegtools : > > > repoquery --whatrequires `repoquery --provides > mjpegtools\* > > | grep so | > > > perl -pe 's/(.*?)-.*/\1*/'` --alldeps --source | > sort -u | > > perl -pe > > > 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | > grep -v > > mjpegtools > > > > > > I will update wiki > > http://rpmfusion.org/ImportantDependencyLists > > > > > > Hi, just check mjpegtools-2.1.0 integrate > y4mscaler , I just > > diff the > > code between mjpegtools-2.1.0 and y4mscaler and they > are equal > > so I > > think the best solution for bug > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=3022 > > is Obsoletes: y4mscaler > > anyone against it ? > > Nope, > > > > > > Can you make the changes from the mjpegtools side ? > > > Done , thks > > > BTw, > > > You should obsoletes/provide to a given version, and add a note that > this can be dropped from fedora release n+2 Should I add : Provides: y4mscaler = 9.0-14 Obsoletes: y4mscaler < 9.0-14 ? what versions should I choose ? and note could be dropped on Fedora 22 ?