jhalfs-X build status

Manuel,
   I have completed an 'alphabetical' and 'udev_update'.
They boot with 
no problems.

   SVN: Added a change to master.sh when specifying the book
version on 
the command line.

   It will soon be is a usable state for the general public.
Should we 
have a naming contest?  ( I propose jhalfs-X  for eXtended
jhalfs )

   I must leave my cave and see what that big yellow ball in
the sky 
is.. it is a rare occurence lately.

  George
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Domingo, 26 de Marzo de 2006 19:06, George Boudreau
escribió:

>    It will soon be is a usable state for the general
public. Should we
> have a naming contest?  ( I propose jhalfs-X  for
eXtended jhalfs )

What I'm thinking is to fix the list of command line
switches (all 
configuration options should have their switch also), to fix
the --help 
output, and to review all messages (both error and succes).

Then, merge it to trunk and ask to Thomas or Jeremy to
plublish an oficial 
announce in the ALFS page and in some of the mailing list.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

M.Canales.es wrote:
> El Domingo, 26 de Marzo de 2006 19:06, George Boudreau
escribió:
> 
>>    It will soon be is a usable state for the
general public. Should we
>> have a naming contest?  ( I propose jhalfs-X  for
eXtended jhalfs )
> 
> What I'm thinking is to fix the list of command line
switches (all 
> configuration options should have their switch also),

   I don't see the real value of this ability.. That is why
I created 
the config files, to eliminate the 20 switch command line.

  to fix the --help
> output, and to review all messages (both error and
succes).

  Should also revisit the "echo_finished" text
in makefile_functions, 
make it generic for all books or create a version for each
book.

> Then, merge it to trunk and ask to Thomas or Jeremy to
plublish an oficial 
> announce in the ALFS page and in some of the mailing
list.
> 

   I also forgot the problem with CLFS 'boot method'
makefile division. 
Back in the cave I go, the yellow ball is supposed to return
in my 
lifetime.. *sigh*
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Domingo, 26 de Marzo de 2006 20:38, George Boudreau
escribió:

>    I don't see the real value of this ability.. That
is why I created
> the config files, to eliminate the 20 switch command
line.

When rendering the multiple variations for each book (CLFS
requires 44 runs to 
track properly the arch, method and testsites-level
variations) to can 
diffing the changes with previous ones, I find annoying to
have to edit the 
config files each time and to remember to return it to their
default values 
before doing a commit.

Of course, for final user could be most simple and failsafe
to edit the config 
files.

>    I also forgot the problem with CLFS 'boot method'
makefile division.
> Back in the cave I go, the yellow ball is supposed to
return in my
> lifetime.. *sigh*

The current implementation work for now?

My point is that the current experimental code is better
than the old one, 
thus we should to promote it to trunk ASAP. 

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

M.Canales.es wrote:
> El Domingo, 26 de Marzo de 2006 20:38, George Boudreau
escribió:
> 
>>    I don't see the real value of this ability..
That is why I created
>> the config files, to eliminate the 20 switch
command line.
> 
> When rendering the multiple variations for each book
(CLFS requires 44 runs to 
> track properly the arch, method and testsites-level
variations) to can 
> diffing the changes with previous ones, I find annoying
to have to edit the 
> config files each time and to remember to return it to
their default values 
> before doing a commit.
   I see your point..
> Of course, for final user could be most simple and
failsafe to edit the config 
> files.
> 
>>    I also forgot the problem with CLFS 'boot
method' makefile division.
>> Back in the cave I go, the yellow ball is supposed
to return in my
>> lifetime.. *sigh*
> 
> The current implementation work for now?
   CLFS build works fine for method=chroot. There is a
specific work 
method when using it with method=boot.
   At the moment once the building of the boot partition
succeeds 
clfs-Makefile is forced to exit( by a very ugly method). The
builder 
then transfers $BUILDDIR to the destination machine, and
does a second 
make -f clfs-Makefile and the build process continues.

   What I want/wanted was
    make -f clfs-Makefile makeboot
    make -f clfs-Makefile makesys
   then there could be no change for errors.. (Yes, I did it
once or 
twice and so will someone else)


> My point is that the current experimental code is
better than the old one, 
> thus we should to promote it to trunk ASAP. 
> 
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page