Hello,
LFS-related patches that are used in the utf8 branch of the Live CD are
available at:
http://www.linxfromscratch.org/~alexander/patches/
Please review them for inclusion into the book (preferrably utf8-only
patches should not go into the trunk, but into a separate utf8 branch).
Details
Matthew Burgess wrote:
> Now, if we can simplify gcc4's SPECFILE assignment, that's great.
Um, the suggestion was to use the correctly documented switch, not to go
and completely redo the specs handling :-) Of course, you can do that if
you want to. I've done exactly that for the DIY build ie: d
On Sun, Aug 14, 2005 at 08:07:07PM +0100, Matthew Burgess wrote:
>
> Firstly, I think we could expand on what we mean by "proper locations" -
> i.e. what makes us use /bin instead of /usr/bin? I can think of 2
> reasons: i) FHS and ii) Bootscript requirements for scripts run before
> /usr is m
Matthew Burgess wrote:
I don't think all device subsystems are udev-compatible at the moment
(the 'input' subsystem rings a bell here). Additionally, I don't think
we handle 'coldplug' events correctly, somewhat ironically, without the
'hotplug' scripts around. Alexander will no doubt correct
On 8/16/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> steve crosby wrote:
>
> > The patch needs a proper LFS header applied and sending upstream
> > (hint, hint, nudge, nudge). Tested here on udev-067 without issue.
>
> Hmm, this is the second patch you've attached (and Randy sent a
> similarl
On 8/16/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote:
>
> > GCC-3.x appears to support -dumpspecs
>
> Obviously (now I've read the two books!), that won't tell us where the
> specs file lives, which is what we need to know! For a clearer
Why do we need to know? we can
Andrew Benton wrote:
so do we need the hotplug scripts? Will they
ever be used for anything? Is it ever called?
I don't think all device subsystems are udev-compatible at the moment
(the 'input' subsystem rings a bell here). Additionally, I don't think
we handle 'coldplug' events correctly,
The version of udev we have in the development version of the book (udev 063)
sets itself as the default hotplug event handler (cat /proc/sys/kernel/hotplug)
so do we need the hotplug scripts? Will they ever be used for anything? Is it
ever called?
--
http://linuxfromscratch.org/mailman/listinf
steve crosby wrote:
The patch needs a proper LFS header applied and sending upstream
(hint, hint, nudge, nudge). Tested here on udev-067 without issue.
Thanks very much Steve. I just submitted it after re-diffing; even with
Bruce's changes it wouldn't apply. Here's hoping I didn't screw the
David Fix wrote:
Yes to WARN. :)
+1 for this
James
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Matthew Burgess wrote:
> steve crosby wrote:
>
>> The patch needs a proper LFS header applied and sending upstream
>> (hint, hint, nudge, nudge). Tested here on udev-067 without issue.
>
> Hmm, this is the second patch you've attached (and Randy sent a
> similarly affected one too) that fails to
Bruce Dubbs wrote these words on 08/15/05 13:55 CST:
> How about:
>
> "To test the results, issue: make check. Note that the “torture
> load testing” option uses more resources than is displayed in the
> prompt."
I like this much better. However, I still think the s/is/those/ is
necessary to mat
steve crosby wrote:
The patch needs a proper LFS header applied and sending upstream
(hint, hint, nudge, nudge). Tested here on udev-067 without issue.
Hmm, this is the second patch you've attached (and Randy sent a
similarly affected one too) that fails to apply cleanly. Vim seems to
think
Bruce Dubbs wrote these words on 08/15/05 12:38 CST:
> Should I call the package cm-super and put it into the A-C directory on
> anduin, just go ahead and put it into the T-V directory with the rest of
> tetex, or rename the package to tetex-cm-super?
I like tetex-cm-super. That way everything is
I am finally getting to this bug that is almost two years old!
To fix the issue, we need to install a set of fonts called cm-super.
Now the tex way of doing things is a bit non-standard. The cm-super
package is generaated on-the-fly when downloaded. What I have done is
created the font .bz2 file
Matthew Burgess wrote:
GCC-3.x appears to support -dumpspecs
Obviously (now I've read the two books!), that won't tell us where the
specs file lives, which is what we need to know! For a clearer
comparison of the two books, here's the relevant snippets:
gcc4:
SPECFILE=`gcc -print-search-
Greg Schafer wrote:
Hi
During the toolchain adjustments, LFS does stuff like this:
gcc --print-file specs
IMHO the usage is bogus because:
1) `--print-file' is undocumented (therefore could break anytime)
2) `--print-file' only works by pure good fortune.
GCC-3.x appears to support -
Alexander E. Patrakov wrote:
Hello,
Bison has been removed from Chapter 5 recently. This prevents me from
fixing a Coreutils bug with the following patch:
I agree with Jim here. Adding bison back into chapter 5 seems overkill
for such a minor issue. We've already set a precedent with 'flex
Doug Ronne wrote these words on 08/15/05 11:19 CST:
> Oops, right you are. Though shouldn't it say ignore this if you do
> NOT want the threading man pages?
Please don't top-post, and perhaps consider trimming your quoted text.
Anyway, there are many things in the LFS book which folks could ignor
On Mon, Aug 15, 2005 at 06:24:50PM +0600, Alexander E. Patrakov wrote:
> Bryan Kadzban wrote:
> >Depending on the developers' version of autoheader, it might be possible
> >to fix this by just running it on either configure.ac or configure.in
> >(for the packages that still use the old filename).
>
Oops, right you are. Though shouldn't it say ignore this if you do
NOT want the threading man pages?
-Doug
On 8/15/05, Jim Gifford <[EMAIL PROTECTED]> wrote:
> Doug Ronne wrote:
>
> >The instructions in 10.4. Glibc-2.3.5 64-Bit in the cross-lfs
> >multilib x86_64 book are missing the part wher
Alex looking at this patch, it just forces setting of the seconds to be
set to 0. I just think this is overkill to add to the coreutils build,
since it's very minor issue. The only thing it affects is the setting of
the date, but it someone wants to enter the seconds, in it will force it
to 0.
Doug Ronne wrote:
The instructions in 10.4. Glibc-2.3.5 64-Bit in the cross-lfs
multilib x86_64 book are missing the part where you unpack the
glibc-linuxthreads.tar.bz2.
-Doug
It's there Doug right above.
make -C ../glibc-2.3.5/linuxthreads/man
--
--
[EMAIL PROTECTED]
[EMAIL PROTE
The instructions in 10.4. Glibc-2.3.5 64-Bit in the cross-lfs
multilib x86_64 book are missing the part where you unpack the
glibc-linuxthreads.tar.bz2.
-Doug
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information p
> Is that yes - I'd like to see a nice green '[ OK ]' when I stop an
> already stopped process (the way it is now, which _is_ correct by the
> exit status)? Or is that yes - I'd like to see a yellow 'Warning: not
> running [ WARN ]' when I stop it (which also returns 0 as is
> required for L
Bryan Kadzban wrote:
Alexander E. Patrakov wrote:
The two cases (forgotten config.h.in entry and obsolete code) cannot
be distinguished from each other automatically. One of them is a bug.
I thought manually setting up config.h.in was obsolete -- aren't people
supposed to be using AC_DEFINE/A
Hello,
Bison has been removed from Chapter 5 recently. This prevents me from
fixing a Coreutils bug with the following patch:
http://www.linuxfromscratch.org/~alexander/patches/coreutils-5.2.1-dateseconds-1.patch
The reason is that the patch modifies the gedtade.y file, and the
Makefile want
Alexander E. Patrakov wrote:
> The two cases (forgotten config.h.in entry and obsolete code) cannot
> be distinguished from each other automatically. One of them is a bug.
I thought manually setting up config.h.in was obsolete -- aren't people
supposed to be using AC_DEFINE/AC_DEFINE_UNQUOTED in t
Anderson Lizardo wrote:
I suggest you use "grep ^HAVE_" instead of only "grep HAVE", so you
reduce the false positives. SANE for instance use macros like
"WE_HAVE_*" which I suppose are not to be listed.
So here goes a slightly modified snnipet, which does not create a temp file:
ifnames `find
On Son, 2005-08-14 at 13:33 +0100, Bernard Leak wrote:
> Dear List,
> I simply can't get Nautilus(-2.8.2) to build against
> medusa(-0.5.1), as suggested in Book. Moreover, I believe that
> it is IMPOSSIBLE. Building with the medusa library invisible:
> build OK. Building with
On 8/15/05, Greg Schafer <[EMAIL PROTECTED]> wrote:
> 1) `--print-file' is undocumented (therefore could break anytime)
fair enough: suggested changes are:
Chapter 5
gcc -dumpspecs | sed -e 's@ /lib/ld-linux.so.2@
/tools/lib/[EMAIL PROTECTED]' > tempfile
gcc -specs=tempfile
rm tempfile
Ch
31 matches
Mail list logo
