[CentOS] Some relevant information

Wed Mar 23 09:42:56 UTC 2011
Johnny Hughes <johnny at centos.org>

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>