Just as a PoC and to see how the inter-worker process locks work in the CentOS buildsystem, I churned the epel6 srpm set through rhel7b1′s public content. The entire run took just over a day, and I was surprised to see 4,440 binary rpms ( from 2,870 srpms ); There was no requeue / rpm-blame enabled here, and the packages were roughly built in the order they went in. 4,950 srpms were import from epel-6/srpms/30th Dec 2013.
Result is available here : http://mirrors.karan.org/epel7/ ; hope this further allows people to test the bits they care about in the upcoming release, and also something that the epel guys can find useful. For everyone who hasent seen the CentOS Buildsystem output, this is what it looks like. The entire contents of the mock resultdir are pushed, along with some metadata around the build, and every build has a ‘TAG’ which represents the date/time when it was ‘requested’.
Most people should/would want to track the real EPEL builds at : http://dl.fedoraproject.org/pub/epel/beta/7/
A couple of years ago If someone said to me that my laptop bag would have equal parts electronics kit and nappy kit, I would have laughed.
Now, that’s just how we roll.
RHEL 7 seems to have dropped installer / native support for 32bit Intel x86 machines. Only 64bit machines will be supported, and there is 32bit multilib support built in, so people can still run most 32bit apps.
So do we want to build a 32bit installer and os tree for CentOS-7 ? Can we find the people and resources ( mostly people, resources for an extra os tree are minimal in this case ) to be able to maintain that 32bit tree ? Large part of the answer would depend on what feature set we intend to support ( likely wont be a 100% cover of the x86_64 spec ), and what the real user demand for this is.
Update: Its worth noting that we might need to build a i686 tree in order to build the multilib components in x86_64 anyway.
Most people reading this blog would already know that RHEL 7 beta1 is now publicly avaialable. If you didnt then you can go download it here : ftp://ftp.redhat.com/redhat/rhel/beta/7/ and see the release notes at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html
Our plans for CentOS Linux 7 are to still focus testing resources on the upstream RHEL-7 beta, the better the overall quality of RHEL-7 when it comes to release, the better off we are all going to be. So there is little attraction in diluting that testing effort; On the other hand, we want to be a lot better prepaired for EL7 than we were for EL6, so that goal – we are going to do a build, publicly, and call it a limited release for testing. Keep your eyes on the centos-devel mailing list for more information about that, and progress reports on the build effort.
The other free win from a CentOS-7beta build is that people currently using CentOS Linux, wanting to migrate to 7 when its released can start doing their own testing for CentOS specific things, and start reporting issues and helping fix problems they encounter. Basically, the aim is to be a lot better prep’d for the release than we have ever been before.
As I migrate the blog over, the older posts are not visible. Should have those done in a few days time. Find something else broken ? please let me know . http://www.karan.org/contact.html
Yesterday we released CentOS-6.5 into GA and I wanted to say a quick thanks to everyone on the QA Team who contributed, often working through the small hours of the night, to bring this release out so rapidly.
The release announcement is at : http://lists.centos.org/pipermail/centos-announce/2013-December/020032.html and the Release Notes are at : http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5 I would also highly recommend looking through the upstream release notes, given the amount of changes in this release : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.5_Release_Notes/