Re: ICA/Farce

[Ken Moffat]

On Sun, Oct 26, 2008 at 08:45:40PM -0500, DJ Lucas wrote:
> 
> Anyway, I killed the build I was working on.  Given the Ken's 
> description of current Farce, I'm not sure that both can run on the same 
> system and have meaningful results.  I'd really like to do a sanity 
> check on the development LFS.  A positive ICA run would do us very well 
> to prove that the old build method is at least still working, even 
> though it is dated. 
> 
 Well, since Greg has said that the 4.3 gcc builds have lost the
randomness he was seeing, maybe farce will again be usable.

 Farce extects you to tar up the system at the end of the build.
I've certainly used it for 3-run testing in the past.

 I don't think I've looked at the details of Greg's ICA since I
wrote farce, so I can't comment on how it works but provided you can
tar everything up at the end of each build, before resuming the next
stage of ICA in jhalfs, you should be able to use the same build.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: ICA/Farce

[Ken Moffat]

On Mon, Oct 27, 2008 at 06:51:38AM -0700, Dan Nicholson wrote:
> On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer <[EMAIL PROTECTED]> wrote:
> >
> > I've never looked at jhalfs but I understand it implements my ICA
> > algorithms. My own scripts have been getting exceptionally clean
> > results lately now that the randomness in GCC builds has apparently gone
> > as of GCC 4.3. I'll happily check any results you can post up.
> 
> I'm obviously out of the loop on building toolchains, but the most
> recent ICA issues with gcc was that a checksum of the .o files was
> built into the gcc binary. Since DIY uses LDFLAGS="-s", the .o files
> are stripped as they're linked. The checksum for the .o files is then
> always the same since the debug symbols are gone when the checksum is
> taken. In LFS, the stripping is always done after the fact, but by
> then the checksum has been built into the binary. But, that was a
> couple releases ago.
> 
 I no longer remember the details (it was too long ago), but I
_think_ what I was seeing was different object code somewhere (I had
the impression it might be moving things at random).  Perhaps only
on 64-bit builds.  I got rid of all my local farce workfiles earlier
this month, so I have no data. [ engages brain, goes off to look for
the mail from archaic to see if it will help ... ]

 Archaic saw unresolved differences for x86 with gcc-4.1.2.
