gmane.linux.lfs.devel

LFS SVN and Systemd Report

Armin K. — 2012-05-25T12:55:58

Hello there, I have just finished LFS+BLFS SVN (with software from LFS 
Trac too, including Perl 5.16.0, Udev+Systemd 183 and Linux 3.4.0).

I say LFS+BLFS since I installed some BLFS packages during LFS build. I 
did not want to complete everything and then install BLFS packages and 
possibly recompile some of LFS packages. But, never the less. Everything 
works. Also, I ditched sysklogd and used rsyslog for my system since it 
provides native systemd units.

I want to add that I've experimented with "the /usr merge" since I use 
one partition for everything.

$ uname -a
Linux lfs 3.4.0-krejzi #1 SMP Thu May 24 18:33:15 CEST 2012 i686 GNU/Linux

My hardware is an older Pentium 4 HT with 1024MB of DDR RAM.

After booting with basic software installed, I get
$ systemd-analyze
Startup finished in 1686ms (kernel) + 7995ms (userspace) = 9682ms

Currently running services are
http://paste.debian.net/plainh/14ddd735

Or if you prefer as ps output
http://paste.debian.net/plainh/504f9d4c

Memory usage with such serv

About packaging LFS - How it works for me 8)

Marius Tolzmann — 2012-05-23T00:00:52

Hi..

I was pointed to the "Once More: Package Management" discussion 
yesterday. So I just joined this list.

First I want to thank you for LFS. It's great. I love it. And i made a 
few more people love it, too. The same is true for BLFS.

I will start with many words about my LFS background 8)

I am using (B)LFS (as a reference) since (i think) 2004. After we had 
some serious issues adjusting a red hat linux to our needs I started a 
linux from scratch to finally have a linux that follow my rules 8)

I really learned a lot from this documentation - even if it wasn't very 
easy all the time.

When using an LFS based distribution in a production environment you 
have to do some kind of minimalistig package management. what we do and 
what we have done isn't really package management it is more about 
package tracking - to answer the important questions like which file 
belongs to which package? just to be able to install and remove a binary 
package after creating it following the (B)LFS Book(s).

Two year

Vim 7.3.xxx

Fernando de Oliveira — 2012-05-19T16:19:10

I am posting this to two lists because Vim is common to both. Of course, discussion and opinions, if any, could be different in each one.

While some softwares are rushing new versions even weekly, others stick to a "main" one and leave the minor versions/corrections in their repositories to be checked out with git or other softwares, and this is the case of Vim and MPlayer.

I have noticed that most distributions are changing to upgrade these more often, perhaps monthly.

Some examples with Vim:

*buntu                       7.3.429
ArchLinux                  7.3.515
Fedora                       7.3.515
Gentoo                      7.3.515
Mageia                       7.3.444
Mandriva devel           7.3.486
openSUSE Factory     7.3.456

Sometimes, they call it version 7.3 "correction-xxx".

MPlayer has already changed. What do you think about Vim in LFS and/or BLFS, with a monthly source in Anduin?

Once more: Package Management

Jeremy Huntwork — 2012-05-19T13:26:31

I've been holding back bringing this up on-list for a while because I 
intended to do the bulk of the work and then present a working system to 
the community for comment and review. I still intend to do that, but 
given some recent discussions, I think the time is right to bring this 
up and see where it goes.

(Sorry for the cross posting, but since it involves both projects, I 
wanted to make sure all saw it - if possible, please reply on lfs-dev.)

Proposal:

1. Adjust LFS/BLFS to auto-generate build recipes for individual 
packages that a packaging tool can use to create binary packages with 
meta information included such as dependency tracking.

2. Store 'official' copies of those binary packages in a developer 
package repository so that when developing (primarily BLFS) a dev can 
automatically pull and install into a build environment the dependencies 
he needs to build and create an individual package.

3. Create a standard workflow and tools whereby a developer can 
accomplish #2 and edit the book

problem of bootscript setclock

xinglp — 2012-05-12T18:27:16

Now, It is the job of udev to start /etc/init.d/setclock .

When I use initd-tools to install somethings else, it was installed
for depended.

And I THINK , ntpd and checkfs should not depend on $time.

resizecons : a proposal

Ken Moffat — 2012-05-11T15:06:54

 First, some assertions:

1. resizecons cannot work without video mode files, which are
produced by a program from the svgalib package.

2. svgalib is defunct, and was only applicable to linux kernels
before 2.6 : there are patches around to enable it to be compiled,
and some distros include it, but it seems very much a minority
interest.

3. the console will be resized to suit the font when 'setfont' is
run.

4. if the resulting font appears too tiny, you can pass video=
arguments to grub, e.g. I use video="1024x768" on one of my machines
which uses kms and a small (8x16) font.  Known to work on
framebuffers, including kms - I haven't built a non-framebuffer
kernel in years.

 The proposal:

 If the first 3 assertions are correct, then I suggest that we should
remove resizecons, and its manpage, from the build - with some seds
(not yet tested), and in explaining the seds use a short summary of
assertions 1-3, or even of 1-4.

 Comments ?

ĸen

