Re: Subject: Digest of [email protected] issue 306 (2354-2357)
Andrew Peter <[email protected]> Mon, 23 Feb 2015 17:10:10 -0800
| Newsgroups | gmane.linux.gentoo.desktop |
|---|---|
| Message-ID | <CAJ8RDp38g2QiCcRz32f4xOPU5tsroPm3SscZW-E0ECaSR_YJwQ@mail.gmail.com> |
--14dae9cc97c81f8a36050fcb2ece Content-Type: text/plain; charset=UTF-8 Unsubscribe On Feb 23, 2015 5:02 PM, <[email protected]> wrote: > Topics (messages 2354 through 2357): > > [gentoo-desktop] ffmpeg versions in portage > 2354 - Brent Busby <[email protected]> > > [gentoo-desktop] Re: ffmpeg versions in portage > 2355 - Duncan <[email protected]> > > [gentoo-desktop] Re: ffmpeg versions in portage > 2356 - Brent Busby <[email protected]> > > [gentoo-desktop] Re: ffmpeg versions in portage > 2357 - Duncan <[email protected]> > > > > ---------- Forwarded message ---------- > From: Brent Busby <[email protected]> > To: Gentoo Desktop Listserv <[email protected]> > Cc: > Date: Wed, 18 Feb 2015 22:19:37 -0600 (CST) > Subject: [gentoo-desktop] ffmpeg versions in portage > With all the arguing I see in the forums lately about libav versus ffmpeg, > I thought I'd ask an ffmpeg question of a different nature: > > Upstream, the ffmpeg people are releasing 2.5 as "stable." Some people > (who I'm not going to argue with, since I don't really have a position on > it myself) say the ffmpeg developers are reckless. However, I notice that > most other distros are at least shipping 2.2 (perhaps with lots of distro > patches to fix problems?). > > Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., not > defunct or deprecated) branch with ffmpeg upstream, apparently maintained > for really conservative users. > > All of this has me wondering...should I unmask? Both 2.2 and 2.5 are > available in Portage as ~amd64 ebuilds. Is anyone here doing this? Does it > unleash the hounds of hell (or the UNIX equivalent, lots of unpleasant > segfaults and codec problems)? I'm mostly wanting better Bluray/WMV3/VC-1 > support, but I don't know how that stands between the various 1.2/2.2/2.5 > branches. > > From talking to people who don't run Gentoo, I've found that it has a > reputation for being bleeding-edge, but at times, I've found to the > contraty that it can actually sometimes be overcautious, making it hard to > tell if you're missing out on things other distros are enjoying because > your upgrades are masked. Sometimes, package versions will stay masked for > months or years just because nobody got around to marking them stable for > amd64 and not because of any actual bugs. > > Anybody running ffmpeg 2.x without issues? If so, which one...2.2 or 2.5? > > -- > + Brent A. Busby + "We've all heard that a million monkeys > + Sr. UNIX Systems Admin + banging on a million typewriters will > + University of Chicago + eventually reproduce the entire works of > + James Franck Institute + Shakespeare. Now, thanks to the Internet, > + Materials Research Ctr + we know this is not true." -Robert Wilensky > > > ---------- Forwarded message ---------- > From: Duncan <[email protected]> > To: [email protected] > Cc: > Date: Thu, 19 Feb 2015 06:47:23 +0000 (UTC) > Subject: [gentoo-desktop] Re: ffmpeg versions in portage > Brent Busby posted on Wed, 18 Feb 2015 22:19:37 -0600 as excerpted: > > > With all the arguing I see in the forums lately about libav versus > > ffmpeg, I thought I'd ask an ffmpeg question of a different nature: > > > > Upstream, the ffmpeg people are releasing 2.5 as "stable." Some people > > (who I'm not going to argue with, since I don't really have a position > > on it myself) say the ffmpeg developers are reckless. However, I notice > > that most other distros are at least shipping 2.2 (perhaps with lots of > > distro patches to fix problems?). > > > > Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., not > > defunct or deprecated) branch with ffmpeg upstream, apparently > > maintained for really conservative users. > > > > All of this has me wondering...should I unmask? Both 2.2 and 2.5 are > > available in Portage as ~amd64 ebuilds. Is anyone here doing this? Does > > it unleash the hounds of hell (or the UNIX equivalent, lots of > > unpleasant segfaults and codec problems)? I'm mostly wanting better > > Bluray/WMV3/VC-1 support, but I don't know how that stands between the > > various 1.2/2.2/2.5 branches. > > > > From talking to people who don't run Gentoo, I've found that it has a > > reputation for being bleeding-edge, but at times, I've found to the > > contraty that it can actually sometimes be overcautious, making it hard > > to tell if you're missing out on things other distros are enjoying > > because your upgrades are masked. Sometimes, package versions will stay > > masked for months or years just because nobody got around to marking > > them stable for amd64 and not because of any actual bugs. > > > > Anybody running ffmpeg 2.x without issues? If so, which one...2.2 or > > 2.5? > > [Adding this note after I wrote the below. I think it ended up reading > harsher than I intended. I know people choose stable for a reason and I > really do respect that. Those people simply aren't me, nor that reason > mine... and that certainly comes out in the below. But no personal, or > even whole-group, offense intended. It's just not me. But it's your > machine, not mine, and gentoo wouldn't be gentoo if it didn't respect > your ultimate control of your machine, neither would I be me in the same > case. So, umm... Read the below with that in mind. =:^) ] > > I think what you actually want to know (which isn't what you asked), is > if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues. > > Because people running ~amd64, including me, if they're current (I am), > are running ffmpeg-2.5.4. > > And in general, I've not seen issues. > > However, that's because the various other apps also in ~amd64 have in > general already been updated to work with the newer ffmpeg. > > Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in > general. The newer ffmpeg can't be unmasked to sta(b)le until pretty > much everything else in sta(b)le has been updated to work with it as well. > > And in fact, whenever there's something that has gotten as far behind on > stable as ffmpeg has, in particular, for stuff like gcc, it's very likely > the same general problem. On gentoo, for packages like gcc in > particular, even ~amd64 (and ~arch in general) is generally quite behind, > because before it's unmasked to ~arch, they want to ensure that all other > packages (at the same ~arch) level have been patched to build with it. > Which means it takes "forever" to unmask even to ~arch, because of all > those other packages that have to be either updated first, or patched to > build with the new gcc. Then when all that is done and it hits ~arch, > the process starts over for sta(b)le; all those patched packages have to > be sta(b)le keyworded before gcc itself can be sta(b)le keyworded. > > And yes, sometimes that does mean "stable" is "stale", no two ways about > it. But it's a choice you make... > > But at least gentoo does make it real easy to package.keyword specific > packages if you like, so you can be sta(b)le on most things while > choosing to try arch or even masked versions if you dare. > > If you like you can do an equery depends ffmpeg, and see which packages > that you actually have installed depend on it. You can then research > each one to see if the version you currently have merged can function > with the newer ffmpeg, and if not, you can of course package.keyword it > ~arch at the same time. > > With a bit of luck all the packages you have installed are already > updated and it'll "just work" (perhaps with a rebuild of some of them) > for you. If you're not that lucky, but still somewhat lucky, they've at > least been updated with blockers or version ranges, so if you go to > install the newer ffmpeg, portage will tell you which packages you have > to keyword-unmask in ordered to proceed. > > Of course you also risk that they've not been updated yet, and simply > quit working with no explanation, until you figure it out and unmask them > so you get the newer version of them too. > > But at least with an equery depends ffmpeg, you can see how many packages > you are risking, and decide whether it's worth the hassle from there, or > if it's too much to risk/hassle and you prefer to wait for the full > stable update after all. > > Of course another alternative is to "Dear Interwebs" the solution. You > can post your equery results here and see if there's enough other people > on sta(b)le but running a newer/package.keyworded ffmpeg with those > packages as well, to compare notes. =:^) > > -- > 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 > > > > ---------- Forwarded message ---------- > From: Brent Busby <[email protected]> > To: [email protected] > Cc: > Date: Thu, 19 Feb 2015 01:38:12 -0600 (CST) > Subject: Re: [gentoo-desktop] Re: ffmpeg versions in portage > On Thu, 19 Feb 2015, Duncan wrote: > > [Adding this note after I wrote the below. I think it ended up reading >> harsher than I intended. I know people choose stable for a reason and I >> really do respect that. Those people simply aren't me, nor that reason >> mine... and that certainly comes out in the below. But no personal, or even >> whole-group, offense intended. It's just not me. But it's your machine, >> not mine, and gentoo wouldn't be gentoo if it didn't respect your ultimate >> control of your machine, neither would I be me in the same case. So, >> umm... Read the below with that in mind. =:^) ] >> > > Well, it's mostly stable. I have a rather long package.keywords file full > of things I've allowed ~amd64 on, and I've been careful about which > packages those are. Some are even live ebuilds pulled from GIT. > > The main reason I'm running stable is because this machine is used for > audio recording and music production, and I need it to work. I have quite > a bit of experience in chasing down problems, but I'd like to keep that to > a minimum. > > And no, I don't want a binary distro. Those have their own problems. > > I think what you actually want to know (which isn't what you asked), is >> if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues. >> >> Because people running ~amd64, including me, if they're current (I am), >> are running ffmpeg-2.5.4. >> >> And in general, I've not seen issues. >> > > Ok, well that's basically what I was wanting to know, since it was the > stability of ffmpeg 2.5 itself I was wondering about. > > However, that's because the various other apps also in ~amd64 have in >> general already been updated to work with the newer ffmpeg. >> >> Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in >> general. The newer ffmpeg can't be unmasked to sta(b)le until pretty >> much everything else in sta(b)le has been updated to work with it as well. >> > > Yes, for that reason, I will very likely end up keeping 1.2 for awhile. I > only unmask when it's possible to do so without a lot of complication. > > And in fact, whenever there's something that has gotten as far behind on >> stable as ffmpeg has, in particular, for stuff like gcc, it's very likely >> the same general problem. On gentoo, for packages like gcc in >> particular, even ~amd64 (and ~arch in general) is generally quite behind, >> because before it's unmasked to ~arch, they want to ensure that all other >> packages (at the same ~arch) level have been patched to build with it. >> Which means it takes "forever" to unmask even to ~arch, because of all >> those other packages that have to be either updated first, or patched to >> build with the new gcc. Then when all that is done and it hits ~arch, >> the process starts over for sta(b)le; all those patched packages have to >> be sta(b)le keyworded before gcc itself can be sta(b)le keyworded. >> >> And yes, sometimes that does mean "stable" is "stale", no two ways about >> it. But it's a choice you make... >> > > I know...and I can wait, if it's going to cause a lot of interdependency > problems with other packages. I've found that stuff does usually make it > to stable eventually, so I don't really have a cow about it. > > But at least gentoo does make it real easy to package.keyword specific >> packages if you like, so you can be sta(b)le on most things while >> choosing to try arch or even masked versions if you dare. >> > > This is one of the biggest reasons I run Gentoo instead of a binary > distro. Debian-based distros have APT-pinning, but it doesn't work nearly > as well, because binary packages have already been compiled against the > libraries they were meant for. You can do your own backports, but that's > even more special treatment to hassle you with. Most of the time, if you > unmask a package on Gentoo, it just compiles against what you have, and it > just works, now, and after future system upgrades. > > If you like you can do an equery depends ffmpeg, and see which packages >> that you actually have installed depend on it. You can then research >> each one to see if the version you currently have merged can function >> with the newer ffmpeg, and if not, you can of course package.keyword it >> ~arch at the same time. >> > > Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is > fundamentally broken in some way. Sounds like it's fine... > > -- > + Brent A. Busby + "We've all heard that a million monkeys > + Sr. UNIX Systems Admin + banging on a million typewriters will > + University of Chicago + eventually reproduce the entire works of > + James Franck Institute + Shakespeare. Now, thanks to the Internet, > + Materials Research Ctr + we know this is not true." -Robert Wilensky > > > ---------- Forwarded message ---------- > From: Duncan <[email protected]> > To: [email protected] > Cc: > Date: Thu, 19 Feb 2015 23:37:50 +0000 (UTC) > Subject: [gentoo-desktop] Re: ffmpeg versions in portage > Brent Busby posted on Thu, 19 Feb 2015 01:38:12 -0600 as excerpted: > > > Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is > > fundamentally broken in some way. Sounds like it's fine... > > Yes. What's broken, for both ffmpeg and libav, is that they don't keep > the same API around very long. New versions thus break everything that > depends on them for awhile, until those package in turn are upgraded to > deal with the new API. > > Which wouldn't be a big deal if it were only a handful of packages > depending on ffmpeg/libav. But when pretty much every audio/visual > application out there does... it's not just a big deal, it's a *HUGE* > deal. > > FWIW, while I'm an ffmpeg user myself, the libav upstream has at least > realized the problem to some extent, and has slowed down the dropping of > older APIs a bit, leaving them around for a version or two even as they > continue to move on with new ones. But I believe that's a fairly new > policy, only the last couple of release series, and it's limited to only > a release series or two in "backward compatibility mode" at once, so it's > still a problem for the slower moving packages depending on it, both > because it's new enough that the slower moving packages haven't had a > chance to absorb it yet, and because it's limited to only a release or > two on a fast-moving base, such that the problem will still exist for the > packages depending on it that are moving slow enough. > > This all came out in the gentoo-dev list ffmpeg/libav default > discussion. Truth is, ffmpeg may well be best for ~arch users for > several reasons including more flexibility and best of both worlds > leading edge development policies, but sta(b)le users may actually be > better with libav, at least as this upstream libav policy takes hold, > given that they're at least making /some/ efforts toward API stability > now, which can only help newer versions reach sta(b)le faster. > > Which means libav may actually be the better gentoo profile default after > all, despite apparent user preference to ffmpeg, because leading edge > users are more likely to be willing to change the profile default, while > sta(b)le users in general prefer that it "just work" with the least > disturbance, at least after they've done their basic setup. > > -- > 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 > > > --14dae9cc97c81f8a36050fcb2ece Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">Unsubscribe</p> <div class=3D"gmail_quote">On Feb 23, 2015 5:02 PM, <<a href=3D"mailto:= gentoo-desktop%[email protected]">[email protected]= g</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Top= ics (messages 2354 through 2357):<br> <br> [gentoo-desktop] ffmpeg versions in portage<br> =C2=A0 =C2=A0 =C2=A0 2354 - Brent Busby <<a href=3D"mailto:brent@keycorn= er.org">[email protected]</a>><br> <br> [gentoo-desktop] Re: ffmpeg versions in portage<br> =C2=A0 =C2=A0 =C2=A0 2355 - Duncan <<a href=3D"mailto:[email protected]= et">[email protected]</a>><br> <br> [gentoo-desktop] Re: ffmpeg versions in portage<br> =C2=A0 =C2=A0 =C2=A0 2356 - Brent Busby <<a href=3D"mailto:brent@keycorn= er.org">[email protected]</a>><br> <br> [gentoo-desktop] Re: ffmpeg versions in portage<br> =C2=A0 =C2=A0 =C2=A0 2357 - Duncan <<a href=3D"mailto:[email protected]= et">[email protected]</a>><br> <br> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Brent Busby &= lt;<a href=3D"mailto:[email protected]">[email protected]</a>><br>To= :=C2=A0Gentoo Desktop Listserv <<a href=3D"mailto:[email protected]= entoo.org">[email protected]</a>><br>Cc:=C2=A0<br>Date:=C2= =A0Wed, 18 Feb 2015 22:19:37 -0600 (CST)<br>Subject:=C2=A0[gentoo-desktop] = ffmpeg versions in portage<br>With all the arguing I see in the forums late= ly about libav versus ffmpeg, I thought I'd ask an ffmpeg question of a= different nature:<br> <br> Upstream, the ffmpeg people are releasing 2.5 as "stable."=C2=A0 = Some people (who I'm not going to argue with, since I don't really = have a position on it myself) say the ffmpeg developers are reckless.=C2=A0= However, I notice that most other distros are at least shipping 2.2 (perha= ps with lots of distro patches to fix problems?).<br> <br> Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., no= t defunct or deprecated) branch with ffmpeg upstream, apparently maintained= for really conservative users.<br> <br> All of this has me wondering...should I unmask?=C2=A0 Both 2.2 and 2.5 are = available in Portage as ~amd64 ebuilds.=C2=A0 Is anyone here doing this? Do= es it unleash the hounds of hell (or the UNIX equivalent, lots of unpleasan= t segfaults and codec problems)?=C2=A0 I'm mostly wanting better Bluray= /WMV3/VC-1 support, but I don't know how that stands between the variou= s 1.2/2.2/2.5 branches.<br> <br> From talking to people who don't run Gentoo, I've found that it has= a reputation for being bleeding-edge, but at times, I've found to the = contraty that it can actually sometimes be overcautious, making it hard to = tell if you're missing out on things other distros are enjoying because= your upgrades are masked.=C2=A0 Sometimes, package versions will stay mask= ed for months or years just because nobody got around to marking them stabl= e for amd64 and not because of any actual bugs.<br> <br> Anybody running ffmpeg 2.x without issues?=C2=A0 If so, which one...2.2 or = 2.5?<br> <br> -- <br> + Brent A. Busby=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ "We've all hea= rd that a million monkeys<br> + Sr. UNIX Systems Admin +=C2=A0 banging on a million typewriters will<br> + University of Chicago=C2=A0 +=C2=A0 eventually reproduce the entire works= of<br> + James Franck Institute +=C2=A0 Shakespeare.=C2=A0 Now, thanks to the Inte= rnet,<br> + Materials Research Ctr +=C2=A0 we know this is not true." -Robert Wi= lensky<br> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Duncan <<a= href=3D"mailto:[email protected]">[email protected]</a>><br>To:= =C2=A0<a href=3D"mailto:[email protected]">gentoo-desktop@lis= ts.gentoo.org</a><br>Cc:=C2=A0<br>Date:=C2=A0Thu, 19 Feb 2015 06:47:23 +000= 0 (UTC)<br>Subject:=C2=A0[gentoo-desktop] Re: ffmpeg versions in portage<br= >Brent Busby posted on Wed, 18 Feb 2015 22:19:37 -0600 as excerpted:<br> <br> > With all the arguing I see in the forums lately about libav versus<br> > ffmpeg, I thought I'd ask an ffmpeg question of a different nature= :<br> ><br> > Upstream, the ffmpeg people are releasing 2.5 as "stable."= =C2=A0 Some people<br> > (who I'm not going to argue with, since I don't really have a = position<br> > on it myself) say the ffmpeg developers are reckless.=C2=A0 However, I= notice<br> > that most other distros are at least shipping 2.2 (perhaps with lots o= f<br> > distro patches to fix problems?).<br> ><br> > Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e= ., not<br> > defunct or deprecated) branch with ffmpeg upstream, apparently<br> > maintained for really conservative users.<br> ><br> > All of this has me wondering...should I unmask?=C2=A0 Both 2.2 and 2.5= are<br> > available in Portage as ~amd64 ebuilds.=C2=A0 Is anyone here doing thi= s? Does<br> > it unleash the hounds of hell (or the UNIX equivalent, lots of<br> > unpleasant segfaults and codec problems)?=C2=A0 I'm mostly wanting= better<br> > Bluray/WMV3/VC-1 support, but I don't know how that stands between= the<br> > various 1.2/2.2/2.5 branches.<br> ><br> > From talking to people who don't run Gentoo, I've found that i= t has a<br> > reputation for being bleeding-edge, but at times, I've found to th= e<br> > contraty that it can actually sometimes be overcautious, making it har= d<br> > to tell if you're missing out on things other distros are enjoying= <br> > because your upgrades are masked.=C2=A0 Sometimes, package versions wi= ll stay<br> > masked for months or years just because nobody got around to marking<b= r> > them stable for amd64 and not because of any actual bugs.<br> ><br> > Anybody running ffmpeg 2.x without issues?=C2=A0 If so, which one...2.= 2 or<br> > 2.5?<br> <br> [Adding this note after I wrote the below.=C2=A0 I think it ended up readin= g<br> harsher than I intended.=C2=A0 I know people choose stable for a reason and= I<br> really do respect that.=C2=A0 Those people simply aren't me, nor that r= eason<br> mine... and that certainly comes out in the below.=C2=A0 But no personal, o= r<br> even whole-group, offense intended.=C2=A0 It's just not me.=C2=A0 But i= t's your<br> machine, not mine, and gentoo wouldn't be gentoo if it didn't respe= ct<br> your ultimate control of your machine, neither would I be me in the same<br= > case.=C2=A0 So, umm... Read the below with that in mind. =3D:^) ]<br> <br> I think what you actually want to know (which isn't what you asked), is= <br> if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues.<b= r> <br> Because people running ~amd64, including me, if they're current (I am),= <br> are running ffmpeg-2.5.4.<br> <br> And in general, I've not seen issues.<br> <br> However, that's because the various other apps also in ~amd64 have in<b= r> general already been updated to work with the newer ffmpeg.<br> <br> Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in<br> general.=C2=A0 The newer ffmpeg can't be unmasked to sta(b)le until pre= tty<br> much everything else in sta(b)le has been updated to work with it as well.<= br> <br> And in fact, whenever there's something that has gotten as far behind o= n<br> stable as ffmpeg has, in particular, for stuff like gcc, it's very like= ly<br> the same general problem.=C2=A0 On gentoo, for packages like gcc in<br> particular, even ~amd64 (and ~arch in general) is generally quite behind,<b= r> because before it's unmasked to ~arch, they want to ensure that all oth= er<br> packages (at the same ~arch) level have been patched to build with it.<br> Which means it takes "forever" to unmask even to ~arch, because o= f all<br> those other packages that have to be either updated first, or patched to<br= > build with the new gcc.=C2=A0 Then when all that is done and it hits ~arch,= <br> the process starts over for sta(b)le; all those patched packages have to<br= > be sta(b)le keyworded before gcc itself can be sta(b)le keyworded.<br> <br> And yes, sometimes that does mean "stable" is "stale", = no two ways about<br> it.=C2=A0 But it's a choice you make...<br> <br> But at least gentoo does make it real easy to package.keyword specific<br> packages if you like, so you can be sta(b)le on most things while<br> choosing to try arch or even masked versions if you dare.<br> <br> If you like you can do an equery depends ffmpeg, and see which packages<br> that you actually have installed depend on it.=C2=A0 You can then research<= br> each one to see if the version you currently have merged can function<br> with the newer ffmpeg, and if not, you can of course package.keyword it<br> ~arch at the same time.<br> <br> With a bit of luck all the packages you have installed are already<br> updated and it'll "just work" (perhaps with a rebuild of some= of them)<br> for you.=C2=A0 If you're not that lucky, but still somewhat lucky, they= 've at<br> least been updated with blockers or version ranges, so if you go to<br> install the newer ffmpeg, portage will tell you which packages you have<br> to keyword-unmask in ordered to proceed.<br> <br> Of course you also risk that they've not been updated yet, and simply<b= r> quit working with no explanation, until you figure it out and unmask them<b= r> so you get the newer version of them too.<br> <br> But at least with an equery depends ffmpeg, you can see how many packages<b= r> you are risking, and decide whether it's worth the hassle from there, o= r<br> if it's too much to risk/hassle and you prefer to wait for the full<br> stable update after all.<br> <br> Of course another alternative is to "Dear Interwebs" the solution= .=C2=A0 You<br> can post your equery results here and see if there's enough other peopl= e<br> on sta(b)le but running a newer/package.keyworded ffmpeg with those<br> packages as well, to compare notes. =3D:^)<br> <br> --<br> Duncan - List replies preferred.=C2=A0 =C2=A0No HTML msgs.<br> "Every nonfree program has a lord, a master --<br> and if you use the program, he is your master."=C2=A0 Richard Stallman= <br> <br> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Brent Busby &= lt;<a href=3D"mailto:[email protected]">[email protected]</a>><br>To= :=C2=A0<a href=3D"mailto:[email protected]">gentoo-desktop@li= sts.gentoo.org</a><br>Cc:=C2=A0<br>Date:=C2=A0Thu, 19 Feb 2015 01:38:12 -06= 00 (CST)<br>Subject:=C2=A0Re: [gentoo-desktop] Re: ffmpeg versions in porta= ge<br>On Thu, 19 Feb 2015, Duncan wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> [Adding this note after I wrote the below.=C2=A0 I think it ended up readin= g harsher than I intended.=C2=A0 I know people choose stable for a reason a= nd I really do respect that.=C2=A0 Those people simply aren't me, nor t= hat reason mine... and that certainly comes out in the below. But no person= al, or even whole-group, offense intended.=C2=A0 It's just not me.=C2= =A0 But it's your machine, not mine, and gentoo wouldn't be gentoo = if it didn't respect your ultimate control of your machine, neither wou= ld I be me in the same case.=C2=A0 So, umm... Read the below with that in m= ind. =3D:^) ]<br> </blockquote> <br> Well, it's mostly stable.=C2=A0 I have a rather long package.keywords f= ile full of things I've allowed ~amd64 on, and I've been careful ab= out which packages those are.=C2=A0 Some are even live ebuilds pulled from = GIT.<br> <br> The main reason I'm running stable is because this machine is used for = audio recording and music production, and I need it to work.=C2=A0 I have q= uite a bit of experience in chasing down problems, but I'd like to keep= that to a minimum.<br> <br> And no, I don't want a binary distro.=C2=A0 Those have their own proble= ms.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I think what you actually want to know (which isn't what you asked), is= <br> if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues.<b= r> <br> Because people running ~amd64, including me, if they're current (I am),= <br> are running ffmpeg-2.5.4.<br> <br> And in general, I've not seen issues.<br> </blockquote> <br> Ok, well that's basically what I was wanting to know, since it was the = stability of ffmpeg 2.5 itself I was wondering about.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> However, that's because the various other apps also in ~amd64 have in g= eneral already been updated to work with the newer ffmpeg.<br> <br> Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in<br> general.=C2=A0 The newer ffmpeg can't be unmasked to sta(b)le until pre= tty<br> much everything else in sta(b)le has been updated to work with it as well.<= br> </blockquote> <br> Yes, for that reason, I will very likely end up keeping 1.2 for awhile. I o= nly unmask when it's possible to do so without a lot of complication.<b= r> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> And in fact, whenever there's something that has gotten as far behind o= n<br> stable as ffmpeg has, in particular, for stuff like gcc, it's very like= ly<br> the same general problem.=C2=A0 On gentoo, for packages like gcc in<br> particular, even ~amd64 (and ~arch in general) is generally quite behind,<b= r> because before it's unmasked to ~arch, they want to ensure that all oth= er<br> packages (at the same ~arch) level have been patched to build with it.<br> Which means it takes "forever" to unmask even to ~arch, because o= f all<br> those other packages that have to be either updated first, or patched to<br= > build with the new gcc.=C2=A0 Then when all that is done and it hits ~arch,= <br> the process starts over for sta(b)le; all those patched packages have to<br= > be sta(b)le keyworded before gcc itself can be sta(b)le keyworded.<br> <br> And yes, sometimes that does mean "stable" is "stale", = no two ways about<br> it.=C2=A0 But it's a choice you make...<br> </blockquote> <br> I know...and I can wait, if it's going to cause a lot of interdependenc= y problems with other packages.=C2=A0 I've found that stuff does usuall= y make it to stable eventually, so I don't really have a cow about it.<= br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> But at least gentoo does make it real easy to package.keyword specific<br> packages if you like, so you can be sta(b)le on most things while<br> choosing to try arch or even masked versions if you dare.<br> </blockquote> <br> This is one of the biggest reasons I run Gentoo instead of a binary distro.= =C2=A0 Debian-based distros have APT-pinning, but it doesn't work nearl= y as well, because binary packages have already been compiled against the l= ibraries they were meant for.=C2=A0 You can do your own backports, but that= 's even more special treatment to hassle you with. Most of the time, if= you unmask a package on Gentoo, it just compiles against what you have, an= d it just works, now, and after future system upgrades.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> If you like you can do an equery depends ffmpeg, and see which packages<br> that you actually have installed depend on it.=C2=A0 You can then research<= br> each one to see if the version you currently have merged can function<br> with the newer ffmpeg, and if not, you can of course package.keyword it<br> ~arch at the same time.<br> </blockquote> <br> Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is fund= amentally broken in some way.=C2=A0 Sounds like it's fine...<br> <br> -- <br> + Brent A. Busby=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ "We've all hea= rd that a million monkeys<br> + Sr. UNIX Systems Admin +=C2=A0 banging on a million typewriters will<br> + University of Chicago=C2=A0 +=C2=A0 eventually reproduce the entire works= of<br> + James Franck Institute +=C2=A0 Shakespeare.=C2=A0 Now, thanks to the Inte= rnet,<br> + Materials Research Ctr +=C2=A0 we know this is not true." -Robert Wi= lensky<br> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Duncan <<a= href=3D"mailto:[email protected]">[email protected]</a>><br>To:= =C2=A0<a href=3D"mailto:[email protected]">gentoo-desktop@lis= ts.gentoo.org</a><br>Cc:=C2=A0<br>Date:=C2=A0Thu, 19 Feb 2015 23:37:50 +000= 0 (UTC)<br>Subject:=C2=A0[gentoo-desktop] Re: ffmpeg versions in portage<br= >Brent Busby posted on Thu, 19 Feb 2015 01:38:12 -0600 as excerpted:<br> <br> > Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is= <br> > fundamentally broken in some way.=C2=A0 Sounds like it's fine...<b= r> <br> Yes.=C2=A0 What's broken, for both ffmpeg and libav, is that they don&#= 39;t keep<br> the same API around very long.=C2=A0 New versions thus break everything tha= t<br> depends on them for awhile, until those package in turn are upgraded to<br> deal with the new API.<br> <br> Which wouldn't be a big deal if it were only a handful of packages<br> depending on ffmpeg/libav.=C2=A0 But when pretty much every audio/visual<br= > application out there does... it's not just a big deal, it's a *HUG= E*<br> deal.<br> <br> FWIW, while I'm an ffmpeg user myself, the libav upstream has at least<= br> realized the problem to some extent, and has slowed down the dropping of<br= > older APIs a bit, leaving them around for a version or two even as they<br> continue to move on with new ones.=C2=A0 =C2=A0But I believe that's a f= airly new<br> policy, only the last couple of release series, and it's limited to onl= y<br> a release series or two in "backward compatibility mode" at once,= so it's<br> still a problem for the slower moving packages depending on it, both<br> because it's new enough that the slower moving packages haven't had= a<br> chance to absorb it yet, and because it's limited to only a release or<= br> two on a fast-moving base, such that the problem will still exist for the<b= r> packages depending on it that are moving slow enough.<br> <br> This all came out in the gentoo-dev list ffmpeg/libav default<br> discussion.=C2=A0 Truth is, ffmpeg may well be best for ~arch users for<br> several reasons including more flexibility and best of both worlds<br> leading edge development policies, but sta(b)le users may actually be<br> better with libav, at least as this upstream libav policy takes hold,<br> given that they're at least making /some/ efforts toward API stability<= br> now, which can only help newer versions reach sta(b)le faster.<br> <br> Which means libav may actually be the better gentoo profile default after<b= r> all, despite apparent user preference to ffmpeg, because leading edge<br> users are more likely to be willing to change the profile default, while<br= > sta(b)le users in general prefer that it "just work" with the lea= st<br> disturbance, at least after they've done their basic setup.<br> <br> --<br> Duncan - List replies preferred.=C2=A0 =C2=A0No HTML msgs.<br> "Every nonfree program has a lord, a master --<br> and if you use the program, he is your master."=C2=A0 Richard Stallman= <br> <br> <br></blockquote></div> --14dae9cc97c81f8a36050fcb2ece--