jhalfs-2.2 - release preparatives.

Hi,

I would to release jhalfs-2.2 this Sunday if there is no
show-stoppers. 
My tests shows that the current code looks good, but more
tests, inputs, and 
comments from others will be helpfull before doing the
release.

There is two reasons why we need to do a new stable release
soon:

-. The LiveCD team is waiting a new release including the
SHELL fixes to can 
release LFS LiveCD 6.3-pre2.

-. Support for BLFS-6.2.x books. When the migration to the
new DocBook DTD and 
XSL versions will be done, in the BLFS-SVN book,
jhalfs-trunk will not 
support anymore BLFS-6.2.x, thus we need to have available
an stable jhalfs 
code supporting that books.

George, has been you able to review and test the last
changes commited by me? 
Do you recall on some issue that should be fixed before do
the release?

Also, I'm thinking to full remove the out-to-date PACO patch
if there is no 
volunters to update and maintain it.
 
 
-- 
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.info
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:
> Hi,
> 
> I would to release jhalfs-2.2 this Sunday if there is
no show-stoppers. 
> My tests shows that the current code looks good, but
more tests, inputs, and 
> comments from others will be helpfull before doing the
release.
> 
> There is two reasons why we need to do a new stable
release soon:
> 
> -. The LiveCD team is waiting a new release including
the SHELL fixes to can 
> release LFS LiveCD 6.3-pre2.
> 
> -. Support for BLFS-6.2.x books. When the migration to
the new DocBook DTD and 
> XSL versions will be done, in the BLFS-SVN book,
jhalfs-trunk will not 
> support anymore BLFS-6.2.x, thus we need to have
available an stable jhalfs 
> code supporting that books.
> 
> George, has been you able to review and test the last
changes commited by me? 
> Do you recall on some issue that should be fixed before
do the release?
   I needed to change ISP and have been off line for a
while. I have not
have a chance to review all the changes in depth but I do
not see any
faults. All the changes you made look fine with one
exception. (see below)
CHROOT:       SHELL=/tools/bin/bash
CHROOT:       $chapter6
   Is this a valid 'make' construct, having duplicate
labels? (I am no
make guru)

> 
> Also, I'm thinking to full remove the out-to-date PACO
patch if there is no 
> volunters to update and maintain it.
   I think the PACO patch should be removed. If jhalfs-3.0
ever leaves
the ground hooks will be placed in the code to allow people
to add their
own flavour of pm.

>  
>  


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

El Jueves, 1 de Marzo de 2007 21:04, George Boudreau
escribió:

> CHROOT:       SHELL=/tools/bin/bash

This one is not a normal makefile target but a variable
definition to be used 
when processing the actual target that have the same name.

I found that few days ago while reading the make manual:

http://www.gnu.org/software/make/manual/mak
e.html#Target_002dspecific

-- 
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.info
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

On Thu, Mar 01, 2007 at 08:05:01PM +0100, M.Canales.es
wrote:
> I would to release jhalfs-2.2 this Sunday if there is
no show-stoppers. 
> My tests shows that the current code looks good, but
more tests, inputs, and 
> comments from others will be helpfull before doing the
release.

This is kind of OT, but this email sparked an idea, so I'd
like to throw
it out there.

The progress bar included in jhalfs is nice, but it's not
(unless it has
changed recently - sorry I haven't been following
development lately) as
functional as it might be. It could also stand to leave less
of an impact on
the general performance of the build.

I'd like to write a modified progress bar in C or C++ that
doesn't call
external binaries for calculations or to draw on the screen.
My idea is
of one that calculates an SBU time for the machine on the
first build of
Binutils, stores that somewhere (a conf file or something),
then draws a
progress bar for each package showing percentage complete
(think
wget-style). There would be an estimated completion time and
we could
also store the actual run-time involved as before and
calculate the SBU.
If this is well-written, being that the calculations are
only what we
need and all internal to the binary, it *should* be both
more practical
and more efficient.

Ideas? Objections? Concerns?

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

El Jueves, 1 de Marzo de 2007 22:22, Jeremy Huntwork
escribió:

> I'd like to write a modified progress bar in C or C++
that doesn't call
> external binaries for calculations or to draw on the
screen. My idea is
> of one that calculates an SBU time for the machine on
the first build of
> Binutils, stores that somewhere (a conf file or
something), then draws a
> progress bar for each package showing percentage
complete (think
> wget-style). There would be an estimated completion
time and we could
> also store the actual run-time involved as before and
calculate the SBU.
> If this is well-written, being that the calculations
are only what we
> need and all internal to the binary, it *should* be
both more practical
> and more efficient.

If you can do that that binary will be able to calculate
also disk space used, 
it could be something very cool, allowing to remove not only
progress_bar.sh 
but also all that du and time calls. 

It it also can improve the build performance due that no
other external 
programs or sub-shells need ve invoked, that idea is a
winner.

The issues that I can think on in this momment is about how
that program will 
be invoked. The console output drawing should start when
make start running a 
target. Disk usage need be meassured before unpacking a
package and before 
deleting the package sources build tree. And SBU is
calculated for the actual 
build and installation time. That meant three different
hocks points.


-- 
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.info
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:
> If you can do that that binary will be able to
calculate also disk space used, 
> it could be something very cool, allowing to remove not
only progress_bar.sh 
> but also all that du and time calls.

Hrm. That would be a challenge, but I suppose if we're going
to take it 
on we should try to get it all in one shot.

> The issues that I can think on in this momment is about
how that program will 
> be invoked. The console output drawing should start
when make start running a 
> target.

Yeah, that's the tough part. But with some careful thought
and a bit of 
research, I think we should be able to come up with
something.

> Disk usage need be meassured before unpacking a package
and before 
> deleting the package sources build tree.

Also after the package has been deleted, correct? So that we
know the 
size of what has been installed?

--
JH

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

El Jueves, 1 de Marzo de 2007 23:28, George Boudreau
escribió:

>
> It seems you cannot call a make function from within a
cmd shell ''. I
> thought I had removed these information calls but I
missed CLFS and HLFS

You can call a make function, but you need not use  and use
;  inside that 
make function.

See create-sbu_du-report LFS target and my last commits to
echo_report make 
function 

-- 
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.info
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

El Jueves, 1 de Marzo de 2007 23:30, Jeremy Huntwork
escribió:

>
> Also after the package has been deleted, correct? So
that we know the
> size of what has been installed?

That size is the same that the one meassured before
unpacking the next 
package 

-- 
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.info
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:
> That size is the same that the one meassured before
unpacking the next 
> package 
> 

Ah, of course. 

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