Pierre Labastie | 26 May 10:55 2016
Picon

jhalfs for merged sysv-systemd

I've received a private message from Bruce about the adaptation of 
jhalfs to the upcoming merged sysv-systemd books.
I think it is better to start a public thread. But I wait for his 
approval for publishing his message.

I do not have much time today, but I'll try to look at Bruce's patch 
later. But please, to anybody who would like to contribute the code, may 
I suggest you produce patches against the most recent version (r3861 
fixed the hostreqs.xml move problem)?

Pierre

--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Cliff McDiarmid | 20 May 00:20 2016

How to setup systemd book

Hi
 
How do I ensure that jhalfs downloads the Systemd book and not the original book?   There seems to be no option to do this.  Can I download it myself and incorporate it?
 
thanks
 
Cliff
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Robert Duffy | 4 May 17:53 2016
Picon

jhalfs update for LFS 7.9

Hello!

I tried last jhalfs with the current LFS book 7.9 on a default and 
updated 64-bit Debian 7 host system and got this error. Does anybody 
know how to fix this error?

Building the system...
make[1]: Entering directory `/mnt/lfs/jhalfs'
--------------------------------------------------------------------------------
mk_LUSER
You are going to log into the user account lfs
sudo requires a password
make: Entering directory `/mnt/lfs/jhalfs'
--------------------------------------------------------------------------------
  Building target 039-gcc-pass2
  [++++++++\make: *** [039-gcc-pass2] Error 2                  ] 17 min. 
8 sec
make: Leaving directory `/mnt/lfs/jhalfs'
make[1]: *** [mk_LUSER] Error 2
make[1]: Leaving directory `/mnt/lfs/jhalfs'

ERROR: Error 2 at common/common-functions line 39!

<jhalfs-trunk> exit

make: *** [all] Error 2

Btw: The LFS book 7.6 works fine with last jhalfs.

Sincerely,
Robert Duffy
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Roger Koehler | 30 Mar 17:02 2016
Picon

package management

Kudos to Pierre! I am impressed with your work on package management in Jhalfs.

I just have some thoughts I'd like to share (if anybody ever reads this list):

Q1) Why would any LFS user want to use package management?

After all, according to the book, for any update in LFS (especially
Glibc), it is recommended that the entire LFS system be rebuilt (which
Jhalfs makes very easy, but it is still time consuming.

A1) To make the build faster!

For every package that DOES NOT need to be rebuilt, DON'T REBUILD IT!
Install the binaries that you saved instead!

In my opinion, package management can do for Jhalfs what Jhalfs did
for LFS -- make it much faster!

Q2) Which package manager would be best suited to satisfy this requirement?

Peirre seems to have settled on Debian's dpkg, but he has provided an
example for pacman as well. I don't know anything about pacman, but I
have enjoyed the ease of building a Debian system using dpkg, alt,
aptitude, and synaptic, and I was very impressed with Peirre's dpkg
solution in Jhalfs. I was so impressed in fact, that I tried to use it
to build some custom packages as well as the blfs_root dependencies.
This is where it bombs and requires more work than should be
necessary. I thought about converting all of the books instructions
into control scripts -- except for the actual binary tarball, but then
other issues are encountered. For example, dpkg complains when any
packages (such as Python2 and Python3) overlap.

A2) Porg!

If all that is desired is to make the installation of an LFS system
faster, porg (see http://porg.sourceforge.net/) is the way to go! Its
one line stated purpose is "to aid management of software packages
installed from source code."

Q3) How should it be implemented?

How can porg be used to make the installation of an LFS system faster?

A3) Only use it where "make install" or similar easily replaceable
instructions are found in the book.

... or in packages that use different build instructions but take long
enough to build to justify creating extensive xsl instructions to
replace them:

Simply search for an archived porgball that matches the version of the
package in the book's instructions. If it matches, use the porgball.
If it doesn't, build a new porgball first, then use it. Then take care
of all the necessary configuration as usual.

Nothing fancy required, and the benefits would be amazing!

Q4) How should it be implemented?

I am planning on using Pierre's example packageManager.xml.dpkg and
packInstall.sh.dpkg files to create porg versions to start, but this
would just create the packages.

A4) Create new LFS.xsl and master.sh files, and put them in the pkgmngt folder.

Also, change the function of the PKGMNGT configuration parameter to
use the new LFS.xsl and master.sh files.

SUMMARY:

What do you say, Pierre? How long would it take you to implement this
solution? I'm sure you are much more qualified to do this than I am,
but I'll plug away at it and see how far I get with my limited time
and know-how. I'm sure I will learn a lot in the process, but I will
happily throw it all away when your solution becomes available!

