On Wed, Sep 14, 2005 at 11:53:48PM -0700, Jim Gifford wrote:
> Matt, one thing I think everyone here has forgot, what about cross-lfs.
> How will the change affect us.
If you have concerns, ideas, or comments, please post them.
--
Archaic
Want control, education, and security from your operati
Matt, one thing I think everyone here has forgot, what about cross-lfs.
How will the change affect us.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Tushar Teredesai wrote:
> On 9/14/05, Richard A Downing <[EMAIL PROTECTED]> wrote:
>
>>Sorry to go against everything my BLFS editorial colleagues have said,
>>but I rather like this proposal.
>>
>>I think it adds to the educational nature of both books.
>>
>>If a device exists and has no rule in
-snip lengthly messages-
Hi all,
I have been following this thread and I have a suggestion that I believe
to be a good compromise.
When installing the Udev package in LFS, add a file called 99default to
the /etc/udev/rules.d directory which basically just puts all the
devices in their defaul
Archaic wrote:
> And apparently your statement is also incorrect because ssh can
> properly create ptys all day long with the proper permissions. So
> apparently a closer look into both scenarios is warranted.
I didn't try ssh. But I did try xterm and expect (both of which use
PTYs), and both fai
On 9/14/05, Richard A Downing <[EMAIL PROTECTED]> wrote:
> Sorry to go against everything my BLFS editorial colleagues have said,
> but I rather like this proposal.
>
> I think it adds to the educational nature of both books.
>
> If a device exists and has no rule in the lfs set, then a node is
>
Archaic wrote:
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 statem
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
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
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
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
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
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
47 matches
Mail list logo