Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On 12/02/13 08:21, Ian Whyman wrote: Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. It is a little bikeshed. Originally the virtual was ordered in a way, then ordered in another and now we are discussing which one is better for the user after we turned it around again. There isn't ANYTHING that is impacting users beside those that they might get the next versions of gst-libav just end up with a runtime error if they use ffmpeg (if the upstream authors follow up with their plan) or those users wanting to use mencoder might get some compile errors if I forgot to update the compatibility patch after somebody bumped w/out testing. It really boils down to decide to be extra careful with mplayer and xbmc or being extra careful with gst-libav and maybe vlc. Sadly this whole discussion turned to discussing who is right or wrong, who is the fork or not and who's an evil bastard oppressing the poor Austrian genius or not. I'm ok discussing technical merits and spend time fixing issues, not so much discussing stuff I'd rather not discuss such as if I'm an evil bastard for not working with somebody that joked about my death. lu
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Tue, Feb 12, 2013 at 2:21 AM, Ian Whyman thev00...@gentoo.org wrote: Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. I don't think the average developer is really in a good position to resolve this - it will just create a whole lot of fuss and who knows if it will come to the right resolution. If it really doesn't matter than save a lot of fuss and flip a coin. If it does matter then the maintainers of the media-video herd should resolve this That's generally where the affected packages are, but they should of course call for comments from reverse dependencies after suitably framing the issue. If anybody feels that isn't going anywhere or isn't going in the right direction and that something needs to change, they can always ask the council to take it up. They're not really the ideal ones to get involved and will probably want somebody to make a really good case for why they should step in. However, if there really is a need for some kind of democratic vote at least the problem becomes properly informing seven people and not 200. Rich
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Tue, 12 Feb 2013 12:16:22 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 12/02/13 08:21, Ian Whyman wrote: Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. It is a little bikeshed. Originally the virtual was ordered in a way, then ordered in another and now we are discussing which one is better for the user after we turned it around again. That's what he's suggesting to vote about. I consider my concerns important and, as such, will continue to use FFmpeg but e.g. your arguments are valid and important too and in the end it boils down to what one considers more important. So far I have been the only one voicing against libav being the default (besides comments on my blog) so I can live with it without vote since it is clear I am minority. Were there more people favoring FFmpeg I would say a kind of vote is needed, but so far I don't think it's worth it. There isn't ANYTHING that is impacting users beside those that they might get the next versions of gst-libav just end up with a runtime error if they use ffmpeg (if the upstream authors follow up with their plan) or those users wanting to use mencoder might get some compile errors if I forgot to update the compatibility patch after somebody bumped w/out testing. Well, this is important. You, as libav developer, could very well try to convince gst-libav people that it's stupid to ban FFmpeg for no technical reason and that the big fat warning when not using the internal version is more due to historical reasons than anything recent since all decent distributions do not use their bundled libav version. mplayer is not that libav-hater as you may think since I believe some libav-compatibility fixes landed before 1.1 (maybe not all, but at least the PIX_FMT hell was resolved). It really boils down to decide to be extra careful with mplayer and xbmc or being extra careful with gst-libav and maybe vlc. IMHO this has to be done whatever the default is. Sadly this whole discussion turned to discussing who is right or wrong, who is the fork or not and who's an evil bastard oppressing the poor Austrian genius or not. I didn't want to have it go that way. I was mainly pointing out that, personal issues apart, FFmpeg has its technical merits that are completely ignored by libav. I'm ok discussing technical merits and spend time fixing issues, not so much discussing stuff I'd rather not discuss such as if I'm an evil bastard for not working with somebody that joked about my death. +1 Alexis.
Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On 11/02/13 03:01, Alexis Ballier wrote: Sorry, I was away this week end... Not a problem, I should be reachable anytime today. This is only because libav people do not care at all about what FFmpeg defines, while FFmpeg seems to care more about its consumers and users by trying to provide a compatible ABI and API. The reasons about that could be multiple, the facts are those. If you want you application to run in both you pick the Libav API. Moreover, this is not true at all when it comes to the parts where supporting both forks is painful: libavfilter and audio resampling. It is pretty clear that the audio resampling wheel was reinvented on the libav part, with a different library name and in 95% of its use cases going from ffmpeg's audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'. Not really, the resample library idea was brewing for long even pre-fork, it got released first on FFmpeg because there is this bulimic tendency to add more features in order to be compelling in FFmpeg. I said already what happened when I started to develop the pulse capture and the generic segmenter in my github as another example of stuff developed by unrelated people and curiously landing before deemed ready by the author in ffmpeg git. (prores could be considered yet another funny example). Some parts of libavfilter also appeared later in libav, sometimes with a slightly different API, making it really awful to support both forks in applications. libavfilter is deemed still not ready for general consumption in Libav and just the set of calls that won't change (hopefully) in the future are provided. Meanwhile we are trying to make the whole buffer management less copy-happy and a little more rational. (not sure if you tried to use libavfilter but it is a _bit_ hard to use if compared to vlc filter layer and such) (I'm still looking forward a patch for xbmc and upstreamed patches for mplayer btw) I might spend a little time. it offers a more compact surface for attacks if you are really concerned about security and usually it is a little more compact If you mean that ffmpeg is libav + ffmpeg additions, then yes. However, if you are concerned by a more compact surface, then libav is not the right answer: you can very well disable selected codecs, (de)muxers, etc at build time. I even started to work on reflecting this into an ebuild some years ago before reaching the conclusion that it would be confusing for little to no gain. This can of course be done if there is some demand, but so far I have not seen any. The ebuild supports extra parameters for that specific purpose. It is funny to see how libav ignores completely ffmpeg even for bugfixes, I stumbled over this recently and it sounded familiar: http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d vs http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b now, you can look at the dates, there's a one year lag in libav for reinventing the same bugfix. This is for a format almost nobody uses, but in any case I do not consider this attitude sane. Nobody is perfect and not everybody has the time to track another project tree every day. and a bit more tested over a wider range of architectures. If you are talking about fate, then I cannot comment. fate started before the split, so I assume the owners of said test machines took them within their respective fork. That speaks a *bit* about the general support maybe? I fully agree there, but you should be careful with who you include in 'our'. In the case of a default then it is clearly 'the users'. Now, considering there are a couple (very few) of packages that do not compile with libav, do you consider having it as default a good idea? I have no opinion, I stayed out of the discussion and decision about that before because I know I have a bias. I let other people decide. Those packages can very well be fixed, but if patches do not go upstream, this is not going to work in the long term. Also, the only reason why I have not pinned those packages to depend only on media-video/ffmpeg is because libav is not the default (not entirely true btw, see later), meaning those that use libav are those that are willing to help and know what they are doing. If people are to get libav by default and then hit compile failures to be told to use ffmpeg, then it is QA 101 that these packages should be depending on media-video/ffmpeg. You can, if you really want, offset ffmpeg so it doesn't clash with Libav. ... and chrome, mplayer, xbmc use ffmpeg :=) Chrome uses its own fork, reverting some changes form FFmpeg and picking what they deem useful. mplayer changes ffmpeg when they need something as they please xbmc used the newimproved libavfilter API to access swscale, the restricted api seems to work just fine. Probably true, but I still consider a quick fix disabling the
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Mon, 11 Feb 2013 12:25:36 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 11/02/13 03:01, Alexis Ballier wrote: Sorry, I was away this week end... Not a problem, I should be reachable anytime today. Will ping you. This is only because libav people do not care at all about what FFmpeg defines, while FFmpeg seems to care more about its consumers and users by trying to provide a compatible ABI and API. The reasons about that could be multiple, the facts are those. If you want you application to run in both you pick the Libav API. Well, then this raises the question: If libav does not care about what is done around it, why should we care about libav? Moreover, this is not true at all when it comes to the parts where supporting both forks is painful: libavfilter and audio resampling. It is pretty clear that the audio resampling wheel was reinvented on the libav part, with a different library name and in 95% of its use cases going from ffmpeg's audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'. Not really, the resample library idea was brewing for long even pre-fork, it got released first on FFmpeg because there is this bulimic tendency to add more features in order to be compelling in FFmpeg. There was a need for it, FFmpeg made it available with 0.10, one year before libav-9. Why not re-using libswr into libav, possibly reworking it entirely but offering a compatible API? This all sounded to me like 'we do not care, users and applications can take the mess, it is not our problem'. There is a problem we are facing today: Some audio decoders started to output planar audio when historically ffmpeg/libav audio decoders produced only iterleaved audio, how do you suggest to fix this in applications? Manually converting planar audio to interleaved (ala mplayer)? This does not seem very future-proof, this will have to be adapted everytime a new format is added (which will not change lib major and thus break application at runtime for poor usage of the provided API). Or maybe use a library as a fallback that ensures you it will be able to convert any audio format produced by ffmpeg/libav to what you need (ala xbmc)? Which one to chose? If I want to support ffmpeg then I have to use libswr, because that is the one that has this property; If I want to support libav, then I have to use libavr... All of this because ~10 people cannot work together, well, really, thank you :) I said already what happened when I started to develop the pulse capture and the generic segmenter in my github as another example of stuff developed by unrelated people and curiously landing before deemed ready by the author in ffmpeg git. (prores could be considered yet another funny example). Can you point out any important problem? Otherwise, this is simply how open source work: this has been published with a free enough license, if I were working on these parts I'd not start from scratch but from the code available to me... If you want to avoid this, don't publish it or publish it with a restrictive license and relicense your code once pushing to libav. Another funny example are the multithreaded decoders (ffmpeg-mt), which was one of the main publicity material at the beginning of libav, and suffered from numerous problems in the early days... nevertheless it was merged by libav. You are criticizing something that has been done on both sides :) Some parts of libavfilter also appeared later in libav, sometimes with a slightly different API, making it really awful to support both forks in applications. libavfilter is deemed still not ready for general consumption in Libav and just the set of calls that won't change (hopefully) in the future are provided. Meanwhile we are trying to make the whole buffer management less copy-happy and a little more rational. (not sure if you tried to use libavfilter but it is a _bit_ hard to use if compared to vlc filter layer and such) Yes, well, if forces were not scattered due to the split then I'm pretty sure libavfilter would be in a much better state. IIRC, ffmpeg's libavfilter is much more 'copy-less' than current libav's version. [...] It is funny to see how libav ignores completely ffmpeg even for bugfixes, I stumbled over this recently and it sounded familiar: http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d vs http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b now, you can look at the dates, there's a one year lag in libav for reinventing the same bugfix. This is for a format almost nobody uses, but in any case I do not consider this attitude sane. Nobody is perfect and not everybody has the time to track another project tree every day. As a Gentoo developer, if you notice a bug in a package, usually the first thing you do is pull upstream's trunk repo and see if there is a fix available. If you don't do that,
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Mon, 11 Feb 2013 17:22:16 +0100 Peter Stuge pe...@stuge.se wrote: Alexis, Alexis Ballier wrote: All of this because ~10 people cannot work together, well, really, thank you :) Do you have experience from being in a similar situation? You are being quite judgemental. There are absolutely situations where people so different that cooperation simply can't work. It's pretty lame, but unless you yourself participate at least on the same level as everyone else (on both sides) you really don't get much of a say. Yes, sorry, I now realize what I wrote is understood differently from what I meant. I was not criticizing the people, but rather the current situation. Luca is the one to ask if you want to know more about this, certainly not me. I am simply a consumer annoyed of having to write more and more complicated code to support both sides. I am aware that the split did not come out of nothing, and considering the vast majority of core FFmpeg developers by that time are now involved in libav, libav is likely to be the side of 'those who are right'. However, as I said, maybe with an incorrect tone, I do not think libav ignoring what happens in ffmpeg to be a pragmatic attitude and believe it is mainly hurting applications trying to do their best in supporting both, and users wanting the extra bugfixes or featues from ffmpeg or the better review process from libav. The critic was directed towards this, which I believe should be orthogonal to the reasons of the split. Finally, I would really love to see some will in reopening the discussions, be it to merge back (I think that's very unlikely, but let's not lose hope) or to decide that there is nothing more to be done and find a sane way out of this lose-lose situation (soname change, or anything better). It's easy to tell people to stop fighting, just get along - but I believ that intentional fighting is quite rare. It's more likely about trying to make one's point. That requires communication, but communication is not always possible. (I don't mean transmissions back and forth, I mean desire to understand the transmissions.) For a long time I idealized open source as being an ideal community, where communication always worked because everyone wanted it to. But that's unfortunately not at all the case. Yep, thanks for shaking me on this, it seems I should reread twice before hitting send on an email since I fell in the same trap. Again, apologies if what I wrote has been taken personally, esp. to those that tried their best to avoid the split. [...] I consider FFmpeg superior, but can understand there are different opinions, however, if this is to lower the tree quality Quality is not a very helpful metric, because it means completely different things for different people. Some people value code readability, maintainability, and correctness very high, other people value having a new idea halfway implemented and released even if it only kindasorta works and is not at all reliable and not on par with previous parts of the code. I see a tendency in myself and in others to not care about what happens on the inside when thinking merely as a user. I see many many people complain about the insides when they are not happy with how it performs. I very rarely see people actually dig in to help fix up the insides. The same pattern exists in pretty much all projects that I know of, and it is quite natural - there are more users than developers. Quality here is: Everything that works with FFmpeg works with libav, and vice-versa. Once that is true, then the default can be what is deemed better. In this precise case it is controversial, so once everyone has expressed his arguments and reasons then default should be what the majority prefers (and here, it seems the majority goes with libav). [...] libav should realize they are the actual fork (this is now pretty clear since the takeover failed and ffmpeg didn't collapse...) and also rename their libraries so that the internal libav/ffmpeg fights would not affect their users anymore and projects could use what they think best... Unless libav considers the API too broken to still be functional I don't see the point of differentiation. A little bit of competition can be good overall even though it is more stressful for both sides. The most important thing is what I asked for already - That users inform themselves, and make informed decisions. For distributors it does matter: if we start to have libav-only or ffmpeg-only packages then users get the choice on what package to use, not the implementation. If there is a differentiation, then upstream decides what they think is best and that's about it. It would not kill competition, rather the contrary I believe. Alexis.
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Alexis - thanks a lot for the awesome response! Alexis Ballier wrote: 'those who are right' (Just a note that I am in no way invested in libav/ffmpeg, I merely speak from experience with another fork.) However, as I said, maybe with an incorrect tone, I do not think libav ignoring what happens in ffmpeg to be a pragmatic attitude and believe it is mainly hurting applications trying to do their best in supporting both, and users wanting the extra bugfixes or featues from ffmpeg or the better review process from libav. Thanks for clarifying that! And I completely agree with you. Especially with forks it's important to keep compatibility a high priority in all projects. The critic was directed towards this, which I believe should be orthogonal to the reasons of the split. Yes, I agree also with that. Separate issues. Finally, I would really love to see some will in reopening the discussions, I guess it was some years ago, but maybe some more time still is good. I know no details, I only recognize the pattern. For a long time I idealized open source as being an ideal community, where communication always worked because everyone wanted it to. But that's unfortunately not at all the case. Yep, thanks for shaking me on this, it seems I should reread twice before hitting send on an email since I fell in the same trap. It's easy. I did too. Again, apologies if what I wrote has been taken personally, esp. to those that tried their best to avoid the split. Not me - but if someone did feel bad about what you wrote I am very sure that they appreciate this! Quality is not a very helpful metric, because it means completely different things for different people. Quality here is: Everything that works with FFmpeg works with libav, and vice-versa. Agree API compatibility is very important. (and here, it seems the majority goes with libav) I for one am sadly uninformed and can not make a decision. :( Unless libav considers the API too broken to still be functional I don't see the point of differentiation. For distributors it does matter: if we start to have libav-only or ffmpeg-only packages then users get the choice on what package to use, not the implementation. Ah! Yes, but that is just a function of what happens upstream, and nothing that can ever really be a distribution's job to resolve. If anything, I think that incompatibilities showing through in the distribution can only help users become more informed about what happens upstream. It can be argued that they shouldn't have to be informed - but actually I don't mind that. It's good to be aware of what is going on even a few layers down. I know that this is not a very common attitude, but I think for Gentoo in particular it wouldn't be bad at all. If there is a differentiation, then upstream decides what they think is best and that's about it. It would not kill competition, rather the contrary I believe. You're right that there would possibly be more activity in both projects if they were going fast in their own direction. On the other hand that fragments the user base (applications) and everyone is already invested in the common API, so I can understand that moving away from that also isn't very desirable. Anyway - good thoughts. Thanks again! //Peter
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Your whole email is derailing a bit from discussing the code at hand and it is going deep down on the people, I'd rather not get there since it gets totally unrelated the question at hand. On 11/02/13 14:49, Alexis Ballier wrote: All of this because ~10 people cannot work together, well, really, thank you :) May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? I'm perfectly happy to develop my code as long I'm not dragged in the mud with outlandish statement or people annoying the hell of me because they want to force me to merge because would be so better. Well, you are talking to one of the two guys that spent about 3 months behind the scenes trying to compose the situation before it ended with the in theory normal demotion of a so-called Leader by democratic means. Sadly or luckily the whole thing ended with us (the majority) having to give up the name and picking a different one. Hopefully that's the last time I have to touch this point here. lu
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Luca Barbato wrote: May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? There was probably a reason for Fabrice to do that, and majority and democracy doesn't have much to do with it. It is more likely that 10 people are right than that 3 are, but a group of 10 is still quite small. I wouldn't mind reading about the backstory. Do you know of some good links beyond the two that were posted already? I'm perfectly happy to develop my code as long I'm not dragged in the mud with outlandish statement or people annoying the hell of me because they want to force me to merge because would be so better. Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. Well, you are talking to one of the two guys that spent about 3 months behind the scenes trying to compose the situation before it ended with the in theory normal demotion of a so-called Leader by democratic means. I don't think open source neccessarily is democracy, and of course a disagreement about something fairly fundamental such as that can be more than enough to cause a fork. Sadly or luckily the whole thing ended with us (the majority) having to give up the name and picking a different one. I think the name itself doesn't matter much (FWIW I think libav is a much better name) but API compatibility is a big deal, and all branches should really make an effort to stay compatible. //Peter
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Mon, 11 Feb 2013 22:04:43 +0100 Luca Barbato lu_z...@gentoo.org wrote: Your whole email is derailing a bit from discussing the code at hand and it is going deep down on the people, I'd rather not get there since it gets totally unrelated the question at hand. I'm not sure if you read my reply, but it was not meant at all as going down on the people. I realized it was understood as such and apologized, and apologize again here. On 11/02/13 14:49, Alexis Ballier wrote: All of this because ~10 people cannot work together, well, really, thank you :) May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? I'm perfectly happy to develop my code as long I'm not dragged in the mud with outlandish statement or people annoying the hell of me because they want to force me to merge because would be so better. It would be better. Nobody wants to force you to do anything though. I guess that answers my question on a possible reopening of the discussions. Well, you are talking to one of the two guys that spent about 3 months behind the scenes trying to compose the situation before it ended with the in theory normal demotion of a so-called Leader by democratic means. To be honest, I never understood why this had to be done by a takeover with such a majority of people, and always wondered why what seen publicly was only a poor leader asking for democracy but demoted by force (exagerating a bit). This surely encouraged people to support him. I guess I should ask you for more details in private. Alexis.
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On 11/02/13 22:33, Peter Stuge wrote: Luca Barbato wrote: May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? There was probably a reason for Fabrice to do that, and majority and democracy doesn't have much to do with it. It is more likely that 10 people are right than that 3 are, but a group of 10 is still quite small. I wouldn't mind reading about the backstory. Do you know of some good links beyond the two that were posted already? The reason behind Fabrice actions is probably the same behind me trying for 3 months to not having to go the way it went. I got to change my mind since I was involved, Fabrice hadn't been since ages and he is doing something totally different nowadays. Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. It is not related to users, is related to me being called as swine a traitor and having death threats. *Slightly* less technical than discussing API. I don't think open source neccessarily is democracy, and of course a disagreement about something fairly fundamental such as that can be more than enough to cause a fork. The rules in Libav are quite well defined and decently enforced. Again, if you have ~15 people and one is deemed misbehaving by more than 10, which is the fork? lu
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Luca Barbato wrote: Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. It is not related to users, I was trying to come back on topic. :) is related to me being called as swine a traitor and having death threats. *Slightly* less technical than discussing API. That is of course not acceptable under any circumstance. I'm sorry to hear that you had to deal with that. :( I don't think open source neccessarily is democracy, and of course a disagreement about something fairly fundamental such as that can be more than enough to cause a fork. The rules in Libav are quite well defined and decently enforced. Again, if you have ~15 people and one is deemed misbehaving by more than 10, which is the fork? The fork is always the younger group, but who is right and wrong is another matter. //Peter
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. Sometimes it seems that endless mailing list threads are the Gentoo way, its a surprise we get anything done! Ian
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Sat, 09 Feb 2013 15:12:15 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 08/02/13 22:46, Alexis Ballier wrote: On Fri, 08 Feb 2013 22:41:04 +0100 Maciej Mrozowski reave...@gmail.com wrote: On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. Not really. I was promised a discussion that hasn't happened yet. I'm available for discussion anytime, I got a little busy in the past days and I will busy the next 3 days, but I should be available today evening or now. Sorry, I was away this week end... I stated already what I think about the whole discussion in a blog post. I'm not fond of discussions via blog posts and do not think it is the right media. I wrote one only to make it clear the decision was not anything near a general consensus, when Tomás made it sound like it was. To summarize it my take is quite simple, Libav leads the way regarding the main API, This is only because libav people do not care at all about what FFmpeg defines, while FFmpeg seems to care more about its consumers and users by trying to provide a compatible ABI and API. Moreover, this is not true at all when it comes to the parts where supporting both forks is painful: libavfilter and audio resampling. It is pretty clear that the audio resampling wheel was reinvented on the libav part, with a different library name and in 95% of its use cases going from ffmpeg's audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'. Some parts of libavfilter also appeared later in libav, sometimes with a slightly different API, making it really awful to support both forks in applications. (I'm still looking forward a patch for xbmc and upstreamed patches for mplayer btw) it offers a more compact surface for attacks if you are really concerned about security and usually it is a little more compact If you mean that ffmpeg is libav + ffmpeg additions, then yes. However, if you are concerned by a more compact surface, then libav is not the right answer: you can very well disable selected codecs, (de)muxers, etc at build time. I even started to work on reflecting this into an ebuild some years ago before reaching the conclusion that it would be confusing for little to no gain. This can of course be done if there is some demand, but so far I have not seen any. It is funny to see how libav ignores completely ffmpeg even for bugfixes, I stumbled over this recently and it sounded familiar: http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d vs http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b now, you can look at the dates, there's a one year lag in libav for reinventing the same bugfix. This is for a format almost nobody uses, but in any case I do not consider this attitude sane. and a bit more tested over a wider range of architectures. If you are talking about fate, then I cannot comment. fate started before the split, so I assume the owners of said test machines took them within their respective fork. I'm not for removing ffmpeg overnight since there are features that might be of use and I'm not so hypocrite to value diversity only when it is in favor of my interests. Nobody talked about removing anything :) That said as long the two project are compatible having one or another as default is just a matter of making our life easier. I fully agree there, but you should be careful with who you include in 'our'. In the case of a default then it is clearly 'the users'. Now, considering there are a couple (very few) of packages that do not compile with libav, do you consider having it as default a good idea? Those packages can very well be fixed, but if patches do not go upstream, this is not going to work in the long term. Also, the only reason why I have not pinned those packages to depend only on media-video/ffmpeg is because libav is not the default (not entirely true btw, see later), meaning those that use libav are those that are willing to help and know what they are doing. If people are to get libav by default and then hit compile failures to be told to use ffmpeg, then it is QA 101 that these packages should be depending on media-video/ffmpeg. [...] Few large projects such as VLC and Gstreamer switched to Libav as their default. ... and chrome, mplayer, xbmc use ffmpeg :=) also as I said in another email, I have yet to see a libav based vlc release. Since Libav is the no-frills variant, notwithstanding the interesting campaign of we have more security11ein! less stuff should break since it is usually more tested and once we gather the samples triggering a crash usually we do not stop preventing that single
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 08/02/13 22:46, Alexis Ballier wrote: On Fri, 08 Feb 2013 22:41:04 +0100 Maciej Mrozowski reave...@gmail.com wrote: On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. Not really. I was promised a discussion that hasn't happened yet. I'm available for discussion anytime, I got a little busy in the past days and I will busy the next 3 days, but I should be available today evening or now. I stated already what I think about the whole discussion in a blog post. To summarize it my take is quite simple, Libav leads the way regarding the main API, it offers a more compact surface for attacks if you are really concerned about security and usually it is a little more compact and a bit more tested over a wider range of architectures. I'm not for removing ffmpeg overnight since there are features that might be of use and I'm not so hypocrite to value diversity only when it is in favor of my interests. That said as long the two project are compatible having one or another as default is just a matter of making our life easier. I'm upstream for Libav and a good number of Libav developers are Gentoo users, including Gentoo on special platforms (e.g. aarch64). Few large projects such as VLC and Gstreamer switched to Libav as their default. Since Libav is the no-frills variant, notwithstanding the interesting campaign of we have more security11ein! less stuff should break since it is usually more tested and once we gather the samples triggering a crash usually we do not stop preventing that single crash but the whole class of possible defect (see my work on mov as an example). I cannot and will not say that Libav is perfect or that no bugs are introduced on our side and other outlandish statements, but within my biased point of view I would expect a better experience for the user not caring about which library to use. If you want to discuss on #gentoo-media ping me within 30 min or in 2 hours. I hope somebody not Libav nor FFmpeg committer could come up with a pros-cons list. lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Sat, Feb 9, 2013 at 9:12 AM, Luca Barbato lu_z...@gentoo.org wrote: I hope somebody not Libav nor FFmpeg committer could come up with a pros-cons list. ++, but frankly the committers are probably in the best place to do any evaluation even if they likely have some bias. If you wanted to delve into the merits of portage vs paludis you'd be far more informed by a discussion between the respective devs (even if flames are involved) than listening to some Ubuntu users go on about which ones were the ricers. Keeping things civil of course is desirable all the same. A wiki page might be a good place for this. Perhaps we should have some category for point-in-time analyses/evaluations/etc when things like this come up. A page like this might be something that gets attention from the linux community in general. If we want it to be anything other than a raging flamewar it might require moderation, and a lot of sticking to the facts and looking at it pragmatically from a what makes sense for a distro standpoint rather than which is the better project standpoint. Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. I mean: You are saying that given two options, Gentoo will do whatever major distros are doing. (Never mind that Gentoo *is* a major distro, and whatever Gentoo does generates collective bias just like whatever any other distro does.) We are not, let's not go too far, please. Oops, I forgot - that would mean actually having to *get informed* first. We as gentoo must certainly avoid getting informed at all cost111oneone Are you *really* quite serious? Please explain yourself. If you disagree with that and you don't want your lead to make that decision Hm? Where can I learn more about the lead ? So it is a single person's decision, and not we as gentoo that decides? I'd like to understand how this decision making process actually works. Does anyone know? It depends - in distro-wide, package-tree-wide matters we have Gentoo Council. In local matters like this - who does the job decides. Tomáš does the job - he decides. which you and I both don't want. Guess what - I have been on the receiving end of the arguably insanely lame mainstream attitude that you support, and honestly it fucking broke my heart that people working on Linux distributions (it wasn't just Gentoo, it was *every* distro) would be so genuinely uninterested in what happens upstream, especially at a time where a downstream decision may carry a bit of extra weight. I do not want that. (Around the time this happened to me I wrote roughly the same in a private email to developers of another distribution which shall remain unnamed. I found that email in a pastebin a few days later.) It is long since clear to me that I have much too high expectations on people. But are you *REALLY* not able to do *any* better than default will be what major distros use ? Seriously? Seriously you should take a deep breath, walk a dog maybe :) regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Fri, 08 Feb 2013 22:41:04 +0100 Maciej Mrozowski reave...@gmail.com wrote: On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. Not really. I was promised a discussion that hasn't happened yet. [...] If you disagree with that and you don't want your lead to make that decision Hm? Where can I learn more about the lead ? So it is a single person's decision, and not we as gentoo that decides? I'd like to understand how this decision making process actually works. Does anyone know? It depends - in distro-wide, package-tree-wide matters we have Gentoo Council. In local matters like this - who does the job decides. Tomáš does the job - he decides. Everyone can do the job to switch defaults :) A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? I mean: You are saying that given two options, Gentoo will do whatever major distros are doing. (Never mind that Gentoo *is* a major distro, and whatever Gentoo does generates collective bias just like whatever any other distro does.) How about making an informed decision instead? Oops, I forgot - that would mean actually having to *get informed* first. We as gentoo must certainly avoid getting informed at all cost111oneone Are you *really* quite serious? Please explain yourself. If you disagree with that and you don't want your lead to make that decision Hm? Where can I learn more about the lead ? So it is a single person's decision, and not we as gentoo that decides? I'd like to understand how this decision making process actually works. Does anyone know? which you and I both don't want. Guess what - I have been on the receiving end of the arguably insanely lame mainstream attitude that you support, and honestly it fucking broke my heart that people working on Linux distributions (it wasn't just Gentoo, it was *every* distro) would be so genuinely uninterested in what happens upstream, especially at a time where a downstream decision may carry a bit of extra weight. I do not want that. (Around the time this happened to me I wrote roughly the same in a private email to developers of another distribution which shall remain unnamed. I found that email in a pastebin a few days later.) It is long since clear to me that I have much too high expectations on people. But are you *REALLY* not able to do *any* better than default will be what major distros use ? Seriously? //Peter
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Dne St 16. ledna 2013 17:09:07, Alexis Ballier napsal(a): On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) Did you read the msg, announced later on, i am just preparing that shit because now I have time. Given that its masked and does not affect existing installs it can stay like this forever. Also if you read planet you would see I stated it on a blog yesterday, preparation of all moves take some time. Also it will be discussed on the dev in near future. I don't have too much of the time and sending mails to -dev takes some preparations if you don't want them turn into huge bikeshed. More seriously: Why ? Who decided this ? Let's be realistic, both upstreams claim they're better than the other in one way or another, and let's think like serious downstreams, not like upstream playground. I do think like serious downstream. Thus tracking what major distros do. Given fedora switched and debian too we ough to do it at some point too. Also quite few upstreams are migrating and few staying so there is a tie. But we have to work on supporting both which currently you don't (see bellow). As a downstream, I can see plenty of reasons against, but none in favor of this change: - There are still a couple of non-trivial packages that need to be fixed to work with libav while I don't know any that works with libav but not ffmpeg. Nice from you that you didnt bother to check out if it works or not because I do it quite often, so does tinderbox from Diego. Every time i bump shit I have to compile it in two virtuals just to please both camps. Lets not forget how carefull you were when commiting to xbmc where you completely fucked stable ebuild without even letting anyone know [1]. From my checking only package right now not building with stable libav is again XBMC (in testing only). If there is something more open bugs in bugize. - All (but the one discovered in Nov. 2012) of the security issues fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 (!!) for ffmpeg according to the website... 8 months before... So what? Checking their importance yea we ride it straight to stable on Gentoo, but security relevance would not deem any maintenance update only to be done with next proposed maintenance one (eg when there is something important to fix) because most of them look . I can waste time to look the other way around and show you broken code in ffmpeg which happened after broken merge from libav but lets not turn this into a piss contest. Basically this having two libraries hurt everyone, but both forks are on par and we as gentoo will provide both while preffered default will be what major distros use. If you disagree with that and you don't want your lead to make that decision, which you and I both don't want. I don't want Luca being blamed that he is evil libav dev who does this just to make more share for his pet project. We can wait with dealing this for a bit and propose it for council meeting. We vote about lots and lots of stuff there and another thread about two ffmpeg implems on g-dev will do just fine, but it will be hell of a bikeshed :-) Tom [1] https://bugs.gentoo.org/show_bug.cgi?id=443006
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 16 January 2013 20:09, Alexis Ballier aball...@gentoo.org wrote: On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) More seriously: Why ? Who decided this ? I agree. This is a big change so there should be a discussion about this or at least an announcement that this is going to happen on the Xth of February. Did you actually test that the tree is ready for libav as the default ffmpeg provider? -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
2013/1/17 Markos Chandras hwoar...@gentoo.org: On 16 January 2013 20:09, Alexis Ballier aball...@gentoo.org wrote: On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) More seriously: Why ? Who decided this ? I agree. This is a big change so there should be a discussion about this or at least an announcement that this is going to happen on the Xth of February. Did you actually test that the tree is ready for libav as the default ffmpeg provider? Yep I did test it. On stable there is nothing broken and right now even mplayer1 compiles fine. On testing there should be nothing broken apart from xbmc, where Alexis is one of upstream devs and he seems not to give fuck about making it work under both. Also Samuli broke it yesterday because he seems not to be bothered about fixing reverse dependencies with cdio update (but again it seems simple to test and fix which will be done when I am not working and have time to test it properly). So yes it works and should not pose any issues to user. I also announced it over blog to get people report more issues they find out so I can be really sure it works out. It turned out the mplayer1 really needs to work under both, which I patched yesterday for stable libav and Luca today for masked libav to work. So overall we are in green numbers if few people didn't break it on purpose or just for the ignorance. The only weird stuff might be for migrating users that they have to use emerge -C ffmpeg emerge -1v libav libpostproc as a postproc is not yet split out of ffmpeg. But even that could be discussed and we can switch to split libpostproc under both libs to have matching deps (even ffmpeg has --disable-postrpoc switch :)). Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 17 January 2013 09:41, Tomáš Chvátal tomas.chva...@gmail.com wrote: I agree. This is a big change so there should be a discussion about this or at least an announcement that this is going to happen on the Xth of February. Did you actually test that the tree is ready for libav as the default ffmpeg provider? So yes it works and should not pose any issues to user. I also announced it over blog to get people report more issues they find out so I can be really sure it works out. Well, a blog post may not be the ideal way to reach a wide audience of Gentoo users. It certainly would be preferred to start a discussion in this mailing list (and/or cc'd gentoo-users). Ok since you have tested the tree against libav, I see no problem with the change but it is not my decision to make. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Ideally we would have had a discussion here, and we could still have one. On the other hand I have used libav and mplayer2 for a long time, and have not run into any problems. The only thing missing is mencoder. I'm not opposing this change, but I also don't know enough of the details of upstream differences to make a strong case for our against. Ben
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/01/13 12:02, Ben de Groot wrote: I have used libav and mplayer2 for a long time, and have not run into any problems. The only thing missing is mencoder. +1 - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlD33xwACgkQRtClrXBQc7WyKwD9EK7AjiRlw4Gcmc9+Vew8fD7H 4zzoj1H48FbXCjtLqLwA/izLXX8iayZHubgcwx1azfeOpzbs1bZTKrmyu03PiZSB =Kp7w -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
2013/1/17 Ben de Groot yng...@gentoo.org: On the other hand I have used libav and mplayer2 for a long time, and have not run into any problems. The only thing missing is mencoder. Which is sovled by the mplayer1 supporting libav since yesterday. :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 17/01/2013 06:31, Samuli Suominen wrote: The tree definately isn't ready for libav so +1 from me, I almost changed it back myself already but to avoid stupid commit wars didn't. I disagree with the tree isn't ready for libav — I can add myself to Ben and Alexander on having used libav for a long time at this point (given I'm also one of the original split team!). But also, if you say that the tree isn't ready because of the bugs I opened — remember that I'm not going to test ffmpeg any time soon. I do reserve the right to not give a damn about software whose authors insulted me more than a few times so ffmpeg is blacklisted on my tinderbox. All the tree is tested with libav — and most of it works fine, with the exception of libav-9 (because of the new API). Interestingly enough, ffmpeg-0.11/1 has mostly same problems as libav-9, so the bugs can easily be shared across the two, so if it's not ready for one, it can't be ready for the other. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thu, 17 Jan 2013 10:41:58 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: [...] On testing there should be nothing broken apart from xbmc, where Alexis is one of upstream devs and he seems not to give fuck about making it work under both. Please check the facts before making false claims with f* words. Thank you. A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thu, 17 Jan 2013 13:22:21 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: [...] But also, if you say that the tree isn't ready because of the bugs I opened — remember that I'm not going to test ffmpeg any time soon. I do reserve the right to not give a damn about software whose authors insulted me more than a few times so ffmpeg is blacklisted on my tinderbox. Nice mix of two different hats. I liked to think the tinderbox was something you were doing for gentoo QA, but it seems it serves also your personal wars... [...] A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 17/01/2013 14:19, Alexis Ballier wrote: Nice mix of two different hats. I liked to think the tinderbox was something you were doing for gentoo QA, but it seems it serves also your personal wars... I'm not on payroll for either hat so I don't see any conflict with that. The tinderbox is a _personal_ effort, among other reasons because otherwise I would be able to force some other developers to care about the bugs instead of closing them as NEEDINFO because they don't like the way they are presented. And I would probably be able to demand people to act on them instead of keeping 1500 of those bugs open at any time. And since I'm a person, and as I said I'm not paid to do this work (the bandwidth and hosting is sponsored by my employer, who uses libav in production, and the rest of the running costs are on me), I can't see how you expect me to disregard insults that have been pointed to me over time. ffmpeg is in the same list as paludis and will not, ever, be tested on my boxes, as long as it's a personal effort. Are you going to pay me to run it? If the answer is no, please fuck off or run your own. And I also told you this before, if you want to be so scandalized by it right now, you either have a very shallow memory or you're looking to make a mountain of a molehill. Finally, I would like to point out that I haven't said anything one way or the other regarding the default — I haven't even tried to push for the change beforehand even though that's the one I tested. I just refuted the statement of the tree not being ready for libav putting on record that there is no indication that ffmpeg's situation is much different, as it is not currently being tested by me (and nobody else is doing the testing, so there). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thu, 17 Jan 2013 14:26:54 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: [...] ffmpeg is in the same list as paludis and will not, ever, be tested on my boxes, as long as it's a personal effort. Are you going to pay me to run it? If the answer is no, please fuck off or run your own. Thank you. I was only pointing out that ffmpeg isn't a one person thing, it's much more that this one (or more) person who insulted you. I am using it, Gentoo is using it, some upstreams are using it, and all of them would benefit from a tinderbox run. What scandalizes me is that you put my work for Gentoo in the same bag as this silly ffmpeg/libav war. Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thu, 17 Jan 2013 10:41:58 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: [...] So yes it works and should not pose any issues to user. I also announced it over blog to get people report more issues they find out so I can be really sure it works out. It turned out the mplayer1 really needs to work under both, which I patched yesterday for stable libav and Luca today for masked libav to work. And this libav-9 patch actually breaks with all non-masked version of both libraries... I've just fixed this, but please stop this madness breaking everything in order to be as quick as possible to make your point... Also, please be sure to send the patches upstream. Your patch may need to be improved (heck, you lose some features with libav and that patch), Luca's one would probably be accepted quickly. Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 17/01/2013 15:00, Alexis Ballier wrote: I was only pointing out that ffmpeg isn't a one person thing, it's much more that this one (or more) person who insulted you. You weren't pointing that out at all: Nice mix of two different hats. I liked to think the tinderbox was something you were doing for gentoo QA, but it seems it serves also your personal wars... Tell me where you pointed out that ffmpeg isn't a one person thing in that phrase? Please top with the bullshit, thank you very much. I am using it, Gentoo is using it, some upstreams are using it, and all of them would benefit from a tinderbox run. And all of them are invited to either decide to let me decide how to spend my time and dime, or actually pay me for said time. What scandalizes me is that you put my work for Gentoo in the same bag as this silly ffmpeg/libav war. I haven't. Don't put words in my mouth, or in my keyboard. I have only said I don't want to care about ffmpeg, and I have the right not to as NOBODY IS PAYING ME TO DO THAT KIND OF WORK. I could realistically just stop doing any tinderboxing at all, but I keep going. I have a steady average of 1500 bugs open at any point in time and most of the times I'm the one catching issues .. I do that for free, which also means you don't get to tell me what to do any more than I get to tell you what to do. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Samuli Suominen wrote: I almost changed it back myself already but to avoid stupid commit wars didn't. Interesting comment considering how blazing fast you were to commit a change of the default for another forked project. It's just another fork, not an upgrade. Interesting comment indeed. //Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 17/01/13 15:07, Alexis Ballier wrote: On Thu, 17 Jan 2013 10:41:58 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: [...] So yes it works and should not pose any issues to user. I also announced it over blog to get people report more issues they find out so I can be really sure it works out. It turned out the mplayer1 really needs to work under both, which I patched yesterday for stable libav and Luca today for masked libav to work. And this libav-9 patch actually breaks with all non-masked version of both libraries... I've just fixed this, but please stop this madness breaking everything in order to be as quick as possible to make your point... I guess I overlooked something, thanks for fixing it. lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thu, 17 Jan 2013 15:10:18 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 17/01/2013 15:00, Alexis Ballier wrote: I was only pointing out that ffmpeg isn't a one person thing, it's much more that this one (or more) person who insulted you. You weren't pointing that out at all: Nice mix of two different hats. I liked to think the tinderbox was something you were doing for gentoo QA, but it seems it serves also your personal wars... Tell me where you pointed out that ffmpeg isn't a one person thing in that phrase? Please top with the bullshit, thank you very much. You are playing on words and becoming aggressive. I was, indeed, not 'pointing out' but rather suggesting... and maybe it wasn't clear but I wasn't writing about who develops it but rather who uses and benefits from it. I believe we all agree that ffmpeg being part of Gentoo, me caring about it, makes it fall under Gentoo QA umbrella which in turns benefits the whole community... I am using it, Gentoo is using it, some upstreams are using it, and all of them would benefit from a tinderbox run. And all of them are invited to either decide to let me decide how to spend my time and dime, or actually pay me for said time. What scandalizes me is that you put my work for Gentoo in the same bag as this silly ffmpeg/libav war. I haven't. Don't put words in my mouth, or in my keyboard. I have only said I don't want to care about ffmpeg, and I have the right not to as NOBODY IS PAYING ME TO DO THAT KIND OF WORK. It's all your right. So is mine to point out you are refusing to help me in my gentoo work because you hate upstream of the package I'm working on. I feel sad for being sent to one side of this silly war just because I'm happy with ffmpeg and want to provide the alternative (*) to our users... [...] (*) Alternative which I indeed still consider superior. This may change in the future. Alexis.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Diego Elio Pettenò posted on Thu, 17 Jan 2013 15:10:18 +0100 as excerpted: And all of them are invited to either decide to let me decide how to spend my time and dime, or actually pay me for said time. To be clear I'm not in a position to offer, and I definitely respect and value your volunteer work, but suppose someone /was/ sufficiently interested in something like ffmpeg to be willing to pay for a tinderbox run on it. What sort of pay for are we talking? Just ballpark. Beverage/dinner on me at the next conference we both attend (or Amazon wish-list book) level, week's consultancy fee level, month's consultancy-fee level, hire me for a year and we'll talk, or...?? Of course given the history here, I'd not blame you for placing a higher price on this particular package, but in general... It occurs to me that this might be more appropriately answered on your blog (I get the feed), but since it came up here, I might as well ask here. Answer here or there or not at all, your call, but it's something I've wondered occasionally when I've seen pay me and it'd be different comments, both yours and others. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Fri, Jan 18, 2013 at 1:32 AM, Duncan 1i5t5.dun...@cox.net wrote: To be clear I'm not in a position to offer, and I definitely respect and value your volunteer work, but suppose someone /was/ sufficiently interested in something like ffmpeg to be willing to pay for a tinderbox run on it. What sort of pay for are we talking? It's tricky to quantify honestly. I've been seriously thinking about it (as those who have been reading my G+ feed today noticed), and the question of how to quantify it is the one that I have no real answer for. I can give you an idea of what's involved, so that it gives an idea of why I tend to be touchy when people complain about the way I report bugs, or the choices of packages I make. For those who follow my blog, part of this has been covered already, so sorry if it feels like a re-heated soup. First of all, there's the time involved in setting up the tinderbox itself. Given that I can easily start from a known configuration, it usually does not take that much of mytime to configure it — but since keeping seeds around is pointless (they go bad too quickly), and since changing package choices often requires cleaning up everything that used the previously-chosen package, even if I wanted to set up a parallel tinderbox for ffmpeg, it'd take me one or two days just of _unmerging_ the currently-installed packages. It's not an exaggeration, last time it took 34hr to complete a --depclean on tbamd64. As of me writing this, tbhs64 (the stable-targeted tinderbox) is performing a depclean, started early this morning. It's machine time, but it needs to be monitored, so let's say that a 5% of the time is my time, and the rest is purely the machine's. Then there is the time to build all the packages, or at least the involved subset — I honestly forgot how many reverse dependencies were involved in the libav testing, but I remember that the time it took was around five days to go through all packages (and their dependencies). Again this is mostly machine time, but as those following my Twitter feed know, it's not so uncommon to have a package hogging down the queue for over 24hr if not monitored, because a test stuck, or (in the case of mldonkey) because a prompt is requested on the tty. If somebody has a good idea how to stop interactive prompts without having to detach or redirect stdout to file, it'd be nice. 7.5-12.5% of the time mine, the rest the machine? Likely. Then comes the actual timedrain: sifting through the logs, and track down the bugs — this generally has to be done while the tinderbox run, because otherwise you can easily get obsolete bugs. While I have written a tool that helps me with the analysis, it only does so in the sense of finding me which logs report failures, and pre-fills the template for reporting a bug related to said log — it does not help me with actually finding what's going on. And sometimes a build log shows a failure due to another package's build mistake. Only about half the logs that my analysis script report end up in a bug at all; for the tinderboxes as they are, I counted in the past few months an average of an hour a day spent on detective work on said logs, to get to the bugs. Now with a bit of luck, the amount of logs to sift through for an ffmpeg-targeted tinderbox would be much less than those generated by tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with a total of 10/12 hr of work all in all? I wouldn't go as far as ask for my going hourly rate, but especially for ffmpeg, it would come for something a bit higher than a dinner at the next conference — more like the travel expenses (given a conference such as FOSDEM, not SCALE, to give an idea). And before anybody tries to misrepresent what I wrote — I don't intend to charge anybody for my usual tinderbox runs; they run and they'll keep running for as long as I have time to dedicate to them. As I said before, my employer (who's sponsoring hosting and bandwidth) uses libav in production, so it actually influences further the fact that the default run is libav-bound — although you could call it a self-fulfilling prophecy, as the fact they run libav is further influenced by the fact that they employ me, but c'est la vie.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Diego Elio Pettenò posted on Fri, 18 Jan 2013 02:04:50 +0100 as excerpted: On Fri, Jan 18, 2013 at 1:32 AM, Duncan 1i5t5.dun...@cox.net wrote: To be clear I'm not in a position to offer, and I definitely respect and value your volunteer work, but suppose someone /was/ sufficiently interested in something like ffmpeg to be willing to pay for a tinderbox run on it. What sort of pay for are we talking? It's tricky to quantify honestly. [I] can give you an idea of what's involved, so that it gives an idea of why I tend to be touchy when people complain about the way I report bugs, or the choices of packages I make. For those who follow my blog, part of this has been covered already, so sorry if it feels like a re-heated soup. Thanks. Yes, part of it's rehash (I do follow the blog), but IMO there's quite some value in getting the information out there. It can't hurt having a bit of background for the bug reports, and with any luck, it'll be interesting enough and make the concept real enough to get others considering running their own tinderboxes. Now with a bit of luck, the amount of logs to sift through for an ffmpeg-targeted tinderbox would be much less than those generated by tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with a total of 10/12 hr of work all in all? I wouldn't go as far as ask for my going hourly rate, but especially for ffmpeg, it would come for something a bit higher than a dinner at the next conference — more like the travel expenses (given a conference such as FOSDEM, not SCALE, to give an idea). So several days of machine time, and /very/ conservatively, at least a work day of your time, more likely 1.5-2 workdays, maybe half a week. Yeah, that's rather more than a dinner with beverage of choice... especially for something you'd rather not be working on anyway. At least readers can have some ballpark idea of what's involved now, both from you personally, and what the cost of a sponsored run might look like. And before anybody tries to misrepresent what I wrote — I don't intend to charge anybody for my usual tinderbox runs; they run and they'll keep running for as long as I have time to dedicate to them. Thanks for the answer. With any luck, someone out there will find the information useful and you'll get a contact or two offering to sponsor a run, now that there's a bit more information out there, more publicly available. A few more tinderbox runs and the resulting fixes certainly won't hurt gentoo's health, either, so everyone benefits. =:^) One more question. I've read about various tinderbox runs, and now we know they take several days of machine time plus say 1-2 (surely more for the really involved stuff, glibc and gcc touch about everything...) days of your time. Are you queued up with tinderbox runs, or is there room for more demand? If someone like Shuttleworth came along and offered to sponsor you to work on gentoo and tinderboxes full time, how far up could it scale before it required more people, and would there be ever more tinderbox possibilities or would the law of diminishing returns kick in? Would you consider that or find it too boring or depressing to do full time? Reworded, how well does it scale, and how close are you/we to a knee, beyond that of your limited volunteer time, at least? FWIW, my own ~amd64/~x86 deployments are REMARKABLY smoother now than in the past, and I know a lot of it is due to your tinderbox runs on new gcc/ glibc, for instance, as well as your work and that of others on --as-needed and similar. (The work of Zac and others on portage, smarter config-protect, etc, has helped dramatically lower my maintenance time cost as well, and there have been many other gentoo improvements over the years, with EAPI-5 now one of the latest. Newbie gentooers these days haven't a clue, no idea what it's like compiling a mile in the snow, uphill both ways...! =:^) So I know I've directly benefited from your tinderbox runs and other projects you've done, and I really do appreciate it, especially as I know much of it is volunteer, tho some is work related but benefits gentoo as well. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) More seriously: Why ? Who decided this ? Let's be realistic, both upstreams claim they're better than the other in one way or another, and let's think like serious downstreams, not like upstream playground. As a downstream, I can see plenty of reasons against, but none in favor of this change: - There are still a couple of non-trivial packages that need to be fixed to work with libav while I don't know any that works with libav but not ffmpeg. - All (but the one discovered in Nov. 2012) of the security issues fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 (!!) for ffmpeg according to the website... 8 months before... Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 16/01/13 21:09, Alexis Ballier wrote: More seriously: Why ? Who decided this ? I never pushed my weight over it before since as you are involved in FFmpeg directly, I am involved in Libav directly. Thus anything I say on this topic has a clear bias. Same goes for you. Tomas is not related to libav beside one of his core project using it by transition, so I would expect him to be less biased than us. Let's be realistic, both upstreams claim they're better than the other in one way or another, and let's think like serious downstreams, not like upstream playground. VLC uses it since ffmpeg doesn't work with rtmp properly last time they checked and other interesting situations. gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus the rename) ubuntu and debian just use Libav. As a downstream, I can see plenty of reasons against, but none in favor of this change: - There are still a couple of non-trivial packages that need to be fixed to work with libav while I don't know any that works with libav but not ffmpeg. See above for the other way round. - All (but the one discovered in Nov. 2012) of the security issues fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 (!!) for ffmpeg according to the website... 8 months before... The security game is fun. Given the number of additional features the surface impact is bigger in FFmpeg and currently all but one of the bugs claimed as security issues originate from the same guy he claim to fix them (sometimes the fix doesn't address the underlying issue but just _that_ specific sample). I'd rather avoid having another mud sliding contest. I stopped caring about FFmpeg since somebody gave a sample of his humor wishing my death. Lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Wed, 16 Jan 2013 21:39:04 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 16/01/13 21:09, Alexis Ballier wrote: More seriously: Why ? Who decided this ? I never pushed my weight over it before since as you are involved in FFmpeg directly, I am involved in Libav directly. I don't know what you mean by involved directly, but ffmpeg happens to be what I use and care about, hence I have a couple of commits there but their number is quite ridiculous in comparison. [Actually, I should be honored that you compare my involvement with yours :)] Thus anything I say on this topic has a clear bias. Same goes for you. ... but I admit I have some bias, however, I'm rather a consumer than a developer when it comes to ffmpeg and believe we need to think as consumers as a downstream distro. Tomas is not related to libav beside one of his core project using it by transition, so I would expect him to be less biased than us. Let's be realistic, both upstreams claim they're better than the other in one way or another, and let's think like serious downstreams, not like upstream playground. VLC uses it since ffmpeg doesn't work with rtmp properly last time they checked and other interesting situations. interesting, did they report it? OTOH, they switched _after_ the 2.0.5 release which happens to be the latest one. Since vlc is probably the ffmpeg/libav interface the most popular in the world (due to their windows and mac builds), I'd like to see an actual release with it and see if there is any regression before claiming they use libav. gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus the rename) you mean use libav internally? because 'per upstream desire' gst-ffmpeg or gst-libav always only worked with the internal libs :) it also appears to build and work fine with ffmpeg-0.10 ubuntu and debian just use Libav. Speaking about bias, the maintainer happens to be part of libav core developers and was even part of what is known as the 'ffmpeg coup' :) As a downstream, I can see plenty of reasons against, but none in favor of this change: - There are still a couple of non-trivial packages that need to be fixed to work with libav while I don't know any that works with libav but not ffmpeg. See above for the other way round. None of what you cited is a problem for a downstream distribution, except maybe vlc+rtmp which should be fixed regardless. xbmc and mplayer did not build last time I tried. xbmc will be a pain because it uses some libavfilter features not in libav. - All (but the one discovered in Nov. 2012) of the security issues fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 (!!) for ffmpeg according to the website... 8 months before... The security game is fun. Given the number of additional features the surface impact is bigger in FFmpeg and currently all but one of the bugs claimed as security issues originate from the same guy he claim to fix them (sometimes the fix doesn't address the underlying issue but just _that_ specific sample). I don't want to verify this and will trust you there, but I still don't consider 8 months to be a correct delay for handling a published vulnerability, whatever its origin may be. I'd rather avoid having another mud sliding contest. I stopped caring about FFmpeg since somebody gave a sample of his humor wishing my death. This is getting personal :) I'm sure the fork didn't happen because some day some devs woke up angry because they didn't have had their coffee. However, I'm also sure the fork is a pain for downstream distros and a lot of upstreams. Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 16/01/13 22:31, Alexis Ballier wrote: interesting, did they report it? OTOH, they switched _after_ the 2.0.5 release which happens to be the latest one. Since vlc is probably the ffmpeg/libav interface the most popular in the world (due to their windows and mac builds), I'd like to see an actual release with it and see if there is any regression before claiming they use libav. Reported, dismissed as bug on their side IIRC. gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus the rename) you mean use libav internally? because 'per upstream desire' gst-ffmpeg or gst-libav always only worked with the internal libs :) it also appears to build and work fine with ffmpeg-0.10 To be more clear, latest gst-libav release does not build with latest ffmpeg release, same said for the gst-libav backport. Speaking about bias, the maintainer happens to be part of libav core developers and was even part of what is known as the 'ffmpeg coup' :) Meanwhile I preferred let people pick their poison since it is easy to switch from one to another, in retrospect would had been better if I just removed ffmpeg from the tree from day 0. None of what you cited is a problem for a downstream distribution, except maybe vlc+rtmp which should be fixed regardless. xbmc and mplayer did not build last time I tried. xbmc will be a pain because it uses some libavfilter features not in libav. mplayer2 works decently here. I didn't try to look at xbmc yet. I don't want to verify this and will trust you there, but I still don't consider 8 months to be a correct delay for handling a published vulnerability, whatever its origin may be. Crashes are always bad, we fix a lot of them every day, we obviously introduce few new since we aren't perfect, calling all of them security problems is a tad extreme in my opinion. The problem with the published vulnerabilities had been usually us being prevented from accessing the example vectors, now the situation is way better. I'm sure the fork didn't happen because some day some devs woke up angry because they didn't have had their coffee. However, I'm also sure the fork is a pain for downstream distros and a lot of upstreams. The rationale is on libav.org/about.html, I spent about 3 months trying to prevent it. I failed. lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Wed, 16 Jan 2013 22:52:52 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 16/01/13 22:31, Alexis Ballier wrote: interesting, did they report it? OTOH, they switched _after_ the 2.0.5 release which happens to be the latest one. Since vlc is probably the ffmpeg/libav interface the most popular in the world (due to their windows and mac builds), I'd like to see an actual release with it and see if there is any regression before claiming they use libav. Reported, dismissed as bug on their side IIRC. Hard to blame anyone without more info nor a description of the problem, it can even be a too quick analysis before dismissing it. gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus the rename) you mean use libav internally? because 'per upstream desire' gst-ffmpeg or gst-libav always only worked with the internal libs :) it also appears to build and work fine with ffmpeg-0.10 To be more clear, latest gst-libav release does not build with latest ffmpeg release, same said for the gst-libav backport. meaning bug #447838 ??? are you kidding ? Speaking about bias, the maintainer happens to be part of libav core developers and was even part of what is known as the 'ffmpeg coup' :) Meanwhile I preferred let people pick their poison since it is easy to switch from one to another, in retrospect would had been better if I just removed ffmpeg from the tree from day 0. Fortunately we're not debian and do not like when people impose their choice on us. None of what you cited is a problem for a downstream distribution, except maybe vlc+rtmp which should be fixed regardless. xbmc and mplayer did not build last time I tried. xbmc will be a pain because it uses some libavfilter features not in libav. mplayer2 works decently here. I didn't try to look at xbmc yet. mplayer2 is a good player but unfortunately for me it doesn't come with a mencoder2. Being the one that did most of the porting to the recent APIs of libav* for xbmc, I can assure you that any help is very welcome to have a sane support for libav. I don't want to verify this and will trust you there, but I still don't consider 8 months to be a correct delay for handling a published vulnerability, whatever its origin may be. Crashes are always bad, we fix a lot of them every day, we obviously introduce few new since we aren't perfect, calling all of them security problems is a tad extreme in my opinion. It's probably the fault of the current trend of tagging most of the crashes as sec. issues. The problem here is that a crash fix is almost invisible, while a CVE gets very high visibility, and leaving time to malicious people for reinventing an attack is bad. The problem with the published vulnerabilities had been usually us being prevented from accessing the example vectors, now the situation is way better. This is news to me, but good it improved. [...] A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 16/01/13 22:09, Alexis Ballier wrote: On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) The tree definately isn't ready for libav so +1 from me, I almost changed it back myself already but to avoid stupid commit wars didn't. I have no plans testing anything against libav anytime soon, and same for mplayer2 for same reasons, no mencoder. It's just another fork, not an upgrade. Regards, Happy user of ffmpeg and mplayer-original - Samuli
