Matthew Burgess wrote:
> If someone could tell me where to dump the script for
> tcp_window_scaling, I'd appreciate it. I've currently got it in
> /etc/dev.d/net/ipv4/tcp_window_scaling.dev but it doesn't get called.
Well... this is odd. Nothing in dev.d gets called when a module is
loaded that
Matthew Burgess wrote:
>Folks,
>
>I'm proposing we stop tracking/using HJL's binutils. Here's my
>reasons:
>
>1) It adds host dependencies of bison and flex
>2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
>
>and fix
>3) FSF recently released 2.16, bringing it back up to
Bruce Dubbs wrote these words on 05/15/05 18:53 CST:
> The editor's guide is just that: a guide. It's not a legal document.
> If an editor has what he thinks is a good reason to deviate, that's OK.
> We should all be trying to make the book as self-consistent as possible
> as well as consistent
Randy McMurchy wrote:
Bruce Dubbs wrote these words on 05/15/05 18:42 CST:
Matthew Burgess wrote:
As for flex, it looks
like the maintainers went AWOL again :(
http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
11 submitted patches yet to be applied. Maybe it would be p
Bruce Dubbs wrote these words on 05/15/05 18:42 CST:
> Matthew Burgess wrote:
>>As for flex, it looks
>>like the maintainers went AWOL again :(
>>http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
>>11 submitted patches yet to be applied. Maybe it would be prudent to
>>roll bac
Matthew Burgess wrote:
> As for flex, it looks
> like the maintainers went AWOL again :(
> http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
> 11 submitted patches yet to be applied. Maybe it would be prudent to
> roll back to 2.5.4a? At least that one manages to get doxygen
Bruce Dubbs wrote:
Does this imply that LFS will drop bison and flex?
From chapter 5, certainly.
If so, they will
need to be added to BLFS. I would hope that they would be retained in
Chapter 6 as they are a part of an overall development base.
Well, I really don't mind keeping bison around. As
Matthew Burgess wrote:
> Folks,
>
> I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
>
> 1) It adds host dependencies of bison and flex
Does this imply that LFS will drop bison and flex? If so, they will
need to be added to BLFS. I would hope that they would be retained
On Sun, 15 May 2005, Matthew Burgess wrote:
>
> So, does anyone think we should still stick with HJL binutils, and if
> so, what are the compelling reasons for doing so?
>
I will be less than surprised if the multi-architecture book has to use
HJL for some architectures, in the past HJL has alwa
Matthew Burgess wrote:
Folks,
I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
1) It adds host dependencies of bison and flex
2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
and fix
3) FSF recently released 2.16, bringing it back up to speed with
mode
Peter Ennis wrote:
Linux From Scratch - Version SVN-20050428
Chapter 5. Constructing a Temporary System
5.15. Coreutils-5.2.1
make RUN_EXPENSIVE_TESTS=yes check.
NOTE: This command is all Bold, including
the period. If you include the period then
it does not belong inside the XML tag(?)
as it is n
ftp://distro.ibiblio.org/pub/Linux/distributions/slackware/slackware_source/ap/ash/ash-0.4.0.tar.gz
should be
ftp://distro.ibiblio.org/pub/linux/distributions/slackware/slackware_source/ap/ash/ash-0.4.0.tar.gz
(small l in linux)
rgds
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
F
Folks,
I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
1) It adds host dependencies of bison and flex
2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
and fix
3) FSF recently released 2.16, bringing it back up to speed with modern
features we were rel
Bryan Kadzban wrote:
Even the one-second wait could be reduced if there was a program
that used directory-change notifications (inotify? maybe...) to sleep
until a directory or file was created or modified, but I don't know of
any such program. I'm fairly sure nothing like that is installed on a
b
Matthew Burgess wrote:
> I'm hoping the dev.d scripts are all handled asynchrohously - i.e.
> udev doesn't wait for one to complete before kicking off the next,
> otherwise boot times might be significantly slowed down with all that
> spinning.
Uh oh. ;-)
udev-056 does indeed wait for each of th
Bryan Kadzban wrote:
I'm not sure what kind of machinery would be needed, but I made a simple
dev.d script for rtc, to handle this case.
Wonderful, thanks!
Number one, it'll print an error to "somewhere" (syslog? udev's log? the
system console? no idea) if your rtc module wasn't configured to suppo
16 matches
Mail list logo
