Ken Moffat wrote: > On Thu, Aug 29, 2013 at 02:43:30PM -0500, Bruce Dubbs wrote: >> Ken Moffat wrote: >>> On Thu, Aug 29, 2013 at 10:02:41AM -0500, Bruce Dubbs wrote: >>>> >>>> OK, I'll do a -rc2 today. I think it best to slip the stable release to >>>> September 7. Should we update to the newer gettext, kbd, and/or kmod at >>>> the same time? Those all seem to have lower potential for problems than >>>> the glibc sed. >> >>> I'm not in favour of updating anything except glibc. >> >> I understand your point of view. Looking at things from a slightly >> different perspective, I don't use kbd at all. kmod is pretty much a >> non-issue for me because I really minimize modules. Right now on my >> development system, none are loaded. It will load SCSI_DEBUG when >> running util-linux tests. Looking at gettext, the release in the book >> is from June. From the latest release changelog: >> >> * windows/gettext.rc: Update copyright year. >> * NEWS: Mention libasprintf change and Tcl bug fix. >> >> That's it. >> >> The idea of including these is that there is a low probability of the >> newer packages causing problems and even if there are, the impact would >> be small. >> >> I will update to the latest kernel. We already say in the book to do >> that. >> >> Those are my observations. If we need to retest, testing everything at >> once would be easier. >> >> All that said, I'm willing to do what we collectively think best. >> >> -- Bruce > > Sorry it's taken me a while to reply, I've been doing a different > sort of tagging with metaflac. > > For kbd, I guess the most likely problem would be a > less-than-optimal set of instructions. As I noted in the ticket, > I'm undecided whether a separate libkbd.so is worthwhile or not > worthwhile. > > For kmod, I guess it works or it doesn't. NB we warn about running > the util-linux tests as root, but running as a user doesn't load the > SCSI_DEBUG module (I tested as a user on my i686, without enabling > that kernel option). > > Certainly, the gettext changes do sound harmless. > > OTOH the more we change for newer and shinier versions, the less > reason people have for respecting the -rc name.
But we are discussing -rc2, not a stable release. If we didn't have the glibc issue, I wouldn't be suggesting the other packages. > Are we going to keep the 7.4 tags showing 7.4 ? On the grounds > that whatever changes in -rc2 is _unlikely_ to break BLFS, I suppose > we could leave them. Unless someone finds a problem. I think the issue was that we were doing the tests for -rc1 and found the glibc error. -rc2 would continue to do the testing. We didn't find the issue until Fernando tried java on a i686. I could do a global sed and replace lfs74 with lfs74rc1 and then start all of BLFS over. 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? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
