[gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 840 bytes --]

See <https://bugs.gentoo.org/show_bug.cgi?id=591722> for context.

chromium-54 is currently hard masked; it'd soon enter ~arch, and then
stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.

These are the options I see for how to proceed. Feel free to share
further alternatives.

A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

B. Backport just the changes needed for chromium to older ffmpeg

C. Mask chromium's system-ffmpeg flag when the dependency on
ffmpeg-3.0.1 can't be satisfied

D. Patch chromium not to require newer ffmpeg

Please share your thoughts about pros, cons, and viability of each option.

I'd certainly be willing to help with testing and making progress on
these, and I could possibly use a fast machine as a tinderbox for this.

That also means help is welcome.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1307 bytes --]

On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
> See <https://bugs.gentoo.org/show_bug.cgi?id=591722> for context.
> 
> chromium-54 is currently hard masked; it'd soon enter ~arch, and then
> stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.
> 
> These are the options I see for how to proceed. Feel free to share
> further alternatives.
> 
> A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

https://bugs.gentoo.org/show_bug.cgi?id=ffmpeg-3

> 
> B. Backport just the changes needed for chromium to older ffmpeg

Any chance of it being included upstream or would it be a downstream
carry for a long time?

> 
> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

Would this result in using bundled libraries instead?

> 
> D. Patch chromium not to require newer ffmpeg
> 
> Please share your thoughts about pros, cons, and viability of each option.
> 
> I'd certainly be willing to help with testing and making progress on
> these, and I could possibly use a fast machine as a tinderbox for this.
> 
> That also means help is welcome.
> 
> Paweł
> 


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
>> B. Backport just the changes needed for chromium to older ffmpeg
>
> Any chance of it being included upstream or would it be a downstream
> carry for a long time?

I haven't looked at any code, but given that it's a major version bump
of a library, the changes probably involve API-breaks. Backporting
them upstream or downstream is probably not a simple matter, and
probably a bad idea.

>>
>> C. Mask chromium's system-ffmpeg flag when the dependency on
>> ffmpeg-3.0.1 can't be satisfied
>
> Would this result in using bundled libraries instead?

Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg
code to be used.

The Chromium project applies security fixes quite regularly, so don't
get too worried over it.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Sun, 28 Aug 2016 19:28:48 +0200
"Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> See <https://bugs.gentoo.org/show_bug.cgi?id=591722> for context.
> 
> chromium-54 is currently hard masked; it'd soon enter ~arch, and then
> stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.
> 
> These are the options I see for how to proceed. Feel free to share
> further alternatives.
> 
> A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

Don't use 3.0. Go for 3.1.x.

Except that, it's ideal, but revdeps need to be fixed somehow first.
Help is actually deeply needed to push forward this agenda.

Good news is that Toralf already ran the tinderbox on both ~arch and
stable. Bad news is that there are a lot of failures. Some are not
simple to fix.


> B. Backport just the changes needed for chromium to older ffmpeg

I doubt that is sanely possible.


> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

It's a bad idea I think.


> D. Patch chromium not to require newer ffmpeg

Maybe the simplest temporary solution, it is equivalent to B. except we
don't change every other consumer of the lib.

In the end, I think if A. can't be sanely achieved, D. is the only
option.


Any clue on what chromium requires from 3.x+ ?

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 68 bytes --]

Work on making 3.1.x stable.

In the mean time, mask system-ffmpeg.

[-- Attachment #2: Type: text/html, Size: 101 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Sun, 28 Aug 2016 19:28:48 +0200
"Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

I'd pick this option, mostly because this is the path that introduces
the least amount of space for breaking users setups.

We've established there's a lot of problem with having system-wide
ffmpeg 3.0, so running towards that seems foolish.

Patching chromimum to not need 3.0 seems also slightly dodgy.

Though I would be ok with a compromise between C and D, where
system-ffmpeg implied the patch, but otherwise left chromium building
with its bundled ffmpeg.


Then the decision about masking USE="system-ffmpeg" depends on how
stable we expect the patch to be.

Keeping in mind that both case C and D will leave us open to a future
chromium being built with ffmpeg3, and we'll need to make sure that
transition is also smooth.

but for the sake of simplicity, I would just hardmask the useflag until
we know it will work, and then unmask it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Jason Zaman]

