-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Greg Schafer wrote:
> The Shadow supplied `su' explicitly twiddles with PATH.
Oh cute.
Well, that really screws up whatever I was (half-) thinking, then.
Still, though: never mind. :-)
> Sidenote: next Coreutils release will no longer install
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Chris Staub wrote:
> Actually the pkg-user hint says to copy su to /tools/bin.
OK, I need to (re-)read before posting. Sheesh. ;-)
> Also, the LFS book explicitly disables the installation of su from
> Coreutils via a patch (always has I think
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> and my proposal for infrastructure changes so that such things could
> no longer happen
> (http://www.linuxfromscratch.org/pipermail/lfs-dev/2006-May/057337.html)
> remains unimplemented.
Well, from re-reading that
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jacek Herold wrote:
> I'm trying to change to the chroot environment. When starting udev
> (in the chroot environment) i have the following error:
The book doesn't start udev in the chroot environment (...does it?), for
exactly this reason. I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jacek Herold wrote:
> In earlier system it was not a problem to have two udev working -
> second in chroot (somehow).
Earlier udev versions didn't try to create this socket, either. The
upstream udev developers do *not* (seem to) intend to allow
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
DJ Lucas wrote:
> That PackageFile should contain the
> following information:
> 1. package name
> 2. package version
> 3. a description of the program
> # possibly meeting whatever text requirements we will need
>
On Thu, Feb 28, 2008 at 04:35:56PM +, [EMAIL PROTECTED] wrote:
> I'm not sure, but how do Arch Linux, Debian, and others do it?
They don't; not really.
The only time I remember seeing a glibc minor version change was after
the most recent Debian stable release, when testing started merging
On Thu, Feb 28, 2008 at 07:17:46AM -0500, Bryan Kadzban wrote:
> Don't have a lot of time to comment ATM (working on too many other
> things), but I'm leery of this kind of change.
I should also note that if we can figure out a way to provide a PM
framework, without mand
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> The reason for this, I think, is because the discussion is taking
> place among LFSers. :) We're all a bunch of control-freaks who like
> to do things our own way.
That's a really good point... ;-)
> but I think, for th
On Fri, Feb 29, 2008 at 11:22:24AM -0600, Rich Edelman wrote:
> While not all package managers keep configure and build as separate steps (in
> fact, I'm not aware of any that actually do have them as separate steps),
The package-user method's current scripts do. However, I'm not sure if
that re
On Fri, Feb 29, 2008 at 03:31:28PM +, [EMAIL PROTECTED] wrote:
> I would like to see UTF-8 in LFS.
I thought it was? Or at least, I thought LFS was UTF-8-ready. (I don't
think we want to enforce UTF-8 on everyone, though.)
> I'm not sure I like using XML for building packages. I prefer rea
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
George Makrydakis wrote:
> On Sunday 02 March 2008 02:02:23 David Jensen wrote:
>> George Makrydakis wrote:
>>> You know what? This can work on windows as well.
>> LOL, and joe-sixpack visits LFS and clicks install ubuntu clone
>> now!
>
> What i
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
George Makrydakis wrote:
> First of all, Joe Sixpack is David's term.
Yeah, I know that...
> Second, I did not use Windows before Linux :)
I'm not talking about you.
I'm talking about the people that you seem to want to use your program
- -- t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> [X] I am an editor of LFS or one of the related projects
> [X] I use LFS as my primary Linux system
> [X] I use LFS on more than one PC (including virtual machines)
> [ ] I deviate a lot from LFS (not counting packag
On Mon, Mar 03, 2008 at 09:35:05AM -0500, Jonathan Oksman wrote:
> Anywho, the test was to find out if chapter 6 packages were required
> to be built as root as the book details it.
Nope, although you do have to make a few adjustments. The package user
hint details most of the required adjustment
On Mon, Mar 03, 2008 at 04:07:38PM +0200, George Makrydakis wrote:
> Cross platform code runs everywhere.
Um, yeah (at least in theory), but does that actually help? See the
question below that you didn't answer:
> > But what does running it on a Windows box actually gain us, that
> > presenting
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Dan Nicholson wrote:
> On Tue, Mar 11, 2008 at 3:03 PM, Nathan Coulson <[EMAIL PROTECTED]>
> wrote:
>> I was just looking at cd udev-config-20080217,
>>
>> Linux 2.6.24.3 (.2 headers), udev 113,
>
> Someone brought this up to me off list and I f
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bryan Kadzban wrote:
> What I'd *like* to do is get a way to create a "symlink" for network
> devices in the kernel;
(Talking to myself here... whee! ;-) )
The sticking point with that whole idea is the fact that IFNA
On Wed, Mar 19, 2008 at 11:20:23AM -0500, Bruce Dubbs wrote:
> My position is that we should stay with grup 0.97 and the compatible
> version of e2fsprogs until upstream gets the problems worked out.
That works great for booting LFS, but an LFS-installed grub won't be
able to boot the host's kerne
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Ag. D. Hatzimanikas wrote:
>
>> Example? The common usage of /usr. Convenient but fundamental
>> broken. From all the BLFS packages the half or even more, (they)
>> really bellongs to /usr/local hierarchy.
>
> Why should t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Nathan Coulson wrote:
> Dont remember seeing this mentioned, so I wanted to inform the
> mailing list.
There was a post about it[1], but no response. I'm going to just assume
that /usr/etc is wrong here. :-)
> It looks like mandb is sticking t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
taipan wrote:
> It still has me wondering if this proposed branch would require or
> benefit from the inclusion of the 'fakeroot' package, as used by
> diy-linux? I've never built either, & am uncertain of it's precise
> function - so this is p
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Sukucorp Sukucorp wrote:
> On Mon, Mar 31, 2008 at 5:12 PM, Bryan Kadzban
> <[EMAIL PROTECTED]> wrote:
>> But any kind of DESTDIR type setup would require it, if the
>> package's "make install" is run as
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> On Tue, Apr 22, 2008 at 12:21:49PM -0700, Dan Nicholson wrote:
>> So, I suppose you could grep for some regex
>> (PAGE_(SHIFT|SIZE|MASK)) of those macros to be safe.
>
> Nothing for the other patterns. So seems like a usa
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> To be current, I'd also like to see the Udev blocker sorted out before
> we release 7.0. See: http://wiki.linuxfromscratch.org/lfs/ticket/2057
Since I see a mention of udev:
Over the past couple weeks, I've started to l
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> If a system has more than one network card that could be identified
> with the same prefix, (eth0, eth1, etc). We would like to like to
> configure udev within chroot so it will maintain the same
> relationship of ethx to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> I would really like to see you commit what you think is right and we
> can then work from that to narrow down any outstanding issues.
Soon. I haven't actually put together what I think is right yet, except
in my head; I'll t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Gerard Beekmans wrote:
>> I think the consensus we're trying to reach is what to do with the
>> bootscripts if we do add them back to an Appendix as Bruce
>> suggested. Do we still install the bootscripts the current way or
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> ...Develop/maintain an actual bootscripts package and during the
> generation of the LFS book, extract the scripts and include into the
> book.
>
> That does mean that anybody who wants to build the LFS book needs to
> c
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> If a diverging is needed then we may just need to branch it.
Yeah, that may have been smarter.
> It's not *the* solution but it sure would keep things easy for us. It
> gets complicated otherwise to rememer.
I'm not sur
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Gerard Beekmans wrote:
>
>> Rather than trying to fix udev, and it sounds like there isn't a
>> solution that isn't hackish and has a risk of not working any day
>> now with new releases. How about we fix our netw
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> I'm not sure if this is possible with the XML toolset, but it may
>> work to grab the values of &udev-config;.tar.bz2 and
>> &udev-config-url;. Run wget on the sec
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> One of the solutions that came from the udev discussion the last few
> days was to move dhclient from BLFS to LFS. Or leave it in BLFS but also
> install it in LFS.
One possible issue would be that there are lots of dif
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Nathan Coulson wrote:
>> I think moving it before mountkernfs would be an ideal time.
>
> hwclock needs to write to /var/lib/lastdate and /etc/adjtime. Could
> /var/lib be remotely mounted? It doen't look like a good idea t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gilles Espinasse wrote:
> It has been reported on ipcop-devel list that cp foo{,.bak} contruction is
> broken on Ubuntu-8.04
>
> This was on expect instructions
>
> cp configure{,.bak}
> cp: missing destination file operand after `configure{,.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gilles Espinasse wrote:
> This was just to inform.
> You could require what you desire.
>
> For me, less requirement is better so we will adapt our scripts. I do
> not imagine I could make Ubuntu change something just to let IPCop
> compile ;-)
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> Just make sure the user that's running your scripts (...or at
>> least, I'm assuming that's how people do an "IPCop compile"?) is
>> running bash. T
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> My point is that this is an unusual user problem and it is not
> appropriate for the book to address it.
Ah. Yes, I'd completely agree with that. :-)
(I was trying to suggest that the "set -B" be added to the IPCop scripts
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Right now there are a few of tickets outstanding with regard to updated
> packages
> or patches to packages that we need to address before a package freeze. We
> need
> to either agree to update or reset the target milest
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Rick Houkes wrote:
> Making m4 part of the temporarily toolchain and installing it after
> autoconf makes a tool of autoconf called autom4te link to the m4 in
> /tools instead of a m4 that would be part of a finished system.
Um, m4 doesn't provid
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> So, to sum up, we have two problems:
>
> 1. m4 in chapter five doesn't link against /tools
> 2. m4 in chapter six is built to late to avoid hard-coded paths to
> /tools/bin/m4 showing up in autotools scripts.
>
> I pers
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
OK, some useful info this time (instead of a state dump...):
DJ Lucas wrote:
> Bruce Dubbs wrote:
>> Right now there are a few of tickets outstanding with regard to updated
>> packages
>> or patches to packages that we need to address before a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>
>> I'd prefer to get rid of it. It wasn't there at all (since 2007 or
>> so) until gcc's extra bits added it as a requirement...
>
> I'd tend to agree
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Connolly wrote:
> On Saturday October 18 2008 10:10:57 pm Bryan Kadzban wrote:
>>>> 2247 Texinfo 4.13a ( repackage due to maintainer error )
>> I just pulled down texinfo-4.13a.tar.gz and texinfo-4.13.tar.gz --
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Connolly wrote:
> On Sunday October 19 2008 12:05:24 am Bryan Kadzban wrote:
>> I can't seem to find the original texinfo-4.13 package anywhere... :-(
>>
>> Oh well.
>
> This is the orig
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
>> Three tests were skipped:
>>
>> cannot tell stack overflow from crash; consider installing libsigsegv
>> SKIP: test-c-stack2.sh
>> Skipping test: multithreading not enabled
>> SKIP: test-lock
>> Skipping test: multithreading
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
DJ Lucas wrote:
> ## Test 4
> [EMAIL PROTECTED] TESTS]$ export LANG=ru_RU.UTF-8
> [EMAIL PROTECTED] TESTS]$ vimtutor
> ===
> =Д о б р о п о ж а л о в а т ь в у ч
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Ken Moffat wrote:
> To me, 2.6.9 is ancient history! (4 years old). I think something
> like 2.6.16 (purely because it is still getting long-term support
> updates) is a better minimum, but also I think we should encourage
> people to build a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Bryan Kadzban пишет:
>> It *looks* like vimtutor -- or at least the way LFS installs it now
>> -- has simply gotten better. If that's correct: Yay! ;-)
>
> Yes, that's correc
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> Ken Moffat wrote:
>>> but also I think we should encourage
>>> people to build a new kernel first (if they aren't using a Live CD)
>>> so that they can
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
>> (Actually it may cause grief with the installed distro's udev
>> system, especially if the wrong CONFIG_ compatibility sysfs flags
>> get unset...)
>
> So don't use udev on the host... [/me runs]
:-P
(You want to try
William Harrington wrote:
> On Dec 16, 2013, at 5:17 PM, John Burrell wrote:
>
>> When I try and update the dynamic linker, /usr/lib/ld-2.18.so in my case,
>>
>>
>> I get the message 'Text file busy'
>>
>> and when I then access the chroot window I get a seg fault.
>
> You aren't clear,
>
> /
John Burrell wrote:
>> ...Also, it is *not* possible to replace either /lib/ld-linux.so.2 or
>> /lib64/ld-linux-x86-64.so.2 (...and yes, I use those paths intentionally,
>> since those are the ABI standard) on a running system unless you replace
>> both it and /lib{,64}/libc.so.6 from the same pr
On Sat, Dec 21, 2013 at 05:56:37PM +0100, Armin K. wrote:
> On 12/21/2013 04:26 PM, Armin K. wrote:
> > In latest lfs book, the "Preparing Virtual File Systems" page contains:
> >
> > 6.2.1. Creating Initial Device Nodes
> >
> > When the kernel boots the system, it requires the presence of a few
On Sat, Dec 21, 2013 at 04:33:42PM +0100, Armin K. wrote:
> devpts should also be bind-mounted, as it will override default devpts
> flags and permissions which were mounted before.
>
> In my case:
>
> mount output before mounting devpts at $LFS/dev/pts
>
> devpts on /dev/pts type devpts (rw,nos
On Sat, Dec 21, 2013 at 03:17:31PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Sat, Dec 21, 2013 at 10:11:06AM -0800, Bryan Kadzban wrote:
> >> On Sat, Dec 21, 2013 at 05:56:37PM +0100, Armin K. wrote:
> >>> This also might be relate
(Headers on this one might be weird because the ssh session died, so I
had to go through weirdness to recover the email...)
On Sat, Dec 21, 2013 at 07:59:37PM +0100, Armin K. wrote:
> On 12/21/2013 07:16 PM, Bryan Kadzban wrote:
> > On Sat, Dec 21, 2013 at 04:33:42PM +0100, Armin
On Sat, Dec 21, 2013 at 06:32:11PM -0600, Bruce Dubbs wrote:
> Bryan Kadzban wrote:
> > On Sat, Dec 21, 2013 at 03:17:31PM -0600, Bruce Dubbs wrote:
> >> Ken Moffat wrote:
> >>> On Sat, Dec 21, 2013 at 10:11:06AM -0800, Bryan Kadzban wrote:
> >>>> On S
Armin K. wrote:
> On 01/19/2014 12:45 AM, Bruce Dubbs wrote:
>> Armin K. wrote:
>>
I'm glad you reminded me of that. I suppose I could avoid a lot of
changes if we made the symlinks, including one for
/usr/include/{blkid,uuid}/. I'll keep investigating.
>>> You don't really
Bruce Dubbs wrote:
> Ken Moffat wrote:
>> On Fri, Feb 07, 2014 at 03:06:52PM -0600, Bruce Dubbs wrote:
>>> BTW, without the above, we do have /usr/lib/libncurses.a. Shouldn't
>>> shouldn't that be picked up?
>
>> You should know me by now - disable static libs when I can, and hide the
>> rest of
Armin K. wrote:
> No matter what you say, if a package A installs a file X.Y that requires
> file Z.Y and package A doesn't either:
>
> a) pull automatically the package (depend on) that contains file Z.Y
> b)ships that file itself
>
> the packaging is broken.
Then BLFS's and LFS's "packaging"
Bruce Dubbs wrote:
> After a fairly extensive discussion, I've update the host system
> requirements page in svn:
>
> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html
Looks reasonable to me, unless we want to take lib64 / lib32 into account,
rather than just lib. I'd
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> After a fairly extensive discussion, I've update the host system
>> requirements page in svn:
>>
>> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html
>
> Looks reasonable to me, unl
Ken Moffat wrote:
> When I woke up in the
> morning, I was surprised to find that my OpenJDK script was still running
> rm -rf for the source directory, and had been doing so for more than 5
> hours (both wall-clock time and CPU time), and was now at 99%-100% of one
> CPU, according to top.
...Odd
Bruce Dubbs wrote:
> I did have a private email with a volunteer to write a hint. If I get
> that, I'll add a note in the systemd section that points there.
I saw a commit mail to -book that added the hint link.
However, if someone (like me...) *really really* doesn't want systemd, and
knows it
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> However, if someone (like me...) *really really* doesn't want systemd,
>> and knows it from the get-go, shouldn't they avoid building all the other
>> junk like libacl / libattr / expat / *dbus* / etc., too? The curre
Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> Sebastian Plotz wrote:
>>> This assignes the name eth0 to the interface with the MAC address
>>> 12:34:56:78:9a:bc. The file name is important: if there would be a
>>> second file (for example 10-eth1.link) with "Name=eth1"instead of
>>> "Name=eth0" the
Sebastian Plotz wrote:
> Am 15.04.2014 05:37, schrieb Bryan Kadzban:
>> Also, does it work to match NICs by device path instead of MAC
>> address,
>
> Yes. Have a look at "|Path=pci-:02:00.0-*":|
Huh. OK, that's unexpected. :-)
However, while this:
Garrett Schure wrote:
5.21 Grep Perhaps add configure option --libdir=/tools/lib.
Fixed: glibc compilation from chroot said "working compiler support
for visibility attribute" required.
FYI, I've see this sometimes when binutils does not compile correctly
(usually because I set -O3 in its CFLAGS, w
Robert Connolly wrote:
Hi. Uhm, using glibc-20050321.
Which binutils version? Since the error is coming from ld, I would
suspect that it's binutils first (though that's basically a guess).
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-d
Matthew Burgess wrote:
The idea is that in roughly 2 weeks we'll release 6.1. So, can
everyone please hammer this one to death and report all problems to
this list and preferably also to bugzilla so we can keep track of
them.
Two issues I've seen so far:
1) The URL for less may not be right. Less
Bryan Kadzban wrote:
If I run into other issues, I'll post them then. I've just finished
compiling binutils pass 1 (yes, by hand, I have a whole weekend ;-) ).
Well, I ran into two issues, but both of them seemed to be caused by my
own mistakes (I really should come up with a scri
Bryan Kadzban wrote:
So when I got to autoconf, it
failed to build, because the chapter 5 Perl did not have Data::Dumper
installed (and /usr/bin/perl was in /tools).
Oops, missed some words:
s/in/looking for it in/
signature.asc
Description: OpenPGP digital signature
--
http
Good grief, I'm replying to myself a lot today!
Anyway, I just saw what I think is a typo in section 7.4 (in the intro):
Device nodes do not require much disk space, so the memory that is
used in negligable.
That should have an 's/ in / is /' done to it, I think.
Also, I missed this in 7.4.2 the fi
Bruce Dubbs wrote:
gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.15.94.0.2.2/bfd -I.
-D_GNU_SOURCE -DTRAD_CORE -I. -I../../binutils-2.15.94.0.2.2/bfd
-I../../binutils-2.15.94.0.2.2/bfd/../include
-I../../binutils-2.15.94.0.2.2/bfd/../intl -I../intl -W -Wall
-Wstrict-prototypes -Wmissing-prototypes
FYI, the /lfs/view/testing/ URL disappeared a short while ago from the
LFS web server. I keep getting 403 errors when browsing directly to it,
and it doesn't show up at /lfs/view/ either.
Was this a symlink that got clobbered by the book render perhaps? Or
was it supposed to go away? Was it repl
Matthew Burgess wrote:
Bryan Kadzban wrote:
I keep getting 403 errors when browsing directly to it, and it
doesn't show up at /lfs/view/ either.
Yeah, sorry about that. I didn't update the version entities
correctly to stop the render-lfs-book.sh script getting all confused.
Should be
On Fri, Apr 08, 2005 at 02:30:02PM +0100, William Zhou wrote:
> The message read as "Excess permission or bad ownership on file
> /var/log/btmp." After changing to 640, it stops complianting.
>
That's a little odd. From openssh-4.0p1/loginrec.c:
if((fst.st_mode & (S_IRWXG | S_IRWXO)) || (fst.s
On Wed, Apr 13, 2005 at 07:50:03AM -0500, Bruce Dubbs wrote:
> In any case, we are getting closer. I did follow the book precisely and
> took the option of not changing anything in the console configuration.
> This worked in the past. It would certainly be easy enough to throw in
> a "stty san
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> None of your boot scripts (or your login scripts) set stty erase
>> ^H, correct? You never know...
>
> Not unless it's done in the lfs-bootscripts.
I don't believe it is, because my 6.1 system (using the lfs-bootsc
Matthew Burgess wrote:
> [EMAIL PROTECTED] wrote:
>
>> I suppose though we'll need 2 host compilers, we'll need a 3.4 for
>> the kernel builds etc
>
> Why?
I'm just guessing here, but I would bet that it'll be similar to the gcc
2.95 / gcc 3.X upgrade. The kernel documentation said to use 2.95
Jim Gifford wrote:
>2 - No Web Browser
> You will no long be able to view web pages for the LFS BOOK.
> You will have a local copy or we
> can add into the directions to download a text copy of the book.
Could we add Lynx to the end of the chapter right before the reboot?
The
Tony Morgan wrote:
> However, what's missing is a second explicit notice along the lines
> of "Ok - that [xxx] build directory we told you not to remove earlier
> - it's now safe to erase it. We won't be needing that particular
> build of [xxx] anymore".
In Section 5.8, right after the "Note" abou
Jeremy Huntwork wrote:
> [EMAIL PROTECTED] wrote:
>
>> you _should_ be able to do a standard lfs build, as long as
>> you build gcc with the --disable-multilib option.
>
> --disable-multilib? or --enable-multilib=no? Is there a difference?
Not with most packages, when they use fairly recent auto
Matthew Burgess wrote:
> Yep, here's my '/etc/sysctl.conf':
>
> net.ipv4.tcp_window_scaling = 0
> dev.rtc.max-user-freq = 1024
>
> I think that the top two were failing because the relevant
> /proc entries hadn't been created; the devices/interfaces hadn't been
> brought up by the time the sysctl
Matthew Burgess wrote:
> So, with all that said, I think someone with some time on their hands
> needs to investigate this whole 'dev.d' setup (or just hit me with
> the relevant cluebat), and we'll put the relevant machinery in the
> bootscripts and/or the book. This, I believe, would completely
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
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
Alexander E. Patrakov wrote:
> In /etc/rc.d/init.d/functions, we have:
>
> # if CUR_LENGTH was set to zero, then end the line
> if [ "${CUR_LENGTH}" == "0" ]; then
> echo ""
> fi
>
> "==" is a bash-specific "pattern matching" operator. In this context, it
>
On Thu, May 19, 2005 at 04:38:30PM +0100, Matthew Burgess wrote:
> Both '[' and 'test' are bash builtins as well as
> binaries in /bin. Is there anyway we can force the bootscripts to
> choose the implementations in /bin without having to rely on potentially
> non-SUSV3 conformant shell builtin
Robert Russell wrote:
> On 5/19/05, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
>
>> We could use the "enable" builtin to disable the builtin versions
>> in bash:
>>
>> enable -n test [
>>
>> I'm (again) not sure about other shells,
Jim Gifford wrote:
> May needs some more changes for udev 058 and 2.6.12 kernel. Will check
> it out.
>
>
>
> Subject:
> [ANNOUNCE] udev 058 release
> From:
> Greg KH <[EMAIL PROTECTED]>
>
> Also, the rules file structure a
Matthew Burgess wrote:
> Do we need a script for it though? I've not tested it yet (of course!
> :) ), but this is what I was thinking:
>
> KERNEL="rtc", ACTION="add", \
> RUN="echo 1024 > /proc/sys/dev/rtc/max-user-freq"
> KERNEL="eth0", ACTION="add", \
> RUN="echo 0 > /proc/sys/net/ipv4/tcp
Jim Gifford wrote:
> Jim Gifford wrote:
>
>> The only one I know if in BLFS is tetex. Correct me if I'm wrong.
>>
> That is require flex. A lot of developers are moving away from flex.
>
To what?
I don't know of any other library that lets you build your own lexer.
(Doesn't mean they don't exi
Marty _ wrote:
> Why doesnt someone do something sensible and mount devfs to /.devfs
Uh... because we don't use devfs? ;-)
> Bring back the old devices style.
udev does (almost completely, anyway), with the rules file(s) we use.
One difference is that you won't see devices for drivers you don't
Matthew Burgess wrote:
> Bryan Kadzban wrote:
>
>> The obvious answer (for me anyway) to "how do I parse a config file" is
>> "use flex and bison to build a grammar".
>
> And the obvious answer to me (being a C++ kinda guy) is to use 'Spirit&
On Tue, May 24, 2005 at 12:33:39PM +0100, Marty _ wrote:
> never investigated udev to be quite honest, just thought it
> was another form of devfs from the guide.
It is, in that it dynamically manages the /dev directory. But it does
this using hotplug events from the kernel, not code inside the
Bruce Dubbs wrote:
> Has it been shown that the current method has leaks from the build
> system into the new LFS system? If so, I'm not aware of them. Can
> you point to anything specific?
If you use a host with "new" binutils (2.15.x), but are building "old"
binutils (2.14 was what was curren
Matthew Burgess wrote:
> I suppose the 20 line scan.l hunk in it is redundant, though it's not
> going to save that much space in the grand scheme of things.
It won't save space, but removing that file from the patch will prevent
scan.c from being rebuilt. Which was (part of) the whole point.
;-
Matthew Burgess wrote:
> Bryan Kadzban wrote:
>
>> Matthew Burgess wrote:
>>
>>> I suppose the 20 line scan.l hunk in it is redundant, though it's
>>> not going to save that much space in the grand scheme of things.
>>
>> It won
501 - 600 of 666 matches
Mail list logo
