Hey all!
As a favor to Gerard, I sat down today and made a list of the
differences between the unstable and testing branches of the LFS book,
in preparation to eliminate Testing, as was proposed by G previously.
Here's a list of all changes I can find currently:
Build command differences:
Chap
Gerard Beekmans wrote:
On February 18, 2005 05:15 pm, Jeremy Utley wrote:
As a favor to Gerard, I sat down today and made a list of the
Thanks for the quick turn-around Jeremy and on such short notice too. It's
appreciated. The reason is I would like to get this task done asap whil
Gerard Beekmans wrote:
On February 15, 2005 11:27 pm, [EMAIL PROTECTED] wrote:
/configure --help
mentions --with-selinux and not --enable-selinux
--with and --enable are sometimes (often?) synonymous in configure scripts.
Can somebody verify this and Bugzilla it if it's an actual issue and
.sSweetMarie wrote:
cannot find -lcidn
collect2: ld returned 1 exit status
This is the key in all of it. 2 things are possible:
1 - you used a different version of glibc in chapter 5 than in chapter 6
(a glibc that does not include the libcidn add-on in chapter 5)
2 - you specified --enable-a
Randy McMurchy wrote:
Hi all,
I noticed in the patches project there's a patch for IPRoute2 named
free_error. There's a -1 and -2 version. Does anyone know if this
patch is scheduled for inclusion in the book, or is it some sort of
optional patch, to be used only if you encounter the error it fixes
Randy McMurchy wrote:
What do you mean a bother? For almost all the packages in the
book that build in just a minute or two, it would take less
than 5 minutes to update the build entities, installed programs
and libraries in the book.
This, IMHO, is a highly optimistic view. For each upgrade,
Randy McMurchy wrote:
This I don't understand. I thought syslog-ng was the new syslog
daemon of choice for LFS. If it goes away, what is destined to
replace it?
Gerard's post came as a shock to me as well, so I took the opprotunity
to ask him about it on IRC, since he happened to be there at th
Steve Crosby wrote:
(Snipped excellent description of the issues)
Steve - thank you very much for the clear, concise description - this is
basically what I got from Gerard on IRC, but there's no way I could have
worded it as well as you have. It is true that sysklogd was mostly
removed out of L
Nathan Coulson wrote:
I was wondering if that "Is the link up command" could be modified...
I mean it sounds like we could create new networking devices on the
fly, or have networking devices that are only up after special
commands are done. Our current scripts would choke on that.
Yep, I ran
Matthew Burgess wrote:
Folks,
For those of you not following LKML, there's been a really really long
thread regarding how the kernel development process can be adapted to
improve the stability/quality of the 2.6.x kernels. The original
thread starts at
http://www.ussg.iu.edu/hypermail/linux/ke
Bruce Dubbs wrote:
What if binutils were just rebuilt using the same package, but leave
the libraries unstripped?
Because the problem is actually if libc.a has been stripped with buggy
binutils, removing the TLS information from the library. The only
resolution would be to completely recompile
Bruce Dubbs wrote:
Jeremy Utley wrote:
Because the problem is actually if libc.a has been stripped with
buggy binutils, removing the TLS information from the library. The
only resolution would be to completely recompile Glibc.
I see. It's glibc that get corrupted. Would it be possib
Jim Gifford wrote:
What's wrong with the one I did Matt, udev-config-2.rules. I made that
after we agreed upon the changes??
The problem with the one you have proposed is we don't have all those
extra groups. dialout, audio, video, floppy, tape.
I will be doing the update to the new groups toni
Matthew Burgess wrote:
Kevin P. Fleming wrote:
But why does LFS-SVN need to wait on BLFS? BLFS is not based on
LFS-SVN, it's based on LFS-6.0.
Exactly, so if we go and remove all those users and groups that we
don't think are required/desired on a base LFS system then it'll cause
pain for those
Stef Bon wrote:
Hello,
after some unclean shutdowns of my computer, I saw that
the openldap server (slapd) leaves some files in the /srv/ldap/run
directory, which makes the startup script think that the server is already running.
In this case it's about the files slapd.args and slapd.pid.
Now is
Edwin van Vliet wrote:
Hi folks,
Just finished yet another LFS installation (SVN), keeping as close to
the instructions as I liked. This time I also kept some notes, for
some things aren't very consistent throughout the book. Here they are:
1) I believe /var/lib/locate should be created in chapt
TheOldFellow wrote:
Fair comment. My earlier posts in LFS-Support in reply to an OP who was
interested in gcc-4 had the links in. But thanks for repeating them.
I'm attempting to stimulate some interest in moving LFS forwards.
It won't be long before LFS is far beyond Greg's build process. Gr
Matthew Burgess wrote:
TheOldFellow wrote:
However it's the LFS new technology gestation period that gets me down.
And I only have i686 boxes :-(
This isn't meant to sound as harsh as it's going to. But, if you
don't like the length of time it takes to get new technology into LFS
then post
TheOldFellow wrote:
>
>Yes, my intention was to show some alternatives and provoke a dicussion.
> I do not propose that you just copy the script - the LFS aims are quite
>different from Greg's - no reason you can't examine them for good ideas
>though.
>
>
With the new build process being worked
Matthew Burgess wrote:
Absolutely no changes are permitted on this branch that aren't
directly related to the gcc-4.0 release. No backports of trunk fixes,
no stylesheet fixups (sorry Manuel :) ), etc. The only things that I
anticpate hitting this branch are dumpspecs stuff and patches for
pa
Matthew Burgess wrote:
Jeremy Utley wrote:
Randy - both of these are strictly cmmi installations - their configure
scripts will pick up deps just fine. I can take a look for the deps for
you guys, if you like.
I started looking into this, but soon got distracted unfortunately.
As you&#x
Matthew Burgess wrote:
Jeremy Utley wrote:
Then what good, may I ask, is this having this branch, if the rest of
the packages are not kept current to the book? Seems to me like it's
a waste of a branch if it's not going to be kept up to date until gcc
4 makes it into our mainline b
Matthew Burgess wrote:
Why is it going to take 2-3 months to get the book up to speed? The
techniques for dealing with the specs file are already known. That
just leaves documenting the patches required for our and BLFS'
packages. Certainly not 2-3 months worth of effort methinks.
Matt.
Our b
Randy McMurchy wrote:
Please, Jim, for me and I'm sure there are others that want to know
the same thing, can you explain *in a technical manner* how the
toolchain could be any "cleaner"?
A simple example will document this clearly. Take building LFS on a
Fedora core release. In the past, we
Randy McMurchy wrote:
Jeremy Utley wrote these words on 04/18/05 23:14 CST:
Randy McMurchy wrote:
Please, Jim, for me and I'm sure there are others that want to know
the same thing, can you explain *in a technical manner* how the
toolchain could be any "cleaner"?
A
Randy McMurchy wrote:
It does. But it is a far cry from the original post by Jim a few
hours ago where the book will have *one* method of building, which
includes rebooting into the 'tools' host.
As long as there is provisions to build remotely, using a known
good host, there is only positives to b
Bruce Dubbs wrote:
My objection was to the comment that rebooting was mandatory. If
instructions are given to give the user a choice and to explain the pros
and cons, I do not object.
As I mentioned, the WORST case scenario would be to provide a hints
document outlining the process for using c
Randy McMurchy wrote:
Cool!
But don't make it a hint, make it part of the book. :-)
Ideally, yes, it should be in the book. However, if for some reason
that's unfeasable, because of limitations in the XML or whatever the
case may be, then my feeling is it could be easily written up as a hint
Just for a heads up to the rest of the community. Since one of the
goals of the new cross-lfs stuff is to make a useable 64-bit build of
LFS, and since I have a AMD64 machine with LOTS of empty hard drive
space, I'm working on setting up partitions with each of the major
64-bit distributions insta
Randy McMurchy wrote:
Hi all,
Discussion has turned to assigning UID's and GID's to specific users
and groups. Is this really necessary?
I know I won't follow any prescribed method of assigning UID/GID's
as I have already a system I use. Should BLFS really be in the
business of assigning UID's and
Erik-Jan wrote:
Jim Gifford wrote:
Erik-Jan wrote:
Hi there,
In cross-LFS, chapter 5.10 Glibc-2.3.5, configure, the book says:
--host=${LFS_HOST} --build=${LFS_TARGET}
Shouldn't that be the other way around?
--host=${LFS_TARGET} --build=${LFS_HOST}
From ./configure --help:
--build=BUILD configu
Archaic wrote:
On Sat, Apr 23, 2005 at 08:47:36AM -0700, Jeremy Utley wrote:
The problem is, if the book, as it is currently written, is followed,
then system users & groups will be created as non-system.
But that doesn't actually matter, it is merely an historical issue that
*
Greg Schafer wrote:
Jeremy Utley wrote:
Greg's still focusing on strictly x86 builds
The key difference is that I only publish what I can test. Think about it.
Your claims of LFS "support" for other arches up until now is bogus.
But the multi-arch XML approach is a good m
Mark A. Nicolosi wrote:
I think the book should mention something like "If you're computer has
SCSI disks and you don't have any IDE disks, sda would be (hd0)." But
made to fit better into the paragraph. Hope that makes sense ;-)
Actually, the ideal way of finding out GRUB's terminology is to us
john wrote:
Jeremy Huntwork wrote:
My intention in making this (nowhere near finished!) rendered version
of the book available is so that it will answer a few questions about
what cross-lfs is and aims to be, making it possible for more to get
involved or interested in the book, offer comments,
Peter Ennis wrote:
Anyone seen this or similar?
Should I ignore and continue?
Running FC4T1 host
I would not recommend FC4 for a build host at current, considering it
has pre-release GCC4 code included in it, which causes known compilation
issues with many packages.
-J-
--
http://linuxfrom
Marcus Singleton wrote:
That's what I was thinking.
I'm planning on using Ubuntu 64-bit, as it's the only one that will allow me
to boot up from hard disk (NForce4 problems) unless you can suggest another
OS that's predominantly 64bit and has nforce4 drivers.
I have Ubuntu 64-bit, Gentoo 64-bit,
Matthew Burgess wrote:
Folks,
I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
1) It adds host dependencies of bison and flex
2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
and fix
3) FSF recently released 2.16, bringing it back up to speed with
mode
Randy McMurchy wrote:
Bruce Dubbs wrote these words on 05/15/05 18:42 CST:
Matthew Burgess wrote:
As for flex, it looks
like the maintainers went AWOL again :(
http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
11 submitted patches yet to be applied. Maybe it would be p
Marty _ wrote:
Good answer, never investigated udev to be quite honest, just thought
it was another form of devfs from the guide.
To add to your note, there isnt a difference between the two, ive just
got so used to slackware's /dev style I couldnt handle the entire
directory tree the devf
40 matches
Mail list logo