resizecons not installed by kbd

xinglp — 2012-05-10T20:06:55

As described at
http://www.linuxfromscratch.org/lfs/view/development/chapter06/kbd.html

But the manpage of resizecons was installed.

Suggestion

Jeremy Huntwork — 2012-05-09T20:19:27

Greetings all,

Consider two things:

1. We all hate long build times. Anything we can (reasonably and 
accurately do) to speed up the build we do.
2. Chapter 5 are a set of throwaway tools (in some cases we only build 
just what we want out of those tools, again, for sake of speed, i.e., 
gettext)

Given the above, why don't we use busybox in chapter 5? If we 
standardize a config we could get rid of 12 packages in chapter 5, 
namely: ncurses, bash, bzip2, coreutils, diffutils, findutils, gawk, 
grep, gzip, sed, tar, xz. Possibly 13, patch, although the last time I 
tested busybox's patch it didn't quite work as hoped, but it's possible 
it is fixed now.

In addition to being able to drop those packages, you also get free of 
charge a vi editor and wget utility for use in chroot.

Thoughts? If interested, I could start a mockup in the jh branch.

JH

gtk-doc-rebuild.xml

Ken Moffat — 2012-05-07T17:55:26

 In gegl, Fernando noted that the shipped documentation is installed
if gtk-doc being present, but the explanation says:

--enable-gtk-doc: Use this parameter if GTK-Doc is installed and you
wish to rebuild and install the API documentation.

 Unfortunately, this is the standard xinclude.  For gegl it would
make more sense to say "Use this parameter if GTK-Doc is installed
and you wish to rebuild the shipped API documentation."

 BUT - is such a change always appropriate, or are there perhaps
some strange gtk packages which ship documentation but don't install
it ?

ĸen

Wording fix

Jeremy Huntwork — 2012-05-05T14:24:25

Looks like I missed some necessary text changes. At the bottom of
chapter 5 glibc, in the sanity check box, the following sentences are
no longer accurate and can be removed:

"Something may have gone wrong with the specs file amendment above. In
this case, redo the specs file amendment, being careful to
copy-and-paste the commands."

Thanks,

JH

Rename sources?

Andrew Benton — 2012-05-04T10:45:35

Hello All,

There's a rather ill natured thread on LFS Support at the moment called
Chapter 5 questions. Scott Robertson has made an interesting point:

On Fri, 04 May 2012 11:35:32 +0100
Scott Robertson <scottrobertson33< at >yahoo.com> wrote:


I think it's a good point and it would help some people who are new to
the book if we renamed the sources folder "materials" or "resources" or
"packages" or something.

Andy

/etc/rc.d/init.d/sysctl 's "Required-Start" should bemountvirtfs

xinglp — 2012-05-02T07:20:16

The "mountkernfs" has been renamed to "mountvirtfs".

Broken sound (glibc).

Ken Moffat — 2012-05-01T19:05:46

 My shiny new LFS system is heading for /dev/null.  That's ok, it
was only a test of current packages, but I must admit I'd hoped to
keep it for a week or two.

 The reason is that although I've built everything except for some
gnome packages, I didn't test sound until last night.  Totally
broken.  gvolwheel reported it couldn't connect open the mixer,
although alsamixer runs ok.  aplay segfaults, but the segfault is in
ld-2.15.so.

 Google found that *some* people have been hitting this since
