In order to avoid a cross post, the following background quote is from SCIENTIFIC-LINUX-USERS@fnal.gov:
<quote> On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon ewan@macmahon.me.uk 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&resI...
On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones christopher.rob.jones@cern.ch 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
</quote>
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 as it has done with BIND?
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
On 10/02/11 02:05, Larry Vaden wrote:
In order to avoid a cross post, the following background quote is from SCIENTIFIC-LINUX-USERS@fnal.gov:
<quote> On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon<ewan@macmahon.me.uk> 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
On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones christopher.rob.jones@cern.ch 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
</quote>
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 as it has done with BIND?
b) will Centos and/or SL follow RH exactly or will their approaches differ?
IOW, how far does the "binary compatiblity" policy extend?
Bug for bug - if the bug is in RHEL-5.6 then it will be in CentOS too.
If it's important to you, file a bug upstream with Red Hat and get it fixed. The fix will naturally flow back downstream to CentOS.
Of course CentOS does have the freedom to do things differently to Red Hat if they want to, but if they do generally it will be outside of the main base/updates) repositories.
On 02/10/2011 12:37 AM, Ned Slider wrote:
On 10/02/11 02:05, Larry Vaden wrote:
In order to avoid a cross post, the following background quote is from SCIENTIFIC-LINUX-USERS@fnal.gov:
<quote> On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon<ewan@macmahon.me.uk> 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
On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones christopher.rob.jones@cern.ch 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
</quote>
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 as it has done with BIND?
b) will Centos and/or SL follow RH exactly or will their approaches differ?
IOW, how far does the "binary compatiblity" policy extend?
Bug for bug - if the bug is in RHEL-5.6 then it will be in CentOS too.
If it's important to you, file a bug upstream with Red Hat and get it fixed. The fix will naturally flow back downstream to CentOS.
Of course CentOS does have the freedom to do things differently to Red Hat if they want to, but if they do generally it will be outside of the main base/updates) repositories.
This is correct, CentOS would add an updated package somewhere (our people.centos.org site or the centos-testing repository would be the likely places).
We want our release to be the same source code where ever possible ... only changing things as required to meet trademark restrictions.
I can't speak to how SL will do it.
On Thu, Feb 10, 2011 at 04:53:09AM -0600, Johnny Hughes wrote:
This is correct, CentOS would add an updated package somewhere (our people.centos.org site or the centos-testing repository would be the likely places).
We want our release to be the same source code where ever possible ... only changing things as required to meet trademark restrictions.
In general, is there a process for deciding whether a package is qualified for inclusion in the centosplus repo? I imagine it's something along the lines of "this package had better be well-built and important enough to break 100% binary compatibility", but I can't find anything specific in the docs. (I personally only use the XFS-related packages out of centosplus, but I can imagine wanting to watch it if other packages appear there that might be useful or interesting.)
--keith
On 02/10/2011 01:33 PM, Keith Keller wrote:
On Thu, Feb 10, 2011 at 04:53:09AM -0600, Johnny Hughes wrote:
This is correct, CentOS would add an updated package somewhere (our people.centos.org site or the centos-testing repository would be the likely places).
We want our release to be the same source code where ever possible ... only changing things as required to meet trademark restrictions.
In general, is there a process for deciding whether a package is qualified for inclusion in the centosplus repo? I imagine it's something along the lines of "this package had better be well-built and important enough to break 100% binary compatibility", but I can't find anything specific in the docs. (I personally only use the XFS-related packages out of centosplus, but I can imagine wanting to watch it if other packages appear there that might be useful or interesting.)
Basically, we would not likely fix issues in centosplus, but in a different place (like a bug entry and a link to a totally separate RPM for this issue).
CentosPlus would be for things like a newer version of PHP or Mysql, etc.
The one exception to that is the kernel ... we do roll in fixes as well as added features in the centosplus kernels.
As far as what gets added to plus, basically it is items that one of the developers will maintain ... usually because the developer needs it as well.
There are any number of 3rd party repos that maintain many newer packages, so getting things into CentOSPlus is not the only option.
On Thu, Feb 10, 2011 at 2:06 PM, Johnny Hughes johnny@centos.org wrote:
There are any number of 3rd party repos that maintain many newer packages, so getting things into CentOSPlus is not the only option.
I would very much appreciate your referral to a repo that has a current BIND.
On Thu, Feb 10, 2011 at 02:59:48PM -0600, Larry Vaden wrote:
On Thu, Feb 10, 2011 at 2:06 PM, Johnny Hughes johnny@centos.org wrote:
There are any number of 3rd party repos that maintain many newer packages, so getting things into CentOSPlus is not the only option.
I would very much appreciate your referral to a repo that has a current BIND.
I'm not aware of one. Would you consider using a Fedora RPM? You could rebuild from the F14 SRPM for EL6. Probably would work pretty well.
You'd have to track security updates and such of course on your own...
Ray
On Thu, Feb 10, 2011 at 3:02 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
On Thu, Feb 10, 2011 at 02:59:48PM -0600, Larry Vaden wrote:
On Thu, Feb 10, 2011 at 2:06 PM, Johnny Hughes johnny@centos.org wrote:
There are any number of 3rd party repos that maintain many newer packages, so getting things into CentOSPlus is not the only option.
I would very much appreciate your referral to a repo that has a current BIND.
I'm not aware of one. Would you consider using a Fedora RPM? You could rebuild from the F14 SRPM for EL6. Probably would work pretty well.
You'd have to track security updates and such of course on your own...
Back when rural T1s were $1500/month and BSD licenses were still the subject of litigation and high $, each basic function an ISP must provide was a purpose built box and the OS was chosen with great sway to the function's authors' choice.
To harden the ISP functions against exploits in a later stage, we used FreeBSD and RedHat for the same function (e.g, ns1 was FreeBSD, ns2 was RedHat) so a miscreant could only take out half of the purpose built boxen. . Eventually, we outsourced the configuration of the most important function, DNS, to miceandmen.com and they used the latest Fedora along with the latest BIND source compiled off site so that miscreants didn't find much to exploit.
Now, with all basic functions back in house, YES, wrt the DNS function, FC14, which includes bind-9.7.2-5.P3.fc14 is interesting and must be considered along with CentOS plus Paul Vixie/ISC's latest source code for BIND now that we have listened to what the CentOS community has to say.
kind regards/ldv
Larry, could you please stop spamming this list with problems you see on the SL list? Thanks. This package isn't even part of CentOS.
Kai
On Thu, Feb 10, 2011 at 12:42:48PM +0100, Kai Schaetzl wrote:
Larry, could you please stop spamming this list with problems you see on the SL list? Thanks. This package isn't even part of CentOS.
Personally, I have no problem with it. Cross-community communication over potentially shared problems should be welcomed.
Larry was probably unaware the package wasn't in CentOS, and even so our two communities have a lot in common.
Larry -- sounded like that package was in EPEL. You should still file an issue in bugzilla.redhat.com. The patch to fix the issue appeared to be small, so I would expect that the maintainer would be completely willing to backport the fix.
Ray
On Thursday, February 10, 2011 06:42:48 am Kai Schaetzl wrote:
Larry, could you please stop spamming this list with problems you see on the SL list? Thanks. This package isn't even part of CentOS.
While google perftools is not a part of either SL or CentOS, it *is* in EPEL, and CentOS users can be users of EPEL; thus it's on-topic for this list, unless it needs to be kept on an EPEL list.
I personally would rather the quick report show up here than to have to subscribe to yet another mailing list.
While google perftools is not a part of either SL or CentOS, it *is* in EPEL, and CentOS users can be users of EPEL
Then it's on-topic on the EPEL list, not here. e.g. ask there for an updated version of the package.
This wasn't the first instance. This guy has recently started a habit of copying mails (that are not his own it seems) that trip him off right to this list. That is bad practice. I do not want to get more of this.
Kai
On Thu, Feb 10, 2011 at 11:31 AM, Kai Schaetzl maillists@conactive.com wrote:
While google perftools is not a part of either SL or CentOS, it *is* in EPEL, and CentOS users can be users of EPEL
Then it's on-topic on the EPEL list, not here. e.g. ask there for an updated version of the package.
This wasn't the first instance. This guy has recently started a habit of copying mails (that are not his own it seems) that trip him off right to this list. That is bad practice. I do not want to get more of this.
My effort was to understand the conditions under which CentOS and/or SL would ever go to current edition for a particular component (e.g, BIND) and I think I understand now and can resign from the list with all due apologies to list members.
kind regards/ldv
On Thu, Feb 10, 2011 at 11:53:52AM -0600, Larry Vaden wrote:
On Thu, Feb 10, 2011 at 11:31 AM, Kai Schaetzl maillists@conactive.com wrote:
While google perftools is not a part of either SL or CentOS, it *is* in EPEL, and CentOS users can be users of EPEL
Then it's on-topic on the EPEL list, not here. e.g. ask there for an updated version of the package.
This wasn't the first instance. This guy has recently started a habit of copying mails (that are not his own it seems) that trip him off right to this list. That is bad practice. I do not want to get more of this.
My effort was to understand the conditions under which CentOS and/or SL would ever go to current edition for a particular component (e.g, BIND) and I think I understand now and can resign from the list with all due apologies to list members.
kind regards/ldv
Kai's opinions are not shared by many of us. You're welcome back any time.
Thanks, Ray
-
Johnny Hughes -
Kai Schaetzl -
Keith Keller -
Lamar Owen -
Larry Vaden -
Ned Slider -
Ray Van Dolson