[users] 64 bit flash-plugin and 64 bit Firefox question

[Todd And Margo Chester]

Hi All,
SL6.0 x64
Firefox 4.0.1 64 bit binary from ftp.mozilla.org
http://fr2.rpmfind.net/linux/dag/redhat/el6/en/x86_64/rpmforge/RPMS/flash-plugin-10.3.162.29-0.1.el6.rf.x86_64.rpm
I have been Googling my butt off trying to figure out how
to get rpmforge's 64 bit flash plugin to work with my 64
bit Firefox. There are lots of articles but nothing works.
So, not ask too stupid a question and face the slings and
arrows of such, but how does one get rpmforge's 64 bit
flash-plugin to work with 64 bit Firefox?
Many thanks,
-T

Hi All,

I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)

Work around:

# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla

I filed a bug on this:

https://bugzilla.mozilla.org/show_bug.cgi?id=684441

Thanks to everyone for their helpful tips and suggestions!

-T

[Ljubomir Ljubojevic]

Hi All,
I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)
# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=684441
Thanks to everyone for their helpful tips and suggestions!
-T

I compiled Firefox 6 rpm based on the Remi's Fedora src.rpm and 64-bit
version works as expected with 64-bit flash plugin.

[Todd And Margo Chester]

Post by Ljubomir Ljubojevic

Hi All,
I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)
# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=684441
Thanks to everyone for their helpful tips and suggestions!
-T

I compiled Firefox 6 rpm based on the Remi's Fedora src.rpm and 64-bit
version works as expected with 64-bit flash plugin.

Yes. All the RPMs I have come across work perfectly with plug-ins. It
is just the binaries from releases.mozilla.org that do not.

[Jim Perrin]

The issue that you're running into is a hallmark of exactly why source
builds (or in your case 3rd party unpackaged binaries) and package
management don't mix. You're trying to circumvent the way the system was
designed to operate, and then complaining when it doesn't act as you'd
expect it to.

This applies pretty much across the board regardless of distribution,
whether is use deb or rpm. Use the package management system your
distribution provides.

On Sat, Sep 3, 2011 at 1:36 PM, Todd And Margo Chester <

Post by Todd And Margo Chester

Post by Ljubomir Ljubojevic

Hi All,
I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)
# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=684441
Thanks to everyone for their helpful tips and suggestions!
-T

I compiled Firefox 6 rpm based on the Remi's Fedora src.rpm and 64-bit
version works as expected with 64-bit flash plugin.

Yes. All the RPMs I have come across work perfectly with plug-ins. It
is just the binaries from releases.mozilla.org that do not.
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Todd And Margo Chester]

An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110903/2d17e217/attachment.html

[Yury V. Zaytsev]

The one my provider provides is way out of date and, arguably because
of it, a security hazard.

Not sure what your provider is, but mine is Red Hat and I am not aware
of known security risks in Firefox RPMs they are shipping. If there are
such risks they should be let known to them, so that they are patched.

The problem with Mozilla.org's binary is that it is looking at the 32
bit location for the plugins and not the 64 bit location. It is a
bug.

Not really, they just assume that on a 64-bit Linux system the libraries
are in /usr/lib, which does not hold true for Red Hat because of the
multiarch implementation that they are using, but might indeed hold true
for some other distributions (i.e. those that do not have multiarch
support at all).

Other than that, I am throughly confused as to your point. Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

Apart from multiarch, there are other more subtle issues with their "one
size fits all distros" binaries, i.e. last time I checked they were
using their own freetype, instead of relying on the system one, which
resulted in rendering artifacts on some systems etc.

[Akemi Yagi]

Post by Yury V. Zaytsev

The one my provider provides is way out of date and, arguably because
of it, a security hazard.

Not sure what your provider is, but mine is Red Hat and I am not aware
of known security risks in Firefox RPMs they are shipping. If there are
such risks they should be let known to them, so that they are patched.

Yes, the following link may help (note that it applies to clones such
as SL and CentOS):

https://access.redhat.com/security/updates/backporting/?sc_cid=3093

Post by Yury V. Zaytsev

Other than that, I am throughly confused as to your point. ?Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

About installing from source, this CentOS wiki explains why it must be
done with great care (if it is indeed needed):

http://wiki.centos.org/PackageManagement/SourceInstalls

Akemi

[Todd And Margo Chester]

Post by Akemi Yagi
Yes, the following link may help (note that it applies to clones such
https://access.redhat.com/security/updates/backporting/?sc_cid=3093

Hi Akemi,

In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. They never did either. I give up.

-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. They never did either. I give up.

I am still not convinced that these were valid reports in the first
place.

[Alan Bartlett]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. ?They never did either. ?I give up.

I am still not convinced that these were valid reports in the first
place.

In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

As you, me and many others know, Red Hat back-port all that is
relevant and necessary to the versions that they ship. There is
nothing "wrong" with Firefox 3.6.20 shipped with RHEL 6u1.

Essentially, this whole discussion is an irrelevance on any Repoforge
mailing list. There is no problem using any packages provided by
Repoforge. The Repoforge packages are designed for RHEL and its clone
OSes. If a user insists on modifying the OS structure from that which
is distributed, then that user must resolve the problems of her / his
making and not expect a third party repository to (incorrectly) modify
the packages it provides to "agree" with her / his "hacked" OS.

In essence, this was what Jim Perrin tried to impart earlier in this thread.

Alan.

[Jim Perrin]

Post by Alan Bartlett
In essence, this was what Jim Perrin tried to impart earlier in this thread.

And thank you for saying it more eloquently than I could!

[Alan Bartlett]

Post by Jim Perrin

Post by Alan Bartlett
In essence, this was what Jim Perrin tried to impart earlier in this thread.

And thank you for saying it more eloquently than I could!

burakkucat grins, raises a paw and waves it in a westerly direction,
over that damp puddle, towards Uncle Sam's land.

[Alan Bartlett]

Post by Jim Perrin

Post by Alan Bartlett
In essence, this was what Jim Perrin tried to impart earlier in this thread.

And thank you for saying it more eloquently than I could!

burakkucat grins, raises a paw and waves it in a westerly direction,
over that damp puddle, towards Uncle Sam's land.

[Yury V. Zaytsev]

Post by Alan Bartlett
In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

I only wish your words to fall on right ears ;-)

[Alan Bartlett]

Post by Yury V. Zaytsev

Post by Alan Bartlett
In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

I only wish your words to fall on right ears ;-)

I have a feeling that in this case, the message has now been understood. :-D

Alan.

[Alan Bartlett]

Post by Yury V. Zaytsev

Post by Alan Bartlett
In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

I only wish your words to fall on right ears ;-)

I have a feeling that in this case, the message has now been understood. :-D

Alan.

[Todd And Margo Chester]

Post by Alan Bartlett
In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

Hi Alan,

Without knowing what and why one is keeping current with Mozilla.org's
stuff,
you can not make this kind of evaluation. I do think you may be being
a bit of a purist.

For instance. My office servers are set up to emulate CentOS & SL
servers I have in the field. This is the reason for CentOS and SL.
(I would rather have FC 15, as it is not out of date. I am relegated to run
it in a virtual machine to support my few FC customers.)