Thanks for reading,

Roger
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Tom Armistead | 14 Feb 21:48 2016
Picon

custom examples could use an update.


Hello,

     The example  files in jhalfs/custom/examples haven't been updated for some time.     I have some free time and would like to update them to the current state of things (BLFS 7.8).

Tom    
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
William Harrington | 28 Dec 03:09 2015

CLFS updates for clfs user .bashrc

Ahoy,

I have noticed some distributions, Slackware for one, which sets PKG_CONFIG_PATH, so when "su - clfs" is
given PKG_CONFIG_PATH from /etc/profile.d is set and wreaks havoc with some packages, namely make if
guile exists, and util-linux if ncursesw exists. Frankly, we always want to use our custom default path
for pkg-config in /cross-tools. Don't let the PKG_CONFIG_PATH spoil our fun. Patch is attached.

Index: CLFS/master.sh
===================================================================
--- CLFS/master.sh	(revision 3824)
+++ CLFS/master.sh	(working copy)
 <at>  <at>  -63,6 +63,7  <at>  <at> 
 	echo "" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "unset CFLAGS" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "unset CXXFLAGS" >> \$(LUSER_HOME)/.bashrc && \\
+	echo "unset PKG_CONFIG_PATH" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "" >> \$(LUSER_HOME)/.bashrc && \\
 EOF
 ) >> $MKFILE.tmp
Index: CLFS2/master.sh
===================================================================
--- CLFS2/master.sh	(revision 3824)
+++ CLFS2/master.sh	(working copy)
 <at>  <at>  -45,6 +45,7  <at>  <at> 
 	echo "" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "unset CFLAGS" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "unset CXXFLAGS" >> \$(LUSER_HOME)/.bashrc && \\
+	echo "unset PKG_CONFIG_PATH" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "export CLFS_HOST=\"${CLFS_HOST}\"" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "export CLFS_TARGET=\"${TARGET}\"" >> \$(LUSER_HOME)/.bashrc && \\
Index: CLFS3/master.sh
===================================================================
--- CLFS3/master.sh	(revision 3824)
+++ CLFS3/master.sh	(working copy)
 <at>  <at>  -45,6 +45,7  <at>  <at> 
 	echo "" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "unset CFLAGS" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "unset CXXFLAGS" >> \$(LUSER_HOME)/.bashrc && \\
+	echo "unset PKG_CONFIG_PATH" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "export CLFS_HOST=\"${CLFS_HOST}\"" >> \$(LUSER_HOME)/.bashrc && \\
 	echo "export CLFS_TARGET=\"${TARGET}\"" >> \$(LUSER_HOME)/.bashrc && \\

Sincerely,

William Harrington
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Pierre Labastie | 1 Nov 12:12 2015
Picon

RFC: Improvements of jhalfs for (C)LFS and BLFS

Hi,

I do not know who monitors this list, but I'd like to submit some ideas about
improving jhalfs, for both (C)LFS and BLFS. My initial idea was to put some
time in jhalf-BLFS improvement, but I think others might have ideas about
improvements to the (C)LFS part. Actually, I think of one: a few parts are
still hard coded and not read from the books (mainly chapter 4). They rarely
change, but it would be interesting to retrieve them from the books. I'll try
that first, but please feel free to add to that TODO.

Now, the BLFS part offers much more room for improvement:
- Pages with no version are not considered by the tool, but may be needed as
dependencies (for example CA certificates for p11-kit and gnutls), or to set
up the environment (for example "Configuring the JAVA environment" and
"Setting the PATH for TeX Live"). I think the <sect1info><date> tag could be
used as version for those pages.
- There is presently no way to know which bootscript to reinstall when the
bootscript tarball is modified. Having a file of installed bootscripts could
help (or maybe use the listing of "/etc/init.d").
- There is no way to build perl modules external (not in the book)
dependencies. It would be interesting to find a way to do that. The main
problem is that the book lacks version information for those dependencies, and
I am not sure it is easy to find the latest one.
- There is no automatic figure computation (SBUs and size). This would be easy
to install.
- There should be a way to store build logs, build scripts and possibly the
used dependency tree. Presently, they get destroyed when running make in the
blfs_root directory. OTOH, indexing those logs is not easy, since very often,
a list of packages is given to be built, and they each pull their
dependencies, so that the logs (same for the scripts and deps) are all grouped
in one unique directory, the naming of which can never be enough to retrieve
one particular package information.
- there is no DESTDIR install option. Installing in a DESTDIR would allow to
reuse the "package management" infrastructure of LFS-jhalfs, giving much more
flexibility to book testing (easy addition or removal of packages to test
dependencies for example).
- the Makefile is not optimal. Normally, there should be no need for ordering
targets, only the dependencies should be given, and make would manage to find
an order. The initial design was mimic what had been done with LFS (where the
book order is important), but I do not think it should be kept. It would be
much easier to add a target (for example a package which is not in the book).

