CentOS - Oct 2020 - Firefox 78 under CentOS 6 -- no sound?

On Wed, 21 Oct 2020 at 14:03, Yves Bellefeuille <yan at storm.ca> wrote:
> Leon Fauster via CentOS <centos at centos.org> wrote:
>
> >  ... or a general problem. Does some one tried the version from
> >  mozilla?
> >
> >  https://www.mozilla.org/en-US/firefox/all/#product-desktop-esr
> >
> >  Can't test it - I don't run EL6 workstations anymore ...
>
> [yves at home firefox]$ ./firefox
> ./firefox: /lib64/libc.so.6: version `GLIBC_2.17' not found (required
> by ./firefox)
> ./firefox: /lib64/libc.so.6: version `GLIBC_2.14' not found (required
> by ./firefox)
>
> CentOS 6 only goes up to glibc 2.12.
>
>
Basically that says that upstream no longer thinks that Firefox is runnable
on RHEL-6/CentOS-6 anymore. I think there was a similar problem at the end
of EL-5 when a 'YOU HAVE TO UPGRADE' fix from Mozilla was released and
while a lot of work was done by Red Hat to get it to work on RHEL-5, some
items (and I really think it was sound and plugins) did not work. At the
tail end of a release, most 'desktop' concerns are very hard to figure
out
as 10 year old software API's are rarely kept working by the various
'upstreams'.

I want to be clear that I do understand this is causing major issues for
users. I think a lesson learned from EL-5 and EL-6 is that EL releases need
to be clearer on the difference between desktops and servers. There seems
to be a point where desktop utilities fixes are mainly going to be
'reasonable effort' versus 'guaranteed' to be 100%... usually in
the last 6
months of a release. That way users can plan better that a certain amount
of work is going to be needed by them to continue it working.


> --
> Yves Bellefeuille
> <yan at storm.ca>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

-- 
Stephen J Smoogen.

>
> Basically that says that upstream no longer thinks that Firefox is runnable
> on RHEL-6/CentOS-6 anymore. I think there was a similar problem at the end
> of EL-5 when a 'YOU HAVE TO UPGRADE' fix from Mozilla was released
and
> while a lot of work was done by Red Hat to get it to work on RHEL-5, some
> items (and I really think it was sound and plugins) did not work. At the
> tail end of a release, most 'desktop' concerns are very hard to
figure out
> as 10 year old software API's are rarely kept working by the various
> 'upstreams'.
> I want to be clear that I do understand this is causing major issues for
> users. I think a lesson learned from EL-5 and EL-6 is that EL releases need
> to be clearer on the difference between desktops and servers. There seems
> to be a point where desktop utilities fixes are mainly going to be
> 'reasonable effort' versus 'guaranteed' to be 100%...
usually in the last 6
> months of a release. That way users can plan better that a certain amount
> of work is going to be needed by them to continue it working.
Upgrades for users would be a lot easier if the "upgrade" option on
the install was more of an upgrade.   I have seen the arguments on how Ubuntu
upgrades leave unneeded packages littering the machine.  However, at a minimum I
would think an upgrade should keep /etc/hosts, /etc/passwd, /etc/shadow,
/etc/sysconfig/network-scripts, the list if repos in use.   This would at least
put the machine in a usable state from the get go.  Saving a list of the
applications which would not be reloaded as part of the upgrade would also be
useful.  It would at least make it possible to get a running start at rebuilding
the users environment.   My issues come from the conversion of CentOS 4 and 5 to
6.   Maybe it is all better going to CentOS 8 (wishful thinking?)


_______________________________________________
CentOS mailing list
CentOS at centos.org
https://lists.centos.org/mailman/listinfo/centos

On Wednesday 21 October 2020, Stephen John Smoogen <smooge at gmail.com> 
wrote:
> > [yves at home firefox]$ ./firefox
> > ./firefox: /lib64/libc.so.6: version `GLIBC_2.17' not found
> > (required by ./firefox)
> > ./firefox: /lib64/libc.so.6: version `GLIBC_2.14' not found
> > (required by ./firefox)
> >
> > CentOS 6 only goes up to glibc 2.12.
> 
> Basically that says that upstream no longer thinks that Firefox is
> runnable on RHEL-6/CentOS-6 anymore. 
That message was from Firefox 78.4 ESR downloaded from Mozilla. 
Obviously Red Hat does think that it's possible to run Firefox 78.3 ESR 
on RHEL 6, because they shipped it. They just didn't get the sound 
working properly.

But end of life is in 6 weeks, so perhaps nobody will bother fixing the 
problem.

-- 
Yves Bellefeuille <yan at storm.ca>
GPG key 837A6134 at http://members.storm.ca/~yan/pgp.asc

On 22/10/20 10:25 am, Stephen John Smoogen wrote:
> Basically that says that upstream no longer thinks that Firefox is runnable
> on RHEL-6/CentOS-6 anymore. I think there was a similar problem at the end
> of EL-5 when a 'YOU HAVE TO UPGRADE' fix from Mozilla was released
and
> while a lot of work was done by Red Hat to get it to work on RHEL-5, some
> items (and I really think it was sound and plugins) did not work. At the
> tail end of a release, most 'desktop' concerns are very hard to
figure out
> as 10 year old software API's are rarely kept working by the various
> 'upstreams'.
> 
> I want to be clear that I do understand this is causing major issues for
> users. I think a lesson learned from EL-5 and EL-6 is that EL releases need
> to be clearer on the difference between desktops and servers. There seems
> to be a point where desktop utilities fixes are mainly going to be
> 'reasonable effort' versus 'guaranteed' to be 100%...
usually in the last 6
> months of a release. That way users can plan better that a certain amount
> of work is going to be needed by them to continue it working.
What confuses me here is why would Red Hat rebase a package so close to 
EOL.  Now that they have they're stuck with either leaving a severly 
broken firefox or providing a fix less than 6 weeks before EOL.  I 
honestly don't know which way they'll go here but it just seems to me 
like it was a very poor decision to rebase firefox in RHEL6 so close to 
EOL to begin with.


Peter

Peter wrote:
>
> What confuses me here is why would Red Hat rebase a package so close to
> EOL.  Now that they have they're stuck with either leaving a severly
> broken firefox or providing a fix less than 6 weeks before EOL.  I
> honestly don't know which way they'll go here but it just seems to
me
> like it was a very poor decision to rebase firefox in RHEL6 so close to
> EOL to begin with.
I'm guessing that as Firefox ESR 68 is now a year 'out-of-date' (and
no longer supported by Mozilla), that they wanted to provide a more up to date
version for those that want to continue using EL6 after its EOL ?

Just a thought, has anyone checked that the Redhat RHEL 6 build of ESR 78 works
or or not? i.e. could it be an issue just with the CentOS build ?

James Pearson