Now the majority of my work (income) comes from that terrible
operating system whose name we shall not mention. And they
are all on the latest versions of Mozilla.org's stuff. So, in order
to make a living, I have to be see what they see. It also gives me
the added benefit of not running a defunct version of Mozilla.org's
stuff full of all kinds of security exploits that "someone" is not is the
"mood" to back port.

I.T. is a series of compromises. You can *never* get everything
exactly the way you want. (When I am king, I will demand that
Wine work perfectly with all programs written for that operating
system we shall not mention, starting with printing my envelopes,
not defaulting to A4 paper all the time, and not overlapping letters
on the printed page.) But, you can get real close!

I hope my disagreement on this tiny issue does not come across
as not appreciating your help. I appreciate it very much.

-T

p.s. I have had zero problems with the 32 bit binaries. I have
only had the plug-in problem with the 64 bit version. And, the code in
the binaries is *restricted* to a single directory which I can remove
at any time and do not have to go chasing all over my hard drive
looking for dependencies that conflict with this that and the other
thing. I currently have one of my office servers down as I
goofed the removal of Fedora People's (Leigh's) Firefox4. Never,
never would have happened with the binaries. (Okay, would not
have happened if I had not done something stupid out of frustration
with the broken dependencies either. Into everyone's a little
humility must fall.)

[Jim Perrin]

Post by Alan Bartlett
In essence, this was what Jim Perrin tried to impart earlier in this thread.

And thank you for saying it more eloquently than I could!

[Yury V. Zaytsev]

Post by Alan Bartlett
In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

I only wish your words to fall on right ears ;-)

[Todd And Margo Chester]

Post by Alan Bartlett
In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

Hi Alan,

Without knowing what and why one is keeping current with Mozilla.org's
stuff,
you can not make this kind of evaluation. I do think you may be being
a bit of a purist.

For instance. My office servers are set up to emulate CentOS & SL
servers I have in the field. This is the reason for CentOS and SL.
(I would rather have FC 15, as it is not out of date. I am relegated to run
it in a virtual machine to support my few FC customers.)

Now the majority of my work (income) comes from that terrible
operating system whose name we shall not mention. And they
are all on the latest versions of Mozilla.org's stuff. So, in order
to make a living, I have to be see what they see. It also gives me
the added benefit of not running a defunct version of Mozilla.org's
stuff full of all kinds of security exploits that "someone" is not is the
"mood" to back port.

I.T. is a series of compromises. You can *never* get everything
exactly the way you want. (When I am king, I will demand that
Wine work perfectly with all programs written for that operating
system we shall not mention, starting with printing my envelopes,
not defaulting to A4 paper all the time, and not overlapping letters
on the printed page.) But, you can get real close!

I hope my disagreement on this tiny issue does not come across
as not appreciating your help. I appreciate it very much.

-T

p.s. I have had zero problems with the 32 bit binaries. I have
only had the plug-in problem with the 64 bit version. And, the code in
the binaries is *restricted* to a single directory which I can remove
at any time and do not have to go chasing all over my hard drive
looking for dependencies that conflict with this that and the other
thing. I currently have one of my office servers down as I
goofed the removal of Fedora People's (Leigh's) Firefox4. Never,
never would have happened with the binaries. (Okay, would not
have happened if I had not done something stupid out of frustration
with the broken dependencies either. Into everyone's a little
humility must fall.)

[Todd And Margo Chester]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. They never did either. I give up.

I am still not convinced that these were valid reports in the first
place.

That was pretty much Red Hat's attitude. Didn't matter how important
Mozilla.org
thought they were. I remember referencing them some pretty
important/scary stuff.
Red Hat doesn't care. I think Red Hat thinks Mozilla.org just puts out
too much stuff
for them to bother keeping up with. Unusual for Red Hat, as my other
experiences
with them are that they are pretty responsive to requests from me. Red
Hat has
garnered a lot of good will with me in he past, especially with them
fixing my
cut a data DVD, ruin your hard drive problem.

-T

[Bryan J Smith]

Red Hat backports many fixes, instead of rebasing to latest.? It's actually an _added_ burden they incur, to mitigate changes in the profiles.

I.e., there are many enterprises who maintain a full GNOME-Firefox profile set, and a rebase of Firefox can cause issues.? Even when Red Hat rebases in an Update Beta, there are still some organizations that complain when the Update release comes out, and breaks a few profiles.

Many times some Firefox bugs are only found in newer versions.? And other times, sometimes the fixes break compatibility, when the issue isn't as much of a detail as people make it (especially Win32-only stuff that doesn't affect Linux).




----- Original Message -----
From: Todd And Margo Chester <toddandmargo at gmail.com>
Sent: Sunday, September 4, 2011 9:40 PM

That was pretty much Red Hat's attitude.? Didn't matter how important
Mozilla.org thought they were.? I remember referencing them some pretty
important/scary stuff.
Red Hat doesn't care.? I think Red Hat thinks Mozilla.org just puts out
too much stuff for them to bother keeping up with.? Unusual for Red Hat,
as my other experiences with them are that they are pretty responsive to
requests from me.? Red? Hat has garnered a lot of good will with me in
the past, especially with them? fixing my cut a data DVD, ruin your hard
drive problem.

[Todd And Margo Chester]

Red Hat backports many fixes, instead of rebasing to latest. It's actually an_added_ burden they incur, to mitigate changes in the profiles.

Red Hat does a pretty good job at this, except Firefox, which they ignore.

I.e., there are many enterprises who maintain a full GNOME-Firefox profile set, and a rebase of Firefox can cause issues. Even when Red Hat rebases in an Update Beta, there are still some organizations that complain when the Update release comes out, and breaks a few profiles.

Enterprise does have to be careful what they break. It is not perfect,
such as the "cut a data
DVD, trash your hard drive" issue in Enterprise 5 that Red Hat fixed for
me. I almost lost my
business, twice. So sometimes the out-of-date stuff can have a dark
side that is unintended.

Many times some Firefox bugs are only found in newer versions. And other times, sometimes the fixes break compatibility, when the issue isn't as much of a detail as people make it (especially Win32-only stuff that doesn't affect Linux).

Yes, but my experience with Firefox, I have pushed Firefox since day one
over two counties, is that
it just gets better and better. So, do you use the old version with all
its know exploits or do
you take a chance on a new version that may introduce something new? I
have *never*
had a problem with the new versions. If I do, since I am using the
binaries, all the code
is restricted to a single directory that can easily be removed with "rm
-rf". Then I will
just down load an older version. They are all up on releases.mozilla.org.

-T

[Bryan J Smith]

Did you actually verify Red Hat failed to backport a fix? Or did you just expect the newer version? You are not making the distinction in your posts.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Red Hat backports many fixes, instead of rebasing to latest. It's actually an_added_ burden they incur, to mitigate changes in the profiles.

Red Hat does a pretty good job at this, except Firefox, which they ignore.

I.e., there are many enterprises who maintain a full GNOME-Firefox profile set, and a rebase of Firefox can cause issues. Even when Red Hat rebases in an Update Beta, there are still some organizations that complain when the Update release comes out, and breaks a few profiles.

