jhalfs not deal with the Chapter 9 of lfs

and the ownership of /etc/lfs-release is not root
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Can I use jhalfs with an already exist "tools"?

I want to use an exist "tools" to save some time.
But the jhalfs only give BREAKPOINT but not STARTPOIN.
So, is there any way to do that?

Thanks.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

host system requirements

Hi,

Currently, the host version required for xz in the book is 5.0.3, which 
is the current stable and less than one year old. It is also what is 
enforced in jhalfs. It seems to me that 5.0.0 (2 years old) is enough, 
and I propose to only enforce that in jhalfs. Anybody against that?

Regards
Pierre

--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Should we strip all symbols in .so libraries when doing ICA?

Hi,

Presently, the ICA preparation step strips debug symbols from .o files 
and all symbols from
any other file. It means that it strips all symbols from .so libraries. 
This has been like that since G. Schaffer's
original ICA files were copied. But I wonder if we should not try to 
compare the .so libraries with all their non-debug
symbols.

Any thought?

Pierre
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

jhalfs lost a endef

lost a endef
svn di svn://svn.linuxfromscratch.org/ALFS/jhalfs/trunk -r3602:3603
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

bug, but good...

Hi,

In jhalfs, there is a supposed guard against the possibility of using
a partially or totally populated $LFS system, unless we ask to
rebuild the Makefile or to clean $LFS:
----------------
if [[ "$REBUILD_MAKEFILE" = "n" ]] ; then

   # If $BUILDDIR has subdirectories like tools/ or bin/, stop the run
   # and notify the user about that.
   if [ -d $BUILDDIR/tools -o -d $BUILDDIR/bin ] && [ -z $CLEAN ] ; then
     eval "$no_empty_builddir"
   fi
---------------
However "no_empty_builddir" is a function (defined in 
common/common-functions),
so that this guard does nothing. Seems to date back r3087, when jhalfs 
was imported
from experimental.

Actually, I am happy that it does not work. It allows me to restart a 
build after
a failure, just at the point where it failed, after modifying something 
which is not
necessary just Makefile.

So I wanted to ask:
Do we correct the bug, or do we suppress the guard

Regards,

jhalfs and the book xml

I'm just moving this to a new thread.
On 25 February 2012 14:11, Pierre Labastie <pierre.labastie <at> neuf.fr> wrote:
> Le 24/02/2012 20:20, Peter Palmer a écrit :
>> On 24 February 2012 16:45, Pierre Labastie<pierre.labastie <at> neuf.fr>  wrote:
>>> Le 24/02/2012 15:46, Peter Palmer a écrit :
>>>> On 24 February 2012 13:13, Pierre Labastie<pierre.labastie <at> neuf.fr>    wrote:
>>>>> I have seen that CLFS is now on git. Have you tried
>>>>> to replace svn instructions by "equivalent" git ones
>>>>> in jhalfs? I do not know much about git, but I know
>>>>> rather well jhalfs, so if I may be of some help...
>>>> First thanks to Thomas for giving me an early pointer to the problem I
>>>> introduced.
>>>>
>>>> I was just working on another patch but Pierre beat me to it. I don't
>>>> bother posting as the only difference is the name for the new variable
>>>> :)
>>> Sorry for that. I always think it is easier to explain with code...
>>>> I never worked with svn as vcs so I use git locally to work with
>>>> jhalfs. I've got one branch that I keep in sync with the svn trunk.
>>>> Branching is very easy in git so I create a branch for whatever
>>>> project I work on. To get the diff I just run:
>>>>
>>> Just to make sure we understood each other (I am not a native
>>> English speaker), I meant that jhalfs had some instructions to
>>> download on the fly the LFS book from SVN repo. I was not talking
>>> about managing jhalfs mods with GIT. Seeing how the philosophy
>>> of GIT is to have a local "working copy" (+ repo), those download
>>> instructions are maybe not necessary for CLFS.
>>>
>>> Since I am also busy with the blfs tools, I think I won't add GIT

Automated BLFS tool

Hi,

Many more tests are needed, but I think the new
BLFS tools are usable (alpha state). The repo is ablfs
(automated blfs). Just type:

svn co svn://svn.linuxfromscratch.org/ALFS/jhalfs/branches/ablfs

The instructions are in README and README.BLFS. Please
let me know if anything is confusing (well, I expect to receive
a lot of messages .

I have been able to build X (not tried to run it yet), but you need to
apply the attached patch to the blfs book. (ticket #3282). There
are also some options change to mesalib configure to avoid
trying to build the nouveau driver (or add it to libdrm).
Also llvm needs a 'source /etc/bash_profile' at the end.
AFAICT, all those come from book defects (or features  )
rather than from the tool. Note that there are no meta
packages, as in the former version of the tools. Just tick
Xorg Server, and it builds all the required dependencies.

Built also subversion, openssl, python. Please have a try for
other packages.
Contrary to the former tools, you can select as many targets
as you want, but the more you have, the more it gets complicated
to sort out bugs in the scripts.

Regards and happy builds,

SBU report

Hi,

here a tiny fist patch (from myself) to fix the SBU report that wasn't
running (current jhalfs svn and CLFS-1.2). I'm new to lfs/jhalfs
development so I hope the format and everything is right and usable.

Schedule of changes:

1. Variables needed initailising as perl was tipping over trying to
substract without that, i.e.:
INSTALLMB=`perl -e 'printf "%.3f" , ('$DU1MB' - '$DU1MBPREV')';`

2. The other change affects the selection of the very first entry of
the $LOGS directory. In CLFS this was a script that run in fractions
of a second... SBU is supposed to be based on the compilation time of
binutils though.

Any feedback appreciated.

Cheers,

Peter

#################################################
diff --git a/common/create-sbu_du-report.sh b/common/create-sbu_du-report.sh
index 115d95d..24ed5a6 100755
--- a/common/create-sbu_du-report.sh
+++ b/common/create-sbu_du-report.sh
@@ -5,7 +5,8 @@ set -e

Branching for new BLFS tool

Hi,

I have a new BLFS tool for jhalfs almost ready.
As already advertised, it seems to deal very well
with circular dependencies (with user input: your
distro, your rules...). Needs
just a few more tests for initialization. Of course it is
in alpha state! Almost all modifications are within BLFS
directory, but I have to slightly modify a few other
files in jhalfs tree, which I do not want to do on trunk.
So I propose to create a branch for some time, so
that adventurous people can test the new tool,
without modifying the usual behavior of trunk jhalfs.

Any thought?

Pierre

--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

patch for downloading LFS tags version >6.x

Hi
Here is what I propose. I'll commit tomorrow if no
comment.
Regards,
Pierre

Index: jhalfs/jhalfs
===================================================================
--- jhalfs.orig/jhalfs	2012-02-14 10:31:32.943065404 +0100
+++ jhalfs/jhalfs	2012-02-20 09:38:34.784101633 +0100
@@ -154,7 +154,14 @@
     ;;
   * )
     case $PROGNAME in
-      lfs | hlfs )
+      lfs )
+        LFSVRS=${BRANCH_ID}
+        TREE=tags/${BRANCH_ID}
+        if (( ${BRANCH_ID:0:1} < 7 )) ; then
+            TREE=${TREE}/BOOK
+        fi
+        ;;
+      hlfs )
         LFSVRS=${BRANCH_ID}
         TREE=tags/${BRANCH_ID}/BOOK
         ;;