On Tue, Dec 2, 2008 at 2:43 AM, Matthew Burgess
<[EMAIL PROTECTED]> wrote:
> On Mon, 01 Dec 2008 21:16:49 -0800, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
>> Jeremy Huntwork wrote:
>>> Because this was a consensus made by several people back in the early
>>> part of 2006, I'd like to open it up for
[ ] I am an editor of LFS or one of the related projects
[ ] 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 package updates as deviations)
[X] I deviate a lot from BLFS (not counting package updates
On 5/24/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> Matt,
>I did respond, but you chose to ignore it.
>
>
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057282.html
>
No, I didn't ignore it. I saw that you said "the rules are not that
different".
On 4/24/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
>
> > >
> > > Approximate build time: 8 SBU
> >
> > I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
>
> Well, my time values can be smallest than yours due that I
On 4/21/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
> In CLFS, we create all the users and groups, this will solve all issues
> if LFS will follow. It will also simplify the BLFS instructions to
> adding users to the appropriate groups. It's a plus for all, eliminates
> so of tedious work the BLFS h
well, i just started it (after grabbing the newest script as of 0100
EDT), it's grabbing the packages now, i'll let you guys know how it
goes tomorrow (between classes probably) ...
On 10/4/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
>
> > Right. I guess I just wanted to
On 10/3/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Hello All,
> ...
> of the team members here. It suggested that I created this notion of
> leaving LFS as a ruse to gain more recognition and ended with the
> comment that I 'need help'.
I'm nt even going to justify the person's reactions wit
On 10/2/05, M.Canales.es <[EMAIL PROTECTED]> wrote:
> The problem at this moment is that I can't figure yet how to manage the chroot
> phase.
hmm ... would it work to make a "Stage 2" script that's simply called
as the command to execute through chroot? ... i'm not much of a
developer, but i've lo
On 9/19/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Richard A Downing wrote:
...
> Ah, but now we have the catch-22. One needs the understanding in order
> to be able to draw the diagram. Those that have the understanding don't
> need the diagram!
>
> Regards,
>
> Matt.
that just sings po
On 9/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> ... I'm only considering the five major ones here,
> too...tcsh, zsh, ksh, bash, and ash. Are there any tcsh users here who could
> tell me which changes (if any) would be needed for that shell?
honestly, far too many ... tcsh is a csh d
On 8/11/05, Dermot Bradley <[EMAIL PROTECTED]> wrote:
> It hit the same problems as a few other people with building uClibc HLFS
> Development version - shadow 4.0.11.1 gave problems with login_pam
> (innetgr) and then with missing l64a code in uClibc.
>
I was one of those people ... I'll test it
Jeremy Huntwork wrote:
> Hi All,
>
> I wanted to open this up to the entire community for further comments
> (especially for those that may not watch the alfs-discuss list). A
> question was brought up on alfs-discuss today that I thought deserves some
> attention.
>
My current LFS build was throu
i'm usually just a lurker here, but as someone who remembers the first
time using the book, i would have to vote against it being added
directly, though i do strongly agree with the hint idea. to me, it
seems that it belongs more in BLFS where it already exists, but either
with a without pam note
just going by the numbers then, and that pass 1 is ~3 times the work,
11 is far too much, but does g++ actually add that much to the compile
time? ... granted i don't recall make test taking more than about
20-30 mins (3-4) SBU on my box ... so i guess 14 with the tests does
fall around the same ma
I'd be interested in helping out some, though I only have minor
experience in coding in TCL/TK ... not much usable for parsing that
many files to dig out the info ... i'll start skimming through the
kernel sources after I figure out whether the patches (including
uClibc) for shadow 2.0.7 will apply
> Is there any particular reason for using ramfs for /dev while building
> the book when tmpfs is what we use after the system is built?
is there any pre-existing requirement to have tmpfs enabled in the
host system's kernel? ... if not, and the host system doesn't have it
enabled (yeah host has t
16 matches
Mail list logo