Enterprise does have to be careful what they break. It is not perfect,
such as the "cut a data
DVD, trash your hard drive" issue in Enterprise 5 that Red Hat fixed for
me. I almost lost my
business, twice. So sometimes the out-of-date stuff can have a dark
side that is unintended.

Many times some Firefox bugs are only found in newer versions. And other times, sometimes the fixes break compatibility, when the issue isn't as much of a detail as people make it (especially Win32-only stuff that doesn't affect Linux).

Yes, but my experience with Firefox, I have pushed Firefox since day one
over two counties, is that
it just gets better and better. So, do you use the old version with all
its know exploits or do
you take a chance on a new version that may introduce something new? I
have *never*
had a problem with the new versions. If I do, since I am using the
binaries, all the code
is restricted to a single directory that can easily be removed with "rm
-rf". Then I will
just down load an older version. They are all up on releases.mozilla.org.

-T
_____________________________________________

users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110904/ddcb976a/attachment.html

[Todd And Margo Chester]

Post by Bryan J Smith
Did you actually verify Red Hat failed to backport a fix? Or did you
just expect the newer version? You are not making the distinction in
your posts.

Hi Bryan,

It was years ago, so my memory is a bit challenged, but my recollection
was that I posted to Red Hat's bugzilla a couple of times with the Cert
exploit and all. I got ignored. And they did not just forget to update
the bugzilla as I saw no updates of any kind go through. What I took
from the experience was this is not something to waste your time on.

My technical opinion: I would not run an out dated browser. The security
danger you place yourself in does not merit any perceived stability
advantage of an older version. I part company with Red Hat on this
one. (Mozilla.org's binaries work fine.)

-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
My technical opinion: I would not run an out dated browser.

Your technical opinion has been noted. Now will this thread please stop
here? Let me revise the points made so far:

0) You don't want to use stock Firefox for whatever reason

1) Likewise, you don't want to use properly packaged Firefox --//---

2) RepoForge Flash plugin is now known to not to work by default with
binary bundles shipped by Mozilla, which we frankly don't care about

3) You made an unsubstantiated claim that stock Firefox is vulnerable to
open CVE's and RH is not taking appropriate actions to fix this

4) You reported a bug against Firefox which is technically not something
Mozilla should care about, since these issues are supposed to be taken
care of by distro packagers, because it's a matter of distro policy

5) An absolutely tangential never-ending discussion regarding release
cycles and software aging spun off

A number of people made other points, which you do not agree with, but I
don't see any further basis for discussion here, because any of this
(apart from (2) to a certain extent, maybe) is not even remotely
relevant to this list, which is devoted to the discussion of
complimentary packages designed to work with RHEL.

I am not against you expressing your technical opinions, but please feel
free do so on an appropriate list (I am sure such lists do exist),
otherwise it's just decreases the SNR and fills subscribers' inboxes
with irrelevant information.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
My technical opinion: I would not run an out dated browser.

I am not against you expressing your technical opinions, but please feel
free do so on an appropriate list (I am sure such lists do exist),
otherwise it's just decreases the SNR and fills subscribers' inboxes
with irrelevant information.

As Yury noted a few times, can we all end this thread here ?

I am not very fond of moderating this list, so I expect everyone to think
about whether a reply is to the benefit of all subscribers, or just a
reiteration to make your point across. In some cases, continuing the
discussion in private is a good way to come to a better understanding.

Anyway, as of today Yury is a list moderator and has the authority to do
pretty much as he pleases, so don't make him angry and stay on topic ;-)

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
My technical opinion: I would not run an out dated browser.

I am not against you expressing your technical opinions, but please feel
free do so on an appropriate list (I am sure such lists do exist),
otherwise it's just decreases the SNR and fills subscribers' inboxes
with irrelevant information.

As Yury noted a few times, can we all end this thread here ?

I am not very fond of moderating this list, so I expect everyone to think
about whether a reply is to the benefit of all subscribers, or just a
reiteration to make your point across. In some cases, continuing the
discussion in private is a good way to come to a better understanding.

Anyway, as of today Yury is a list moderator and has the authority to do
pretty much as he pleases, so don't make him angry and stay on topic ;-)

[Bryan J Smith]

Did you open a Ticket? Or just a Bugzilla?

And what you're saying here is that backports should never be done with Firefox? What about for those with many desktop profiles?

Post by Todd And Margo Chester

Post by Bryan J Smith
Did you actually verify Red Hat failed to backport a fix? Or did you
just expect the newer version? You are not making the distinction in
your posts.

Hi Bryan,
It was years ago, so my memory is a bit challenged, but my recollection
was that I posted to Red Hat's bugzilla a couple of times with the Cert
exploit and all. I got ignored. And they did not just forget to update
the bugzilla as I saw no updates of any kind go through. What I took
from the experience was this is not something to waste your time on.
My technical opinion: I would not run an out dated browser. The security
danger you place yourself in does not merit any perceived stability
advantage of an older version. I part company with Red Hat on this
one. (Mozilla.org's binaries work fine.)
-T
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Yury V. Zaytsev]

Post by Todd And Margo Chester
My technical opinion: I would not run an out dated browser.

Your technical opinion has been noted. Now will this thread please stop
here? Let me revise the points made so far:

0) You don't want to use stock Firefox for whatever reason

1) Likewise, you don't want to use properly packaged Firefox --//---

2) RepoForge Flash plugin is now known to not to work by default with
binary bundles shipped by Mozilla, which we frankly don't care about

3) You made an unsubstantiated claim that stock Firefox is vulnerable to
open CVE's and RH is not taking appropriate actions to fix this

4) You reported a bug against Firefox which is technically not something
Mozilla should care about, since these issues are supposed to be taken
care of by distro packagers, because it's a matter of distro policy

5) An absolutely tangential never-ending discussion regarding release
cycles and software aging spun off

A number of people made other points, which you do not agree with, but I
don't see any further basis for discussion here, because any of this
(apart from (2) to a certain extent, maybe) is not even remotely
relevant to this list, which is devoted to the discussion of
complimentary packages designed to work with RHEL.

I am not against you expressing your technical opinions, but please feel
free do so on an appropriate list (I am sure such lists do exist),
otherwise it's just decreases the SNR and fills subscribers' inboxes
with irrelevant information.

[Bryan J Smith]

Did you open a Ticket? Or just a Bugzilla?

And what you're saying here is that backports should never be done with Firefox? What about for those with many desktop profiles?

Post by Todd And Margo Chester

Post by Bryan J Smith
Did you actually verify Red Hat failed to backport a fix? Or did you
just expect the newer version? You are not making the distinction in
your posts.

Hi Bryan,
It was years ago, so my memory is a bit challenged, but my recollection
was that I posted to Red Hat's bugzilla a couple of times with the Cert
exploit and all. I got ignored. And they did not just forget to update
the bugzilla as I saw no updates of any kind go through. What I took
from the experience was this is not something to waste your time on.
My technical opinion: I would not run an out dated browser. The security
danger you place yourself in does not merit any perceived stability
advantage of an older version. I part company with Red Hat on this
one. (Mozilla.org's binaries work fine.)
-T
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Todd And Margo Chester]

