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. -------------- 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-0001.sig>
On Wed, Mar 23, 2011 at 5:42 AM, Johnny Hughes <johnny at 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 olderOuch. 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 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. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
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.....
>> * 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