Hey All,
Just a quick note to say hello and respond to some recent concerns about
the inactivity of LFS projects.
For me, as I'm sure is the case for several others, several things in my
personal life have taken up nearly all my time lately. LFS gets pushed
into the background.
I think we'd a
Hey All,
Sorry for the absence. The lfs-JH branch is now back up to speed with
trunk, although the tickets that were opened for it are still valid and
that work needs to be done.
My home page on the server had also been broken for some time, it is now
fixed and the rendered branch can once aga
Alan Lord wrote:
> There is a virtually unlimited path for the direction/coverage of the
> LFS project as a whole, but it needs more promotion. It makes me sad to
> see how quiet these lists are right now.
I agree with your sentiments, but am low on ideas, or at least, on the
energy needed at p
Hello Everyone,
It has recently been suggested to me that the LFS LiveCD project be
killed. The main arguments for this are, essentially:
1) It is currently unmaintained
2) It removes the essential prerequisite of being able to configure a
Linux system
3) It leads to less testing from other hos
Bruce Dubbs wrote:
> I think we should just leave the project as quiescent, not kill it. A
> live CD is useful, but it doesn't have to be completely current. Just
> leave it alone for now and we can look into updating it when a change
> makes it necessary. For someone to use it, with a more curr
Alexander E. Patrakov wrote:
> It may be
> easier to start from scratch instead of "updating" this quirky CD.
If we were to go back and start from scratch for the next CD, I would
start with an _absolutely_ minimal CD and get rid of nearly all of the
BLFS packages) so that we could focus on gene
Alexander E. Patrakov wrote:
> Howard_apfc6 wrote:
>> - Seems like the ultimate build platform for newbs.
>
> That's exactly what I am against. LiveCD users create 90% of support
> requests.
> Noobs (not to be confused with newbs) should be filtered out, e.g., by
> telling
> them to install an
Alexander E. Patrakov wrote:
> Jeremy Huntwork wrote:
>
>> The LiveCD exists as standing proof that the LFS book is
>> sound and produces a working system.
>
> Here I disagree. Because of numerous deviations and wagons of extras, it
> proves
> nothing. Her
Jeremy Huntwork wrote:
> * Does the community still want the LiveCD project? (Consider that a
> couple of the arguments above imply that the LFS LiveCD by its nature is
> degrading the quality of LFS)
>
> * If so, is the community prepared to lend help in keeping it alive?
Th
Alexander E. Patrakov wrote:
> Please subtract the number that want to use the LiveCD to cover LFS bugs,
> don't
> realize the inherent incompatibility of LFS with 64-bit hosts (IMHO, the fact
> that LFS doesn't mention it counts as a bug), or don't know how to apt-get
> install build-essential
Alexander E. Patrakov wrote:
> So we see at least two non-empty camps. One wants a strictly minimal CD, and
> one
> wants packages beyond it. The most "democratic" solution would be to make two
> CDs (and that's, in fact, the origin of the talks about package management),
> but
> we don't have
TheOldFellow wrote:
> My feeling is that LFS-NG should use the new DIY-Linux build method, AND
> have a Package Management system, AND have a defined way of managing
> updates. THEN, I think ALFS and BLFS should use the chosen PM.
Well this certainly is taking the discussion to the next level. I'
Alan Lord wrote:
> Firstly, Gerard is definitely on the right track in his recent posts,
> and DJ also hit the nail on the head too with some of his concerns.
Based on the sorts of replies I've been seeing most of us are agreed
that LFS needs a change of direction. Something that will make it mo
Gerard Beekmans wrote:
> For LFS purposes we first need to determine how far we want to take
> package management. In its utmost basic form we can provide commands in
> the book to collect a list of installed files before and after the
> installation of a package. Compare the two lists with a pr
Gerard Beekmans wrote:
> Just some more food for thoughts. While we're discussing let's also take
> the time to think outside the box. Abandon, at least in theory, anything
> that is currently LFS, pre-conceived notions and otherwise, and see what
> happens when we re-invent LFS and the way we d
George Makrydakis wrote:
> In what way(s) could you do this that diy-linux and clfs do not do already?
> How is it going to compete with the other two? Or three.. Or four... Or
> Infinity?
I'm sorry for being dense, but I'm not sure I understand what you're
asking here.
> Combining from the ot
On Thu, Feb 28, 2008 at 11:59:01PM +0200, George Makrydakis wrote:
> On Thursday 28 February 2008 22:33:09 Ag. D. Hatzimanikas wrote:
>
> > c. I was involved in such discussions in the past and I had high hopes
> >that things would change. They didn't. What left to me is that usually
> >no
Hello All,
Please bear with me... this is a long post, although I tried to keep it
simple and easy to read.
Gerard invited me to share some of my ideas with him privately about our
recent discussions on lfs-dev. What follows is mostly what I presented
to him, with a summary of his comments at
Alexander E. Patrakov wrote:
> And here is a problem: the chosen PM affects the whole system, i.e., its
> choice
> (unlike, say, the choice of an MTA) is not a local change. And, as you can
> see,
> RPMs and DEBs use very different buildscripts. E.g., RPM finds the shared
> library requirement
Alexander E. Patrakov wrote:
>> The option to bootstrap a temporary toolchain is just an example. But it
>> should give you an idea of how we might make LFS a bit modular.
>
> I agree, but maybe some other example modules would make the idea even more
> clear.
Well, another example may be i18n.
On Fri, Feb 29, 2008 at 04:20:25PM +0200, George Makrydakis wrote:
> I would have some heavy commenting to do on the origin of what you are
> proposing here but in anycase, time for this will come and you know it.
> People
> who know, know. Those who don't probably did not care enough. Discussio
On Fri, Feb 29, 2008 at 07:46:41AM -0800, Dan Nicholson wrote:
> On Fri, Feb 29, 2008 at 1:20 AM, Alan Lord <[EMAIL PROTECTED]> wrote:
> > ---
> > So perhaps the LFS project becomes some sort of "course" (and I use the
> > term loosely). The "modules" of which, could be something like:
> >
> >
On Fri, Feb 29, 2008 at 08:45:47PM +0200, George Makrydakis wrote:
> You have some issues, sir. You are doing the same thing to everybody else's
> project you cannot touch. You did the same when you ungraciously backported
> everything from cross-lfs and diy in order to have a 64bit build. To the
Hello,
This is an off topic message. I apologize for its presence here,
especially after Gerard's request to end it. However, I feel that since
some drama took place here, it should also be resolved here. Please skip
this post if you are uninvolved and uninterested.
Some years ago, when I was
TheOldFellow wrote:
> I'm sorry but I can't continue to take this mailing list. Despite
> request by Gerard to STFU, the noise continues. I had hoped that ther
> was some hope for a new project, one that I might enjoy being part of.
> But there is ONE character who's ego is larger than I can take
Randy McMurchy wrote:
> Don't speak about the project, because you're not correct in
> that assumption. What is best for you, well, only you can
> determine that. But think about what I (and others) have
> said. You're presence is good for the community.
I had no intention of replying to this thre
On Mon, Mar 03, 2008 at 01:58:51AM -0600, Randy McMurchy wrote:
> If you mean that, then you won't go. Plain and simple.
I suppose I was a little rash and hasty. I've also been told that I'm
too sensitive and need a thicker skin. :)
The number of requests for me to stay (both here and in private)
Alexander E. Patrakov wrote:
> Some people do want to use LFS in production. There are only two ways to deal
> with this situation: make LFS work perfectly, or drive them away from LFS,
> e.g.,
> by including somewhere in the preface some concrete missing features that
> make
> LFS unsuitable
On Mon, Mar 17, 2008 at 08:46:31AM +0500, Alexander E. Patrakov wrote:
> Did anyone investigate the boot loader options further? What should be done
> for
> LFS-7.0?
Based on what I've read, I vote for switching to LILO as the default.
This has the advantage of making things easier for bringing
Bryan Kadzban wrote:
> Since that's the problem, we could move in one of two directions to fix
> it: either stop using any filesystem driver in the bootloader (which
> means, at this point, "move to LILO"), or fix the ext2/3 driver in grub
> (with the patch).
I'm not sure if the community has deci
Randy McMurchy wrote:
> Upstream is notorious for changing the patch content but not changing
> the name. And we don't see changes. This can only be a bad thing.
> There is nothing gained by changing the patch and calling it an LFS
> patch. This can only be a losing situation (upstream changes it,
J. Greenlees wrote:
> I decided that I wanted to take a look at init-ng while doing my current
> test build with the latest svn version of the book.
> once the build is done I'll be able to decide if it is worth using and
> adding a hint for.
>
> But, in looking at it, and the dependencies, init-n
J. Greenlees wrote:
> With the direction for LFS discussions, isn't presenting the options in
> keeping with the general input for the direction, which was to make LFS
> more a guide to creating a distro if I remember correctly than just a
> guide to building a linux system?
Indeed. We just need t
As I'm going through the book, I realized I couldn't place why e2fsprogs
is built in chapter 5. The description about udev needing its headers
makes no sense to me...
Was this a mistake?
See:
http://wiki.linuxfromscratch.org/lfs/changeset/8457/trunk/BOOK/chapter05/chapter05.xml
And:
http://wi
On Thu, Apr 03, 2008 at 03:50:00PM +0200, Jens Stroebel wrote:
> Hello.
>
> While browsing the wget list generated for the LFS devel book, I noticed
> that
> http://www.linuxfromscratch.org/patches/lfs/development/db-2.8.1-fixes-1.patch
> is not present...
>
This is already fixed, b
Ivan Kabaivanov wrote:
> I was wondering if the devs are, perhaps, working behind the scenes on
> putting
> together some PM as per the long thread(s) from a few weeks ago. Is there
> still interest in and momentum behind this idea?
I think there is, but it's just actually a matter of stepping
Dennis Clarke wrote:
> Both attempts seem to be failing in similar way.
>
> Not sure what direction to take here.
>
> Any thoughts ?
Well the CFLAGS thing shouldn't be necessary on powerpc, so your second
approach was the better one. But then you hit this:
'mawk: scripts/gen-sorted.awk: line 1
Alexander E. Patrakov wrote:
> Jeremy Huntwork wrote:
>> As I'm going through the book, I realized I couldn't place why e2fsprogs
>> is built in chapter 5. The description about udev needing its headers
>> makes no sense to me...
>
> util-linux-ng ne
Dennis Clarke wrote:
> It may be reasonable to include a line or two for RISC (PPC/ARM etc) based
> people that may get different output from compiling that dummy.c code.
Sure, if you're willing to continue to provide the appropriate data. :)
Of course, a balance needs to be struck, too. More tha
Dennis Clarke wrote:
> I'll post any interesting progress reports as they occur.
Yes, please do. Many thanks for the feedback, Dennis.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Randy McMurchy wrote:
> So, bottom line for me is I don't see any errors other than the
> math/test-double error in a 32bit multilib build. Both the 64bit
> multilib and regular LFS (not JH branch) don't get any errors.
Not really the bottom line (yet). Dennis is working on a PowerPC arch.
Or, at
Ken Moffat wrote:
> My most recent ppc build (clfs, book dated 20080212) with
> glibc-2.7 had the following fail (1.4GHz G4):
>
> math/test-ldouble.out
> math/test-ildoubl.out
> crypt/sha512c-test.out
> elf/check-localplt.out
Woops, posted the other message before I saw this one. Thanks for the
Dennis Clarke wrote:
> If anyone has words of encouragement .. now would be a good time :-)
Yeah, what Randy said. :) Anyway, yours is the type of testing, interest
and feedback we need to keep this project alive and moving forward, so
keep it coming. I know it's a bear to try to sort out all th
Nathan Coulson wrote:
> I was attempting to compile http://www.acpica.org/downloads/, and flex
> reported a flex: fatal internal error, bad transition character
> detected in sympartition()
>
> I ran into this bugreport when diagnosing, which implied this was
> possible with flex 2.5.34, and that
Hey all,
Running through a build here (with a couple of package updates) and ran
across an error when running 'make test' for chapter 6 perl. Essentially
amounts to a 'No such file' error for asm/page.h.
Tracking it down, it appears that recent Linux headers no longer install
asm/page.h. (I don't
On Tue, Apr 22, 2008 at 12:02:14PM -0700, Dan Nicholson wrote:
> On Tue, Apr 22, 2008 at 11:47 AM, Jeremy Huntwork
> For page.h, we'll need to patch so that getpagesize() or sysconf(
> _SC_PAGESIZE) is used instead of PAGE_SIZE. That's the way it always
> should have been
On Tue, Apr 22, 2008 at 01:09:10PM -0600, Jeremy Huntwork wrote:
> I removed the line where it includes the header and Perl built
> successfully and all tests passed. This is also what Gentoo does:
> https://bugs.gentoo.org/show_bug.cgi?id=168312
>
> However, there's like
On Tue, Apr 22, 2008 at 12:21:49PM -0700, Dan Nicholson wrote:
> So, I suppose you could grep for some regex (PAGE_(SHIFT|SIZE|MASK))
> of those macros to be safe.
Nothing for the other patterns. So seems like a usable enough solution
for perl. Will have to see if this affects any other packages..
Hello,
Can anyone confirm if the comment after the 'make check' command in
chapter 6 grep is still valid? I'm currently doing a build on x86_64 and
my results were:
==
All 13 tests passed
(1 tests were not run)
==
--
JH
--
http://linuxfromscratch.org/mail
On Tue, Apr 22, 2008 at 03:47:30PM -0500, Randy McMurchy wrote:
> FWIW:
>
> Very recent SVN build. I can give package version details if necessary
Oh, good, thanks Randy. Just wanted to make sure that it wasn't an old
comment left behind. Am in the middle of tracking down previous
discussions on
On Wed, Apr 23, 2008 at 12:47:07AM +0200, Philipp Christian Loewner wrote:
> I built a 64 bit system without multilib, kernel 2.6.24.4,
> GCC 4.3.0, Glibc 2.7. I'll try building a similar system
> on a i586 notebook in a few days, and if I'm "lucky", the
> errors will happen again so I can post the
Hello,
So I finally got a free evening and the energy to sit down and get
conceptual. This is the result:
http://linuxfromscratch.org/~jhuntwork/php-test/
Before replying about all that you see is wrong with it ;) keep the
following in mind:
This is a rough draft! A proof-of-concept only, des
Alexander E. Patrakov wrote:
> Glibc is not the best example for discussion. I requested such sample page
> for
> bash, not for glibc, for a reason: bash needs a specific patch in the RPM
> case,
> and I don't see the way to force such PM-specific instructions in the current
> framework.
I ex
Alexander E. Patrakov wrote:
> Jeremy Huntwork wrote:
>
>> http://linuxfromscratch.org/~jhuntwork/php-test/
>
> IMHO, too much state is kept in the PHP session. This may lead to bugs if a
> reader first generates one book and then the other variant, differing in the
Dan Nicholson wrote:
> That's awesome! My only concern with the multiple paths is with
> duplicating changes. Like, you found a typo in one of the commands and
> you have to change it in 4 spots. But I'd take that tradeoff here for
> the gain in coolness. :)
Well, that's part of the 'coolness'. Th
Ken Moffat wrote:
> I'm guessing 4.3.1 will be out soon, and that it will be worth
> playing with.
I've done some testing with 4.3.0 as well. It's a little cranky. And
based on similar reports I also decided to hold off working on updating
-dev until a new release. Otherwise, I may have added i
Bruce Dubbs wrote:
> In any case, I don't see a reason that there won't be a LFS 6.4 or 7.0
> release
> sometime this summer.
At the current rate, if we do LFS 7.0 this summer it would have to be
sans package manager.
However, x86_64 support (and PowerPC, for that matter) is pretty much
ready
Bryan Kadzban wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Jeremy Huntwork wrote:
>> To be current, I'd also like to see the Udev blocker sorted out before
>> we release 7.0. See: http://wiki.linuxfromscratch.org/lfs/ticket/2057
>
> Since
Dennis Clarke wrote:
> Sorry to drop in. I just wanted you to know that I was still out here
> working on this little embedded PPC device and that I was getting to
> the boot loader issue .. eventually.
Don't apologize. :) Dropping in is welcome.
> Just FYI.
Thanks for the reminder, Dennis. I'll
Dennis Clarke wrote:
> you know .. I really like the atmosphere in the LFS project.
> Such a nice bunch of people.
Oh, we've had our moments. You don't even have to go very far back in
the archives to read some. :(
But I think, on the whole, we all prefer a nicer, friendlier atmosphere,
and we
On Mon, May 12, 2008 at 09:06:59AM -0500, Randy McMurchy wrote:
> Marc McLaughlin (LUSYN) wrote these words on 05/12/08 06:39 CST:
> > Also, is anyone interested in my build notes? I've noted the changes to
> > the 6.3 build to get a working x86-64 build.
>
> I also have the changes required to b
On Mon, May 12, 2008 at 09:37:24AM -0500, Randy McMurchy wrote:
> I agree totally that trying to introduce multilib into LFS would be
> very difficult for us right now. I wasn't trying to say we should. In
> fact, I probably shouldn't have commented to the thread at all. But I
> wasn't sure if the
Gerard Beekmans wrote:
> As everybody has their own ideas and wishes, you'll find the document is
> not comprehensive and complete by any means. That's where the
> discussions here come in, to make sure it *becomes* complete.
>
> Looking forward to reading you guys' comments.
I wanted to wait a
Gerard Beekmans wrote:
> For us to be able to use an online tool to write the book, that tool
> needs to support every kind of tag we'd use for book editing; including
> tags like , /, all the structures
> surrounding chapter setup, entities, section info tags, the sometimes
> tricky internal X
Bruce Dubbs wrote:
> It seems that your idea is for a look and feel change along with a dynamic
> change of the book depending on the type if PM chosen by the user.
No, not really, sorry if it came across that way. The page layout was a
product of some other work I had been doing in unrelated (n
Julio Meca Hansen wrote:
> But can you explain a bit more what kind of data editing are you thinking
> about? I'm not sure
> if letting people edit the contents would be a wise idea, unless you were
> thinking in the people involved
> in LFS (I was kinda thinking ala wikipedia, edit for all)
In
Joe Ciccone wrote:
> I'm just curious what the code looks like. It looks a LOT like a parser
> I wrote working on a project with Jeremy almost a year ago. Link below.
> Obviously the concept is the same. If it is the same base code, all I
> ask is for attribution of the original idea, No more.
>
>
Alexander E. Patrakov wrote:
> Yes, that's the point, and you describe the purpose of the _current_ XML in
> the
> book precisely.
>
> The problem with Jeremy's approach is that his XML is different and
> unsuitable
> for PDF generation, and the rest of the tasks can be done with a simpler
>
Jeremy Huntwork wrote:
> It continues to amaze me... I show a Proof Of Concept as _potential_ for
> a direction that LFS could take, it's purpose being illustrative and to
> show potential. And yet, each time, it is judged solely by what is seen
> as if it is supposed to be a
Bruce Dubbs wrote:
> What this means is that the process to update bootscripts is now to change
> the
> appropriate file in BOOK/bootscripts and update the entity in packages.ent
>
> To have the current date.
>
> Likewise, for udev-config, update the files in BOOK/udev-config and the entity
Matthew Burgess wrote:
> As those of you who have been following ticket #2205 have already seen, DJ &
> Randy
Congrats guys! I wouldn't say I've been monitoring LFS in the past few
months, but now and then I'd look around to see what's going on and it's
nice to see that there's still some bit o
Bruce Dubbs wrote:
> To me, I'd like to see two things. First, an update to the packages. This
> is
> relatively straight forward, but of course has a lot of detail.
I think DJ and Randy are handling that so far? I wouldn't mind lending
some fingertips and half a brain here but I've not yet c
Bruce Dubbs wrote:
> The new page would introduce the issues and provide information for a user to
> use to decide if they want a 32-bit system or a 64-bit system. Yes, I think
> that page is necessary.
Hmmm. Alright. That will require some thought and a bit of research, I
think. I suppose I c
DJ Lucas wrote:
> Probably after the next release, but I was driving down the road a few
> minutes ago, and I had a very simple idea on that. It involves a little
> scripting, added to the book for each supported PM. "supported PM" ==
> "A developer is interested in maintaining it" It would a
DJ Lucas wrote:
> From what I've seen of it, I guess there is no concept of
> {,/usr}/{,s}bin64 or /usr/include64 like there is for the lib dirs (or
> the alternate). I mean a total separation of the system, side by side
> would be ideal IMO. Unfortunately I am just not able to make any usefu
Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> Bruce, Randy, ya'll got anything to add?
>
> No, not really. On a LUG list I read we just had a long discussion about
> problems on guy had getting his wireless to work with ndis wrapper. He was
> using Ubuntu64 and never could get it to work. When h
Hello,
I know I'm jumping in a little bit late here, but I'm having trouble
spotting where this discussion took place and I'd appreciate a cluebat.
I'm just curious, what was the rationale behind building gmp and mpfr in
different manners within the same book? To be more specific, why let
GC
Randy McMurchy wrote:
> Hi all,
>
> Best I can tell the GMP package needs M4 to build successfully.
> This can be approached in one of two ways:
>
> 1. Build M4 before building GMP in Chapter 5 (in fact it may
> be needed to be built before GCC pass1 as GMP is built inside
> the GCC Pass1 instruc
Philipp Christian Loewner wrote:
> From what I understand about it, building GMP and MPFR as separate
> packages is the preferred method, but the bootstrap build will fail
> to locate these programs in the /tools directory in the first stage.
Hmmm. I read through that thread already, but I didn't
Randy McMurchy wrote:
> I believe most of the information he has was determined by
> seeing what was going on over at DIY. I know that they discussed
> it a bit over there. You may want to check the DIY archives.
Well, DIY lets GCC build them internally on all passes. When I posted, I
was already
Dan Nicholson wrote:
>> * Only GCC needs them.
>
> Just for the record, I know guile can use an external libgmp:
>
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820
>
> Google shows that clamav and openswan use it, too. I don't know if
> that's comp
DJ Lucas wrote:
> I do not have all the details in front of me, but somebody said that gcc
> failed if gmp was not on the host in pass1. Greg pointed us to a DIY
> thread that showed how to build with GCC. There was no _need_ to build
> inline beyond that point, because that fixed the problem
Randy McMurchy wrote:
> Hi all,
>
> Looking at the tickets in Trac, there are a couple that
> really aren't SVN issues, but instead point to the stable
> book in which case to resolve the issues, it takes an
> entry in the stable errata.
>
> Therefore, I think that someone with Trac rights should
Randy McMurchy wrote:
> Could someone with the proper privileges update Trac
> or the mailing lists or whatever it is so that when
> Robert (who I didn't even know had SVN commit privs)
> makes a commit, it will show up in the -book list.
Well, Robert isn't subscribed to lfs-book, so that seems to
Dan Nicholson wrote:
> $ getent services barf
> $ echo $?
> 2
You mean you don't have the barf service on your system? I thought that
was pretty standard... :)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above info
Randy McMurchy wrote:
> Hi all,
>
> Looking at the build order, I'm curious as to why the Chapter 6
> Sed installation is so far up in the build. It is built in
> Chapter 5, and there's only a binary program installed (other
> than docs and locales), so there should be no real need to build
> it o
Bruce Dubbs wrote:
> I'm a bit hazy on this and don't want to take to time to try to dig through
> the
> archives. However, I think Robert is right. At the time we just wanted to
> promote the tools that are used a lot. I don't think there are any technical
> issues that would prevent using
Bruce Dubbs wrote:
> http://wiki.linuxfromscratch.org/lfs/ticket/2156
For what it's worth, I do intend to do some work on the LiveCD project
again. Obviously, it would be wise to wait and actually see what happens
here before counting on what I say. I don't think I intend to maintain
the CD in
Bruce Dubbs wrote:
> LFS SVN-20081015
>
> I tried jhalfs and a manual build but glibc fails for me in exactly the same
> place:
>
> /mnt/lfs/sources/gcc-build/i686-pc-linux-gnu/libssp/../../../gcc-4.3.2/libssp/ssp.c:175:
>
> multiple definition of `__stack_chk_fail_local'
> /mnt/lfs/sources/gl
Bruce Dubbs wrote:
> Thanks Jeremy. At least it's reproducible. Have you built glibc without the
> switch in Chapter 6?
Not yet. I got hit with another issue after that, and then got busy
again with work. Since you're able to use jhalfs on your host (jhalfs
rejects most versions of everything
Robert Connolly wrote:
> When GCC 4.1 released libssp, Glibc copied all of libssp in to Glibc, for
> better performance. This happened in Glibc 2.4 or 2.5. If you're running a
> new Glibc, libssp can not be used because it will conflict with identical
> functions in Glibc.
Given this, is there
Greg Schafer wrote:
> Definitely triggered by the addition of `--disabled-shared' to GCC Pass 1.
> If you're going to use that switch then must also use `--disable-libssp'.
Aha...
But, wait, why only now? I wasn't seeing this issue with glibc 2.7 and
gcc-4.2.3. What is currently in the jh branch
Hello,
I know that we've talked about this before but given the events of the
past year or so, I'd like to revisit this briefly.
Alexander and I have been talking and we're trying to take a very
realistic approach to any efforts made to re-enliven the LiveCD project.
Without going into too man
Bruce Dubbs wrote:
> mknod -m 666 $LFS/dev/tty c 5 0
>
> If that is done in Chapter 6, then the user doesn't have to remember any
> additional lines other than the chroot line (which is difficult enough).
Keep in mind why you want this. If you are really going through the book
as a user, this e
Bruce Dubbs wrote:
> Yes. Is there something wrong with that?
Changing the book is the wrong approach. Especially, changing the
commands in the book is the wrong approach. There are changes in the
format of the underlying XML to accomodate scripting (and therefore
jhalfs) but I personally feel
Matthew Burgess wrote:
> On Thu, 16 Oct 2008 00:30:46 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>> I don't believe it's about simply minimalism, but it's about keeping to
>> the point. If it is really beneficial to many users in various
>>
Just FYI:
Seems that the headers_install (and therefore headers_check) command in
the kernel source is a now a Perl script. This appears to be new in 2.6.27.x
See here: http://lkml.org/lkml/2008/6/8/29
There is a problem, however. The script uses open() but with 3 arguments
instead of 2. From
Jeremy Huntwork wrote:
> There is a problem, however. The script uses open() but with 3 arguments
> instead of 2. From what I've found so far, this change in syntax was
> introduced in perl-5.8.0, so the installation of Linux Headers fails if
> the host's version o
Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>> There is a problem, however. The script uses open() but with 3
>> arguments instead of 2. From what I've found so far, this change in
>> syntax was introduced in perl-5.8.0, so the installation of Linux
>> Header
Randy McMurchy wrote:
> I realize this was just FYI, but since you casually mention
> adding a minimal Perl to /tools, I'd thought I'd mention that
> it really wouldn't do us any good.
I expected this response from someone at some point. :)
Yeah, I'm not suggesting we do this for LFS. In fact, I
801 - 900 of 1449 matches
Mail list logo