Well, I am thinking of other things, but this is already a pretty long TODO...
Pierre
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bruce Dubbs | 2 Oct 00:17 2015
Picon

jhalfs needs to be updated for lfs-7.8

It wants libncursesw.so.5, but lfs-7.8 has libncursesw.so.6

The workaround of course is to copy .5 from an older build.  I didn't 
try, but it's possible a symlink from libncursesw.so.5 to 
libncursesw.so.6 might work.

   -- Bruce
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Michael Løjtnant | 20 Aug 01:22 2015
Picon

CLFS 3.0.0-systemd breaks on Chapter 76

Hi,

I'm trying to build a Pure 64-bit system using JHALFS and CLFS, but it 
breaks when it reaches Chapter 76-Choose.

I'm using the 3.0.0-systemd stable book, and chosen chroot for the Build 
method.

Host system is LFS-7.0.

JHALFS is latest development version

The build fails with this error:

---- Start build error:

Building the system...
make[1]: Entering directory `/mnt/lfs/jhalfs'
--------------------------------------------------------------------------------
         Executing Final Preparations Cross and Temporary Tools scripts
--------------------------------------------------------------------------------

make: Entering directory `/mnt/lfs/jhalfs'
--------------------------------------------------------------------------------
  Building target 076-choose
  [|make: *** [076-choose] Error 126                           ] 0 min. 
0 sec
make: Leaving directory `/mnt/lfs/jhalfs'
make[1]: *** [mk_F_PREPS] Error 2
make[1]: Leaving directory `/mnt/lfs/jhalfs'

ERROR: Error 2 at common/common-functions line 39!

<jhalfs-trunk> exit

make: *** [all] Error 2
[cosis <at> LFS70 jhalfs$

---- End Build error

Any suggestions on how to proceed from here?

Best regards
  Michael Løjtnant

--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
John D. Hendrickson | 2 Jul 20:50 2015
Picon
Picon

made a complete but different (jh)ALFS already - please offer on LFS and or discuss

I'd like this "AFS" to be a link with a small write-up on the LFS site 
please.  Also I would like to work with you all and hear advice on doing 
so.  All except for the negative funding part :)

http://sourceforge.net/projects/debguyscripts/files/build-0.1.2.tar.gz

build-0.1

Makes everything "%100 automatically" for a basic system: from 
libtermcap up to and including firefox-5.0, desktop and browsing ready 
when done.  350+ pkgs.

0) assumes you have linux kernel 2.6+ compiled

1) makes a chroot1 using some debinan sarge .deb
    (dpkg, debian not required: just lk 2.6)

2) builds core and makes chroot2 from initial pkg list

3) builds the rest inside chroot2

4) is able to boot as new / when done
    (actually, here is where user gets to move around
     their dirs - that one job is wisely left undone)

5) its a nice build environment because it's simple:
    it works pretty well in across resets when things go wrong
    because it's just a simple sh script that knows
    you'll be stopping and starting (if adding new fixes)

*) does not come with /boot or /etc, use your own
    (and really dont install a new grub if your old one works!)

** if nothing else it may help you or others with
    build methods or build options of some 350+ pkgs
    (infact, as it goes it records what it uses for use at sh prompt)

** making only 350+ its missing allot: ie, libdb2.  but that can be
    borrowed from (debian squeeze, sarge, even slackware) bins

README.build-0.1 has 1-2-3 instructions which I myself have followed 
successfully a few times now (no detours, it worked).

"build" is simple sh script that: downlods pkgs, makes chroots, builds. 
  It's mostly straight down: no complex functions or other programs, 
just simple readable sh (which can do all fixing up make(1) cannot do to 
get the job done).

GNU/Linux is what I call it ;)  It begins with "a well know starting 
point" and is CAREFUL that none of "debian sarge" gets into chroot2. 
 From there things build right because it is based on exact versions and 
default install of GNU/Linux (gcc, glibc, etc).  About 150 out of 350 
have fixes applied, while the others are good with just default 
configure options.

CAVEATE:  most versions are intently similar to Debian Squeeze (around 
year 2010) - and run debian squeeze/sarge bins where there's no conflicts*