Post by Bryan J Smith
Did you actually verify Red Hat failed to backport a fix? Or did you
just expect the newer version? You are not making the distinction in
your posts.

Hi Bryan,

It was years ago, so my memory is a bit challenged, but my recollection
was that I posted to Red Hat's bugzilla a couple of times with the Cert
exploit and all. I got ignored. And they did not just forget to update
the bugzilla as I saw no updates of any kind go through. What I took
from the experience was this is not something to waste your time on.

My technical opinion: I would not run an out dated browser. The security
danger you place yourself in does not merit any perceived stability
advantage of an older version. I part company with Red Hat on this
one. (Mozilla.org's binaries work fine.)

-T

[Bryan J Smith]

Did you actually verify Red Hat failed to backport a fix? Or did you just expect the newer version? You are not making the distinction in your posts.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Red Hat backports many fixes, instead of rebasing to latest. It's actually an_added_ burden they incur, to mitigate changes in the profiles.

Red Hat does a pretty good job at this, except Firefox, which they ignore.

I.e., there are many enterprises who maintain a full GNOME-Firefox profile set, and a rebase of Firefox can cause issues. Even when Red Hat rebases in an Update Beta, there are still some organizations that complain when the Update release comes out, and breaks a few profiles.

Enterprise does have to be careful what they break. It is not perfect,
such as the "cut a data
DVD, trash your hard drive" issue in Enterprise 5 that Red Hat fixed for
me. I almost lost my
business, twice. So sometimes the out-of-date stuff can have a dark
side that is unintended.

Many times some Firefox bugs are only found in newer versions. And other times, sometimes the fixes break compatibility, when the issue isn't as much of a detail as people make it (especially Win32-only stuff that doesn't affect Linux).

Yes, but my experience with Firefox, I have pushed Firefox since day one
over two counties, is that
it just gets better and better. So, do you use the old version with all
its know exploits or do
you take a chance on a new version that may introduce something new? I
have *never*
had a problem with the new versions. If I do, since I am using the
binaries, all the code
is restricted to a single directory that can easily be removed with "rm
-rf". Then I will
just down load an older version. They are all up on releases.mozilla.org.

-T
_____________________________________________

users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110904/ddcb976a/attachment-0002.html>

[Todd And Margo Chester]

Red Hat backports many fixes, instead of rebasing to latest. It's actually an_added_ burden they incur, to mitigate changes in the profiles.

Red Hat does a pretty good job at this, except Firefox, which they ignore.

I.e., there are many enterprises who maintain a full GNOME-Firefox profile set, and a rebase of Firefox can cause issues. Even when Red Hat rebases in an Update Beta, there are still some organizations that complain when the Update release comes out, and breaks a few profiles.

Enterprise does have to be careful what they break. It is not perfect,
such as the "cut a data
DVD, trash your hard drive" issue in Enterprise 5 that Red Hat fixed for
me. I almost lost my
business, twice. So sometimes the out-of-date stuff can have a dark
side that is unintended.

Many times some Firefox bugs are only found in newer versions. And other times, sometimes the fixes break compatibility, when the issue isn't as much of a detail as people make it (especially Win32-only stuff that doesn't affect Linux).

Yes, but my experience with Firefox, I have pushed Firefox since day one
over two counties, is that
it just gets better and better. So, do you use the old version with all
its know exploits or do
you take a chance on a new version that may introduce something new? I
have *never*
had a problem with the new versions. If I do, since I am using the
binaries, all the code
is restricted to a single directory that can easily be removed with "rm
-rf". Then I will
just down load an older version. They are all up on releases.mozilla.org.

-T

[Bryan J Smith]

Red Hat backports many fixes, instead of rebasing to latest.? It's actually an _added_ burden they incur, to mitigate changes in the profiles.

I.e., there are many enterprises who maintain a full GNOME-Firefox profile set, and a rebase of Firefox can cause issues.? Even when Red Hat rebases in an Update Beta, there are still some organizations that complain when the Update release comes out, and breaks a few profiles.

Many times some Firefox bugs are only found in newer versions.? And other times, sometimes the fixes break compatibility, when the issue isn't as much of a detail as people make it (especially Win32-only stuff that doesn't affect Linux).




----- Original Message -----
From: Todd And Margo Chester <toddandmargo at gmail.com>
Sent: Sunday, September 4, 2011 9:40 PM

That was pretty much Red Hat's attitude.? Didn't matter how important
Mozilla.org thought they were.? I remember referencing them some pretty
important/scary stuff.
Red Hat doesn't care.? I think Red Hat thinks Mozilla.org just puts out
too much stuff for them to bother keeping up with.? Unusual for Red Hat,
as my other experiences with them are that they are pretty responsive to
requests from me.? Red? Hat has garnered a lot of good will with me in
the past, especially with them? fixing my cut a data DVD, ruin your hard
drive problem.

[Alan Bartlett]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. ?They never did either. ?I give up.

I am still not convinced that these were valid reports in the first
place.

In all honesty, Yury, if a user of RHEL, Scientific Linux or CentOS
needs to constantly install the latest "whizzo" version of Firefox or
Thunderbird that Mozilla has just pushed out, then the wrong OS
distribution is being used.

As you, me and many others know, Red Hat back-port all that is
relevant and necessary to the versions that they ship. There is
nothing "wrong" with Firefox 3.6.20 shipped with RHEL 6u1.

Essentially, this whole discussion is an irrelevance on any Repoforge
mailing list. There is no problem using any packages provided by
Repoforge. The Repoforge packages are designed for RHEL and its clone
OSes. If a user insists on modifying the OS structure from that which
is distributed, then that user must resolve the problems of her / his
making and not expect a third party repository to (incorrectly) modify
the packages it provides to "agree" with her / his "hacked" OS.

In essence, this was what Jim Perrin tried to impart earlier in this thread.

Alan.

[Todd And Margo Chester]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. They never did either. I give up.

I am still not convinced that these were valid reports in the first
place.

That was pretty much Red Hat's attitude. Didn't matter how important
Mozilla.org
thought they were. I remember referencing them some pretty
important/scary stuff.
Red Hat doesn't care. I think Red Hat thinks Mozilla.org just puts out
too much stuff
for them to bother keeping up with. Unusual for Red Hat, as my other
experiences
with them are that they are pretty responsive to requests from me. Red
Hat has
garnered a lot of good will with me in he past, especially with them
fixing my
cut a data DVD, ruin your hard drive problem.

-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. They never did either. I give up.

I am still not convinced that these were valid reports in the first
place.

[Yury V. Zaytsev]

Post by Akemi Yagi

Post by Yury V. Zaytsev

Other than that, I am throughly confused as to your point. Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

About installing from source, this CentOS wiki explains why it must be

FYI, he is actually using relocatable statically linked binary bundles
provided by Mozilla which can be unpacked in an arbitrary directory and
run from there, so it's a little bit different than installing from
source, although some considerations still apply.

[Gary Gatling]

Hello,

I am using these relocatable statically linked binary bundles for both
thunderbird and firefox on CentOS 5 and RHEL 6 with no problems. In fact
I've been doing it for more than a year. (I think its more like 2 years) I
do use the 32 bit versions howver due to adobe flash issues. In RHEL 5 /
CentOS 5 you do need to add a newer libstdc++.so.6 library to the
firefox/thunderbird directory (I use libstdc++.so.6.0.10 placed in that
directory from fedora 9) I've also had to add the regular oracle java to
my browser instead of the openjdk. I realize this is kind of a hack.

