gmane.linux.lfs.devel

Re: LFS SVN and Systemd Report

Markku Pesonen — 2012-05-26T08:15:09

I'm still hoping someone fixes this upstream. This is what Kay Sievers
said in April:

"After udev is merged into the systemd tree you can still build it for
usage outside of systemd systems, and we will support these builds
officially. In fact, we will be supporting this for a long time since
it is a necessity to make initrds (which lack systemd) work properly.
Distributions not wishing to adopt systemd can build udev pretty much
the same way as before, however should then use the systemd tarball
instead of the udev tarball and package only what is necessary of the
resulting build."
( http://article.gmane.org/gmane.linux.hotplug.devel/17392 )

Building udev "pretty much the same way as before" is not possible with
the systemd-183 tarball.

Re: LFS SVN and Systemd Report

Bryan Kadzban — 2012-05-26T04:10:02

It also doesn't work with LVM, according to that wiki page -- which is a
showstopper for both my rootfs, and my initramfs.  :-)

Also I have configuration all over the place (DVD playing software's
config somewhere in my home directory, /etc/fstab, maybe elsewhere that
I no longer remember) that refers to /dev/disk/by-<something> to find a
disk's device file.  Making udev create by-label symlinks for LVs was
one of the first things I had to do when rebuilding last time.