* (ie, if squeeze depends on pam, and if pam is not built: which doesn't 
effect things like xpdf, route, pnmtops, etc)

Motivation:

I didn't like the build options debian/bsd admins began using - nor the 
direction of deleting inetd for systemd or moving toward deleting X11 
for Wayland: and it damages software i already $purchased.

Flat out I needed to have a system where if someone (attacked) a feature 
I relied on - I could patch in code that bypasses / works it.

Also: for debain (i'm kinda hooked on linux kernel) I found no clear way 
to build from scratch - that making a "build server" was not something i 
though would "be easy once installed" (i rather like the freeBSD Make 
world build system, other things aside).  Ie, when i try building a pkg 
from source.iso as their directions suggest: i often get build failures 
- it's too complex.  Their sources assumes a build server  environment 
that has magic which may need packages to build more than once to 
"finally build".   (some src pkgs build easy: some need hacking, due to 
this).  Worse: I THINK they are putting some old sources and bins in NEW 
distros: meaning ... the binary still works but in the new debian the 
source no longer builds and they call this "depreciated" or "needs help 
/ unmaintained / may be removed".  (that's a great argument to use 
freeBSD: but look at their bug list - users somehow end up with a 
mountain of problems getting a "stable distro" to compile from scratch 
these days - not like the days of stable freeBSD from what i heard)

Finally I'd really prefer freeBSD if it weren't for the two things:

1) freeBSD doesnt contain much of linux kernel yet nor freeBSD in linux
    and oppositely not enough freeBSD in linux

2) freeBSD admins are also hacking in "admin favorites" (pam pam pam)
    the sum of getting rid of opts I didnt want to have a basic unix
    system: is adding up to being more time and effort than making one
    from scratch.  too many whistles and bells to manage to get rid of.

3)  my motto i think would be: dont give users trouble
     that they didnt ask to get into :)
--

-- 
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Pol Vangheluwe | 4 Jun 09:04 2015
Picon

segmentation fault when chrooting

I already built several times LFS (6.4, 6.6, 6.8 and 7.2) manually (on old Apple PowerPC computers).  This takes every time several months, because I do it in my sparse free time.
I recently found a second-hand PowerMac G4 (MDD) and decided to try ALFS on this machine (starting from Ubuntu 14.04.2 LTS).
Documentation about ALFS is quite limited, but anyway, I managed to start the building process with the following options:

Checking tools required for jhalfs
SUDO.............. <1.8.9p5>             OK (Min version: 1.7.0)
WGET.............. <1.15>                OK (Min version: 1.0.0)
LIBXML2........... <2.09.01>             OK (Min version: 2.06.20)
LIBXSLT........... <1.01.28>             OK (Min version: 1.01.14)
------------------------------------------------------------------------------

BOOK.............. </mnt/build_dir/jhalfs/lfs-branch-systemd>
CUSTOM_TOOLS...... <n>
BLFS_TOOL......... <n>
LUSER............. <lfs>
LGROUP............ <lfs>
LHOME............. </home>
BUILDDIR.......... </mnt/build_dir>
CLEAN............. <n>
GETPKG............ <y>
SRC_ARCHIVE....... </mnt/build_dir/archive>
SERVER............ <ftp://ftp.lfs-matrix.net>
RETRYSRCDOWNLOAD.. <y>
RETRYDOWNLOADCNT.. <3>
DOWNLOADTIMEOUT... <30>
RUNMAKE........... <y>
TEST.............. <1>
BOMB_TEST......... <n>
STRIP............. <y>
VIMLANG........... <n>
FSTAB............. <>
CONFIG............ <>
TIMEZONE.......... <GMT>
PAGE.............. <A4>
LANG.............. <nl_BE <at> euro/ISO-8859-15>
INSTALL_LOG....... <n>
PKGMNGT........... <n>
FULL_LOCALE....... <n>
COMPARE........... <n>
OPTIMIZE.......... <0>
REPORT............ <y>
REBUILD_MAKEFILE.. <n>

The building process was a few times aborted during compilation of gcc (pass-1).  I could fix it by extending ulimit and restarting ‘make’.
I am now in CHROOT, compiling 082-gcc-5.1.0 and again facing an abort.  However, I cannot proceed anymore because of this:

------------------------------------------------------------------------------

Creating Makefile... START
Processing... <Chapter4     ( SETUP ) >
Processing... <Chapter5     ( LUSER ) >
Processing... <Chapter6     ( CHROOT ) >
Processing... <Chapter7/8   ( BOOT ) >
Creating Makefile... DONE
------------------------------------------------------------------------------