I will probably switch to a 64 bit version of a firefox browser when adobe
changes how they support 64 bit OSes.

The advantage of doing this is that mozilla firefox itself tells you when
a new version is availible. On the day it comes out. And you just click
"update" and it magically updates itself to the latest version. As long
as you have write access to where the directory is. Kind of like how
"minecraft" works with updates to your ~/.minecraft directory. Or the way
"Second Life" updates itself in its special directory.

You can download these tarballs by going to mozilla.org and click on the
"Get Firefox" button. (much like how it works for Windows or Macintosh)
It will automaticaly detect you need the Linux version. This does not give
you source code. To get that you have to go elsewhere.

When I downloaded and tried fedora 15 I noticed they were still on firefox
4. I think its hard for the Linux distros to keep up due to firefox's
rapid development pace.

People might say if I want firefox 6.0.1 I should go use fedora 16 alpha
or a mac / windows or something. Or even switch to chrome. But I don't
want GNOME 3 or a 6 month support cycle or any mac/windows crap so I just
go ahead and do things a little bit differently and I end up just fine.
If your browser doesn't work for some reason one day you could always go
back to the distro provided binaries until you figure out what is wrong.
I'm pretty sure security issues will get patched in those. Just not any
new features.

I think that advice about not using source tarballs is very good for
beginners but once you've been using Red Hat Linux for a while you are
going to want to install some newer software to get some software you care
about to work. I have tons of stuff I've installed in /usr/local and /opt
and everything installed there works very well for me. I did not feel
like dealing with making a spec file for software only I will ever care
about. :)

Cheers,

Gary Gatling | ITECS Systems

Post by Yury V. Zaytsev

Post by Akemi Yagi

Post by Yury V. Zaytsev

Other than that, I am throughly confused as to your point. Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

About installing from source, this CentOS wiki explains why it must be

FYI, he is actually using relocatable statically linked binary bundles
provided by Mozilla which can be unpacked in an arbitrary directory and
run from there, so it's a little bit different than installing from
source, although some considerations still apply.
--
Sincerely yours,
Yury V. Zaytsev
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Ljubomir Ljubojevic]

Post by Gary Gatling
People might say if I want firefox 6.0.1 I should go use fedora 16 alpha
or a mac / windows or something. Or even switch to chrome. But I don't
want GNOME 3 or a 6 month support cycle or any mac/windows crap so I just
go ahead and do things a little bit differently and I end up just fine.
If your browser doesn't work for some reason one day you could always go
back to the distro provided binaries until you figure out what is wrong.
I'm pretty sure security issues will get patched in those. Just not any
new features.
I think that advice about not using source tarballs is very good for
beginners but once you've been using Red Hat Linux for a while you are
going to want to install some newer software to get some software you care
about to work. I have tons of stuff I've installed in /usr/local and /opt
and everything installed there works very well for me. I did not feel
like dealing with making a spec file for software only I will ever care
about. :)

Remi's repository has Firefox and Thunderbird src.rpms for Fedora.
Latest is 6.0.1. I've fixed spec file and recompiled them for CentOS 6,
but so far only for x86_64, and they are not signed yet. It works as
expected, in fact I am writing from Thunderbird 6.0.1 installed via yum.
I am planing to create packages that will install jre/java symlinks for
Firefox so it works without any modifications.
As soon as I make some changes so Remi's spec can be used unchanged for
EL6, I am going to contact him so he can build them for his repository.

The goal should always be to install everything from yum, so you can
easily deploy copies of your system, and to avoid "it does not work"
nightmares.

[Gary Gatling]

Post by Ljubomir Ljubojevic

Post by Gary Gatling
I think that advice about not using source tarballs is very good for
beginners but once you've been using Red Hat Linux for a while you are
going to want to install some newer software to get some software you care
about to work. I have tons of stuff I've installed in /usr/local and /opt
and everything installed there works very well for me. I did not feel
like dealing with making a spec file for software only I will ever care
about. :)

Remi's repository has Firefox and Thunderbird src.rpms for Fedora.
Latest is 6.0.1. I've fixed spec file and recompiled them for CentOS 6,
but so far only for x86_64, and they are not signed yet. It works as
expected, in fact I am writing from Thunderbird 6.0.1 installed via yum.
I am planing to create packages that will install jre/java symlinks for
Firefox so it works without any modifications.
As soon as I make some changes so Remi's spec can be used unchanged for
EL6, I am going to contact him so he can build them for his repository.
The goal should always be to install everything from yum, so you can
easily deploy copies of your system, and to avoid "it does not work"
nightmares.

Yes. You are 100% correct about that with things where you need to
replicate the software to many systems or users. Like I would never try
this hack with a lab of systems. The Red Hat packaged browser is "good
enough" for that for sure. :) And of course I won't care about web
servers or file servers, etc.

Why I use repoforge is to easily get all those awesome fedora packages so
I can build interesting software that would otherwise fail. So I am
extremely grateful for that service and also the stuff that actually
helps me use CentOS as a laptop OS. Things like vlc so I can watch DVD
movies. Or drivers for my wireless card in an old OS like centOS 5. A lot
of the stuff I build from source are weird emulators that there are no
rpms for. And they are only going to be on one box for one user. So thanks
for all these packages here. I do appriciate the service.

I'll shut up now and completely agree with folks if you hack the OS you
shouldn't expect the repo to fix around your oddities. like with /lib vs
/lib64. Its not a bug.

Cheers,

Gary Gatling | ITECS Systems

[Ljubomir Ljubojevic]

Post by Gary Gatling
Why I use repoforge is to easily get all those awesome fedora packages so
I can build interesting software that would otherwise fail. So I am
extremely grateful for that service and also the stuff that actually
helps me use CentOS as a laptop OS. Things like vlc so I can watch DVD
movies. Or drivers for my wireless card in an old OS like centOS 5. A lot
of the stuff I build from source are weird emulators that there are no
rpms for. And they are only going to be on one box for one user. So thanks
for all these packages here. I do appriciate the service.

Be aware that ElRepo has numerous kmod drivers with weak-updates, so
kernel change does not need neither dkms nor new kmdl package. The best
I have seen yet.

Post by Gary Gatling
I'll shut up now and completely agree with folks if you hack the OS you
shouldn't expect the repo to fix around your oddities. like with /lib vs
/lib64. Its not a bug.

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

[Yury V. Zaytsev]

Post by Ljubomir Ljubojevic

Post by Gary Gatling
I'll shut up now and completely agree with folks if you hack the OS you
shouldn't expect the repo to fix around your oddities. like with /lib vs
/lib64. Its not a bug.

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

It is way easier just to get latest FF packaged and you'll get minimum
side effects as a bonus.

Unfortunately, we don't have the ressources to package FF, so this
discussion would better continue elsewhere.

[Bryan J Smith]

On x86-64, it's easier just to install the couple of RPMs from x86 for Firefox, and then launching Firefox with the 'setarch' environment.? E.g.,
? $ setarch i386 firefox &

