On 1.3.2014 23:44, Bruce Dubbs wrote: > Pierre Labastie wrote: >> Le 01/03/2014 22:58, Bruce Dubbs a écrit : >>> Pierre Labastie wrote: >>>> Le 28/02/2014 23:24, Bruce Dubbs a écrit : >>> >>>> Now, I have a question. I have never been involved in development, so just >>>> take my question as a mark of curiosity: what is the reason to expect >>>> release >>>> of LFS and BLFS to be close in time? I would think of something like: >>>> >>>> - LFS rc1 (duration: a few weeks, unless there is a need for rc2): >>>> - freeze packages on LFS >>>> - extensive testing of LFS build; correct security issues and blockers >>>> - update BLFS svn as usual >>>> - LFS stable, BLFS test against LFS (duration: a month or so): >>>> - restart updating LFS svn >>>> - stop testing/updating BLFS against the previous LFS release >>>> - begin building/updating/tagging BLFS against the recent LFS release >>>> - BLFS rc1 (duration: a few weeks + possibly rc2,3...): >>>> - freeze packages on BLFS. >>>> - extensive testing of BLFS build; correct security issues and >>>> blockers >>>> - tag untagged packages >>>> - BLFS stable >>>> >>>> What I see as an advantage is that during the LFS rc stage, it is still >>>> possible to change a few things on LFS, without risk to break already >>>> tagged >>>> pacakges in BLFS. But there may be drawbacks I do not see... >>> >>> The problem is that upstream changes packages very often and it takes >>> time to check BLFS. We did a package freeze two weeks ago and LFS has >>> had 7 packages update. BLFS has had about 40 update in the same time. >>> If we update a library, then what does that say about the testing of >>> packages that may need that library but have already been tested? >>> >>> For many years, we didn't release a 'stable' BLFS at all. We just used >>> a rolling release. We've got some more help now, so the freeze time is >>> relatively short. >>> >>> Testing the LFS build is actually fairly quick. With alfs and skipping >>> checks, we can do it in a couple of hours. The real test is whether >>> BLFS builds on it. Unfortunately, as you know, it's difficult to >>> automate BLFS. >>> >>> It's all a tradeoff. We are almost ready. The only things left right >>> now are fretts, gnash, and sendmail. >>> >> >> Yeah, I have seen that this morning, only two packages left, it is >> incredible! >> + sendmail in archive. I feel bad I have done such a small part, and you have >> done a wonderful job. >> >> I cannot test any multimedia app (no sound). >> >> I can have a look at sendmail, if nobody is working on it (tomorrow... it is >> late here). > > I've just started sendmail. Actually I'm most interested in getting the > slackware issue settled for LFS. That's our only holdup for release. > > -- Bruce
Why should we care when it's a distribution issue? Every "sane" distro works just fine except slackware. So let them fix it instead of us. An errata entry should be fine. The other solution is to "rm $(grep -rl libgmp.la /usr/lib*/)" since the issue seems to come from another .la file which seems to pull libgmp.la, but the latter one isn't arround. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
