Firstly, there are a couple of cool things with rhel6 beta2 - rpmdevtools is included by default, which helps gets things started and helps a bit in managing spec files etc.

What isnt so cool is that the newer rpm in el6beta creates packages which then cause issues with some of the older CentOS releases. eg. this areca_cli package built on el6beta2/x86_64 for target i686 caused this to happen with yum:

Downloading Packages:
areca_cli-1.83_091103-1.e 100% |=========================| 493 kB    00:00     
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
rpmlib(FileDigests) is needed by areca_cli
rpmlib(PayloadIsXz) is needed by areca_cli
Complete!
(1, [u'Please report this error in https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%205&component=yum'])

Which causes the package to not install. This is on a CentOS-5.2 machine. And I need to maintain that at CentOS-5.2 due to various issues ( no, machine is not available on the internet, and only hosts a single app in production ). Trying the install on a CentOS-5.3 machine I get the exact same issue. Upgrading rpm to 4.4.2.3-18.el5 ( the version in 5.4 and 5.5 ) makes no difference.

On the other hand, builds run on CentOS-5 have no problems installing on EL6Beta. So for the time being it looks like all buildhosts and all build stuff will need to stay on EL5. Specially since that allows you to target CentOS-3 and CentOS-4 as well.

- KB

Note: yeah, I see that url pointing at bugzilla isnt idea. I'll look into plumbing in a bugs.centos.org reference instead.

In the early days of EL5, there was a perl.i386 included in the distro, which Red Hat then took away and made perl.x86_64 the only perl in the x86_64 tree. This caused a non-trivial issue to people who already had a CentOS install and wanted to maintain that install. So in order to avoid having to deal with potentially hundreds of people who would have had a broken perl setup as well as yum update issues, we decided to maintain a perl.i386 in the extras repo for c5/x86_64. This would mean that people who already had a perl.i386 on their machines would still be able to keep things the way they were - and new installs would only get the perl.x86_64 ( since the install is only run from the os/ repository, it does not come in contact with the perl.i386 in extras at all ). Yum has also become a lot smarter about its handling of arch specific packages, which would mean that people not looking for a perl.i386 by name, would not need to worry about it at all.

Think of it this way - when we had to make that decision, we asked around. Specially people who use perl in their day to day jobs and people who have non trivial contributions to cpan about the impact of perl.i386 on a x86_64 install. None of them came back to say anything that would lead us to believe perl.i386 was going to be a problem. So we took the approach of not breaking installs - and keeping the perl.i386 in a place where most people could access it.

So why the sudden interest in this issue again ? We had a perl update for CentOS-5 go out 2 days back. And this brought in some interest - since there are *still* people, three years down the road, who have perl.i386 installs! but it was a bit of our fault as well. In the specific case of perl-5.8.8-32.el5_5.1, the perl.i386 pkg into extras/x86_64 lagged by a few hours - and that resulted in *some* mirrors getting out of shape for a few hours. That was my fault completely. If you tried to do an update for perl and hit one of those mirrors, during those few hours, yum would have complained about conflicts between perl.x86_64 and perl.i386 ( of-course, only if you have perl.i386 in the first place ).

To make sure this does not happen again in the future I've plumbed in a test that checks for perl.i386 in extras/x86_64 matching perl in updates/i386/; This should ensure that we can do the update push in the future unless all the perl packages are in place first.

Keeping all this in mind, should we have taken the hit in the early CentOS-5 days and let users deal with the update issues they would almost certainly have run into ? I still think we did the right thing long term.

- KB

In terms of what agenda for the chat, we have four issues that need attention:

• Setup some goals for the effort
• Nominate some people who could be contact points
• Where we are right now
• How do we get to the targets - so that would include deciding on co-ordination and collaboration process

See you all then!

- KB

To Fix this, make sure you select the option to review partition and disk layout, and manually change /boot from ext4 to ext2. Everything should just work fine.

- KB

