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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20110323/f272db34/attachment-0005.sig>