Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
The udev_retry initscript should run after mountfs
and re-trigger the failed uevents in hope that they won't fail again.
I really don't think this is necessary.
Think about ALSA: alsactl is in /usr/sbin. B
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
2) There is no "udev_retry" initscript. The idea is that, if a program
specified in the "RUN" rule exits with nonzero status (presumably
because it needs /usr), udev places a symlink into /dev/.udev/failed.
The udev_retry initscript should
Jeremy Utley wrote:
As indicated by the email from Greg earlier, we do create /dev/shm as
a directory during the install process. However, mounting a tmpfs
filesystem there to allow POSIX shared memory support is an optional,
although recommended and default, thing to do.
There's actually some
Dan Nicholson wrote:
> I don't know much about the subject either, Chris. Here's the thread
> for the original flame war that resulted in that wording, though:
>
> http://linuxfromscratch.org/pipermail/lfs-dev/2003-October/039106.html
>
> Maybe someone who understands the uses of SysV shared me
On 2/22/06, Chris Staub <[EMAIL PROTECTED]> wrote:
>
> I don't really know much of anything about the subject myself, but it
> seems strange that it says /dev/shm is "optional" when it's described as
> required during the LFS system build. Is that paragraph simply out-of-date?
I don't know much ab
In the "Creating /etc/fstab" section, there is this paragraph:
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).
Please note that very little s
In the "Creating /etc/fstab" section, there is this paragraph:
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).
Please note that very little s
On 2/22/06, Bob Winckelmans <[EMAIL PROTECTED]> wrote:
> My bad,
>
> I had seen
>
> >"[jhuntwork] - Adjust binutils-pass1 so we don't need to hang on to its
> >source directories..
>
> in the changelog... and I was under the (wrong) impression that those where no
> longer necessary. I missed the c
My bad,
I had seen
>"[jhuntwork] - Adjust binutils-pass1 so we don't need to hang on to its
>source directories..
in the changelog... and I was under the (wrong) impression that those where no
longer necessary. I missed the cp command, and thought that the commands no
longer mattered becaus
On 2/22/06, Bob Winckelmans <[EMAIL PROTECTED]> wrote:
> 5.3. Binutils-2.16.1 - Pass 1
>
> At the bottom, the
>
> >Next, prepare the linker for the "Adjusting" phase later on:
> > make -C ld clean
> > make -C ld LIB_PATH=/tools/lib
> > cp -v ld/ld-new /tools/bin
>
> is no longer necessary I believe
Thanks for the hint, I will have a look at it.
William Zhou
Dan Nicholson wrote:
On 2/21/06, William Zhou <[EMAIL PROTECTED]> wrote:
The configuration switch --with-local-prefix seems to be redundant in
GCC package.
But after searching through the whole config script, it seems
# Adjusting the Toolchain
# Tcl-8.4.12
# Expect-5.43.0
# DejaGNU-1.4.4
# GCC-4.0.2 - Pass 2
# Binutils-2.16.1 - Pass 2
Between toolchain adjustment and the 2nd pass of binutils, there are
five packages including binutils itself get complied. If the ld were not
replaced, it would search librari
Bob Winckelmans wrote:
5.3. Binutils-2.16.1 - Pass 1
At the bottom, the
Next, prepare the linker for the “Adjusting” phase later on:
make -C ld clean
make -C ld LIB_PATH=/tools/lib
cp -v ld/ld-new /tools/bin
is no longer necessary I believe,
Kind regards,
Bob
Huh? Why is it "not necessary
5.3. Binutils-2.16.1 - Pass 1
At the bottom, the
>Next, prepare the linker for the “Adjusting” phase later on:
> make -C ld clean
> make -C ld LIB_PATH=/tools/lib
> cp -v ld/ld-new /tools/bin
is no longer necessary I believe,
Kind regards,
Bob
--
http://linuxfromscratch.org/mailman/listinfo/lfs
On 2/22/06, Alexander E. Patrakov <[EMAIL PROTECTED]> 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. The solution is to upgrade to linux-2.6.16-rc4 or to say that
> the bug exists and
Alexander E. Patrakov wrote:
Below is the incomplete list of things done wrong or incompletely in the
udev_update branch. Here "wrong" doesn't include upstream faults.
Thanks very much for the report Alexander.
1) Udev bootscript doesn't wait for uevents to be fully processed.
OK, I'll add
Gerard Beekmans wrote:
Jeremy Huntwork wrote:
The upstream keyword would certainly work. If Matt would like, you
could also add either a new ticket type or a new component to reflect
that the problem lies upstream. There's several ways to skin this cat. :)
And think about a scenario like thi
Gerard Beekmans wrote:
> Jeremy Huntwork wrote:
>
>> The upstream keyword would certainly work. If Matt would like, you
>> could also add either a new ticket type or a new component to reflect
>> that the problem lies upstream. There's several ways to skin this cat. :)
>
>
> And think about a sc
Nico R. wrote:
> You all may think that these two points are very minor (and you are
> probably right), but right now, I find them to be highly annoying. :-|
No problem. The suggestion to look at these issues is reasonable.
We'll see what we can do.
-- Bruce
--
http://linuxfromscratch.org/ma
[EMAIL PROTECTED] wrote:
> Bruce, I'll be doing X7 day after tomorrow
> now...just didn't have time to get to it tonight.
That's great. Please take a look at tickets 1298, 1463, 1770, and 1319
also and see if what you are doing can address them.
-- Bruce
--
http://linuxfromscratch.org/mailma
> Microsoft Corporation napisa?(a):
> > This mail has been sent to all windows users.
> > This is our last update that must be to all windows users. We Are Changing
> > too many things.
> > This file need to be in your computer for your security.
> > Our Sponsor SpeedyShare.Com uploaded it.
> > Qi
R.Quenett wrote:
So, *if* it's a benefit to put it in at all, why not _post_pend it
instead of _pre_pend it, ie
Summary here [LFS Ticket #abc]
To be honest, it looks odd. Also if a subject line is truncated in an
email program due to space constraints, [LFS Ticket] may not appear.
Only see
on Wednesday, February 22, 2006 at 7:56 Gerard Beekmans wrote:
" Maybe a change that combines both and use the old Bugzilla Subject method:
"
" [LFS Ticket #abc] Summary here
" [BLFS Ticket #def] Summary here
" and so forth.
If I may suggest, the stuff in the square brackets
Gerard Beekmans wrote:
What happens in cases where text is *not* US-ASCII and still sent with
the content-transfer-encoding set to quoted-printable? Maybe nothing
happens. I admit to knowing next to nothing about character sets in this
way.
If the text is not US-ASCII and the content-transfe
Gerard Beekmans wrote:
What happens in cases where text is *not* US-ASCII and still sent with
the content-transfer-encoding set to quoted-printable? Maybe nothing
happens. I admit to knowing next to nothing about character sets in this
way.
It is perfectly legal to set content-transfer-encod
Gerard Beekmans wrote:
Nico R. wrote:
This is unfortunate, because when the subject can't be displayed
completely by the mail reader, most messages look pretty much the same
to me, example when there are replies to them:
"Re: [Linux From Scratch] #1715: bas..."
I suggest changing the subject pr
Jeremy Huntwork wrote:
The upstream keyword would certainly work. If Matt would like, you could
also add either a new ticket type or a new component to reflect that the
problem lies upstream. There's several ways to skin this cat. :)
And think about a scenario like this one: What do we do then
Nico R. wrote:
This is unfortunate, because when the subject can't be displayed
completely by the mail reader, most messages look pretty much the same
to me, example when there are replies to them:
"Re: [Linux From Scratch] #1715: bas..."
I suggest changing the subject prefixes to LFS, BLFS, ALF
Alexander E. Patrakov wrote:
Hello,
right now, both upstream bugs and LFS-specific issues would show up as
"defects" in Trac. I would like to view them separately. Is it OK for me
in the future to add the "upstream" keyword to bugs that are not
LFS-specific? Or is some other way of marking su
Hello,
right now, both upstream bugs and LFS-specific issues would show up as
"defects" in Trac. I would like to view them separately. Is it OK for me
in the future to add the "upstream" keyword to bugs that are not
LFS-specific? Or is some other way of marking such issues actually
preferred?
I noticed two things in the many mails I'm receiving from the Trac
ticket system:
1. The subject lines always start with the full project name in square
brackets and the ticket number.
Example subject: "[Linux From Scratch] #1715: bash-3.1.010".
This is unfortunate, because when the subject can't
I wrote:
1) Udev bootscript doesn't wait for uevents to be fully processed.
Upstream recommends the following shell snippet for this purpose:
loop=300
while test -d /dev/.udev/queue; do
sleep 0.1
test "$loop" -gt 0 || break
loop=$(($loop - 1))
Below is the incomplete list of things done wrong or incompletely in the
udev_update branch. Here "wrong" doesn't include upstream faults.
1) Udev bootscript doesn't wait for uevents to be fully processed.
Upstream recommends the following shell snippet for this purpose:
loop=300
Matthew Burgess <[EMAIL PROTECTED]> writes:
> Dan Nicholson wrote:
>
>> So, am I to gather from Matt and DJ that udevstart won't work
>> correctly from udev-084? Or just that it's not installed by default?
>
after I did "/etc/rc.d/init.d/udev start" in chroot I have ruined the host
system by some
34 matches
Mail list logo
