On 02/10/2011 02:59 AM, Larry Vaden wrote:
On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon<[email protected]> wrote:
I'm a little bit hazy on the details, but there are some slides from the
meeting here[1]:
http://indico.cern.ch/getFile.py/access?contribId=8&sessionId=1&resId=1&materialId=slides&confId=106641
THANKS!
On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones
<[email protected]> wrote:
I would say a bug in tcmalloc, not SL or RHEL. See for instance
<http://code.google.com/p/google-perftools/issues/detail?id=305>
The fix is to move to google perftools 1.7
Because of a problem with not running the current BIND release a
couple of weeks ago, I would like to ask:
a) is RedHat likely to choose to backport the fix to 1.6 or will it
adopt 1.7 or leave as is until 5.7 or later?
google-perftools comes from epel, not rhel. What the epel
google-perftools maintainer will do is not easy to judge. I don't know
how to interpret https://bugzilla.redhat.com/show_bug.cgi?id=675376.
But since this is epel and not rhel, I see no relation to the 5.7
release. I would expect that epel maintainers react to this
incompatibility between google-perftools and the current rhel release.
But then again i have not found an epel bugzilla entry that explicitly
mentions the problem.
Matthias
b) will Centos and/or SL follow RH exactly or will their approaches differ?
IOW, how far does the "binary compatiblity" policy extend?
kind regards/ldv
