[blfs-dev] glibc errors in blfs packages on i686
bruce.dubbs at gmail.com
Thu Aug 29 17:29:16 PDT 2013
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.
> 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.
More information about the blfs-dev