[gentoo-desktop] Re: Digest of [e-mail] issue 306 (2354-2357)

[Andrew Peter]

Unsubscribe
On Feb 23, 2015 5:02 PM, <gentoo-desktop+help@l.g.o> wrote:

> Topics (messages 2354 through 2357):
>
> [gentoo-desktop] ffmpeg versions in portage
>       2354 - Brent Busby <brent@×××××××××.org>
>
> [gentoo-desktop] Re: ffmpeg versions in portage
>       2355 - Duncan <1i5t5.duncan@×××.net>
>
> [gentoo-desktop] Re: ffmpeg versions in portage
>       2356 - Brent Busby <brent@×××××××××.org>
>
> [gentoo-desktop] Re: ffmpeg versions in portage
>       2357 - Duncan <1i5t5.duncan@×××.net>
>
>
>
> ---------- Forwarded message ----------
> From: Brent Busby <brent@×××××××××.org>
> To: Gentoo Desktop Listserv <gentoo-desktop@l.g.o>
> 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 <1i5t5.duncan@×××.net>
> To: gentoo-desktop@l.g.o
> 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 <brent@×××××××××.org>
> To: gentoo-desktop@l.g.o
> 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 <1i5t5.duncan@×××.net>
> To: gentoo-desktop@l.g.o
> 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
>
>
>