Preparing for 6.3 Release
dbn.lists at gmail.com
Mon Jun 11 07:12:11 PDT 2007
I want to just say out front what my opinion of the LiveCD is before I
respond to individual points. The most important task of the livecd is
to provide a host with a known working kernel and toolchain to allow
people to build *LFS. Next, it should provide tools that allow the
*LFS support channels to be reached. Everything else is a bonus and
should not determine whether a livecd release is made. IMO.
On 6/11/07, Alexander E. Patrakov <patrakov at ums.usu.ru> wrote:
> I wrote:
> > 1) Unclear status of wireless network support. The CD doesn't contain
> > wpa-supplicant and doesn't have firmware for most wireless network cards
> > (even though we qualify as ISV and thus can redistribute ipwXXXX firmware).
> > However, I can't test this because I don't have a wireless card.
I'd say don't bother. We don't even have a working wireless setup in
BLFS. I don't think it's asking people too much to plug in an ethernet
cable if they want to use the livecd. This would be a great feature,
but it shouldn't stop a release from being made.
> > 2) Incorrect contents of /etc/issue with the "toram" boot option. The
> > sources are intentionally not copied to RAM (so that one can use "toram" on
> > a 512M box), but the message still says they are available in /lfs-sources.
> > Since it is easy to add generation of the no-sources ISO, we may want to
> > cover this case, too.
"If you're using the toram option, you must remount the CD to use the
package tarballs in /lfs-sources."
I don't know if that's all that's correct. I didn't investigate when I
was using toram yesterday.
> > 3) Undocumented initramfs boot options. Maybe we should document things like
> > "noapic pci=noacpi", too.
That'd be nice. Is it possible to add more documentation pages to
isolinux? We could add options2.msg and add "F2 options2.msg" to
> > 4) It is necessary to add back the reiser4 and loop-aes kernel patches once
> > the kernel version in LFS stabilizes.
I suppose. I don't consider that high priority at all. If you're
depending on functionality that's not in the mainline kernel, then
it's a huge bonus if anyone supports you out of the box.
> > 5) I have updated the packages "blindly" too frequently. Many of them are
> > simply untested. Someone should go through _all_ of them and attempt to make
> > sure that the basic functionality is there.
Well, LFS-6.3 will put a test to that. It's not a problem if bugs are
found and a -2 release needs to be made. It seemed to work fine for
me, although I didn't do too much. Like I said above, the main two
tasks for me are the toolchain and the support tools. I hope the
toolchain is fine or LFS is in trouble, too. I played with seamonkey
and pidgin briefly. My network was setup fine out of the box, and I
was able to jump right onto the internet and irc. So, from my end, it
was working fine.
The only package I saw that I thought was borderline was
xf86-video-intel-2.0.0. You and I both read the xorg mailing list and
know that it's not stable yet. If you're curious, the G965 is
supported just fine in xf86-video-i180-1.7.4. I've been using it for
months. It doesn't have all the fancy functionality of intel-2.0.0
(but neither does the livecd since it's using libXrandr-1.1.2), but
it's working fine. What was the reason for updating to 2.0.0?
> 6) In Japanese locales, fontconfig chooses the wrong default font (AR PL New
> Sung, while it should use Kochi fonts)
Is there any way to change this in fonts.conf? It looks like you're
adding configuration for firefly, but not for kochi.
More information about the lfs-dev