glibc-2.14.  It also pointed me to a patch at cross-lfs,
http://patches.cross-lfs.org/dev/eglibc-2.15-fixes-1.patch
which is from the libc-alpha list last year.  It applies (eglibc
isn't _that+ different :), but I'm reluctant to try upgrading the
running glibc - doing in-place toolchain updates is the beginning
of a slippery slope!

 I'll try a fresh test build, and this time test 'aplay' in chroot.
So, for the moment this is just a heads-up that I'm looking at this.

 Still puzzled about what suddenly broke this for m

New failure in coreutils tests

Ken Moffat — 2012-04-28T23:39:07

 (resending, hopefully I've got the right list this time)

 I'm building the current book with the newer grep, man-pages,
kernel-headers, and autofoo that Matt is working on.  This is as a
test of my hardware (looking good at the moment, but a few BLFS
packages have caused me ICEs recently, so not yet certain if it is
now ok - will reply to the earlier thread with the gory details when
I'm convinced :)

 The host system is LFS-7.1.  In coreutils it now fails in 'check
user' with
../build-aux/test-driver: line 95: 12348 Aborted "$< at >" > $log_file
2>&1
FAIL: test-getlogin

 which sets non-zero status and breaks my build at the end of 'check
user'.  The code is

# Test script is run here.
"$< at >" >$log_file 2>&1
estatus=$?
if test $enable_hard_errors = no && test $estatus -eq 99; then
  estatus=1
fi

 I'm assuming this is from gnulib-tests/test-getlogin.c.  Not seen
this failure in my builds earlier this week, perhaps it's a one-off
or perhaps something in the 3.3.4 headers has changed.

 Or, maybe it's just my hard

Nitpick on the jh merge

Ken Moffat — 2012-04-26T18:02:57

 Working my way through the changes to my own scripts, when I got to
chapter 6 I found 6.10 was still called Re-adjusting the Toolchain,
despite the apparent rename of the xml file, and I found the first
part of the text confusing in the light of the chapter 5 changes.

 Compare
http://www.linuxfromscratch.org/lfs/view/development/chapter06/readjusting.html
 to
http://www.linuxfromscratch.org/lfs/view/jh/chapter06/adjusting.html

 I think that it's just the text in the first para after 'it is time
to adjust the toolchain' which has old content, but the name of the
html should probably also be changed to 'adjusting.html'.

 I can have a go at fixing this, but I'd like someone to confirm
it's wrong (wouldn't be the first time I've misread things).

ĸen

The jh branch has been merged

Bruce Dubbs — 2012-04-25T19:34:22

I've just merged the jh branch into trunk.  I had a little problem with the svn 
merge command so I baically did it manually.

Please pay close attention to any new builds and give tell us any issues you see 
with instructions, text, or the xml.

I have also updated the web site version of the book so there is no need to wait 
for the nightly build.

   -- Bruce

glibc configparms: any experience with -O3 on x86_64 ?

Ken Moffat — 2012-04-24T19:43:43

 For i?86, when we force it to build for m486 we also add -O3.  I've
been using -O3 for glibc on x86_64 in case it turns out to be
beneficial.  On my old single processor machines, I doubt that it
helped, but my suspicions about it are actually raised by results on
my phonon which definitely has enough horsepower.

 On LFS-7.1 I noted ldd segfaulted for one of the gst plugins
packages near the end of my system build, but that eventually built
ok.  On my i3, no problems.

 Now I'm doing my first test build of current svn, mainly to iron
out the bugs in my scripts, and then to sort out the changes for the
first part of my desktop scripts.  Here, glibc bombs out very
quickly (internal compiler error, segmentation fault in vfscanf.c)
.
 Did it twice, so at that point I dropped back to -O2 and it was ok.
Perhaps I should mention that everything else using my own CFLAGS
uses -O2, it's only glibc where I've tried -O3.

 Has anyone seen similar problems with -O3 in glibc (or, converesely,
has anyone used -O3 without

Cherry picking r9818 and r9822 for trunk

Matt Burgess — 2012-04-23T20:33:25

Hi,

I don't think $subject should be particularly contentious, but thought
I'd send a request for approval/comments just in case.

So, ticket #3066 states that on certain hosts Ncurses fails to build if
GPM is installed.

This is because the configure script is apparently finding the GPM
headers on the host.  This is Not Good (TM).

The fix for this is to add
--with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
builds so that it doesn't look at /usr/include at all.

In addition, --without-cloog and --without-ppl can be removed as they
don't do anything useful.

Jeremy, my gut feeling is that your proposed build method changes may
well make it into trunk fairly shortly, but in the mean time I'd like to
take the above mentioned commits as they fix known issues and are as
applicable to the old build method as the new (i.e. they don't require
any of your other changes in order to be applied to trunk).

Any objections?

Ta,

Matt.

Minor nitpick

Jeremy Huntwork — 2012-04-23T16:45:46

This changelog entry on 2012-04-05 isn't quite correct. It reads:

[matthew] - Use su from chapter 6 Coreutils in the Bash instructions, 
instead of the one from chapter 5. Install su as su rather than su-tools 
in chapter 5. Fixes #3057.

coreutils in chapter 6 doesn't install su. So the su you're using for 
tests all throughout chapter 6 is the one we explicitly install from 
chapter 5 coreutils. su is installed in chapter 6 by the shadow package.

I can't recall offhand why we chose to use su-tools originally. Probably 
just as a nominal reminder that we were using the one in /tools. :)

If I get a chance, just for curiosity, I'll see if I can look up that 
thread.

JH

Summary of changes in JH toolchain proposal

Bruce Dubbs — 2012-04-23T03:36:37

I've been studying Jeremy's changes and want to summarize them here.

Chapter 5
   Binutil pass 1
     Add two configure options:
       --with-sysroot=$LFS
       --with-lib-path=/tools/lib

     These are not in the main binutils configure command, but are in the
     configure for ld


   gcc-pass1
     Change 28 header files (as in pass2):
       3 sparc, 1 mn10300, 1 tilepro, 1 alpha, 1 vax, 2 ia64, 2 mips,
       1 bfin, 1 cris, 1 microblaze, 1 s390, 1 xtensa, 1 m68k, 3 i386,
       1 sh, 1 m32t, 3 rs6000, 1 tilegx, 1 frv, and 1 base linux.h

       The only places that affect us where the sed matches is in
       gcc/config/i386/linux.h and gcc/config/i386/linux64.h.
       I doubt any of the other files need to be
       changed, but it doesn't hurt anything either.

     for file in \
       $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
     do
       cp -uv $file{,.orig}
       sed -r -e 's< at >/lib(64)?(32)?/ld< at >/tools&amp;< at >g' \
              -e 's< at >/usr< at >/tools< at >g' $file.orig &gt;

minor

Jeremy Huntwork — 2012-04-22T22:41:36