Ivan Kabaivanov wrote:
> Hi all,
>
> I believe there's a untriggered bug in chapter 6, Re-adjusting the toolchain.
>
> We've just entered the chroot, installed the kernel headers and built glibc.
> At this point we still only have /tools/bin/gcc. We've just built glibc so
> we have it under /li
On Monday 10 December 2007, Chris Staub wrote:
> Ivan Kabaivanov wrote:
> > Hi all,
> >
> > I believe there's a untriggered bug in chapter 6, Re-adjusting the
> > toolchain.
> >
> > We've just entered the chroot, installed the kernel headers and built
> > glibc. At this point we still only have /to
On Mon, 10 Dec 2007 03:09:04 -0500
Ivan Kabaivanov <[EMAIL PROTECTED]> wrote:
>
> Sorry for sounding the alarm without merit :-)
Hey, isn't it good to see that:
1) Someone is paying attention.
2) Some people actually understand building the toolchain.
Well it makes me feel more confident any
Hi:
I am back:) For the past year or so I have been using Ubuntu Linux
mainly because of lack of time. For the past month I have been
updating my scripts to match the current LFS setup so that I can be a
happy LFSer again.
I recently received a question from a user who inquired why we did the
thi
Tushar Teredesai wrote:
> Hi:
>
> I am back:)
I'm glad someone is.
> I recently received a question from a user who inquired why we did the
> things in LFS the way were are doing them now. That got me thinking
> that though not-so-old-timers like me know how LFS evolved over the
> years, new co
This was reported on IRC by "sbnet". On page 7.6, Configuring the Linux
Console, it says...
"There is no pre-made UTF-8 Russian keyamp, therefore it has to be
produced by converting the existing KOI8-R keymap as illustrated below:"
"keyamp" should of course be "keymap".
--
http://linuxfromscra
Chris Staub wrote:
> This was reported on IRC by "sbnet". On page 7.6, Configuring the Linux
> Console, it says...
>
> "There is no pre-made UTF-8 Russian keyamp, therefore it has to be
> produced by converting the existing KOI8-R keymap as illustrated below:"
>
> "keyamp" should of course be "
As the wiki states, either e2fsprogs or udev needs to be installed in
chapter 5 if we're going to include the util-linux-ng package.
After analysing the matter a bit, I've been testing with the
installation of e2fsprogs in chapter 5, this set of commands:
mkdir -v build
cd build
../configure --p
Hi,
While we are talking about the evolution of LFS, now seems like a good
time to announce to the wider LFS community the availability of a Next
Generation build method.
The main advantages of the new method are:
- sane x86_64 bi-arch (aka Multilib)
- no more weird host issues like those expe
Julio Meca Hansen wrote:
> As the wiki states, either e2fsprogs or udev needs to be installed in
> chapter 5 if we're going to include the util-linux-ng package.
>
> After analysing the matter a bit, I've been testing with the
> installation of e2fsprogs in chapter 5, this set of commands:
>
> mk
On Dec 10, 2007 1:49 PM, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Julio Meca Hansen wrote:
> > As the wiki states, either e2fsprogs or udev needs to be installed in
> > chapter 5 if we're going to include the util-linux-ng package.
> >
> > After analysing the matter a bit, I've been testing with th
On Monday 10 December 2007 16:41, Greg Schafer wrote:
> Hi,
>
> While we are talking about the evolution of LFS, now seems like a good
> time to announce to the wider LFS community the availability of a Next
> Generation build method.
>
> The main advantages of the new method are:
>
> - sane x86_6
On Tue, Dec 11, 2007 at 08:41:06AM +1100, Greg Schafer wrote:
> - when targeting x86_64, it doesn't matter whether the host is running
>32-bit or 64-bit kernel or userland or combination of both, it just
>works.
>
In best /. fashion, I haven't read the links yet, but you're saying
it's o
Bruce Dubbs wrote:
> Julio Meca Hansen wrote:
> I've lost the background on this. Looking at util-linux, why do we need
> it at all in Chapter 5? Can't we just build it once in Chapter 6 just
> before the first file that needs it?
>
From what I remember it was so we could mount /dev/pts and /d
Bruce Dubbs wrote:
> Julio Meca Hansen wrote:
> I've lost the background on this. Looking at util-linux, why do we need
> it at all in Chapter 5? Can't we just build it once in Chapter 6 just
> before the first file that needs it?
>
From what I remember it was so we could mount /dev/pts and /d
Bruce Dubbs wrote:
> Julio Meca Hansen wrote:
> I've lost the background on this. Looking at util-linux, why do we need
> it at all in Chapter 5? Can't we just build it once in Chapter 6 just
> before the first file that needs it?
>
From what I remember it was so we could mount /dev/pts and /d
Thomas Pegg wrote:
> Bruce Dubbs wrote:
>
>> Julio Meca Hansen wrote:
>>
>
>
>> I've lost the background on this. Looking at util-linux, why do we need
>> it at all in Chapter 5? Can't we just build it once in Chapter 6 just
>> before the first file that needs it?
>>
>>
> From wh
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Thomas Pegg wrote:
> From what I remember it was so we could mount /dev/pts and /dev/shm
> inside of the chroot, but that's unnecessary now with the bind mount
> of the host's /dev.
The bind-mount of /dev isn't what makes it unnecessary. That's
Bryan Kadzban wrote:
> Thomas Pegg wrote:
>> From what I remember it was so we could mount /dev/pts and /dev/shm
>> inside of the chroot, but that's unnecessary now with the bind mount
>> of the host's /dev.
>
> The bind-mount of /dev isn't what makes it unnecessary. That's why
> section 6.2.3 s
Ken Moffat wrote:
> On Tue, Dec 11, 2007 at 08:41:06AM +1100, Greg Schafer wrote:
>> - when targeting x86_64, it doesn't matter whether the host is running
>>32-bit or 64-bit kernel or userland or combination of both, it just
>>works.
>>
> In best /. fashion, I haven't read the links ye
20 matches
Mail list logo