There are also persistent links for V4L devices (which I haven't used
because I haven't done anything with V4L since support for them got
added to udev), and for input devices (which xorg uses internally, but
which aren't exposed in a config file anywhere).

And that might all be reasonable for a really minimalist setup -- except
when the alternative is full systemd.  (Too large of a jump for my
liking, anyway.)  The persistent links are at least documented somewhere
else; maybe someone will come up with a package that's mdev plus
persisten

Re: LFS SVN and Systemd Report

Ken Moffat — 2012-05-25T23:31:32

 I too have no wish to be forced to install systemd - if it solves
problems, they are not problems I've seen on my own systems.

 Unfortunately, mdev appears not to be a full replacement.  Looking
at the gentoo wiki - https://wiki.gentoo.org/wiki/Mdev - I see two
breakages for desktop users, and a further problem:

1. Xorg now expects to use evdev on linux, instead of mouse and kbd.
Evdev requires udev.  Specifically, it looks for libudev.pc.  I
suppose we could go back to kbd and mouse, as if we were on some
lesser system, but I would prefer not to.

2. Any desktop packages which require (g)udev will not build.  On my
own icewm desktops I can happily ignore such packages, but users of
gnome and perhaps other DEs will be disappointed.

 The further problem is with additional usb devices.  The gentoo
wiki implies a usb printer can work, but I've seen nothing about
adding rules to sort out other devices.  In my own case I've got
rules for USB sticks (every time I get a new one, it announces
itself as something

Re: LFS SVN and Systemd Report

Bruce Dubbs — 2012-05-25T19:40:54

That would be a 'good thing'.

   -- Bruce

Re: LFS SVN and Systemd Report

Jeremy Huntwork — 2012-05-25T17:51:03

There are dev alternatives, like mdev from busybox. It may at least be 
worth investigation to see if we can avoid the systemd craziness completely.

JH

Re: LFS SVN and Systemd Report

Armin K. — 2012-05-25T17:25:10

Yes and yes. Udev will handle modules later. And /sbin/init is link to 
systemd, as well as poweroff,runlevel,shutdown,reboot are links to 
systemctl. I don't have any of sysvinit init programs installed.


Well, yes. Also, intltool is needed for NLS, which needs XML::Parser 
which needs expat. I think that dependency can be ommited by using 
--disable-nls.


Yeah. Also, coreutils can benefit from libcap2 and acl (another dep of 
attr).


[..]


[..]


[..]


Scroll down.


You're not only user of LFS. There are people who use it.


systemd will still interface with fsck.ext4 for example which is part of 
e2fsprogs, but it does implement something internal for fsck tough which 
I don't understand (the systemd-fsck).


I was trying to make point for that. But I wasn't good enough at it. I 
agree it is hard analyzing 149025 lines of code, but those lines 
reimplement most of the tools you said "are part of LSB core" since it 
is easier and faster to eg set hostname or create file using system call 
than run s

Re: LFS SVN and Systemd Report

Bruce Dubbs — 2012-05-25T16:51:42

I think the reason it finishes so early for you is that the drivers are 
modules and have not yet been initialized.

Is /sbin/init a link to systemd?

My system has [    1.880758] Switching to clocksource hpet
Perhaps that difference is just HW.


OK then.  We could write a script that would do: 'mount | grep -v 
cgroups' if there are no parameters and another command: alias 
cgroups='mount |grep --color=never cgroups'


We'll need to add dbus to LFS. :(    The only requirement I can see is 
expat so we'll need that too.


I suppose they mean libcap2 which has attr as a dependency.

So we have to add 3 packages that we don't want to support systemd what 
we don't want in order to get udev which we do want.






Other than the dependency issue, I can live with that.


Naming is not a terribly important issue.  We could symlimk some names 
though.



That's true.  We don't show the users much about mknod any more.


Those are part of LSB Core.  Using them does not add overhead.


I don't use modules.


So we

Re: LFS SVN and Systemd Report

Armin K. — 2012-05-25T15:11:43

[    1.176174] Switching to clocksource tsc
[    1.374790] systemd[1]: RTC configured in localtime, applying delta 
of 120 minutes to system time.
[    2.487258] udevd[55]: starting version 183

So, basically kernel finishes loading of builtin stuff at 1.176 seconds 
and then systemd starts and pulls in udev. That's where it gets that 
value from. Others are just modules, and they are running paralely with 
other services. As for other messages, it's just usb subsystem which 
turns on and off my mouse for some reason.


No, it is listed in README as requirement. Also it is not systemd's 
fault that kernel exposes cgroups like that.

 From README:

REQUIREMENTS:
         Linux kernel >= 2.6.39
                 with devtmpfs
                 with cgroups (but it's OK to disable all controllers)
                 optional but strongly recommended: autofs4, ipv6
         dbus >= 1.4.0
         libcap
         PAM >= 1.1.2 (optional)
         libcryptsetup (optional)
         libaudit (optional)
         libselin

Re: LFS SVN and Systemd Report

Bruce Dubbs — 2012-05-25T13:52:32

It's not clear what that does.  From dmesg, it looks like the kernel is 
till running at 6.7 seconds.  It will take a little longer for the 
kernel to load all those modules.

I don't understand where systemd gets it's numbers.  It


That's not very clear to me.


Better.


cgroups should be optional.  Imposing complexity on simple problems is 
not letting the user decide.


Another case of taking away user choice.


I've asked on the hotplug list, but I havn't received a response.


If you want to build a simple web server with no xorg, why would we need 
dbus?  Another case of imposing a lack of choice.


We use the login from shadow.


   -- Bruce

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

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-23T02:18:26

Actually, from my experience a packaging tool eases a lot of the pain 
inherent in the process you've described. Auto-fetching of sources 
(including dependencies), auto-preparation of a clean build tree, 
post-build reports of what files have been included in the package and 
what (if any) auto dependencies have been discovered.

Re-doing a build if issues or errors are found (including, if necessary, 
setting up an entire chroot system as well) becomes a matter of one 
command, instead of several.


This is one of those scenarios where I think it's difficult to see how a 
thing will be useful or beneficial until after you've actually tried it 
out. I'm not guaranteeing you'll think it better, more useful or simpler 
- though my belief is that it does actually simplify the process of 
correctly building and documenting the build of an individual package, 
once the tools are available and the infrastructure in place.


Perhaps it really is something that needs to been seen and experienced. 
I can do as I pl

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

Re: Once more: Package Management

Pierre Labastie — 2012-05-22T06:46:13

Le 22/05/2012 01:58, Armin K. a écrit :
Hi,
It depends on what you want to do with a package manager. I would 
separate two main uses :
(a) Building from sources using a spec file.
(b) Packaging and installing.

As far as (B)LFS is concerned, (a) involves some kind of rewriting of 
the book instructions to make a spec file. I do not know whether it is 
the purpose of (B)LFS to show how to do that. Among the PM I know 
(mainly dpkg and pacman), pacman is by far the easiest for this purpose. 
The spec files used by Bent linux were very simple too, but the project 
seems to have been stale for a few years. I agree that dpkg is more work 
to learn, but at least it is Makefile instructions, not a completely new 
language as rpm.

If the only aim is to do (b), and I would believe that it is what is 
needed by (B)LFS, dpkg is by far the simplest: it amounts to build per 
the book instructions adding DESTDIR to the install commands, making a 
very simple description file (sample below), and running dpkg-deb then 
d

Re: Once more: Package Management

Armin K. — 2012-05-21T23:58:38

I don't get what's the whole thing about, but I think that packaging can 
be documented very well. I have installed about 1000 packages using 
DESTDIR or equivalent method, writing base INSTALL files which contain 
just cp -r commands and some triggers, like adding an user, chowning, 
chmoding, running gtk-update-icon-cache, man-db update, installing info 
files and such. It's not hard work and it can be done if we just put 
some effort. Also, if this is to happen, I suggest we don't make any 
changes to the current BLFS since Bruce has planed release for 
September, and it isn't enough time for the goal. I am in process of 
fully documenting build process from cd sourcedir to after make install 
DESTDIR, including install triggers, post make install stuff like 
stripping, creating aditional files, symlinks and such.

Also, I see you mention package managers ... For me, Debian's dpkg is 
the hardest one. debian/rules file uses Makefile syntax which I am not 
familiar with. Red Hat's rpm uses some kind of sp

Re: Once more: Package Management

DJ Lucas — 2012-05-21T23:27:12

Seems my phone ate my previous response...easier to type on a real 
keyboard anyway.

It omits the core point of LFS...education. I dislike providing binary 
packages to users, but a working example of how to create those binary 
packages is something we've lacked for a long time, plus getting those 
packages that don't honor DESTDIR explained with a working example 
chroot...I just can't (or possibly don't want to) see a downside as far 
as education or documentation is concerned. Yes, it'll undoubtedly be a 
bit hairy at first. As far as choosing what PM to use, I guess it is no 
different than making the decision to use vim over emacs (an equally 
nasty holy war). As long as concepts learned are applicable to other 
PMs, then it is all good. I suspect a good deal could be taken from 
other consumers of pacman (that is what Arch uses, right?).

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-21T01:10:52

[snip - a number of good, thoughtful questions]

I'm going to have to let your questions brew for a while before I can 
reply to them. Perhaps someone else will have an opinion regarding them 
in the meantime...

JH

Re: Vim 7.3.xxx

Bruce Dubbs — 2012-05-21T01:10:04



OK, I will reorder the patch to be first.


I'll fix this in a couple of minutes too.

Thanks for the feedback.

   -- Bruce

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-21T01:05:56

This method does not collect and keep package dependency. Using a 
manager like pacman, ff you have a repository with dependency baked in, 
when you go to build an individual tool you can automatically discover 
and download/install into your build environment all required packages - 
and only the required packages.

Also, for a reader who is serious about making a distro, creating a 
giant tarball of the LFS base does not teach any good practices for 
creating and deploying a distribution of their own.

Another benefit of a package manager is that changelog information can 
be related to individual packages and can be easier to track changes - 
again, this is less important in LFS, but could be useful in BLFS.

If it's simplicity that you like, one advantage of pacman is that the 
packages themselves are actually just tar archives containing the files 
and metadata.

JH

Re: Once more: Package Management

Baho Utot — 2012-05-21T00:57:50

[putolin]



Just use the dependencies that are required that's in the book.  You as 
a "user/builder can add any additional one you would like.


pacman package management also has a set of tools to check the resulting 
package for "corectness" based upon LSB.  It will also detect permission 
problems and RPATH issues.


One doesn't need to fetch a binary, just the PKGBUILD file and then you 
can build it


I have placed my build of LFS 6.8 using Arch linux pacman package 
manager onto github.

The URL: github.com/baho-utot/LFS-pacman

Have a look at it if you like.

I don't follow the recent comments at all.
Pacman packeage manager has some great features that makes rooling your 
own easier.
For example if I get the PKGBUILD for a package that is in BLFS from 
someone then I am not duplicating my effort and I have a mecanisim that 
gives me a "package that will work".

Package management is also learned so why not include something in the book?

I see using pacman package management as a plus.

Re: Vim 7.3.xxx

Fernando de Oliveira — 2012-05-20T23:21:25

[...]


Just did it. Thank you very much, Bruce. How fast!

Couple of observations:

1. When scripting, if patch is after the echo's, some fail, script stops.
patching file src/feature.h
Hunk #4 FAILED at 1316.
1 out of 4 hunks FAILED -- saving rejects to file src/feature.h.rej

Fine if patch is before echo's.

2. Broken
http://www2.nl.vim.org/unix/vim-7.3.tar.bz2
http://www2.nl.vim.org/extra/vim-7.2-lang.tar.gz

These work
ftp://ftp.vim.org/pub/vim/unix/vim-7.3.tar.bz2 (this already in both books)
ftp://ftp.vim.org/pub/vim/extra/vim-7.2-lang.tar.gz

3. In BLFS:

typo: tar -xf ../vim-7.3-lang.tar.gz --strip-components=1

s/3/2/

Re: Once more: Package Management

Ken Moffat — 2012-05-20T23:09:49

 The more I think about this, the less happy I am.  Point 2 doesn't
really help editing BLFS as far as I can see (upgrading a package
usually needs several builds - typically, for me, a first to see if
it actually works when I use it, then others to get nice clean
measurements, check what is in the DESTDIR (or INSTALLROOT), and
review options for the optional dependencies and any testsuite.

 OK, for a few packages I will build them without being able to
confirm that they still work (e.g. mutt in the recent tagging), but
in general the absence of required dependencies is the least of the
issues - and anyway, sometimes the dependencies need to be upgraded.

 Then there is the question of dependencies - in BLFS we don't
normally tell people how to use optional deps.  Sometimes they are
picked up automatically, but many times you have to pass a switch to
get them used.  The instructions in BLFS are hopefully correct, but
they don't suit everyone.

 I'm also wary of standard workflows - my own LFS build is diffe