Remember, Firefox x86 is just installed under /usr/lib/ while Firefox x86-64 installed under /usr/lib64.? Instead of symlinks, install the appropriate packages, they should not conflict.


I documented how to do this with Fedora x86-64 here:?

- http://lists.leap-cf.org/pipermail/leaplist/2011-March/010751.html

I've also done it for EL as well.? It's none-too-difficult to do, especially if you have a RHN Satellite Server custom channel, or local YUM repositories.

?

----- Original Message -----
From: Ljubomir Ljubojevic <office at plnet.rs>
Sent: Sunday, September 4, 2011 4:01 PM

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

[Bryan J Smith]

On x86-64, it's easier just to install the couple of RPMs from x86 for Firefox, and then launching Firefox with the 'setarch' environment.? E.g.,
? $ setarch i386 firefox &

Remember, Firefox x86 is just installed under /usr/lib/ while Firefox x86-64 installed under /usr/lib64.? Instead of symlinks, install the appropriate packages, they should not conflict.


I documented how to do this with Fedora x86-64 here:?

- http://lists.leap-cf.org/pipermail/leaplist/2011-March/010751.html

I've also done it for EL as well.? It's none-too-difficult to do, especially if you have a RHN Satellite Server custom channel, or local YUM repositories.

?

----- Original Message -----
From: Ljubomir Ljubojevic <office at plnet.rs>
Sent: Sunday, September 4, 2011 4:01 PM

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

[Yury V. Zaytsev]

Post by Ljubomir Ljubojevic

Post by Gary Gatling
I'll shut up now and completely agree with folks if you hack the OS you
shouldn't expect the repo to fix around your oddities. like with /lib vs
/lib64. Its not a bug.

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

It is way easier just to get latest FF packaged and you'll get minimum
side effects as a bonus.

Unfortunately, we don't have the ressources to package FF, so this
discussion would better continue elsewhere.

[Bryan J Smith]

On x86-64, it's easier just to install the couple of RPMs from x86 for Firefox, and then launching Firefox with the 'setarch' environment.? E.g.,
? $ setarch i386 firefox &

Remember, Firefox x86 is just installed under /usr/lib/ while Firefox x86-64 installed under /usr/lib64.? Instead of symlinks, install the appropriate packages, they should not conflict.


I documented how to do this with Fedora x86-64 here:?

- http://lists.leap-cf.org/pipermail/leaplist/2011-March/010751.html

I've also done it for EL as well.? It's none-too-difficult to do, especially if you have a RHN Satellite Server custom channel, or local YUM repositories.

?

----- Original Message -----
From: Ljubomir Ljubojevic <office at plnet.rs>
Sent: Sunday, September 4, 2011 4:01 PM

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

[Bryan J Smith]

On x86-64, it's easier just to install the couple of RPMs from x86 for Firefox, and then launching Firefox with the 'setarch' environment.? E.g.,
? $ setarch i386 firefox &

Remember, Firefox x86 is just installed under /usr/lib/ while Firefox x86-64 installed under /usr/lib64.? Instead of symlinks, install the appropriate packages, they should not conflict.


I documented how to do this with Fedora x86-64 here:?

- http://lists.leap-cf.org/pipermail/leaplist/2011-March/010751.html

I've also done it for EL as well.? It's none-too-difficult to do, especially if you have a RHN Satellite Server custom channel, or local YUM repositories.

?

----- Original Message -----
From: Ljubomir Ljubojevic <office at plnet.rs>
Sent: Sunday, September 4, 2011 4:01 PM

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

[Ljubomir Ljubojevic]

Post by Gary Gatling
Why I use repoforge is to easily get all those awesome fedora packages so
I can build interesting software that would otherwise fail. So I am
extremely grateful for that service and also the stuff that actually
helps me use CentOS as a laptop OS. Things like vlc so I can watch DVD
movies. Or drivers for my wireless card in an old OS like centOS 5. A lot
of the stuff I build from source are weird emulators that there are no
rpms for. And they are only going to be on one box for one user. So thanks
for all these packages here. I do appriciate the service.

Be aware that ElRepo has numerous kmod drivers with weak-updates, so
kernel change does not need neither dkms nor new kmdl package. The best
I have seen yet.

Post by Gary Gatling
I'll shut up now and completely agree with folks if you hack the OS you
shouldn't expect the repo to fix around your oddities. like with /lib vs
/lib64. Its not a bug.

How about somehow redirecting /usr/lib -> /usr/lib64 just for Firefox?
like chrooted alias or something like that? This is just an brainstorm,
I like rpms more then anything!

[Gary Gatling]

Post by Ljubomir Ljubojevic

Post by Gary Gatling
I think that advice about not using source tarballs is very good for
beginners but once you've been using Red Hat Linux for a while you are
going to want to install some newer software to get some software you care
about to work. I have tons of stuff I've installed in /usr/local and /opt
and everything installed there works very well for me. I did not feel
like dealing with making a spec file for software only I will ever care
about. :)

Remi's repository has Firefox and Thunderbird src.rpms for Fedora.
Latest is 6.0.1. I've fixed spec file and recompiled them for CentOS 6,
but so far only for x86_64, and they are not signed yet. It works as
expected, in fact I am writing from Thunderbird 6.0.1 installed via yum.
I am planing to create packages that will install jre/java symlinks for
Firefox so it works without any modifications.
As soon as I make some changes so Remi's spec can be used unchanged for
EL6, I am going to contact him so he can build them for his repository.
The goal should always be to install everything from yum, so you can
easily deploy copies of your system, and to avoid "it does not work"
nightmares.

Yes. You are 100% correct about that with things where you need to
replicate the software to many systems or users. Like I would never try
this hack with a lab of systems. The Red Hat packaged browser is "good
enough" for that for sure. :) And of course I won't care about web
servers or file servers, etc.

Why I use repoforge is to easily get all those awesome fedora packages so
I can build interesting software that would otherwise fail. So I am
extremely grateful for that service and also the stuff that actually
helps me use CentOS as a laptop OS. Things like vlc so I can watch DVD
movies. Or drivers for my wireless card in an old OS like centOS 5. A lot
of the stuff I build from source are weird emulators that there are no
rpms for. And they are only going to be on one box for one user. So thanks
for all these packages here. I do appriciate the service.

I'll shut up now and completely agree with folks if you hack the OS you
shouldn't expect the repo to fix around your oddities. like with /lib vs
/lib64. Its not a bug.

Cheers,

Gary Gatling | ITECS Systems

[Bryan J Smith]

Fedora has a 2 release + 1 month lifecycle, which means any Fedora release typically has a 13-15 month lifecycle.? Fedora can and does rebase when required, but not always.


EL, on the other hand, has a 7-10 year life cycle, with a 3-5 year Phase I-II "enhancement" period.? EL tries to avoid rebasing at all costs, with very select reasons when it does rebase.


So what you want is something that has a 2+ year "desktop-centric" rebasing lifecycle.? If so, then instead of trying to interject yet a 3rd approach, why not contribute to Fedora and push consideration of the Extended Support to a 3 release + 1 month cycle?


