, but hopefully you'll agree
that this is better than having lost posts that show up on the
newslists, but are not reflected in the mailman archives or to
email-only subscribers.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq
. It would nicely bring it all up-to-date
and fix a few bugs, notably, the strip bug and the 2.6.8.1 cd-writing bug.
I'd like to see a release happen now.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
, (the new release was
mostly just to get sysklogd back in) and as Matt just posted as well,
likely a testing phase before release would go through. I think that
should prove enough time to test the latest version of the scripts.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo
for reference. ;)
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ready to change if it's deemed
that gnu.org is the better link.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Ken Moffat wrote:
Confirmed that 1.36 ran check ok, diffed it and realised this is a new
test. Google found one thread for e2fsprogs tst_ostype - the fix is at
http://www.diy-linux.org/pipermail/diy-linux-dev/2005-March/000490.html
Thanks, Greg. Did I miss the LFS editorial decision not to
Puvi wrote:
configure: error: forced unwind support is required
See this thread:
http://archives.linuxfromscratch.org/mail-archives/lfs-hackers/2004-July/001835.html
The problem seems to lie in the way your host system is set up, though
after reading through that thread, I'm not sure if the exact
Andrew Benton wrote:
Sorry if this has been covered already, but I'm just looking at the page
7.4. Device and Module Handling on an LFS System in Linux From Scratch -
Version 6.1-testing-20050401 Chapter 7. Setting Up System Bootscripts
It has a section 7.4.3. Handling Hotpluggable/Dynamic
Allard Welter wrote:
At the end of the udev install it mutters:
killall udevd
udevd: no process killed
make: [install] Error 1 (ignored)
Obviously this is harmless, but perhaps somewhat disconcerting to
someone doing this the first time?
Perhaps. And noted. Thanks.
--
Jeremy H.
--
Bruce Dubbs wrote:
As an interesting note, from vim, do a :help Linux-backspace
That is exactly what I am running into.
Do you have a /etc/sysconfig/console file? Or did you leave it alone?
Guess I'm wondering if you have a keymap that needs fixing as is
mentioned here:
there. Sound ok? Any ideas or suggestions as far as that goes?
Thanks,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Jeremy Huntwork wrote:
In
fact, unless there is any technical benefit to rebooting into a fresh
kernel before chapter 6 on matching arch pairs, I think I'd rather see
the book continue to chroot by default and assume that the user is
building for the same arch, which would remove some
O Mon, Apr 18, 2005 at 10:52:37PM -0500, Randy McMurchy wrote:
Jeremy, this is a discussion. I was dismissed because I build
x86 biddy builds (whatever that is). You are not a moderator,
Jeremy, enter the discussion with something to contribute or let
us continue it without your interference.
to suggestions.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Norman J Heckscher wrote:
steve crosby wrote:
The question is, with the new multi-choice cross-lfs book being worked
on, how are we planning on producing a hardcopy version? Questions
regarding the linear flow of the book are resolved by using smart
XML processing, but I've yet to see that
haven't done any other cross-compiling on
this machine save for what the cross-lfs book does.
I'm not sure that this is a major concern - however I too would prefer
to see that it *always* find the libgcc_s.so in /cross-tools
I'll add your sed into the next revision, thanks.
--
Jeremy Huntwork
wanted to put this forward for comments. Personally, it would make
me feel much more comfortable with where we're leading the reader.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
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, suggestions, etc.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe
thread I just started, Successful Build of Cross-LFS
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
to the auto-render scripts alongside the
other LFS books. Test the builds, submit errors, suggestions, etc.
Thanks!
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
information in the book
to help you with x86_64, but that's just about next on our list of
things to implement. Thus, we'll need the help of testers and people
who have already successfully built on x86_64.
HTH,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http
,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
M.Canales.es wrote:
El Viernes, 6 de Mayo de 2005 17:34, Jeremy Huntwork escribió:
Nothing impossible, I think, but very difficult to implement.
Ok. Thanks Manuel for responding on that. :) Perhaps it's best then, to
leave this idea to mature for a while and re-visit it once we have the
full
or comment on the above,
*please* reply here. We *need* your feedback in order to make a decision.
Thanks!
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Matthew Burgess wrote:
Jeremy Huntwork wrote:
So, in a nutshell, my opinion is that we should do multilib as a
default for 64-bit archs with /lib and /lib64 directories.
Care to explain the basis on which you're forming that opinion for those
of us paupers not able to afford such exotic
M.Canales.es wrote:
Is there some de facto standard used by commercial distros?
Not sure. I just grabbed a gentoo stage3 tarball for amd64 and it seems
they have it layed out like this:
/lib - /lib64
/lib32
/lib64
/usr/lib - lib64
/usr/lib32
/usr/lib64
--
Jeremy Huntwork
--
http
where necessary, this ppc book is
fairly new.
I'll look over your comments and make the changes as I have a free minute.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
...
Though if we have a multilib book and a uni-arch book, we can cater for
both straight64 and multilib...
Let me get at least the first way down and in book form and we'll see
what happens after that. ;) Can't really comment on your XML ideas
because I'm not very versed there either.
--
Jeremy
Public License as published by the Free Software
# Foundation; either version 2 of the License, or (at your option) any later
# version.
# --- T2-COPYRIGHT-NOTE-END ---
Thanks,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq
). The other
is the set of commands to run if one of those args is passed.
These expressions receive an $enableval variable. If --disable-X is
passed, then $enableval is equal to no. If --enable-X=blah is passed,
then $enableval is equal to blah.
Nice. Thanks for the explanation, Bryan. :)
--
Jeremy
Hey all,
I've just put up a new livecd iso. This is version x86-6.1-1-pre3. There
are still a few known missing items that we will put in the next iso,
and hopefully that one will be a release candidate. However, there are
some substantially new features with this cd, so we wanted to give
Jeremy Huntwork wrote:
ftp://ftp.lfs-matrix.net/pub/lfs-livecd/lfslivecd-x86-6.1-1.pre3.iso
Grr.
A small typo in that url above:
Should be:
ftp://ftp.lfs-matrix.net/pub/lfs-livecd/lfslivecd-x86-6.1-1-pre3.iso
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http
Matthew Burgess wrote:
Jim/Jeremy, could you audit all occurences of 'sed' prior to chapter
6.17 (sed-4.1.4 installation) and remove the '-i' flag please? Either
that or we need to have modern 'sed' built really early on.
I'll keep that in mind and work it in as I make other edits, if
.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Jeremy Huntwork wrote:
Actually, we do have it correct, (look at the sparc64 book), but
apparently the x86 book was mangled a little bit with our recent
re-structuring. Thanks for bringing this to my attention, I'll fix it in
just a minute.
There. Take a look:
http://linuxfromscratch.org
John Profic wrote:
I'm continue trying to build lfs by intructions from cross-lfs on x86_64.
Currently I finish temp-tools part, and have some notices:
1) Gcc, compiled by instructions from cross-lfs-x86 uses /lib64 even
build with enable-multilib=no, so no one just compiled program cannot
run
as many BLFS packages as possible too. Perhaps give that new BLFS
profile for nALFS a test all at once. :)
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
John Profic wrote:
Sorry, for confusion, but I mean book titled i386/x64_64 not standalone
x86_64 (which I notice is *broken* :))
You mean this one?
http://linuxfromscratch.org/~jhuntwork/cross-lfs/x86/
If so, the title for that one is 'Intel/AMD x86' and it's assumed that
you're building
Bruce Dubbs wrote:
There are more developers for LFS than for BLFS, but the package count
is about 6 to 1 in favor of BLFS.
Actually, I don't think there are more for LFS atm. But your point is
still valid.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Archaic wrote:
In an attempt to get this info both archived, and presented to the
larger community, I am writing up a synopsis of ideas that have been
floating around on IRC as to how to handle the chroot/reboot phase of
the cross-lfs book. I will list them and give a brief pro/con for each
as I
Jim Gifford wrote:
Matt, that was one of the purposes of the cross-lfs was the
multi-architecture build, the reboot section is needed. I have it
working and have been making the changes. It's just at the reboot point
where there seems to be an issue.
I think that's what he was saying - Keep
TheOldFellow wrote:
I must start by saying that I have not been interested enough in this
thread to have read every contribution in detail.
Having built a couple of POX86S (plain old X86 system) with cross-lfs
instructions, I've decided to take a copy of the latest svn
non-cross-lfs book and
R.Quenett wrote:
Pardon me for butting in here but, to me in my ignorance, the one
benefit that would justify (again, to me - I'm not trying to speak
for anyone else) almost anything would be the 'purity of the build'
(which I understand to mean the new build containing as close to zero
as
Randy McMurchy wrote:
I asked a very similar question a while back. After pressing the
issue, the answer was that for x86 builds, you end up with the
same thing regardless which build method you use. Note, however,
this only applies to non-cross builds.
I'm sorry, I must have missed this one.
TheOldFellow wrote:
We often (once a year or so) have a debate in LFS circles to decide if
those who want to try experimental stuff should be in the forefront, or
whether we should be trying to get a perfect book for newbies to build
with. The answer is a compromise, always was, always will be.
Bryan Kadzban wrote:
If you use a host with new binutils (2.15.x), but are building old
binutils (2.14 was what was current when this issue came up), then after
you install the old binutils, linking won't work anymore. gcc's specs
file uses --as-needed, because 2.15.x supported it, but the ld
Matthew Burgess wrote:
Was the SE-Linux afflicted FC3 distro also because of host infection, or
was that down to incorrect instructions? Basically what was happening
was that (I think) glibc was being built in chapter 5 against the host's
se-linux stuff. When we were chrooted in chapter 6,
Hugo Bernier wrote:
On that note, the most valuable tool to build a LFS system is a good
LFS live cd. I do have some suggestions to put forward but I'm unsure
if this is the right place to put them.
There is in fact a LFS livecd project, and it has its own mailing list:
Alexander E. Patrakov wrote:
a) drop 8139cp (in preference to 8139too), eepro100 (in preference to
e100), dmfe (in preference to tulip), xircom_tulip_cb (in preference to
xircom_cb, and it doesn't load anyway because of missing symbols). If
you disagree because this breaks your network
Hey Everyone,
I was just reviewing some of the pages on the current website, and
sadly, much of it is outdated. I came across this page, which I don't
recall ever reading before, and I got a bit of a chuckle out of it:
http://www.linuxfromscratch.org/organization.html
This (and what
Jim Gifford wrote:
Matt, Jeremy, and LFS-Dev,
What are you feelings on cross-lfs moving to GCC 4.x?
Or do you want to continue the testing with 3.4.4, then after that's
completly stablized, then move to
GCC 4.x?
I've looked at what Ryan has done, not to many things to change.
TheOldFellow wrote:
I think the problem is that we have not RELEASED anything. We are too
cautious - release and be damned! (or at least be flooded with support
issues). I think that if Gerard were still alive there might be some
more movement on that, but it's hard to do it by concensus - it
Mike Hernandez wrote:
Not sure this is lfs-dev material, but irc.linuxfromscratch.org seems
to be down...
Just thought I'd mention it... ok I'm lying, actually I'm addicted to
irc and I'm going through withdrawal. ;)
Actually, it's just the lfs-matrix.de server, which is now in the
process
Archaic wrote:
On Thu, Jun 16, 2005 at 01:35:35PM -0400, Jeremy Huntwork wrote:
But not sure if the community wants this, or would start using a wiki again.
Start? It never really started. A couple of people wrote stuff. That's
all.
Maybe you never really looked at the wiki
Archaic wrote:
On Thu, Jun 16, 2005 at 11:19:14PM +0200, M.Canales.es wrote:
In that case, that is the most common one, to create cross-tools is acceptable
a maybe needed for purity and isolation from the host system. But to have to
cross-compile the full final system look excessive.
I
Jeremy Huntwork wrote:
Is there something major that's wrong with this suggestion that I'm not
seeing at the moment? Anyone else think of advantages or disadvantages?
Opinions?
Thanks for all the comments on this. They were actually very helpful.
They clarified a few things for me
Forwarding to lfs-dev for consideration.
--
JH
From Don Porter in the lfs-dev list:
Hello,
I'm one of the maintainers of the Tcl programming language.
Lately we're seeing a small but increasing number of bug reports submitted
against Tcl coming from people attempting to follow the Linux
Jeremy Huntwork wrote:
Forwarding to lfs-dev for consideration.
Sorry for the noise on this one - I was told I posted something that
already had been.
However, I'm still of the opinion that our install instructions should
be slightly altered for tcl and expect so that we can make use
Archaic wrote:
I would have agreed with you before glibc required tmpfs to pass it's
checks and shared memory became common. Are you aware of any popular
distro that *doesn't* include tmpfs in the default configuration?
The reason is that the bootscripts use tmpfs, so when explaining the
manual
Randy McMurchy wrote:
I realize there is an effort to migrate the web site to a new setup.
But, I also notice that the only person who does any real work on the
web site is also the project lead for the nALFS team, an active LFS
editor, and the project lead for the LIVECD project.
Sorry, being
Randy McMurchy wrote:
My initial post was an offer to help get something current on the
*web site that we currently have*. Apparently, there is no interest
there, so please disregard the noise.
Did you see my other message in this thread? I told you what you could
do to help *now*. I can't
Jim Gifford wrote:
I just confirmed something that we need to probably put a note into the
book.
If a glibc in chapter 5 is built without support for libidn, and you
attempt to build it in chapter 6 with libibn you will get the symlink
failure in the chapter 6 glibc. This has been mentioned
Kev Buckley wrote:
I am sure I am not the only one who keeps track of developments by
reading the Changelog, so imagine my surprise when I refreshed my
link to the index page for the development book and found it gone !
Will it be back ?
There were a few broken tags in the book's XML
Gerard Beekmans wrote:
On July 1, 2005 03:42 pm, Jason Gurtz wrote:
Maybe it would be worthwhile to see what a call for donations can scratch
up so there can be a dedicated server?
I'd like to cut down the recurring monthly colocations fees.
I've come across at least one deal where you can
Bernard Leak wrote:
Dear List,
H'mmm - I tried searching for a prior posting on this subject and got
Index file error: Index file 'lfs-dev.swish' and property file
'lfs-dev.swish.prop' are not related.
Thanks for the report on this. We were having trouble with our search
engine earlier.
Kim McCall wrote:
The offending line of tc-i386.h reads:
extern const struct relax_type md_relax_table[];
Is there a problem with trying to compile using the latest gcc,
distributed with FC4? (I guess I missed the memo).
Btw, yes, the current LFS book(s) will not work with gcc4. There needs
Gerard Beekmans wrote:
precious physical space. At least with the LFS server's current 4U rack. If I
can find a way to put the hardware in a 1U rackmount, there won't be an
issue. I can squeeze it in anywhere and have LFS dedicated again.
Ah, so then we need to put out a call for a decent 1U
this new
design implemented.
http://beta.linuxfromscratch.org/
Thank you,
--
Jeremy Huntwork
LFS Website Team
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
David Fix wrote:
Hey guys...
I'm running through SVN-20050705, and I notice that on 6.14 (GCC 3.4.4), it
says to run the tests (make check)... However, in chapter 5, it mentions
that you don't HAVE to run the tests in chapter 5, but gives details on the
test suite notes... In chapter 6, where
David Fix wrote:
You can find this same error in the testing book (TESTING-20050705), with
the following URL (for GCC-3.4.3, of course):
http://beta.linuxfromscratch.org/lfs/build-logs/testing/
This is a website issue - will be fixed later today.
Thanks
--
JH
--
LiveCD, visit
http://www.linuxfromscratch.org/livecd/download.html for a list of mirrors.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Justin R. Knierim wrote:
Ahh. This one was lfs-matrix.de before it switched servers around an
month or two ago. Can someone please exchange ip's please:
Instead of 80.237.204.39, now 213.202.245.135
Fixed.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Greetings Everyone:
The LFS LiveCD team has released an updated version of the 6.1 CD,
version x86-6.1-2. This version of the LiveCD fixes two important bugs:
* Missing patches: glibc-2.3.4-fix_test-1.patch,
mktemp-1.5-add_tempfile-2.patch
* Updated included HTML copy of the LFS book to
Matthew Burgess wrote:
Actually, thinking about this some more, the space was originally
introduced to stop people from breaking things if they happened to apply
the sed more than once. To that end, we could trivially change the new
sed to:
sed -i -e '[EMAIL
Greg Schafer wrote:
jim wrote:
Where is the development happening? I do not see it happening on the LFS
lists. Where is Ryan lately?
Right now there is no major discussions occuring with the cross-lfs
book, on or off of the lists.
The cross-lfs branch of the LFS book is in nearly
TheOldFellow wrote:
But the point is that without Jim's efforts there would not be a
Cross-LFS branch. To a large degree it's 'Jim's Branch'. (Ryan's
ideas, maybe some from Greg too, but Jim actually (mostly) did the branch.)
-snip-
So in my view: Use IRC for branch development UP TO the
Archaic wrote:
And there is nothing requiring an imminent release of cross-lfs, either.
The idea of getting gcc-4 into trunk post 6.2 sounds good. What really
sounds good after that is an i18n cleanup in 6.4 and a merge to
cross-lfs when it is done. That said, there is also no technical reason
Greg Schafer wrote:
Jim, the evidence is clear. Please, I urge you to do the ethical thing and
acknowledge you have used my research.
What evidence? Please note, in this email I am not countering the actual
claim that you have discovered first the issues that Jim fixed changed in
Cross-LFS.
Randy McMurchy wrote:
However, if there is a chance that the Cross-LFS stuff
can/will/should/might be/whatever the official LFS product, then
folks should be able to discuss things and recommend/suggest changes,
starting now.
I can see your point - public interest, ideas and discussion often
Greg Schafer wrote:
Just be careful when using them early in the build before you've installed
coreutils. You need to be wary of host issues. For example, `mkdir' on
RH62 doesn't support -v (but `install -d' does :-)
I recall that early in chapter 6 there was a change to 'install -d' over
Greg Schafer wrote:
Jeremy Huntwork wrote:
I recall that early in chapter 6 there was a change to 'install -d' over
'mkdir' for the Create Directories section
Yes, but the proposal is not about that.
I understand what the proposal was about. You mentioned the possibility
of some
Randy McMurchy wrote:
The biggest reason to use install -d instead of mkdir is that using
the install -d command allows you to also place a -m755 (or whatever
mode you wish) on the command. This creates directories with the
desired permissions, unlike mkdir which creates the directory using
Bruce Dubbs wrote:
Please help me in welcoming Richard Downing (aka TheOldFellow) as a new
BLFS Editor. Richard has been contributing to the lists since 2002 and
will be a valuable asset to the BLFS Team.
I was a little early on blfs-book I guess. ;)
Again, nice to see you with a bit more
Hi All,
I'd like to publicly welcome Thomas Pegg who has joined the LFS LiveCD
team. He specifically volunteered to help create a x86_64 LiveCD - I
think that there are many of you out there that would welcome such a CD.
For some time Thomas has been efficiently maintaining the nALFS profiles
Greg Schafer wrote:
GCC Makefile variable `XCFLAGS'. Something like the following sed (ONLY for
GCC Pass2 and Ch 6 GCC) achieves the desired effect for me:
sed -i '/^XCFLAGS/s/$/ -fomit-frame-pointer/' gcc/Makefile.in
Please forgive me if I'm missing something here, but I'm not quite sure
Jeremy Huntwork wrote:
Please forgive me if I'm missing something here, but I'm not quite sure
I'm seeing how this could work.
# grep -c XCFLAGS Makefile.in
0
Apologies on the above - of course this is down to my failing. My eyes
missed the gcc, so I ran grep on Makefile.in and not gcc
Randy McMurchy wrote:
Yes, that would be better. I wonder how much trouble it is to point
just the docs of /usr/share/vim/vim63 over to /usr/share/doc. There is
a whole bunch of stuff installed in /usr/share/vim/vim63 other than
the docs.
I started playing with this, and I got it to work,
Jeremy Huntwork wrote:
make HELPSUBLOC=/usr/share/doc/vim-6.3 -C src
make HELPSUBLOC=/usr/share/doc/vim-6.3 -C src install
The above could be replaced with a sed:
sed -i 's:$(VIMRTLOC)$(HELPSUBDIR):/usr/share/doc/vim-6.3:' src/Makefile
./configure ...
make
make install
That sed also
Randy McMurchy wrote:
Hi all,
Something I've thought about for a long time, and now that CrackLib
is a maintained and stable package, I would like to propose that the
community consider adding this package to Chapter 6 in the LFS build.
Here are some things to consider.
1) A system is not
Matthew Burgess wrote:
room to manouevre
Ack! Brit-speke!
/me runs screaming. ;)
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Randy McMurchy wrote:
This can be applied to many of the LFS packages. It is a meaningless
suggestion, as this is not the way it is done in LFS.
Perhaps salting a baboon would be a good idea.
Now that's a meaningless suggestion. Mine however, was not.
There are already precedents in the LFS
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
I have already stated it. There is no *technical* reason for including
it in a base development system.
That is not a reason to not include it.
/me blinks. about:kitchensink!
I'm sorry. What keeps users from
Randy McMurchy wrote:
Yet you give a -1 for the simple addition of a single little old
library (and its dictionary) to LFS. Please provide something concrete,
else I'll think you are just disagreeing for the fun of it. :-)
Randy, that's hardly fair. Several times in this thread people *have*
Randy McMurchy wrote:
I don't think so. And I can't imagine anyone else thinking so also,
unless they simply just want to disagree with the suggestion.
And therein lies the problem. Either unable or unwilling to allow for
different thinking.
--
JH
--
Matthew Burgess wrote:
Thoughts, comments, suggestions?
I like it. It's essentially all the questions we've been asking already,
but it's nice to have it listed as such. Does this mean we go back and
run all our current packages through the ringer now? :P
Which reminds me, we might want
Hi All,
I wanted to open this up to the entire community for further comments
(especially for those that may not watch the alfs-discuss list). A
question was brought up on alfs-discuss today that I thought deserves some
attention.
As far as I am aware, historically, ALFS as a project was
This is what the hard part is. Keeping those things pointed out
above in sync with LFS. nALFS has a team which does this already.
For every other automated build method, someone must ensure that
these things take place.
Right. One solution to that which I am interested in pursuing a bit more
On Tue, Aug 09, 2005 at 06:51:16PM +0100, Matthew Burgess wrote:
I'd then write handlers for each of those events that would result in
me having exactly the same Makefiles that I have now, but with the
massive benefit of being automatically generated/maintained. This
processing is inspired
Archaic wrote:
LILO is reported to work for 64 bit. You don't seem to be acknowledging
that since all I can see is talk of silo, colo, and grub.
Does LILO work for sparcs and/or MIPS machines?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Heya,
I've encountered a minor error when testing the latest LiveCD scripts and
I'm trying to track down if this is an error in LFS trunk or if it's a
problem with our scripts.
In the chapter 6 build of gcc there are two symlinks made after 'make
install':
ln -s ../usr/bin/cpp /lib
ln -s gcc
1 - 100 of 1158 matches
Mail list logo
