headers
Armin K. | 25 May 14:55
Picon
Favicon

LFS SVN and Systemd Report

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 services is as following
$ free -m
              total       used       free     shared    buffers     cached
(Continue reading)

Permalink | Reply | 5 comments |
headers
Marius Tolzmann | 23 May 02:00
Picon
Favicon
Gravatar

About packaging LFS - How it works for me 8)


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 years ago we were forced to rebuild the whole system - because it 
seemed to be easier to rebuild than to upgrade and solve the dependency 
hell.
The way we maintained our LFS based system between 2004 and 2012 worked 
wuite well, but was not really perfect: To document how a package was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando de Oliveira | 19 May 18:19
Picon
Favicon

Vim 7.3.xxx

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?

-- 
[]s,
Fernando
--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jeremy Huntwork | 19 May 15:26

Once more: Package Management

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 accordingly in an efficient, reliable way.

Rationale:

(B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a 
huge undertaking - and it's a difficult beast to maintain. In order to 
create a stable reference page in BLFS an editor has to have spent the 
time to build all of LFS, tweak it, go through current BLFS, manually 
install dependency packages and then carefully document the package he
(Continue reading)

Permalink | Reply | 28 comments |
headers
xinglp | 12 May 20:27
Picon

problem of bootscript setclock

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.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Permalink | Reply | 5 comments |
headers
Ken Moffat | 11 May 17:06

resizecons : a proposal

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

--
(Continue reading)

Permalink | Reply | 37 comments |
headers
xinglp | 10 May 22:06
Picon

resizecons not installed by kbd

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

But the manpage of resizecons was installed.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Permalink | Reply | 11 comments |
headers
Jeremy Huntwork | 9 May 22:19

Suggestion

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

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Permalink | Reply | 5 comments |
headers
Ken Moffat | 7 May 19:55

gtk-doc-rebuild.xml

 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
-- 
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
Permalink | Reply | 1 comment |
headers
Jeremy Huntwork | 5 May 16:24

Wording fix

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

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Permalink | Reply | 9 comments |
headers
Andrew Benton | 4 May 12:45
Favicon

Rename sources?

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:

> 
>  But do you not see from a newcomers
> perspective that you seem to use "source directory" in more ways than one?
> 
> $LFS/sources and (for example) $LFS/sources/binutils-x.x could BOTH be referred to as "source directories".
> 
> And when you say to build (again for example) the binutils-build directory OUTSIDE of the source
directory, 
> that can have more than one meaning.  It could mean to build it outside of the $LFS/sources directory
> OR it could mean to build it outside of the $LFS/sources/binutils-x.x SOURCE directory, 

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

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Permalink | Reply | 1 comment |

Gmane