I know most people would love to be able to run with Fedora for 18+ months, instead of only 12+ months.? That would solve most of the current desires for what you, among others, seek out of EL or EL rebuilds.



----- Original Message -----
From: Gary Gatling <gsgatlin at ncsu.edu>
Sent: Sunday, September 4, 2011 11:49 AM

... But I don't want GNOME 3 or a 6 month support cycle or any mac/windows
crap so I just go ahead and do things a little bit differently ...

[Ljubomir Ljubojevic]

Post by Bryan J Smith
I know most people would love to be able to run with Fedora for 18+ months, instead of only 12+ months.
That would solve most of the current desires for what you, among

others, seek out of EL or EL rebuilds.

Curently, and for 2-3 years at least, Any/many packages for Fedora are
easy to recompile for EL6. It will get more complicated with time, but
there will always be third party repositories that will offer newer
version. You just need someone that will monitor patches made and update
regularly.
So there is no need for this discussion.

[Bryan J Smith]

Really? Has there been the same with EL5 as well? I'm just speaking from experience here, I suggests otherwise.

Do enterprises really pick from various repos and aggregate them, hoping they are updated? with securing fixes?

And I thought we're weren't talking latest. I thought we were talking a 3rd "standard" between Fedora and EL?

Most enterprises I've worked in have an annual build standard and refresh desktop software every 18-24 months.

In just 18 months we'll be looking at Fedora 19, which is a far cry from Fedora 12/13 (EL6). Maybe EL7 will be out by then, maybe not.

I just see a lot of gaps and questions, just like back for EL5. On the other foot, there is a real call by Fedora with something more exacting. Just had to point that out.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Post by Bryan J Smith
I know most people would love to be able to run with Fedora for 18+ months, instead of only 12+ months.
That would solve most of the current desires for what you, among

others, seek out of EL or EL rebuilds.

Curently, and for 2-3 years at least, Any/many packages for Fedora are
easy to recompile for EL6. It will get more complicated with time, but
there will always be third party repositories that will offer newer
version. You just need someone that will monitor patches made and update
regularly.
So there is no need for this discussion.
--
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110905/08f80a85/attachment.html

[Bryan J Smith]

Really? Has there been the same with EL5 as well? I'm just speaking from experience here, I suggests otherwise.

Do enterprises really pick from various repos and aggregate them, hoping they are updated? with securing fixes?

And I thought we're weren't talking latest. I thought we were talking a 3rd "standard" between Fedora and EL?

Most enterprises I've worked in have an annual build standard and refresh desktop software every 18-24 months.

In just 18 months we'll be looking at Fedora 19, which is a far cry from Fedora 12/13 (EL6). Maybe EL7 will be out by then, maybe not.

I just see a lot of gaps and questions, just like back for EL5. On the other foot, there is a real call by Fedora with something more exacting. Just had to point that out.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Post by Bryan J Smith
I know most people would love to be able to run with Fedora for 18+ months, instead of only 12+ months.
That would solve most of the current desires for what you, among

others, seek out of EL or EL rebuilds.

Curently, and for 2-3 years at least, Any/many packages for Fedora are
easy to recompile for EL6. It will get more complicated with time, but
there will always be third party repositories that will offer newer
version. You just need someone that will monitor patches made and update
regularly.
So there is no need for this discussion.
--
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110905/08f80a85/attachment-0002.html>

[Ljubomir Ljubojevic]

Post by Bryan J Smith
I know most people would love to be able to run with Fedora for 18+ months, instead of only 12+ months.
That would solve most of the current desires for what you, among

others, seek out of EL or EL rebuilds.

Curently, and for 2-3 years at least, Any/many packages for Fedora are
easy to recompile for EL6. It will get more complicated with time, but
there will always be third party repositories that will offer newer
version. You just need someone that will monitor patches made and update
regularly.
So there is no need for this discussion.

[Ljubomir Ljubojevic]

Post by Gary Gatling
People might say if I want firefox 6.0.1 I should go use fedora 16 alpha
or a mac / windows or something. Or even switch to chrome. But I don't
want GNOME 3 or a 6 month support cycle or any mac/windows crap so I just
go ahead and do things a little bit differently and I end up just fine.
If your browser doesn't work for some reason one day you could always go
back to the distro provided binaries until you figure out what is wrong.
I'm pretty sure security issues will get patched in those. Just not any
new features.
I think that advice about not using source tarballs is very good for
beginners but once you've been using Red Hat Linux for a while you are
going to want to install some newer software to get some software you care
about to work. I have tons of stuff I've installed in /usr/local and /opt
and everything installed there works very well for me. I did not feel
like dealing with making a spec file for software only I will ever care
about. :)

Remi's repository has Firefox and Thunderbird src.rpms for Fedora.
Latest is 6.0.1. I've fixed spec file and recompiled them for CentOS 6,
but so far only for x86_64, and they are not signed yet. It works as
expected, in fact I am writing from Thunderbird 6.0.1 installed via yum.
I am planing to create packages that will install jre/java symlinks for
Firefox so it works without any modifications.
As soon as I make some changes so Remi's spec can be used unchanged for
EL6, I am going to contact him so he can build them for his repository.

The goal should always be to install everything from yum, so you can
easily deploy copies of your system, and to avoid "it does not work"
nightmares.

[Bryan J Smith]

Fedora has a 2 release + 1 month lifecycle, which means any Fedora release typically has a 13-15 month lifecycle.? Fedora can and does rebase when required, but not always.


EL, on the other hand, has a 7-10 year life cycle, with a 3-5 year Phase I-II "enhancement" period.? EL tries to avoid rebasing at all costs, with very select reasons when it does rebase.


So what you want is something that has a 2+ year "desktop-centric" rebasing lifecycle.? If so, then instead of trying to interject yet a 3rd approach, why not contribute to Fedora and push consideration of the Extended Support to a 3 release + 1 month cycle?


I know most people would love to be able to run with Fedora for 18+ months, instead of only 12+ months.? That would solve most of the current desires for what you, among others, seek out of EL or EL rebuilds.



----- Original Message -----
From: Gary Gatling <gsgatlin at ncsu.edu>
Sent: Sunday, September 4, 2011 11:49 AM

... But I don't want GNOME 3 or a 6 month support cycle or any mac/windows
crap so I just go ahead and do things a little bit differently ...

[Gary Gatling]

Hello,

I am using these relocatable statically linked binary bundles for both
thunderbird and firefox on CentOS 5 and RHEL 6 with no problems. In fact
I've been doing it for more than a year. (I think its more like 2 years) I
do use the 32 bit versions howver due to adobe flash issues. In RHEL 5 /
CentOS 5 you do need to add a newer libstdc++.so.6 library to the
firefox/thunderbird directory (I use libstdc++.so.6.0.10 placed in that
directory from fedora 9) I've also had to add the regular oracle java to
my browser instead of the openjdk. I realize this is kind of a hack.

I will probably switch to a 64 bit version of a firefox browser when adobe
changes how they support 64 bit OSes.

The advantage of doing this is that mozilla firefox itself tells you when
a new version is availible. On the day it comes out. And you just click
"update" and it magically updates itself to the latest version. As long
as you have write access to where the directory is. Kind of like how
"minecraft" works with updates to your ~/.minecraft directory. Or the way
"Second Life" updates itself in its special directory.

