Ken Moffat wrote: > On Thu, Aug 29, 2013 at 05:58:29PM -0500, Bruce Dubbs wrote: >> Ken Moffat wrote: >>> On Thu, Aug 29, 2013 at 04:37:53PM -0500, Bruce Dubbs wrote: >> >>>> Right now I'm thinking about a potential BLFS release in mid-October or >>>> early November. After 5 years, what's a month or two? >>>> >>> Yeah. I might even have upgraded my own server to 7.4 by then. >>> But to be honest, the sooner the better for cutting a BLFS release. >> >> I agree with that, but starting BLFS over loses two weeks of checks. >> There are only 9 open tickets right now that need to be addressed, but >> new packages are released pretty much every day. It seems we have been >> averaging about 2/day, counting weekends (12 in the last week).
> I'm not sure we're understanding each other. Perhaps it's another > example of "divided by a common language". > > Up until about 24 hours ago (give or take), 7.4-rc1 in BLFS looked > very good. There is no way I want to lose all that testing. I don't either. > If > anything new gets picked up now, I hope it will either be by someone > using LFS 7.4-rc, or else a package where the current version is > still tagged for 7.3 so that repeating a 7.3 tag won't cause much > likelihood of conflict. But I can't speak for what everyone else > with editorial privileges is using. I'm not sure of your meaning here. I'd hope package updates now are against 7.4-rc1 or later. The problem as I see it is that a critical package has to be changed. It's not a large change and if it were not in a package freeze situation, then it would not be a big deal. A package freeze for LFS is generally not much of a problem. There are only 62 packages and only a couple have changed in the last two weeks. It's also the case that the new packages that have shown up are in areas that are relatively isolated. The fact that glibc is where the current problem lies is a very different matter. It affects everything. I'm not sure the tests we made before changing that are completely valid. I suspect that they *are* valid, but I don't have a way of being sure. My point is if we need to retest for glibc, then we might as well do it for kmod and gettext and the kernel. A package freeze for BLS is a bigger deal in my opinion. With 750 packages (counting all the xorg packages separately), there will almost certainly be 20-30 new releases if we have a -rc freeze of two weeks. How do we manage that? One way might be to have a very short freeze period and go ahead and release with some packages still at 73_checked. I would like to have everything at least 74_built but we are resource limited. I have 354 packages (counting things like xorg libs one) as in my log for -rc1 right now and that's taken about 10 days. By my count, there are still about 200 packages still at lfs73. The good news is that we really are close to up-to-date. I have scripts for all the existing packages so rerunning for -rc2 should be relatively easy. It just that an update to version numbers in a package take a little more time, an update without change from -73 to -74 a little less and a recheck of one of the -74 tested packages even less. I'm going to build an 'enhanced' version of -rc1 (x86_64) with package updates tonight. We can see what that yields and go from there. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
