Hi, I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules. Thanks, David Hrbac
On Fri, 2006-08-18 at 15:39 +0200, David Hrbáč wrote:
Hi, I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules. Thanks, David Hrbac
Nope ... we build what they provide ... including bugs/
Johnny Hughes napsal(a):
Nope ... we build what they provide ... including bugs/
Hmm, I'm asking because I have developed yumfirst plugin for Karanbir and it depends on a function, which is not implemented in centos yum. Karanbir has been talking about backporting. So are we going to use backports or not? To backport or not to backport, that's the question. :o)
I guess better way is to provide centosplus iptables-devel package. David Hrbac
David Hrbáč wrote:
Johnny Hughes napsal(a):
Nope ... we build what they provide ... including bugs/
Hmm, I'm asking because I have developed yumfirst plugin for Karanbir and it depends on a function, which is not implemented in centos yum. Karanbir has been talking about backporting. So are we going to use backports or not? To backport or not to backport, that's the question. :o)
But yum isn't taken from upstream, as they still use up2date, so making changes to yum doesn't really contradict what Johnny said up there.
I guess better way is to provide centosplus iptables-devel package.
That probably would be the better way to do it, yes.
Ralph
On Mon, 2006-08-21 at 11:32 +0200, Ralph Angenendt wrote:
David Hrbáč wrote:
Johnny Hughes napsal(a):
Nope ... we build what they provide ... including bugs/
Hmm, I'm asking because I have developed yumfirst plugin for Karanbir and it depends on a function, which is not implemented in centos yum. Karanbir has been talking about backporting. So are we going to use backports or not? To backport or not to backport, that's the question. :o)
But yum isn't taken from upstream, as they still use up2date, so making changes to yum doesn't really contradict what Johnny said up there.
Exactly ... we added yum to CentOS, and it is really the lone "functional" difference between CentOS and upstream. Since we added yum, we can do things to it that we _WILL_NEVER_ do to packages that are included in the upstream product. (like backport functionality, etc.)
I guess better way is to provide centosplus iptables-devel package.
That probably would be the better way to do it, yes.
If we need iptables-devel, then centosplus is indeed the mechanism to make that happen.
Ralph
Thanks, Johnny Hughes
Johnny Hughes wrote:
If we need iptables-devel, then centosplus is indeed the mechanism to make that happen.
I made a bug report and attached a patch for the spec file: http://bugs.centos.org/view.php?id=1454
Greg
On Fri, Aug 18, 2006 at 12:46:38PM -0500, Johnny Hughes wrote:
On Fri, 2006-08-18 at 15:39 +0200, David Hrbáč wrote:
Hi, I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules. Thanks, David Hrbac
Nope ... we build what they provide ... including bugs/
It's not a BUG! You are servind missing devel packages too. So your strong oposition should be rethinked.
I wonder - you have rules and exceptions. Why do you simply do not put differencies ro the RELEASE-NOTES and join CentOS/RPMS and addons? Separate dir is worthless because you have yum and i586 kernels in CentOS/RPMS already. So this "rule" isn't working from the start already.
I suggest distro and updates only.
Then think about Extras, Plus and Contrib. This is really too complicated.
Milan Keršláger wrote:
I wonder - you have rules and exceptions. Why do you simply do not put differencies ro the RELEASE-NOTES and join CentOS/RPMS and addons? Separate dir is worthless because you have yum and i586 kernels in CentOS/RPMS already. So this "rule" isn't working from the start already.
yum is there, because the architecture behind up2date (vulgo RHN) just isn't there, as it is *not* free software. The i586 kernel cannot go into a separate repository, as that won't be usable at install time -- yes, that is a change regarding to the stuff upstream delivers.
I suggest distro and updates only.
It would be against the CentOS goals - look at www.centos.org.
Then think about Extras, Plus and Contrib. This is really too complicated.
Stuff which *really* differs from upstream -- meaning that it *overwrites* stuff which comes from upstream -- has to go to centosplus, if at all.
Ralph
On Mon, 2006-08-21 at 14:12 +0200, Ralph Angenendt wrote:
Milan Keršláger wrote:
I wonder - you have rules and exceptions. Why do you simply do not put differencies ro the RELEASE-NOTES and join CentOS/RPMS and addons? Separate dir is worthless because you have yum and i586 kernels in CentOS/RPMS already. So this "rule" isn't working from the start already.
yum is there, because the architecture behind up2date (vulgo RHN) just isn't there, as it is *not* free software. The i586 kernel cannot go into a separate repository, as that won't be usable at install time -- yes, that is a change regarding to the stuff upstream delivers.
The i586 kernel was/is extra support ... it does not affect the i686 kernel. As Ralph pointed out, this is an exception to allow the i586 kernel to be used at start time.
I suggest distro and updates only.
It would be against the CentOS goals - look at www.centos.org.
Then think about Extras, Plus and Contrib. This is really too complicated.
It is not complicated ...
Extras - Items that add functionality and are not in upstream. This concept is quite popular and was added by Fedora as well in Fedora Extras.
CentOSPlus - Items that are upgrades to actual CentOS content. This repo is so that people who want max compatibility can disable this repo.
Contrib - we don't have any in CentOS-4 ... and probably will never have any (so this one is pretty much already dead).
Stuff which *really* differs from upstream -- meaning that it *overwrites* stuff which comes from upstream -- has to go to centosplus, if at all.
We have more than a million users and most want upstream compatibility and some want upgraded packages. Having Extras, CentOSPlus and Base/updates allows us to do both.
I am not going to fight with people about how we do this ... we have already made the decisions. We will continue doing things the way we have for the last 2 years. It has made us 'THE' premiere community enterprise linux distribution in the world ... and I see no reason to change the formula that got us here.
Thanks, Johnny Hughes
On Mon, Aug 21, 2006 at 07:29:33AM -0500, Johnny Hughes wrote:
Stuff which *really* differs from upstream -- meaning that it *overwrites* stuff which comes from upstream -- has to go to centosplus, if at all.
We have more than a million users and most want upstream compatibility and some want upgraded packages. Having Extras, CentOSPlus and Base/updates allows us to do both.
What I'm trying to point out that you are talking about rules. But that rules has exceptions already. Few devel packages are *NOT* changing functionality so your argument are simply not OK.
Your distributing system is overcomplicated and could be more simple.
Your rules has exceptions already so remove already broken rules with exceptions to change to more simple model with no broken rules (write list of this devel packages to RELEASE_NOTES for example).
What is wrong - you are building kernel with broken compiler even Red Hat does not. Even there is fixed compiler already in place and is usable with not breaking GPL rules.
This is the case where you are breaking your own rules even forcing "rules" on other things.
Thing about it. This is _really_ inconsistecy and you have to fix it - or stop talking about rules (and goals you broke already).
I am not going to fight with people about how we do this ... we have already made the decisions. We will continue doing things the way we have for the last 2 years. It has made us 'THE' premiere community enterprise linux distribution in the world ... and I see no reason to change the formula that got us here.
Thanks, Johnny Hughes
Things are changing all the time. Red Hat changed their model many times and Linux (and Linus) too (I'm working with Linux since 1993).
There is no reason to sit on decisions that are not so optimal (read: stay on rules you are already ignoring and breaking).
Milan Keršláger wrote:
What is wrong - you are building kernel with broken compiler even Red Hat does not. Even there is fixed compiler already in place and is usable with not breaking GPL rules.
Oh come on. Not that again. That has all been explained in *detail* in http://bugs.centos.org/view.php?id=1402, where you couldn't explain either on where to obtain the gcc the kernel has been compiled with by the upstream vendor.
Furrfu,
Ralph
On Wed, Aug 23, 2006 at 01:06:36PM +0200, Ralph Angenendt wrote:
Milan Keršláger wrote:
What is wrong - you are building kernel with broken compiler even Red Hat does not. Even there is fixed compiler already in place and is usable with not breaking GPL rules.
Oh come on. Not that again. That has all been explained in *detail* in http://bugs.centos.org/view.php?id=1402, where you couldn't explain either on where to obtain the gcc the kernel has been compiled with by the upstream vendor.
The SRC packages are available from Beta channel from RHN. There is a person from your team who exacly know the version. So grab the SRC package and rebuild.
If you know GPL you know that this is completly safe.
Building broken kernel is WRONG. The kernel crashes and you know about it but do not build the kernel correctly. The kernel does not follow 'as close as possible' RHEL. This is wroong too as you may read in this thread.
So what are you doing guys? Rules that you are do not follow but talking about following the rules? This is very very sad.
If you know where the source is and you are unable to grab them, write to me - simple script is able to put them to any FTP site. I'm using CentOS and RHN too to give back to Red Hat at least a little.
On Wed, Aug 23, 2006 at 01:29:45PM +0200, Milan Ker?láger enlightened us:
Milan Ker?láger wrote:
What is wrong - you are building kernel with broken compiler even Red Hat does not. Even there is fixed compiler already in place and is usable with not breaking GPL rules.
Oh come on. Not that again. That has all been explained in *detail* in http://bugs.centos.org/view.php?id=1402, where you couldn't explain either on where to obtain the gcc the kernel has been compiled with by the upstream vendor.
The SRC packages are available from Beta channel from RHN. There is a person from your team who exacly know the version. So grab the SRC package and rebuild.
If you know GPL you know that this is completly safe.
Building broken kernel is WRONG. The kernel crashes and you know about it but do not build the kernel correctly. The kernel does not follow 'as close as possible' RHEL. This is wroong too as you may read in this thread.
And how can you prove that building the kernel with a BETA toolchain will not result in a broken kernel as well? Maybe it fixes your problem - if that's the case, feel free to get the BETA toolchain and rebuild for yourself. Johnny has stated that he will continue to use the STABLE, RELEASED toolchain. End of discussion.
So what are you doing guys? Rules that you are do not follow but talking about following the rules? This is very very sad.
What rule are you referring to? The goal is to make CentOS as *close* to binary compatible as possible, but there is also the goal to make CentOS self-hosting - something that RedHat thus far has not done.
If you know where the source is and you are unable to grab them, write to me - simple script is able to put them to any FTP site. I'm using CentOS and RHN too to give back to Red Hat at least a little.
As do many CentOS developers and users. Would you like a cookie?
Please end this discussion, it will fall on deaf ears until RedHat releases their toolchain as stable.
On Wed, Aug 23, 2006 at 07:35:21AM -0400, Matt Hyclak wrote:
Building broken kernel is WRONG. The kernel crashes and you know about it but do not build the kernel correctly. The kernel does not follow 'as close as possible' RHEL. This is wroong too as you may read in this thread.
And how can you prove that building the kernel with a BETA toolchain will not result in a broken kernel as well? Maybe it fixes your problem - if that's the case, feel free to get the BETA toolchain and rebuild for yourself. Johnny has stated that he will continue to use the STABLE, RELEASED toolchain. End of discussion.
Johny know better tahan people from kernel team from RH what compiler is better to use to build kernel. Probably. He is the God. Probably.
But still building broken kernel and do not follow your own rules - as you wrote here - to be as close as possible to RHN.
So why do you have a rules? To use the against other. Probably.
So what are you doing guys? Rules that you are do not follow but talking about following the rules? This is very very sad.
What rule are you referring to? The goal is to make CentOS as *close* to binary compatible as possible, but there is also the goal to make CentOS self-hosting - something that RedHat thus far has not done.
If you know where the source is and you are unable to grab them, write to me - simple script is able to put them to any FTP site. I'm using CentOS and RHN too to give back to Red Hat at least a little.
As do many CentOS developers and users. Would you like a cookie?
Please end this discussion, it will fall on deaf ears until RedHat releases their toolchain as stable.
The tool is stable to build kernel. See their kernel.
Hi Milan
well, I see your name since the day when whitebox was an starting project but I certainly remember you from the messages you wrote when John had problems tring to keep whitebox updated (and creating others WB arch) I am sure your intentions are the best, always to help peoples, to help a project to become a better project :-) http://beau.org/pipermail/whitebox-devel/2004-January/000721.html
I guess you want the same for the CentOS project but it is the way you chose to express your intentions, your help. you always make the others get angry with you!!! and then, all the good that your messages could be had, its gone. I am nobody, it looks that you had done a lot more things than me, so you have more credicts in the comunity that the ones that I could have, but all of this will not matter if you keep writing-talking the way you are doing
take the advice please, all of us will win :-) roger
--- Milan Ker¹láger milan.kerslager@pslib.cz wrote:
On Wed, Aug 23, 2006 at 07:35:21AM -0400, Matt Hyclak wrote:
Building broken kernel is WRONG. The kernel
crashes and you know about
it but do not build the kernel correctly. The
kernel does not follow 'as
close as possible' RHEL. This is wroong too as
you may read in this
thread.
And how can you prove that building the kernel
with a BETA toolchain will
not result in a broken kernel as well? Maybe it
fixes your problem - if
that's the case, feel free to get the BETA
toolchain and rebuild for
yourself. Johnny has stated that he will continue
to use the STABLE,
RELEASED toolchain. End of discussion.
Johny know better tahan people from kernel team from RH what compiler is better to use to build kernel. Probably. He is the God. Probably.
But still building broken kernel and do not follow your own rules - as you wrote here - to be as close as possible to RHN.
So why do you have a rules? To use the against other. Probably.
So what are you doing guys? Rules that you are
do not follow but talking
about following the rules? This is very very
sad.
What rule are you referring to? The goal is to
make CentOS as *close* to
binary compatible as possible, but there is also
the goal to make CentOS
self-hosting - something that RedHat thus far has
not done.
If you know where the source is and you are
unable to grab them, write
to me - simple script is able to put them to any
FTP site. I'm using
CentOS and RHN too to give back to Red Hat at
least a little.
As do many CentOS developers and users. Would you
like a cookie?
Please end this discussion, it will fall on deaf
ears until RedHat releases
their toolchain as stable.
The tool is stable to build kernel. See their kernel.
-- Milan Kerslager E-mail: milan.kerslager@pslib.cz WWW: http://www.pslib.cz/ke/ _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
__________________________________________ RedHat Certified Engineer ( RHCE ) Cisco Certified Network Associate ( CCNA )
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Milan Keršláger wrote:
Please end this discussion, it will fall on deaf ears until RedHat releases their toolchain as stable.
The tool is stable to build kernel. See their kernel.
Milan, actually - i did see their kernel and no their kernel was not built using the beta gcc either.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If you all know it so much better why don't you go ahead and build your own distro. Milan Keršláger schrieb:
On Wed, Aug 23, 2006 at 01:06:36PM +0200, Ralph Angenendt wrote:
Milan Keršláger wrote:
What is wrong - you are building kernel with broken compiler even Red Hat does not. Even there is fixed compiler already in place and is usable with not breaking GPL rules.
Oh come on. Not that again. That has all been explained in *detail* in http://bugs.centos.org/view.php?id=1402, where you couldn't explain either on where to obtain the gcc the kernel has been compiled with by the upstream vendor.
The SRC packages are available from Beta channel from RHN. There is a person from your team who exacly know the version. So grab the SRC package and rebuild.
If you know GPL you know that this is completly safe.
Building broken kernel is WRONG. The kernel crashes and you know about it but do not build the kernel correctly. The kernel does not follow 'as close as possible' RHEL. This is wroong too as you may read in this thread.
So what are you doing guys? Rules that you are do not follow but talking about following the rules? This is very very sad.
If you know where the source is and you are unable to grab them, write to me - simple script is able to put them to any FTP site. I'm using CentOS and RHN too to give back to Red Hat at least a little.
- -- financial.com AG Tel. +49 (0) 89 / 31 85 28 - 44 Maria-Probst-Str. 19 Fax. +49 (0) 89 / 31 85 28 - 28 D-80939 München http://www.financial.com/
Milan Keršláger wrote:
On Wed, Aug 23, 2006 at 01:06:36PM +0200, Ralph Angenendt wrote:
Oh come on. Not that again. That has all been explained in *detail* in http://bugs.centos.org/view.php?id=1402, where you couldn't explain either on where to obtain the gcc the kernel has been compiled with by the upstream vendor.
The SRC packages are available from Beta channel from RHN. There is a person from your team who exacly know the version. So grab the SRC package and rebuild.
Oh, you mean that beta channel where 3.4.6-3 was available, which wasn't the gcc version either upstream built their kernel rpm with (3.4.6-2)?
And now take that foot out of your mouth, it really makes you look funny.
Regards,
Ralph
On Wed, Aug 23, 2006 at 01:45:17PM +0200, Ralph Angenendt wrote:
Milan Keršláger wrote:
On Wed, Aug 23, 2006 at 01:06:36PM +0200, Ralph Angenendt wrote:
Oh come on. Not that again. That has all been explained in *detail* in http://bugs.centos.org/view.php?id=1402, where you couldn't explain either on where to obtain the gcc the kernel has been compiled with by the upstream vendor.
The SRC packages are available from Beta channel from RHN. There is a person from your team who exacly know the version. So grab the SRC package and rebuild.
Oh, you mean that beta channel where 3.4.6-3 was available, which wasn't the gcc version either upstream built their kernel rpm with (3.4.6-2)?
-3 has 4 bug more fixed. You never will have 3.4.6-2 even after release in U4. So where is the problem?
Do you want to build with compiler with 4 more bug fixed or with 5 or 6 more?
And now take that foot out of your mouth, it really makes you look funny.
And you too. Rules only for some people. Really funny.
I was asking to build non-crashing kernel only. Instead of fix I've got angry people trying to push me out. Really not funny end.
Milan Keršláger wrote:
On Wed, Aug 23, 2006 at 01:45:17PM +0200, Ralph Angenendt wrote:
Oh, you mean that beta channel where 3.4.6-3 was available, which wasn't the gcc version either upstream built their kernel rpm with (3.4.6-2)?
-3 has 4 bug more fixed. You never will have 3.4.6-2 even after release in U4. So where is the problem?
The problem is that the gcc version RedHat used to build the kernel never has been released.
Do you want to build with compiler with 4 more bug fixed or with 5 or 6 more?
No, normally with the compiler which is used by upstream (and wasn't available). How do you know that a new compiler doesn't introduce new bugs when building the kernel?
And now take that foot out of your mouth, it really makes you look funny.
And you too. Rules only for some people. Really funny.
I still haven't understood what you mean by "Rules only for some people". As already stated: CentOS *tries* to stay as close as possible to the upstream release. It looks like that isn't always possible (as in this case, where the build chain from upstream hadn't been released).
The only case I see where CentOS (base!) strays from upstream is the i586 kernel which can be used at installation time and the packaging of yum (as RHN isn't available).
I was asking to build non-crashing kernel only. Instead of fix I've got angry people trying to push me out. Really not funny end.
It might have been the way you asked. Calling people "unprofessional" and mark their doings as "PLAIN WRONG" really doesn't help. Claiming that they don't know "what is giving back" and suggesting that they do not have a subscription while "using all that from REDHAT" doesn't help either. Please reread your statements (and *HOW* you put them) in that bug report.
Ralph
On Wed, 2006-08-23 at 14:10 +0200, Ralph Angenendt wrote:
Milan Keršláger wrote:
I still haven't understood what you mean by "Rules only for some people". As already stated: CentOS *tries* to stay as close as possible to the upstream release. It looks like that isn't always possible (as in this case, where the build chain from upstream hadn't been released).
The only case I see where CentOS (base!) strays from upstream is the i586 kernel which can be used at installation time
And let me point out that the reason we did the i586 kernel were this:
1. It does not CHANGE the i686 (or any other kernel) compiled with the source code. The i586 kernel is added for those who need it, it doesn't affect users who don't use it at all.
and the packaging of yum (as RHN isn't available).
And the reason we did this:
We had to modify RHN ... as we could not use it. We had to provide some other system for updates. We choose yum and used that.
Making changes to the RH software to fix RH problems is another issue entirely.
Also, notice now that the beta channel is gone after the 4u4 release. All those files do not exist at RH anymore. The gcc they released happened to be 3.4.6-3 ... but it could have been 3.4.6-4 or something else in 4u4 (there was a different glibc, for example, than in the beta). So, you would have us produce a kernel with an RPM that was never officially released upstream ... one that might disappear when they release the update set, that doesn't appear on any RH ftp server?
How could that be called responsible or professional? If I did that, it would be (IMHO) very unprofessional.
CentOS has rules, and we follow them. We do not build anything on a build tree that is not released.
All updates are built on a centos build tree.
I was asking to build non-crashing kernel only. Instead of fix I've got angry people trying to push me out. Really not funny end.
It might have been the way you asked. Calling people "unprofessional" and mark their doings as "PLAIN WRONG" really doesn't help. Claiming that they don't know "what is giving back" and suggesting that they do not have a subscription while "using all that from REDHAT" doesn't help either. Please reread your statements (and *HOW* you put them) in that bug report.
That didn't help, no.
On Wed, Aug 23, 2006 at 08:48:01AM -0500, Johnny Hughes wrote:
Also, notice now that the beta channel is gone after the 4u4 release. All those files do not exist at RH anymore. The gcc they released happened to be 3.4.6-3 ... but it could have been 3.4.6-4 or something else in 4u4 (there was a different glibc, for example, than in the beta). So, you would have us produce a kernel with an RPM that was never officially released upstream ... one that might disappear when they release the update set, that doesn't appear on any RH ftp server?
What about
ftp.redhat.com:/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/gcc-3.4.6-3.src.rpm
Dated June 12th?
But on the other hand, the name calling has got to stop. Milan, Johnny is nothing but responsible and professional.
Matthew Miller wrote:
On Wed, Aug 23, 2006 at 08:48:01AM -0500, Johnny Hughes wrote:
Also, notice now that the beta channel is gone after the 4u4 release. All those files do not exist at RH anymore. The gcc they released happened to be 3.4.6-3 ... but it could have been 3.4.6-4 or something else in 4u4 (there was a different glibc, for example, than in the beta). So, you would have us produce a kernel with an RPM that was never officially released upstream ... one that might disappear when they release the update set, that doesn't appear on any RH ftp server?
What about
ftp.redhat.com:/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/gcc-3.4.6-3.src.rpm
Dated June 12th?
But released on Aug-10
https://rhn.redhat.com/errata/RHBA-2006-0509.html
On Wed, 2006-08-23 at 09:59 -0400, Matthew Miller wrote:
On Wed, Aug 23, 2006 at 08:48:01AM -0500, Johnny Hughes wrote:
Also, notice now that the beta channel is gone after the 4u4 release. All those files do not exist at RH anymore. The gcc they released happened to be 3.4.6-3 ... but it could have been 3.4.6-4 or something else in 4u4 (there was a different glibc, for example, than in the beta). So, you would have us produce a kernel with an RPM that was never officially released upstream ... one that might disappear when they release the update set, that doesn't appear on any RH ftp server?
What about
ftp.redhat.com:/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/gcc-3.4.6-3.src.rpm
Dated June 12th?
But on the other hand, the name calling has got to stop. Milan, Johnny is nothing but responsible and professional.
Matt ... we are using gcc-3.4.6-3 now ... as it is being released in CentOS-4.4 ... however at the time of the kernel release in question (more than a month BEFORE the RHEL 4u4 release), there was no idea what what binutils, glibc or gcc was going to be released. The new kernels are being built with the 4.4 toolchain, as is our standard practice.
But as an example, the stable glibc was glibc-2.3.4-2.19 in 4.3, glibc-2.3.4-2.22 was in the beta and they released glibc-2.3.4-2.25 with 4.4. If i built real items against glibc-2.3.4-2.22, who knows what issues it will introduce. Obviously glibc-2.3.4-2.22 is not stable, as they rolled in changes from the Beta test period to finally release glibc-2.3.4-2.25. glibc-2.3.4-2.22 is not anywhere to be found now on the RH site since the beta channel is erased ... and only glibc-2.3.4-2.19 and glibc-2.3.4-2.25 are available from RHN. Having a glibc-2.3.4-2.22 or items built against it would not be at all like upstream.
We will only build with released tool chains .. and whenever possible, we will build against the same tool chain as upstream. Some times that is not possible. In the cases where it is not possible, we will build against the stable CentOS tree.
We won't build against items in a beta status.
Thanks, Johnny Hughes
On Wed, Aug 23, 2006 at 12:34:40PM -0500, Johnny Hughes wrote:
Matt ... we are using gcc-3.4.6-3 now ... as it is being released in CentOS-4.4 ... however at the time of the kernel release in question (more than a month BEFORE the RHEL 4u4 release), there was no idea what what binutils, glibc or gcc was going to be released. The new kernels are being built with the 4.4 toolchain, as is our standard practice.
So, the RHSA-2006:0617-15-based kernel from yesterday is built with the new gcc, and the whole conversation is pretty frickin' moot.
We will only build with released tool chains .. and whenever possible, we will build against the same tool chain as upstream. Some times that is not possible. In the cases where it is not possible, we will build against the stable CentOS tree.
We won't build against items in a beta status.
This is clearly a good general policy, but I do think it might be reasonable to consider exceptions in some particular cases where the problem fixed is severe *and* where changes from a known-stable version are clearly minor. That may or may not fit this case, and given the above, I don't want to waste any more of your time discussiong whether it does. :)
On Wed, Aug 23, 2006 at 01:45:17PM +0200, Ralph Angenendt wrote:
Oh, you mean that beta channel where 3.4.6-3 was available, which wasn't the gcc version either upstream built their kernel rpm with (3.4.6-2)?
What are the changes between the -2 release and the -3 release? Sometimes it's as simple as "fixed spelling error in description" or "added tiny little patch which is clearly not going to cause trouble" -- but other times it's "updated to new snapshot, altering about 100,000 lines of code". Which is it in this case?
If it's nearer the former, Milan's request that the newer compiler be used because it fixes a known and serious problem seems quite reasonable.
Policies are good, but if the changes are small, doesn't it seem like using 3.4.6-3 is more in the spirit of the rules than the literal interpretation? Clearly the problem is the way Red Hat is building things in a non-self-hosted way -- but it's hard to do anything about that.
Matthew Miller wrote:
On Wed, Aug 23, 2006 at 01:45:17PM +0200, Ralph Angenendt wrote:
Oh, you mean that beta channel where 3.4.6-3 was available, which wasn't the gcc version either upstream built their kernel rpm with (3.4.6-2)?
What are the changes between the -2 release and the -3 release? Sometimes it's as simple as "fixed spelling error in description" or "added tiny little patch which is clearly not going to cause trouble" -- but other times it's "updated to new snapshot, altering about 100,000 lines of code". Which is it in this case?
If it's nearer the former, Milan's request that the newer compiler be used because it fixes a known and serious problem seems quite reasonable.
Policies are good, but if the changes are small, doesn't it seem like using 3.4.6-3 is more in the spirit of the rules than the literal interpretation? Clearly the problem is the way Red Hat is building things in a non-self-hosted way -- but it's hard to do anything about that.
here is the changelog:
* Tue May 23 2006 Jakub Jelinek jakub@redhat.com 3.4.6-3
- -fvar-tracking fixes needed for SystemTap (BZ#2438) - add workaround for buggy programs that link in their own unwinder and reexport it (#192814) - make all globals in libgcc_eh.a hidden, so that newly (incorrectly) linked programs can't reexport the unwinder - support -fno-frame-base-loclist option to prevent use of DWARF2 location lists in DW_AT_frame_base value (#191041)
Matt, the point is - those changes might have implications down the road - I dont have the gcc knowledge to work out exactly what those issues might be - and some of them do seem to have a direct impact on kernel space stuff ?
you say that Policy is good, i agree - and its this form of policy that a userbase can take for granted - that helps sustain CentOS!
One point that we seem to be missing is that when RHAT are building something in a way that cant be reproduced, its them who are breaking with the spirit of things - and we really should push them to not do that.
Also, would someone like to donate some RHN subscriptions to the CentOS project so that we might be able to keep a closer eye on whats going on with RHat side of things from the inside ? Would RHat be ok with that knowledge coming our way ? Does that open us upto any legal issues ?
Karanbir Singh wrote:
Also, would someone like to donate some RHN subscriptions to the CentOS project so that we might be able to keep a closer eye on whats going on with RHat side of things from the inside? Would RHat be ok with that knowledge coming our way ? Does that open us upto any legal issues ?
Once you figure out if it opens up legal issues or not, and if it doesnt, I will donate an RHN subscription.
Trevor Benson A1 Networks
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Aug 23, 2006 at 05:06:11PM +0100, Karanbir Singh wrote:
One point that we seem to be missing is that when RHAT are building something in a way that cant be reproduced, its them who are breaking with the spirit of things - and we really should push them to not do that.
Totally agreed.
On Wed, 23 Aug 2006, Karanbir Singh wrote:
Matthew Miller wrote:
it's "updated to new snapshot, altering about 100,000 lines of code". Which is it in this case?
If it's nearer the former, Milan's request that the newer compiler be used because it fixes a known and serious problem seems quite reasonable.
here is the changelog:
Let's see what the changes were .... I think it is undecidable as to the matter of 'reasonableness', in doing a postmortem
- Tue May 23 2006 Jakub Jelinek jakub@redhat.com 3.4.6-3
- -fvar-tracking fixes needed for SystemTap (BZ#2438)
- not clear which BZ is referred to, but it is not the Red Hat one; not in the Cygwin one (http://www.cygwin.com/bugzilla/), not in the Gnu one (http://gcc.gnu.org/bugzilla/)
- add workaround for buggy programs that link in their own unwinder
and reexport it (#192814)
- probably the Red Hat bugzilla, but bug 192814 is blocked from review by 'mere mortals' in the general public -- This implies a security related matter, which are definitionally important changes
- make all globals in libgcc_eh.a hidden, so that newly (incorrectly)
linked programs can't reexport the unwinder
- no bugzilla reference as to why and what 'incorrectly' linked programs are exporting the unwinder, nor why that is dangerous (rather than just wrong -- if only wrong, the problem is in the sources of the misbehaving program, and would seem to be more properly fixed there, unless there ARE security overtones). Is the kernel one of the offenders? -- One cannot say.
- support -fno-frame-base-loclist option to prevent use of
DWARF2 location lists in DW_AT_frame_base value (#191041)
- probably the Red Hat bugzilla, but bug 191041 is also blocked from review by 'mere mortals' in the general public
One has to suspect that there may be dangerous behaviours being addressed, from the obscure Changelog backreferences.
Matt, the point is - those changes might have implications down the road - I dont have the gcc knowledge to work out exactly what those issues might be - and some of them do seem to have a direct impact on kernel space stuff ?
and as we see in this case, and after inspection from the Changelog, and the outlinks it references, that NONE of the underlying reasoning nor cause for the changes for that GCC variant may be inspected, without further study than what we have or can easily access.
It would take further study to reach decideability as to 'reasonable', comparing between patched source trees of the GCC versions in question to even see what has changed. As I recall, gcc builds part of its macro expansion set on the fly during the compile, and so one has to snapshot it from time to time as well, to see what is changing.
Matt later said:
So, the RHSA-2006:0617-15-based kernel from yesterday is built with the new gcc, and the whole conversation is pretty frickin' moot.
I want also to point out that just because a person produces a binary variant with a header containing the string 'X', nothing guarantees that the compiler version you THINK produced that X is truly one that a later appearing X variant in fact produced -- one can trivially spoof such values; buildsystems slipstream changes all the time
... we _hope_ is is the same, we hope it is moot, but nothing at all says that the binary update from June was build with the similarly version numbered sources released in August. It need not even be intentional that identical number versions may hold varying content. Personal buildtrees outside of a central buildsystem are the rule, not the exception.
From CentOS' point of view, the most responsible way to
proceed, is to have a reproducable course documented, and to follow it. _If_ one had a formal confirmaton on a particular kernel's buildsystem environment (which will not be forthcoming), or access to the specific GCC sources known to have been used for the specific binary kernel variant being compared to, other options might exist. The PNAELV did not choose to timely make available the asserted gcc variant in question.
A better approach, the CentOS approach: build using a toolchain, based on the freely reproducable sources actually released, and not expose that million user base to unknown risks with 'likely' used variants without formal provenance.
A downstream user/admin wishing to do so, and to be daring, may do so, as they see fit, but in turn only harm themself, if the decision turns out to be ill advised.
- Russ Herrold
On Thu, Aug 24, 2006 at 05:02:11PM -0400, R P Herrold wrote:
- Tue May 23 2006 Jakub Jelinek jakub@redhat.com 3.4.6-3
- -fvar-tracking fixes needed for SystemTap (BZ#2438)
- not clear which BZ is referred to, but it is not the
Red Hat one; not in the Cygwin one (http://www.cygwin.com/bugzilla/), not in the Gnu one (http://gcc.gnu.org/bugzilla/)
Red Hat's secret other bugzilla. http://sources.redhat.com/bugzilla --> http://sourceware.org/bugzilla/show_bug.cgi?id=2438.
- add workaround for buggy programs that link in their own unwinder
and reexport it (#192814)
- probably the Red Hat bugzilla, but bug 192814 is
blocked from review by 'mere mortals' in the general public -- This implies a security related matter, which are definitionally important changes
Sadly, it seems to often imply "involves big-name customer, or customer who thinks they are big name". But yeah, not being able to review the bug is a bad thing.
[...]
and as we see in this case, and after inspection from the Changelog, and the outlinks it references, that NONE of the underlying reasoning nor cause for the changes for that GCC variant may be inspected, without further study than what we have or can easily access.
That does seem to be true in this case.
On Mon, 21 Aug 2006, Milan Ker?láger wrote:
On Fri, Aug 18, 2006 at 12:46:38PM -0500, Johnny Hughes wrote:
On Fri, 2006-08-18 at 15:39 +0200, David Hrbá? wrote:
Hi, I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules. Thanks, David Hrbac
Nope ... we build what they provide ... including bugs/
It's not a BUG! You are servind missing devel packages too. So your strong oposition should be rethinked.
I wonder - you have rules and exceptions. Why do you simply do not put differencies ro the RELEASE-NOTES and join CentOS/RPMS and addons? Separate dir is worthless because you have yum and i586 kernels in CentOS/RPMS already. So this "rule" isn't working from the start already.
Not sure if my opinion matters on this, but I actually see it as a service to Red Hat to not fix bugs (or other problems) that are in upstream packages.
This forces users of CentOS to report those problem upstream and makes sure CentOS is following the same quality process that Red Hat is going through. If we catch up with Red Hat and fix (what we think is) broken behaviour we might be shooting in our own foot if Red Hat eventually fixes it in a different way that makes both solution incompatible.
Of course one can say that you should do an assessment of that risk, but some things are impossible to prevent. Especially if long-term strategies of Red Hat are involved. We are no better than Red Hat engineers and an unresolved problem is either because they are not aware of it, do not see it as an important problem or the fix might be worse to the majority (or even minority) of the customers.
And if you really rely on a bugfix, you should buy a Red Hat entitlement and make that money pay off. The process is slow and painful and sometimes does not seem worthwhile, but it has its purpose.
And the fact that CentOS offers so much more, does not make a difference to the fact that people (can) know exactly what they are getting in to. As soon as we break those policies, certainty is gone for everybody excepts the people that think they know what they're doing.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
David Hrbác wrote:
I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules.
I'm cc'd on that bug. Someone from Redhat added this "flag" that is invisible on the bug report, but I got this email hinting it may be done for 4.5...
-----Original Message----- From: bugzilla@redhat.com [mailto:bugzilla@redhat.com] Sent: Wednesday, August 02, 2006 1:08 AM To: gregswallow@skynetonline.ca Subject: [Bug 178417] missing iportant header files form the devel package
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: missing iportant header files form the devel package
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178417
laroche@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |rhel-4.5?
On Fri, 18 Aug 2006, Greg Swallow - SkyNet wrote:
David Hrbác wrote:
I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules.
I'm cc'd on that bug. Someone from Redhat added this "flag" that is invisible on the bug report, but I got this email hinting it may be done for 4.5...
-----Original Message----- From: bugzilla@redhat.com [mailto:bugzilla@redhat.com] Sent: Wednesday, August 02, 2006 1:08 AM To: gregswallow@skynetonline.ca Subject: [Bug 178417] missing iportant header files form the devel package
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: missing iportant header files form the devel package
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178417
laroche@redhat.com changed:
What |Removed |Added
Flag| |rhel-4.5?
So does one expect with the new timelines that RedHat has announced that we will not see RHEL 4.5 for about 6 months?
-Connie Sieh
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Fri, 2006-08-18 at 12:56 -0500, Connie Sieh wrote:
On Fri, 18 Aug 2006, Greg Swallow - SkyNet wrote:
David Hrbác wrote:
I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules.
I'm cc'd on that bug. Someone from Redhat added this "flag" that is invisible on the bug report, but I got this email hinting it may be done for 4.5...
-----Original Message----- From: bugzilla@redhat.com [mailto:bugzilla@redhat.com] Sent: Wednesday, August 02, 2006 1:08 AM To: gregswallow@skynetonline.ca Subject: [Bug 178417] missing iportant header files form the devel package
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: missing iportant header files form the devel package
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178417
laroche@redhat.com changed:
What |Removed |Added
Flag| |rhel-4.5?So does one expect with the new timelines that RedHat has announced that we will not see RHEL 4.5 for about 6 months?
-Connie Sieh
I'm not sure if those apply starting now or after the 4.5 release when they start the 4.5.0 then 4.5.1 & 4.6.0 then 4.5.2 & 4.6.1 & 4.7.0 ... etc.
Greg Swallow - SkyNet napsal(a):
David Hrbác wrote:
I'd like to ask if iptables-devel package is going to be patched by CentOS team to include all header files. Upstream provider still seems to ignore this bug, even it was fixed in FC5. We need to fix it to simplify automatic build of iptables/kernel modules.
I'm cc'd on that bug. Someone from Redhat added this "flag" that is invisible on the bug report, but I got this email hinting it may be done for 4.5...
Well, today I have received email from upstream Bugzilla. RH seems to really ignore this bug. The bug is closed finally. :o( David
-------- Původní zpráva -------- Předmět: [Bug 178417] missing iportant header files form the devel package Datum: Tue, 5 Sep 2006 16:01:13 -0400 Od: bugzilla@redhat.com Komu: david.hrbac@vsb.cz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: missing iportant header files form the devel package
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178417
pm-rhel@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX
-
Christoph Maser -
Connie Sieh -
Dag Wieers -
David Hrbáč -
Greg Swallow - SkyNet -
Johnny Hughes -
Karanbir Singh -
Matt Hyclak -
Matthew Miller -
Milan Keršláger -
R P Herrold -
Ralph Angenendt -
Roger Pe�a Escobio -
Trevor Benson