Matthew Burgess wrote:
> Hi guys,
>
> Archaic and I have put our heads together to try and come up with a more
> reasonable set of Udev rules. These are based on the following criteria:
>
> 1) If a device needs packages outside those installed by LFS then don't
> include a rule for it. (e.g. aud
On Wed, Sep 14, 2005 at 01:23:25AM -0500, Randy McMurchy wrote:
>
> What does LFS gain by eliminating these groups and Udev rules?
I do not see it as what does {B,}LFS gain, but what do the readers gain?
An elaboration is in the post I just sent 60 seconds ago. :)
--
Archaic
Want control, educ
On Wed, Sep 14, 2005 at 01:09:31AM -0500, Randy McMurchy wrote:
>
> First of all Archaic, I would like to point out that your message
> was so perfectly stated that it really made me think about the big
> picture here. Well done, sir.
Thank you.
> The crux of the issue seems to be Gerard's desir
Archaic wrote these words on 09/14/05 00:41 CST:
> I do not think that if it is the
> main argument that it should have enough power to overrule the benefit.
But what is the benefit? I've asked this question now three times in
this thread and have yet to receive an answer.
What does LFS gain by e
Archaic wrote these words on 09/14/05 00:41 CST:
> Stepping in even later than you... :) While I didn't expect the first
> round proposal would be seen with much favor, I must point out the true
> impetus of this undertaking. None of the criteria Matt listed gives the
> "why" behind this, only the
On Tue, Sep 13, 2005 at 06:35:52PM -0400, Bryan Kadzban wrote:
> Matthew Burgess wrote:
> > ### RATIONALE FOR REMOVAL ### ptmx - isn't directly accessed by a
> > user. /etc/fstab dictates pty perms
>
> That's incorrect; this change would break PTYs completely.
And apparently your statement is als
On Tue, Sep 13, 2005 at 12:43:33PM -0700, Dan Nicholson wrote:
>
> I'm sorry if this has been suggested before and there's a major fault
> in it, but the above line only works if you have one cdrom installed.
> If you have multiple drives, only the last one gets the symlink. A
> very simple fix
On Tue, Sep 13, 2005 at 09:08:55PM +0200, M.Canales.es wrote:
>
> The network devices removal includes eth0 and like?
No. There was only one device listed. linux doesn't use a /dev device
for eth.
KERNEL="tun", NAME="net/%k"
--
Archaic
Want control, education, and security from your operatin
On Tue, Sep 13, 2005 at 10:09:48PM -0500, Bruce Dubbs wrote:
>
> I can understand the desire to remove rules for non-LFS targeted
> architectures, but have to disagree with the proposal to remove the
> entries for audio devices and other BLFS supported devices.
Stepping in even later than you...
Bruce Dubbs([EMAIL PROTECTED])@Wed, Sep 14, 2005 at 12:01:00AM -0500:
> Ag Hatzim wrote:
>
> > I always was under the impression,that there is some kind of interaction
> > between LFS/BLFS.
>
> We do have interaction. That was exactly the reason Matt made the post.
> He wanted to get the reac
Ag Hatzim wrote:
> I always was under the impression,that there is some kind of interaction
> between LFS/BLFS.
We do have interaction. That was exactly the reason Matt made the post.
He wanted to get the reaction of the LFS community. We do most things
publicly via the mailing lists.
The s
Jeremy Huntwork([EMAIL PROTECTED])@Tue, Sep 13, 2005 at 11:30:40PM -0400:
> Bruce Dubbs wrote:
> >
> >I strongly urge the criterion number one to read:
> >
> >1) If a device needs packages outside those installed by LFS or BLFS
> >then don't include a rule for it.
> >
> >BLFS assumes the user has a
Alexander E. Patrakov wrote:
No, it is not the same driver, because the UDMA line is missing. My
guess so far is:
Was wondering about that...
1) If the relevant IDE chipset driver is present in the kernel, locking
works.
2) If the generic IDE driver is used because the proper one is missing,
Jeremy Huntwork wrote:
Using the same driver, so must be a hardware specific thing. It's not a
very old machine either...
No, it is not the same driver, because the UDMA line is missing. My
guess so far is:
1) If the relevant IDE chipset driver is present in the kernel, locking
works.
2) If
On Tue, Sep 13, 2005 at 07:26:22PM +0100, Andrew Benton wrote:
>
> For what it's worth, this cdrom locks for mounted disks for me
Everything I tried it on locked.
--
Archaic
Want control, education, and security from your operating system?
Hardened Linux From Scratch
http://www.linuxfromscrat
Bruce Dubbs wrote:
I strongly urge the criterion number one to read:
1) If a device needs packages outside those installed by LFS or BLFS
then don't include a rule for it.
BLFS assumes the user has a base LFS system. Don't make a lot of work
for us for some exotic minimalism principle.
Agai
Matthew Burgess wrote:
> Hi guys,
>
> Archaic and I have put our heads together to try and come up with a more
> reasonable set of Udev rules. These are based on the following criteria:
>
> 1) If a device needs packages outside those installed by LFS then don't
> include a rule for it. (e.g. aud
Stephan wrote:
what says:
cat /proc/sys/dev/cdrom/lock
if theres a 1 then the lock at mount is enabled. if there is a 0 then lock
at mount is disabled.
you can enable this with:
echo 1 > /proc/sys/dev/cdrom/lock
or disable with:
echo 0 > /proc/sys/dev/cdrom/lock
i dont know if this is related t
On 9/14/05, steve crosby <[EMAIL PROTECTED]> wrote:
> Note also that editing the default ruleset supplied by LFS is not
> necessary - multiple rules files are perfectly acceptable, as long as
> the rules of precedence are considered.
Replying to myself ;)
Does it make sense to have *two* rule
Matthew Burgess wrote:
> ### RATIONALE FOR REMOVAL ### ptmx - isn't directly accessed by a
> user. /etc/fstab dictates pty perms
That's incorrect; this change would break PTYs completely.
In order to create a PTY, the master process opens /dev/ptmx. That's
the pseudo-terminal master file for eve
On 9/14/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> Archaic and I have put our heads together to try and come up with a more
> reasonable set of Udev rules. These are based on the following criteria:
>
Good work guys - tthanks for creating the initial ruleset.
>
> # /etc/u
Dom wrote:
> Got going, was all going well, and as I come to bunzip the
> libc-headers in the temporary system (yes, which is extremely early
> on in the process) and I ran out of space!
Have you been deleting the package build directories? (Are those even
on the same partition?) Are you buildin
Randy McMurchy wrote:
> Richard A Downing wrote these words on 09/13/05 15:00 CST:
>
>
>>I just got though building it on the GCC-4 system. It appears to work
>>well. (gtk+-2.8.3/glib-2.8.1/pango-1.10.0/atk-1.10.1/cairo-1.0.0)
>
>
> Probably should have moved to ATK-1.10.3 as this is what the
In the etc directory of the udev tarball there are rules that are used
by the distro's. Maybe we could use one of those instead???
([EMAIL PROTECTED])-(02:12 PM Tue Sep 13)-(/usr/src/udev-068/etc/udev)
# ls
debian frugalware gentoo redhat slackware suse udev.conf.in
udev-devfs.rules
--
Randy McMurchy wrote:
LFS installs the daemon, LFS starts the daemon and provides a
mechanism so that it is started and each boot. Folks that want to
learn about Udev should have already discovered that knowledge when
they installed it in LFS.
And everything is there for them to do that (now t
Matthew Burgess wrote these words on 09/13/05 15:47 CST:
> But how can *attempting to* correctly configure the devices when we
> don't install the software that exercises those nodes be a good thing?
> Surely one should configure the devices when one installs the software
> that uses them, just
Randy McMurchy wrote:
A Udev rules file sets up parameters to create device nodes if,
*and only if*, the hardware exists. The device nodes need to be
created if the hardware exists. A properly set up Udev rules file
ensures the device nodes are properly created.
Yes, but who's to say that the
Richard A Downing wrote these words on 09/13/05 15:00 CST:
> I just got though building it on the GCC-4 system. It appears to work
> well. (gtk+-2.8.3/glib-2.8.1/pango-1.10.0/atk-1.10.1/cairo-1.0.0)
Probably should have moved to ATK-1.10.3 as this is what the book
will be moving to.
--
Randy
Matthew Burgess wrote these words on 09/13/05 15:05 CST:
> Hmm, I'd equate that with telling folks to grab the blfs-bootscripts
> package and do a 'make install' (i.e. install every single bootscript,
> whether it's required or not).
No Matt, that is a bad analogy. Bootscripts run at boot time
Randy McMurchy wrote:
But for the BLFS devs to painstakingly
go through the book and try and figure out which ones of the almost
400 packages are going to need updates to add an entry to a rules
file, and instructions to restart udev is simply such a royal pain
in the ass.
I wasn't/we weren't e
Andrew Benton wrote:
As I understand it A==B is a test to see whether A is the same as B but
A=B means A will be assigned the same value as B
Yep, thanks for that, I can't believe I didn't spot those during my review!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linu
Randy McMurchy wrote:
> Hi all,
>
> Are we ready to move to the new GTK/Glib/Cairo/Pango/ATK stuff. I
> see that David has the GTK+ and Glib bugs spoken for, but I'll be
> adding Cairo to the book this weekend, and was wondering what the
> community thinks about moving forward.
>
> I'd like to ge
Hello
First, let me just brief you.
I would like to build a Linux distro that can be run on a low powered laptop
(233 MHz - 700 MHz.) But having no previous Linux distributions, I thought I
had best try and build a "normal" one first. So I had a go. I created a
virtual machine (using VMWare,) gav
Matthew Burgess wrote:
With that in mind, we'd appreciate feedback on the attached config file
especially if you've tested it "in the field" and found that we broke
something! Errors and omissions expected :)
As I understand it A==B is a test to see whether A is the same as B but A=B
means
Dan Nicholson wrote:
On 9/13/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
# Create the /dev/cdrom symlink.
BUS="ide", KERNEL="*[!0-9]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom",
NAME="%k", SYMLINK="cdrom"
I'm sorry if this has been suggested before and there's a major fault
i
On 9/13/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> # Create the /dev/cdrom symlink.
>
> BUS="ide", KERNEL="*[!0-9]", PROGRAM="/bin/cat /proc/ide/%k/media",
> RESULT="cdrom", NAME="%k", SYMLINK="cdrom"
I'm sorry if this has been suggested before and there's a major fault
in it, but the abov
Randy McMurchy wrote:
Matthew Burgess wrote these words on 09/13/05 14:05 CST:
Looking over the rules very briefly, I noticed that the comm devices
are not going to be defined. Did I interpret that correctly?
If so, I think it is a mistake. One couldn't even use his serial mouse.
Can you us
Jeremy Huntwork wrote these words on 09/13/05 14:22 CST:
> If that's the case, then I somewhat retract. However, I still feel that
> if you're going to do something, do it right the first time.
Yes. I should have stated in my earlier message that I believe a
*properly created* device node for an
On Tue, 13 Sep 2005, Matthew Burgess wrote:
Like I said in the original RFC, udev *will* still create nodes for *all*
device it finds, regardless of the existence or otherwise of a rule in its
configuration files. It just means that where a rule doesn't exist for the
device, it will be give
Matthew Burgess wrote:
Like I said in the original RFC, udev *will* still create nodes for
*all* device it finds, regardless of the existence or otherwise of a
rule in its configuration files. It just means that where a rule
doesn't exist for the device, it will be given the following
owners
Randy McMurchy wrote:
I don't see the payoff in the scheme. I suppose I still look at it
that whatever hardware may be installed on the machine should have
a device node (if appropriate) created for it at boot time, regardless
if there is software that can actually use it.
I more or less agre
Matthew Burgess wrote these words on 09/13/05 14:15 CST:
> Like I said in the original RFC, udev *will* still create nodes for
> *all* device it finds, regardless of the existence or otherwise of a
> rule in its configuration files. It just means that where a rule
> doesn't exist for the devic
Matthew Burgess wrote these words on 09/13/05 14:05 CST:
>>Looking over the rules very briefly, I noticed that the comm devices
>>are not going to be defined. Did I interpret that correctly?
>>
>>If so, I think it is a mistake. One couldn't even use his serial mouse.
>
> Can you use your mouse on
Randy McMurchy wrote:
I suppose I still look at it
that whatever hardware may be installed on the machine should have
a device node (if appropriate) created for it at boot time, regardless
if there is software that can actually use it.
Like I said in the original RFC, udev *will* still create n
El Martes, 13 de Septiembre de 2005 20:50, Matthew Burgess escribió:
> With that in mind, we'd appreciate feedback on the attached config file
> especially if you've tested it "in the field" and found that we broke
> something! Errors and omissions expected :)
The network devices removal include
Matthew Burgess wrote these words on 09/13/05 13:50 CST:
> Archaic and I have put our heads together to try and come up with a more
> reasonable set of Udev rules. These are based on the following criteria:
Looking over the new rules proposal further, I would like to go
on record as being again
Randy McMurchy wrote:
Looking over the rules very briefly, I noticed that the comm devices
are not going to be defined. Did I interpret that correctly?
If so, I think it is a mistake. One couldn't even use his serial mouse.
Can you use your mouse on a vanilla LFS box? I thought it required a
Matthew Burgess wrote these words on 09/13/05 13:50 CST:
> Archaic and I have put our heads together to try and come up with a more
> reasonable set of Udev rules. These are based on the following criteria:
Looking over the rules very briefly, I noticed that the comm devices
are not going to be
Hi guys,
Archaic and I have put our heads together to try and come up with a more
reasonable set of Udev rules. These are based on the following criteria:
1) If a device needs packages outside those installed by LFS then don't
include a rule for it. (e.g. audio devices)
2) If hardware is spe
Jeremy Huntwork wrote:
Here's a clip of dmesg from one that exhibits the behavior - the CD
ejects while the LiveCD is mounted and in use.
Using the same driver, so must be a hardware specific thing. It's not a
very old machine either...
--
JH
---
what says:
cat /proc/sys/dev/cdrom/lock
if theres a 1 then the lock at mount is enabled. if there is a 0 then lock
at mount is disabled.
you can enable this with:
echo 1 > /proc/sys/dev/cdrom/lock
or disable with:
echo 0 > /proc/sys/dev/cdrom/lock
i dont know if this is related to your behavior,
Jeremy Huntwork wrote:
Jeremy Huntwork wrote:
Like Archaic, I'll test the LiveCD on a few other PC's here at work
and report...
Here's a clip of the dmesg output on a PC that locked properly at work,
I'll try to do the same for the ones at home that showed the problem (or
if I find anoth
Jeremy Huntwork wrote:
Like Archaic, I'll test the LiveCD on a few other PC's here at work and
report...
Here's a clip of the dmesg output on a PC that locked properly at work,
I'll try to do the same for the ones at home that showed the problem (or
if I find another one here at work that d
Jeremy Huntwork wrote:
steve crosby wrote:
Some older CDROM drives don't fully support the standards - as such,
they ignore the "lock" command (amongst other more important ones!)
I assume by 'older' you mean very old. Both of these machines are fairly
recent. One, at the least, post-2000
steve crosby wrote:
Some older CDROM drives don't fully support the standards - as such,
they ignore the "lock" command (amongst other more important ones!)
I assume by 'older' you mean very old. Both of these machines are fairly
recent. One, at the least, post-2000 and the other probably c
On 9/13/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Hey Everyone:
>
> I've run across something that I'm pretty sure isn't supposed to happen.
> On two different systems, when I have a CD mounted, I have been able to
> push the eject button and eject the CD. This has happened on both my
Some
Hey Everyone:
I've run across something that I'm pretty sure isn't supposed to happen.
On two different systems, when I have a CD mounted, I have been able to
push the eject button and eject the CD. This has happened on both my
installed LFS system and when using the LiveCD. With the LiveCD
e
57 matches
Mail list logo
