HTML page for ALFS

Hi,

I have changed the ALFS HTML page, to make it similar to the wiki. I 
hope it gives up to date information.

I am of course open to any enhancement you would think of (although my 
limited knowledge of HTML will not allow me to do too fancy things).

I have also modified the wiki page for the supported books. Current 
jhalfs does not support {C,H}LFS anymore, and I updated the book 
versions with those I have tried.

Regards
Pierre

--

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

pending patches

Hi,
We have two pending patches:
One about the host requirements, which was postponed because it broke CLFS,
and one for exiting gracefully, with 2 versions (see the thread "ALFS 
Trac").

Shouldn't we come to some conclusion?
Regards
Pierre
--

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

Removing the BLFS tools function(s)

Unless you use very old versions of LFS/BLFS, the BLFS tool is broken in 
jhalfs trunk.

As suggested by Bruce, Those tools could be suppressed.

OTH, I have working (still improvable) BLFS tools in the ablfs branch. 
That branch does not change the behavior of jhalfs: I have built LFS 
several times. Wouldn't it be time to merge that branch with trunk?

Pierre
--

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

ALFS Trac

Hi,

I do not know who reads this list, but I have recently found that there 
was a "new" (January) bug report on the ALFS Trac.

It was about a minor typo and easy to fix (bug #1687). Bruce gave me the 
privileges on the ALFS Trac system, so that I could close that one.

OTH, I discovered quite a few other active bugs, mainly about nALFS and 
ALFS.

Maybe it is not my job, but I propose to close all the {n,}ALFS bugs as 
"wontfix", with a comment "{n,}ALFS is not developped anymore."

As of the few bug reports concerning jhalfs (2 active bugs), I have the 
following proposition:
- for #1686 "BLFS-Tools Error parsing XML dependencies of Xorg", I 
propose to close it as "wontfix", adding the comment "Jhalfs BLFS-Tools 
is not maintained anymore. Please use the ablfs branch: 
svn://svn.linuxfromscratch.org/ALFS/jhalfs/branches/ablfs"
- for #1680 "Review and extend jhalfs README", I propose to close it as 
"worksforme" with the comment:
"README has been improved a lot since this bug report has been filed. If 
you need further modifications, please reopen and tell us where we can 
improve more. Thanks"

Is it OK?

Regards
Pierre

separating tzdata and XML::Parser scriptlets

Although Armin seems to think otherwise, tzdata and
XML::Parser are not parts of respectively glibc and
Perl. So, if doing package management, they should be
packaged separately.

This is the reason why I'd like to separate the tzdata scriptlet
from that of glibc and same for XML::Parser.

I think I could achieve that with some modification of
lfs.xsl, but OTH, I do not want to begin coding if this is going
to be rejected by jhalfs users.

What I propose to do is adding one scriptlet for tzdata and
one (in the systemd branch) for XML::Parser. This should not
otherwise change what you are used to.

Please let me know whether I may go ahead.

Pierre
--

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

LFS-systemd branch fails Perl tests

Hi,

About 2 weeks ago, Armin merged the XML-Parser instructions in the
Systemd branch of LFS into the Perl page
(http://wiki.linuxfromscratch.org/lfs/changeset/10154).  When I run
jhalfs against a systemd branch working copy it ends up producing the
following commands for the Perl page:

echo "127.0.0.1 localhost $(hostname)" > /etc/hosts
sed -i -e "s|BUILD_ZLIB\s*= True|BUILD_ZLIB = False|"           \
       -e "s|INCLUDE\s*= ./zlib-src|INCLUDE    = /usr/include|" \
       -e "s|LIB\s*= ./zlib-src|LIB        = /usr/lib|"         \
    cpan/Compress-Raw-Zlib/config.in
sh Configure -des -Dprefix=/usr                 \
                  -Dvendorprefix=/usr           \
                  -Dman1dir=/usr/share/man/man1 \
                  -Dman3dir=/usr/share/man/man3 \
                  -Dpager="/usr/bin/less -isR"  \
                  -Duseshrplib
make
make -k test >> $TEST_LOG 2>&1 || true
tar xf ../XML-Parser-2.41.tar.gz
cd XML-Parser-2.41
perl Makefile.PL
make
make test >> $TEST_LOG 2>&1
make install
make install

Note how the 'make install' from the main Perl package has been moved to

alfs reports

I just noticed that we have an instruction in common/makefile-functions 
that says:

echo $(WHITE)Please send the $(BOLD)$(MOUNT_PT)/jhalfs/$(1)$(WHITE) ; \
echo file to $(BOLD)manuel <at> linuxfromscratch.org$(WHITE) ; \

We probably need to change that to jhalfs <at> linuxfromscratch.org and set 
up a method to automatically strip the report from the email and place 
it in a directory accessible via http.

We also need to review the echo_finished portion of the script and 
update it for teh current book.

   -- Bruce
--

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

jhalfs does not parse procps-ng test correctly

Hi,

The file /mnt/lfs/jhalfs/lfs-commands/chapter06/087-procps-ng
contains:
[...]
pushd testsuite
   sed -i 's|exec which sleep|exec echo /tools/bin/sleep|' config/unix.exp
   sed -i 's|pmap_initname\\\$|pmap_initname|'             
pmap.test/pmap.exp
   make site.exp
   DEJAGNU=global-conf.exp runtest
popd >> $TEST_LOG 2>&1
[...]
This is not what is wanted I guess...
I attach a patch which creates :
{ pushd testsuite
   sed -i 's|exec which sleep|exec echo /tools/bin/sleep|' config/unix.exp
   sed -i 's|pmap_initname\\\$|pmap_initname|'             
pmap.test/pmap.exp
   make site.exp
   DEJAGNU=global-conf.exp runtest
popd; } >> $TEST_LOG 2>&1

The last line has an additional || true if we should not stop on errors.

Let me know if I should commit it

Regards
Pierre

RFC: Continue CLFS support?

Wanted to open this up to the list for comments.

If you didn't know jhalfs has supported for a long time LFS, CLFS and
use to support HLFS, but support for that was discontinued sometime
ago. What I've noticed as of late is that most changes to jhalfs,
concern LFS. Now this is not a bad thing, but it does make me think
that the primary users are those from the LFS/BLFS crowd. I haven't
seen too much traffic from CLFS users.

Therefore the question is do we continue to maintain support for a
book that is hardly used or not??

Thomas
--

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

Exiting jhalfs cleanly

Hi,

With the new logic for creating /dev/shm, jhalfs does not
exit cleanly anymore. I attach a patch, which aims at curing that.

Can anybody else test it? For me, it seems to work.
Thanks
Pierre

Index: jhalfs/LFS/master.sh
===================================================================
--- jhalfs.orig/LFS/master.sh	2012-12-29 22:38:31.000000000 +0100
+++ jhalfs/LFS/master.sh	2012-12-30 16:03:48.000000000 +0100
 <at>  <at>  -512,15 +512,28  <at>  <at> 
 devices: ck_LFS ck_UID
 	sudo mount -v --bind /dev \$(LFS)/dev
 	sudo mount -vt devpts devpts \$(LFS)/dev/pts
-	sudo mount -vt tmpfs shm \$(LFS)/dev/shm
 	sudo mount -vt proc proc \$(LFS)/proc
 	sudo mount -vt sysfs sysfs \$(LFS)/sys
+	if [ -h \$(LFS)/dev/shm ]; then \\
+	  link=\$\$(readlink \$(LFS)/dev/shm); \\
+	  sudo mkdir -p \$(LFS)/\$\$link; \\
+	  sudo mount -vt tmpfs shm \$(LFS)/\$\$link; \\
+	  unset link; \\
+	else \\
+	  sudo mount -vt tmpfs shm \$(LFS)/dev/shm; \\
+	fi

lib64 is not removed when cleaning the LFS dir

Hi,

In the current jhalfs, lib64 is not removed when cleaning the build 
directory.
This has the effect that the command ln -sv lib /lib64 creates a symlink 
`lib'
pointing to itself inside the directory /lib (that is, there is a file 
/lib/lib).

Here is a simple patch which corrects this (and makes two lines out of a 
long one):
Index: jhalfs/common/common-functions
===================================================================
--- jhalfs.orig/common/common-functions 2012-02-22 22:11:47.000000000 +0100
+++ jhalfs/common/common-functions      2012-12-30 15:51:37.000000000 +0100
 <at>  <at>  -71,7 +71,8  <at>  <at> 
        if [ -d $BUILDDIR/sys ] ; then
          sudo rmdir $BUILDDIR/sys || exit 1
        fi
-      sudo rm -rf 
$BUILDDIR/{bin,boot,dev,etc,home,lib,media,mnt,opt,root,sbin,srv,tmp,tools,cross-tools,usr,var}
+      sudo rm -rf $BUILDDIR/{bin,boot,dev,etc,home,lib{,64},media,mnt}
+      sudo rm -rf 
$BUILDDIR/{opt,root,sbin,srv,tmp,tools,cross-tools,usr,var}
        echo "done"
        echo -n "Cleaning $JHALFSDIR ..."
        sudo rm -rf $JHALFSDIR

If no one speaks up, I'll commit it tomorrow.