Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Sat, Apr 2, 2011 at 3:41 PM, Alexis Ballier aball...@gentoo.org wrote: On Saturday, April 02, 2011 07:02:54 AM Paweł Hajdan, Jr. wrote: On 3/31/11 9:37 AM, Tomáš Chvátal wrote: Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Thank you, but it's still not enough for chromium. The virtual uses =ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767. We need to require =ffmpeg-0.6_p25767, not just 0.6. By the way, I still didn't have time to test with libav, but it seems that it's expected to be compatible. iirc, this dep in chromium is due to the need for libavcore, but this lib has been merged back to libavutil in latest snapshots (and thus chromium fails to build); if chromium goes back to look for the functions in libavutil, you may have chances to be compatible with 0.6 I did some testing for this; the results are not ideal. See bug 361665 [1]. Basically, Chromium needs an ffmpeg (or libav) version which includes the function introduced by the following commit. ffmpeg-0.6 and libav-0.6.2 don't work. commit 6f84cd127947394e53a6621e9ed077517df5a6d2 Author: Stefano Sabatini stefano.sabatini-l...@poste.it Date: Tue Nov 2 22:20:49 2010 + Add av_get_bits_per_sample_fmt() to libavcore/samplefmt.h and deprecate av_get_bits_per_sample_format(). Originally committed as revision 25654 to svn://svn.ffmpeg.org/ffmpeg/trunk [1] https://bugs.gentoo.org/show_bug.cgi?id=361665
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On 3/31/11 9:37 AM, Tomáš Chvátal wrote: Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Thank you, but it's still not enough for chromium. The virtual uses =ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767. We need to require =ffmpeg-0.6_p25767, not just 0.6. By the way, I still didn't have time to test with libav, but it seems that it's expected to be compatible. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Saturday, April 02, 2011 07:02:54 AM Paweł Hajdan, Jr. wrote: On 3/31/11 9:37 AM, Tomáš Chvátal wrote: Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Thank you, but it's still not enough for chromium. The virtual uses =ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767. We need to require =ffmpeg-0.6_p25767, not just 0.6. By the way, I still didn't have time to test with libav, but it seems that it's expected to be compatible. iirc, this dep in chromium is due to the need for libavcore, but this lib has been merged back to libavutil in latest snapshots (and thus chromium fails to build); if chromium goes back to look for the functions in libavutil, you may have chances to be compatible with 0.6 A.
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Sat, 2011-04-02 at 16:41 -0300, Alexis Ballier wrote: On Saturday, April 02, 2011 07:02:54 AM Paweł Hajdan, Jr. wrote: On 3/31/11 9:37 AM, Tomáš Chvátal wrote: Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Thank you, but it's still not enough for chromium. The virtual uses =ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767. We need to require =ffmpeg-0.6_p25767, not just 0.6. By the way, I still didn't have time to test with libav, but it seems that it's expected to be compatible. iirc, this dep in chromium is due to the need for libavcore, but this lib has been merged back to libavutil in latest snapshots (and thus chromium fails to build); if chromium goes back to look for the functions in libavutil, you may have chances to be compatible with 0.6 A. I've reported that upstream 2 days ago and it was fixed yesterday. I'm running chromium-11.0.696.28 against libav-0.7_pre20110327 here and it works fine. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Note for everyone: if pkg works with all current implementations DO NOT specify the version for the virtual :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ULy4ACgkQHB6c3gNBRYcNaQCfT/7cPitr4gShFZW6uYQ8Z2CE VdsAnRfxu0f3Yi0YmQXAqelTb4Ulm7+B =cSM8 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 29.3.2011 04:12, Alexis Ballier napsal(a): On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote: On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: Hi guys, As there is new ffmpeg fork that is a bit alive we should provide it as alternative to current media-video/ffmpeg. So libav is stored in media-video/libav (look at it, try to find issues and stuff). Virtual package is virtual/ffmpeg where now i implemented it to have versioned dependencies. So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can decide what they need. Samuli pointed out that we do not slot ffmpeg nor support versioned deps and always demand everything to be working with latest. If you have strong opinion on that one please express it here so the virtual gets redesigned to just simple virtual/ffmpeg-0.1 without any version stated in it. I myself like the chance to express the version explicitly. Virtual itself provide access to all useflags currently used in eapi2 deps. More can be added when required. With the same logic we have always pulled in from master, instead of release trees (such as 0.5.x, 0.6.x). It's not legal to set versioned deps forcing downgrade on same stabilization level (stable, or ~arch) as that will just cause dependency conflict. Applies to any package. So just punt the just committed virtuals and just leave virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is not fixed in reasonable time, gets lastrited like before. well, if you want to convert all the tree you'll need a versioned virtual because the = deps are still needed (and the virtual should also have = deps, not ~ nor =..* in order not to force a downgrade because of an outdated virtual) A. Well the virtuals can be versioned as i said previously, altho others convinced me that unversioned are desirable. If we would want versioned one we currently need 3 of them: 0.5 including only ffmpeg = 0.5 0.6 including libav or ffmpeg both = 0.6 0.7 including libav = 0.7_pre or ffmpeg = 0.6_p So what do you think. For the || dependencies order it should be lazy evaluated for 2 years now. Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2R17UACgkQHB6c3gNBRYc9eACfcheohzlRT9JRV27FdjSybk1C dyUAn1WPNzlxMDolYAqODZLo26y2Pcxk =0gYI -END PGP SIGNATURE-
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Tuesday, March 29, 2011 09:59:33 AM Tomáš Chvátal wrote: Dne 29.3.2011 04:12, Alexis Ballier napsal(a): On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote: On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: Hi guys, As there is new ffmpeg fork that is a bit alive we should provide it as alternative to current media-video/ffmpeg. So libav is stored in media-video/libav (look at it, try to find issues and stuff). Virtual package is virtual/ffmpeg where now i implemented it to have versioned dependencies. So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can decide what they need. Samuli pointed out that we do not slot ffmpeg nor support versioned deps and always demand everything to be working with latest. If you have strong opinion on that one please express it here so the virtual gets redesigned to just simple virtual/ffmpeg-0.1 without any version stated in it. I myself like the chance to express the version explicitly. Virtual itself provide access to all useflags currently used in eapi2 deps. More can be added when required. With the same logic we have always pulled in from master, instead of release trees (such as 0.5.x, 0.6.x). It's not legal to set versioned deps forcing downgrade on same stabilization level (stable, or ~arch) as that will just cause dependency conflict. Applies to any package. So just punt the just committed virtuals and just leave virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is not fixed in reasonable time, gets lastrited like before. well, if you want to convert all the tree you'll need a versioned virtual because the = deps are still needed (and the virtual should also have = deps, not ~ nor =..* in order not to force a downgrade because of an outdated virtual) A. Well the virtuals can be versioned as i said previously, altho others convinced me that unversioned are desirable. you were right to version them at the beginning for the above reasons If we would want versioned one we currently need 3 of them: 0.5 including only ffmpeg = 0.5 0.6 including libav or ffmpeg both = 0.6 I would only add these 2 here 0.7 including libav = 0.7_pre or ffmpeg = 0.6_p So what do you think. there is no 0.7 for the moment, so we do not really care; we'll add new virtual versions as the need comes; a quick look at your list shows 0.6 to be the highest required version by some packages. For the || dependencies order it should be lazy evaluated for 2 years now. Still, you're making the jump rather quickly by having a fork as the default implementation a couple of days after the fork. libav is 'new' and shiny, comes with better promises and everything, but why would they fork if they didnt ? :) Its already starting to be a mess with the versions differing... I can't wait to see the next API break... I really wish one of the 2 forks will die rather sooner than later. A.
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 29.3.2011 16:05, Alexis Ballier napsal(a): Its already starting to be a mess with the versions differing... I can't wait to see the next API break... I really wish one of the 2 forks will die rather sooner than later. The versions differing is simple. There is planned 0.6.3 - if we just add 0.6.2_pSNAPSHOTDAY it would get overshadowed later. if we name it 0.7_pre 0.6 releases never gets to collide with it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2R7KEACgkQHB6c3gNBRYdHbQCcDZBJLjdwb4ZBC+3O4l3zi4qt vmcAni7gb6vQazQ2u9oYiovutNZGmk1c =yjLw -END PGP SIGNATURE-
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote: On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: Hi guys, As there is new ffmpeg fork that is a bit alive we should provide it as alternative to current media-video/ffmpeg. So libav is stored in media-video/libav (look at it, try to find issues and stuff). Virtual package is virtual/ffmpeg where now i implemented it to have versioned dependencies. So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can decide what they need. Samuli pointed out that we do not slot ffmpeg nor support versioned deps and always demand everything to be working with latest. If you have strong opinion on that one please express it here so the virtual gets redesigned to just simple virtual/ffmpeg-0.1 without any version stated in it. I myself like the chance to express the version explicitly. Virtual itself provide access to all useflags currently used in eapi2 deps. More can be added when required. With the same logic we have always pulled in from master, instead of release trees (such as 0.5.x, 0.6.x). It's not legal to set versioned deps forcing downgrade on same stabilization level (stable, or ~arch) as that will just cause dependency conflict. Applies to any package. So just punt the just committed virtuals and just leave virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is not fixed in reasonable time, gets lastrited like before. well, if you want to convert all the tree you'll need a versioned virtual because the = deps are still needed (and the virtual should also have = deps, not ~ nor =..* in order not to force a downgrade because of an outdated virtual) A.
[gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: Hi guys, As there is new ffmpeg fork that is a bit alive we should provide it as alternative to current media-video/ffmpeg. So libav is stored in media-video/libav (look at it, try to find issues and stuff). Virtual package is virtual/ffmpeg where now i implemented it to have versioned dependencies. So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can decide what they need. Samuli pointed out that we do not slot ffmpeg nor support versioned deps and always demand everything to be working with latest. If you have strong opinion on that one please express it here so the virtual gets redesigned to just simple virtual/ffmpeg-0.1 without any version stated in it. I myself like the chance to express the version explicitly. Virtual itself provide access to all useflags currently used in eapi2 deps. More can be added when required. With the same logic we have always pulled in from master, instead of release trees (such as 0.5.x, 0.6.x). It's not legal to set versioned deps forcing downgrade on same stabilization level (stable, or ~arch) as that will just cause dependency conflict. Applies to any package. So just punt the just committed virtuals and just leave virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is not fixed in reasonable time, gets lastrited like before.
