Hello everyone:
* DNS does not have a "refresh rate". In DNS, the person running the domain determines what the "refresh rate" (it's called TTL in DNS) for their records is; for example, Google has a TTL of "once per hour" and my domains (maradns.org, etc.) have a TTL of one day.
* As mentioned before, Scientific Linux 6.0 is out. What hasn't been mentioned here is that while SL 5.6 hasn't come out, 5.6 security updates are being backported to SL 5.5. Ditto with SL 4 (no 4.9 but security patches look current)
Take care everyone,
- Sam
On 03/22/2011 08:37 AM, Sam Trenholme wrote:
Hello everyone:
- DNS does not have a "refresh rate". In DNS, the person running the
domain determines what the "refresh rate" (it's called TTL in DNS) for their records is; for example, Google has a TTL of "once per hour" and my domains (maradns.org, etc.) have a TTL of one day.
- As mentioned before, Scientific Linux 6.0 is out. What hasn't been
mentioned here is that while SL 5.6 hasn't come out, 5.6 security updates are being backported to SL 5.5. Ditto with SL 4 (no 4.9 but security patches look current)
And we try very hard not to release things until they pass our QA testing.
We are still finding and correcting issues with the 5.6 things that we have built (things not properly linking when compared to upstream, etc).
One we release something, we can't take it back. If we release a package that is linked incorrectly, it gets out to millions of machines.
If it is broken, it does not matter if it is fast.
Everyone will need to make their own decisions on what they want.
========================================================================================= For example, do you want things like this or not:
Verifying certmonger-0.30-4.el5.x86_64.rpm against certmonger-0.30-4.el5.x86_64.rpm certmonger-0.30-4.el5.x86_64.rpm FAIL ref:656933 +/-:-10856 %:1 ------------------------- Verifying libtevent-0.9.8-10.el5.x86_64.rpm against libtevent-0.9.8-10.el5.x86_64.rpm libtevent-0.9.8-10.el5.x86_64.rpm FAIL ref:36184 +/-:-192 %:0 -------------------------
And then looking at the reason for the fails:
Differing package requirements certmonger-0.30-4.el5.x86_64.rpm.out: --- work/SL-req 2011-03-23 02:53:25.000000000 -0500 +++ work/RHEL-req 2011-03-23 02:53:25.000000000 -0500 @@ -38,7 +38,7 @@ libpthread.so.0(GLIBC_2.2.5)(64bit) libsmime3.so()(64bit) libssl3.so()(64bit) -libtalloc.so.1()(64bit) +libtalloc.so.2()(64bit) libtevent.so.0()(64bit) libxmlrpc.so.3()(64bit) libxmlrpc_client.so.3()(64bit)
Differing package requirements libtevent-0.9.8-10.el5.x86_64.rpm.out: --- work/SL-req 2011-03-23 02:53:26.000000000 -0500 +++ work/RHEL-req 2011-03-23 02:53:26.000000000 -0500 @@ -5,7 +5,7 @@ libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) -libtalloc.so.1()(64bit) +libtalloc.so.2()(64bit) libtevent.so.0()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 =========================================================================================
What does that mean ... it means that those 2 packages were built against the wrong version of libtalloc. Those packages use the older library for libtalloc, not the newer one. Will that package work like the upstream one ... probably not. I do not make it a practice of checking Scientific Linux links to upstream. I only check ones we specifically have issues with, to see if anyone else gets it to build correctly. We initially had this same issue in our 5.6 build and for us it is now corrected because of our QA process. It is still in the SL 50x Rolling.
It takes hours to analyze all the packages in a build ... I do not have hours to spend on doing it for SL ... but here is another error that I found in the SL tree when figuring out build issues in the CentOS 5.6 tree:
Differing package requirements kdbg-2.0.2-1.2.1.i386.rpm.out: --- work/RHEL-req 2011-03-23 08:43:18.000000000 +0000 +++ work/SL-req 2011-03-23 08:43:18.000000000 +0000 @@ -13,7 +13,6 @@ libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.4) libdl.so.2 -libfam.so.0 libgcc_s.so.1 libidn.so.11 libkdecore.so.4
This is not in any way trying to slight the SL distro, it is a very good product (as is CentOS). These are just a couple of examples of things we have fixed in our 5.6 build in the last week that are also in SL that I know about because I specifically checked SL when we found the issue in CentOS.
On Wed, Mar 23, 2011 at 5:42 AM, Johnny Hughes johnny@centos.org wrote:
And then looking at the reason for the fails:
Differing package requirements certmonger-0.30-4.el5.x86_64.rpm.out: --- work/SL-req 2011-03-23 02:53:25.000000000 -0500 +++ work/RHEL-req 2011-03-23 02:53:25.000000000 -0500 @@ -38,7 +38,7 @@ libpthread.so.0(GLIBC_2.2.5)(64bit) libsmime3.so()(64bit) libssl3.so()(64bit) -libtalloc.so.1()(64bit) +libtalloc.so.2()(64bit) libtevent.so.0()(64bit) libxmlrpc.so.3()(64bit) libxmlrpc_client.so.3()(64bit)
Differing package requirements libtevent-0.9.8-10.el5.x86_64.rpm.out: --- work/SL-req 2011-03-23 02:53:26.000000000 -0500 +++ work/RHEL-req 2011-03-23 02:53:26.000000000 -0500 @@ -5,7 +5,7 @@ libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) -libtalloc.so.1()(64bit) +libtalloc.so.2()(64bit) libtevent.so.0()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 =========================================================================================
What does that mean ... it means that those 2 packages were built against the wrong version of libtalloc. Those packages use the older
Ouch. Johnny, I'd really like to replicate this error, but I just don't have the visibility into your build configurations. Saying "it's easy to do yourself" doesn't work, because there are subtleties in the configurations, such as whether "mock" configurations use the older, CentOS 5.5 release or the existing set up updated CentOS pre-release 5.6 components, that can generate precisely this sort of issue.
On 03/23/2011 07:53 AM, Nico Kadel-Garcia wrote:
On Wed, Mar 23, 2011 at 5:42 AM, Johnny Hughes johnny@centos.org wrote:
And then looking at the reason for the fails:
Differing package requirements certmonger-0.30-4.el5.x86_64.rpm.out: --- work/SL-req 2011-03-23 02:53:25.000000000 -0500 +++ work/RHEL-req 2011-03-23 02:53:25.000000000 -0500 @@ -38,7 +38,7 @@ libpthread.so.0(GLIBC_2.2.5)(64bit) libsmime3.so()(64bit) libssl3.so()(64bit) -libtalloc.so.1()(64bit) +libtalloc.so.2()(64bit) libtevent.so.0()(64bit) libxmlrpc.so.3()(64bit) libxmlrpc_client.so.3()(64bit)
Differing package requirements libtevent-0.9.8-10.el5.x86_64.rpm.out: --- work/SL-req 2011-03-23 02:53:26.000000000 -0500 +++ work/RHEL-req 2011-03-23 02:53:26.000000000 -0500 @@ -5,7 +5,7 @@ libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) -libtalloc.so.1()(64bit) +libtalloc.so.2()(64bit) libtevent.so.0()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 =========================================================================================
What does that mean ... it means that those 2 packages were built against the wrong version of libtalloc. Those packages use the older
Ouch. Johnny, I'd really like to replicate this error, but I just don't have the visibility into your build configurations. Saying "it's easy to do yourself" doesn't work, because there are subtleties in the configurations, such as whether "mock" configurations use the older, CentOS 5.5 release or the existing set up updated CentOS pre-release 5.6 components, that can generate precisely this sort of issue.
CentOS has it lined correctly ... it is SL that has it linked incorrectly.
I have been building CentOS for 8 years Nico .. I do NOT need your help to build it. I try to tell you how I build it, but you tell me I don't know what I am doing.
If you want to use CentOS then use it. Stop filling up the mailing lists with your trolling diatribe.
Get this straight ... I do not need you to "TEACH" me anything about CentOS, the process used to build it, the process used to distribute it, how it originated, where it is moving to, or anything else about it.
On Wed, Mar 23, 2011 at 9:12 AM, Johnny Hughes johnny@centos.org wrote:
On 03/23/2011 07:53 AM, Nico Kadel-Garcia wrote:
Ouch. Johnny, I'd really like to replicate this error, but I just don't have the visibility into your build configurations. Saying "it's easy to do yourself" doesn't work, because there are subtleties in the configurations, such as whether "mock" configurations use the older, CentOS 5.5 release or the existing set up updated CentOS pre-release 5.6 components, that can generate precisely this sort of issue.
CentOS has it lined correctly ... it is SL that has it linked incorrectly.
Understood. I'd like to replicate or examine the error. "Building it yourself", without that access to your unique build environment or a way to gracefully replicate it, represents dozens or hundreds of man-hours for each contributor who'd like to help. That's a little hard to do right now.
I have been building CentOS for 8 years Nico .. I do NOT need your help to build it. I try to tell you how I build it, but you tell me I don't know what I am doing.
Ohh. Then I guess all the "requests for help" in the last few months were looking for something else?
Johnny, I'm trying to help. I'm trying to get the ducks lined up to be *able* to help, and not spend my time waddling around a little pond.
If you want to use CentOS then use it. Stop filling up the mailing lists with your trolling diatribe.
Get this straight ... I do not need you to "TEACH" me anything about CentOS, the process used to build it, the process used to distribute it, how it originated, where it is moving to, or anything else about it.
Fine. Then show *US* how you're doing it. Publish the /etc/mock/ files you use, and provide some visibibility to the bootstrapping you're allegedly using for CentOS 6, and we'd love to help on this and future releases. The build components in the "build" repository, for example, are pretty old and clearly out of date. Point us to the current versions, please!
I can't make you learn about source control, you apparently get by without it. I'd be glad to help the other devs use it to make that build structure available. You can actually use Dag Weier's work over at RPMforge as a good example of it, and it does integrate well with mock.
On Wednesday, March 23, 2011 09:56:34 am Nico Kadel-Garcia wrote:
Understood. I'd like to replicate or examine the error. "Building it yourself", without that access to your unique build environment or a way to gracefully replicate it, represents dozens or hundreds of man-hours for each contributor who'd like to help. That's a little hard to do right now.
He's given out his build system requirements. Last I saw it was 'C5.5 fully updated' (which I take to be 'with all the current public updates') .... but, no, you can grep the archives for yourself for the mock version he said. I read that message; it gave enough information to get started.
And to replicate the error you have to do the work; there is no shortcut, and if you don't have time to put that many hours into it (like me; I don't have that kind of time right now either) then you can't replicate it. Besides, it's already fixed in the C5 tree, so replication is not really useful at the moment, at least not to CentOS, I would think.
Ohh. Then I guess all the "requests for help" in the last few months were looking for something else?
Yes, they were. None of the requests for help I saw included 'help us build or re-tool the buildsystem' as part of the request. Requests were made for help with specific tasks; building or source control for changed specs was not found in any of those requests. If you're going to help someone, you have to help that someone in the areas that that someone wants help; if you go to the auto mechanic and ask for an oil change it doesn't help for that mechanic to go ahead and do an engine overhaul just because the mechanic would rather help by doing an engine overhaul, even if an oil change *is* a side-effect of an engine overhaul.
Fine. Then show *US* how you're doing it. Publish the /etc/mock/ files you use,
He has done this. More than once, now, in the CentOS-devel list. Go read the archives; it's all there.
and provide some visibibility to the bootstrapping you're allegedly using for CentOS 6, and we'd love to help on this and future releases.
Ok, let's try this again. The bootstrapping of the buildroots is a process that isn't really finished until the last package is built and tested as binary compatible If all the packages aren't built, or if all the packages have not passed QA, then the full bootstrap is not known.
Bootstrapping a major version bump for a distribution is a really a one-time event, I would think, and the specifics of that bootstrap likely will not be usable (the general way of going about it will be) as such on the next major version.
Bootstrapping a from-source rebuild is at the moment, and as far as I know, the least documented of the steps involved, but at the same time information has been posted as to the initial seed for the rebuild, and for the bootstrapping start point. While I could do the legwork and post the link for you in the archives, I think you should go find it yourself.
The build components in the "build" repository, for example, are pretty old and clearly out of date. Point us to the current versions, please!
How do you know that those are not the current versions for building and QAing C4.x and C5.x? For C6 they're not going to publish until they have proven working versions. C4 and C5 are old enough.... and build scripts for old base distributions don't need changing for every release if the old version still works, no?
The CentOS developers did not ask for (that I saw, at least) and at this point in time apparently neither want nor need help with the build piece; we have some promises that the process will be better documented for C6, and we'll not see that document until it is known that the process works to a fully-released conclusion.
So hold on to your hat, be patient, and wait on the release.... or go build it yourself for already published documents/e-mails. It is doable. Once you do it be sure to publish your results.....
On Wed, Mar 23, 2011 at 12:15 PM, Lamar Owen lowen@pari.edu wrote:
On Wednesday, March 23, 2011 09:56:34 am Nico Kadel-Garcia wrote:
Understood. I'd like to replicate or examine the error. "Building it yourself", without that access to your unique build environment or a way to gracefully replicate it, represents dozens or hundreds of man-hours for each contributor who'd like to help. That's a little hard to do right now.
He's given out his build system requirements. Last I saw it was 'C5.5 fully updated' (which I take to be 'with all the current public updates') .... but, no, you can grep the archives for yourself for the mock version he said. I read that message; it gave enough information to get started.
mock version is not the same as mock files. Really. The mixing of older, CentOS 5.5 versus updated components can get tricky, and the tweaks to enable the use of unsigned locally managed components requires thought (or should!!). There are also components in the RHEL 5.6 SRPM's that have mutual dependencies and have to be built together. I don't care to spend all that time rebuilding all that work if I don't have to.
And to replicate the error you have to do the work; there is no shortcut, and if you don't have time to put that many hours into it (like me; I don't have that kind of time right now either) then you can't replicate it. Besides, it's already fixed in the C5 tree, so replication is not really useful at the moment, at least not to CentOS, I would think.
Fine. Then show *US* how you're doing it. Publish the /etc/mock/ files you use,
He has done this. More than once, now, in the CentOS-devel list. Go read the archives; it's all there.
and provide some visibibility to the bootstrapping you're allegedly using for CentOS 6, and we'd love to help on this and future releases.
Ok, let's try this again. The bootstrapping of the buildroots is a process that isn't really finished until the last package is built and tested as binary compatible If all the packages aren't built, or if all the packages have not passed QA, then the full bootstrap is not known.
*Current status* would be helpful.
Bootstrapping a major version bump for a distribution is a really a one-time event, I would think, and the specifics of that bootstrap likely will not be usable (the general way of going about it will be) as such on the next major version.
Bootstrapping a from-source rebuild is at the moment, and as far as I know, the least documented of the steps involved, but at the same time information has been posted as to the initial seed for the rebuild, and for the bootstrapping start point. While I could do the legwork and post the link for you in the archives, I think you should go find it yourself.
"And then a miracle occurred". Yes.
The build components in the "build" repository, for example, are pretty old and clearly out of date. Point us to the current versions, please!
How do you know that those are not the current versions for building and QAing C4.x and C5.x? For C6 they're not going to publish until they have proven working versions. C4 and C5 are old enough.... and build scripts for old base distributions don't need changing for every release if the old version still works, no?
Becuse I read them. Many, not all are centos-3 specific. Others are behavioral replicas, with no indication which is actually in use.
That's the sort of thinig source control is so useful for. Getting not just your source, but your build chain under into the source management helps assure the overall quality and consistency of what you do, and be able to replicate your build environment.
I've looked at the previous requests for help. I stink at graphics, unfortunately, but have considerable difficulty replicating the other issues because the build environment is undocumented.
The CentOS developers did not ask for (that I saw, at least) and at this point in time apparently neither want nor need help with the build piece; we have some promises that the process will be better documented for C6, and we'll not see that document until it is known that the process works to a fully-released conclusion.
So, you're saying they don't want help, only help with what they want help with, thank you very much?
So hold on to your hat, be patient, and wait on the release.... or go build it yourself for already published documents/e-mails. It is doable. Once you do it be sure to publish your results.....
Or hop to Scientificic Linux, where the resulting delays are not so large.
On Wed, 23 Mar 2011, Johnny Hughes wrote:
It takes hours to analyze all the packages in a build ... I do not have hours to spend on doing it for SL ... but here is another error that I found in the SL tree when figuring out build issues in the CentOS 5.6 tree:
Which is why opening the process would mean more people are doing that work for you. Much like Linus Torvalds is not doing a lot of programming anymore these days.
If you don't want to become the Linus of CentOS, that's fine too, but I don't see the point in doing this behind doors all by yourself if sharing and coordination would solve most of the issues.
You pick, build and sign what you like from a shared pool of information.
- As mentioned before, Scientific Linux 6.0 is out. What hasn't been
mentioned here is that while SL 5.6 hasn't come out, 5.6 security updates are being backported to SL 5.5. Ditto with SL 4 (no 4.9 but security patches look current)
And we try very hard not to release things until they pass our QA testing.
Let me make something clear: I have been a CentOS user since 2006. I really, really appreciate all of the contributions the CentOS team has made--contributions which have been made without being properly compensated for the time and effort made.
We are still finding and correcting issues with the 5.6 things that we have built (things not properly linking when compared to upstream, etc).
As I mentioned before, the CentOS team owes me nothing. If the CentOS team decides tomorrow that deathmatching Nexuiz (errr, Xonotic, because how dare anyone try making money with their open-source project) is more fun than making security updates and getting 5.6 or 6 out the door, enjoy yourselves! CentOS does not owe me a single release more or even a single security update.
For me, I would rather have timely releases and security updates than guaranteed binary compatibility. My appeal of a RHEL clone is that I will be able to use a RHEL 5 clone until 2014 (RHEL 6 clone until 2017) and have security issues fixed.
Anyway, thank you for the great work, and it has been a pleasure using CentOS for so many years!
- Sam
Sam Trenholme wrote:
- As mentioned before, Scientific Linux 6.0 is out. What hasn't been
mentioned here is that while SL 5.6 hasn't come out, 5.6 security updates are being backported to SL 5.5. Ditto with SL 4 (no 4.9 but security patches look current)
And we try very hard not to release things until they pass our QA testing.
Let me make something clear: I have been a CentOS user since 2006. I really, really appreciate all of the contributions the CentOS team has made--contributions which have been made without being properly compensated for the time and effort made.
We are still finding and correcting issues with the 5.6 things that we have built (things not properly linking when compared to upstream, etc).
As I mentioned before, the CentOS team owes me nothing. If the CentOS team decides tomorrow that deathmatching Nexuiz (errr, Xonotic, because how dare anyone try making money with their open-source project) is more fun than making security updates and getting 5.6 or 6 out the door, enjoy yourselves! CentOS does not owe me a single release more or even a single security update.
For me, I would rather have timely releases and security updates than guaranteed binary compatibility. My appeal of a RHEL clone is that I will be able to use a RHEL 5 clone until 2014 (RHEL 6 clone until 2017) and have security issues fixed.
I think I'm seeing a miss-understanding here - please correct me if I'm wrong. Binary Compatibility means that rpms made for RHEL will "just work" on CentOS. If binary compatibility is dropped in favor of just getting a patch out the door, then sooner or later an rpm or module that used to work will fail and trying to track down the problem and resolve it will be made more difficult as the provider of the rpm has two (or more) possible build environments and dependencies to deal with. Be careful what you wish for!!
Anyway, thank you for the great work, and it has been a pleasure using CentOS for so many years!
- Sam
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Dag Wieers -
Johnny Hughes -
Lamar Owen -
Nico Kadel-Garcia -
Rob Kampen -
Sam Trenholme