Gerard Beekmans wrote:
Bruce Dubbs wrote:
I think you can compare better with this:
It seems all changes are what I would classify as non-crucial.
There is one thing I would like to bring up:
The placement of Vim. The reason Vim, and its dependencies, are built as
early as possible is to pr
Matthew Burgess wrote:
If you feel the explanation given in the final paragraph of
http://www.linuxfromscratch.org/lfs/view/development/chapter06/chapter06.html#ch-system-introduction
is insufficient, feel free to raise a bug/submit a patch :-)
I didn't realize the book actually linked to th
Randy McMurchy wrote:
I do feel that LFS should *expose* readers to the *concept* of
package management and suggest implementation of some form or
another, after considering what is available and figuring out
what would be best for him/her.
If you feel the explanation given in the final paragr
Jeremy Huntwork wrote these words on 11/25/05 16:23 CST:
> Now, if there is another way of achieving what Matthias has done - one
> where we don't have to have a separate user for each package - that
> would be great. In short, what I'd like to see is a clearer
> understanding of the packages b
On 11/25/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Now, if there is another way of achieving what Matthias has done - one
> where we don't have to have a separate user for each package - that
> would be great. In short, what I'd like to see is a clearer
> understanding of the packages being
Randy McMurchy wrote:
I'd like to work with you on this one (meant as I'd like to give
what you're saying a chance, and not just dismiss the idea).
Thank you.
What exactly do you mean by "more control". I suppose this is what
is confusing me. I am interpreting "more control" as something tha
Randy McMurchy wrote:
What exactly do you mean by "more control". I suppose this is what
is confusing me. I am interpreting "more control" as something that
would allow folks to put files where they want and such, which I
think would be a bad thing, so I'd like to know what you mean as
I don't w
On 11/25/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> I'm going to say this *one more time* and that will be it. My suggestion
> was *not* about package management! It was about using the parts of that
> hint that give you 'more control' over the system. If we can achieve the
> same things via
Jeremy Huntwork wrote these words on 11/25/05 15:18 CST:
> I'm going to say this *one more time* and that will be it. My suggestion
> was *not* about package management! It was about using the parts of that
> hint that give you 'more control' over the system. If we can achieve the
> same things
Dan Nicholson wrote:
No way. That is definitely hint material and way too advanced for a
first timer to debug. Besides, package management is your own choice.
I use a different package management system, and I personally would
be pissed off if my I had hundreds of users on my system each owni
On 11/24/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> So. I had been thinking it would be nice if LFS and BLFS adopted (some
> of) this approach. Again, I fully recognize that this is new ground in a
> way and that many people will think, "it is a hint and should stay a
> hint", but, IMHO, ther
DJ Lucas wrote these words on 11/25/05 03:04 CST:
> The point is that Python must be built before libxml2. Python is listed
> (correctly) only as an optional dep of libxml2. [snip]
>
> but I think it warrants a note.
How does this sound? (This will be an easy-to-see beneath the
Optional Python
In particular when creating the /etc/hosts file it talks about the
private network address Classes, and picking an IP address, etc.
This page, as well as the next one where /etc/sysconfig/network-devices/
files are created, should be modified and list either more, or less
information. What's t
Hello everybody!
Can anyone tell me, why HLFS compiles a hardened toolchain?
ie. things like:
sed -e 's/^CFLAGS\t.*$/& -pie -fpie/' \
-i {progs,tack}/Makefile.in
in chapter 5.
Is there a need to compile SSP and pic/pie in chapter 5?
Wouldn't it be enough to use the toolchain from LFS and j
Matthew Burgess wrote these words on 11/25/05 12:53 CST:
> Perl is needed to run at least the Glibc testsuite, and probably other
> things too.
I didn't know that about Glibc. Thanks for the update.
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stabl
Randy McMurchy wrote:
Furthermore, if you start thinking about packages to pull from LFS,
then you need to start looking at Perl as well. Where do you stop?
Perl is needed to run at least the Glibc testsuite, and probably other
things too. The autotools are not required by any packages in LF
Randy McMurchy wrote:
First, you have to define "what is needed". Only then could one even
begin to consider removing or adding packages to the base LFS system.
This question comes up every now and then (for good reason). It was
decided, and most people have agreed, that we try to maintain thi
Chris Staub wrote these words on 11/25/05 11:42 CST:
> You don't stop. You should be continually evaluating what is and isn't
> needed.
First, you have to define "what is needed". Only then could one even
begin to consider removing or adding packages to the base LFS system.
--
Randy
rmlscsi:
Gerard Beekmans wrote:
There exist programs like checkinstall, install-log, and myriad others
by now that are able to get us that kind of information. These programs
and scripts act as wrappers around "make install" processes usually and
track what is being done (and output of these tools can
Randy McMurchy wrote:
Chris Staub wrote these words on 11/25/05 11:25 CST:
Well, I mean for now at least. :) I mainly said that because I've been
mentioning removing autotools many, many times (mainly in the chat room)
and nobody really gave a reason why not to (except the general
"well-round
Are there really enough distros that won't build lfs (other than the
ones that are just too old and ones that don't meet other basic
criteria) to justify creating a such a list? We already have FAQ
entries for a couple of problematic distros...just add more to the FAQ
as needed...
Very f
Chris Staub wrote these words on 11/25/05 11:25 CST:
> Well, I mean for now at least. :) I mainly said that because I've been
> mentioning removing autotools many, many times (mainly in the chat room)
> and nobody really gave a reason why not to (except the general
> "well-rounded development e
Alexander E. Patrakov wrote:
Matt Darcy wrote:
Hi all,
I believe this has been discussed before, but after reading a post on
lfs-chat recently and some pretty frustring issues within the support
IRC channels, I thought I'd post this open question.
Should there be an "unsupported distro" pa
Gerard Beekmans wrote these words on 11/25/05 11:17 CST:
> My vote is to keep Vim (and its dependencies) as early in chapter 6 as
> possible.
I agree with everything you said in the original message (most of it
snipped for brevity).
In fact, I build Vim in Chapter 5 when I don't automate the bu
Gerard Beekmans wrote:
Chris Staub wrote:
>
Good enough for me. I'll shut up about it now. :)
Please don't. Discussions are always welcome, and encouraged. You'll
find with a lot of projects, and LFS isn't immune to it, that sometimes
there are things that are done because they are always d
Bruce Dubbs wrote:
I think you can compare better with this:
It seems all changes are what I would classify as non-crucial.
There is one thing I would like to bring up:
The placement of Vim. The reason Vim, and its dependencies, are built as
early as possible is to provide us with an editor
Chris Staub wrote:
I've built several whole systems without them - everything else builds
fine. Of course I don't remember how far I got with them (how much I
used them) so I'm not sure how much this means... :p
After I send the email I checked chapter 6's list of dependencies and
nothing use
Gerard Beekmans wrote:
Chris Staub wrote:
3. Drop autoconf, automake, and libtool, or move them to BLFS. I doubt
many non-software-developers actually use them. I never do...
I've done done a check myself in recent months. The reason for autoconf,
automake, and libtool being in the book is to
Gerard Beekmans wrote:
Jeremy's idea of using portions of that hint has merit, but I agree the
hint as-is isn't suitable for the book.
Thank you Gerard. I think you picked up the gist of what I was trying to
achieve.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://w
Jeremy's idea of using portions of that hint has merit, but I agree the
hint as-is isn't suitable for the book.
However, there are other ways to obtain the same information. I think
most people will agree the key element here is learning exactly which
files get installed, if they are setuid ro
FuKu wrote:
hi, I've a group of people,who want to translate LFS, BLFS,. ... project
Can We get a space on yours server, or we must have our ??
It would be much more convenient if you had your own server you could
use. Translations are often short-lived projects especially in the LFS
communi
Chris Staub wrote:
3. Drop autoconf, automake, and libtool, or move them to BLFS. I doubt
many non-software-developers actually use them. I never do...
I've done done a check myself in recent months. The reason for autoconf,
automake, and libtool being in the book is to satisfy dependencies. O
Kev Buckley wrote:
Just in case anyone is interested, I've put the coddled HTML, as it
was a few days ago, here:
http://www.lancs.ac.uk/~kevin/LFS-SVN-051107-kmb.html
Very interesting. This is helpful. :)
As to Jeremy Huntwork's "playful" suggestion that the concepts be
adopted into LFS p
Richard A Downing wrote:
Unix isn't designed to be built this way. It's interesting that it CAN
be. It adds too much complexity - and yes I have tried it - it made
management HARDER.
Heh, no offense meant, but I'm sure there are those who would say the
exact same thing about LFS. :)
If yo
Martin Ereth wrote:
Hello!
I used LFS 6.0. Then gcc 4.0 came up. I read the mail from the
lfs-announce-list, that lfs 6.1.1 will be coming soon.
It seems that gcc 4 is not included there.
Or will it be included?
What are the plans concerning the combination of gcc4 anf lfs?
Where can I fin
Jeremy Huntwork wrote:
Matthew Burgess wrote:
If anyone wants any other features included now's the time to get
those requests in. At the moment, I'm considering branching off for
stabilisation in around 4 weeks time (though with that being very
close to Christmas, it may slip a little). Onl
Hello!
I used LFS 6.0. Then gcc 4.0 came up. I read the mail from the lfs-announce-list, that
lfs 6.1.1 will be coming soon.
It seems that gcc 4 is not included there.
Or will it be included?
What are the plans concerning the combination of gcc4 anf lfs?
Where can I find the roadmap of the
hi, I've a group of people,who want to translate LFS, BLFS,. ... project
Can We get a space on yours server, or we must have our ??
--
-=[FuKu]=-
gg://2897032
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information
> Hello Kev,
>
> I'm not sure I see what you've done.
All I've done was to follow the "More Control and ..." hint and try to
record the changes.
> you just appear to have put "su $package_name_user" infront of each
> package build - and changed nothing else.
>
> Have I missed the point ?
No
Just in case anyone is interested, I've put the coddled HTML, as it
was a few days ago, here:
http://www.lancs.ac.uk/~kevin/LFS-SVN-051107-kmb.html
Basically, as rendered at my end, commands from LFS that I no longer
needed to follow are tagged with a RED background to the
parts and command
> I've been reading and attempting to apply in my spare time Matthias
> Benkmann's hint, 'More Control and Package Management using Package
> Users'. There are *many* aspects of that hint that I find extremely
> helpful and useful, especially from an educational perspective.
> Especially I lik
Jeremy Huntwork wrote:
> So. I had been thinking it would be nice if LFS and BLFS adopted (some
> of) this approach. Again, I fully recognize that this is new ground in a
> way and that many people will think, "it is a hint and should stay a
> hint", but, IMHO, there are many techniques employed he
mp;this 0
XPASS: g++.old-deja/g++.other/init5.C execution test
=== g++ Summary ===
# of expected passes11665
# of unexpected successes 2
# of expected failures 65
# of unsupported tests 64
/home/bdubbs/gcc-build/gcc/testsuite/../g++ version 4.1.0 20
Richard A Downing wrote these words on 11/25/05 01:53 CST:
> On Thu, 24 Nov 2005 21:58:24 -0500
> Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>>I've been reading and attempting to apply in my spare time Matthias
>>Benkmann's hint, 'More Control and Package Management using Package
>>Users'.
>
>
On Thu, 24 Nov 2005 21:51:02 -0600
Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
> > Jeremy Huntwork wrote these words on 11/24/05 21:23 CST:
>
> >>It is a mystery why Unix admins who wouldn't even trust their employer
> >>with more than a normal user account carelessly execute
45 matches
Mail list logo