Actually, looking at his results (they're at ~/archaic) they look
pretty good - blkid.tab.old and locale-archive should probably now
be expected to differ, and they were the only differences between
his second and third builds.

 Between his first and second builds, he also had differences in cc1
and cc1plus (maybe down to the checksums), libstdc++.la and
libsupc++.la (the path on one pair has some unnecessary repeats),
nscd, and coreutils.info.  The info file was encoding
the version of makeinfo it was using, and build one seems to have
used the host's version.  I think we maybe altered something to fix
that.  Nscd is a different matter.

 My own notes show that c++ programs and libraries were showing
differences I couldn't adequately explain, and I was marking these
as 'expected' for programs like lynx (it's not in the base LFS).

 I'm not sure I like building with LDFLAGS=-s for general use,
anything that helps get a backtrace might be valuable.  But for a
system only used for analysis, it wouldn't be a problem.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: ICA/Farce

[Ken Moffat]

On Mon, Oct 27, 2008 at 06:36:07PM +0100, Gilles Espinasse wrote:
> Selon Ken Moffat <[EMAIL PROTECTED]>:
> 
> ...
> >
> >  Archaic saw unresolved differences for x86 with gcc-4.1.2.
> > Actually, looking at his results (they're at ~/archaic) they look
> > pretty good - blkid.tab.old and locale-archive should probably now
> > be expected to differ, and they were the only differences between
> > his second and third builds.
> >
> locale-archive is a file influenced by gzip -n flag when glibc compress locale
> files.
> When the locales compressed files no more include the timestamp, 
> locale-archive
> checksum no more change.
> 
> That's what I found recently.
> 
> Gilles

 Interesting.  I'm tempted to ask how you discovered this, but since
glibc scares me to death at the best of times, I wont ;-)

 Do you have a way of either altering the build (for testing builds)
to remove the timestamp, or do you have a way of breaking out the
archive contents to compare them ?

 Last time I looked, google knew nothing about it, and 'file' still
thinks it's some sort of PDP-11 thing.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: ICA/Farce

[Ken Moffat]

On Mon, Oct 27, 2008 at 10:15:31AM -0700, Dan Nicholson wrote:
>  In farce, Ken had some
> functions that would skip these stamps, but I don't recall how he
> implemented that.
> 
 For gzipped files, just cmp -s -i 8 (the comment says bytes 4,5,6,7
are the timestamp, hopefully everything ahead of it is the magic).

 At least you aren't asking me to explain the perl regexp which
converts known text patterns (kernel version, date and time).

 That's the sort of thing that might need updating for new date
formats in updated packages.  From memory, some of those date-format
differences took a long while to show up and depended in part on
things like rebuilding in a different month or different timezone
(the return to non-summertime in Europe was yesterday, so probably
missed that).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: blfs svn, libglade errors

[Ken Moffat]

On Mon, Oct 27, 2008 at 10:39:01PM -0400, Brittany Dunlap wrote:
> I've followed BLFS svn mostly to a T except for the fluxbox version I
> installed and probably a few other top-level apps.  I'm working on
> getting GDM installed but the dependency libglade (dependency to
> libgnomecanvas) is having some issues. There is more to what is below
> but it's of the same format. If anybody can shed some light on this
> subject It'd be greatly appreciated. Thanks!!
> 
> .libs/glade-init.o:/usr/include/glib-2.0/glib/gutils.h:347: first defined here
> .libs/glade-gtk.o: In function `g_trash_stack_height':
> /usr/include/glib-2.0/glib/gutils.h:356: multiple definition of
> `g_trash_stack_height'
> .libs/glade-init.o:/usr/include/glib-2.0/glib/gutils.h:356: first defined here
> .libs/glade-gtk.o: In function `g_bit_storage':
> /usr/include/glib-2.0/glib/gutils.h:304: multiple definition of 
> `g_bit_storage'
> .libs/glade-init.o:/usr/include/glib-2.0/glib/gutils.h:304: first defined here
> collect2: ld returned 1 exit status
> make[2]: *** [libglade-2.0.la] Error 1
> make[2]: Leaving directory `/sources/libglade-2.6.1/glade'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/sources/libglade-2.6.1'
> make: *** [all] Error 2
> root [ /sources/libglade-2.6.1 ]#
> 
> Brittany Dunlap
> bdunlap at #lfs-support
Hi Brittany,

 You'll probably do better asking on -support.  Meanwhile, google
found the following:
http://www.linux-archive.org/fedora-development/27954-gxine-mass-rebuild-status-gcc-4-3-0-0-4-rawhide-20071220-a.html

 Are you using a version of gcc later than 4.1.2 ?

 The desktop in BLFS svn has barely moved on from the old versions
for 6.3.  The key phrase in that link is "most of them are just
C++ being stricter".  In other words, newer versions will be more
likely to work.  You could try glade-2.6.3 (works for me with
gcc-4.2.4 and *current* glib-gtk-atk-pango-cairo).  If that doesn't
help, all I can do is suggest you will need to use a mostly newer
set of packages.  I posted a link to my notes yesterday, they are at
http://www.linuxfromscratch.org/~ken/new-desktop-late-2008-first-attempt.gz
 (I gave up on current gdm, it needs things I don't want, and kept
to gdm-2.18.something which still needs libgnomecanvas).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: gcc-4.3.2 build fails

[Ken Moffat]

On Sun, Nov 02, 2008 at 01:55:25AM -0800, Trent Shea wrote:
> On Saturday 01 November 2008 23:59:36 John Frankish wrote:
> > If I understand correctly, due to the fact that the ps3 has a 64-bit
> > cpu/kernel and 32-bit os, I would need to cross-compile to get either
> > a 64-bit os or a 32-bit os? Which would be better to use on the host
> > system - the ydl-6 gcc-4.1.1. or IMB cell SDK-3 ppu-gcc?
> 
> I don't have any experience with this; I have not looked at the cell 
> processor in any great detail, but if it is anything like the amd64, 
> which allows you to run 32bit kernel/os, you should be able to boot a 
> 32bit distro and build away following the LFS instructions.
> 
 Or, if it's anything like the various versions of the 970 ('G5' in
apple speak) the kernel will refuse to build unless you set it for
64-bits (and have a 64-bit (cross-) gcc (C only) and binutils.

 I've done that in the past for ppc (32) userspace on ppc64.  Some
packages in the base system may produce obscure issues doing that,
so not all of my builds succeeded.

> Whichever you choose it will have to be based on a little bit of 
> research, and usage analysis.
> 

 Dunno about the usage analysis (a lot of us build our own systems
"because we can" or "because it's there"), but research is
definitely needed.  'linux32' can be helpful if configure thinks
it's on a 64-bit machine.

 As was said earlier, clfs might be (a little) more useful - I'm not
willing to talk about the detail here, it's definitely O/T (we
haven't even got x86_64 into LFS yet).

 For a machine with only limited memory, I guess building a 32-bit
userspace is probably a lot more practical than 64-bit (e.g. the
toolchain packages build much bigger files on 64-bit powerpc than on
x86).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: current pkg-config looks for gtk-config and glib-config for 1.x

[Ken Moffat]

On Tue, Nov 11, 2008 at 01:17:31AM -0600, DJ Lucas wrote:
> I had completely forgotten about gtk1 and made a typo, but I find this 
> to be very sloppy:
> 
> [EMAIL PROTECTED] gtk+-2.14.4]# pkg-config --libs gtk+
> sh: gtk-config: command not found
> sh: gtk-config: command not found
> sh: gtk-config: command not found
>  
> [EMAIL PROTECTED] gtk+-2.14.4]# pkg-config --libs gtk+-2.0
> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 
> -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lz 
> -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0  
> [EMAIL PROTECTED] gtk+-2.14.4]#
> 
> Same thing for glib.  Should this be fixed at this point?
> 
 Funnily enough, I came near the glib-1 part of this yesterday, as
part of investigating things which ship their own copies of other
libraries.  In the end, I concluded that did no harm: it only uses
its copy of glib-1 to provide a static lib for itself, which is
perfctly acceptable.  The "workaround" for missing .pc files using
these long-obsolete -config files is just part of the program's
history.

 The main use of pkg-config is from within a configure script.  I
agree that it looks odd, but changing it risks damaging working
builds for people who still use the obsolete versions.  To me, it's
not worth spending time on.  YMMV.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: gmp required ABI=32

[Ken Moffat]

On Wed, Nov 12, 2008 at 07:26:14AM +1100, Greg Schafer wrote:
> Tobias Gasser wrote:
> 
> > i had to add ABI=32 as my system was identified ad 64bit.
> > 
> > ./configure ABI=32 --prefix=/usr --enable-cxx --enable-mpbsd
> > 
> > i'm using CFLAGS="-O3 -march=i486" as a global setting, overwritten for 
> > some special cases mentionned in the book.
> > 
> > any idea why i have to add ABI=32 ???
> 
> You're on 64-bit capable hardware? I brought this up here about a month
> ago, and over 2 years ago on the GCC list. I'm surprised more people
> haven't hit it:
> 
> http://article.gmane.org/gmane.linux.lfs.devel/7762
> 
 My box built gmp and the first part of chapter 6 during the night
without any apparent problem.  The host system was LFS-6.3 with a
current kernel.

[EMAIL PROTECTED] ~ $uname -a
Linux ac30 2.6.27.5 #1 Sun Nov 9 19:53:29 GMT 2008 i686 AMD
Athlon(tm) 64 Processor 4000+ AuthenticAMD GNU/Linux

 From the build log for gmp:
checking build system type... athlon64-pc-linux-gnu
checking host system type... athlon64-pc-linux-gnu
checking for a BSD-compatible install... /tools/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of
Makefiles... no
checking ABI=64
checking compiler gcc -O2 -m64 ... no
checking ABI=32
checking compiler gcc -m32 -O2 -fomit-frame-pointer ... yes
...
using ABI="32"
  CC="gcc"
  CFLAGS="-m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8"
  CPPFLAGS=""
  CXX="g++"
  CXXFLAGS="-m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8"
  MPN_PATH=" x86/k7/mmx x86/k7 x86 generic"
checking for function prototypes... yes
(etc)

 This implies Tobias has both a compiler and libc in chroot that are
able to handle -m64.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: gmp required ABI=32

[Ken Moffat]

On Wed, Nov 12, 2008 at 09:32:16PM +1100, Greg Schafer wrote:
> Ken Moffat wrote:
> 
> >  My box built gmp and the first part of chapter 6 during the night
> > without any apparent problem.  The host system was LFS-6.3 with a
> > current kernel.
> 
> I just looked into this. It appears the bug only tickles when CFLAGS are
> set. ie: if CFLAGS are set in the environment, it guesses the wrong ABI
> when building 32-bit x86 on 64-bit AMD hardware (not sure about Intel).
> You can easily reproduce this by setting CFLAGS then running ./configure.
> Issue is exacerbated due to GMP's "tricked up" config.guess ie:
> 
> $ ./config.guess
> athlon64-pc-linux-gnu
> $ /usr/share/libtool/config/config.guess
> i686-pc-linux-gnu
> $ /usr/share/automake-1.10/config.guess
> i686-pc-linux-gnu
> 
> The CFLAGS aspect at least explains why everyone is not seeing this.
> 
> >  This implies Tobias has both a compiler and libc in chroot that are
> > able to handle -m64.
> 
> No. See above.
> 
> Regards
> Greg
 Agreed.  Thanks for the analysis.  With CFLAGS=-O2 it now shows

checking ABI=64
checking compiler gcc -O2 ... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
...
using ABI="64"
  CC="gcc"
  CFLAGS="-O2"
  CPPFLAGS=""
  MPN_PATH=" x86_64 generic"

and continues until

checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP
the
intended ABI, see "ABI and ISA" in the manual.

 So, I suppose we ought to warn people, and tell them to add ABI=32
if they are using their own CFLAGS on an AMD_x86_64 ?

 Anyone got a 64-bit-capable intel to confirm if those are also
affected ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

hang in gettext tests

[Ken Moffat]

 In my build of 6.4-rc1, the box was hanging, apparently for more
than 10 minutes, in the gettext tests.  Last thing in the log was
make[3]: Entering directory
`/building/gettext-0.17/gettext-runtime/tests'
Starting test_lock ... OK
Starting test_rwlock ...

 I killed it with ^C, then took a look around.  Deleted test_lock
and test_lock.o in gettext-runtime and gettext-tools/gnulib-tests,
reran make check, again it hung.

  I guessed that I might be able to turn the debugging on with
CFLAGS=-DENABLE_DEBUGGING=1 (didn't seem to add debugging output)
but the tests sailed through.  Deleted the test_lock files, repeated
without attempting to enable debugging, again sailed through.

 Back to the script, put a tail -f on the log: halted on

test_rwlock, but showed an interruptmake[3]: Entering directory
`/building/gettext-0.17/gettext-runtime/tests'
Starting test_lock ... OK
Starting test_rwlock ...make[3]: *** [check-TESTS] Interrupt
make[2]: *** [check-am] Interrupt
make[1]: *** [check-recursive] Interrupt
make: *** [check-recursive] Interrupt

 and there it appeared to be stopped while I was writing up my
notes, until I realised it had moved on to the next package.  The
test log now shows
Starting test_lock ... OK
Starting test_rwlock ... OK
Starting test_recursive_lock ... OK
Starting test_once ... OK
PASS: test-lock
==
All 1 tests passed
==

 followed by the main tests (1 FAIL in format-c-5 FWIW).

 Strange.  Maybe it will never happen again.  Maybe it will always
get through if left for a sufficiently long time.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Is LFS 6.4 ready for release?

[Ken Moffat]

On Wed, Nov 12, 2008 at 11:00:32AM -0600, Randy McMurchy wrote:
> Bruce Dubbs wrote:
> > I don't know of any outstanding issues except the GMP issue with some 
> > combinations of hardware and CFLAGS setting.  Although we recommend not 
> > using 
> > CFLAGS, that could be addressed with a note.
> 
> It has not even been one week since the RC1. I don't think that
> is enough time. I would wait a bit, especially if there are not
> going to be any more RC versions.
> 
> Unless of course, you are in a *hurry* to get it done.
> 
 Yeah, what's the rush ?

 My build of chapter 6 finished this morning, I haven't yet had time
to look at the test results, beyond the one oddity I reported.

 At the moment, it's doing an in-place rebuild so I can see if
'farce' is again usable.  Didn't get very far, my script installs
the docs for gmp and I forgot to change 'mkdir -v' to 'mkdir -vp' in
my script.

 Completing the build to a point where I can boot it will probably
take me a few days, I've not yet got to the end of my list of things
to look at for my new desktop, and I now build a lot before
rebooting, so don't wait on my account if you're in a hurry.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Version in glibc

[Ken Moffat]

 For a long time, distros have patched glibc to show the distro's
details when you run /lib/libc.so.6 - this is typically encountered
when people report a bug to the kernel list and run scripts/ver_linux
from the kernel tree.

 Now that glibc no longer has official releases, we are just using a
weekly snapshot which happens to work well (at least, as far as test
results are concerned).

 I've applied the following patch to my glibc:

--- glibc-2.8-20080929/version.h.orig   2008-11-05 03:42:01.0 +
+++ glibc-2.8-20080929/version.h2008-11-05 03:42:22.0 +
@@ -1,4 +1,4 @@
 /* This file just defines the current version number of libc.  */
 
 #define RELEASE "stable"
-#define VERSION "2.8"
+#define VERSION "2.8-20080929-LFS"

 which gives the following from libc.so.6:
GNU C Library stable release version 2.8-20080929-LFS, by Roland
McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
Compiled on a Linux 2.6.27.5 system on 2008-11-12.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
.

and the following from ver_linux:
Linux ac30 2.6.27.5 #1 Sun Nov 9 19:53:29 GMT 2008 i686 athlon-4
i386 GNU/Linux
 
Gnu C  4.3.2
Gnu make   3.81
binutils   2.18
util-linux 2.14.1
mount  support
module-init-tools  3.4.1
e2fsprogs  1.41.3
Linux C Library2.8-20080929-LFS
Dynamic linker (ldd)   2.8-20080929-LFS
Linux C++ Library  6.0.10
Procps 3.2.7
Kbd1.14.1
Sh-utils   6.12
Modules Loaded via_velocity crc_ccitt

 Is there any interest in doing something like this ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Vim man pages

[Ken Moffat]

 Me again!

 I seem to have an excess of man pages from vim.  It's possible I've
fubar'd something when I removed my own "everything UTF-8" commands,
it's equally possible vim has always done this duplication.  So I'll
start by asking if other people have this:

fr pages in man/fr man/fr.ISO8859-1 man/fr.UTF-8
it pages in man/it man/it.ISO8859-1 man/it.UTF-8
pl pages in man/pl man/pl.ISO8859-2 man/pl.UTF-8
ru pages in man/ru.KOI8-R man/ru.UTF-8

 Each of these is a full set.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

6.4-rc1 test results

[Ken Moffat]

 Such as they are, here are the things I noted from my test logs.  My
build had the following variations from the book:

1. built from a host with a 2.6.27.5 kernel, and used 2.6.27.5
headers.
2. glibc was given configparms of
"CFLAGS += -march=i686 -mtune=native"
and configured with --enable-kernel=current
3. some of the static libraries were renamed so that they are not
available as a matter of course.  Of course, muggins here decided it
would be a good idea to get rid of a static zlib, onyl to have to
revert that for module-init-tools.

 I failed to run tests for bash, file, gzip because of errors in my
script.

glibc-2.8 looked superb, just the annex.c message.

gcc-4.3.2 had 1 XPASS in libstdc++ which is as good as I can
remember.

e2fsprog-1.41.3 claimed to pass all tests, despite the following:
swap1: ./test_probe: line 39:
../../../lib/blkid/tests/tmp/swap1.results: No such file or
directory
./test_probe: line 42: mkswap: command not found
ok

coreutils-6.12 had a couple of tests skipped for missing locales,
which is odd because I installed all the locales.
PASS: test-math
Skipping test: no turkish Unicode locale is installed
SKIP: test-mbscasecmp.sh
PASS: test-mbsstr1
PASS: test-mbsstr2.sh
Skipping test: no chinese GB18030 locale is installed
SKIP: test-mbsstr3.sh

 I only noticed these because I noticed one of them while scrolling,
it's possible that htese tests have always skipped but I don't have
any 6.12 logs on this box.

gettext-0.17 : as I said earlier, this seemed to hang, but the log
from my final attempt claimed to run all of the lock tests ok.  It
failed in format-c-5 which is not something I remember seeing
before.

grep-2.5.3 was as the book says.

 Everything else seemed ok, even vim (which is the first time I
can remember that).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Version in glibc

[Ken Moffat]

On Wed, Nov 12, 2008 at 08:02:32PM +, Ken Moffat wrote:
> 
>  I've applied the following patch to my glibc:
> 
> --- glibc-2.8-20080929/version.h.orig 2008-11-05 03:42:01.0 +
> +++ glibc-2.8-20080929/version.h  2008-11-05 03:42:22.0 +
> @@ -1,4 +1,4 @@
>  /* This file just defines the current version number of libc.  */
>  
>  #define RELEASE "stable"
> -#define VERSION "2.8"
> +#define VERSION "2.8-20080929-LFS"
> 
 Update: I didn't realise this would change the sonames - I have
/lib/libc-2.8-20080929-LFS.so
and
/lib/ld-2.8-20080929-LFS.so

 I don't know if distros also change these sonames, or if there is
something else to be done to revert them to -2.8.so ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

6.4-rc1 and farce testing

[Ken Moffat]

 Using farce-002 to test my version of 6.4-rc1, I had one
explainable difference: perl's CORE/config.h and Config_heavy.pl
differed because my in-place rebuild didn't have /proc mounted, so
/proc/self/exe wasn't defined.

 /usr/lib/libgmpxx.la also added libstdc++.la to its dependency
libs, which is probably not significnt.

 The following binary files differed, perl (and perl5.10.0 which I
assume is hardlinked to it) might be explained by the absence of
/proc/self/exe.  I don't remember having a
/var/cache/ldconfig/aux-cache before, but as a cache it can be
ignored.  The other differences are unexplained, so I still don't
think farce is as useful as it once seemed to be.

/bin/bash
/lib/libc-2.8-20080929-LFS.so
/usr/bin/perl{,5.10.0}
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/cc1{,plus}
/usr/sbin/nscd
/usr/share/locale/{fi,vi}LC_MESSAGES/util-linux-ng.mo
/var/cache/ldconfig/aux-cache

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Chapter 6 building against /tools still?

[Ken Moffat]

On Thu, Nov 13, 2008 at 08:37:54PM +, Ken Moffat wrote:

 Forgot the Cc:

> On Thu, Nov 13, 2008 at 09:10:37PM +1300, Simon Geard wrote:
> > Hey, guys. Just finished a build of recent SVN (a week or two old),
> > getting some problems on some of the BLFS packages. Tools like Bison
> > aren't working properly, that sort of thing, and then I got one error
> > message (can't remember what package it was on) complaining
> > about /tools.
> > 
> > And yes, it looks to me like most of chapter 6 (including binutils and
> > gcc) has been linked against libraries in /tools. Scripts like libtool
> > have ended up with paths to /tools/bin/grep, and binaries
> > like /usr/bin/gcc and the like contain references to /tools/include,
> > which appear to be debug symbols.
> > 
> > Rebuilding the offending packages appears to fix them, but I'd quite
> > like to know how this happened, since this is almost certainly a bug in
> > my build scripts. Can anyone suggest what would cause this? It's as
> > though programs and libraries in /tools were still taking precedence
> > over those built later.
> > 
> > Simon.
> 
>  We've had a certain amount of movement in the build order to catch
> things which were hard-coding /tools/bin into scripts.  A quick test
> of my own first build of 6.4-rc1 looks clean for that.
> 
>  In bison, did you use the YYENABLE_NLS define for the first build ?
> If you did, any recollection of *how* it failed ?
> 
>  For /tools/include: ouch!  Yes, agreed, and they are indeed
> debug symbols, which get removed if you run strip --strip-unneeded.
> 
>  Cc'ing to -dev for possible discussion, I've no idea if we can get
> rid of these references without stripping them and without
> rebuilding them.
> 
> ĸen
> > -- 
> > http://linuxfromscratch.org/mailman/listinfo/lfs-support
> > FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> > Unsubscribe: See the above information page
> 
> 
> -- 
> das eine Mal als Tragödie, das andere Mal als Farce
> -- 
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page

-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 6.4-rc1 test results

[Ken Moffat]

On Wed, Nov 12, 2008 at 07:49:33PM +, Ken Moffat wrote:
> 
> coreutils-6.12 had a couple of tests skipped for missing locales,
> which is odd because I installed all the locales.
> PASS: test-math
> Skipping test: no turkish Unicode locale is installed
> SKIP: test-mbscasecmp.sh
> PASS: test-mbsstr1
> PASS: test-mbsstr2.sh
> Skipping test: no chinese GB18030 locale is installed
> SKIP: test-mbsstr3.sh
> 
>  I only noticed these because I noticed one of them while scrolling,
> it's possible that htese tests have always skipped but I don't have
> any 6.12 logs on this box.

 Self-inflicted egg-on-face time: back in February I'd set my script
to only build the minimal locales when running tests, so that I
could get space/time figures for both that and the full install.
Oh well.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 6.4-rc1 test results

[Ken Moffat]

On Thu, Nov 13, 2008 at 10:09:55PM +, Ken Moffat wrote:
> On Wed, Nov 12, 2008 at 07:49:33PM +0000, Ken Moffat wrote:
> > 
> > coreutils-6.12 had a couple of tests skipped for missing locales,
> > which is odd because I installed all the locales.
> > PASS: test-math
> > Skipping test: no turkish Unicode locale is installed
> > SKIP: test-mbscasecmp.sh
> > PASS: test-mbsstr1
> > PASS: test-mbsstr2.sh
> > Skipping test: no chinese GB18030 locale is installed
> > SKIP: test-mbsstr3.sh
> > 
> >  I only noticed these because I noticed one of them while scrolling,
> > it's possible that htese tests have always skipped but I don't have
> > any 6.12 logs on this box.
> 
>  Self-inflicted egg-on-face time: back in February I'd set my script
> to only build the minimal locales when running tests, so that I
> could get space/time figures for both that and the full install.
> Oh well.

 In fact, I had managed to overlook the tr_TR.UTF-8 locale in my
script's minimal list, the book was correct for that. zh_CN.GB18030
added to the list in trunk/ at r8741, to allow coreutils'
gnulib-tests/test-mbsstr3.sh to run, and the explanatory text fixed
to refer to what is now the first locale in the list.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: hang in gettext tests

[Ken Moffat]

On Wed, Nov 12, 2008 at 11:10:49AM +, Ken Moffat wrote:
>  In my build of 6.4-rc1, the box was hanging, apparently for more
> than 10 minutes, in the gettext tests.  Last thing in the log was
> make[3]: Entering directory
> `/building/gettext-0.17/gettext-runtime/tests'
> Starting test_lock ... OK
> Starting test_rwlock ...
> 
>  I killed it with ^C, then took a look around.  Deleted test_lock
> and test_lock.o in gettext-runtime and gettext-tools/gnulib-tests,
> reran make check, again it hung.
> 
>   I guessed that I might be able to turn the debugging on with
> CFLAGS=-DENABLE_DEBUGGING=1 (didn't seem to add debugging output)
> but the tests sailed through.  Deleted the test_lock files, repeated
> without attempting to enable debugging, again sailed through.
> 
>  Back to the script, put a tail -f on the log: halted on
> 
> test_rwlock, but showed an interruptmake[3]: Entering directory
> `/building/gettext-0.17/gettext-runtime/tests'
> Starting test_lock ... OK
> Starting test_rwlock ...make[3]: *** [check-TESTS] Interrupt
> make[2]: *** [check-am] Interrupt
> make[1]: *** [check-recursive] Interrupt
> make: *** [check-recursive] Interrupt
> 
>  and there it appeared to be stopped while I was writing up my
> notes, until I realised it had moved on to the next package.  The
> test log now shows
> Starting test_lock ... OK
> Starting test_rwlock ... OK
> Starting test_recursive_lock ... OK
> Starting test_once ... OK
> PASS: test-lock
> ==
> All 1 tests passed
> ==
> 
>  followed by the main tests (1 FAIL in format-c-5 FWIW).
> 
>  Strange.  Maybe it will never happen again.  Maybe it will always
> get through if left for a sufficiently long time.
> 
 I'm doing a fresh build, after discovering I'd only installed a few
locales.

 Left the build running in gettext, used another machine, came back
to it more than 4 hours later, it hadn't advanced.

 top showed
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND 
5560 root  30  10 44356  580  416 S 99.7  0.1 268:16.62 test-lock

log showed

make[3]: Entering directory
`/building/gettext-0.17/gettext-runtime/tests'
Starting test_lock ... OK
Starting test_rwlock ...

 So, it _doesn't_ automatically get past any hang!

 Killed it.  Repeated.  The 'system activity window' on the taskbar
in icewm shows system is busy, but firing up 'top' shows that top is
the process using high % of cpu, which seems somewhat unlikely.
Test log ends

make[3]: Entering directory
`/building/gettext-0.17/gettext-runtime/tests'
Starting test_lock ... OK
Starting test_rwlock ...make[3]: *** [check-TESTS] Interrupt
make[2]: *** [check-am] Interrupt
make[1]: *** [check-recursive] Interrupt
make: *** [check-recursive] Interrupt

 A little later, the testlog has fresh results, so this one will get
through - indeed, it has and I'm now up to man-db.

 We haven't altered gettext in some time.  Maybe this only happens
on this machine, either with this compiler, or this kernel, or this
glibc.

 It would be reassuring to know who has run the full testsuites
without problems, and gone on to build their normal software without
any strange issues ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Perl error

[Ken Moffat]

On Fri, Nov 14, 2008 at 04:14:33PM +0100, Tobias Gasser wrote:

[ not commenting on the main problem, or your seds - I find perl's
configuration painful enough at the best of times, so I'm chickening
out for the moment ]

> 
> even when the make is sucessfull i get 3 failures in the make test.
> 
 And your failures are:
ext/DynaLoader/t/DynaLoader...#
Failed test 'array should contain one result result or more: libc =>
()'
#   at ../ext/DynaLoader/t/DynaLoader.t line 109.
# '0'
# >=
# '1'
FAILED at test 20

lib/Term/UI/t/00_load.ok
pp.c:(.text+0x9eb1): undefined reference to `ceil'
../libperl.a(pp.o): In function `Perl_pp_sin':
pp.c:(.text+0xa0d5): undefined reference to `sin'
pp.c:(.text+0xa191): undefined reference to `sqrt'
pp.c:(.text+0xa22f): undefined reference to `cos'
pp.c:(.text+0xa247): undefined reference to `log'
pp.c:(.text+0xa25f): undefined reference to `exp'
../libperl.a(pp.o): In function `Perl_pp_atan2':
pp.c:(.text+0xa3e0): undefined reference to `atan2'
../libperl.a(pp.o): In function `Perl_pp_modulo':
pp.c:(.text+0xc1fa): undefined reference to `floor'
pp.c:(.text+0xc25b): undefined reference to `fmod'
pp.c:(.text+0xc430): undefined reference to `floor'
../libperl.a(pp.o): In function `Perl_pp_pow':
pp.c:(.text+0xc714): undefined reference to `pow'
../libperl.a(pp_pack.o): In function `S_pack_rec':
pp_pack.c:(.text+0x3dad): undefined reference to `floor'
pp_pack.c:(.text+0x3de1): undefined reference to `floor'
collect2: ld returned 1 exit status
FAILED at test 1
lib/ExtUtils/t/eu_command.ok

lib/Term/UI/t/00_load.ok
$v = uc;
$v = uc $m1;
$v = lc;
$v = lc $m1;

$v = quotemeta;
$v = quotemeta $m1;
EXPECTED:
Use of uninitialized value $m1 in crypt at - line 5.
Use of uninitialized value $g1 in crypt at - line 5.
Use of uninitialized value $_ in ord at - line 7.
Use of uninitialized value $m1 in ord at - line 8.
Use of uninitialized value $_ in chr at - line 9.
Use of uninitialized value $m1 in chr at - line 10.
Use of uninitialized value $_ in quotemeta at - line 22.
Use of uninitialized value $m1 in quotemeta at - line 23.
GOT:
The crypt() function is unimplemented due to excessive paranoia. at
- line 5.
# Failed at ../t/lib/common.pl line 190
FAILED at test 251
t/Module_Pluggable/01use..ok

 My own results are
ext/DynaLoader/t/DynaLoader...ok

lib/Term/UI/t/00_load.ok
lib/Term/UI/t/01_history..ok

lib/warnings..ok

 As you say, it seems to not run some sort of 'make depend' on the
failing runs.  Both are i686-linux, but the comment about 'crypt()'
above sounds as if it is running on something different.  Searching
for the exact error message was briefly amusing (for me), but found
a man page:

 The crypt() function is unimplemented due to excessive paranoia
 (F) Configure couldn’t find the crypt() function on your machine,
 probably because your vendor didn’t supply it, probably because
 they think the U.S. Government thinks it’s a secret, or at least
 that they will continue to pretend that it is.  And if you quote
 me on that, I will deny it.

Do you have /mnt/lfs/usr/include/crypt.h ?

Is this a native build, or are you running in a vm ?

What is your host system, and which kernel is it running ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Version in glibc

[Ken Moffat]

On Thu, Nov 13, 2008 at 07:43:28PM +, Ken Moffat wrote:
> On Wed, Nov 12, 2008 at 08:02:32PM +0000, Ken Moffat wrote:
> > 
> >  I've applied the following patch to my glibc:
> > 
> > --- glibc-2.8-20080929/version.h.orig   2008-11-05 03:42:01.0 
> > +
> > +++ glibc-2.8-20080929/version.h2008-11-05 03:42:22.0 +
> > @@ -1,4 +1,4 @@
> >  /* This file just defines the current version number of libc.  */
> >  
> >  #define RELEASE "stable"
> > -#define VERSION "2.8"
> > +#define VERSION "2.8-20080929-LFS"
> > 
>  Update: I didn't realise this would change the sonames - I have
> /lib/libc-2.8-20080929-LFS.so
> and
> /lib/ld-2.8-20080929-LFS.so
> 
>  I don't know if distros also change these sonames, or if there is
> something else to be done to revert them to -2.8.so ?
> 
 In fact, it applied to ALL the sonames from glibc, which is
horribly messy.  I tried extracting a binary rpm for fedora-10
preview, to see what the files were called, but failed miserably.
Looking at both their srpm and debian's patches, I'm unconvinced
that the installed files there get called anything other than
glibc-2.8 etc.

 Maybe my memory was wrong, and the distro identification only
appears in the gcc version.

 I took a look at OpenSuse - they add CVSDATE, set it from the date
of the changelog, and also add the build host (which presumably
picks up some Suse identification) and conditionally add something
about the configure options.

 This is revised to just show _which_ weekly snapshot we used
(I assume they'll all be '2.8' for the foreseeable future).  The
following patch achieves this (CVSDATE is transformed without any
extra work):

Not yet Submitted By: Ken Moffat 
Date: 2008-11-16
Initial Package Version: 2.8-20080929 (weekly snapshot)
Upstream Status: Not offered.
Origin: Self, based on OpenSuse
Description: Display the date of the snapshot in '/lib/libc.so.6'.

diff -Naur glibc-2.8-20080929.orig/csu/version.c 
glibc-2.8-20080929/csu/version.c
--- glibc-2.8-20080929.orig/csu/version.c   2008-01-02 19:25:22.0 
+
+++ glibc-2.8-20080929/csu/version.c2008-11-16 14:50:04.0 +
@@ -24,7 +24,7 @@
 static const char __libc_version[] = VERSION;
 
 static const char banner[] =
-"GNU C Library "RELEASE" release version "VERSION", by Roland McGrath et al.\n\
+"GNU C Library "RELEASE" release version "VERSION" ("CVSDATE"), by Roland 
McGrath et al.\n\
 Copyright (C) 2008 Free Software Foundation, Inc.\n\
 This is free software; see the source for copying conditions.\n\
 There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A\n\
diff -Naur glibc-2.8-20080929.orig/version.h glibc-2.8-20080929/version.h
--- glibc-2.8-20080929.orig/version.h   2008-04-11 08:01:16.0 +0100
+++ glibc-2.8-20080929/version.h2008-11-16 14:49:01.0 +
@@ -2,3 +2,4 @@
 
 #define RELEASE "stable"
 #define VERSION "2.8"
+#define CVSDATE "20080929"



 With this, the sonames are just -2.8 and /lib/ld.so.6 reports
GNU C Library stable release version 2.8 (20080929), by Roland
McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
Compiled on a Linux >>2.6.27.5<< system on 2008-11-16.
etc.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: development/chapter06/glibc

[Ken Moffat]

On Mon, Nov 17, 2008 at 08:20:43PM -0800, Trent Shea wrote:
> On November 17, 2008 09:47:39 am Lefteris Dimitroulakis wrote:
> > mkdir: created directory `/usr/lib/locale'
> > cannot open locale definition file `zh_CN.GB18030': No such file or
> > directory make: *** [glibc] Error 4
> >
> > rgrds
> > Lefteris
> 
> Hi,
> 
> 
> It looks like a typo, the command should probably be:
> localedef -i zh_CN -f GB18030 zh_CN.GB18030
> 
> I've posted a ticket as well #2279
> 
> 
> Trent.
 Thanks.  I think I've fixed it.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: hang in gettext tests

[Ken Moffat]

On Fri, Nov 14, 2008 at 08:17:26PM -0600, William Harrington wrote:
> 
> On Nov 14, 2008, at 6:13 PM, Ken Moffat wrote:
> 
> > On Wed, Nov 12, 2008 at 11:10:49AM +0000, Ken Moffat wrote:
> >> In my build of 6.4-rc1, the box was hanging, apparently for more
> >> than 10 minutes, in the gettext tests.  Last thing in the log was
> >> make[3]: Entering directory
> >> `/building/gettext-0.17/gettext-runtime/tests'
> >> Starting test_lock ... OK
> >> Starting test_rwlock ...
> >>
> >> I killed it with ^C, then took a look around.  Deleted test_lock
> >> and test_lock.o in gettext-runtime and gettext-tools/gnulib-tests,
> >> reran make check, again it hung.
> >> I'm doing a fresh build, after discovering I'd only installed a few
> > locales.
> >
> > Left the build running in gettext, used another machine, came back
> > to it more than 4 hours later, it hadn't advanced.
> >
> > top showed
> > PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> > 5560 root  30  10 44356  580  416 S 99.7  0.1 268:16.62 test-lock
> >
> > log showed
> >
> > make[3]: Entering directory
> > `/building/gettext-0.17/gettext-runtime/tests'
> > Starting test_lock ... OK
> > Starting test_rwlock ...
> >
> > So, it _doesn't_ automatically get past any hang!
> >
> > Killed it.  Repeated.  The 'system activity window' on the taskbar
> > in icewm shows system is busy, but firing up 'top' shows that top is
> > the process using high % of cpu, which seems somewhat unlikely.
> > Test log ends
> 
> I didn't test it during the build while using LFS 6.3 r2160 livecd,  
> however, I didn't get this with my dual P3 1.4 system. It flew right  
> past it while in the running LFS 6.4-rc1 system.
> 
> -William
 Maybe it's just my box, dunno.  I'm currently in my third fresh
build of chapter 6, and the problem is spreading: m4 tests hung on
test_rwlock (it's part of gnulib, so probably in other packages) but
on a second attempt they wizzed through like they normally do.  Got
to gettext, the first two attempts hung here, but the third is
continuing.  Not a showstopper, but annoying.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: hang in gettext tests

[Ken Moffat]

On Thu, Nov 20, 2008 at 12:02:03AM +0100, Gilles Espinasse wrote:
> 
> - Original Message - 
> From: "Ken Moffat" <[EMAIL PROTECTED]>
> To: "LFS Developers Mailinglist" 
> Sent: Wednesday, November 19, 2008 2:13 AM
> Subject: Re: hang in gettext tests
> 
> 
> ...
> > > -William
> >  Maybe it's just my box, dunno.  I'm currently in my third fresh
> > build of chapter 6, and the problem is spreading: m4 tests hung on
> > test_rwlock (it's part of gnulib, so probably in other packages) but
> > on a second attempt they wizzed through like they normally do.  Got
> > to gettext, the first two attempts hung here, but the third is
> > continuing.  Not a showstopper, but annoying.
> >
> I don't know why it would happen there but that's a low cost to check if
> entropy pool is not totally or almost empty
> cat /proc/sys/kernel/random/entropy_avail
> 
> Gilles
> 
 An interesting suggestion.  For the moment, I'm not planning on
another build.  I'll try to remember to check this - normally, I've
got plenty of entropy.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Releasing LFS-6.4

[Ken Moffat]

On Sat, Nov 22, 2008 at 03:25:36PM -0600, Bruce Dubbs wrote:
> LFS-6.4-rc1 has been out two and a half weeks now and there are really no 
> significant issues that I know about.  Of course there are some changes that 
> could be made, but I don't know of any that really *need* to be made.
> 
> A problem with delaying is that newer packages continue to be available, so 
> the 
> longer we go, the more out of date -rc1 becomes.
> 
> Are there any objections to me releasing 6.4 tomorrow (23 Nov)?
> 
>-- Bruce
 Any thoughts on the changes I've made to trunk ? (zh_CN.18030
locale - the version with the typo removed - and note for CFLAGS in
gmp).  No objections to releasing, either with or without these, my
initial concerns seem to be unsubstantiated.

 Apart from the hangs that only I have seen during testsuites, it
all seems good.

 I was going to ask about a udev message I've been glimpsing during
boot, but I finally managed to spot the whole text tonight (it
usually scrolls too quickly), and it's just a misconfiguration on my
part (I shouldn't be using CONFIG_SYSFS_DEPRECATED - the original
help for that was misleading).

 On the bright side, I've built all of what I think will now be my
current desktop packages.  A lot still need to be tested to confirm
they are working, but it's looking really good.

 A big vote of thanks to You, DJ, and Randy, for dragging it into
the gcc-4.3 age.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Updating BLFS to 6.4 (long)

[Ken Moffat]

On Tue, Nov 25, 2008 at 08:54:44AM -0600, Randy McMurchy wrote:
> Ken Moffat wrote:
> 
> >  Oh, and I might end up comenting out testsuites if they're
> > complicated to run!
> 
> Not sure what "complicated to run" means, but please bring up
> a topic on this list, or a ticket before just commenting out
> things in the book.

 OK.  I can't remember which package I was thinking of.  It was
something where you seemed to need a proper domain to be able to
test it.
> 
> FWIW, I've got an almost complete BLFS setup based on current
> LFS. I've waited to update the book to ensure that things deep
> in the BLFS build work as expected with all the updated versions.
> 
> I'm about ready to do massive updates as well. Let's ensure we
> use the ticket system for each and every package update. That
> why we won't end up redoing some work that others may have
> already done, but just hasn't been committed.
> 

 Agreed. I have every intention of assigning tickets to myself a day
or so before I work on them.  At the moment, I have _nothing_
prepared, other than my own buildscripts.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: Updating BLFS to 6.4 (long)

[Ken Moffat]

On Tue, Nov 25, 2008 at 02:34:19PM +, I wrote:
> 
>  I can do esound, flac (patch), id3lib (patch), lame, libdvdcss,
> SDL, mpg123, xine-lib, audacious (plugins now require neon, at least
> at runtime, we have it as a link from subversion).  I'll be happy to
> add libtheora, but I think fixing existing packages is probably more
> urgent.
> 
 DJ - you've got a later version of esound in your gnome-2.24
ticket.  Is there any point me doing 0.2.40 ?

>  I can probably do gstreamer, its plugins, totem (and its playlist
> parser), but I think the current versions depend on gnome-2.24.
 You've also got these in the ticket (mine might be slightly older
versions).  Again, is there any point me doing these ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: The value of 64-bit vs 32-bit

[Ken Moffat]

On Fri, Nov 28, 2008 at 12:01:45AM -0600, Bruce Dubbs wrote:
> 
> One commenter said that virtually everything except flash and grub
> were 64 bit.  I believe that flash is a very important application for
> many users and  until that becomes available, many users will reject
> 64-bit Linux.
> 
 Gnash works for me on both 32 and 64.  Sometimes uses a lot of power
just to render adverts in the browser, but I can always close the tab
if I need the cpu cycles.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: The new build method is in...

[Ken Moffat]

On Fri, Dec 05, 2008 at 03:58:24PM -0500, Jeremy Huntwork wrote:
> 
> http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk
> 
> There is no technical hindrance to bringing in multilib, the changes are 
> minimal. The effect is not so minimal. I would like to know people's 
> thoughts on how to deal with multilib in LFS. Specifically, how do we 
> handle for x86, where multilib is not an option? Do we just have a note 
> that says 'for 64-bit architectures only'? If so, how do we handle this 
> in jhalfs?
> 
 Last time this was discussed, the general view seemed to be that
pure64 was a step far enough.  Care to remind me what the advantages
of multilib builds are ?  I'm looking at the "whole system" here,
most of which is in BLFS (or, for existing multilib users, cblfs).

 Sure, I know how to build my desktop with this part 64-bit and that
part 32-bit, and how to keep the gnome stuff happy (I only ever
build kde as 64-bit on multilib).  I'm not sure I'm keen on forcing
that onto BLFS, there is enough trouble catching up to 6.4.

 Note: I'm a lilo user on my pure64 box, so "can build grub" isn't
enough to convince me.

ĸen, who does build multilib desktops, but nowadays only on ppc64.
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: The new build method is in...

[Ken Moffat]

On Fri, Dec 05, 2008 at 06:54:51PM -0800, Bryan Kadzban wrote:
> Ken Moffat wrote:
> > Last time this was discussed, the general view seemed to be that 
> > pure64 was a step far enough.  Care to remind me what the advantages
> > of multilib builds are ?
> 
> For me: Flash.  Either "standard" flash, or nspluginwrapper-flash --
> both require 32-bit libs somewhere.  (nspluginwrapper so that its 32-bit
> binary and the flash library can use them; standard flash so that both
> the FF binary and the flash library can use them.)
> 
 gnash mainly works for me.

> 
> (In short: anywhere anyone would be using anything closed-source or
> easier to obtain as a binary may introduce a need for multilib.)
> 

 Well, if enough people want to do that, don't let me stand in the
way.  It will be "interesting" for BLFS.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: ffMPEG

[Ken Moffat]

On Mon, Dec 01, 2008 at 11:28:25PM -0600, DJ Lucas wrote:
> DJ Lucas wrote:
> > *(September 8, 2008)* FFmpeg is undergoing major changes in its API/ABI. 
> > The last valid revision for libavcodec version 51 is r15261.
> >
> > Guess we should go with this version for BLFS.  Anybody tried it yet?
> >   
> BTW...after getting completely ticked off looking at it better than 100 
> times to figure out why libswscale wouldn't exportI took a day off.  
> Apparently I needed it...I have no better excuse than tired eyes. :-)
> 
> Anyway, if you do an svn export (typical practice before generating a 
> tarball), ffmpeg will not export correctly because libswscale/ is 
> imported from another repo.   Do a cp -a and then remove libswscale/.svn.
> 
> -- DJ Lucas

Tried your tarball earlier today:

Creating config.mak and config.h...
grep: /usr/src/ffmpeg-20080908-r15261/libswscale/swscale.h: No such
file or directory
./configure: line 2226: libswscale/libswscale.pc: No such file or
directory
./configure: line 2242: libswscale/libswscale-uninstalled.pc: No
such file or directory
./configure: line 631: libswscale/libswscale.pc: No such file or
directory
rm: cannot remove `libswscale/libswscale.pc.tmp': No such file or
directory

 For the moment I'll go back to the slightly newer random snapshot
I've been using.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: CLFS discussion

[Ken Moffat]

On Fri, Dec 26, 2008 at 04:14:49PM -0500, Jeremy Huntwork wrote:
> 
> Well, it's going to take a firm resolve and direction by those taking 
> the lead in the projects. You would have to have some sort of discussion 
> to attempt to bring efforts together. Here's a quick list to try:
> 
> Gerard (if someone can wake him up...)
> Matthew Burgess and Bruce Dubbs (representing LFS)
> Randy McMurchy and DJ Lucas (representing BLFS)
> Robert Connolly (representing HLFS)
> George Boudreau (representing ALFS)
> Jim Gifford, Ryan Oliver and Joe Ciccone (if CLFS is interested, which I 
> think is the hope)
> 
> And a somewhat 'neutral' party. I would suggest either Ken Moffat or Dan 
> Nicholson, or perhaps both. These two have always (in my opinion) kept 
> to a very balanced view of things.
> 
 I've just logged in after updating yet another system to 2.6.28
ready for an appropriate gecko (firefox-2.0.0.19 in this case, I
think - it's a rather old system).  I mention that because my real
interest is in a usable end-system (mostly, desktops - I try to keep
my [64-bit] server going for a long time between rebuilds).

 After biting my tongue, I was all set to reply to Matt's post
(because I think he has broad shoulders, and because branches in svn
are a PITA and what matters is what works - the clfs book does (at
least, last time I checked) - as an editor there, it's too easy to
break other architectures (I'm particularly hard on alpha because I
don't always appreciate its differences)).  Now that Jeremy has
posted this, I'll reply here instead.

 I'm flattered, but disconcerted - aren't all editors supposed to
take a balanced view ?  In the interests of "full disclosure" (one
of my buzzwords because I don't think "our" (LFS, BLFS, clfs)
security is "up to scratch" I need to disclose that I perhaps still
bear you (JH) a tiny amount of scepticism - you pulled me in to this,
for which I'm grateful, but then you put ppc64 into clfs, only to
lose your access to the hardware - making that work on the desktop
has taken far more time (basically, a huge chunk each time gcc had a
version upgrade) than I ever wished to use, and then there was the
teaser of the jh LFS book - yes, it worked, but it withered on the
vine.  So, I recognize your past contributions, and your good intent,
but I'm not yet convinced that this will be a productive use of my
time.

 Fortunately, DJ and Randy dragged LFS kicking and screaming in to
gcc-4.3 (as I probably should have realised, trying to fix gcc-4.2
on non-x86_32 was a wasted effort because none of the big distros
were using it).  For me, the challenge now is to get BLFS up to date
(although I can understand why Joe turned down commit rights).

 As for waking up Gerard, your guess is as good as mine about how to
do it.  Maybe he's skiing.

 In my opinion (and no, I'm not going to pretend any humility), the
major problem with LFS has been the "x86_32 is good enough" views.
I do not include Bruce (who has taken a sceptical view about 64-bits),
because he has always given a reasoned view of why 64-bits may not
be a good idea.

 When we had the lfs-hackers list, we could discuss other
architectures as well as more bleeding-edge versions of the packages.
Unfortunately, Gerard shut that down, and then when clfs moved to its
own server there was a reluctance among s390 and ppc users to move to
clfs.  Perhaps we are *all* too exclusive, I don't know.

 I was going to say "feel free to flame away", but looking at
previous contributions that is clearly unnecessary.  So, "a very
Merry Crimble to you all" and now, whether you will excuse me or
not, I'll go back to updating my old systems (at least it's easier
than messing with cmake and kde4 ! ;-)

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

sqlite3 and qt3

[Ken Moffat]

 I'm looking at possible users for sqlite3.  In the book, qt-3.3.8b
has sqlite as an optional external dependency.  But, the current
version appears NOT to be able to use a 'system' sqlite3.  It says
it finds sqlite, but that by default it is not enabled.  So, I added
'-plugin-sql-sqlite' to the configure, built it, and did an
INSTALL_ROOT to review it.

 I was expecting it to be like qt4 (i.e., that the file
plugins/sqldrivers/libsqlite.so links to libsqlite3.so), but ldd
doesn't show that.  I then looked at the log, but all the references
to sqlite are using the *internal* copy.

 Reviewed configure options - nothing.  Looked at fedora, gentoo,
debian - they just use the plugin option I'd already tried.  Then I
looked a bit further into the configure script.

sqlite)
if [ -f $relpath/src/3rdparty/sqlite/sqlite.h ]; then
CFG_SQL_AUTODETECTED="$CFG_SQL_AUTODETECTED sqlite"
fi
;;

 In other words, the 'detected' message means the tarball's copy was
found.  According to sqlite.h it is version 2.8.13.

 At this point, I start to wonder if I'm missing something obvious.
Opensuse don't build against sqlite, and they stopped doing so
back in 2004 on the grounds that the included version was broken.

 Finally, the questions : has anyone built a recent version of qt3
using an external sqlite3 ?  Have I indeed missed something obvious ?
Should we drop the link to sqlite on the qt3 page ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: Should we use a perl with shared libraries?

[Ken Moffat]

On Sat, Mar 21, 2009 at 01:47:05PM -0500, William Immendorf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hey,
> 
> Should we use a perl with shared libraries? Just a thought.
> 
 IMHO, definitely.

> BTW, the configure option for a shared lib perl is -Duseshrplib, and you
>need to apply this sed so that DynaLoader.a is built with -fPIC,
> so that it can be linked into a shared library:
> 
> {{{
> sed -i -e "s...@pldlflags=''@pldlflags=\"\$cccdlflags\"@g" \
> 33-e "s...@static_target='static'@static_target='static_pic'@g"
> Makefile.SH
> }}}
> 
> William

 As Robert reminded me (probably on one of the blfs lists, when I
was moaning about static libs, e.g. in gnumeric):
 -Duseshrplib

 I've since build one LFS-6.4 system like that - WFM.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Binutils - Chapter Six: libiberty header files, and Trac #1929

[Ken Moffat]

On Mon, Mar 23, 2009 at 03:39:57PM -0600, Trent Shea wrote:
> Hi,
> 
> 
> I'm looking at binutils in chapter six, and how we are copying libiberty.h to 
> its final location. For the record, I've been working with binutils-2.19.1.
> 
> The configure option --enable-install-libiberty should "Install headers for 
> end users," unfortunately, I can't get it to work (well, see below.) 
> 
> GCC also ships with libiberty and --enable-install-libiberty works as I'd 
> expect (IE. header files get installed.) Previous discussion on this mailing 
> list indicates that binutils has historically distributed a newer version, 
> and 
> that its version is the preferred choice. I list GCC as an example to show 
> that there are other packages that distribute libiberty, and that they are 
> configurable in such a way that the headers get installed. Perhaps it may be 
> appropriate to report upstream that --enable-install-libiberty has no effect?
[...]
> 
> I'm still in the early stages of researching this, but I'd appreciate any 
> input; mainly, whether or not installing all of the archive's header files 
> should be considered.
> 
> 
> Regards,
> Trent.

 Libiberty came up when I was moaning about static libraries.
Robert pointed out that the devs like to make changes without
worrying about backwards compatability.
http://linuxfromscratch.org/pipermail/blfs-dev/2009-February/019325.html

 In my own builds, the only packages capable of using libiberty are
binutils, gcc, and gdb.  They all ship a version, so I figured I'd
try NOT installing libiberty.a - gcc and gdb thus use the versions
they ship with.  The resulting system is, of course, working fine
(modulo continuing hangs in testsuites like I reported in -rc1 for
the same machine, and modulo problems with the newest libxml2 and
abiword).  So I now doubt that installing libiberty.a is beneficial.

 Certainly, it hasn't done any harm so far, and I try not to get too
involved in the toolchain.

 If you don't ever intend to have more than one version of gcc
available, it probably makes not a lot of difference.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: "mount --bind" with rootfs

[Ken Moffat]

On Tue, Apr 14, 2009 at 06:52:53AM +0200, John Frankish wrote:
> As per Chapter 6.2.2 of SVN-20090401 where the host (tinycorelinux) runs 
> entirely in ram I get this:
> 
> # mount --bind /dev /mnt/sdc1/dev
> mount: wrong fs type, bad option, bad superblock on /dev,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail  or so
> 
> I understand this is something to do with rootfs (the ,dev option is set for 
> sdc1), but cannot find how to get around it - I'd be grateful for any 
> suggestions
> 
> Thanks, John
> -- 
 This probably belongs on lfs-support.

 The only time I saw anything like this (trying to mount ext4, in
that case I had to rebuild some things) the explanation was indeed
in syslog, so please check what that says.

 The problem is probably your host system - tinycorelinux is based
on busybox.  I guess any error message in the syslog will show that
the configuration of busybox in tinycorelinux doesn't support the
--bind option for mount.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Vulnerabilities in udev

[Ken Moffat]

 I'm posting this to the lfs-dev and {,b}lfs-support lists.  If
you wish to reply, please just reply to the list (NOT "to all" -
that might cause rejections if you aren't subscribed to all the
lists).

 There are two vulnerabilities in versions of udev before udev-141.

(i.) For all previous versions, netlink messages can be received
from local users, allowing privilege escalation.  CVE-2009-1185

(ii.) There is a potential buffer overflow in the util_path_encode
function - rated as a denial of service.  This function was
introduced comparatively recently (somewhere between versions 114
and 124) so it does not apply to older versions.  CVE-2009-1186

 All users who run udev are recommended to upgrade and reboot.
Unfortunately, dropping in a newer version of udev to an old
system is not generally a good idea.  I recommend the following
alternatives.  I'll spell this out in full, apologies to those
who already know what to do.

1. Ensure you have backups (in this case, the files installed by
udev), plus a means of restoring them if udev breaks (e.g. separate
system on same machine, or rescue CD).

2. If you are running with the development book, a straight upgrade
to -141 is likely to work.  My own newest system had udev-137, and
works fine with -141 (I tried to port the fixes, but ended up having
to copy a lot more of the recent changes to get it to compile, so I
tried a straight upgrade).  Of course, YMMV.

3. If you are running udev-130 (e.g. LFS-6.4) there is a patch in
-patches, udev-130-security_fixes-1.patch : this was backported to
udev-124 by fedora, then I forward-ported it : let's hope I got it
right!

4. If you are running a version between -085 and -114, use the
udev-113-security_fix-1.patch (I have one old LFS-6.3 system I want
to keep usable) : this was backported by SUSE for -114 but looking
at their naming it seems it will apply to the range of versions.

5. For all other versions, pick the nearest version you can find
from what the distros are supporting, extract the patch or patches,
and port as necessary to the version you are running.  Fun!

 When building an old version, don't forget to use the instructions
that applied when you built it originally!  You do keep either the
version of the book that you used, or buildscripts, right ?  The
released version of the books are mostly at
http://archive.linuxfromscratch.org/lfs-museum/

 The following distros support the following versions:
debian: 105, 125
fedora: 124, 127
gentoo: 124
ubuntu: 079, 113, 117, 124 - unfortunately, I've been unable to
 download from ftp.ubuntu.com for the past few days.

 I've listed these distros because they are usually easy to access
for the source.  If for some reason you are running an even older
version of udev, there are some fixes in other distros.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Vulnerabilities in udev

[Ken Moffat]

On Mon, Apr 27, 2009 at 11:22:05AM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> 
> > 
> >  I've listed these distros because they are usually easy to access
> > for the source.  If for some reason you are running an even older
> > version of udev, there are some fixes in other distros.
> 
> Older versions of udev for stable releases of LFS are found at
> http://anduin.linuxfromscratch.org/sources/LFS/conglomeration/udev/
> 
> Almost all of sources for the released versions of udev are found at
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/
> 
>-- Bruce

 And yet again, what I write is obviously open to other
interpretations than I intended!  I wasn't intending people to get
the package source from distros, but those I mentioned are
comparatively easy to navigate for patches (or build instructions,
if they choose to do any of this with a sed).

 Other rpm distros can be processed from the source rpm to find what
patches they are using, but I know from experience that it isn't
always straightforward to find the source rpms.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: RFC: Man-DB UTF-8 support fix

[Ken Moffat]

On Sun, May 10, 2009 at 09:10:56AM -0600, Matthew Burgess wrote:
> Hi all,
> 
> At 
> http://www.linuxfromscratch.org/~matthew/lfs_man_db_fix/chapter06/man-db.html
> you can see the results of my attempt at fixing #2379
> (http://wiki.linuxfromscratch.org/lfs/ticket/2379).
> 
> I'd appreciate review of that page to check that it is accurate.  The changes
> from 
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/man-db.html
> include:
> 
> 1) Removal of the convert-mans script.  Man-DB should just do the right thing
>now.
> 2) Removal of the discussion of what other distributions support as I judged
>it to be largely irrelevant and confusing given the much simplified
>setup we can now adopt
> 3) Updated the encoding table to match what Man-DB-2.5.5 languages now 
> supports
>and removed the now outdated list of languages it doesn't support.
 I was going to say "nice work" for the table, but checking it
against src/encodings.c I note that Ukrainian should be KOI8-U not
-R.  Sorry to carp ;-)

 I was also going to say that the warning seemed a bit harsh, and
that only _legacy_ encodings not listed are unsupported, but I had
slightly odd results copying a UTF-8 page to uz_UZ, adding in the
cyrillic and latin from http://www.omniglot.com/writing/uzbek.htm
and adding some random UTF-8 accented versions of the letter 'a'
(cyrillic mostly rendered as latin, which was weird, some of the
non-latin1 accents dropped to give just 'a') so I guess it is
technically correct.  In any case, translations of man pages in
other languages are hard to find.

[ A more relevant language to me, gd_GB, seems to work as UTF-8
but it only uses latin1 characters. ]

> 4) Added a 'make check' command, as Man-DB now comes with a test suite.  This
>currently fails 8 out of 9 of the test though, with the following message:
> 
>FAIL: col: Invalid or incomplete multibyte or wide character
> 
>So this may get dropped before the commit is made.

Matt, please add

http://www.linuxfromscratch.org/patches/downloads/man-db/man-db-2.5.5-fix_testsuite-1.patch

 When I tried it, it appeared to fix all the issues, but I'd feel
happier if it was tested in a build.  I did hide col when I tested
it, but I also make mistakes - on my latest build (clfs using gdbm
and man-db) I forgot to use the patch :-(

 Tapadh leat air an obair seo (literally, 'thanks for this work').

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: linux-2.6.27.4 headers patch

[Ken Moffat]

2009/6/16 Konrad Mosoń 
>
> Hi.
>
> I creating now LFS, and i was on page:
>     5.6. Linux-2.6.27.4 API Headers
> from
>     LFS-BOOK-6.4.
>
> I tryied to run:
>
> $ make headers_check
>
> but i can't becouse i was that errors:
>
>   CHK     include/linux/version.h
>   HOSTCC  scripts/unifdef
> scripts/unifdef.c:209: error: conflicting types for 'getline'
> /usr/include/stdio.h:651: note: previous declaration of 'getline' was here
> make[1]: *** [scripts/unifdef] Error 1
> make: *** [__headers] Error 2
>
> Well... i wrote simple patch, and now this command results success:
>
> diff -up ./scripts/unifdef.c.orig ./scripts/unifdef.c
> --- ./scripts/unifdef.c.orig 2009-06-16 12:00:11.0 +0200
> +++ ./scripts/unifdef.c 2009-06-16 11:59:54.0 +0200
> @@ -206,7 +206,7 @@ static void             done(void);
> static void             error(const char *);
> static int              findsym(const char *);
> static void             flushline(bool);
> -static Linetype         getline(void);
> +static Linetype         get_line(void);
> static Linetype         ifeval(const char **);
> static void             ignoreoff(void);
> static void             ignoreon(void);
> @@ -512,7 +512,7 @@ process(void)
>
> for (;;) {
> linenum++;
> - lineval = getline();
> + lineval = get_line();
> trans_table[ifstate[depth]][lineval]();
> debug("process %s -> %s depth %d",
>    linetype_name[lineval],
> @@ -526,7 +526,7 @@ process(void)
>  * help from skipcomment().
>  */
> static Linetype
> -getline(void)
> +get_line(void)
> {
> const char *cp;
> int cursym;
>
> Before, i found patch on: http://lkml.org/lkml/2009/3/5/249 but i can't apply 
> this, well i wrote my.
> Directory structure:
>
> ./linux-headers.patch
> ./linux-2.6.27.4/
> ./linux-2.6.27.4/scripts/
> ./linux-2.6.27.4/scripts/unifdef.c
>
> Redards to,
> Konrad (morsik) Mosoń
>

 I think this is caused by your host system using a newer glibc than
what is in the book.  Can you confirm that, please ?  I saw the
original report on lkml in May, but at that time nobody else on that
list who looked at it was able to replicate the problem.  At the
moment, I'm slightly puzzled why nobody else has seen this  in LFS.

 Also, we conventionally create patches so that they can be applied
with -p1, not -p0.  I guess I could do that part [if I don't lose my
network connection again ;-) ] but I'd like to understand the
circumstances in which this patch is needed.

 Thanks

ĸen
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel compression with lzma

[Ken Moffat]

> as the kernel compile does not check wether lzma is possible but just
> starts compiling resulting in a failure at the very end, i propose at
> least a hint in the kernel section about not to use lzma unless the
> corresponding chapter from blfs is done.

 I guess that's a better place for it to go at first - like many things in
the past, lzma sounds like a good idea.  Whether it lives up to the
hopes and expectations remains to be seen.

  I'm assuming that one day (shades of one of the HHGTTG episodes)
there will be a new BLFs release - for the moment we seem to lack
editors with sufficient time and skills.

 On a personal note, I'm not in a state to do development at the
moment (a side effect, for me, of the statin I was briefly prescribed
is intermittent lack of interest in sleep, interspersed with inability
to sleep) - I know my limitations.  I hope to produce an updated
list of what I've been building for my desktop, with the full
commands, fairly soon. I've frozen my versions (parts of
gnome-2.24 and kde-4.2.2) while I tested on non-x86, so much of
what I've been using is now objectively old.

Meanwhile, you guys are moving on - I hope you find workarounds
for all the issues gcc-4.4 will bring before I get back to development ;-)

ĸen
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: How do you calculate SBUS?

[Ken Moffat]

2009/6/25 William Immendorf :
> Hey,
>
> I'm just wondering: How do you calculate the SBU amount for (B)LFS
> packages? Because I want to see the SBUS for new packages, and recent
> versions of packages.
>
> William
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
>

In theory, the same way as in LFS, but using the LFS version
for which the book is targetted (so, supposedly 6.4 at the
moment, with gcc-4.3 not 4.4.).

In practice, I've never found the (small) figures are
necessarily consistent, so if I'm editing and an SBU is
different from mine but not manifestly wrong I'll leave
it.

I think other editors have taken a different view, hence
the small SBUs recorded to 2 places of decimals.

Usually, it's better for a reporter to leave the calculation -
if I accept a ticket, I'll build the package (often several times)
and form a view of the time and space required, and I'm
sure the other editors will do likewise.  Of course, things get
harder when there are a lot of optional dependencies.

ĸen
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: LFS-6.5-RC1 released

[Ken Moffat]

2009/7/18 Randy McMurchy :

> But as I said earlier, it's your call. I just think it is premature to
> release a version of LFS that nobody has actually tested in any real
> life situation. It's only one person's opinion, please don't get worked
> up about it. I just thought I'd throw it out there.

 On the plus side for doing a release now: when I got back online,
perhaps a month ago now (and still no access to my original
mail account - excuse me for a moment while I swear at virgin
media ... ) there were clearly people using LFS-svn - I remember
a bug in firefox's rendering was mentioned, and apparently
solved by a patch checked in to either nss or nspr, so it seems
to build desktops that are mostly ok.

 Also, I think we've generally looked for more testing once LFS
seems to be ready for a release.

 On the negative side, I share the disquiet with a .0 gcc release,
but I'm not aware of any deal-breaking bugs in it.

ĸen
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: New BLFS Editor

[Ken Moffat]

2009/7/22 Thomas Trepl :
>
> Welcome on board Wayne!!  Congratulations!
>

 And from me.

> In the meanwhile I have a quite fine KDE4 (4.2.4) installation running. It
> seems to make great progress to reach the quality/stability of 3.5.10. Not to
> far in the future, 4.3 will be out and this is what we should have a look on
> for the book, I think. Don't you?
>
> Greetings,
> Thomas
>
> --
 If you have the stomach for it, and the disk space, go for it!

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: superfluous i686-lfs-linux-gnu folder in tools folder?

[Ken Moffat]

2009/8/11 Bénoît Segond von Banchet :
> I completed ch 5 of lfs-6.5-rc2. So far so good.
> I wondered if the folder i686-lfs--linux-gnu in the tools folder is
> still necessary. It looks as if that folder was created in the first
> tool-building pass. In the second pass i686-pc-linux-gnu was created.
>
> Just to be sure: do I need both folders in ch.6, or did I miss something?
>
> thnx for your trouble..
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
>

Are you really so short of space that it matters ?

Most people have enough space not to care - build chapter 6 and
then get rid of /tools (or, for the cautious, rename it or just make
sure it isn't on $PATH and then test everything).

Your analysis sounds correct, but I've not built 6.5 so I can't say
for certain.  In general, the contents of /tools don't matter providing
it's good enough to build chapter 6.  So, you may find directory names
such as /tools/libexec even though for the final system and in BLFS
we take steps to prevent /usr/libexec being used.

Carry on and build the final system!

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: LFS Directions

[Ken Moffat]

2009/9/18 Nathan Coulson :
.
>
> I have been experimenting with a multilib LFS System (where /lib,
> /usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used for
> 32bit).  I wanted something as close to LFS as possible, primarily
> 64bit, but just enough 32bit so if I wanted to compile something
> 32bit, I could.
>
> In fact, the only 32bit libraries I install, are e2fs, glibc, ncurses,
> udev, utillinux, and zlib.  [The only 32bit program I use is wine,  I
> didn't want a full fledged 32bit system just for wine].  If all I
> wanted was a compiler that could build 32bit code, I could probably
> drop e2fs, ncurses, udev, and utillinux from that list.
>
> The toolchain I use for compiling the system is based on our previous
> work,  I could not make the current directions build a multilib
> capable gcc toolchain.  (I am not an expert when it comes to tool
> chains though)
>
> If you wish, I could review my buildscripts, and note where I deviated
> for a 32bit build.  (From the email, I get the sense this is probably
> not a immediate goal)
>
>
> My Thoughs when I designed my MultiLib LFS System:
> - A Typical user would probably not need every 32bit library that is
> build in a base LFS Build if they have a 64bit version, but you would
> still want the ability to install it at a later date [GCC Multilib
> Compiler, which requires zlib32bit, and glibc32bit.  binutils/gcc
> should be build with multilib support]
> - Most programs like to install in /lib or /usr/lib by default, which
> in a standard multilib system.  Some programs take a lot of effort to
> install in /lib64 and /usr/lib64.  I decided to use /lib and /usr/lib
> as 64bit directories and /lib/32, /usr/lib/32 as 32bit.  [For me, this
> was the best decision at the time.  Kept things clean, and close to
> LFS defaults.  I am not sure what would be the best in the official
> book.  Either /lib,/lib64, of /lib32,lib I suppose].
> - Some programs have their own program to find paths, ex:/
> ncurses-config.  I did not like the idea of using something like
> ARCH=32 or ARCH=64 for installation, so instead I threw such programs
> in /usr/lib/32/bin.  [I noticed that CLFS/CBLFS use this to specify
> which program to run]
> - in LFS, we prefer to stay as close to the defaults as specified by
> the package maintainer.
>
> On my system, if I want to build a program 32bit, I could use
> PATH=/usr/lib/32/bin:${PATH} CC="gcc -m32" CXX="g++ -m32"
> PKG_CONFIG_PATH=/usr/lib/32/pkgconfig
>
> if I want to build 64bit, I would not have to deviate from LFS/BLFS,
> except in a few odd cases.
>

 To me, this sounds a very sensible way to use multilib on x86_64:
only build 32-bit when absolutely necessary.  Of course, as people
have already noted, it violates the fhs.  For me, that isn't a
showstopper.

 ISTR debian has used /usr/lib32, but I could be wrong.

 On ppc64 (my last build was a variation of clfs, using
--with-cpu=default32 so that userspace is 32-bit for better
cache footprints and the kernel is 64-bit), I had to build both
sizes of gmp, mpfr, zlib (similarly PPL and CLooG which LFS
ignores).

 I've built full-multilib in the past, and learned a lot from
building a working gtk desktop on it, but I don't have the
time or inclination to keep building multilib desktops.

 Certainly, fixing up runtime stuff for gtk and pango on
a desktop where some of their users were 32-bit and others
were 64-bit was *interesting* until I cracked it.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: lib32 or lib64 (was LFS Directions)

[Ken Moffat]

2009/9/18 Tobias Gasser :

[ snip good explanations ]

> what about the kernel modules. they will be 64 bit, don't they have to
> be in /lib64/modules?

 Tried it in clfs.  Not worth the aggro.  You have to change the top-level
kernel Makefile every time.

> perl: most will be in /lib/perl as they are architecture independent
> (.pm, .pod, .pl). but some libraries (.a, .so) must be moved over to
> /lib64/bin.
>

Perl is a real aggravation to build multilib - primarily because its
build system pre-dates everything we are now used to.  What is
in clfs for perl works (no cross-compilation, both 32 and 64 bit.

I suspect a full multilib system only needs one size of perl, but
since I don't built these systems any more I don't have any interest
in investigating this.  Certainly, cblfs systems need perl modules
(e.g. XML::Parser) to be built in the size of the program that will
use them, but that is becasue of the USE_ARCH variable.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Library requirements for Linux Standards Base

[Ken Moffat]

2009/9/19 Bruce Dubbs :
> I've been investigating the Linux Standards Base core specification.
>
> http://dev.linux-foundation.org/betaspecs/booksets/LSB-Core-IA32/LSB-Core-IA32.html#REQUIREMENTS
>
> 1.  Looking at the required libraries, I see that libncurses.so.5 is required.
> We have libncursesw.so.5 and libcurses.so.5.  I think we may also need to add 
> a
> symlink:
>
> libncurses.so.5 -> libncursesw.so.5

 Confirmed - alsa-mixer needs it on my boxes.

>
> 2.  To meet the spec, we also need to add a symlink:
>
> For ia32:
>  /lib/ld-lsb.so.3 -> /lib/ld-linux.so.2
>
> For amd64:
>   /lib64/ld-lsb-x86-64.so.3 -> /lib64/ld-linux-x86-64.so.2
>

 This part seems to only tick a box .  I suppose it's a
way of not having to know the real name (for different
architectures), but I don't understand how it would
be supposed to work - if it's for binaries, they've still
got to be compiled for the correct architecture.

> 3.  For the full spec, we also need libpam.  Does this LSB core requirement
> justify promoting PAM from BLFS to LFS?
>
> Comments?
>
>   -- Bruce

 My antipathy to PAM is known.  After Simon's comment
the other month that all the distros use it, I started to
consider adding it, but chickened out because too much
could go wrong if it didn't spend time understanding the
detail of it.

 I agree with your follow-up (page in LFS introducing LFS,
anything else in BLFS).

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re:

[Ken Moffat]

2009/10/14 ALIP BUDIANTO :
> Oops, I was using a old version by accisdent!

 And since LFS is all about learning, I'll attempt to
explain what you were asking about.  The problem
was that recent versions of glibc defined futimens.
At that time, several packages had their own internal
versions of futimens.  Gzip was the last of those
packages to get a new release that  fixed the problem.

 Specifically, it's nothing to do with bash code.  The
loop you queried runs sed on the source files to
rename futimens to gl_futimens.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: GRUB-1.97

[Ken Moffat]

2009/10/29 Bryan Kadzban :
>
> Same with some kinds of RAID -- it can assemble a RAID array, but won't
> (always) do it on its own.  (It can autoassemble some types of md-raid,
> I think, but I'm not sure how well-maintained that is.  It won't do
> anything with dm-raid, since that's only a device-mapper map; the kernel
> can't know about all possible maps that people might want, and when to
> apply each.  Or at least that's their argument.)
>
 md-raid seems to be well maintained.  I use it for raid-1 on my server.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: GRUB-1.97

[Ken Moffat]

2009/10/29 Bruce Dubbs :
> I have updated the book to GRUB-1.97.  The on-line book should regenerate in a
> few hours.
>
> The GRUB section in Chapter 6 is pretty straight forward, but the section on
> configuration and testing in Chapter 8 is pretty complex.  I'd appreciate 
> anyone
> building and installing this package giving feedback.
>
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/grub.html
> http://www.linuxfromscratch.org/lfs/view/development/chapter08/grub.html
>
>   -- Bruce
> --

 Seems to have built on x86_64 (pure64) with a DESTDIR install.  But I got a lot
of errors while it was creating the info files, ending in

../docs/grub.texi:83: Menu reference to nonexistent node `Preset Menu'
(perhaps incorrect sectioning?).
../docs/grub.texi:81: Menu reference to nonexistent node `Network'
(perhaps incorrect sectioning?).
../docs/grub.texi:80: Menu reference to nonexistent node
`Configuration' (perhaps incorrect sectioning?).
../docs/grub.texi:964: warning: unreferenced node `Menu entry editor'.

This is using texinfo-4.13. Status was 0, so I carried on.

I'm not close to testing it (need to create an up to date lilo rescue
CD before I start, then see if grub-mkrescue can create a CD (I don't
have any floppy drives) - found some docs, but I think they were for
grub-legacy.

At this point, the missing Configuration node in the info is a pain,
and there is nothing in info for grub-mkrescue.  Also, it created man1
and man8 directories, but they are empty.

Oh well, at least grub-mkrescue is a script.  Looks as if cdrom is the
default, but El Torito emulation isn't..

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: GRUB-1.97

[Ken Moffat]

2009/10/29 Ken Moffat :
> 2009/10/29 Bruce Dubbs :

> Oh well, at least grub-mkrescue is a script.  Looks as if cdrom is the
> default, but El Torito emulation isn't..
>
 Posted too soon.  It uses genisoimage which is from cdrkit.  Looking
at the manpage for mkisofs from dvdrecord, it looks as if symlinking
mkisofs as genisoimage should work.

 Probably don't need eltorito, although I think I've always used it
in the past on x86-family.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Some detail needs to be added

[Ken Moffat]

2009/11/28 Glen :
 It's nice that the book goes into detail as to the commands for
> making directories, but it never says how to mass extract gzip or bzip2
> archives.

For modern versions of gnu tar (probably any version released
in the last 5 years), tar -tvf filename | head [ that's just a sanity
check, primarily to make sure the tarball will create a directory
- shouldn't be needed in LFS itself, but does no harm ], and then
tar -xf filename  to extract it.

 Unfortunately, I think some not-so-old versions of certain
distributions have stuck with old versions of tar and might need
-j (for bzip2) or -z.

 But, as Bruce said, this is among the general background
you need.  If you have never felt the need to compile
software packages on a linux system, I'm not sure that
building a system using LFS is going to be a good use of
your time.

 Among other things, the system we build in the LFS book
is so minimal that you won't really be able to do anything
much at all with it until you've downloaded and built some
other packages - and you really could use another system
on which to do those downloads because LFS itself doesn't
include even a console browser or wget or an ftp client
(that's what BLFS is for.

 Also, you become responsible for your own security, and
you have to manage your own updates.

 But, people have used LFS as a learning experience
without going on to make it their ongoing system, so the
choice is yours.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: OT: Too much RAM ?

[Ken Moffat]

2009/11/30  :
> Hi all,
>
> this some kind of Off-Topic since it has nothing to do with LFS at all. I
> send this to this list because I know that there are quite a lot geeks and
> experienced people out there who may have a hint for me.
>
> Have you ever seen a machine which has too much RAM installed? We have a
> brand new HP (DL380G6) server here with 48G RAM installed. It has an p410i
> and a p800 SAS controller connected to a MSA70 with 1TB usable disk space.
> There are 2 Quad-Core-Xeon (X5560) with hyperthreading (a total of 16 CPUs).
>
 Actually, I _have_ seen a machine with too much RAM installed, but I can't
remember the details.  What I do remember is that wih a bit too much RAM
(but still a common desktop amount) it wasn't all cached.

 This is a 32-bit kernel ?  If so, I'll guess it's a problem creating buffers
(Bruce replied ... maybe HIGHMEM64G will fix it for you) and you *really*
should be using a 64-bit kernel (I suspect you might also benefit from
64-bit userspace, but who knows).

 vmstat might be useful (no, I don't know any details about how best to
use it).

 The MagicSysRQ key might perhaps show what is going on, but that is
probably not available in an enterprise kernel.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: OT: Too much RAM ?

[Ken Moffat]

2009/11/30 Thomas Trepl :

>
> We will test it tomorrow with the 64bit SLES10. Will have to redo the whole
> installation but when it helps its ok.
>

 You can't install just a 64-bit kernel and modules for testing ?

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: LFS Splash Screen

[Ken Moffat]

2009/12/3 Bruce Dubbs :
> I've been playing with GRUB2 and splash screens.  I've got it working so
> I wanted to make an lfs screen with a somewhat dark background so that
> the menu would show over it.
>
> I played around with gimp and came up with:
>
>    http://linuxfromscratch.org/~bdubbs/lfs.png
>
> I thought I'd share it.  The base image is from
>
>   http://commons.wikimedia.org/wiki/Category:Tux
>


 Thanks for the inline hint (I assume I can google
for what the .tga format is all about), and the link.

 As an inveterate lilo user, I *liked* this.

 Must find my stash of round tuits!

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

T_CFLAGS on x86_64 (gcc in 5.10 and 6.15

[Ken Moffat]

I still haven't built a recent LFS system, but I'm about to
restart (x86_64), and I'm checking my scripts match the
current development book, and working out what the
presence of the {,/usr}/lib64 symlinks from 6.5 will do to my
BLFS scripts (for the moment, I'm not sure if I like these
symlinks but they certainly save patching gcc for pure64
(spent some time yesterday trying to bootstrap 4.4.x on a
clfs host before I eventually twigged what was wrong).

We have an inconsistency in what we tell people to do on
x86_64.

In 5.10 the explanation applies to 'x86' machines (which is
true), but the sed is applied unconditionally.  On x86_64 a
bootstrap uses -fno-omit-frame-pointer within
CRTSTUFF_T_CFLAGS and *never* uses -fomit-frame-pointer
so the build is now different (FWIW, CRTSTUFF_T_CFLAGS
come at the end of the command lines where they are used so
crtbegin.o and friends are unaffected, but in general the
build is different (e.g. libgcc.so.1 _muldi3.so, and so
forth).

In 6.15 the sed is correctly wrapped in a case statement, but
the text just says
> As in Section 5.10, “GCC-4.4.2 - Pass 2”, apply the following
> sed to force the build to use the -fomit-frame-pointer
> compiler flag in order to ensure consistent compiler builds:

 So, the sed in 5.10 should be wrapped in a similar case
statement.  I think we could alter the 6.15 text to
... Pass 2", for x86 machines apply the following ...

 I'll be happy to fix this, but I'm raising it first in case
anyone has other views.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: T_CFLAGS on x86_64 (gcc in 5.10 and 6.15

[Ken Moffat]

2009/12/5 Bruce Dubbs :

>>
>> In 6.15 the sed is correctly wrapped in a case statement, but
>> the text just says
>>> As in Section 5.10, “GCC-4.4.2 - Pass 2”, apply the following
>>> sed to force the build to use the -fomit-frame-pointer
>>> compiler flag in order to ensure consistent compiler builds:
>>
>>  So, the sed in 5.10 should be wrapped in a similar case
>> statement.  I think we could alter the 6.15 text to
>> ... Pass 2", for x86 machines apply the following ...
>
> I'm having a problem understanding the issue you have.  If x86_64
> doesn't use the T_CFLAGS that's applied, why does it make a difference?
> Are you just concerned about the explanation?
>
>   -- Bruce
>
 A *bootstrap* build on x86_64 doesn't use that option, but we
are passing it anyway (so, presumably, our second set of
compilers are built differently from a bootstrap (and from our
final set of compilers).

 ĸen



-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Running IPRoute2 testsuite

[Ken Moffat]

2009/12/26 Matthew Burgess :
> Hi all,
>
> The current instructions mention the fact that running the IPRoute2
> testsuite is unreliable from within the chroot environment as it depends
> on /proc/config.gz support.  That's fair enough, but even when running
> on a freshly rebooted LFS build, the following appears to be required:
>
> sed -i '/^TARGETS/@arpd@@g' misc/Makefile

 Hah!  You fooled me by omitting the 's' - copy'n'paste can be good!

> make DESTDIR=
> cd testsuite
> sed -i 's/sudo/& -E/' Makefile
> make
> mkdir results
> make alltests # requires sudo
>
> Even then, I get not particularly fantastic results (a fair few
> 'Operation not supported' errors), but they may be down to me being
> under a VirtualBox environment and therefore just having a simple
> PCNET32 device hooking up to my hosts's interface.
>
> Could someone run the above commands, please, and verify that they work
> for you?  They were carried out using the latest iproute2-2.6.31 release.
>
> Thanks,
>
> Matt.
> --

 For anyone else playing along at home, the name is apparently a typo -
the code is supposed to be up to date for 2.6.32.  Of course, I can't
*imagine* why anyone would be testing this on a kernel older than 2.6.32,
but if you are, you're probably SOL.

 I'd forgotten how much I hate sudo (for a single physical user, I don't
think it provides any additional security).  But, set up for myself following
BLFS I get (from 2.6.32.2 with the ck1 patchset, on x86_64)

k...@bluesbreaker ~/iproute2-2.6.31/testsuite $make alltests
Running cbq.t [iproute2-this/2.6.32.2-ck1]: RTNETLINK answers:
Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
Dump terminated
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
Dump terminated
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
PASS
Running cls-testbed.t [iproute2-this/2.6.32.2-ck1]:
tests/cls-testbed.t: line 59: tests/cls/*.t: No such file or directory
tests/cls-testbed.t: line 59: tests/cls/*.t: No such file or directory
tests/cls-testbed.t: line 59: tests/cls/*.t: No such file or directory
FAILED
Running dsmark.t [iproute2-this/2.6.32.2-ck1]: FAILED
k...@bluesbreaker ~/iproute2-2.6.31/testsuite $

 Of course, it's possible that *some* of this is because we haven't kept up to
date with upstream changes (c.f. e.g. module-init-tools), but at least the
errors for tests/cls/*.t seem to be an upstream problem:

k...@bluesbreaker ~/iproute2-2.6.31/testsuite $ls tests/
cbq.t  cls-testbed.t  dsmark.t  policer


ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

stable kernel in next release ?

[Ken Moffat]

We've always used current kernels in the book, but many of our users
seem to have a distinct unwillingness to upgrade to newer kernels.
This week, Greg KH formally announced that he intends to maintain
2.6.32 long-term
http://www.kroah.com/log/linux/stable-status-01-2010.html so I wonder
if it would be a good idea to stick with this series for the next
release ?

I don't have strong views either way (I normally use the latest
kernel), but I guess not everyone follows lkml.

And now, I'll go back to swearing at mesa git (now looks as if I've
got more than 1 problem there, which makes bisecting somewhat
difficult).

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [LFS-DEV] stable kernel in next release ?

[Ken Moffat]

2010/1/19 Agathoklis D. Hatzimanikas :
> Hi Ken,
>
Hi Ag
> On Tue, Jan 19, at 08:03 Ken Moffat wrote:

[ 2.6.32 will be maintained long-term ]

>
> Anyway, the news remind me that LFS/BLFS doesn't have a maintainable stable
> branch, and these days where so many rapid changes happening from
> day-to-day, many folks actually wishing (including me) to run in their
> desktop stable software, which is (probably) future-less than the latest
> development, but bug-free (again supposedly), so it looks like a good idea.
>
> If there was a volunteer to lead the maintenance of such a stable branch, I
> would probably help him to back-port any bug fixes (I could dedicate some time
> once in a week or something).

 Usually, vulnerabilities in the base LFS system get addressed
fairly quickly (e.g. the move to libtool-2.2.6b).  Maybe that's
no longer true, but more likely people are just busy on other
things.  Unfortunately, it's always good practice to build a
system with the new package before putting it in to LFS,
(and ideally a complete system), so I don't feel able to
update the kernel or gzip at the moment.

 As to BLFS and stable systems, I've been burnt one time
too many.  I'm happy to advise people on what I build, and
if I can get a current system which is good (see my earlier
comments on mesa/dri) I might be able to again contribute
- but, my system is now newer than the current stable
BLFS target and I have no current interest in building for
32-bit i686.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Proposing a new LFS release

[Ken Moffat]

2010/1/25 Bruce Dubbs :
> Thanks to Matt's hard work, it looks like the -dev version of the book
> now has over half the packages updated from the current stable release.
>
> There only a couple of minor tickets outstanding.  We are at
> Linux-2.6.32 which has been designated for long term support.
>
> I am proposing that we make a -rc1 release next weekend with a target
> 6.6 stable release around the 1st of March.
>
> Comments?
>
>   -- Bruce
> --
 I've got one issue on 64-bit - I eventually build gnumeric.
That pulls in perl's dynaloader (seems to be for embedding
perl).

 Gnumeric fails to build on x86_64 unless I pass
 --without-perl
because of relocation errors from libperl while trying to link
perl_loader.so.  On i?86 it's ok to mix static and shared objects
in a shared lib, on x86_64 they don't link.

 The simplest fix is to configure perl with -Duseshrplib=Y.
That certainly builds on i?86, but it looks as if it passes
-fPIC all over the place.  I haven't compared the sizes of
the installed perl files on i686, so I don't know if that would
be a benign change.

 I also haven't identified what changes in gnumeric - all the
functionality I rely on seems to be there, it's just a pain
having to tweak the configure.  Presumably, anything else
that embeds perl might have a similar problem (but, the
only obvious candidate was apache, which seemed not to
care).

 If there was a way of easily adding the extra configure
switch to x86_64 only, that would be good, but my ideas
so far have been ugly.

 Measuring this is on my ToDo list, but for the moment I
don't have time.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: ext4

[Ken Moffat]

On 29 January 2010 16:42, Bruce Dubbs  wrote:
> ICMP Request wrote:
>
>> I'm just asking if I plan to turn my /home partition to an EXT4 FS,
>> supposing I used to do weekly backups when it was EXT3, you would
>> recommend now daily or I could stick with weekly (I'm not asking you in
>> opinions about how often a backup should be made for a desktop computer,
>> just how can I trust that EXT4 stability with kernels from, let's say
>> november till now)
>
> Sorry, I don't know.  I've not felt the need to even try ext4.  ext3
> works fine for me.  The book doesn't depend on file system type.  We
> don't address using mkfs at all.
>
>   -- Bruce
> --

 I've been using ext4 on '/' for a few months now.  Seems to work
ok, but the worst that I've done has been sync-umount-boot with
Alt-SysRq when xorg locks.  I think we're now at the stage where
ext4 is starting to get widespread use, which is why a lot of
odd corner-cases are now coming to light.

 What _I'd_  *like* to do is move /home to ext4, because the periodic
fsck is so much faster, but some of my available systems are a bit
too old (ISTR the fs name changed, perhaps around 2.6.30).  When I
started using ext4, I had fun and games getting systems to a point
where they could mount an ext4 partition, some needed e2fsprogs
and/or util-linux-ng upgraded, and one time I manged to build a
kernel without a necessary config option (CONFIG_LBDAF).

 Similarly, my server should really benefit from ext4, but that holds
my backups and music/photos so I'll want experience with ext4
on /home on my desktops first.

 For many people, ext4 is currently at least as good as ext3.  As to
benchmarks, particularly at phoronix, I tend not to give much credence
to them.  If you intend to try ext4, I suggest you create a new fs
and make sure you can correctly mount it, and perhaps run tests
if you are concerned about performance, before deciding to move
to ext4 for existing data.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: LFS Directions

[Ken Moffat]

On 2 February 2010 21:59, Bruce Dubbs  wrote:

>
> One of my concerns is "One unpleasant consequence of running several
> commands simultaneously is that output generated by the commands appears
> whenever each command sends it, so messages from different commands may
> be interspersed."
>
Me too.  I've only got single-processor systems, so any potential
speedup is perhaps less, but I like to be able to look back at my
build logs and get some sense from the output.  From what I've
seen, running parrallel make appears to sacrifice that.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: GCC Test report LFS-6.6-rc1

[Ken Moffat]

On 5 February 2010 06:31, Bryan Kadzban  wrote:
> Bruce Dubbs wrote:
>> gcc:
>>
>> FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-use -D_PROFILE_USE
>> FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE
>>
>> ERROR: tcl error sourcing
>> /sources/gcc-4.4.3/gcc/testsuite/gcc.misc-tests/linkage.exp.
>> ERROR: couldn't execute "file": no such file or directory
>>      while executing
>>

 Embarassingly, I've got that in my build from December,
but I didn't notice (on gcc, I "know" enough to look for "FAIL").

 But then, people will know that I think the book tends to
take an unrealistically optimistic position that toolchain
tests will all pass - on architectures other than i686
(and perhaps i586 - I no longer have one handy) that
has only rarely, if ever, been true.

ĸen

-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: LFS-6.6 test error explanations

[Ken Moffat]

On 1 March 2010 23:36, Bruce Dubbs  wrote:
> I've been analyzing the test errors found when I was building LFS-6.6.
> The logs are at
>
>   http://www.linuxfromscratch.org/lfs/build-logs/6.6/
>
> This is a summary:

 Thanks for this, it confirms and explains some of what I've found
in my own x86_64 build.
>
> glibc
>   annexc - long time errors that can be ignored.
>
>   tst-cpuclock2 -  this seems to be triggered by a setting in the
> kernel for cpu-scaling.  That option is not needed on desktops, but it
> is set by default.  It requires, by default, a user application to
> change   cpu frequencies, but there are other options in the kernel.  I
> think it can be ignored.

 I didn't see this, but this build is on my one machine which
*doesn't* use frequency scaling.  I think I've seen it on the
other x86_64

>
>
> gcc
>   bb-reorg.c
>   pr34999.c  - These do not build properly in the test suite.  I found
> an entry in the bug tracker that this has been fixed for gcc-4.5.

 Same here, thanks for the explanation
>
>   libmudflap.c++/pass41-frag.cxx - This should be fixed in gcc-4.5 also.
>
 Ditto - it's been broken for *ages*

> automake
>   aclocal5.test.  I couldn't track this down, but it seemed to pass and
> fail on my system intermittently.  It passes all the time in a 32-bit
> system.

 Didn't see this, but maybe I was lucky this time.
>
> gawk
>   stackoverflow2 - This appears ot be a kernel issue.  I was building
> using lfs-6.5 (kernel 2.6.30.2) and getting the failure.  It seems to be
> fixed when rebuilding on a 2.6.32.8 kernel.
>
 Didn't see this, running 2.6.33 and using the 2.6.32.9 headers.

>   machine specific failures - These are corner cases that test specific
> 64-bit boundary conditions.  They don't fail on a 32-bit system and do
> appear to show up differently on different hardware.  The possibility of
> running into problems here is very, very small.
>
 Again, thanks for the explanation, I had exactly the same results
(oldish Athlon64).
> --
>
> I don't know if these errors should go into the book, be put on a web
> page, or just left in the mail repository for people to find when
> searching.  Putting details about all of them in the book seems to be
> overkill, but we do have a section in 6.9, Glibc-2.11.1 about glibc test
> errors and some general comments, including libmudflap, in 6.16,
> GCC-4.4.3.  There is nothing in the automake or gawk sections of the book.
>
>   -- Bruce
>
> --
 At the moment, I'm dubious about recording these unless they turn
out to be common.  Then again, a few people seem to think that any
failure not specifically mentioned in the book is cause for concern.
Dunno.

 Meanwhile, I've got a few of my own (in alphabetical order) :
Didn't keep any of the directories, and only looked at the logs
later.  First the non-locale errors

autoconf-2.65
failed 182: parallel test execution (autotest.at:1116)

binutils-2.20 (ld)
FAIL: bootstrap with --static
FAIL: static preinit array
FAIL: static init array
FAIL: static fini array
FAIL: Could not link a static executable
 - these are probably down to me, I get rid of static libs
(except in the toolchain), probably it wants something I've
moved out of the way.  I've seen these before and they
don't concern me.

linux-2.6.32.9 (headers)
The usual messages about include/scsi/scsi.h
(userspace cannot call function or variable defined in the kernel)

 What I found interesting was that _no_ test progs were left
running when I unmounted at the end of chapter 6 - usually
I have problems unmounting.  OTOH...

 When I went back in today to finish building the extras I
need (fcron, mailx, ntp, nfs, etc) I had an error message
that it couldn't set the en_GB.UTF-8 locale, which was
worrying.- the finished system is ok (all locales seem
present), but there seems to be something wrong in my
scripts because I had:

bash-4.1
 in run-printf
 printf2.sub: multibyte character conversion failed

grep-2.5.4

Test #6 F failed: Cosi tu ^[[01;31m^[[KČiš^[[m^[[KÍ...
Test #7 F failed: Cosi tu ^[[01;31m^[[KČiš^[[m^[[KÍ...
FAIL: fmbtest.sh
(ISTR fmbtest failing is not unexpected)

sed-4.2.1

 4 failures
FAIL: utf8-1
FAIL: utf8-2
FAIL: utf8-3
FAIL: utf8-4

(these are testing case conversion (\u and \U)
for cyrillic d/D [ д/Д ]

Still, as with all tests, I try not to give them too much
credence :)

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: KDE4

[Ken Moffat]

On 9 March 2010 10:28,   wrote:
> Is it all bad only to me or do you feel same?

 I think most people here feel the same.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: grep 2.5.4 fmbtest test failure

[Ken Moffat]

On 9 March 2010 23:40, Bruce Dubbs  wrote:

>
> Ken submitted the patch two years ago against grep 2.5.3.  The purpose
> of the patch was
>
> Description: Various fixes, particularly speed improvements for UTF-8
> locales. Also adds a 'standard input' marker into the results for
> certain obscure uses.

 I *vaguely* remember that in some particular test, perhaps on a very big
file, the unpatched grep was disgustingly slow in a UTF-8 locale, and that
patch seemed to fix it.  I also remember that fmbtest never used to work.
At one point there was some hackery upstream to get rid of failure reports
on tests that weren't expected to work at the moment.

 Unfortunately, my subscription to bug-grep was one of the things that
went when I lsot access to my old nthell mail, and I didn't notice.

 When I first saw this thread, I remembered nothing about it until Bruce
pointed out the patch had my name!

>
> ---
>
> The tests that fail are for
>
> # Test that --color=always does not depend on individual pattern order
> within the pattern
> # list, and that a longer match is preferred to a shorter one starting
> at the same point.
>
> test6="`echo 'Cosi tu Ä~LiÅ¡Ã~M...' \
>    | LC_ALL=cs_CZ.UTF-8 ${GREP} --color=always -${mode}i \
>      -e 'Ä~MiÅ¡' -e 'Ä~Miší'`"
> if echo "$test6" | LC_ALL=C ${GREP} -q 'Cosi tu
> .*\[.*m\(.\[K\)\?Ä~LiÅ¡Ã~M.*\[.*m\(.\[K\)\?\.\.\.'; then
>   :
> else
>   echo "Test #6 ${mode} failed: $test6"
>   failures=1
> fi
>
> where mode is F.
>
> A similar test fails for test7.
>
> -
>
> I downloaded the current debian patch and all tests pass against that
> patch.
>
> Ken, can you take a look at the new debian patch and create a new lfs
> patch for us that fulfills your intent?
>

 Added to my ToDo list.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: grep 2.5.4 fmbtest test failure

[Ken Moffat]

On 10 March 2010 00:43, Ken Moffat  wrote:
> On 9 March 2010 23:40, Bruce Dubbs  wrote:
>
>>
>> Ken submitted the patch two years ago against grep 2.5.3.  The purpose
>> of the patch was
>>
>> Description: Various fixes, particularly speed improvements for UTF-8
>> locales. Also adds a 'standard input' marker into the results for
>> certain obscure uses.
>

 There are still reports of slowness in bug-grep, but I'm optimistic that
2.6 might improve things.

 The problem is that if you grep a large (text) file in a UTF-8 locale,
the elapsed time increases.  Unfortunately, I don't have any large
files with multi-byte characters.  With a 500KB+ file containing
ASCII (the syslog), there is a small slowdown  but I suspect part of
that might be from loading the new environment.

 Looking at debian's 2.5.4-4, which I believe is their latest, the patches
are 60, 61, 63,64,65, 66,67 and now 69 (which is newer).  If I don't
apply the patches, the testsuite is happy.  If I do apply them, it fails
as noted.

 Bruce,  which patch are you using ?

ĸen
-- 
After tragedy, and farce, "OMG poneys!"


keytest
Description: Binary data
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: grep 2.5.4 fmbtest test failure

[Ken Moffat]

On 10 March 2010 19:37, Bruce Dubbs  wrote:
> I downloaded grep_2.5.4-4.diff.gz and it applied without fuzz.  All tests
> passed for me on both LFS-6.5 on a 64-bit system and an older 32-bit system.
>
>  -- Bruce
>
 Sorry to be pedantic, but did you apply the patches from
debian/patches/ (as with all debian, they create patches
here and then apply them) ?

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: grep 2.5.4 fmbtest test failure

[Ken Moffat]

On 10 March 2010 20:36, Bruce Dubbs  wrote:
> Ken Moffat wrote:
>> On 10 March 2010 19:37, Bruce Dubbs  wrote:
>>> I downloaded grep_2.5.4-4.diff.gz and it applied without fuzz. Â All tests
>>> passed for me on both LFS-6.5 on a 64-bit system and an older 32-bit system.
>>>
>>> Â -- Bruce
>>>
>>  Sorry to be pedantic, but did you apply the patches from
>> debian/patches/ (as with all debian, they create patches
>> here and then apply them) ?
>
> No.  http://packages.debian.org/sid/grep which points to
> http://ftp.de.debian.org/debian/pool/main/g/grep/grep_2.5.4-4.diff.gz
>
>   -- Bruce
> --
 If you just applied that, then everything remains in the
debian/ directory and isn't applied to src/, see e.g. the
start of patch 60 :

--- grep-2.5.4.orig/debian/patches/60-dfa.c-case_fold.patch
+++ grep-2.5.4/debian/patches/60-dfa.c-case_fold.patch
@@ -0,0 +1,20 @@
+--- a/src/dfa.c.orig   2004-10-19 01:52:09.0 +0900
 b/src/dfa.c2004-10-19 01:59:43.0 +0900
+@@ -547,6 +547,17 @@
+   /* build character class.  */
+   {
+ wctype_t wt;
++/* NOTE:
++ * when case_fold, character class [:upper:] and [:lower:]


So, I'm back at not being able to produce a testcase that
shows a meaningful slowdown without the patch, because
I no longer have suitable test data, and it breaks tests
which (in 2.5.4) would otherwise succeed.

Unless someone with a large amount of multibyte text in
UTF-8 can provide some meaningful timings for why the
unpatched verson is a bad idea, or has real life examples
of the bugs debian are trying to fix, maybe we should just
drop that patch for 2.5.4.

Diffing the testsuite against grep-git (a waste of time,
I'm missing dependencies to be able to configure that),
I see that 2.5.4 seems to be using zh_CN in one of the tests
- but only noticed because that test has dropped out.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

fuser - netfs bootscript still using /bin

[Ken Moffat]

On my 6.6 build, I've noticed that the netfs bootscript fails to find /bin/fuser
when shutting down.  Not a big priority, because I had to comment fuser out
on previous builds (supposed to be fixed in 22.10, bit not yet confirmed).

Digging through trac, I've eventually identified
#2489 psmisc --exec-prefix="" and killall path
( implemented in r9078 on 29th September )

 which noted that fuser wasn't in the LFS bootscripts, and said it should
be in /usr/bin to make things easier for people using an initramfs.

So, is the policy that only programs in the LFS bootscripts belong
in /bin, in which case I'll take this to BLFS, or is it supposed to be the
same for progs used in BLFS bootscripts ?

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Website

[Ken Moffat]

On 16 April 2010 21:39, Jeremy Huntwork
 wrote:
> On Mar 19, 2010, at 3:52 PM, Jeremy Huntwork wrote:
>> On Mar 19, 2010, at 11:49 AM, Matthew Burgess wrote:
>>> Yeah, I guess I didn't really make my point clear.  What I was trying to 
>>> say was that I'm
>>> not sure the overhead of having both trac and plone is worth it for our 
>>> relatively small
>>> site.  If trac is 'good enough' for our needs, then let's just use that.
>>
>> As I've said, whatever you decide, it's really up to you guys. If you all 
>> like the design
>> (so far it seems pretty positive), I'd be happy to help you implement 
>> whatever you
>> want to do.
>
> So... where does this stand?
>
> --
> JH
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
>
 I didn't comment earlier, but I find the blue and green backgrounds too dark
(at the bottom - the top is ok), which surprisingly makes them slightly hard to
read on my LCD.  Note that my monitor is set to a much lower brightness than
the default, so that I can look at phots and get a reasonable idea of
how they'll
print.

 But not a showstopper.  I could say I prefer the simplicity of the current
design, but I'd probably be showing my age, and anyway it's not *my*
lawn :)  But if it was up for discussion, something like the slashdot pink
ponies might look good - then we could spend hours arguing about which
shade of pink.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Website

[Ken Moffat]

On 16 April 2010 23:12, Jeremy Huntwork
 wrote:
> On Apr 16, 2010, at 5:44 PM, Ken Moffat wrote:
>> I didn't comment earlier, but I find the blue and green backgrounds too dark
>> (at the bottom - the top is ok), which surprisingly makes them slightly hard 
>> to
>> read on my LCD.
>
> The blue and green backgrounds on the bottom? Do you mean the link colors? 
> Not sure I understand...
>
 Sorry, it was obvious to me when I wrote it.  The green backgrounds
are graduated from top to bottom of each box.  On a quick glance I
thought the blue ones were too, but now I'm less sure about the main
batch (BLFS ... Patches) - those are ok, it's just the main 'LFS' and
the little 'Search' boxes that I find hard to read.  It's also
possible that it looks different on my other main desktop, certainly I
have to set the brightness slightly differently for the differnet
video card (same monitor).

 I see that all of the main box backgrounds get "washed in white"
(toned down) when I mouse over them, which helps.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

gmp note (#2648)

[Ken Moffat]

Moving this here from trac.  When I put the ABI=32 note in, I
screwed up.  But it's only 2 weeks ago that anyone noticed.

In the meantime, building for x86_64 is now supported by LFS, so
the current note could also be misinterpreted.

There is a second issue on the ticket - if I've understood correctly,
this only happens when you build on one machine to run on a
different (probably, "lesser") machine.  If that is correct, I think
it's worth noting even though we don't necessarily support this.

 I've taken a first stab at rewording and expanding the note,
but I'd appreciate some review.  The page is at
http://www.linuxfromscratch.org/~ken/tmp/chapter06/gmp.html
(only that page, plus images and stylesheets so that it renders).

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: gmp note (#2648)

[Ken Moffat]

On 9 May 2010 18:00, Bruce Dubbs  wrote:

>
> The substance looks pretty good.  How about some minor changes:
>
> If you are building with a 32-bit kernel, but you have a CPU which is
> capable of running 64-bit code *and* you have specified CFLAGS in the
> environment, the configure script will attempt to configure for 64-bits
> and fail. Avoid this by invoking the configure command below with ABI=32
>
>        ABI=32 ./configure ...
>
> If you are building on one machine but intending to run on another
> machine (cross compiling), be aware that gmp will optimize itself for
> the local machine. For example, if you build on a recent i686 machine
> the binaries will contain instructions invalid for an i486. LFS does not
> directly support cross-compilation, but CLFS does.
>
>   -- Bruce

 First "*and*" - it's emphasised.  Are you are using recent kde ?
Gtk-webkit doesn't do emphasis (looking at epiphany-2.28), gecko does
(italics in forefox-3.6.3plugin), lynx does (different colour).  So, I'm
reluctant to add '*' for emphasis in the text.

 I'm also reluctant to give a false impression that setting ABI is need on
*any* architecture, it's only an i?86 thing.  Yes, I know that we only
support x86, but I still feel that unqualified statements can spread
confusion.  I'm willing to concede the point on this, if that is the
consensus.

 Insetting the ABI=32 ./configure  looks a lot nicer.  I've put a revised
version there for this - boxing ('userinput') seems to work, and insets
the line, but the box is an extra line deep on my browsers.  /me misses
Manuel's advice.

 For the second note ( and still assuming I've understood the problem
correctly! ), this isn't strictly cross-compiling.  The reference in the
ticket shows there were no i486- tools.  It's "detuning" the i?86 build.
On glibc the book uses "-march=i486 -mtune=native" to build for i486.
We've had people building on one i?86 machine and trying to run the
binaries on lesser machines for as long as I've been using LFS.

 I'm happy to drop the second note if everyone wants to enforce
"build on the machine you will run on" throughout the book.

 Thanks for these comments,

-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: gmp note (#2648)

[Ken Moffat]

On 9 May 2010 18:58, Gilles Espinasse  wrote:
> Just tested on AMD Athlon(tm) 64 Processor 3500+, 32bits distrib, with only
> ./configure --build=i486-linux
>
> this result in
> ...
> checking for egrep... /bin/grep -E
> using ABI="32"
>      CC="gcc -std=gnu99"
>
>
>    CFLAGS="-m32 -O2 -pedantic -fomit-frame-pointer -mtune=i486 -march=i486"
>      CPPFLAGS=""
>      MPN_PATH=" x86/i486 x86 generic"
>
> So adding ABI=32 is not strictly needed when the build cpu is 32 bits only.
>
> That's hard to search for host_cpu on configure script as 90 lines match
> that word. I would advice to search near i486*.
>
> For the first part of the explanation, there is different way to force
> 32bits compilation (linux32, CFLAGS). ABI=32 could be indicated before or
> after configure.
> I would write :
> On 64-bits capable CPU using a 32-bits distrib, you need to add ABI=32 on
> the ./configure line or select a 32-bits CPU using --build=[CPU]-linux. If
> you want to be able to run the compiled code on a less capable CPU than the
> building machine. Use for example --build=i486-linux allow to run on any
> i486 or more capable machine. Search near i486* on configure script for the
> list of available CPU options.
>
> Gilles
>

 For x86_64-capable CPUs (pedantically, I don't think this is an issue on
other 64-bit-capable architectures) I see no benefit in specifying '--build'..
ABI=32 is more appropriate.

  Thanks for confirming the second issue is indeed a "build on one machine,
run on another" problem.

 New version now up, saying (after the ABI=32 stuff)

The configure script will optimise gmp for the processor on which it
is compiled. If you intend to run the binaries on a different i?86
processor you may need to 'detune' the build. For example, to build
for i486 use

./configure ... --build=i486-linux

- you can search the configure script for 'i486*)' to find a suitable
value from the available i?86 host_cpu variants.

[ I'm now trying to guide people explicitly to the code - ' i486*'
had a first match on a discussion of m32 etc for old versions of
gcc. ]

 Is this the only place in the current book where following the
instructions and building on recent i686 produces binaries that
do not run on i486 ?

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: gmp note (#2648)

[Ken Moffat]

On 10 May 2010 02:09, Bruce Dubbs  wrote:

> Style issues:
>  Blank line after 1st configure

 I've got separate paras for the two parts of the note, because they are
unrelated - putting two separate Note boxes would, I think, be overkill.
Other comments noted.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: gmp note (#2648)

[Ken Moffat]

On 10 May 2010 07:41, Gilles Espinasse  wrote:
>
> - Original Message -
> From: "Ken Moffat" 
> To: "LFS Developers Mailinglist" 
> Sent: Sunday, May 09, 2010 10:12 PM
> Subject: Re: gmp note (#2648)
>
>
>> >
>>
>>  For x86_64-capable CPUs (pedantically, I don't think this is an issue on
>> other 64-bit-capable architectures) I see no benefit in specifying
> '--build'..
>> ABI=32 is more appropriate.
>>
> Should be the same on ppc and sparc 64-bits cpu with 32-bits userland.
> I don't have a pcc64 and my sparc64 build is broken actually.

 My ppc64 is part way through building LFS-6.6 for my ibook (I managed
to get a new battery, so I'm hoping to give it a less ancient system).  The
ibook is a 'G4', my reading is that the binaries will _probably_ work.  I
grant that a G3 (750) would get different native code.  But that's a
build-for-another-machine comment.

 What I know for certain is that my ppc64 [ biarch toolchain, 64-bit
kernel, everything else 32-bit, with a 32-bit default ] didn't need any
ABI= override even though I seem to pass CFLAGS=-O2.

>>  Is this the only place in the current book where following the
>> instructions and building on recent i686 produces binaries that
>> do not run on i486 ?
>>
> Parsing our entire build tree with analyse-x86.sh (curious name for a perl
> script), here are the first results
>
> i486:    0 i586:    2 mmx:    0 sse:    2 3dnow:    0 ext3dnow:    0
> /bin/kill will run on AMD Athlon 4 (athlon-4) or higher processor.
>
[...]
>
> This need a bit more work
> With some of the binaries in that list, the script say
> "This binary was found to contain the cpuid instruction.
> It may be able to conditionally execute instructions if
> they are supported on the host (i586+)."
>
> That script has a bug when the cpu is not displayed and there is a space for
> /lib/libc-2.11.1.so will run on  or higher processor.
> /lib/libpthread-2.11.1.so will run on  or higher processor.
> /sbin/ldconfig will run on  or higher processor.
> /usr/lib/libcrypto.so.0.9.8 will run on  or higher processor.
> /usr/lib/libpixman-1.so.0.17.10 will run on  or higher processor.
 Those last two aren't in LFS.
>
> There is probably another bug in the script for /lib/ld-2.11.1.so
> All counts are 0 but script say i686 is needed.
>
> kil, ps, free, top, uptime, vmstat, w belong to the same procps package.
> There is a problem there.

 Thanks for that.  Unfortunately, I'm starting to feel less convinced
about the merit of mentioning this for the book as part of this ticket..
Adding notes *all_over* the book for a situation that I'm still not sure
we *support* seems wrong [ the notes jump out of the page, as they
are meant to ].

  Perhaps it might still be worth adding a section somewhere to explain
at least which packages give problems, and perhaps how to address
them.  If this was BLFS, I'd say for certain that it belongs in the wiki.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: patch for ../net/ipv4/arp.c (former PCMCIA, IBMTR_CS, ARP-HW-TYPE)

[Ken Moffat]

On 10 May 2010 20:21, Claus Regelmann  wrote:
> I think the attached patch should be made generally available.
> For the time it is not included in the kernel, it fixes a problem
> with arp-packages on networks other than ethernet (at least for Token Ring).
>

 I'm astonished that anyone still uses token ring.  I salute your efforts
to keep an obsolete technology going, and I'm known for having used
weird things (for linux,amigaone and ppc64, otherwise jupiter ace, CP/M
on a z80, MVS, and for a couple of months token ring if someone hadn't
unplugged one of the machines), but I think this is a bit *too* far off the
beaten track for LFS.

  Fortunately, google should be able to find it if anyone needs it.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 13 May 2010 01:55, Bruce Dubbs  wrote:
>
> My last try was linux-2.6.32.8 which is the stable lfs-6.6 kernel.  I
> used the identical configuration.
>
 Please try with a newer kernel (2.6.32.13 or 2.6.33.4) in case
something in the latest fixes has cured it.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 13 May 2010 23:00, Bruce Dubbs  wrote:
>
> I tried the above, but still get a segfault in init.  I even tried
> adding init=/bin/bash, but still get a segfault at the identical address
> as when using /sbin/init.
>
> I'm running a memory test, but that doesn't show any errors yet at the
> halfway point.
>
> I guess I'll need to start over.
>
>   -- Bruce
  So, it's actually init that segfaults ?  I suppose that makes sense,
I think the kernel is privileged enough to do what it wants.  I must
admit, when I read your original post I assumed you meant it was
panicking.

 Anyway, I start to wonder if something about both init and bash
has been "compiled differently", or perhaps it's something in the
interface twixt kernel and userspace.

 Any chance you could compile a _static_ bash (or init, or other
shell), on a system with an older compiler, then try using that
for init ?

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 13 May 2010 23:53, Ken Moffat  wrote:
>  So, it's actually init that segfaults ?  I suppose that makes sense,
> I think the kernel is privileged enough to do what it wants.  I must
> admit, when I read your original post I assumed you meant it was
> panicking.
>
 Hmm, I can now confirm that it does panic after init segfaults (2.6.34-rc7,
-rc5 and gcc-4.4 were working, x86_64).  I built a minimal gcc-4.5 (C only)
and installed it in /opt/kgcc.  So, everything else was compiled with the
complier from LFS-6.6.

copied by hand -
Freeing unused kernel memory: 528k free
INIT: version 2.86 booting
segfault at fff810076019 ip 810076a9 sp 7fff9db4 57f8 error 15
[ above line repeated ]
Kernel panic - not syncing: Attempted to kill init!

 I blame gcc-4.5.

 Related question, although maybe it belongs on support - how do you
get grub2 (1.97, if it matters) to boot in single mode?  I need to fsck
my /home partition manually (fsck'd after nn boots, came up with
errors), and it's shared between all the systems on that box.

 init=/bin/bash works, but (of course) no disk devices.

 adding 'single' or '1' or 'init 1' to the end of the grub command line is
ineffective.  So, for the moment that box is out of use until I can find my
rescue CD.  Never had this problem with lilo, grumble, grumble :-(

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 14 May 2010 01:58, Ken Moffat  wrote:
>
>  Related question, although maybe it belongs on support - how do you
> get grub2 (1.97, if it matters) to boot in single mode?  I need to fsck
> my /home partition manually (fsck'd after nn boots, came up with
> errors), and it's shared between all the systems on that box.
>
>  init=/bin/bash works, but (of course) no disk devices.
>
>  adding 'single' or '1' or 'init 1' to the end of the grub command line is
> ineffective.  So, for the moment that box is out of use until I can find my
> rescue CD.  Never had this problem with lilo, grumble, grumble :-(
>
 Actually, I think it was a brainfart on my part - I'd been thinking that
/home wouldn't be mounted in single user mode.

 Found the rescue CD, ran fsck - *lots* of damage, mostly in .gconf/
.gnumeric/ and similar xml files, quite a lot ended up in lost+found.
 Nothing serious, but this was an ext4 filesystem that I'd converted
from ext3 following the wiki  -
 https://ext4.wiki.kernel.org/index.php/Main_Page
so I'm now slightly dubious about its long-term health.  My other
ext4 filesystems were all created as ext4 (with a backup and restore
for /home on the other box),

ĸen



-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 14 May 2010 02:58, Bruce Dubbs  wrote:
> Bruce Dubbs wrote:
>
>>>  I blame gcc-4.5.
>>
>> Me too, but I got a little further by disabling
>>
>> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
>
> Success!!
>
> I took a known good config (for 2.6.32.8) and copied that to 2.6.33.4
> and only changed the above option.  Boots fine now, including networking.
>
> I think I will file a bug with gcc.
>
>   -- Bruce
 Excellent.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 14 May 2010 14:23, Jeremy Huntwork  wrote:

>
> Also, if you've followed the book's instructions precisely (i.e., you've 
> named your kernel vmlinux-...) when you run grub-mkconfig, a config file will 
> be generated with two options based on that kernel, one being single user 
> mode.
>
Follow the book precisely ?  You must be kidding :)  As I said just now,
I think I was mistaken about what 'single' would do.  Grub is certainly
respecting init=/bin/bash when I add that to the command line.

 What you have overlooked is that I have a /boot partition full of
kernels for 4 or 5 systems, and I've edited grub.cfg to make
sense of what is available, safe in the knowledge that I could add
extra options such as 'single' if I needed to.

 Anyway, I suppose I'd better test 4.5 without
CONFIG_CC_OPTIMIZE_FOR_SIZE and then I can get back to my
LFS-6.6-on-ppc (ibook) build - thanks for your earlier work on
spreading LFS beyond i?86.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 14 May 2010 05:06, Bryan Kadzban  wrote:
> Ken Moffat wrote:
>> Related question, although maybe it belongs on support - how do you
>> get grub2 (1.97, if it matters) to boot in single mode?  I need to
>> fsck my /home partition manually (fsck'd after nn boots, came up with
>> errors), and it's shared between all the systems on that box.
>>
>> init=/bin/bash works, but (of course) no disk devices.
>
> Run the bootscripts manually, up until checkfs?  Dunno, but that's what
> I tend to do when (say) even single-user is running scripts that break
> something (like, oh, udev for instance).  :-)
>
 Yeah, that seems the way to go.  Apart from being mistaken about
what 'single' means, I've not had any recent need to fix filesystems
until this happened.  I guess I'm a bit rusty.

 Thanks.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: kernel and gcc-4.5

[Ken Moffat]

On 14 May 2010 16:46, Ken Moffat  wrote:
>> I think I will file a bug with gcc.
>>
>>   -- Bruce
>  Excellent.

 Just to confirm, unsetting CONFIG_CC_OPTIMIZE_FOR_SIZE
fixes it for me too (2.6.34-rc7).

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: gmp note (#2648)

[Ken Moffat]

On 24 May 2010 01:04, Bruce Dubbs  wrote:
>
> Ken,
>   I haven't seen any activity on this in a couple of weeks.  Would you
> like me to add the text you have to the book and handle the ticket?
>
>   -- Bruce

 Apart from looking at other things (my own keymaps for xorg - got my
ibook working as well as ever, but severely broke my cyrillic keymap :-(
and the last of the slammers this week
[ http://en.wikipedia.org/wiki/Slam_door_trains ]
 I've been hoping there would be more info provided on #2661, and
that I could kill the proverbial 'twa birds wi ane stane'.

 I was thinking about a vague "in some circumstances, particularly if
building in a virtual machine, you might need to pass --build".  We'd
established that passing --build for e.g. i486 is not enough to build
the whole of LFS for i486 on an i685, so I'm reluctant to mention that
option in the gmp text, but there seems to be a minority of people
who need *something* on x86_64.

 That other ticket has been silent for a week now, so I guess I'll cut
back what I'd suggested to only fix the ABI part.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: GMP-5.0.1 ABI=32 ./configure ... 074-gmp

[Ken Moffat]

On 28 May 2010 11:17, Matthew Burgess  wrote:
> On Tue, 25 May 2010 15:53:51 -0500, Bruce Dubbs  wrote:
>> Troy Will wrote:
>>> Hi Everybody,
>>>
>>> You will need to comment out the  "ABI=32  ./configure ..." line in
>>> the GMP-5.0.1 build script if using jhalfs with the latest SVN version
>>> of the book.
>>>
>>> The book includes a note which has a fictional command in it which
>>> jhalfs interprets literally. Just comment it out.
>>>
>>> The script involved is 074-gmp.
>>
>> I think you may be using an older svn version.  There is nothing like
>> that in SVN-20100523.
>
> Bruce, there is, it was introduced by Ken in 
> http://wiki.linuxfromscratch.org/lfs/changeset/9287.
>
> It just needs a 'role="nodump"' attribute adding. I'll fix it up tonight 
> unless someone
> beats me to it.
>
> Regards,
>
> Matt.
>
 Sorry.  As you can see, I don't use jhalfs.  Since you've diagnosed
the problem, if you
don't mind I'll leave it to you (rather than me throwing the attribute
at the xml and
putting it wherever it sticks ;).  Thanks.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Bounces on blfs-book ?

[Ken Moffat]

Anybody else getting a lot of bounces from blfs-book, resulting in
delivery becoming disabled ?  I seem to get them every few days.  No
visible problems with the other lists.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

ssl certs - not found by epiphany-2.30

[Ken Moffat]

(yeah, I know the book is still using gnome-2.28).  In openssl we put
the certs in
/etc/ssl/ca-bundle.crt.  I haven't yet identified what else is using
these, but epiphany is looking for
 /etc/pki/tls/certs/ca-bundle.crt and
/etc/ssl/certs/ca-certificates.crt.  I can fix this by passing
--with-ca-file=/etc/ssl/ca-bundle.crt but ti makes me wonder if we are
putting them in the wrong place.

Any pointers to investigating this ?  At the moment I'm unclear is
it's us or the epiphany devs who are mistaken (or, perhaps, some
distros use one name, and others use a different name).

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: ssl certs - not found by epiphany-2.30

[Ken Moffat]

On 22 June 2010 17:54, Dan Nicholson  wrote:
> On Tue, Jun 22, 2010 at 8:44 AM, Ken Moffat  
> wrote:
>>   I can fix this by passing
>> --with-ca-file=/etc/ssl/ca-bundle.crt but ti makes me wonder if we are
>> putting them in the wrong place.
>
> I don't think so. Fedora just happens to put them in
> /etc/pki/tls/certs/ca-bundle.crt, but I believe Debian/Ubuntu does
> something different. If you build wget, you'll see a different
> default. I think you just have to make sure the packages use the certs
> where you put them.
>
>> Any pointers to investigating this ?  At the moment I'm unclear is
>> it's us or the epiphany devs who are mistaken (or, perhaps, some
>> distros use one name, and others use a different name).
>
> I think the latter. :)
>
> --
 Thanks, Dan.  I'll stick with telling epiphany where to look.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: Sysvinit --> Upstart?

[Ken Moffat]

On 6 July 2010 18:50, Sebastian Plotz  wrote:
> I just want to start a discussion, if it would be meaningful to replace
> Sysvinit with Upstart ...
>
> Here are some points for discussion:
>
> 1. The bootscripts can still be used (like Ubuntu did).
> 2. The LFS user will learn something about old techniques (runlevels) and
> new techniques (event based booting) at the same time.
> 3. Upstart is more modern than Sysvinit (and it is under active
> development).
> 4. Some distributions already use upstart (Ubuntu, Fedora) or will use it
> in future (openSUSE, Debian).
>
> What are you thinking about that?
>
 Changing things *for the sake of changing them* when we don't have to
just causes work.  I don't see any concrete advantages listed (either for
upstart, or for the alternatives listed by others).

 From memory, I think the reason ubuntu moved from sysvinit was to
speed up their boot process.  Last time I used ubuntu (admittedly a long
time ago), my impression was that their boot process was excessively
complex, and in some ways I would actually describe it as "wrong" (like
debian, run a graphical login on all runlevels for desktops).  I also recall
that they switched to dash, which I regard as an *inadequate* shell, to
improve their boot times.

 Do I think the LFS/BLFS desktop boot could be quicker ?  Of course.
In my case, I get a delay of several seconds while ntp starts up.  But
so far, I've managed to live with that and I know that it *doesn't* need
a completely revised method of booting to address it.

 I might be misjudging you, but so far your post comes across as "ooh,
upstart is newer and shinier".  ISTR those were the motivations behind
kde4 - and for those of us who build from source on bare metal, that
turned into a disaster (total bloat).  I suggest that you identify *what*
you think can be done better during the boot process, then go off and
try different method(s) - if any of them provides a significant benefit,
come back and explain why you think the change is worthwhile - if the
aim is to speed up the boot, timings will be useful.

 In my case, the slowest part of booting my desktop machines is
waiting for the bios to present me with the grub boot screen, then
the ntp delay I mentioned.  From memory, I think that saving 5
seconds in the whole process is actually neither here nor there,
but people have different views.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Sysvinit --> Upstart?

[Ken Moffat]

On 6 July 2010 21:25, Sebastian Plotz  wrote:
> Am Dienstag, den 06.07.2010, 20:39 +0100 schrieb Ken Moffat:
>> On 6 July 2010 18:50, Sebastian Plotz  wrote:
>> > I just want to start a discussion, if it would be meaningful to replace
>> > Sysvinit with Upstart ...
>> >
>> > Here are some points for discussion:
>> >

>
> Yes of course, saving boot time is an important point of Upstart. But I
> think that the system actually won't boot faster if we're using the old
> bootscripts (I don't know any timings).

 Well, if you have a watch with a second hand or a seconds display, you
can try building two systems (for *your* definition of how much or how
little is contained within a system, in particular what services are started).
Then, try booting each of them several times and take an average.  Yes,
I know that only resolves to about 1 second, and a stop-watch would be
better, but I think it will give enough information for an early stage review.

 You also get to find out if there are oddities about how the new
dependencies are built (e.g. do they have to pull in a shed load of other
packages that we don't build).

 You are the person suggesting a change.  I'm trying to persuade you
to do the leg work and produce figures to explain why it is beneficial.
Generally, saying "almost everyone else does it now" is not an adequate
reason to persuade LFS to change.
>
> My idea was, that we're using the scripts for an unspecified time. After
> that, they may be replaced with event based jobs.
>
> Another point is, that the event based jobs are shorter than the
> scripts. So I think that they are easier to maintain. --> please correct
> me, if I'm wrong
>
 You talk about replacing the current bootscripts with "event based
jobs".  I have no idea what this means.  At the moment, if I add in a
new package to my own builds which needs something started in
certain runlevels, I take the template and edit it.  If we were using
these "event based jobs", what would I have to know when starting
a new service ?  This may all be as clear as day to you, but to some
of us here you might as well be speaking in gibberish because we
don't understand the practical changes.

 Maintenance of the main part of the LFS bootscripts doesn't seem
to be required very often, in fact looking at the current and previous
releases (ignoring contrib/) it's only udev that needed changes.  But,
since I've no idea how these event based jobs would look, it's hard
for me to say that you are either right or wrong.

 Further - at the moment I can, if I wish, start in a particular run level,
but you say that run levels will disappear.  There is only one "dyed in
the wool" run level that particularly matters (I assume you can still
reboot and shut down in the normal ways) - run level 1 or single user
mode.  Do your alternative method(s) continue to support that ?

ĸen, still not understanding the details of what you are suggesting.
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Website

[Ken Moffat]

On 28 July 2010 22:52, Yaacov-Yoseph Weiss  wrote:

> We (at least Jeremy and myself) are referring to package management in
> a way that won't affect regular users at all, except for another optional
> command in each chapter, similar to the current "make test/check"
> commands available today.

I'm _very_ glad you wrote that, because it saved me firing off a "I hate
package management too" response to earlier postings!  FWIW, I *do*
have my own package management in my buildscripts (last released
version in ~/ken but getting a bit old!) - try to touch headers because
they seem to be installed with the shipped dates, then find anything
newer than when I started the build.

 I came to linux via redhat (6.x) and mandrake - at that time, you had to
search to find new versions (particularly, new xfree86 releases), and
every distro had different dependencies - on dial-up, it was one of the
things that brought me to LFS and BLFS (learning to build and minimise
the dependencies).  Later, I had to try ubuntu/debian to get non x86
kit working, and I developed a deep loathing for the intricacies of the
debian package management system, and indeed for debian's general
configurability (/etc/alternatives and so forth), together with a great
respect for their developers supporting multiple architectures and
indeed OS's (hurd, bsd as well as linux).  So, whenever someone here
mentions 'package management' my alarm bells start ringing.

 For the little I've been able to do on BLFS, using DESTDIR is well
worthwhile.  It's of perhaps less use for LFS (use it when building on
current system, and perhaps note different programs or libraries,but
for LFS changes, the key thing is to build LFS with the newer version
of the package, and then ideally build a complete system to see if
anything breaks (for old hands - can you say 'bison' ?)

 So, (and maybe I've misread the thread by skimming it - many of the
posts seem very long), if the upshot is that LFS moves to mentioning
DESTDIR, I think I can live with that.  Adding that to BLFS is a different
matter, and O/T for this list - in any case, BLFS development is stalled.
Thread at
http://linuxfromscratch.org/pipermail/blfs-dev/2010-June/020490.html

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Website

[Ken Moffat]

On 28 July 2010 18:01, Bruce Dubbs  wrote:
> Because I don't use it and don't see the need for it (for me).  I have
> no problems reinstalling a newer package over an older one.  The only
> package that gives me pause for that is glibc.
>
FWIW, my ppc64 system is rather old (a bit over a year now).  It runs
epiphany-2.24, so using an old version of gecko.  I can live with that
for _where_ I use epiphany, but I want a reasonably current browser
to use for general browsing.  So, as part of fixing known vulnerabilities
I upgraded libpng (used generally, even if I let my firefox-derivative
use its own version) and cups.  The upgrade to libpng broke epiphany
(a symbol seems to have disappeared), and the newer cups couldn't
find a particular library.  First time I've ever seen these sort of problems
when upgrading packages, but it's always a good idea to be able to roll
back.  In my case, I'm content to live without the functionality until I can
build a more recent system.  So, as always, "builder beware".

I'm also doubtful that it's often worth upgrading LFS packages in a running
system, unless there is either clear extra functionality, or fixed
vulnerabilities.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Website

[Ken Moffat]

On 29 July 2010 00:51, Bruce Dubbs  wrote:
> Ken Moffat wrote:
>
>> it's always a good idea to be able to roll back.
>
> Did you try building the older version of png and reinstalling?
>
 No, the obvious thing to do would be to recompile epiphany
against the current version (the update was to fix all known
vulnerabilities), but it didn't seem worth doing.  To be honest,
at the moment that box is testing my patience and I might just
relegate it to an emergency electrical heater.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: How can I contribute?

[Ken Moffat]

On 30 July 2010 21:55, Bruce Dubbs  wrote:
> harrold hunt wrote:
>> Hello,
>>
>> I would like to help out the LFS project in some way, preferably
>> documentation which is the main part of the project. I'm not entirely
>> sure what I could do. But I am interested in any contribution to help
>> the project move forward.
>
>
> Where we really need help is in BLFS.  There are 225 open tickets there:
>
> http://wiki.linuxfromscratch.org/blfs/query?status=assigned&status=new&status=reopened&group=milestone&max=300&col=id&col=summary&col=status&col=type&col=priority&col=milestone&order=priority
>
> The most difficult part of contributing is learning docbook and being
> able to build the book.  Then make the changes and submit a patch by
> attaching a diff.
>
> svn diff > mypatch.diff
>
> I'd suggest trying to pick something easy that stands alone to start.
> Tickets 3110 and 3134 look appropriate.
>
> Post a note at BLFS-dev if you are going to work on something just in
> case someone else has started that ticket.
>
>   -- Bruce
> --
 Just for the record, BLFS is still targetted at LFS-6.5, so build instructions
should be appropriate to that version.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page