ken at linuxfromscratch.org
Sun Nov 27 16:22:02 PST 2005
On Sun, 27 Nov 2005, Jim Gifford wrote:
>> The bad news is that alsamixer is broken in cross-lfs-1 (the devices
>> starting at controlCn are missing), at least if sound is compiled into the
>> kernel (haven't tested modules). The config-5 works correctly for me (with
> That's BLFS and not CLFS, but that will change with what I have in the works
Meanwhile, we are supposed to waste everybody's time with partial
rules? Or are you suggesting that CLFS should not be a valid platform
for building BLFS packages, and therefore each of our builders should
reinvent the wheel when they build the applications they need ? I know
there have been suggestions that alsa devices should move to a separate
rules file, but lfs-svn hasn't done that yet so I fail to see what
benefit there is for CLFS in not only ignoring some of the devices, but
in not providing a separate rules file to create them for people who
We're an official LFS project, where is the benefit in forging a
separate path for udev rules ? And doesn't development happen on the
>> I can see there might be reasons to use our own rules, e.g. if lfs-svn
>> dropped devices that aren't found on x86, but at the moment the regular lfs
>> rules support iSeries devices and dasd (s390) so I think there is no reason
>> to maintain our own rules.
>> Anybody think we ought to maintain our own rules ? If so, which devices
>> do you need that aren't supported by the regular lfs rules ?
> We are going to have our own support packages for udev.
As part of the udev tarball ? If so, how is CLFS different from LFS,
which is happily using its own rules file ? And I repeat, what devices
do we need to support that aren't in the current LFS rules ? Or if not
as apart of the udev tarball, what is the point of extra packages ?
das eine Mal als Tragödie, das andere Mal als Farce
More information about the cross-lfs