KERNEL............ <3.13.0-51-powerpc-smp> OK (Min version: 2.6.32)
BASH.............. <4.3.11(1)-release>   OK (Min version: 3.2)
GCC............... <5.1.0>               OK (Min version: 4.1.2)
G++............... <5.1.0>               OK (Min version: 4.1.2)
GLIBC............. <2.21>                OK (Min version: 2.11)
BINUTILS.......... <2.25>                OK (Min version: 2.17)
TAR............... <1.28>                OK (Min version: 1.18)
BZIP2............. <1.0.6>               OK (Min version: 1.0.4)
BISON............. <3.0.2>               OK (Min version: 2.3)
COREUTILS......... <8.23>                OK (Min version: 6.9)
DIFF.............. <3.3>                 OK (Min version: 2.8.1)
FIND.............. <4.4.2>               OK (Min version: 4.2.31)
GAWK.............. <4.1.2>               OK (Min version: 4.0.1)
GREP.............. <2.21>                OK (Min version: 2.5.1a)
GZIP.............. <1.6>                 OK (Min version: 1.3.12)
M4................ <1.4.17>              OK (Min version: 1.4.10)
MAKE.............. <4.1>                 OK (Min version: 3.81)
PATCH............. <2.7.5>               OK (Min version: 2.5.4)
PERL.............. <5.20.2>              OK (Min version: 5.8.8)
SED............... <4.2.2>               OK (Min version: 4.1.5)
TEXINFO........... <5.2>                 OK (Min version: 4.7)
XZ................ <5.2.1>               OK (Min version: 5.0.0)
------------------------------------------------------------------------------

Building the system...
make[1]: Entering directory '/mnt/build_dir/jhalfs'
--------------------------------------------------------------------------------
mk_CHROOT
You are going to CHROOT into /mnt/build_dir lfs
a password is required
/tools/bin/bash: line 1:  5666 Segmentation fault      (core dumped) make BREAKPOINT= CHROOT
Makefile:87: recipe for target 'mk_CHROOT' failed
make[1]: *** [mk_CHROOT] Error 139
make[1]: Leaving directory '/mnt/build_dir/jhalfs'

ERROR: Error 2 at common/common-functions line 39!


<jhalfs-trunk> exit

Makefile:11: recipe for target 'all' failed
make: *** [all] Error 2

Chrooting manually is no problem:

lfs <at> ppc125:~$ sudo chroot "$LFS" /tools/bin/env -i \
> HOME=/root \
> TERM="$TERM" \
> PS1='\u:\w\$ ' \
> PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
> /tools/bin/bash --login +h
[sudo] password for lfs: 
root:/# pwd
/
root:/# ls -l
total 120
drwxrwxr-x  2 1001 1001  4096 May 28 14:57 archive
drwxr-xr-x  2 root root  4096 Jun  1 19:26 bin
drwxr-xr-x  2 root root  4096 Jun  1 19:26 boot
drwxr-xr-x  2 root root  4096 Jun  1 19:26 dev
drwxr-xr-x  4 root root  4096 Jun  1 22:47 etc
drwxr-xr-x  2 root root  4096 Jun  1 19:26 home
drwxrwxrwt  7 1001 1001  4096 Jun  2 20:35 jhalfs
drwxr-xr-x  4 root root  4096 Jun  1 22:47 lib
drwx------  2 root root 16384 May 14 16:31 lost+found
drwxr-xr-x  4 root root  4096 Jun  1 19:26 media
drwxr-xr-x  2 root root  4096 Jun  1 19:26 mnt
drwxr-xr-x  2 root root  4096 Jun  1 19:26 opt
drwxr-xr-x  2 root root  4096 Jun  1 19:26 proc
drwxr-x---  2 root root  4096 Jun  1 19:26 root
drwxr-xr-x  2 root root  4096 Jun  1 19:26 run
drwxr-xr-x  2 root root  4096 Jun  1 22:44 sbin
drwxrwxrwt  4 1001 root  4096 Jun  2 20:34 sources
drwxr-xr-x  2 root root  4096 Jun  1 19:26 srv
drwxr-xr-x  2 root root  4096 Jun  1 19:26 sys
drwxrwxrwt  2 root root 20480 Jun  2 04:00 tmp
drwxr-xr-x 12 root root  4096 May 31 21:01 tools
drwxr-xr-x 10 root root  4096 Jun  1 19:26 usr
drwxr-xr-x 10 root root  4096 Jun  1 19:26 var

Any suggestion how I can fix this and continue with ALFS?


pvg


--

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

Gmane