You can download these tarballs by going to mozilla.org and click on the
"Get Firefox" button. (much like how it works for Windows or Macintosh)
It will automaticaly detect you need the Linux version. This does not give
you source code. To get that you have to go elsewhere.

When I downloaded and tried fedora 15 I noticed they were still on firefox
4. I think its hard for the Linux distros to keep up due to firefox's
rapid development pace.

People might say if I want firefox 6.0.1 I should go use fedora 16 alpha
or a mac / windows or something. Or even switch to chrome. But I don't
want GNOME 3 or a 6 month support cycle or any mac/windows crap so I just
go ahead and do things a little bit differently and I end up just fine.
If your browser doesn't work for some reason one day you could always go
back to the distro provided binaries until you figure out what is wrong.
I'm pretty sure security issues will get patched in those. Just not any
new features.

I think that advice about not using source tarballs is very good for
beginners but once you've been using Red Hat Linux for a while you are
going to want to install some newer software to get some software you care
about to work. I have tons of stuff I've installed in /usr/local and /opt
and everything installed there works very well for me. I did not feel
like dealing with making a spec file for software only I will ever care
about. :)

Cheers,

Gary Gatling | ITECS Systems

Post by Yury V. Zaytsev

Post by Akemi Yagi

Post by Yury V. Zaytsev

Other than that, I am throughly confused as to your point. Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

About installing from source, this CentOS wiki explains why it must be

FYI, he is actually using relocatable statically linked binary bundles
provided by Mozilla which can be unpacked in an arbitrary directory and
run from there, so it's a little bit different than installing from
source, although some considerations still apply.
--
Sincerely yours,
Yury V. Zaytsev
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Todd And Margo Chester]

Post by Akemi Yagi
Yes, the following link may help (note that it applies to clones such
https://access.redhat.com/security/updates/backporting/?sc_cid=3093

Hi Akemi,

In days of yesteryear, I use to post bugs on Firefox security exploits
on Red Hat's bugzilla and ask them to backport or upgrade Firefox to
cover them. They never did either. I give up.

-T

[Yury V. Zaytsev]

Post by Akemi Yagi

Post by Yury V. Zaytsev

Other than that, I am throughly confused as to your point. Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

About installing from source, this CentOS wiki explains why it must be

FYI, he is actually using relocatable statically linked binary bundles
provided by Mozilla which can be unpacked in an arbitrary directory and
run from there, so it's a little bit different than installing from
source, although some considerations still apply.

[Akemi Yagi]

Post by Yury V. Zaytsev

The one my provider provides is way out of date and, arguably because
of it, a security hazard.

Not sure what your provider is, but mine is Red Hat and I am not aware
of known security risks in Firefox RPMs they are shipping. If there are
such risks they should be let known to them, so that they are patched.

Yes, the following link may help (note that it applies to clones such
as SL and CentOS):

https://access.redhat.com/security/updates/backporting/?sc_cid=3093

Post by Yury V. Zaytsev

Other than that, I am throughly confused as to your point. ?Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

About installing from source, this CentOS wiki explains why it must be
done with great care (if it is indeed needed):

http://wiki.centos.org/PackageManagement/SourceInstalls

Akemi

[Yury V. Zaytsev]

The one my provider provides is way out of date and, arguably because
of it, a security hazard.

Not sure what your provider is, but mine is Red Hat and I am not aware
of known security risks in Firefox RPMs they are shipping. If there are
such risks they should be let known to them, so that they are patched.

The problem with Mozilla.org's binary is that it is looking at the 32
bit location for the plugins and not the 64 bit location. It is a
bug.

Not really, they just assume that on a 64-bit Linux system the libraries
are in /usr/lib, which does not hold true for Red Hat because of the
multiarch implementation that they are using, but might indeed hold true
for some other distributions (i.e. those that do not have multiarch
support at all).

Other than that, I am throughly confused as to your point. Maybe I
am missing something.

I guess his point was that you should build your own RPMs if you
desperately need latest Firefox, using binary releases from Mozilla is
not the best option, although they might work to a certain extent.

Apart from multiarch, there are other more subtle issues with their "one
size fits all distros" binaries, i.e. last time I checked they were
using their own freetype, instead of relying on the system one, which
resulted in rendering artifacts on some systems etc.

[Todd And Margo Chester]

An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110903/2d17e217/attachment-0002.html>

[Jim Perrin]

The issue that you're running into is a hallmark of exactly why source
builds (or in your case 3rd party unpackaged binaries) and package
management don't mix. You're trying to circumvent the way the system was
designed to operate, and then complaining when it doesn't act as you'd
expect it to.

This applies pretty much across the board regardless of distribution,
whether is use deb or rpm. Use the package management system your
distribution provides.

On Sat, Sep 3, 2011 at 1:36 PM, Todd And Margo Chester <

Post by Todd And Margo Chester

Post by Ljubomir Ljubojevic

Hi All,
I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)
# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=684441
Thanks to everyone for their helpful tips and suggestions!
-T

I compiled Firefox 6 rpm based on the Remi's Fedora src.rpm and 64-bit
version works as expected with 64-bit flash plugin.

Yes. All the RPMs I have come across work perfectly with plug-ins. It
is just the binaries from releases.mozilla.org that do not.
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

[Todd And Margo Chester]

Post by Ljubomir Ljubojevic

Hi All,
I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)
# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=684441
Thanks to everyone for their helpful tips and suggestions!
-T

I compiled Firefox 6 rpm based on the Remi's Fedora src.rpm and 64-bit
version works as expected with 64-bit flash plugin.

Yes. All the RPMs I have come across work perfectly with plug-ins. It
is just the binaries from releases.mozilla.org that do not.

[Todd And Margo Chester]

Hi All,
SL6.0 x64
Firefox 4.0.1 64 bit binary from ftp.mozilla.org
http://fr2.rpmfind.net/linux/dag/redhat/el6/en/x86_64/rpmforge/RPMS/flash-plugin-10.3.162.29-0.1.el6.rf.x86_64.rpm
I have been Googling my butt off trying to figure out how
to get rpmforge's 64 bit flash plugin to work with my 64
bit Firefox. There are lots of articles but nothing works.
So, not ask too stupid a question and face the slings and
arrows of such, but how does one get rpmforge's 64 bit
flash-plugin to work with 64 bit Firefox?
Many thanks,
-T

Hi All,

I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)

Work around:

# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla

I filed a bug on this:

https://bugzilla.mozilla.org/show_bug.cgi?id=684441

Thanks to everyone for their helpful tips and suggestions!

-T

[Ljubomir Ljubojevic]

Hi All,
I "finally" figured this out. The problem is with the 64 bit
Firefox binaries from releases.mozilla.org. (The 64 bit RPMs
floating around do not have this problem.)
# mv /usr/lib/mozilla /usr/lib/mozilla.000
# ln -s /usr/lib64/mozilla /usr/lib/mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=684441
Thanks to everyone for their helpful tips and suggestions!
-T

I compiled Firefox 6 rpm based on the Remi's Fedora src.rpm and 64-bit
version works as expected with 64-bit flash plugin.