Disapointed that Exim is going away, its become my mta of choice over the last few years. Also disapointed that ruby is at 1.8.6 and isnt going to make 1.9.x. Although, having rubygems in the distro is good. Same with all the major Version control systems are now included, svn, git, cvs, rcs, mercurial and bazaar

On the other hand, python 2.6 is cool. Along with the inclusion of ipython, turbogears and pylons. Like the fact that amqp via qpid ( my implementation of choice ) are also included in the base distro. Same with FCoE, been testing it over the last few months and would be really nice to see it in a supported format now.

Also amongst the interesting stuff : bacula replacing amanda, like it. Sysklogd replaced by rsyslog, like it. Vixie-cron replaced by cronie, like it. Al the system-config-* tools are gone, dont care - never used them myself anyway. Xfs is now in the mainstream supported mode along with ext4, like it. Completely Fair Scheduler in the kernel, like it. No drbd, odd given that its being used quite a lot.

This is just a first look reaction, over the next few weeks I'm going to try and poke around a bit more and will blog about more specific things.

http://www.karan.org/stuff/rhel6-i386-beta-dvd.torrent
http://www.karan.org/stuff/rhel6-ppc64-beta-dvd.torrent
http://www.karan.org/stuff/rhel6-x86_64-beta-dvd.torrent 

There are a few seeds, on fairly high speed links, to get you started.

- KB

The first thing that everyone will want to know is : when will centos-6-beta come out. Well, it wont be for a while. The reason is - this is a public beta, you can get it directly from Red Hat, and we want you to do that. Beta test the Red Hat builds, report issues and bugs at http://bugzilla.redhat.com/ and make sure you follow their rhel-6-beta list. And do this because, we all want a better upstream product.

So where does this leave CentOS and CentOS-6-beta ? We will setup a build process for CentOS-6-Beta, and we will go through the process of putting out a new release, across a restricted number of machines so that people can also test our builds, however we want the focus of this testing around CentOS-6-beta to be the packages we need to change, modify and adapt for CentOS. The core packages and testing should still be focused on RHEL-6, since a better upstream product helps all of us, and a large number of issues reported against CentOS-6-beta will almost certainly be pushed upstream.

- KB

The idea here is that we have a couple of machines, close to the buildsystem, that can take a centos release, and run through installs in a loop, reporting success or failure after each install. Even if we only start with one machine for each primary arch, i386 and x86_64, we should be able to cycle through over 120 install cycles per arch within 24 hours with the right kind of automation. The automation is what I would like to focus on, I need your help with the kickstarts.

If you are able to write up some kickstarts, or even just go through an install and adapt the resulting anaconda-ks.cfg file - send them to me. Send me kickstarts for just about any role or deployment strategy you can think of - to get the ideas flowing I've made a short list of thing that would be good to have kickstarts for; dont, in any way feel restricted to these roles:

My initial wish list is something along these lines:

• General install, with no changes in the installer, just filling out whatever is the minimum required input
• A minimal install that only needs cd-1
• A LAMP server
• A Postgresql server
• GNOME Desktop
• KDE Desktop
• Xen Dom0 host
• KVM host
• DHCP and Static networked server installs
• Install from CDrom
• Install over http
• Install over NFS
• Install from local disk
• Office SME server, with samba and email

Here's how you could contribute the kickstarts:

• Post it online and leave a comment here with a url pointing to it
• Post it to the centos-devel list ( http://lists.centos.org )
• Drop into #centos-devel on irc.freenode.net and point us at it there

The kickstarts that we collect will be published online ( unless you specifically ask me not to ) along with results from each install cycle and details that came from it.

I know its not very organised at this time. But along with the automation I will build a web interface that lists the kickstarts along with a git repo that lets people directly pull from and push patches into.

If you need some help getting started with kickstarts, take a look at the wiki article at : http://wiki.centos.org/TipsAndTricks/KickStart and the docs at : http://www.centos.org/docs/5/html/5.2/Installation_Guide/s1-kickstart2-file.html . I would also highly recommend looking at the /root/anaconda-ks.cfg file that is left behind on any new centos install. Then there is always google.

- KB