On Sun, Aug 28, 2016 at 11:15:40PM -0400, Mike Gilbert wrote:
> On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> > On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
> >> B. Backport just the changes needed for chromium to older ffmpeg
> >
> > Any chance of it being included upstream or would it be a downstream
> > carry for a long time?
> 
> I haven't looked at any code, but given that it's a major version bump
> of a library, the changes probably involve API-breaks. Backporting
> them upstream or downstream is probably not a simple matter, and
> probably a bad idea.

Please don't backport or patch. That sounds like a potential disaster
waiting to happen. The tracker bug for ffmpeg 3.0 has been open for
quite a while and is taking time. Backporting just parts of it has the
potential to break both stable and unstable and the time would be better
used working on stabilizing 3.0.

> >> C. Mask chromium's system-ffmpeg flag when the dependency on
> >> ffmpeg-3.0.1 can't be satisfied
> >
> > Would this result in using bundled libraries instead?
> 
> Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg
> code to be used.
> 
> The Chromium project applies security fixes quite regularly, so don't
> get too worried over it.

Masking it is fine. Its suboptimal but it has much less breakage-
potential. If 3.0 is not stable in time then just mask it.

Also, is this ffmpeg or libav? or are they the same for 3.x?

-- Jason

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Tue, 30 Aug 2016 16:33:04 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> On Sun, 28 Aug 2016 19:28:48 +0200
> "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
> 
> > C. Mask chromium's system-ffmpeg flag when the dependency on
> > ffmpeg-3.0.1 can't be satisfied  
> 
> I'd pick this option, mostly because this is the path that introduces
> the least amount of space for breaking users setups.


You seem to forget the burden and the bugs this introduces by itself. A
quick glance at bugzie gave me:

https://bugs.gentoo.org/show_bug.cgi?id=562600
https://bugs.gentoo.org/show_bug.cgi?id=513048
https://bugs.gentoo.org/show_bug.cgi?id=507080
https://bugs.gentoo.org/show_bug.cgi?id=506268
https://bugs.gentoo.org/show_bug.cgi?id=493670
https://bugs.gentoo.org/show_bug.cgi?id=491850
https://bugs.gentoo.org/show_bug.cgi?id=491582
https://bugs.gentoo.org/show_bug.cgi?id=491466


Most are fixed, but for me this implies that the space for breaking
users setup is much wider with bundled ffmpeg...

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

On Tue, 30 Aug 2016 09:37:51 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> Most are fixed, but for me this implies that the space for breaking
> users setup is much wider with bundled ffmpeg...

But that fallout is limited to firefox.

As opposed to "roll out ffmpeg 3 prematurely" which will break *more* than just
firefox.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Duncan]

Kent Fredric posted on Wed, 31 Aug 2016 03:11:07 +1200 as excerpted:

> On Tue, 30 Aug 2016 09:37:51 +0200 Alexis Ballier <aballier@gentoo.org>
> wrote:
> 
>> Most are fixed, but for me this implies that the space for breaking
>> users setup is much wider with bundled ffmpeg...
> 
> But that fallout is limited to firefox.
> 
> As opposed to "roll out ffmpeg 3 prematurely" which will break *more*
> than just firefox.

Umm... you mean chromium, not firefox, correct?

Because I checked a couple of the bugs wondering how on earth a chromium-
bundled ffmpeg would bug out firefox, and they're definitely chromium 
bugs, generally build-related, not firefox.

Either way, having to stick with an old and likely vulnerable browser 
because the new one won't build isn't a bug I'd like to have.

(In fact, that's one reason I'm downloading my browser updates direct 
from upstream, now, at least firefox ebuilds can be far enough behind for 
even ~arch, that I get worried I'm risking my security due to browsing 
with an outdated browser with known flaws published for several days, 
long enough the bad guys are likely exploiting them!  Yes, there's 
additional risk from running the same binary build everyone else is, but 
when it's days after the upstream update and security flaws notification, 
and there's no ~arch or even hard-masked ebuild for it, even in the 
mozilla overlay let alone in the main tree, on an app as security-
critical as a browser...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Martin Vaeth]

Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Alexis Ballier <aballier@gentoo.org> wrote:
>>
>> As opposed to "roll out ffmpeg 3 prematurely" which will break *more*
>> than just firefox.
>
> Umm... you mean chromium, not firefox, correct?

