https://www.centos.org/modules/newbb/viewtopic.php?topic_id=25878&forum=53
My current understanding is that the ongoing build of CentOS 6.0 is still running in minimal mode. I expect it to pick up speed once all the current CentOS 5.6 updates have been built and pushed to the update queue.
I will be discussing the 6.0 build status with Karanbir in the next few days and hopefully will have something a little less tenuous to report early-ish next week.
I think it is fair to say that as CentOS 6.0 is a new entry into the product line, it may spend somewhat more time in QA whilst the critical eyes give it close scrutiny.
-- Alan
Presumably, this means that it is reasonable to expect a longer window than the early optimistic estimates of two weeks after the CentOS 5.6 release.
On Fri, 2011-04-15 at 12:12 -0400, Matthew Miller wrote:
Presumably, this means that it is reasonable to expect a longer window than the early optimistic estimates of two weeks after the CentOS 5.6 release.
Is there any update on what's going on the CentOS 6 front?
The last update in the forums have been published on Apr. 14, the last tweet was on Apr. 18 and nothing has been posted on the list either. I am not following CentOS-Users, but it is reasonable to expect that if any official update was posted there for it to be cross-posted here as well.
Thanks!
On Tue, Apr 26, 2011 at 8:20 AM, Yury V. Zaytsev yury@shurup.com wrote:
On Fri, 2011-04-15 at 12:12 -0400, Matthew Miller wrote:
Presumably, this means that it is reasonable to expect a longer window than the early optimistic estimates of two weeks after the CentOS 5.6 release.
Is there any update on what's going on the CentOS 6 front?
The last update in the forums have been published on Apr. 14, the last tweet was on Apr. 18 and nothing has been posted on the list either. I am not following CentOS-Users, but it is reasonable to expect that if any official update was posted there for it to be cross-posted here as well.
A build and QA plan is being worked out now with the QA team. I expect that once this is finalized there will be a statement from a CentOS dev with more details.
-Jeff
On 04/26/2011 11:25 AM, Jeff Sheltren wrote:
A build and QA plan is being worked out now with the QA team. I expect that once this is finalized there will be a statement from a CentOS dev with more details.
via Twitter, 5:13 AM May 3rd:
CentOS-6 release plan, target-1) tree's to QA by 10th May
On 05/06/2011 02:47 PM, Mike Doroshenko wrote:
On 05/06/2011 12:49 AM, Bill McGonigle wrote:
target-1) tree's to QA
What does /target-1) tree's to QA/ mean? I know QA stands for Quality Assurance, but /tree's to Quality Assurance/ still doesn't make sense to me.
If you look on mirror.centos.org, what we consider a "Tree" is the 5.6 directory or the 4.8 directory.
In this particular case, we are saying that we will get all the RPMs (built) in the 6.0 to QA to look at.
They will be installable as RPMs from the directory (ie, like the updates directory).
We may have network installable boot images at that point, but we will not have a full set of installable / bootable ISOs.
Once we run several sets of tests in QA with many kinds of installs (or updating over other installs for other than the .0 releases) and once we fix issues found with these RPMS, then we will generate the actual install ISOs and test those.
On 05/06/2011 03:01 PM, Johnny Hughes wrote:
On 05/06/2011 02:47 PM, Mike Doroshenko wrote:
On 05/06/2011 12:49 AM, Bill McGonigle wrote:
target-1) tree's to QA
What does /target-1) tree's to QA/ mean? I know QA stands for Quality Assurance, but /tree's to Quality Assurance/ still doesn't make sense to me.
If you look on mirror.centos.org, what we consider a "Tree" is the 5.6 directory or the 4.8 directory.
In this particular case, we are saying that we will get all the RPMs (built) in the 6.0 to QA to look at.
They will be installable as RPMs from the directory (ie, like the updates directory).
We may have network installable boot images at that point, but we will not have a full set of installable / bootable ISOs.
Once we run several sets of tests in QA with many kinds of installs (or updating over other installs for other than the .0 releases) and once we fix issues found with these RPMS, then we will generate the actual install ISOs and test those.
Some of the tests that we run in this stage (where we have all the RPMs, but not necessarily an installable distro) is:
1. All the RPMs seemed to install properly on a running system.
2. That the dynamic libraries linked by all the libraries/binaries are the same as upstream.
3. That the file list of every RPM we produced is identical to the file list of every RPM from upstream.
4. That the trees contain the correct versions of all files (the same ones on the .0 isos from upstream). We want to make sure the updates go into the updates directory.
5. That the comps.xml (compilation) file has the correct groups in it. Upstream has several different versions of their codebase that they sell for different amounts ... ie: a. Server b. Workstation c. Desktop
CentOS has no need for the segregation, our product is free and contains all the packages (and yum install groups, etc.) from all of those combined.
We also remove several packages (all the RHN items, for example, since CentOS is not allowed to update from RHN, etc.)
This requires us to take the applicable portions of several comps files and build a combined comps file that allows you to install Servers, Desktops, Workstations, etc.
6. In the case of 6.0 specifically, there is an "optional" channel that contains many of the -devel (development) files needed to build things. We also have no need for that, but we need to get the items in that channel integrated into our distribution and comps files.
Once we get all of these things done and tested, then we can generate a set of real ISOs and test the install groups, etc.
Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
We also remove several packages (all the RHN items, for example, since CentOS is not allowed to update from RHN, etc.)
Yes, but these packages might be important for Spacewalk deployment. So I'd prefer to modify these packages and release. DH
Hi David,
all the neccessary packages are in the spacewalk-client repo anyway. Plus as of Spacewalk 1.4 they can be provisioned from the server quite easily. Why duplicate work? These are not really needed for a standalone CentOS.
am Freitag, 6. Mai 2011 um 22:47 schrieben Sie:
Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
We also remove several packages (all the RHN items, for example, since CentOS is not allowed to update from RHN, etc.)
Yes, but these packages might be important for Spacewalk deployment. So I'd prefer to modify these packages and release. DH
Dne 7.5.2011 00:03, Thomas Göttgens napsal(a):
Hi David,
all the neccessary packages are in the spacewalk-client repo anyway. Plus as of Spacewalk 1.4 they can be provisioned from the server quite easily. Why duplicate work? These are not really needed for a standalone CentOS.
Thomas, This is not the duplication. First of all you have to register the system into Spacewalk. So you need rhnreg_ks, which is in rhn-setup-1.3.12-1.el5. One must install spacewalk-repo-client package first. Regards, DH
On 05/06/2011 09:47 PM, David Hrbáč wrote:
Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
We also remove several packages (all the RHN items, for example, since CentOS is not allowed to update from RHN, etc.)
Yes, but these packages might be important for Spacewalk deployment. So I'd prefer to modify these packages and release.
The space walk guys seem to prefer not having the code in the distro, and just use the latest / greatest from the spacewalk repo's; has that mindset changed in the recent past ? ( since we had the chat on this list last anyway .. )
- KB
Dne 7.5.2011 00:18, Karanbir Singh napsal(a):
The space walk guys seem to prefer not having the code in the distro, and just use the latest / greatest from the spacewalk repo's; has that mindset changed in the recent past ? ( since we had the chat on this list last anyway .. )
- KB
I'm not talking about following Spacewalk. Having just "old" package for bootstrapping would be fine and useful. So one can easily register into Spacewalk and update spacewalk client from Spacewalk channel then. DH
On Fri, 6 May 2011, David Hrbáč wrote:
Dne 6.5.2011 22:24, Johnny Hughes napsal(a):
We also remove several packages (all the RHN items, for example, since CentOS is not allowed to update from RHN, etc.)
Yes, but these packages might be important for Spacewalk deployment. So I'd prefer to modify these packages and release.
Thinking out loud here ...
The question then becomes: how to test these? We'll need a 'cookbook' or automated process for setting up the needed test harness infrastructure, and then the functional tests, if these parts were to be retained ...
By and large, the only non-end-user posters 'in quantity' on the spacewalk mailing lists seem to be @redhat folks, and so the utility of such an effort is not clear
-- Russ herrold
Hi!
Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
On Mon, 2011-05-30 at 15:27 +0200, Fabian Arrotin wrote:
On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:
Hi!
Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
No and the current tree isn't complete either
Thanks for the update!
On Mon, May 30, 2011 9:29 am, Yury V. Zaytsev wrote:
On Mon, 2011-05-30 at 15:27 +0200, Fabian Arrotin wrote:
On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:
Hi!
Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
No and the current tree isn't complete either
Thanks for the update!
Would it be possible to update the QAWeb calendar accordingly?
On 30 May 2011 15:09, Patrice Guay patrice.guay@nanotechnologies.qc.ca wrote:
On Mon, May 30, 2011 9:29 am, Yury V. Zaytsev wrote:
On Mon, 2011-05-30 at 15:27 +0200, Fabian Arrotin wrote:
On 05/30/2011 02:55 PM, Yury V. Zaytsev wrote:
Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
No and the current tree isn't complete either
Thanks for the update!
Would it be possible to update the QAWeb calendar accordingly?
Jeff ?? Where are you ?
Alan.
On 30 May 2011 18:35, John R. Dennison jrd@gerdesas.com wrote:
On Mon, May 30, 2011 at 06:30:16PM +0100, Alan Bartlett wrote:
Jeff ?? Where are you ?
You're aware that today is a US federal holiday?
Bah! Humbug!
The CentOS Project is not US of A-centric. :P
FYI, today is a UK Bank Holiday!
Alan.
On Mon, May 30, 2011 at 10:38 AM, Alan Bartlett ajb@elrepo.org wrote:
On 30 May 2011 18:35, John R. Dennison jrd@gerdesas.com wrote:
On Mon, May 30, 2011 at 06:30:16PM +0100, Alan Bartlett wrote:
Jeff ?? Where are you ?
You're aware that today is a US federal holiday?
Bah! Humbug!
I'm around, but enjoying time away from the computer today. There is some progress being made on QA -- will update the calendar accordingly.
-Jeff
On 05/30/2011 01:55 PM, Yury V. Zaytsev wrote:
Hi!
Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
the isos are uploading at the moment, will try and put some of this stuff into a blog post on the qaweb interface
- KB
On Mon, May 30, 2011 at 3:40 PM, Karanbir Singh mail-lists@karan.org wrote:
Did the ISO's make it to Q&A on May 27 as scheduled on the calendar?
the isos are uploading at the moment, will try and put some of this stuff into a blog post on the qaweb interface
I posted an update here: http://qaweb.dev.centos.org/qa/node/82
Will get the calendar updated soon.
-Jeff
On 2011-05-31 00:40, Karanbir Singh wrote:
the isos are uploading at the moment, will try and put some of this stuff into a blog post on the qaweb interface
- KB
I don't know whether you use (and can use) the following hack to speed up rsyncing the iso files:
- you need to have the full (or mostly complete) package tree on the target
- on the target machine manually make the tar archive out of already rsynced package tree, rename that tar to CentOS-whatever_it_is.iso so that it pretends to be the older version of the real .iso
- rsync the real iso (CentOS-whatever_it_is.iso) over this template iso
The test made with CentOS-5.6-x86_64-bin-DVD-1of2.iso shows:
sent 186234656 bytes received 521538 bytes 3626333.86 bytes/sec total size is 4249268224 speedup is 22.75
Just my 2 cents...
Andrzej
Hi,
On 06/01/2011 06:52 PM, Andrzej Szymański wrote:
I don't know whether you use (and can use) the following hack to speed up rsyncing the iso files:
- you need to have the full (or mostly complete) package tree on the target
We do some sanity tests that span the buildsys, the intermediary host and the final rsync targets. So its important that the first set of contents is sync'd out from the buildsys as-is. Perhaps extra caution, but we have had problems in the past ( even with rsync saying two files are identical when they were clearly not ).
On the other hand, the ISOS can be fairly easily re-created from the tree, so if the rpms tree are is already in place that would be easier than going down the tar route.
- KB
On 06/02/2011 12:21 PM, Karanbir Singh wrote:
Hi,
On 06/01/2011 06:52 PM, Andrzej Szymański wrote:
I don't know whether you use (and can use) the following hack to speed up rsyncing the iso files:
- you need to have the full (or mostly complete) package tree on the target
We do some sanity tests that span the buildsys, the intermediary host and the final rsync targets. So its important that the first set of contents is sync'd out from the buildsys as-is. Perhaps extra caution, but we have had problems in the past ( even with rsync saying two files are identical when they were clearly not ).
if it's that important: rsync --checksum it's expensive but will guarantee identity
On the other hand, the ISOS can be fairly easily re-created from the tree, so if the rpms tree are is already in place that would be easier than going down the tar route.
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/02/2011 01:15 PM, Ferry Huberts wrote:
if it's that important: rsync --checksum it's expensive but will guarantee identity
it actually does not, the -c option was tried at the time as well. It turned out to be a bug in rsync itself ( in the 2.6.9 version ); who's to say there are no more of those!
- KB
On 06/02/2011 04:24 PM, Karanbir Singh wrote:
On 06/02/2011 01:15 PM, Ferry Huberts wrote:
if it's that important: rsync --checksum it's expensive but will guarantee identity
it actually does not, the -c option was tried at the time as well. It turned out to be a bug in rsync itself ( in the 2.6.9 version ); who's to say there are no more of those!
ah, that would be a problem yes ;-)
keep up the good work!
On 06/02/2011 04:01 PM, Ferry Huberts wrote:
it actually does not, the -c option was tried at the time as well. It turned out to be a bug in rsync itself ( in the 2.6.9 version ); who's to say there are no more of those!
ah, that would be a problem yes ;-)
I just realised that no mention was made of the problem - we had a situation in 5.2 release days where a repomd file with a clearly different timestamp was being considered by rsync to be identical, even with the -c flag on. Similarly we had issues with the comps-extras rpms being considered identical when they clearly were not, resigning the package also made no difference.
keep up the good work!
thanks
Karanbir Singh wrote on 06/02/2011 06:21 AM:
On the other hand, the ISOS can be fairly easily re-created from the tree, so if the rpms tree are is already in place that would be easier than going down the tar route.
Seems that would help a lot with the limited QA upload bandwidth that apparently delayed the initial unified tree.
Publishing a recipe for doing it would save a lot of people a lot of time and bandwidth for QA downloads, as well as releases for the community. The current procedure on the Wiki
http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia
fails with a package tree for lack of a .discinfo file. If there is a simple process for creating one it could be incorporated into the script.
Phil
On 06/02/2011 01:49 PM, Phil Schaffner wrote:
http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia
fails with a package tree for lack of a .discinfo file. If there is a simple process for creating one it could be incorporated into the script.
i dont know whats on the end of that wiki article, am http less at the moment - however, even the cd's should have a .discinfo
- KB
Karanbir Singh wrote on 06/02/2011 10:25 AM:
On 06/02/2011 01:49 PM, Phil Schaffner wrote:
http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia
fails with a package tree for lack of a .discinfo file. If there is a simple process for creating one it could be incorporated into the script.
i dont know whats on the end of that wiki article, am http less at the moment - however, even the cd's should have a .discinfo
The Wiki article mainly comprises a script, originally by Chris Kloiber ckloiber@redhat.com with tweaks by yours truly, that can build a DVD iso from CDs, or a package tree - given that a .discinfo file is available. If there are no ISOs yet available, as for instance with the current QA tree, the script does not know how to create a .discinfo on the fly, nor do I. I did look around a bit in the past (that being circa 2008) but failed to come up with the formula; however, I would assume the developers must know the correct magic incantation.
It occurs to me while writing this that the script also does not know how to split things up if more than one DVD is required, as that was not a concern when the script was created, nor when I modified it for the Wiki.
Phil
On 06/02/2011 07:58 PM, Phil Schaffner wrote:
available. If there are no ISOs yet available, as for instance with the current QA tree, the script does not know how to create a .discinfo on the fly, nor do I. I did look around a bit in the past (that being circa 2008) but failed to come up with the formula; however, I would assume the developers must know the correct magic incantation.
the .discinfo and .treeinfo are created when the installer builds, and it contains content that needs to be in sync with the installer images - so manually creating it isnt going to cut it :)
- KB
If you want to be symbolic, I highly recommend you release this next Friday. Since I can already see everyone comparing this to be the Linux equivalent to Duke Nukem Forever, releasing it on the same day would be a suiting irony.
~Shawn
On Thu, Jun 2, 2011 at 8:20 PM, Karanbir Singh mail-lists@karan.org wrote:
On 06/02/2011 07:58 PM, Phil Schaffner wrote:
available. If there are no ISOs yet available, as for instance with the current QA tree, the script does not know how to create a .discinfo on the fly, nor do I. I did look around a bit in the past (that being circa 2008) but failed to come up with the formula; however, I would assume the developers must know the correct magic incantation.
the .discinfo and .treeinfo are created when the installer builds, and it contains content that needs to be in sync with the installer images - so manually creating it isnt going to cut it :)
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Karanbir Singh wrote:
Hi,
Andrzej Szymański wrote:
I don't know whether you use (and can use) the following hack to speed up rsyncing the iso files:
- you need to have the full (or mostly complete) package tree on the target
We do some sanity tests that span the buildsys, the intermediary host and the final rsync targets. So its important that the first set of contents is sync'd out from the buildsys as-is. Perhaps extra caution, but we have had problems in the past ( even with rsync saying two files are identical when they were clearly not ).
On the other hand, the ISOS can be fairly easily re-created from the tree, so if the rpms tree are is already in place that would be easier than going down the tar route.
I found out the hard way in a large production setting about rsync parameters that were "new to me":
--bwlimit=0 (Don't throttle transfers that run "too quickly")
--whole-file (don't use the delta-xfer algorithm, the whole file needs replacing)
--sockopts=TCP_NODELAY (_might_ be useful, you'd have to test if it helps on your system)
and apropos of well-defined behavior, you might have overlooked:
--delay-updates
This option puts the temporary file from each updated file into a holding directory until the end of the transfer, at which time all the files are renamed into place in rapid succession. This attempts to make the updating of the files a little more atomic.
On 06/02/2011 03:15 PM, Charles Polisher wrote:
and apropos of well-defined behavior, you might have overlooked:
--delay-updates
the msync machines all run with this option set, since it can take a while to get 20 odd Gigs per release into place across 90 odd machines :D
Thanks for the tips and helpful feedback.
- KB
-
Alan Bartlett -
Andrzej Szymański -
Bill McGonigle -
Charles Polisher -
David Hrbáč -
Fabian Arrotin -
Ferry Huberts -
Jeff Sheltren -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Matthew Miller -
Mike Doroshenko -
Patrice Guay -
Phil Schaffner -
R P Herrold -
Shawn Thompson -
Thomas Göttgens -
Yury V. Zaytsev