Re: [gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 03/02/2015 20:02, Michał Górny wrote: > Dnia 2015-02-03, o godz. 18:50:43 > "Jason A. Donenfeld" napisał(a): > >> If you want ffmpeg-ish features, at all, USE=ffmpeg. >> >> If you'd like to use the libav implementation, USE=libav. If you'd prefer >> to use the original ffmpeg implementation, USE=-libav. >> >> >> This is simple. Why can't we just stick with this? > > No, it's not simple. It requires users to read another useless manual > that doesn't teacj them with anything except for how to solve a very > specific problem we introduced. > Agreed. I'm a user, and when I say "USE=ffmpeg", I want to get the actual package called ffmpeg, not something that looks like ffmpeg but might be a fork. I especially don't want to disable the alternate package to get the original pre-fork package. I support the idea of re-defining the USE flags even if it means once-off temporary pain. That's far better than having to deal with the existing method forever. Plus, user bug reports will never stop. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: toolchain.eclass: need to revert fixincludes commit
On 02/03/2015 08:55 PM, Anthony G. Basile wrote: > On 02/02/15 19:06, viv...@gmail.com wrote: >> Il 02/02/2015 23:30, Pacho Ramos ha scritto: >>> El sáb, 31-01-2015 a las 16:48 -0500, Anthony G. Basile escribió: Hi everyone, We need to revert the following change to toolchain.eclass: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.647&r2=1.648 >>> Please remember to add a comment to the eclass with the reference to not >>> forget in the future why fixincludes stuff is needed ;) >>> >> fixincludes only on prefix and bsd is doable/acceptable? > > @pacho. absolutely. part of the process is me learning the layers of > history there. > its not like the code is hard to read, its just "why was this done?". > > @vivo75. the fixedincludes are removed after compiling, so they don't make it > to $ROOT > during qmerge either for linux or bsd/prefix. > Its just that are needed during compiling for fbsd/prefix. To complete this info: At least in prefix they have to be installed as well, as subsequent packages may still use host's (libc at least) headers, and gcc requires them to be "fixed". > So a straight revert is fine. Fine for now, it's forked in prefix-overlay still. > We need to explain this in a comment in case some "clever" future dev doesn't > comes to the > same erroneous conclusion, that its okay to just disable their build. Thanks! /haubi/
[gentoo-dev] ffmpeg vs libav choice of default
With the recent introduction of the libav USE flag, the Gentoo default for ffmpeg vs libav is more pronounced than it was before (with libav being listed first in || ( ) dependencies). In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 several users have expressed their preference for ffmpeg. So can someone please remind me what are the technical reasons why we prefer libav over ffmpeg? Ulrich pgptP0wFCiZ6W.pgp Description: PGP signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 10:12:12 Ulrich Mueller napisał(a): > With the recent introduction of the libav USE flag, the Gentoo default > for ffmpeg vs libav is more pronounced than it was before (with libav > being listed first in || ( ) dependencies). > > In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 > several users have expressed their preference for ffmpeg. > > So can someone please remind me what are the technical reasons why we > prefer libav over ffmpeg? We have a developer inside, so it's easier to bring some sanity in. Then ffmpeg people copy each patch, so double benefit for us :P. -- Best regards, Michał Górny pgprRVYqtSbyR.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 17:21, Michał Górny wrote: > Dnia 2015-02-04, o godz. 10:12:12 > Ulrich Mueller napisał(a): > >> With the recent introduction of the libav USE flag, the Gentoo default >> for ffmpeg vs libav is more pronounced than it was before (with libav >> being listed first in || ( ) dependencies). >> >> In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 >> several users have expressed their preference for ffmpeg. >> >> So can someone please remind me what are the technical reasons why we >> prefer libav over ffmpeg? >From an upstream that I care about: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav Based on that I would say we should switch back the default to ffmpeg. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, 4 Feb 2015 10:12:12 +0100 Ulrich Mueller wrote: > With the recent introduction of the libav USE flag, the Gentoo default > for ffmpeg vs libav is more pronounced than it was before (with libav > being listed first in || ( ) dependencies). > > In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 > several users have expressed their preference for ffmpeg. > > So can someone please remind me what are the technical reasons why we > prefer libav over ffmpeg? good luck ! wait for other opinions, but I'd say: libav has a cleaner codebase and stricter development rules. (NB: some gentoo devs are member of the core libav dev team) IMHO, from a pure consumer POV where I want to play a random video and my programs using the libraries not to break, ffmpeg is much better (more codecs get in faster, API is preserved a bit longer), so I never understood nor agreed with that choice of default. Alexis.
[gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Zac Medico wrote: > > Also, portage-2.2.16 will have support for special USE_EXPAND syntax in > package.use I knew from reading portage-dev ml Actually, I am hoping that the introduction of the feature be taken as an opportunity to document USE_EXPAND better as a whole on some prominent places where USE-flags are introduced, explaining that these are internally really just USE-flags with special names (example) and that the whole syntax with variables (and the new one in package.use) are just convenience shortcuts for global/local settings. It would also not hurt to refer to desc/ Probably some native speaker can formulate this much better.
Re: [gentoo-dev] ffmpeg vs libav choice of default
El mié, 04-02-2015 a las 17:24 +0800, Ben de Groot escribió: [...] > From an upstream that I care about: > https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav > > Based on that I would say we should switch back the default to ffmpeg. Thanks a lot for the link
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, Feb 4, 2015 at 10:24 AM, Ben de Groot wrote: > > > From an upstream that I care about: > https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav > > Based on that I would say we should switch back the default to ffmpeg. > I can vouch for the content of that link and the expert opinion of its author. As a consequence, I would high recommend switching back to ffmpeg as default.
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, Feb 4, 2015 at 10:21 AM, Michał Górny wrote: > Dnia 2015-02-04, o godz. 10:12:12 > Ulrich Mueller napisał(a): > > > So can someone please remind me what are the technical reasons why we > > prefer libav over ffmpeg? > > We have a developer inside > I think it's time to end this cronyism, and instead examine things on their technical merit alone. I believe we should go with the opinion of the upstream mpv authors, who make a very clear and compelling case for ffmpeg as default.
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 17:24:03 Ben de Groot napisał(a): > On 4 February 2015 at 17:21, Michał Górny wrote: > > Dnia 2015-02-04, o godz. 10:12:12 > > Ulrich Mueller napisał(a): > > > >> With the recent introduction of the libav USE flag, the Gentoo default > >> for ffmpeg vs libav is more pronounced than it was before (with libav > >> being listed first in || ( ) dependencies). > >> > >> In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 > >> several users have expressed their preference for ffmpeg. > >> > >> So can someone please remind me what are the technical reasons why we > >> prefer libav over ffmpeg? > > From an upstream that I care about: > https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav > > Based on that I would say we should switch back the default to ffmpeg. From what I heard, that upstream likes to change its opinion frequently, pretty much based on which upstream he is pissed at the moment. But it's just rumors. -- Best regards, Michał Górny pgpTlujFP6Odr.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, Feb 4, 2015 at 10:55 AM, Michał Górny wrote: > > From what I heard, that upstream likes to change its opinion > frequently, pretty much based on which upstream he is pissed at > the moment. But it's just rumors. > This is most certainly untrue. Please stop disseminating FUD like this. There is zero factual basis for it. Fortunately, the wiki history of the above linked page retains its history, and we can quickly disprove this petty claim: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav/_history
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 17:55, Michał Górny wrote: > Dnia 2015-02-04, o godz. 17:24:03 > Ben de Groot napisał(a): > >> From an upstream that I care about: >> https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav >> >> Based on that I would say we should switch back the default to ffmpeg. > > From what I heard, that upstream likes to change its opinion > frequently, pretty much based on which upstream he is pissed at > the moment. But it's just rumors. Rumours have no place here. Let's focus on the technical arguments. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
I'd like to insert, early on in this thread, that we must leave personal biases and associations *out* of this discussion, and instead focus on technical merits and analyses only. Thus, I would *strongly encourage* that authors of libav and ffmpeg will *refrain from joining this discussion* in order to keep unnecessary biases out, which perhaps the sole exception of sending stray commit sha1s along if needed. I believe previous Gentoo policy to have been ruled by this non-technical aegis.
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 18:01:57 Ben de Groot napisał(a): > On 4 February 2015 at 17:55, Michał Górny wrote: > > Dnia 2015-02-04, o godz. 17:24:03 > > Ben de Groot napisał(a): > > > >> From an upstream that I care about: > >> https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav > >> > >> Based on that I would say we should switch back the default to ffmpeg. > > > > From what I heard, that upstream likes to change its opinion > > frequently, pretty much based on which upstream he is pissed at > > the moment. But it's just rumors. > > Rumours have no place here. Let's focus on the technical arguments. If I were to be picky, 'upstream I care about' is not a technical argument either. -- Best regards, Michał Górny pgpThYJ16mkZG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 11:04:57 "Jason A. Donenfeld" napisał(a): > I'd like to insert, early on in this thread, that we must leave personal > biases and associations *out* of this discussion, and instead focus on > technical merits and analyses only. Thus, I would *strongly encourage* that > authors of libav and ffmpeg will *refrain from joining this discussion* in > order to keep unnecessary biases out, which perhaps the sole exception of > sending stray commit sha1s along if needed. I believe previous Gentoo > policy to have been ruled by this non-technical aegis. I disagree. The authors/maintainers of both have the most to say here since they actually may know *something* rather than the FUD that's been going around like forever. -- Best regards, Michał Górny pgpVaBzXjZU_P.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 10:26:06 Alexis Ballier napisał(a): > On Wed, 4 Feb 2015 10:12:12 +0100 > Ulrich Mueller wrote: > > > With the recent introduction of the libav USE flag, the Gentoo default > > for ffmpeg vs libav is more pronounced than it was before (with libav > > being listed first in || ( ) dependencies). > > > > In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 > > several users have expressed their preference for ffmpeg. > > > > So can someone please remind me what are the technical reasons why we > > prefer libav over ffmpeg? > > > good luck ! I pretty much agree with Alexis' points. To clarify... > wait for other opinions, but I'd say: libav has a cleaner codebase and > stricter development rules. (NB: some gentoo devs are member of the core > libav dev team) I'd say both projects suck hard at lack of understanding of API/ABI stability. However, if one of them is going to finally get some stability, it's rather going to be libav. But we're far from that, so... > IMHO, from a pure consumer POV where I want to play a random video and > my programs using the libraries not to break, ffmpeg is much better > (more codecs get in faster, API is preserved a bit longer), so I never > understood nor agreed with that choice of default. It's easiest to look at the trackers: - ffmpeg-2 [1] -- 26/26 fixed, - ffmpeg-2.4 [2] -- 3/3 fixed (but unsure if there won't be more), - libav-9 [3] -- 55/55 fixed, - libav-10 [4] -- 11/25 fixed. No offense here but in my experience, ffmpeg support in Gentoo is fixed faster than libav. [1]:https://bugs.gentoo.org/show_bug.cgi?id=476490 [2]:https://bugs.gentoo.org/show_bug.cgi?id=524568 [3]:https://bugs.gentoo.org/show_bug.cgi?id=443230 [4]:https://bugs.gentoo.org/show_bug.cgi?id=509294 -- Best regards, Michał Górny pgpaHMWCyiOt5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
El mié, 04-02-2015 a las 11:40 +0100, Michał Górny escribió: [...] > It's easiest to look at the trackers: > > - ffmpeg-2 [1] -- 26/26 fixed, > - ffmpeg-2.4 [2] -- 3/3 fixed (but unsure if there won't be more), > - libav-9 [3] -- 55/55 fixed, > - libav-10 [4] -- 11/25 fixed. > > No offense here but in my experience, ffmpeg support in Gentoo is fixed > faster than libav. > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=476490 > [2]:https://bugs.gentoo.org/show_bug.cgi?id=524568 > [3]:https://bugs.gentoo.org/show_bug.cgi?id=443230 > [4]:https://bugs.gentoo.org/show_bug.cgi?id=509294 > Also I am unsure how many packages are working with recent libav versions: https://bugs.gentoo.org/show_bug.cgi?id=474408
Re: [gentoo-dev] Re: toolchain.eclass: need to revert fixincludes commit
On 02/04/15 03:06, Michael Haubenwallner wrote: On 02/03/2015 08:55 PM, Anthony G. Basile wrote: On 02/02/15 19:06, viv...@gmail.com wrote: Il 02/02/2015 23:30, Pacho Ramos ha scritto: El sáb, 31-01-2015 a las 16:48 -0500, Anthony G. Basile escribió: Hi everyone, We need to revert the following change to toolchain.eclass: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.647&r2=1.648 Please remember to add a comment to the eclass with the reference to not forget in the future why fixincludes stuff is needed ;) fixincludes only on prefix and bsd is doable/acceptable? @pacho. absolutely. part of the process is me learning the layers of history there. its not like the code is hard to read, its just "why was this done?". @vivo75. the fixedincludes are removed after compiling, so they don't make it to $ROOT during qmerge either for linux or bsd/prefix. Its just that are needed during compiling for fbsd/prefix. To complete this info: At least in prefix they have to be installed as well, as subsequent packages may still use host's (libc at least) headers, and gcc requires them to be "fixed". Thanks for the correction. So a straight revert is fine. Fine for now, it's forked in prefix-overlay still. We could build in intelligence with the appropriate `use prefix`, `use userland_BSD` and `use userland_GNU`. I'll probably do a simple revert this afternoon so we can have a working toolchain.eclass for fbsd, but I'll look at the prefix overlay and compare eclasses and see if we can't just bring in the prefix stuff into the main tree in a safe way. If fixedincludes is the only issue, then I don't see a problem. We need to explain this in a comment in case some "clever" future dev doesn't comes to the same erroneous conclusion, that its okay to just disable their build. Thanks! /haubi/ -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] ffmpeg vs libav choice of default
> So can someone please remind me what are the technical reasons why we > prefer libav over ffmpeg? *ugh* Please no. What about leaving the default (if there ever was such a default) as it is and avoid the otherwise imminent trainwreck? Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
> On Wed, 04 Feb 2015, Matthias Maier wrote: >> So can someone please remind me what are the technical reasons why we >> prefer libav over ffmpeg? > *ugh* Please no. > What about leaving the default (if there ever was such a default) as it > is and avoid the otherwise imminent trainwreck? As I said, so far the default was very weak, namely by ordering of dependencies in a || ( ) group. This has changed since the libav flag is now enabled in profiles: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/base/make.defaults?r1=1.121&r2=1.122 Ulrich pgp4oudLNRC7v.pgp Description: PGP signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Whilst the default *is* still in place (and particularly after the recent news article detailing that users should be using libav), could we please keep commits like the following until *after* we've made an agreed upon decision please? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.16328&r2=1.16329 Anyone using mpv (because mplayer does not work with libav, and they were directed to use mpv by the news article) will now be hit by blockers attempting to reinstall ffmpeg. It's fine to have disagreements, but airing them in front of the users like this is not an ideal situation... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iKYEARECAGYFAlTSE/pfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEZGQjEyM0ZDRDBCRjcwREE1MzA0MjNBREJC QkFENkEyNkMyMDE1N0EACgkQu7rWomwgFXos8ACeIq/rqIdp9DAowP2qVyrUQFfn 4rUAn1coOLGSk60pA9VSbKdXBnPiiSki =aOWg -END PGP SIGNATURE-
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 04/02/15 11:40, Michał Górny wrote: It's easiest to look at the trackers: - ffmpeg-2 [1] -- 26/26 fixed, - ffmpeg-2.4 [2] -- 3/3 fixed (but unsure if there won't be more), - libav-9 [3] -- 55/55 fixed, - libav-10 [4] -- 11/25 fixed. No offense here but in my experience, ffmpeg support in Gentoo is fixed faster than libav. Given I have to fix the downstream issues first in Libav and then whenever FFmpeg decides to drop the stale API they get those for free I'm not surprised. As per Libav, I managed to convince my fellow developers not to drop 2-years old APIs for some more time, since there is enough orphaned software using it (thus why libav 10 and 11 had been kept API (source) compatible) and we (as Libav) spent a decent chunk of time to get updates for a good number of them. Sadly the balance between the requirements of our active users, that demands better APIs and the latent users, that did not update since version 0.8 or so, was a bit too much toward the former. I'd like not to have to discuss more than this since I'm strongly related to Libav and I have no time to get involved in a discussion with fans. lu
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, 04 Feb 2015 13:57:55 +0100 Luca Barbato wrote: > On 04/02/15 11:40, Michał Górny wrote: > > It's easiest to look at the trackers: > > > > - ffmpeg-2 [1] -- 26/26 fixed, > > - ffmpeg-2.4 [2] -- 3/3 fixed (but unsure if there won't be more), > > - libav-9 [3] -- 55/55 fixed, > > - libav-10 [4] -- 11/25 fixed. > > > > No offense here but in my experience, ffmpeg support in Gentoo is > > fixed faster than libav. > > Given I have to fix the downstream issues first in Libav and then > whenever FFmpeg decides to drop the stale API they get those for free > I'm not surprised. > yeah, the above numbers are a bit unfair since most libav-9 fixes/bugs would have applied to ffmpeg 2 I think. Alexis.
Re: [gentoo-dev] ffmpeg vs libav choice of default
Ulrich Mueller napisał: >> On Wed, 04 Feb 2015, Matthias Maier wrote: > >>> So can someone please remind me what are the technical reasons why >we >>> prefer libav over ffmpeg? > >> *ugh* Please no. > >> What about leaving the default (if there ever was such a default) as >it >> is and avoid the otherwise imminent trainwreck? > >As I said, so far the default was very weak, namely by ordering of >dependencies in a || ( ) group. > >This has changed since the libav flag is now enabled in profiles: >http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/base/make.defaults?r1=1.121&r2=1.122 > >Ulrich It wasn't only weak but quite inconsistent too. Some packages had their own || deps, with different order. -- Michał Górny
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 04/02/15 14:25, Jason A. Donenfeld wrote: By now it should be clear to most people that everything goes smoother, works better for the end user, and causes less breakage when *ffmpeg is the default, not libav*. "Works better" is a matter of perception, if I (and the few that help me not afraid of having rabid FFmpeg-fans bite them) fix the bulk of the issues early surely those that use FFmpeg get a smoother experience. Again it is one project parasiting everything the other does. Currently I'm trying to get Libav not to drop the old APIs as hard as I could so at least that part would be even. Probably I should stop caring about the breakages myself and wait until they hit FFmpeg and let other do the work so I can spend my spare time in implementing more features instead. lu
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, 04 Feb 2015 14:30:56 +0100 Michał Górny wrote: > > It wasn't only weak but quite inconsistent too. Some packages had > their own || deps, with different order. > this was to reflect upstreams preferences
Re: [gentoo-dev] ffmpeg vs libav choice of default
Ulrich Mueller schrieb: In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 several users have expressed their preference for ffmpeg. To help finding out what users actually think, I added a poll to the forum to ask them about their preference. https://forums.gentoo.org/viewtopic-t-1010096.html Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, Feb 4, 2015 at 5:09 AM, Michał Górny wrote: > Dnia 2015-02-04, o godz. 11:04:57 > "Jason A. Donenfeld" napisał(a): > >> I'd like to insert, early on in this thread, that we must leave personal >> biases and associations *out* of this discussion, and instead focus on >> technical merits and analyses only. Thus, I would *strongly encourage* that >> authors of libav and ffmpeg will *refrain from joining this discussion* in >> order to keep unnecessary biases out, which perhaps the sole exception of >> sending stray commit sha1s along if needed. I believe previous Gentoo >> policy to have been ruled by this non-technical aegis. > > I disagree. The authors/maintainers of both have the most to say here > since they actually may know *something* rather than the FUD that's > been going around like forever. > ++ Those with the greatest stake in a decision are often the ones who have the most information to provide. That does of course include a risk of bias, but you don't get the best decision possible by having a conversation limited to people who have never heard of ffmpeg or libav. :) -- Rich
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 14:41:06 Alexis Ballier napisał(a): > On Wed, 04 Feb 2015 14:30:56 +0100 > Michał Górny wrote: > > > > It wasn't only weak but quite inconsistent too. Some packages had > > their own || deps, with different order. > > > > this was to reflect upstreams preferences The point is, the default was so weak that Portage's decision could have been randomly influenced by ordering of packages in depgraph. -- Best regards, Michał Górny pgpUKXBtgB1AG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/02/15 09:27 AM, Michał Górny wrote: > Dnia 2015-02-04, o godz. 14:41:06 Alexis Ballier > napisał(a): > >> On Wed, 04 Feb 2015 14:30:56 +0100 Michał Górny >> wrote: >>> >>> It wasn't only weak but quite inconsistent too. Some packages >>> had their own || deps, with different order. >>> >> >> this was to reflect upstreams preferences > > The point is, the default was so weak that Portage's decision > could have been randomly influenced by ordering of packages in > depgraph. > In other words, we didn't actually have a default, we just had a means that portage would choose one of them if the end-user haddn't chosen already. This to me is still the ideal solution (not the || deps due to the issues they have, but the soft default) -- why is it that we need to actually choose or force a default implementation in the profiles anyhow?? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlTSMV4ACgkQ2ugaI38ACPDlOwD+JHd0OPGfcz0m/i4+nJW7jWSF hrpLj7kJrSuWuMUDYQMA/03GKhbIr9ZXNb3OetA0qUHKcrcrEnbirKiFO8vbD5Ex =/WPf -END PGP SIGNATURE-
Re: [gentoo-dev] ffmpeg vs libav choice of default
Dnia 2015-02-04, o godz. 09:49:02 Ian Stakenvicius napisał(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 04/02/15 09:27 AM, Michał Górny wrote: > > Dnia 2015-02-04, o godz. 14:41:06 Alexis Ballier > > napisał(a): > > > >> On Wed, 04 Feb 2015 14:30:56 +0100 Michał Górny > >> wrote: > >>> > >>> It wasn't only weak but quite inconsistent too. Some packages > >>> had their own || deps, with different order. > >>> > >> > >> this was to reflect upstreams preferences > > > > The point is, the default was so weak that Portage's decision > > could have been randomly influenced by ordering of packages in > > depgraph. > > > > In other words, we didn't actually have a default, we just had a means > that portage would choose one of them if the end-user haddn't chosen > already. > > This to me is still the ideal solution (not the || deps due to the > issues they have, but the soft default) -- why is it that we need to > actually choose or force a default implementation in the profiles anyhow?? Because binary flag has to have a value :P. And anyway, having a default has the advantage that people don't have to bother when they don't care. -- Best regards, Michał Górny pgpabqog1aiSm.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wed, Feb 4, 2015 at 9:49 AM, Ian Stakenvicius wrote: > > This to me is still the ideal solution (not the || deps due to the > issues they have, but the soft default) -- why is it that we need to > actually choose or force a default implementation in the profiles anyhow?? > I think this is an option that should probably at least be on the table. We seem to have about a half-dozen ways we can handle this, and they all involve pain to users/developers/etc just in different ways. If this nonsense keeps up all that much longer, I wonder if we'll start seeing everybody just bundling their preferred implementation in their packages. -- Rich
Re: [gentoo-dev] ffmpeg vs libav choice of default
On Wednesday 04 February 2015 09:49:02 Ian Stakenvicius wrote: > In other words, we didn't actually have a default, we just had a means > that portage would choose one of them if the end-user haddn't chosen > already. > > This to me is still the ideal solution (not the || deps due to the > issues they have, but the soft default) -- why is it that we need to > actually choose or force a default implementation in the profiles anyhow?? Because it was causing obscure blocks when trying to build/update sufficiently complex system (e.g. pulling in mplayer and vlc simultaneously). I hit this a few times recently while rebuilding a few systems, which caused me to go and search for "wtf all this mess is about?" and finding exactly that link with explanation that was already cited in this thread (by developer of some viewer named similarly to vlc - vmp??). On the technical side: setting -libav +ffmpeg explicitly seemed to work the best. I had an impression that the other way around was not as robust - I tried to enforce libav, but that was before reading on this issue, so I don't remember what was the state of ffmpeg. I just remember having to look at the emerge --tree -pv output to figure out that these two flags were in conflict.. George
Re: Re: [gentoo-dev] ffmpeg vs libav choice of default
> This to me is still the ideal solution (not the || deps due to the > issues they have, but the soft default) -- why is it that we need to > actually choose or force a default implementation in the profiles anyhow?? Because blockers resulted whenever two different packages made portage pick two different implementations. Which is a natural result of "weak preferences" in one place combined with "try to avoid uninstalling A and installing B" and "hard dependencies" in another place. Because the messy & chaotic virtual solution did not provide any deterministic way to rebuild reverse deps when needed. -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] arm64
On Sun, 25 Jan 2015 18:43:49 +0100 Sebastian Pipping wrote: > I got a bug report for arm64 against the test suite of uriparser. If I > could get a temporary arm64 shell somewhere, that could help me > understand the issue. I can give you an accout here; system is Opteron 2000 (i.e., ancient) but it is arm64. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508
Re: [gentoo-dev] arm64
On Mon, 02 Feb 2015 00:44:20 +0100 Sebastian Pipping wrote: > So I don't need shell access any more, at least not in this context. If you are interested in fixing things feel free to ping me and we can get you ssh access (assuming that an Opteron 2376 is sufficient) prior to needing it :-) -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508
Re: [gentoo-dev] arm64
On Wed, 4 Feb 2015 09:36:06 -0600 Steven Lembark wrote: > On Sun, 25 Jan 2015 18:43:49 +0100 > Sebastian Pipping wrote: > > > I got a bug report for arm64 against the test suite of uriparser. > > If I could get a temporary arm64 shell somewhere, that could help me > > understand the issue. > > I can give you an accout here; system is Opteron 2000 (i.e., ancient) > but it is arm64. > Isn't an opteron processor an amd64, not arm64. The arm64 is a very new processor in the arm family, just in the last year or so. -- Brian Dolbec