I also think so. I have unmasked ffmpeg-3 since several months,
because I don't use any package from bug 574788, but instead >gcc-5.
Everything for which I (and I suppose most people) need ffmpeg
compiles (and so far runs) without any problems:
libquicktime, xine-lib-1.2.6-r1, mplayer-1.3.0, mpv-0.19.0,
handbrake-0.10.5-r1, firefox-48.0, avidemux-2.6.8

(Well, for the apparently maintainer-needed avidemux I had lately
to do a version bump to 2.6.12 and some patching in the mv overlay;
but this was only for the very latest bump of ffmpeg-1.3.2 -> 1.3.3
plus a simultaneous bump gcc-5.4.0 -> 6.2.0. I didn't check whether
the ffmpeg bump was related here, at all, or whether a similar
patching could have been done for avidemux-2.6.8)

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Wed, 31 Aug 2016 03:11:07 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> On Tue, 30 Aug 2016 09:37:51 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > Most are fixed, but for me this implies that the space for breaking
> > users setup is much wider with bundled ffmpeg...  
> 
> But that fallout is limited to firefox.
> 
> As opposed to "roll out ffmpeg 3 prematurely" which will break *more*
> than just firefox.

nobody is talking about a premature unmask and even less about
firefox :)

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

On Wed, 31 Aug 2016 03:46:38 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Umm... you mean chromium, not firefox, correct?
> 

Correct, mental bozo bits flipped temporarily ;)

> Either way, having to stick with an old and likely vulnerable browser 
> because the new one won't build isn't a bug I'd like to have.
> 
> (In fact, that's one reason I'm downloading my browser updates direct 
> from upstream, now, at least firefox ebuilds can be far enough behind
> for even ~arch, that I get worried I'm risking my security due to
> browsing with an outdated browser with known flaws published for
> several days, long enough the bad guys are likely exploiting them!
> Yes, there's additional risk from running the same binary build
> everyone else is, but when it's days after the upstream update and
> security flaws notification, and there's no ~arch or even hard-masked
> ebuild for it, even in the mozilla overlay let alone in the main
> tree, on an app as security- critical as a browser...)

<offtopic>

I really wish there was a way to run ancient firefox with security
fixes :(

I've started to really draw hate for all the new stuff they're adding.

I put up with australis for a few years, but I've finally had enough of
it. ( Not merely the look and feel, but how it was implemented has
rubbed me wrong for far too long, much longer than the typical "people
hate new things" period )

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Firefox bloat (was: Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1115 bytes --]

On 08/31/2016 01:28 PM, Kent Fredric wrote:
> On Wed, 31 Aug 2016 03:46:38 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 

..

> <offtopic>
> 
> I really wish there was a way to run ancient firefox with security
> fixes :(
> 
> I've started to really draw hate for all the new stuff they're adding.

You and me both, it is amazing how a project (actually both projects,
includes thunderbird as well), that were explicitly set up in order to
be lightweight alternatives to the suit are so utterly bloated
(thunderbird for some reason includes an IRC and xampp clients). It
makes security auditing horrible, introduces numberous issues on a broad
attack plane and breaks stability.

That said, little we can do about this downstream, but here is [the
thread last time I brought it up upstream]


References:
[the thread last time I brought it up upstream]:
https://mail.mozilla.org/pipermail/tb-planning/2016-January/004357.html


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

On Wed, 31 Aug 2016 09:43:08 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> nobody is talking about a premature unmask and even less about
> firefox :)

Right. My bad on the FF :)  ( ffmpeg having FF in it is clearly perturbing my brain )

But my point really is that *chromium* has end users desiring latest-and-greatest
for valid security reasons.

And the strategy of allowing temporary USE masking means the life-cycles of stabilization
between Chromium and ffmpeg don't need to be tied together.

That way we're not motivated to push stabilization of ffmpeg into end users systems
in order to satisfy the security cycles of Chromium, so we can get Chromium stable
and secure without necessitating we do the same with ffmpeg.

And as stabilizing/unmasking ffmpeg relies mostly on the ability for its reverse
dependencies not to be broken, this essentially means without the USE mask option,
our stabliziation/unmasking workflow for Chromium is now dependent on everything
that uses ffmpeg.

And I'd just rather we not create such a tight, inflexible dependency that motivates
us to propagate breakage when there's a clear path that doesn't propagate breakage.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Wed, 31 Aug 2016 23:36:21 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> On Wed, 31 Aug 2016 09:43:08 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > nobody is talking about a premature unmask and even less about
> > firefox :)  
> 
> Right. My bad on the FF :)  ( ffmpeg having FF in it is clearly
> perturbing my brain )
> 
> But my point really is that *chromium* has end users desiring
> latest-and-greatest for valid security reasons.
> 
> And the strategy of allowing temporary USE masking means the
> life-cycles of stabilization between Chromium and ffmpeg don't need
> to be tied together.
> 
> That way we're not motivated to push stabilization of ffmpeg into end
> users systems in order to satisfy the security cycles of Chromium, so
> we can get Chromium stable and secure without necessitating we do the
> same with ffmpeg.
> 
> And as stabilizing/unmasking ffmpeg relies mostly on the ability for
> its reverse dependencies not to be broken, this essentially means
> without the USE mask option, our stabliziation/unmasking workflow for
> Chromium is now dependent on everything that uses ffmpeg.
> 
> And I'd just rather we not create such a tight, inflexible dependency
> that motivates us to propagate breakage when there's a clear path
> that doesn't propagate breakage.


