Matthew Burgess wrote:
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
3) Linux-2.6.15 is used, which means that some deices (e.g., IDE
CD-ROMs and input devices) won't get modaliases or won't generate
uevents properly.
There is already a note in the book
Bruce Dubbs wrote:
Chris Staub wrote:
The BLFS Xorg instructions compile lndir and copy it to /usr/bin before
compiling X.
And every package in *LFS compile programs and copy them to their final
positions. What's your point?
-- Bruce
Well, you were asking where the "2nd copy" of lndir
Chris Staub wrote:
> The BLFS Xorg instructions compile lndir and copy it to /usr/bin before
> compiling X.
And every package in *LFS compile programs and copy them to their final
positions. What's your point?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www
Greg Schafer wrote:
> Matthew Burgess wrote:
>
>
>>As regards to LFS unstable living up to its name, that's probably
>>because we chose the right name for it, i.e. we don't try and pretend
>>that it's something it isn't. I don't see why you thought a :-( was
>>necessary. Yes, testing could h
Tim van der Molen wrote:
> As Xorg 6.9.0 (I don't know about 6.8.2 and 7.0) and XFree86 4.5.0
> install a copy of lndir to /usr/X11R6/bin, is there a reason why we keep
> the one in /usr/bin?
6.8.2, yes. 7.0 no.
Why not keep it in /usr/bin? It is a general purpose program.
-- Bruce
--
http:/
Matthew Burgess wrote:
> As regards to LFS unstable living up to its name, that's probably
> because we chose the right name for it, i.e. we don't try and pretend
> that it's something it isn't. I don't see why you thought a :-( was
> necessary. Yes, testing could have been more thorough, but
On 2/23/06, Tushar Teredesai <[EMAIL PROTECTED]> wrote:
> On 2/23/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
> > Sigh.. even tho' jhalfs provides the facility to prevent this kind of
> > damage, LFS unstable is still living up to its name :-(
>
> Isn't that the point of having a revision control s
On 2/23/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Sigh.. even tho' jhalfs provides the facility to prevent this kind of
> damage, LFS unstable is still living up to its name :-(
Isn't that the point of having a revision control system and an unstable branch?
--
Tushar Teredesai
mailto:[EMA
Greg Schafer wrote:
matthew wrote:
Author: matthew
Date: 2006-02-21 13:50:22 -0700 (Tue, 21 Feb 2006)
New Revision: 7392
Modified:
trunk/BOOK/chapter01/changelog.xml
trunk/BOOK/chapter03/patches.xml
trunk/BOOK/patches.ent
Log:
Add Bash patches 009 and 010 from upstream
Matt, patch 01
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
For those of you who are still patient enough to test the udev_update
branch out, please find an updated Udev rules file at
http://www.linuxfromscratch.org/~matthew/pub/. I think it corrects all
the problems Alexander pointed out.
Tha
matthew wrote:
> Author: matthew
> Date: 2006-02-21 13:50:22 -0700 (Tue, 21 Feb 2006)
> New Revision: 7392
>
> Modified:
>trunk/BOOK/chapter01/changelog.xml
>trunk/BOOK/chapter03/patches.xml
>trunk/BOOK/patches.ent
> Log:
> Add Bash patches 009 and 010 from upstream
Matt, patch 010 b
Alexander E. Patrakov wrote:
For those of you who are still patient enough to test the udev_update
branch out, please find an updated Udev rules file at
http://www.linuxfromscratch.org/~matthew/pub/. I think it corrects all
the problems Alexander pointed out.
Regards,
Matt.
--
http://lin
Matthew Burgess wrote:
> Andrew Benton wrote:
>
>> With the udev_update branch nothing loads the uhci-hcd module.
>
> Thanks. Alexander, do you know if this is one of those problematic
> drivers that has since been fixed up in 2.6.16-rc4?
I doubt it; the kernel source for 2.6.15.3 has somethin
Bryan Kadzban wrote:
3) 'Quoted-printable' will avoid failing in the case of a non-ASCII
character. It'll still be mostly readable without a mail client, though
(because most characters are 7-bit ASCII) -- IMO, that's the best of both
worlds.
I would also say that viewability with Vim is "nice
Andrew Benton wrote:
With the udev_update branch nothing loads the uhci-hcd module.
Thanks. Alexander, do you know if this is one of those problematic
drivers that has since been fixed up in 2.6.16-rc4?
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.
Richard A Downing wrote:
Bryan Kadzban wrote:
ACTION=="add", SUBSYSTEM=="?*" MODALIAS=="?*", RUN+="/sbin/modprobe
${modalias}"
Thanks Brian. I understood that. Unfortunately changing the rules
didn't fix my problem. Nothing loads the modules. So I guess I must
have a typo somewhere else.
nadav vinik wrote:
But I didn't find any page in the website which include open and
critical bugs of the development lfs and blfs.
All of our bugs are available on the 'Trac' system. For the particular
information you want, see http://wiki.linuxfromscratch.org/lfs/report/1
and http://wiki.l
Chris Staub wrote:
The /dev/shm mount point for tmpfs is included to allow enabling
POSIX-shared memory. The kernel must have the required support built
into it for this to work (more about this is in the next section).
IMO, the second sentence is redundant as tmpfs support is also required
On Thu, Feb 23, 2006 at 11:20:02AM -0500, Jeremy Huntwork wrote:
> >If the text is not US-ASCII and the content-transfer-encoding is
> >quoted-printable, all non-ASCII bytes are converted to the "=XY"
> >notation, where X and Y are hex digits. ASCII pats of the message are
> >readable with vim t
I wouldn't like that as well. It makes it harder to write rules to sort
the email if info is in different headers. I would prefer to have the
subproject abbreviation in the Subject: header.
Why couldn't you filter on the From: header if it ends up containing the
subproject's name? To include
Gerard Beekmans wrote:
> That's not to say it always has to be that way. I personally have no
> real preference using something like [LFS Ticket #number] or [LFS
> #number]. I would keep the # symbol in it.
My preference would be [?LFS $number].
> Tickets are sent as From: Linux From Scratch
>
Matthew Burgess wrote:
11) The deprecated udev_run_hotplugd helper is needed for
compatibility with BLFS (look at HAL).
>>> Why? I thought Kay was actively helping the HAL guys out? Why has
>>> he caused it to break by deprecating the udev_run_hotplugd helper?
>> That's just obsolete
kevin lyda wrote:
I think what was meant was this (this is a cut and paste of mutt's index
pane):
3 N 23/02.15:52 BLFS Trac #45: Gnome 'sploded lots and scared my kitt
4 N 23/02.11:17 LFS Trac#12: Thingy go boom
5 N 23/02.11:16 LFS Trac#1: It no workee unless
kevin lyda wrote:
3 N 23/02.15:52 BLFS Trac #45: Gnome 'sploded lots and scared my kitt
4 N 23/02.11:17 LFS Trac#12: Thingy go boom
5 N 23/02.11:16 LFS Trac#1: It no workee unless the thingamugug is
6 N 23/02.10:45 Jeremy Huntwork +->
7 N 23/02.08:34
On Thu, Feb 23, 2006 at 08:34:11AM -0700, Gerard Beekmans wrote:
> >If we did what you suggest above, the Subject would be (I think):
> >
> >[LFS Trac] #number: Summary
>
> Close enough for me.
I think what was meant was this (this is a cut and paste of mutt's index
pane):
3 N 23/02.15:52 B
Alexander E. Patrakov wrote:
If the text is not US-ASCII and the content-transfer-encoding is
quoted-printable, all non-ASCII bytes are converted to the "=XY"
notation, where X and Y are hex digits. ASCII pats of the message are
readable with vim this way, but non-ASCII requires Mutt. If viewa
On Thu, 23 Feb 2006, Alexander E. Patrakov wrote:
The "iseries" rules in our file are also useless on anything other
than s390 boxes.
Wearing my pedant's hat for the moment, iSeries != s390 (I believe
iSeries is POWER, or it might be ppc64). I know somebody did LFS on
s390 a while ago,
Gerard Beekmans wrote:
[LFS Trac] #number: Summary
Close enough for me.
Alright. I'll test a couple of changes...
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Indeed. You have to keep in mind how Trac parses its config files, what
variables are available. Some of the suggestions put forth so far I'm
sure are possible, but would take some serious hacking of Trac or the
creation of our own Python plugin for Trac.
Any "serious hacking" seems a bit sill
Gerard Beekmans wrote:
Judging by the lack of responses (okay, granted, not much time has gone
by yet) nobody really cares either way. How about we take a step back
for a minute and figure out *how* to change Trac.
Indeed. You have to keep in mind how Trac parses its config files, what
variab
On 2/23/06, Nico R. <[EMAIL PROTECTED]> wrote:
>
> What about the following?
> [LFS #1234] Useful subject lines
> [BLFS #] Handle ticket numbers with 5 digits or more
> [CLFS #4711] New build method
I like this the best. Combined with the From: field, I wouldn't have
a problem figuring
I started to install LFS 6.1.1 and before I pass to the real
installation in section III, I want to know what is the state of the
development, maybe I should to start again since the stabe is a little
old.
But I didn't find any page in the website which include open and critical bugs of the develop
Nico R. wrote:
We all know that it is about tickets, so we could drop that.
Always keep in mind, though, there's more people than us. If we make
things clearer by adding a word or two, it's not always a bad thing.
It's even more grammatically correct.
That's not to say it always has to be t
On Thu, 23 Feb 2006, Alexander E. Patrakov wrote:
The "iseries" rules in our file are also useless on anything other than s390
boxes.
Wearing my pedant's hat for the moment, iSeries != s390 (I believe
iSeries is POWER, or it might be ppc64). I know somebody did LFS on
s390 a while ago, but
Gerard Beekmans wrote:
> It can be made more clear. And is the project name truly necessary in
> the Subject header. We already know which project a ticket belongs to
> based on the mailinglist it was sent to (this of course is me assuming
> most everybody uses separate email folders to filter emai
Alexander E. Patrakov wrote:
[...]
>
> If the text is not US-ASCII and the content-transfer-encoding is
> quoted-printable, all non-ASCII bytes are converted to the "=XY"
> notation, where X and Y are hex digits. ASCII pats of the message are
> readable with vim this way,
[...]
So quoted-printabl
36 matches
Mail list logo
