gmane.linux.lfs.automated

jhalfs permission problem

lich000king — 2012-05-03T08:54:38

Hi

 

After going through LFS stable and LFS current development by the book, I
wanted to try jhalfs. But I'm stuck at the beginning with permission
problems.

I already posted this to LQ, but didn't get any replies.

 

I get the following shortly after fetching the book:

 

###

You are going to log into the user account lfs

sudo requires a password

.bashrc: line 8: /mnt/lfs/jhalfs/envars: Permission denied

make[1]: *** [mk_LUSER] Error 1

make[1]: Leaving directory `/mnt/lfs/jhalfs'

 

<jhalfs 2.3.2> exit

 

make: *** [all] Error 2

###

 

I did edit the sudoers file to include

 

###

[username]    ALL=(ALL) NOPASSWD: ALL

###

 

for the host and lfs users and I also added

 

###

alias su='sudo su'

###

 

To all the users' .profile, none of this helped. It does not matter if I use
jhalfs 2.3.2 or svn version.

 

I'm using a compliant host based on an up-to-date Debian.

 

Does anyone have an idea, where the problem lies?

 

Thanks in advance!

 

Cheers,

Oliver

jhalfs not deal with the Chapter 9 of lfs

xinglp — 2012-05-12T20:11:11

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

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

xinglp — 2012-05-07T13:23:02

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.

host system requirements

Pierre Labastie — 2012-03-28T11:56:38

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

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

Pierre Labastie — 2012-03-17T12:58:12

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

jhalfs lost a endef

xinglp — 2012-03-15T10:27:39

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

bug, but good...

Pierre Labastie — 2012-02-27T11:28:17

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,
Pierre

jhalfs and the book xml

Peter Palmer — 2012-02-25T18:54:59

I'm just moving this to a new thread.
On 25 February 2012 14:11, Pierre Labastie <pierre.labastie< at >neuf.fr> wrote:
Long text below covers that :o)
Git is like a database that contains the whole development history of
a project. You can tell git to go back to earlier commits of other
developers etc. because you've got all that in your local repository.
If the online copy gets lost you can use your local copy to restore
that repository up to the state where you did your last fetch. It does
not stay updated automatically though.
SVN (so I believe) just syncs your current directory with the
repository without pulling all that metadata.
In both cases you can:
svn co / git clone
to get the initial download
svn up /git remote fetch
to bring your data up to date.
if you can ignore all the metadata, don't modify in the directory you
work on, the result is effectively the same.
My point is in reference to the SVN feature in jhalfs. Most people
want the snapshot of the data, they don't plan to do development work.
If you look from that point of view svn and git will look to you the
same.

May I propose two solutions (a short and a long one) to that problem.

Short: In menuconfig lets take all the options under 'release' out and
only leave the string field for the path to the book sources. Maybe
get some instructions into the help file where sources can be obtained
and get on with other things ;)

Long: On the other hand it would be nice having all the other options
working again. I had a look around anyway when I still thought 'set
git up' was a quick job. This is what I wrote earlier:

I am trying to remember the fist time I used jhalfs. I spent a lot of
time messing around with the download options because I assumed that
way I had the best chance to get a version of the book that works well
with jhalfs. To get to the point that I got the book myself and used
'working copy' took quite a while. I think this can and should be made
easier and more intuitive.

The SVN option... you say yourself you switched after the first
download to 'working copy'. I think having to do this is a workaround
to a bug though that is not obvious to a new user.
When working with the SVN (or any other) option we should tell the
user in the help what jhalfs is going to do in regard to updating
before starting a build that may take ... on a very slow computer as
long as days (CLFS still takes 12 hours here when run on one processor
core).

Moreover there is a funny bug:
The SVN download works fine on the first run.
Every subsequent run it does a 'svn up' but does not extract a new set
of scripts. So it does stay consistent with the initial download
_except_ if you delete the lfs build dir or... svn tips over - not an
unlikely thing if your network connection is not stable. I even tested
that because I couldn't believe I read the script right:

      if LC_ALL=C svn up | grep -q At && \
         test -d $JHALFSDIR/${PROGNAME}-commands && \
         test -f $JHALFSDIR/pkg_tarball_list ; then
        # Set the canonical book version
        echo -ne "done\n"
        cd $JHALFSDIR
        case $PROGNAME in
          clfs | clfs2 | clfs3 )
            VERSION=$(xmllint --noent
$BOOK/prologue/$ARCH/bookinfo.xml 2>/dev/null | grep subtitle | sed -e
's/^.*ion //'  -e 's/<\/.*//') ;;
          *)
            VERSION=$(xmllint --noent $BOOK/prologue/bookinfo.xml
2>/dev/null | grep subtitle | sed -e 's/^.*ion //'  -e 's/<\/.*//')
;;
        esac
        get_sources
      else
        echo -ne "done\n"
        extract_commands
      fi

The example above is by the way the only path where extract_commands
is not run by get_book. IMHO this should only run the first time or
when requested by selecting the option 'rebuild makefile' in the menu.
This needs to be implemented in a different way. But before that can
be done it needs to be clear what it's supposed to do. Please bear
with me and allow me to start from the top.

This is how it currently works: if you look at menuconfig there are
three choices in the release section (they are the same for everything
except BLFS and set the same vars in the configuration file by the
way):

1.SVN
2.Working Copy
3.Branch or stable

of these only #2 is working correctly. #1 as I already pointed out is
working correctly on the first run but does weird things if run
repeatedly. #3 is wired up in a way that it basically does the same as
#2 (and is thus currently redundant).

I think #2 is the main option for experienced users anyway and it's
working. Fine.

About #3... has anyone read the help for that and followed the link?
It is not clear what to enter. People will spend ages and get
frustrated trying to figure out what to do. Then when you read the
script this is actually all it does:
a. unnecessarily bomb out if you leave the default
b. exactly the same as #1

Here is my understanding how it should work:

1. establish we've got a book by
1.1 SVN - (should be renamed to 'development' to avoid confusion with
svn and git):
if !$local_copy_present
  svn co (or equivalent)
else
# New option on the menu 'update svn' that becomes available if we
select 'rebuild the makefile'.
  if $update_svn
    svn up
  fi
fi
1.2 Working copy
if !$local_copy_present
  tell_user_to_fix
fi

1.3 Branch or stable:
This needs to change on the menu.
a.) rename to 'stable' only. I expect only experienced users to work
with branches and they would want to use 'working copy' anyway.
b.) get rid of the string. Instead use radio buttons that point to
actual hardcoded stable releases.
c.) for the time being though take this option off the menu until we
have the code behind that in place.
And then:
if !$local_copy_present
  get_it
fi

2. Extract the version (use as sanity check of the book)
3. Only run extract_commands if we are (re-)building the whole makefile as well.
N. Do the rest

Pierre, you are probably aware that the code around get_book looks
very ... grown. I've got a fair understanding now of how the cogs and
wheels fit together so I started here pruning things a bit. I am quite
sure this is not in conflict with any of the blfs code so I hope there
are no issues with your work.

I am currently working on these files:

./Config.in
./jhalfs
./common/libs/func_book_parser

Thanks for your time,

Peter

Automated BLFS tool

Pierre Labastie — 2012-02-24T17:21:33

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,

Pierre

SBU report

Peter Palmer — 2012-02-23T22:19:47

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
< at >< at > -5,7 +5,8 < at >< at > set -e

 LOGSDIR=$1
 VERSION=$2
-
+DU1PREV=0
+DU1MBPREV=0
 LINE="================================================================================"

 # Make sure that we have a directory as first argument
< at >< at > -51,7 +52,7 < at >< at > free >> "$REPORT"
 BUILDLOGS="`grep -l "^Totalseconds:" ${LOGSDIR}/*`"

 # Match the first timed log to extract the SBU unit value from it
-BASELOG=`grep -l "^Totalseconds:" $LOGSDIR/* | head -n1`
+BASELOG=`grep -l "^Totalseconds:" $LOGSDIR/???-binutils | head -n1`
 echo -e "\nUsing ${BASELOG#*[[:digit:]]-} to obtain the SBU unit value."
 SBU_UNIT=`sed -n 's/^Totalseconds:\s\([[:digit:]]*\)$/\1/p' $BASELOG`
 echo -e "\nThe SBU unit value is equal to $SBU_UNIT seconds.\n"

Branching for new BLFS tool

Pierre Labastie — 2012-02-22T12:58:21

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

patch for downloading LFS tags version >6.x

Pierre Labastie — 2012-02-21T08:10:41

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

About subversion properties

Pierre Labastie — 2012-02-19T11:20:56

Well,
I just added the subversion property 'svn:keywords Id' to a few
files, some of which have been there much before I became
involved in jhalfs (in 'custom' dir). The result is that my name
appears as the Id, which was not the purpose. I guess Manuel
and/or George wrote them, and that their names should appear
instead. I suggest to add a line in the comments:
# Written by Manuel Esparcia and George Boudreau.
But maybe somebody has a better idea.

Regards
Pierre

RFC: Is there a use for blfs-tool?

Pierre Labastie — 2012-02-18T11:41:40

Hi,

When configuring jhalfs, the user is given the possibility
of choosing "Beyond Linux From Scratch" in the
"Use BOOK" menu. That basically disables all the settings you
have when running jhalfs, except the choice of
the Release and of a few directories needed for
blfs-tools. Then `blfs-tool' is run instead of
`jhalfs'. Basically, `blfs-tool' performs a few
checks, and sets up a "blfs_root" directory in
users's $HOME. It then launches make in that
directory.
All the preceding supposes that LFS is already
installed (with the BLFS dependencies, DocBook,
Lynx and friends). It does not much more than
what jhalfs does when ticking "Add blfs-tool support".
The only part which is missing after jhalfs is
moving "blfs_root" to user's $HOME, which is
not mandatory actually.
Furthermore, choosing blindly "Beyond Linux From Scratch" in the
"Use BOOK" menu on a non LFS system is potentially harmfull,
since you might end up installing BLFS packages on your
host system!
So my proposition is to remove altogether the
"Beyond Linux From Scratch" choice and the blfs-root script.
See attached patch.

Regards
Pierre

patch for avoiding warnings

Pierre Labastie — 2012-02-17T22:39:39

Following discussion on lfs-dev, here
is a patch which avoids most of the warnings in 000masterscript.log
There are still the last two warnings about packageManager.xml.
Maybe copy a dummy packageManager.xml to $JHALFSDIR when
not using package management.

Regards
Pierre

jhalfs's error log

xinglp — 2012-02-17T06:37:48

This is the log produced by jhalfs, some errors in it, but it worked
well when build lfs.

RFC: Remove GETKERNEL parameter

Matt Burgess — 2012-02-10T20:42:56

Hi all,

The kernel package has been required since LFS-6.3.  LFS-6.2 was
released 5.5 years ago, which was the last release when the kernel
package wasn't required until chapter 8.  As such, the attached patch
removes the ability to choose whether or not to download the kernel
package.

Regards,

Matt.

Catching GMP test failures

Matt Burgess — 2012-02-09T20:16:26

Hi,

Currently, jhalfs copies the exact command for invoking GMP's tests:

make check 2>&1 | tee gmp-check-log >> $TEST_LOG 2>&1

The problem with this is that the exit status of 'make check' is lost;
the exit status of 'tee' is what will cause the script to fail or not,
and that's pretty much never going to fail to run.

The attached patch changes the command to:

make check 2>&1 | tee gmp-check-log >> $TEST_LOG 2>&1 && exit
$PIPESTATUS

I'm doing a full build now to test it, but it at least generates what I
think is the correct command line.

Regards,

Matt.

JHALFS

George Boudreau — 2012-02-09T17:47:34

Hi guys,

It has been a while but it is nice to see the old JHALFS still has some 
users.

Nice work Pierre. The code is pretty convoluted for bash and even I 
would get lost on occasion and I wrote it --along with Manuel Esparcia--.

George Boudreau

Changing the logic of 'rebuild files'

Pierre Labastie — 2012-02-09T17:04:42

Hi,

When you tick 'rebuild files' and the build dir is empty, jhalfs exits
with an error. In the attached patch, I modify this logic.
The behavior remains the same if the directory is not empty.
When it is empty (or just contains "lost+found"),
the clean stage is skipped.

The patch contains also some cosmetic and corrects a typo.

Regards,
Pierre

patch for avoiding warnings when building mconf

Pierre Labastie — 2012-02-09T16:22:19

Hi,

Here is a patch, which modifies the code for the menu of jhalfs,
and avoids warnings when compiling.

Tested (no big changes, and actually cleaner code, I think).

Regards,
Pierre