For years we've been patching packages to work with >= our latest stable
version of ffmpeg/libav and unbundle it. Even mplayer. Chromium shouldnt
be any exception.

Patching consumer packages that way has some advantages:
- Maintainers do not need to wait for ffmpeg to be stabilized.
- ffmpeg does not need to be stabilized in lockstep with a few dozen
  packages that work with this only version.

x 2 if you replace 'stabilized' by 'unmasked' in the above.


Most often it is rather trivial to do; sometimes really annoying (hey
gst)...

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Rich Freeman]

On Wed, Aug 31, 2016 at 8:06 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> For years we've been patching packages to work with >= our latest stable
> version of ffmpeg/libav and unbundle it. Even mplayer. Chromium shouldnt
> be any exception.
>
> Patching consumer packages that way has some advantages:
> - Maintainers do not need to wait for ffmpeg to be stabilized.

Sure, but we're talking about a major version here, and a web browser
where future security updates need to be deployed quickly.  You don't
want to be stuck figuring out what other ffmpeg API calls were touched
in the new version while there is some exploit floating around.

It seems like bundling is the simpler solution here, unless the
necessary patches are trivial.  If they're in fact trivial somebody
can probably just post one and save a lot of speculation.  :)

Ultimately though I think it is up to the chromium team to decide
whether they would rather bundle or patch.  Then perhaps the rest of
us get to decide whether we want chromium in the tree or not.  They're
volunteers, after all, we can't force them to create patches.  I
suspect for quite a few Gentoo would probably go before Chromium does.

-- 
Rich

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Sun, 28 Aug 2016 19:28:48 +0200
"Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> D. Patch chromium not to require newer ffmpeg


You can use the attached patch. Quick test on youtube showed it works.

[-- Attachment #2: chromium-54-ffmpeg2compat.patch --]
[-- Type: text/x-patch, Size: 798 bytes --]

Index: chromium-54.0.2837.0/media/ffmpeg/ffmpeg_common.cc
===================================================================
--- chromium-54.0.2837.0.orig/media/ffmpeg/ffmpeg_common.cc
+++ chromium-54.0.2837.0/media/ffmpeg/ffmpeg_common.cc
@@ -786,7 +786,9 @@ TEST_PRIMARY(SMPTE170M);
 TEST_PRIMARY(SMPTE240M);
 TEST_PRIMARY(FILM);
 TEST_PRIMARY(BT2020);
+#if LIBAVUTIL_VERSION_INT > AV_VERSION_INT(55,5,0)
 TEST_PRIMARY(SMPTEST428_1);
+#endif
 
 TEST_TRANSFER(RESERVED0);
 TEST_TRANSFER(BT709);
@@ -804,8 +806,10 @@ TEST_TRANSFER(BT1361_ECG);
 TEST_TRANSFER(IEC61966_2_1);
 TEST_TRANSFER(BT2020_10);
 TEST_TRANSFER(BT2020_12);
+#if LIBAVUTIL_VERSION_INT > AV_VERSION_INT(55,5,0)
 TEST_TRANSFER(SMPTEST2084);
 TEST_TRANSFER(SMPTEST428_1);
+#endif
 
 TEST_COLORSPACE(RGB);
 TEST_COLORSPACE(BT709);

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Wed, 31 Aug 2016 08:28:14 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> Sure, but we're talking about a major version here, and a web browser
> where future security updates need to be deployed quickly.  You don't
> want to be stuck figuring out what other ffmpeg API calls were touched
> in the new version while there is some exploit floating around.
> 
> It seems like bundling is the simpler solution here, unless the
> necessary patches are trivial.  If they're in fact trivial somebody
> can probably just post one and save a lot of speculation.  :)

