On Thu, 31 Mar 2005, Bruce Dubbs wrote:
I just got a new system for testing LFS builds. It is a Intel 3.2GHz P4
system with EM64T technology. It came with RH Enterprise 3.0 for
AMD64 and EM64T preinstalled.
8-D
I'm not really sure what the EM64T technology does, except Googling
around
On Fri, 1 Apr 2005, Matthew Burgess wrote:
Matthew Burgess wrote:
Until then, you'll have to wait until I render the book and post a link to
it :)
OK, it's now rendered and available at
http://www.linuxfromscratch.org/lfs/view/testing/.
Regards,
Matt.
Curse you, Red Baron! I've
On Sat, 2 Apr 2005, Matthew Burgess wrote:
Ken Moffat wrote:
On Sat, 2 Apr 2005, Matthew Burgess wrote:
So that's why I never saw it. I simply don't have the time or resources
to do a full rebuild every time a package gets upgraded.
Hmm, now I've seen your comment that you hadn't
On Fri, 1 Apr 2005, Matthew Burgess wrote:
PS: SBUs, disk usage and package tarball size reports would be most
welcome, from anyone with the necessary scripts to record them. I think
the upgraded packages should be pretty accurate, but I've not done a
full system build with them yet, so I
On Mon, 18 Apr 2005, Randy McMurchy wrote:
SSL/SSH != minimalistic
I realize your suggestion Jim is a concession to a serious drawback
in the new methodology, but just in the hour or so since you posted
you message, there been talk of adding SSS, SSL, Lynx and GPM to
core LFS (not all
On Sun, 8 May 2005, Jeremy Huntwork wrote:
Could someone throw me a cluebat here? I've found a patch that is needed
for the sparc architecture and kbd-1.12 (Build fails with:
kbdrate.c:167: error: structure has no member named `period')
The patch I've found is placed under two licenses it
On Fri, 13 May 2005, Jeremy Huntwork wrote:
Ken Moffat wrote:
In my opinion, put it all in variables - the sparc page has '-m32'
exposed to the reader without an explanation (although it might be
explained on another page). Put it all in variables, and explain them
at the beginning
On Fri, 13 May 2005, Jim Gifford wrote:
Ken that's one of the things we are going to do after we get the builds
working is go through every page and add more text or less text to give
the reader a better understanding. We would welcome your input on this.
I'll be happy to contribute, but
On Sat, 14 May 2005, M.Canales.es wrote:
El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió:
Lastly, IMHO the combo HOST != TARGET only is usefull in two cases:
To build a full system (with X, servers, etc...) in a fast machine that will
be later instaled in a slow machine.
Or to build
On Sat, 14 May 2005, M.Canales.es wrote:
Don't miss the point of this thread: Is there realy some case where you must
to build the packages up to reboot in one machine (the HOST) and then to
copy that temp system to other machine (the TARGET) to build the final
system?
Ah, I misunderstood
On Sun, 15 May 2005, Matthew Burgess wrote:
So, does anyone think we should still stick with HJL binutils, and if
so, what are the compelling reasons for doing so?
I will be less than surprised if the multi-architecture book has to use
HJL for some architectures, in the past HJL has always
On Tue, 21 Jun 2005, Jim Gifford wrote:
The one thing I'm not sure on is if the SBU's will be the same on the
different architectures, as far as the build size goes, it should be the
same except for one package which is gcc, since we have a 32bit ABI
build, 32/64 ABI build, and 32/n32/64 ABI
On Wed, 6 Jul 2005, Bernard Leak wrote:
Dear List,
I present a few nits I have picked out of the
hair of blfs-6.1-pre1 (the book):
LFS, not blfs.
The word is programme. Yes, it really is, unless you
are writing American. It is a curiosity of the LFS book
that
Should I expect /mnt/lfs/dev to be busy when I come to shut down after
building 6.1-pre2 (in an xterm, if it matters) ? Nothing showed in lsof
or fuser, and I was able to remount r/o.
Maybe this isn't new and I've just not noticed before ?
Ken
--
das eine Mal als Tragödie, das andere Mal
On Thu, 7 Jul 2005, Matthew Burgess wrote:
Ken Moffat wrote:
Should I expect /mnt/lfs/dev to be busy when I come to shut down after
building 6.1-pre2 (in an xterm, if it matters) ?
Not if you were using the version specified in that book. Later
versions kick off a daemon, which one has
On Thu, 7 Jul 2005, Chris Staub wrote:
The coreutils installation page (in both Chapters 5 and 6) strongly
recommends adding DEFAULT_POSIX2_VERSION=199209 to the configure
command. I've installed lfs several times over the last couple of months
without that, and never had a problem. It is
On Mon, 25 Jul 2005, Matthew Burgess wrote:
LFS-6.2:
This will just be an incremental release, further stabilising our
already proven PLFS-based build method. GCC-3.4.x combined with
Glibc-2.3.5 seems pretty robust, and adding binutils-2.16.1 to the mix
should further solidify that.
On Mon, 25 Jul 2005, GN wrote:
On Monday 25 July 2005 12:36, Matthew Burgess wrote:
A number of people have emailed me privately, and its also come up
on the list recently, so here's my thoughts on what could/should be
going on in LFS land. Yes, I know it's taken me far too long to
On Tue, 26 Jul 2005, TheOldFellow wrote:
OK, we have some i18n 8-bit users, but multibyte? I see some names than
might be Chinese on the list occasionally.
I imagine some of our german-speaking users might prefer to use utf. I
often see posts (not necessarily on lfs lists) where there are
I've definitely got a strangeness in my current build scripts for
pure64 x86_64 from i686. First time I built it, running make check on
target glibc hung in inet tests. Looking at it, I discovered I had
omitted the fix_test patch. Applied that, tests completed.
This time, I'm trying to get
On Tue, 26 Jul 2005, Ryan Oliver wrote:
Indeed I have seen this a couple of times...
From (possibly faulty) memory I recall noticing it in chroot builds
(which for convenience is predominately what I have done of late...)
will check my logs and get back to you...
Thanks, I'll appreciate
On Fri, 29 Jul 2005, Jim Gifford wrote:
In my
book patching GCC should only be done when neccessary, to me there had
to be a better solution.
Hi Jim,
Applying that remark to a different context, I guess that means you'll
be dead against lib|lib32 (instead of lib64|lib), or indeed pure64
On Sat, 30 Jul 2005, Bruce Dubbs wrote:
This is a list of the remaining 6.1 bugs that need package updates:
Bug Package Assigned to
1350 Kerberos
1369 Tidy Randy
1430 LIBPCAP
1443 Firefox
1444 Thunderbird Richard
1475 Ethereal Randy
-
Bruce, I take it
On Sat, 30 Jul 2005, Jaap Struyk wrote:
Op za 30-07-2005, om 17:19 schreef Jaap Struyk:
What the 2 have in common is:
asm operand 1 probably doesn't match constraints
and
impossible constraint in `asm'
Both modules build fine on a clean kernel, but the errors don't make
sence to me.
This is prompted by upgrading zlib to 1.2.3 (thanks to Matt for the
heads up). Everything in my system using a shared libz is linked
against libz.so.1 (good), but we persist in offering packages a symlink
from /usr/lib/libz.so to /usr/lib/libz.so.1.2.3 [ png bit me when I
overlooked that in my
On Mon, 1 Aug 2005, Randy McMurchy wrote:
Hi all,
A minor nit I noticed in the Chapter 5 GCC instructions (all versions):
Noted in the SBU times between Pass 1 and Pass 2 is that they seem to
be reversed. Pass 1 is shown to be 4.4 SBU and Pass 2 is 11.0. Shouldn't
these be the other way
On Wed, 3 Aug 2005, steve crosby wrote:
Just a heads up - util-linux 2.13 will remove several items, as per
the following changelog entry for pre1
Changes:
GNU autoconf/automake/libtool are now used for building. schedutils
were added. Support for curses implementations other than ncurses
On Mon, 8 Aug 2005, Torsten Vollmann wrote:
Hi Folks.
I think of this because I want to run a stable LFS on my main system but if a
package is updated and put into LFS-trunk I'm always wondering if it could be
applied to LFS-stable, too, or if it would mix up the build process because
the
On Mon, 8 Aug 2005, Matthew Burgess wrote:
Jens Olav Nygaard wrote:
My system clock seems to gain an extra five minutes per hour,
snip
Any ideas?
Yep, I just use ntp (see BLFS). My hardware clock seems to gain even
when the system is switched off! I have a bootscript that syncs the
On Tue, 9 Aug 2005, Ken Moffat wrote:
I plan to look at dhcpcd in a few minutes
Well, the good news is it seems to be maintained again (a 2.0.0 version
at berlios.de incorporating recent patches from debian and gentoo).
The bad news is the layout of the source has been tidied up, moving
Hi,
One of the things I've started spending more time on recently is trying
to ensure my systems are patched against known problems. [ Ah, the good
old days when I only had a handful of applications to worry about ].
Most of the packages I'm trying to monitor are not in the LFS book, but
a few
On Tue, 16 Aug 2005, Archaic wrote:
On Tue, Aug 16, 2005 at 09:47:06PM +0100, Ken Moffat wrote:
This vulnerability should be low risk for most of us, but I think it's
the sort of thing that ought to be applied.
Agreed.
Hmm, I think I should have checked the patches list before
On Mon, 22 Aug 2005, Matthew Burgess wrote:
Hi folks.
Does anyone know why shared libraries need the execute bit set on them? My
most recent build (gcc4-based) has most[1] *.so files installed with 755
permissions. As it's so consistent, I'm assuming there is a reason for them
to be
On Sat, 20 Aug 2005, Ken Moffat wrote:
On Fri, 19 Aug 2005, Jim Gifford wrote:
Ken, Ryan, Doug, and others
Do we need to make a change here for the pure64 build, or is further
testing needed?
Well, I've got through this part now, using 20050821, building pure64
from my own pure64
On Tue, 23 Aug 2005, Ken Moffat wrote:
Sack-cloth and ashes time. I missed the slibdir=/lib part. Since LFS is
all about learning, anybody like to point me to a HOWTO on learning to read
what the book says, rather than what I think it says ?
Thanks for the clue, Jim.
So, now I'll
On Wed, 24 Aug 2005, Ken Moffat wrote:
On Tue, 23 Aug 2005, Jim Gifford wrote:
No problems Ken. But what do you think of my reasoning on the error about
the different symlink names for ld?
At the moment, that sounds plausible (I've just posted about the perl script
bailing out). I used
On Wed, 24 Aug 2005, Randy McMurchy wrote:
[cc'd to BLFS-Dev from BLFS-Support]
Archaic wrote these words on 06/25/05 12:01 CST:
[snip what is already instructions in the book]
make -C browser/installer
cd dist
mv firefox /opt/firefox-${version}
ln -sf /opt/firefox-${version}
Test results from a pure64 build (gawk was still 3.1.4, although I
doubt that makes a difference here). This is just intended as an
initial marker, for binutils the book expects no errors - maybe we'll
change that if people confirm these results. This build was from an
LFS-6.1 pure64 host.
On Thu, 1 Sep 2005, Matthew Burgess wrote:
Or, to address both of those points, make it LFS-patches policy to simply
reject any patch that hasn't been submitted upstream! :)
Matt.
OK, so we can drop most of the lfs-specific patches for starters. And
what happens when we do send
A question for all of the people champing at the bit to get gcc4 into
the mainline book - does *anybody* see glibc passing the maths tests
(float, double, ifloat, idouble) in chapter 6 ? If they pass for you,
what CPU ?
I've got a reasonably new AMD processor (San Diego athlon64, slumming
On Sat, 3 Sep 2005, David Ciecierski wrote:
It most certainly does have to be selected.
Yeah, my sys runs like a charm with it :-) Just a small question: with grsec
every mount and unmount produces a few lines of text saying who is
{,u}mounting something. Can that be turned off? I mean,
On Sun, 4 Sep 2005, Greg Schafer wrote:
There is a patch available to fix most of the failures, but not all:
http://sources.redhat.com/ml/libc-hacker/2005-03/msg00067.html
http://sources.redhat.com/ml/glibc-cvs/2005-q2/msg00239.html
There is also available a dubious workaround:
So everybody on i686 can expect *some* failures in the glibc math tests
with gcc-4. I've got the patch from Drepper's (whoops, from _Mr_
Drepper's) commit (thanks, Greg) which solves half of the failures.
Looking at fedora4, even with their ability to selectively pick fixes
from CVS they use
On Mon, 5 Sep 2005, Randy McMurchy wrote:
Randy McMurchy wrote these words on 09/05/05 11:10 CST:
Good work, Ken. FWIW, I think that the SBU and disk space should
include building all locales. Here are my figures.
[EMAIL PROTECTED]: ~/build/Build-System/Installed-System/glibc-2.3.5 cat
On Tue, 6 Sep 2005, Alexander E. Patrakov wrote:
Ken Moffat wrote:
Thanks, I'm only really concerned about chapter 6 at the moment. I seem
to remember somebody (Alexander, perhaps) suggesting that the correct
method is to install the required locales, which for me equates to the
minimal
On Thu, 8 Sep 2005, Olivier Seubert wrote:
Yeah, you asked this on -support yesterday, and I replied that the
config.log you need to look at is in the libstdc++-v3 directory. If you
didn't seem my response, it should be in the archives. Please take this
back to lfs-support.
Ken
--
das
On Thu, 8 Sep 2005, Jeremy Huntwork wrote:
Jim Gifford wrote:
Interesting!! So either GCC is not compiling Glibc with NPTL correctly, or
we have a GCC 4.0.1 issue.
Matt Darcy is trying the Currently GLIBC snapshot.
If the snapshot works well, we should seriously consider using that in
On Wed, 7 Sep 2005, Randy McMurchy wrote:
Here's a current list of packages known to compile using GCC-4. The
list is updated as I go (automated). Build scripts for any of the
packages you see on this list are available upon request.
On Tue, 13 Sep 2005, Matthew Burgess wrote:
Like I said in the original RFC, udev *will* still create nodes for *all*
device it finds, regardless of the existence or otherwise of a rule in its
configuration files. It just means that where a rule doesn't exist for the
device, it will be
On Thu, 15 Sep 2005, Jim Gifford wrote:
Jeremy Huntwork wrote:
That seems to be the natural course to follow. I would like to see some of
the goals/guiding principles of Cross-LFS layed out, too though. For
example, how closely does it follow LFS and decisions made there, like
package
On Thu, 15 Sep 2005, M.Canales.es wrote:
If that will meant that Cross-LFS will be focused on pure cross-build
techniques and scenarios, i.e. it assumes that host-triplet !=
target-triplet, thus no chroot way to build the final system, focusing the
normal LFS book on host-triplet =
On Tue, 20 Sep 2005, Jeremy Huntwork wrote:
Thanks again - I've enjoyed it immensely.
Thanks for all you've done, maybe we'll see you back one day.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Two questions:
(i) Is there still a public rendering of this book ? I went to the
website to check if I'd borked something in my editing but couldn't find
any mention of Cross-LFS. Perhaps it's part of the restructuring. (/me
suppresses a thought that editors on non-projects have a
On Fri, 30 Sep 2005, Jim Gifford wrote:
We are currently trying to stablize the Cross-LFS book.
Any thoughts on a package freeze for existing packages, particularly
glibc ? (That is, freeze versions unless it becomes clear that a
different version will solve problems). I'm preparing to
On Sat, 1 Oct 2005, Jim Gifford wrote:
Manuel and LFS-dev,
I have been thinking about this for a few days. Cross-LFS has two
different options in it, boot and chroot. Boot is a complete reboot and
chroot is like the standard LFS book. Talking with various people, an idea
popped into my
On Sun, 2 Oct 2005, M.Canales.es wrote:
If you are rendering/validating all book each time that you made a little
change in the sources, yes, the process is very long.
But if the change you made only affect some archs, you can validate/render
only that books (for example, mips ands mips64)
On Sun, 2 Oct 2005, Andrew Benton wrote:
Ken Moffat wrote:
Well, the snapshot in cross-lfs is surprisingly good, but in general
trying to follow glibc CVS is a full-time job for anybody who cares about
more than just x86. I haven't built x86 on cross-lfs yet, but if the
c++-types-check
On Mon, 3 Oct 2005, Jeremy Huntwork wrote:
Hello All,
Hi Jeremy,
I was pleased to see you back. I'm disappointed that not everyone
viewed your useful contributions in the same way.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
On Mon, 3 Oct 2005, Andrew Benton wrote:
Ken Moffat wrote:
Were you using glibc-20050926, or glibc-2.3-20050926 ? Oh, and did you
definitely include the bash avoid_WCONTINUED patch ?
I started with glibc-20050912 and I've been updating it with cvs every Sunday
(I know how to have fun
I've been trying to understand why the findutils testsuites were
failing in Cross-LFS. The first problem (the xargs suite) could be
fixed by adding a /bin/echo symlink (we were using /tools/bin/echo when
the test ran, and the xargs tests were rewritten for 4.2.25 - if no
action is specified
On Sat, 8 Oct 2005, Jeremy Huntwork wrote:
I hadn't meant cut a branch from trunk and call it 'stable' - that would
require a lot more testing. I meant take the current 'stable' book and do
whatever minimally needs to be done to fix each bug and re-release. It really
would be a 6.1.1 in
directories are empty, e.g. in a chroot.
Ken
Submitted By:
Date: 2005-10-14
Initial Package Version: 3.3.4
Upstream Status: From glibc-cvs
Origin: http://sources.redhat.com/ml/libc-hacker/2005-02/msg5.html
Applied by hand and rediffed by Ken Moffat.
Description: Avoid segfault
On Fri, 14 Oct 2005, Jeremy Huntwork wrote:
This one applied fine with an offset, built correctly and is running
smoothly. Openssh-4.2p1 also built on the same system and running well.
In that case, I'd rather go with yours (I think there is a possibility
that my rejection was caused by
On Mon, 17 Oct 2005, jaca wrote:
Hello
I've obtained the following errorc while compiling Kbd-1.12
gcc -c -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -DDATADIR=\/usr/share
/kbd\ kbdrate.c
kbdrate.c: In function 'KIOCSRATE_ioctl_ok':
kbdrate.c:167: error: 'struct kbd_rate' has no
On Wed, 19 Oct 2005, Ken Moffat wrote:
For the temporary tools, I'm guessing we could just build a 32-bit perl
(assuming any 64-bit testsuites will NOT produce perl modules).
Progress update:
Using the 20051017 glibc snapshot and ONLY a 32-bit perl in test-tools,
the 64-bit glibc
On Thu, 20 Oct 2005, Ryan Oliver wrote:
example patch for x86_64 lib64 attached (rename it to something
appropriate)
Thanks, I'll play with one of those later.
Just thought I'd pipe up here... what use is there having both 32 and
64bit modules created if you are only going to be able
pOn Thu, 20 Oct 2005, Doug Ronne wrote:
But now the cvs emacs requires texinfo, which I
had been leaving off my temporary tools. So I guess I have to install
texinfo to install emacs to install gettext but texinfo requires
gettext! wee!!!
Don't you lose the info pages from gcc if you
On Mon, 24 Oct 2005, Duncan Webb wrote:
Hi all,
Just build the boot stages of Version 7.0-cross-lfs-20051023-x86_64 from a
LFS 6.1 (32-bit) system. I've noticed a few small errors that I would like to
report.
5.4. Build Variables
Following the commands will set LFS_TARGET to
On Mon, 24 Oct 2005, Duncan Webb wrote:
wouldn't it be better to say:
echo am_cv_func_working_getline=yes config.cache
because if the configure has already been run then the cache file should
be truncated.
I've assumed that _some_ architectures already write to config.cache in
these
On Tue, 25 Oct 2005, Duncan Webb wrote:
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have
On Tue, 25 Oct 2005, Duncan Webb wrote:
I know this is off topic, so don't shout at me...
I was trying to build strace-4.5.12 under x86_64 but it has compilation
problems. Attached is a patch, taken from gentoo that fixes there.
Regards,
Duncan
Blimey, it's a bit big, isn't it ;) I've
On Wed, 26 Oct 2005, Duncan Webb wrote:
Ken Moffat wrote:
My rule of thumb for Beyond-Cross-LFS, at the moment, is to mention issues
on blfs-support.
Are you thinking of a dedicated Cross-LFS mailing list?
Not my call. But we are talking about strace which is a BLFS package
On Thu, 27 Oct 2005, Alexander E. Patrakov wrote:
Jim Gifford wrote:
Translated for Cross-LFS would be.
-Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \
-Dprivlib=/usr/lib/perl5/5.8.7 \
-Dsitelib=/usr/lib/perl5/site_perl/5.8.7 \
-Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.7 \
(Adding Jim back to the CC)
On Thu, 27 Oct 2005, Ken Moffat wrote:
Apart from that, this has two deficiencies in my view:
(i) our 64-bit perl installs in /usr/lib instead of /usr/lib64,
as do all subsequent modules (tested with XML-Parser, which finds libexpat
from /usr/lib64, but installs
On Thu, 27 Oct 2005, Thomas Pegg wrote:
On Thu, 2005-10-27 at 21:35 +0100, Ken Moffat wrote:
OK, using Ryan's patch from last week plus the installstyle echo, with
only a 64-bit perl, everything is in /usr/lib64/perl5 and XML-Parser
installs into /usr/lib64/perl5/site_perl. Looks good
On Fri, 28 Oct 2005, Duncan Webb wrote:
Question is:
1) should a symlink from /usr/lib to /usr/lib64 be created in the section
Creating Directories in chapters 7 8
I agree that xorg is a BLFS support issue and that deals with case 2.
Case 1 is a bit like /usr/man link to /usr/share/man,
On Thu, 3 Nov 2005, Duncan Webb wrote:
What I don't understand is why anybody would have a problem syncing the
hardware clock to the system clock at reboot/power off. After all the system
clock is synced to the hardware clock at boot.
In that case, please search the lfs archives and
On Sat, 12 Nov 2005, Matthew Burgess wrote:
Jeremy Huntwork wrote:
Anyway, the results of the farce run are in my homedir:
http://linuxfromscratch.org/~jhuntwork/farce-results
A question for Ken, then. What's the difference between:
2 files differed as expected
and
1 files differed as
On Sat, 12 Nov 2005, Jeremy Huntwork wrote:
Chris Staub wrote:
I just found a problem. I tried building arts and got this...
Here's another uncleanness:
e2fsprogs and libtool hardcode the path of sed into installed scripts.
/usr/bin/mk_cmds (from e2fsprogs) and /usr/bin/libtool both have
On Sun, 13 Nov 2005, Ken Moffat wrote:
Heh, I was just about to revisit your earlier posting and ask about libtool.
The difference in bison might be worrying, or it might be nothing (maybe even
another candidate for differs as they usually do) - anything interesting in
farce-extras
On Sun, 13 Nov 2005, Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Richard A Downing wrote:
Is LILO still maintained? Your comments here worry me a lot about the
competence of the team writing grub2.
Looks like it is - http://home.san.rr.com/johninsd/pub/linux/lilo. The
only
On Sun, 20 Nov 2005, Matthew Burgess wrote:
DJ Lucas wrote:
Sorry it's so last minute with release scheduled in 6 days, but I'd suggest
testing this patch for inclusion in 6.1.1. I have tested and verified only
on 2.3.5.
I don't have time to test this myself, so I'm going to have to ask
On Sun, 20 Nov 2005, Archaic wrote:
On Sun, Nov 20, 2005 at 09:56:28PM +, Ken Moffat wrote:
Personally, I've not seen any problems with xmms (1.2.10) or xine that
sound like this bug, even on my 6.1 systems.
It is a glibc bug, not nvidia, xmms, xine, or OOo. Read the debian bug
report
On Tue, 22 Nov 2005, Matthew Burgess wrote:
Jeremy Huntwork wrote:
1) Are those specific headers for that version necessary? Wouldn't the
current ones work?
Well, they work for me (I've been running 2.6.14 for a while now). However,
I'd imagine that if the kernel gets a new feature (e.g.
I'm running into problems with the src/su dummy -c make
RUN_EXPENSIVE_TESTS=yes check tests on a new architecture - it's
telling me that user dummy doesn't exist with both 5.92 and 5.93, but
5.2.1 passes without errors.
Looking at my notes and scripts, this is the first time I've tried
On Tue, 22 Nov 2005, Matthew Burgess wrote:
Yep, I ran into the same issue. Testing suggested that the /etc/passwd entry
for users you want to `su' to need a home dir. I therefore changed the
creation of the dummy user to:
echo dummy:x:1000:1000::/root:/bin/bash /etc/passwd
Have you
On Tue, 22 Nov 2005, Jeremy Huntwork wrote:
This is a bit off-topic, but this discussion has triggered another thought.
With CLFS at some point (whether you decide to chroot or boot) you're going
to be building the remainder of the book natively. At that point does CLFS
really need to
On Tue, 29 Nov 2005, Randy McMurchy wrote:
Though I've never seen a situation where I 'ran into a problem during
make install', I suppose it could happen.
Just wait till you move to a multilib machine ;)
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
Submitted By: Ken Moffat ken at linuxfromscratch.org
Date: 2005-12-03
Initial Package Version: 1.0.3
Upstream Status: not submitted
Origin: self
Description: Copied from the non-shared Makefile so that the shared version
can be tested
On Sat, 3 Dec 2005, go moko wrote:
After your remarks, I've done another test on my new
64 bits system. This time, I've quite exactly the same
time for compressing and decompressing a 600Mo archive
(OOo, for the example) with the shared and the
partially-static version, with options -9
On Thu, 15 Dec 2005, Jeremy Huntwork wrote:
Ken's Farce is probably good enough for our needs. However I did take a
brief look at Greg's scripts and he does a couple of other interesting
things, such as de-compressing all .gz files and un-archiving all .a
files before running the comparison.
On Fri, 16 Dec 2005, Ken Moffat wrote:
On Thu, 15 Dec 2005, Jeremy Huntwork wrote:
Ken's Farce is probably good enough for our needs. However I did take a
brief look at Greg's scripts and he does a couple of other interesting
things, such as de-compressing all .gz files and un-archiving all
On Thu, 15 Dec 2005, Dan Nicholson wrote:
It sounds like Ken's scripts do a great job of doing the comparison.
What I like about Greg's scripts is deciding what's being compared.
1. The build automatically loops to the beginning, skipping the first
few stages: create symlinks, create
On Thu, 15 Dec 2005, Dan Nicholson wrote:
That's my prime objection to Greg's method - we always tell people
fbbg, but the comparison takes a shortcut.
Right, but for the purposes of testing, the environment should be as
consistent as possible. That's standard procedure for running a test
On Thu, 15 Dec 2005, Ken Moffat wrote:
I seem to recall that in repeated standard LFS i686 builds, these same
binaries can in fact differ, without anybody ever quite knowing why - this is
why Greg's ICA, at least last time I looked, did -three- builds to compare
which bytes always differed
On Fri, 16 Dec 2005, Dan Nicholson wrote:
On 12/16/05, Ken Moffat [EMAIL PROTECTED] wrote:
snip everything
Ken, I seemed to have offended you and I'm sorry that happened. I
really don't mean to bad mouth the way you've tested or the tool
you've created to assist. I was only arguing
On Fri, 16 Dec 2005, Dan Nicholson wrote:
On 12/16/05, Ken Moffat [EMAIL PROTECTED] wrote:
Just seemed that you were taking offense to my suggestions or you
assumed I was taking shots at your tool. If not, then that's good
because I didn't mean either.
Great
As pertains to the testing, I
On Sun, 18 Dec 2005, Jeremy Huntwork wrote:
There are 4 lines that, to me, stand out:
unexpected FAIL: /usr/bin/libtool is different
unexpected FAIL: /usr/bin/vim differs after stripping and processing
unexpected FAIL:
/usr/include/c++/4.0.2/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch is
On Fri, 23 Dec 2005, Greg Schafer wrote:
On Wed, 21 Dec 2005 11:34:22 -0800, Jim Gifford wrote:
I posted a solution in lfs-support. Here is it
In my testing with Cross-LFS, I have found that this works
echo dummy1:x:1000: /etc/group
echo dummy:x:1000:1000:::/bin/bash /etc/passwd
cd tests
On Fri, 23 Dec 2005, Dan Nicholson wrote:
I haven't done any research yet, but I'm attaching the ICA report for
1v2. With the exception of farce-extras (too big to move around), you
can see the results in http://students.washington.edu/dbnichol/lfs/ .
I'm going out of town in the morning, so
1 - 100 of 715 matches
Mail list logo
