Re: Update ffmpeg in F24 to 3.1.x ?
W dniu 23.11.2016 o 09:14, Xavier Bachelot pisze: > Hi, > > On 23/11/2016 08:41, Michael Cronenworth wrote: >> On 10/14/2016 11:09 AM, Sérgio Basto wrote: >>> I think we can perform the mass rebuild (or not) just in F24 without >>> touching F25 and rawhide. >> >> May I ask why a mass rebuild was not performed? >> >> I just uncovered an issue with the FFMpeg 3.1 update. Kodi core dumps >> when attempting to play MPEG2 streams. A rebuild fixes it. I'm pushing >> through one now for F24. >> >> In the future let's please be more careful with these updates. There >> certainly were some small ABI changes and upstream dropped the ball on >> announcing them. >> >> Thanks, >> Michael > > There are tools to check for ABI changes, announced or not. > http://upstream.rosalinux.ru/index.html > > Here's the link for ffmpeg : > https://abi-laboratory.pro/tracker/timeline/ffmpeg/ > > Regards, > Xavier > Thanks for the link! Having said that, the tracker shows that no symbols were removed so we would have been at a loss anyway. Best regards, Julian
Re: Update ffmpeg in F24 to 3.1.x ?
Hi, On Qua, 2016-11-23 at 09:14 +0100, Xavier Bachelot wrote: > Hi, > > On 23/11/2016 08:41, Michael Cronenworth wrote: > > > > On 10/14/2016 11:09 AM, Sérgio Basto wrote: > > > > > > I think we can perform the mass rebuild (or not) just in F24 > > > without > > > touching F25 and rawhide. > > May I ask why a mass rebuild was not performed? > > > > I just uncovered an issue with the FFMpeg 3.1 update. Kodi core > > dumps > > when attempting to play MPEG2 streams. A rebuild fixes it. I'm > > pushing > > through one now for F24. > > > > In the future let's please be more careful with these updates. > > There > > certainly were some small ABI changes and upstream dropped the ball > > on > > announcing them. > > > > Thanks, > > Michael > There are tools to check for ABI changes, announced or not. > http://upstream.rosalinux.ru/index.html > > Here's the link for ffmpeg : > https://abi-laboratory.pro/tracker/timeline/ffmpeg/ I had move the conversation to the new thread: Updating ffmpeg to 3.2 in rawhide , we did update both ffmpegs at same time 3.2 in rawhide and : "ffmpeg-3.1.5 was submit to f24 ! Process was to update ffmpeg to 3.1.5 in f24 and mplayer/mpv because they are using private symbols, that's all . Now, how I know if any package have ffmpeg private symbols ? " I also though that we will rebuild more packages than mplayer/mpv , I also rebuilt x264 ... > Regards, > Xavier -- Sérgio M. B.
Re: Update ffmpeg in F24 to 3.1.x ?
Hi, On 23/11/2016 08:41, Michael Cronenworth wrote: > On 10/14/2016 11:09 AM, Sérgio Basto wrote: >> I think we can perform the mass rebuild (or not) just in F24 without >> touching F25 and rawhide. > > May I ask why a mass rebuild was not performed? > > I just uncovered an issue with the FFMpeg 3.1 update. Kodi core dumps > when attempting to play MPEG2 streams. A rebuild fixes it. I'm pushing > through one now for F24. > > In the future let's please be more careful with these updates. There > certainly were some small ABI changes and upstream dropped the ball on > announcing them. > > Thanks, > Michael There are tools to check for ABI changes, announced or not. http://upstream.rosalinux.ru/index.html Here's the link for ffmpeg : https://abi-laboratory.pro/tracker/timeline/ffmpeg/ Regards, Xavier
Re: Update ffmpeg in F24 to 3.1.x ?
On 10/14/2016 11:09 AM, Sérgio Basto wrote: I think we can perform the mass rebuild (or not) just in F24 without touching F25 and rawhide. May I ask why a mass rebuild was not performed? I just uncovered an issue with the FFMpeg 3.1 update. Kodi core dumps when attempting to play MPEG2 streams. A rebuild fixes it. I'm pushing through one now for F24. In the future let's please be more careful with these updates. There certainly were some small ABI changes and upstream dropped the ball on announcing them. Thanks, Michael
Re: Update ffmpeg in F24 to 3.1.x ?
On Sáb, 2016-11-12 at 09:45 +0100, Kevin Kofler wrote: > Julian Sikorski wrote: > > > > Could you please point me to a reference for this? I looked around > > a bit > > but couldn't find one. Thanks! > The original post had a quote: > > > > "There are no SONAME changes, only new symbols added to the > > libraries, > > so they're backwards compatible and no rebuild of dependencies > > should > > be required" > but don't ask me where it comes from. https://bugzilla.rpmfusion.org/show_bug.cgi?id=4145#c4 > Kevin Kofler -- Sérgio M. B.
Re: Update ffmpeg in F24 to 3.1.x ?
Julian Sikorski wrote: > Could you please point me to a reference for this? I looked around a bit > but couldn't find one. Thanks! The original post had a quote: | "There are no SONAME changes, only new symbols added to the libraries, | so they're backwards compatible and no rebuild of dependencies should | be required" but don't ask me where it comes from. Kevin Kofler
Re: Update ffmpeg in F24 to 3.1.x ?
W dniu 12.10.2016 o 16:15, Kevin Kofler pisze: > Michael Cronenworth wrote: >> This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained >> AFAIK. We can't push out a big rebuild of a major library so one, new >> package can be introduced into F24. > > Huh? Upstream says 3.1 is API- and ABI-compatible to 3.0 (with only one > application needed fixing for some reason), Could you please point me to a reference for this? I looked around a bit but couldn't find one. Thanks! so it should be perfectly > suitable as an update. This is similar to Qt upgrades that have often been > done in Fedora (where there are also a few odd packages that invariably need > rebuilding due to (ab)using private Qt APIs). > > Introducing a second package for the new version is a horrible idea, it will > lead to symbol conflicts (in applications accidentally transitively linking > both versions) and a waste of space. I would just upgrade the existing > package to the new version. > > Kevin Kofler >
Re: Update ffmpeg in F24 to 3.1.x ?
On Qui, 2016-10-13 at 10:01 +0200, Nicolas Chauvet wrote: > 2016-10-12 2:49 GMT+02:00 Sérgio Basto : > > > > Hi, > > Nicolas, ask me to bring this discussion to the mailing list . > > Nicolas sorry for the delay , I had a big cold, I'm ok now (it just > > an > > excuse :) ) > > > > OK, all story is in > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=4260 > > and in https://bugzilla.rpmfusion.org/show_bug.cgi?id=4145 > > > > and we have 48 packages depends on ffmpeg-libs. > > > > First, ABI changes of ffmpeg 3.0.x to 3.1.x ? > > "There are no SONAME changes, only new symbols added to the > > libraries, > > so they're backwards compatible and no rebuild of dependencies > > should > > be required" . "mpv will break" . > > > > My arguments, I read today > > http://fedoraproject.org/wiki/Updates_Policy#All_other_updates and > > it > > have one exceptions list, we have some items that can be applied to > > this case, like : > > > > - The update doesn't change ABI/API and nothing needs to be rebuilt > > against the new version. (almost) > > > > - The update fixes serious bugs that many fedora users are > > encountering. > Where thoses serious bugs was reported ? Is there upstream reports ? > What I would expect instead are more features instead, (and even some > features was removed such as libdcadec) > So despite there is no ABI changes, there are some behavior changes. > > > > > ffmpeg-3.0 is a major version that had short duration, it was the > > first > > version of an major version (3.0.x), so we expect have more bugs, > > also > > vlc now requires ffmpeg 3.1.x and we have to maintain it about more > > 9 > > months (F24 be an fresh version also counts). > I don't understand what you mean by "we expect to have more bugs..", > so a little history: > > Previously ffmpeg upstream didn't provide maintained branches at all. > If one distro packager wanted a rebase to a newer snapshot from > master, there are probably some API changes and very often ABI > changes > (along with new bugs and features mixed). Also if one wanted to > report > and issue upstream, the first step was to test with a recent git > snapshot. Most likely that our stable ffmpeg packages was contains > known upstream bugs that was unfixed because of that. > So the way we used to have a stabilized version was to periodically > check for api/abi snapshot, get the last commit before an abi break > and stick to this version with adding only patches and backports from > our user base reported issues. On a fedora development cycle, we > updated the newer api/abi snapshot, rebuild (and more likely patch) > all dependent applications and try to fix regression and feedbacks > from our rawhide users. > > This was lot of packager work about testing, patching, bisecting for > finding regression and all. And probably that job was done across all > ffmpeg package maintainers. So really see that having maintained > branches upstream as an enormous improvement. > Here the proposition seems to ask to withdraw all that and only pick > the last stable release everywhere. So this sounds to me that we are > going backward on the highway. > > I would also notice, that our stabilization process was very little > in > the f24 development timeframe, because of the infra issues we had > passed. So I'm expect to have a better stabilization process with f25 > and hopes to have lot of feedbacks from branches/rawhide users while > keeping users stable. (There is probably already lot of issue related > to f24 -> f25 system-upgrade migrations). > > Now that was rather general about our stabilization process, but now > from a more specific analysis on ffmpeg 3.0x and 3.1x maintained > branches, I see the same kind of fixes between branches. I think > there > is just normal bugfix . So not having 3.1x only means missing the 3.1 > specific features. So It's probably safe from ffmpeg itslef > perpective. Don't agree with this premise, they have 3.0x , because they must have it, IMHO. I choose +1 because, although we don't have any major bug, but and if we find one ? will be much more complicate to fix it (we have vlc that is not much stable) and what upstream will say first ? "please update to 3.1x". So with this scenario and in this time frame, for me, is better have F24 and F25 with same ffmpeg, is better for testing, everybody test the same thing, if some bug is found, we are in last release, could be fixed more easily. He should have better stability and functionality with 3.1x, we have some assurance that 3.1x is quiet stable. So, IMHO we are wasting time (test time) using ffmpeg 3.0x in F24. > > > > I hope have one decision, quickly and close this subject (update > > ffmpeg > > in F24 to 3.1.x ? ). > So the question is do we update 3.1x in f24 ?, my vote is the > following: > +0 > It means I don't agree with the proposition, but I won't hold it > either. > instead, I expect that people that want this proposition are actively > working on testing the pack
Re: Update ffmpeg in F24 to 3.1.x ?
On Thursday, 13 October 2016 at 10:01, Nicolas Chauvet wrote: [...] > (on a side note I would like to have a my ffmpeg-nonfree patches > reviewed/merged before any backport to f24 - rfbz#4243) I'll try to take a look at those before the weekend. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
Re: Update ffmpeg in F24 to 3.1.x ?
2016-10-12 2:49 GMT+02:00 Sérgio Basto : > Hi, > Nicolas, ask me to bring this discussion to the mailing list . > Nicolas sorry for the delay , I had a big cold, I'm ok now (it just an > excuse :) ) > > OK, all story is in > https://bugzilla.rpmfusion.org/show_bug.cgi?id=4260 > and in https://bugzilla.rpmfusion.org/show_bug.cgi?id=4145 > > and we have 48 packages depends on ffmpeg-libs. > > First, ABI changes of ffmpeg 3.0.x to 3.1.x ? > "There are no SONAME changes, only new symbols added to the libraries, > so they're backwards compatible and no rebuild of dependencies should > be required" . "mpv will break" . > > My arguments, I read today > http://fedoraproject.org/wiki/Updates_Policy#All_other_updates and it > have one exceptions list, we have some items that can be applied to > this case, like : > > - The update doesn't change ABI/API and nothing needs to be rebuilt > against the new version. (almost) > > - The update fixes serious bugs that many fedora users are > encountering. Where thoses serious bugs was reported ? Is there upstream reports ? What I would expect instead are more features instead, (and even some features was removed such as libdcadec) So despite there is no ABI changes, there are some behavior changes. > ffmpeg-3.0 is a major version that had short duration, it was the first > version of an major version (3.0.x), so we expect have more bugs, also > vlc now requires ffmpeg 3.1.x and we have to maintain it about more 9 > months (F24 be an fresh version also counts). I don't understand what you mean by "we expect to have more bugs..", so a little history: Previously ffmpeg upstream didn't provide maintained branches at all. If one distro packager wanted a rebase to a newer snapshot from master, there are probably some API changes and very often ABI changes (along with new bugs and features mixed). Also if one wanted to report and issue upstream, the first step was to test with a recent git snapshot. Most likely that our stable ffmpeg packages was contains known upstream bugs that was unfixed because of that. So the way we used to have a stabilized version was to periodically check for api/abi snapshot, get the last commit before an abi break and stick to this version with adding only patches and backports from our user base reported issues. On a fedora development cycle, we updated the newer api/abi snapshot, rebuild (and more likely patch) all dependent applications and try to fix regression and feedbacks from our rawhide users. This was lot of packager work about testing, patching, bisecting for finding regression and all. And probably that job was done across all ffmpeg package maintainers. So really see that having maintained branches upstream as an enormous improvement. Here the proposition seems to ask to withdraw all that and only pick the last stable release everywhere. So this sounds to me that we are going backward on the highway. I would also notice, that our stabilization process was very little in the f24 development timeframe, because of the infra issues we had passed. So I'm expect to have a better stabilization process with f25 and hopes to have lot of feedbacks from branches/rawhide users while keeping users stable. (There is probably already lot of issue related to f24 -> f25 system-upgrade migrations). Now that was rather general about our stabilization process, but now from a more specific analysis on ffmpeg 3.0x and 3.1x maintained branches, I see the same kind of fixes between branches. I think there is just normal bugfix . So not having 3.1x only means missing the 3.1 specific features. So It's probably safe from ffmpeg itslef perpective. > I hope have one decision, quickly and close this subject (update ffmpeg > in F24 to 3.1.x ? ). So the question is do we update 3.1x in f24 ?, my vote is the following: +0 It means I don't agree with the proposition, but I won't hold it either. instead, I expect that people that want this proposition are actively working on testing the package update and doing the needed QA in cooperation with each package maintainer if needed. I also note that I'm way too much busy with internal infra issue to back this update and the eventual regressions (on a side note I would like to have a my ffmpeg-nonfree patches reviewed/merged before any backport to f24 - rfbz#4243) Thx -- - Nicolas (kwizart)
Re: Update ffmpeg in F24 to 3.1.x ?
2016-10-12 16:15 GMT+02:00 Kevin Kofler : > Michael Cronenworth wrote: >> This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained >> AFAIK. We can't push out a big rebuild of a major library so one, new >> package can be introduced into F24. > > Huh? Upstream says 3.1 is API- and ABI-compatible to 3.0 (with only one > application needed fixing for some reason), so it should be perfectly > suitable as an update. This is similar to Qt upgrades that have often been > done in Fedora (where there are also a few odd packages that invariably need > rebuilding due to (ab)using private Qt APIs). > > Introducing a second package for the new version is a horrible idea, it will > lead to symbol conflicts (in applications accidentally transitively linking > both versions) and a waste of space. I would just upgrade the existing > package to the new version. I totally agreed with that, That's why I think we shouldn't have multiple version of ffmpeg libs in EL7 where packagers can link any version. Unfortunately this doesn't seem a common knowledge across all packagers. -- - Nicolas (kwizart)
Re: Update ffmpeg in F24 to 3.1.x ?
On 10/12/2016 09:15 AM, Kevin Kofler wrote: Huh? Upstream says 3.1 is API- and ABI-compatible to 3.0 (with only one application needed fixing for some reason), so it should be perfectly suitable as an update. This is similar to Qt upgrades that have often been done in Fedora (where there are also a few odd packages that invariably need rebuilding due to (ab)using private Qt APIs). Yes, we don't /need/ to rebuild every ffmpeg-using app. However, Kodi caches the version you compile against so it will continue to erroneously report you are using FFmpeg 3.0. Other apps, like mpv, do the same but actually fail if you use a different version at runtime. I would feel safer if we went ahead and rebuilt if it is pushed to F24. Introducing a second package for the new version is a horrible idea, it will lead to symbol conflicts (in applications accidentally transitively linking both versions) and a waste of space. I would just upgrade the existing package to the new version. We don't need to add a second package for this.
Re: Update ffmpeg in F24 to 3.1.x ?
On Wednesday, 12 October 2016 at 02:49, Sérgio Basto wrote: [...] > I hope have one decision, quickly and close this subject (update ffmpeg > in F24 to 3.1.x ? ). +1 to updating. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
Re: Update ffmpeg in F24 to 3.1.x ?
Michael Cronenworth wrote: > This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained > AFAIK. We can't push out a big rebuild of a major library so one, new > package can be introduced into F24. Huh? Upstream says 3.1 is API- and ABI-compatible to 3.0 (with only one application needed fixing for some reason), so it should be perfectly suitable as an update. This is similar to Qt upgrades that have often been done in Fedora (where there are also a few odd packages that invariably need rebuilding due to (ab)using private Qt APIs). Introducing a second package for the new version is a horrible idea, it will lead to symbol conflicts (in applications accidentally transitively linking both versions) and a waste of space. I would just upgrade the existing package to the new version. Kevin Kofler
Re: Update ffmpeg in F24 to 3.1.x ?
On Ter, 2016-10-11 at 21:37 -0500, Michael Cronenworth wrote: > On 10/11/2016 07:49 PM, Sérgio Basto wrote: > > > > the mailing list". > > > > I hope have one decision, quickly and close this subject (update > > ffmpeg > > in F24 to 3.1.x ? ). > This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained > AFAIK. We can't > push out a big rebuild of a major library so one, new package can be > introduced into > F24. > > In any case I tested Kodi 16 against ffmpeg 3.1 and it works fine. > The only problem > I see is that you pushed the master/F25 kodi branch (Kodi 17.x) over > to F24 and all > that will have to be undone. Please do not commit to the kodi branch > unless you > discuss it with me. Yes, you may have provenpackager, but please do > not abuse it. OK, no worries , anyway I not planning upgrade any version on F24 just because one rebuild, if we need rebuild. Also we can fork the git tree. I try maintain all branches in same tree like in kodi [1] but if is not possible or in this special case, I don't see a problem have an exception. [1] https://pkgs.rpmfusion.org/cgit/free/kodi.git/log/ > I'm neutral on this - leaning towards no. Wait until F25 to introduce > Telegram. F25 > is almost out. 2016-11-15 if no delays, yeah F24 have almost 4 months, after F25 released doesn't make sense to me, anyway cycle between F24 and F25 may have less of 5 months. Thanks. -- Sérgio M. B.
Re: Update ffmpeg in F24 to 3.1.x ?
On 10/11/2016 07:49 PM, Sérgio Basto wrote: the mailing list". I hope have one decision, quickly and close this subject (update ffmpeg in F24 to 3.1.x ? ). This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained AFAIK. We can't push out a big rebuild of a major library so one, new package can be introduced into F24. In any case I tested Kodi 16 against ffmpeg 3.1 and it works fine. The only problem I see is that you pushed the master/F25 kodi branch (Kodi 17.x) over to F24 and all that will have to be undone. Please do not commit to the kodi branch unless you discuss it with me. Yes, you may have provenpackager, but please do not abuse it. I'm neutral on this - leaning towards no. Wait until F25 to introduce Telegram. F25 is almost out.
