So is beta 2 off - in favor of just waiting for the real RHEL5 release? RH has said it is ready to go and would be released in march. Hopefully march 1. HA!
No complaining just curious.
Jerry
On Tue, 2007-02-20 at 10:21 -0500, Jerry Geis wrote:
So is beta 2 off - in favor of just waiting for the real RHEL5 release? RH has said it is ready to go and would be released in march. Hopefully march 1. HA!
More like March 15th (and don't hold your breath :P)
We will release a beta ... as we are close now at fixing everything.
Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2007-02-20 at 10:21 -0500, Jerry Geis wrote:
So is beta 2 off - in favor of just waiting for the real RHEL5 release? RH has said it is ready to go and would be released in march. Hopefully march 1. HA!
More like March 15th (and don't hold your breath :P)
We will release a beta ... as we are close now at fixing everything.
Just out of couriosity, would you be willing to comment on the issues the CentOS team is running up against. Given upstream's decision to scrap the old way of spinning and distributing the distro I would imagine some of them are large problems.
Regards,
On Wed, 2007-02-21 at 21:22 -0500, Tom Diehl wrote:
Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2007-02-20 at 10:21 -0500, Jerry Geis wrote:
So is beta 2 off - in favor of just waiting for the real RHEL5 release? RH has said it is ready to go and would be released in march. Hopefully march 1. HA!
More like March 15th (and don't hold your breath :P)
We will release a beta ... as we are close now at fixing everything.
Just out of couriosity, would you be willing to comment on the issues the CentOS team is running up against. Given upstream's decision to scrap the old way of spinning and distributing the distro I would imagine some of them are large problems.
Well ... the majority of our problems are coming from the fact that upstream did not build everything on the same builder. They grabbed .fc6 stuff as is and used it (not necessarily compiled on their el5 builder).
Many items are compiled against different kernel-headers, etc.
Because of that, we needed to fix a bunch of stuff that we normally don't need to.
Also, the whole Registration thing (you need this number to use the Server repo and that number to install VT, etc.) we are by passing, as well as removing all the RHN bits.
Scientific Linux took a different approach (they released several of the upstream files that do not build on el5 ... and I think they build the fc6 files on fc6). We did not want that approach, as one of our goals is that the repo is self-hosting was well (meaning that it will completely build on itself). Not that the Scientific Linux approach is wrong, we thought about doing it that way too. But in the end, we wanted it self hosting and all built on el5.
Thanks, Johnny Hughes
On Wed, Feb 21, 2007 at 08:41:47PM -0600, Johnny Hughes wrote:
Many items are compiled against different kernel-headers, etc. Because of that, we needed to fix a bunch of stuff that we normally don't need to.
And thus provide a valuable service for upstream, because sooner or later they'll hit many of these same problems. And better that they're reported sooner.
On Wed, 21 Feb 2007, Johnny Hughes wrote:
On Wed, 2007-02-21 at 21:22 -0500, Tom Diehl wrote:
Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2007-02-20 at 10:21 -0500, Jerry Geis wrote:
So is beta 2 off - in favor of just waiting for the real RHEL5 release? RH has said it is ready to go and would be released in march. Hopefully march 1. HA!
More like March 15th (and don't hold your breath :P)
We will release a beta ... as we are close now at fixing everything.
Just out of couriosity, would you be willing to comment on the issues the CentOS team is running up against. Given upstream's decision to scrap the old way of spinning and distributing the distro I would imagine some of them are large problems.
Well ... the majority of our problems are coming from the fact that upstream did not build everything on the same builder. They grabbed .fc6 stuff as is and used it (not necessarily compiled on their el5 builder).
Many items are compiled against different kernel-headers, etc.
Because of that, we needed to fix a bunch of stuff that we normally don't need to.
Also, the whole Registration thing (you need this number to use the Server repo and that number to install VT, etc.) we are by passing, as well as removing all the RHN bits.
Scientific Linux took a different approach (they released several of the upstream files that do not build on el5 ... and I think they build the
I am hoping that they will be fixed in the final release. Did not want to have to fix things twice.
fc6 files on fc6). We did not want that approach, as one of our goals
Everything we built was built on RHEL 5 beta 2. Mostly in a mock chroot. If it did not build and it was easy for me to fix I just fixed it otherwise I borrowed the rpm from RHEL 5 beta 2. RHEL 5 beta 2 contained alot of .fc6 rpms, but the SRPMS provided had .el5 rpms. So I just put in the .el5 rpms as that was what was provided.
I just wanted to get something out and to get a head start are building SL 5.x , did not expect the "Very Alpha" of BETA2 to be a finished product. Guess I was going for the "release early" part of open source.
is that the repo is self-hosting was well (meaning that it will completely build on itself). Not that the Scientific Linux approach is wrong, we thought about doing it that way too. But in the end, we wanted it self hosting and all built on el5.
We expect self hosting too.
Thanks, Johnny Hughes
-Connie Sieh Scientific Linux Developer
On Thu, 2007-02-22 at 09:15 -0600, Connie Sieh wrote:
On Wed, 21 Feb 2007, Johnny Hughes wrote:
On Wed, 2007-02-21 at 21:22 -0500, Tom Diehl wrote:
Johnny Hughes mailing-lists@hughesjr.com wrote:
On Tue, 2007-02-20 at 10:21 -0500, Jerry Geis wrote:
So is beta 2 off - in favor of just waiting for the real RHEL5 release? RH has said it is ready to go and would be released in march. Hopefully march 1. HA!
More like March 15th (and don't hold your breath :P)
We will release a beta ... as we are close now at fixing everything.
Just out of couriosity, would you be willing to comment on the issues the CentOS team is running up against. Given upstream's decision to scrap the old way of spinning and distributing the distro I would imagine some of them are large problems.
Well ... the majority of our problems are coming from the fact that upstream did not build everything on the same builder. They grabbed .fc6 stuff as is and used it (not necessarily compiled on their el5 builder).
Many items are compiled against different kernel-headers, etc.
Because of that, we needed to fix a bunch of stuff that we normally don't need to.
Also, the whole Registration thing (you need this number to use the Server repo and that number to install VT, etc.) we are by passing, as well as removing all the RHN bits.
Scientific Linux took a different approach (they released several of the upstream files that do not build on el5 ... and I think they build the
I am hoping that they will be fixed in the final release. Did not want to have to fix things twice.
That is also very valid. We were also looking to create a buildsystem to automate more of our build process (with plague / mock) to help us get ready for the final release, as upstream is now building with dynamic chroots (like mock/plague ... called brew or brewbuild). As you guys probably already know, the BuildRequires are much better in the EL5 sources because of that.
fc6 files on fc6). We did not want that approach, as one of our goals
Everything we built was built on RHEL 5 beta 2. Mostly in a mock chroot. If it did not build and it was easy for me to fix I just fixed it otherwise I borrowed the rpm from RHEL 5 beta 2. RHEL 5 beta 2 contained alot of .fc6 rpms, but the SRPMS provided had .el5 rpms. So I just put in the .el5 rpms as that was what was provided.
I wasn't sure about the fc6 items (which is why I said "I think" :P ) and of course some of the upstream SRPMS had fc6 hard coded and others had %{?dist}, so it is hard to tell what is going on in that regard.
I just wanted to get something out and to get a head start are building SL 5.x , did not expect the "Very Alpha" of BETA2 to be a finished product. Guess I was going for the "release early" part of open source.
Thank you very much ... we looked at your RPMS and SRPMS as we were working and really appreciate all you do for the community. The SL 5 does look very good.
We did indeed look at those exact same issues (do a very fast release or take a longer approach and try to fix all the outstanding issues). Actually, since you did the first of those, it helped us decide that with two versions out there for people to see (SL and the original EL5B2), we could use the other approach and see if we could get most everything done before releasing.
is that the repo is self-hosting was well (meaning that it will completely build on itself). Not that the Scientific Linux approach is wrong, we thought about doing it that way too. But in the end, we wanted it self hosting and all built on el5.
We expect self hosting too.
Hopefully the final release sources will be much closer to being able to do that than the beta was :P
Thanks a lot, Johnny Hughes
Johnny Hughes wrote:
Well ... the majority of our problems are coming from the fact that upstream did not build everything on the same builder. They grabbed .fc6 stuff as is and used it (not necessarily compiled on their el5 builder).
Many items are compiled against different kernel-headers, etc.
Wow! Why did they do that? Anybody knows?
On Thu, Feb 22, 2007 at 10:15:09AM -0800, Florin Andrei wrote:
Well ... the majority of our problems are coming from the fact that upstream did not build everything on the same builder. They grabbed .fc6 stuff as is and used it (not necessarily compiled on their el5 builder). Many items are compiled against different kernel-headers, etc.
Wow! Why did they do that? Anybody knows?
Red Hat seems to have, for a long time, followed a policy of not rebuilding packages which have been through QA unless there is a reason to rebuild them. So, packages which were built against older headers stay that way until there's either a new package release or a problem.
On 2/22/07, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Feb 22, 2007 at 10:15:09AM -0800, Florin Andrei wrote:
Well ... the majority of our problems are coming from the fact that upstream did not build everything on the same builder. They grabbed .fc6 stuff as is and used it (not necessarily compiled on their el5 builder). Many items are compiled against different kernel-headers, etc.
Wow! Why did they do that? Anybody knows?
Red Hat seems to have, for a long time, followed a policy of not rebuilding packages which have been through QA unless there is a reason to rebuild them. So, packages which were built against older headers stay that way until there's either a new package release or a problem.
A rebuild is supposed to trigger a complete restart of the QA process so it was easier to do so.. especially after all the logging required for SOX and god-help-them-if-they-ISO-themselves.