It depends on the complexity of the patch indeed. We're talking about 3
enum values that were added in ffmpeg-3 here.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Rich Freeman]

On Wed, Aug 31, 2016 at 1:03 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Wed, 31 Aug 2016 08:28:14 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> Sure, but we're talking about a major version here, and a web browser
>> where future security updates need to be deployed quickly.  You don't
>> want to be stuck figuring out what other ffmpeg API calls were touched
>> in the new version while there is some exploit floating around.
>>
>> It seems like bundling is the simpler solution here, unless the
>> necessary patches are trivial.  If they're in fact trivial somebody
>> can probably just post one and save a lot of speculation.  :)
>
> It depends on the complexity of the patch indeed. We're talking about 3
> enum values that were added in ffmpeg-3 here.
>

If that is indeed all this is, then it does seem like a no-brainer...

-- 
Rich

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Martin Vaeth]

Kent Fredric <kentnl@gentoo.org> wrote:
>
> I really wish there was a way to run ancient firefox with security
> fixes :(

There's palemoon

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Duncan]

Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 +0000 as excerpted:

> Kent Fredric <kentnl@gentoo.org> wrote:
>>
>> I really wish there was a way to run ancient firefox with security
>> fixes :(
> 
> There's palemoon

For Linux?  I haven't looked into it personally, but I had read that 
palemoon was MS-platform only.  So it's news to me if it's available for 
Linux.  Thanks very much for clearing that up for me if it's available 
for Linux, also!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[»Q«]

On Thu, 1 Sep 2016 01:59:21 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 +0000 as excerpted:

> > There's palemoon  
> 
> For Linux?  I haven't looked into it personally, but I had read that 
> palemoon was MS-platform only.  So it's news to me if it's available
> for Linux.  Thanks very much for clearing that up for me if it's
> available for Linux, also!

<http://linux.palemoon.org/> says it's in Gentoo overlays, but I don't
know which ones.

[gentoo-dev] Firefox bloat Was: chromium ...

[Duncan]

Kent Fredric posted on Wed, 31 Aug 2016 23:28:17 +1200 as excerpted:

> I really wish there was a way to run ancient firefox with security fixes
> :(
> 
> I've started to really draw hate for all the new stuff they're adding.
> 
> I put up with australis for a few years, but I've finally had enough of
> it. ( Not merely the look and feel, but how it was implemented has
> rubbed me wrong for far too long, much longer than the typical "people
> hate new things" period )

FWIW, the australis thing never really affected me much.  I had some 
extensions (and configuration mania guified native options) changing the 
look somewhat before, and have some extensions (and config mania options) 
changing the look somewhat now.  It did take me several hours (between 
configuring and extension browsing) to get the new UI setup to something 
I was comfortable with, but then I'm used to that any time I change 
desktop (kde) major versions as well, and this was a comparable change.  
I've never seen a desktop GUI I was entirely comfortable with as shipped 
and I don't expect I ever will, and with the browser being used /as/ a 
desktop more and more these days, and most people including me spending 
more and more time in it even when they don't use it /as/ the desktop, 
it's reasonably comparable, and the australis GUI intro /was/ in 
practice /quite/ comparable to a major desktop upgrade, so I /expected/ 
to need to spend that time reconfiguring the GUI and extensions after the 
australis upgrade, and it wasn't a big deal for me.

Tho I can definitely see the problem for people who actually /do/ find a 
GUI they like (or have trained themselves to like) without having to 
reconfigure/customize it, only to have the thing moved out from under 
them once they are used to it.  It's just that I'm not such a person, and 
both the before and after were and remain impressively configurable with 
extensions, so I never had that problem.

I am rather disturbed by bloat such as pocket, reader, and hello, but 
config mania has options to disable hello, and I got rid of the pocket 
icons as well, so the reader icon appearing in the address bar (which BTW 
also has much of the not-so-awesome disabled, config mania again), so at 
least I can keep them out of my face, even if they remain part of the too-
large audit footprint, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Firefox bloat Was: chromium ...

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 3885 bytes --]

On Thu, 1 Sep 2016 02:36:27 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> FWIW, the australis thing never really affected me much.  I had some 
> extensions (and configuration mania guified native options) changing
> the look somewhat before, and have some extensions (and config mania
> options) changing the look somewhat now.  It did take me several
> hours (between configuring and extension browsing) to get the new UI
> setup to something I was comfortable with, but then I'm used to that
> any time I change desktop (kde) major versions as well, and this was
> a comparable change. I've never seen a desktop GUI I was entirely
> comfortable with as shipped and I don't expect I ever will, and with
> the browser being used /as/ a desktop more and more these days, and
> most people including me spending more and more time in it even when
> they don't use it /as/ the desktop, it's reasonably comparable, and
> the australis GUI intro /was/ in practice /quite/ comparable to a
> major desktop upgrade, so I /expected/ to need to spend that time
> reconfiguring the GUI and extensions after the australis upgrade, and
> it wasn't a big deal for me.
> 
> Tho I can definitely see the problem for people who actually /do/
> find a GUI they like (or have trained themselves to like) without
> having to reconfigure/customize it, only to have the thing moved out
> from under them once they are used to it.  It's just that I'm not
> such a person, and both the before and after were and remain
> impressively configurable with extensions, so I never had that
> problem.
> 
> I am rather disturbed by bloat such as pocket, reader, and hello, but 
> config mania has options to disable hello, and I got rid of the
> pocket icons as well, so the reader icon appearing in the address bar
> (which BTW also has much of the not-so-awesome disabled, config mania
> again), so at least I can keep them out of my face, even if they
> remain part of the too- large audit footprint, etc.

Again, my frustration was not *just* with "new look and feel", but that
the implementation details are both lethargic in comparison to the
previous model, and introduce a *constant* conflict with every tab
extension.

Every time you open the configuration, your vertical tab bar gets
relocated to the top of the screen, and you have a giant configuration
interface that is simply less useful than the previous one.

And sometimes this "move all the things" breaks the interface requiring
a restart to return back to working.

The browser gets into a schizophrenic confusion where configuration
wants tabs to be a certain way *just* to configure things, but the user
doesn't want those tabs to be configured that way, and has to design
their new look-and-feel in the knowledge that it will all shift
somewhere else when you close the configuration UI.

I don't care for a "fancy" look and feel, and I don't want to have to
have *technical* and usability issues introduced to provide such
look-and-feel I never asked for.

This is thus not a problem merely introduced with "Getting it how you
like it", but is a problem that becomes a new problem that flares up
every time you want to change a thing, because one of the things that
is not to your liking is the configuration UI itself, and there's no
meta-configuration-UI to eradicate *that*

Its like every other special snowflake application that decides it
needs some "special" user interface that deviates substantially from
the generic ones provided by their windowing toolkit.

It all ends in hate.

However, seems like Palemoon is an acceptable compromise to me.
Some things are a bit out of touch, but it is responsive and does what
I tell it to, and I don't feel so enslaved to the whims of some
designer at mozilla who is tasked with making Firefox more like Chrome.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Sun, 28 Aug 2016 19:28:48 +0200
> "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
>
>> D. Patch chromium not to require newer ffmpeg
>
>
> You can use the attached patch. Quick test on youtube showed it works.

Nice! Testing this now.

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Wed, 31 Aug 2016 21:03:34 -0500
»Q« <boxcars@gmx.net> wrote:

> <http://linux.palemoon.org/> says it's in Gentoo overlays, but I don't
> know which ones.

Tar.bz2's from http://linux.palemoon.org/download/mainline/ are working nicely for me
as a straight download/unpack/run-in-$HOME

Much so ( and more securely so ) than the equivalent with using legacy Firefoxes :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Wed, Aug 31, 2016 at 11:09 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier <aballier@gentoo.org> wrote:
>> On Sun, 28 Aug 2016 19:28:48 +0200
>> "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
>>
>>> D. Patch chromium not to require newer ffmpeg
>>
>>
>> You can use the attached patch. Quick test on youtube showed it works.
>
> Nice! Testing this now.

The code you have disabled seems to be comparing color space id values
as defined in src/ui/gfx/color_space.h to the equivalent values in the
ffmpeg API. I would assume this is because some chromium code uses
them interchangeably.

What happens if we pass one of those ids to an ffmpeg function that
doesn't understand it? I'm afraid this might break in some subtle way.

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Martin Vaeth]

Duncan <1i5t5.duncan@cox.net> wrote:
> Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 +0000 as excerpted:
>
>> Kent Fredric <kentnl@gentoo.org> wrote:
>>>
>>> I really wish there was a way to run ancient firefox with security
>>> fixes :(
>>
>> There's palemoon
>
> For Linux?

Even for gentoo: There's a "palemoon" overlay in layman.
For instance, palemoon still provides the old privacy-keeping
sync method instead of firefox's new data harvester.

The only reason I still want firefox installed is that palemoon
still only supports gstreamer (though they recently updated
optionally to gstreamer:1.0) but not ffmpeg.

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Bill Kenworthy]

and it doesn't work on some websites whereas firefox does - the
Australian census site for one :(

BillK



On 09/01/16 13:03, Martin Vaeth wrote:
> Duncan <1i5t5.duncan@cox.net> wrote:
>> Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 +0000 as excerpted:
>>
>>> Kent Fredric <kentnl@gentoo.org> wrote:
>>>> I really wish there was a way to run ancient firefox with security
>>>> fixes :(
>>> There's palemoon
>> For Linux?
> Even for gentoo: There's a "palemoon" overlay in layman.
> For instance, palemoon still provides the old privacy-keeping
> sync method instead of firefox's new data harvester.
>
> The only reason I still want firefox installed is that palemoon
> still only supports gstreamer (though they recently updated
> optionally to gstreamer:1.0) but not ffmpeg.
>
>

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Thu, 1 Sep 2016 00:01:16 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Wed, Aug 31, 2016 at 11:09 PM, Mike Gilbert <floppym@gentoo.org>
> wrote:
> > On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier
> > <aballier@gentoo.org> wrote:  
> >> On Sun, 28 Aug 2016 19:28:48 +0200
> >> "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
> >>  
> >>> D. Patch chromium not to require newer ffmpeg  
> >>
> >>
> >> You can use the attached patch. Quick test on youtube showed it
> >> works.  
> >
> > Nice! Testing this now.  
> 
> The code you have disabled seems to be comparing color space id values
> as defined in src/ui/gfx/color_space.h to the equivalent values in the
> ffmpeg API. I would assume this is because some chromium code uses
> them interchangeably.
> 
> What happens if we pass one of those ids to an ffmpeg function that
> doesn't understand it? I'm afraid this might break in some subtle way.

Me too. Except that looking at the code I realized those values are
only read from ffmpeg, never written to, so this case cannot happen I
think.

Worse: ffmpeg usually parses it from the bitstream and passes it
straight from it since the numerical values are made to match e.g. the
ones from the hevc spec, so it should actually be transparent.

[gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Duncan]

Martin Vaeth posted on Thu, 01 Sep 2016 05:03:20 +0000 as excerpted:

> Duncan <1i5t5.duncan@cox.net> wrote:
>> Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 +0000 as excerpted:
>>
>>> Kent Fredric <kentnl@gentoo.org> wrote:
>>>>
>>>> I really wish there was a way to run ancient firefox with security
>>>> fixes :(
>>>
>>> There's palemoon
>>
>> For Linux?
> 
> Even for gentoo: There's a "palemoon" overlay in layman.

Again, thanks, everyone.  I'm not personally so put off by firefox /yet/ 
to need palemoon, but I'm very glad to be corrected and know that it's at 
least /available/ for Linux, both in case I /do/ need it myself, and so I 
can correctly mention it as an option to others should the subject come 
up elsewhere.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[waltdnes]

On Thu, Sep 01, 2016 at 03:12:08PM +1200, Kent Fredric wrote
> On Wed, 31 Aug 2016 21:03:34 -0500
> »Q« <boxcars@gmx.net> wrote:
> 
> > <http://linux.palemoon.org/> says it's in Gentoo overlays, but I don't
> > know which ones.
> 
> Tar.bz2's from http://linux.palemoon.org/download/mainline/ are
> working nicely for me as a straight download/unpack/run-in-$HOME

  Or, with root or sudo, you can make Pale Moon global on your system.

rm -rf /usr/local/palemoon
tar -C /usr/local/ -xvjf palemoon<version_name>.bz2
ln -sf /usr/local/palemoon/palemoon /usr/bin/palemoon

...or in /opt...

rm -rf /opt/palemoon
tar -C /opt/ -xvjf palemoon<version_name>.bz2
ln -sf /opt/palemoon/palemoon /usr/bin/palemoon

  And there's also the option of cloning the git repository, and
building on your own machine with "-march=native".  I also build a
32-bit version "-march=bonnell" in a VM on my desktop, for use in my
ancient 32-bit-only Atom netbook.  I disable webRTC, gconf+dbus,
pulseaudio, etc. in my personal builds.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On 01/09/16 17:58, Duncan wrote:
> Martin Vaeth posted on Thu, 01 Sep 2016 05:03:20 +0000 as excerpted:
>
>> Duncan <1i5t5.duncan@cox.net> wrote:
>>> Martin Vaeth posted on Wed, 31 Aug 2016 18:08:17 +0000 as excerpted:
>>>
>>>> Kent Fredric <kentnl@gentoo.org> wrote:
>>>>> I really wish there was a way to run ancient firefox with security
>>>>> fixes :(
>>>> There's palemoon
>>> For Linux?
>> Even for gentoo: There's a "palemoon" overlay in layman.
> Again, thanks, everyone.  I'm not personally so put off by firefox /yet/ 
> to need palemoon, but I'm very glad to be corrected and know that it's at 
> least /available/ for Linux, both in case I /do/ need it myself, and so I 
> can correctly mention it as an option to others should the subject come 
> up elsewhere.
>
I believe there are several Firefox-derived forks out there, some
available some less-so for linux. I was exploring a couple of ones I'd
heard mentioned that aren't in portage (or overlays, to my knowledge)
which it would be possible to add to the web browser portfolio if a
suitable enthusiastic maintainer were to come forward ... [and No, I'm
not volunteering at this point!!!]


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] Re: chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

On Thu, 01 Sep 2016 22:03:37 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> [and No, I'm
> not volunteering at this point!!!]

Well volunteered [future] you.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Firefox bloat Was: chromium ...

[waltdnes]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Thu, Sep 01, 2016 at 02:36:27AM +0000, Duncan wrote

> FWIW, the australis thing never really affected me much.  I had some
> extensions (and configuration mania guified native options) changing
> the look somewhat before, and have some extensions (and config mania
> options) changing the look somewhat now.  It did take me several hours
> (between configuring and extension browsing) to get the new UI setup
> to something I was comfortable with, but then I'm used to that any
> time I change desktop (kde) major versions as well, and this was a
> comparable change.

  I had always customized Firefox's GUI to my own liking.  When I first
saw the Atrocious^H^H^H^H^H Austraulis gui, I said "No problem", I'll
reconfigure it, like I've always done before".  What really shocked me
was not only the garbage gui, but the fact that you couldn't get a sane
"classic" gui withing Firefox.  The Firefox people obviously knew that
users' first reaction would be to get rid of Australis, so they removed
that ability.

  Extensions soon sprang up that sort of allowed you to go back to a
sane desktop.  But I didn't want to go that far.  Australis was the
breaking point.  Attached is a sample of what the top of my Pale Moon
gui looks like, which is how I used to do Firefax way-back-when.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[-- Attachment #2: pm.png --]
[-- Type: image/png, Size: 57821 bytes --]