DJ Lucas wrote:
> Bruce Dubbs wrote:
>
>>Jim Gifford wrote:
>>
>>
>>
>>>We are asking Manuel for a way to
>>>put a decision at the beginning of the chapter for a choice, if choice a
>>>- chroot then display these, if choice b - reboot do these. I can work
>>>that in with no problems.
>>
>>
>>I rea
Bruce Dubbs wrote:
> Jim Gifford wrote:
>
>
>>We are asking Manuel for a way to
>>put a decision at the beginning of the chapter for a choice, if choice a
>>- chroot then display these, if choice b - reboot do these. I can work
>>that in with no problems.
>
>
> I really don't care for that appr
Jim Gifford wrote:
> We are asking Manuel for a way to
> put a decision at the beginning of the chapter for a choice, if choice a
> - chroot then display these, if choice b - reboot do these. I can work
> that in with no problems.
I really don't care for that approach. A discussion and presentat
Randy McMurchy wrote:
Cool!
But don't make it a hint, make it part of the book. :-)
Ideally, yes, it should be in the book. However, if for some reason
that's unfeasable, because of limitations in the XML or whatever the
case may be, then my feeling is it could be easily written up as a hint
Bruce Dubbs wrote:
My objection was to the comment that rebooting was mandatory. If
instructions are given to give the user a choice and to explain the pros
and cons, I do not object.
As I mentioned, the WORST case scenario would be to provide a hints
document outlining the process for using c
Randy McMurchy wrote:
Jeremy Utley wrote these words on 04/18/05 23:44 CST:
There's a lot of plusses to this build, and very few downfalls, when you
really sit down to think about it. Mentioning the need for the reboot
was a good thing, but it's important to know WHY that becomes essential
-
Jeremy Utley wrote these words on 04/19/05 00:05 CST:
> Oh believe me, Randy. I build remotely too (I have my server in the
> datacenter, plus my home server that I only have access to via SSH), and
> even if the default position of the book was to take the reboot method,
> the chroot method co
Randy McMurchy wrote:
It does. But it is a far cry from the original post by Jim a few
hours ago where the book will have *one* method of building, which
includes rebooting into the 'tools' host.
As long as there is provisions to build remotely, using a known
good host, there is only positives to b
Jeremy Utley wrote:
> Randy McMurchy wrote:
>
>> The need to reboot and build from the console is an overwhelmingly
>> big new difference. To the point that I would have to find a different
>> build method than what Jim described.
> And that need only arises if you are building from a different a
Jeremy Utley wrote these words on 04/18/05 23:44 CST:
> There's a lot of plusses to this build, and very few downfalls, when you
> really sit down to think about it. Mentioning the need for the reboot
> was a good thing, but it's important to know WHY that becomes essential
> - because if we'r
>[EMAIL PROTECTED] wrote these words on 04/18/05 21:55 CST:
>
>> Please folks, have a bit of a think about how things actually
>work,
>> or actually take a look at how it hangs together, before going off
>> the deep end
>
>Nobody's gone off the deep end, Ryan. We're just asking questions.
>Th
Randy McMurchy wrote:
Jeremy Utley wrote these words on 04/18/05 23:14 CST:
Randy McMurchy wrote:
Please, Jim, for me and I'm sure there are others that want to know
the same thing, can you explain *in a technical manner* how the
toolchain could be any "cleaner"?
A simple example wil
Jeremy Huntwork wrote these words on 04/18/05 23:29 CST:
> My point was that in the banter between yourself
> and Ryan it looked as though things were quickly becoming unpleasant and when
> that happens the intelligence of these discussions always suffers. I don't
> know
> about you, or anyone el
Jeremy Utley wrote these words on 04/18/05 23:14 CST:
> Randy McMurchy wrote:
>>Please, Jim, for me and I'm sure there are others that want to know
>>the same thing, can you explain *in a technical manner* how the
>>toolchain could be any "cleaner"?
>
> A simple example will document this clearly.
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 interfere
Randy McMurchy wrote:
Please, Jim, for me and I'm sure there are others that want to know
the same thing, can you explain *in a technical manner* how the
toolchain could be any "cleaner"?
A simple example will document this clearly. Take building LFS on a
Fedora core release. In the past, we
On Mon, Apr 18, 2005 at 10:47:52PM -0500, Randy McMurchy wrote:
>
> And was exactly why I was so surprised to see this message. I take
> offense to the Editor of the BLFS book coming onto the -dev list
> with problems he's having with a precompiled version of OpenOffice.
Get off your high horse,
Jeremy Huntwork wrote these words on 04/18/05 22:40 CST:
> Ok, let's stop this right here. Are we really that incapable of carrying
> on intelligent conversation? Why the need to make things personal? And
> yes, I know Ryan directed his somewhat strong comments at you Randy, but
> come on... Is
Randy McMurchy wrote:
[EMAIL PROTECTED] wrote these words on 04/18/05 21:55 CST:
Your message did not help me understand the changes, Ryan. It came
off as a defensive, poorly phrased way of saying that building LFS
on the x86 platform is for sissys.
Ok, let's stop this right here. Are we really tha
Presently, the only logging that happens seems to be post-sysklog
starting up. This seems to have very limited usefulness as it will miss
any errors about why the net may not have come up or why fsck may have
failed. So this email is meant to ascertain if there is any support for
continuing the mai
[EMAIL PROTECTED] wrote these words on 04/18/05 21:55 CST:
> Please folks, have a bit of a think about how things actually work,
> or actually take a look at how it hangs together, before going off
> the deep end
Nobody's gone off the deep end, Ryan. We're just asking questions.
The LFS Editor wh
Ken Moffat wrote:
>nfs-utils ? (all my source is on an nfs mount).
Heh, I build portmap, tcp-wrappers and nfs-utils
(all my source and homedirs are nfs mounts)
>Cross-compiling is a very educational experience, for those few who
>manage to complete it (I've cross-compiled kernels, cross-comp
On Mon, Apr 18, 2005 at 07:58:27PM -0400, Jeremy Huntwork wrote:
>
> Create alternate instructions in the book. If you are building for a
> separate arch, build a kernel, and boot your machine with the new tools,
> otherwise enter chroot. This way you won't have to keep up two books,
> and for
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 al
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 of the pit
Jim Gifford wrote these words on 04/18/05 18:36 CST:
> Randy the message was posted a long time ago and no objections were
> noted. Here is the original post from Matt,
> http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-February/050262.html,
>
> granted it was in a message about
Jeremy Huntwork wrote:
It could be done, but you'd have to deviate, likely, from what is in
the book. If I'm understanding this correctly, if you are for example,
building traditional x86 > x86 you could swap out the reboot for a
chroot. I suppose that would be the case for any matching arch pai
Randy McMurchy wrote:
Jim Gifford wrote these words on 04/18/05 18:10 CST:
There may be a simple resolution, since in the MIPS build and some
of the other architecture that don't have keyboards and mice, we had to
add SSL, and SSH. We could add them to the BOOK as core packages.
SSL/SS
Bruce Dubbs wrote:
Jim Gifford wrote:
We will no longer be doing a chroot, since we are going to be booting
into a working Linux with enough tools to build what we need, this could
be a plus for those who want a more minimal system and an easy way to
get rid of the tools directory.
I have a major
Jim Gifford wrote these words on 04/18/05 18:10 CST:
> There may be a simple resolution, since in the MIPS build and some
> of the other architecture that don't have keyboards and mice, we had to
> add SSL, and SSH. We could add them to the BOOK as core packages.
SSL/SSH != minimalistic
I
Bruce Dubbs wrote:
Jim Gifford wrote:
We will no longer be doing a chroot, since we are going to be booting
into a working Linux with enough tools to build what we need, this could
be a plus for those who want a more minimal system and an easy way to
get rid of the tools directory.
I have a
Jim Gifford wrote:
> We will no longer be doing a chroot, since we are going to be booting
> into a working Linux with enough tools to build what we need, this could
> be a plus for those who want a more minimal system and an easy way to
> get rid of the tools directory.
I have a major problem wi
Archaic wrote:
> What kind of timeline might there be for adding user/group configuration
> to the packages that need them? I'm trying to figure out when we can
> make the changes listed in:
>
> http://bugs.linuxfromscratch.org/show_bug.cgi?id=1032
I want to put that in in the next week or two.
M.Canales.es wrote:
> El Domingo, 17 de Abril de 2005 01:52, Bruce Dubbs escribió:
> Bruce, is there some policies decided about all that topics?
>
> I would start my work soon to can release BLFS-6.1 with an homogeneus XML
> tagging and HTML/PDF look across the book.
Manuel, what we need first
Randy McMurchy wrote:
Jim Gifford wrote these words on 04/18/05 16:25 CST:
Randy McMurchy wrote:
I mean, using the new method versus the current method, you still
end up with the same exact end product, right?
Actually, you get a cleaner toolchain, from my experience with this
proce
Jim Gifford wrote these words on 04/18/05 16:25 CST:
> Randy McMurchy wrote:
>>I mean, using the new method versus the current method, you still
>>end up with the same exact end product, right?
>
> Actually, you get a cleaner toolchain, from my experience with this
> process and a much more minim
Jim Gifford wrote:
>2 - No Web Browser
> You will no long be able to view web pages for the LFS BOOK.
> You will have a local copy or we
> can add into the directions to download a text copy of the book.
Could we add Lynx to the end of the chapter right before the reboot?
The
Randy McMurchy wrote:
Jim Gifford wrote these words on 04/18/05 16:03 CST:
Another issue will be after the tools are built we will be building a
cross-compiled kernel, so we can boot into the architecture we are
building for and complete the build process. There are a few pitfalls to
this.
Jim Gifford wrote these words on 04/18/05 16:03 CST:
> Another issue will be after the tools are built we will be building a
> cross-compiled kernel, so we can boot into the architecture we are
> building for and complete the build process. There are a few pitfalls to
> this.
> 1 - All sour
Just a not about what is planned about the next release, and some
concerns that have been raised. The development team is asking for
community opinion.
For the 7.x release we are planning to release a cross compiled
multi-architecture book. The build process will allow you to build for
any arc
On April 18, 2005 11:29 am, Archaic wrote:
> It
> seems to me that blocking port 80 (for example) would be a system-wide
> policy and not one that required that a daemon that uses port 80 is on
> the box. I do believe the rules should be *configured* in each relevant
> package's page, but I don't s
Bryan Kadzban wrote:
> Matthew Burgess wrote:
>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>>I suppose though we'll need 2 host compilers, we'll need a 3.4 for
>>>the kernel builds etc
>>
>>Why?
>
>
> I'm just guessing here, but I would bet that it'll be similar to the gcc
> 2.95 / gcc 3.X upgrade. The
Randy McMurchy wrote:
Hi all,
It appears the BLFS book hasn't rendered for the last couple of
cycles. It appears stuck on the 4/16 changes. Is there anything in
the logs or elsewhere that may show what is going on?
I just tried rendering it manually. It's having trouble with the latest
versions o
Hi all,
It appears the BLFS book hasn't rendered for the last couple of
cycles. It appears stuck on the 4/16 changes. Is there anything in
the logs or elsewhere that may show what is going on?
I'm basing this on the fact the there are no mirrors current, as
well as Belgarath being behind.
--
Ra
On Sun, Apr 17, 2005 at 10:29:22AM -0700, Jeremy Utley wrote:
>
> But, how is someone who wants to use this branch to do so when the other
> packages are perhaps 2 or 3 months behind? That's my concern - if the
> other parts of the GCC 4.0 book are not kept up to date, then noone's
> going to
Matthew Burgess wrote:
> [EMAIL PROTECTED] wrote:
>
>> I suppose though we'll need 2 host compilers, we'll need a 3.4 for
>> the kernel builds etc
>
> Why?
I'm just guessing here, but I would bet that it'll be similar to the gcc
2.95 / gcc 3.X upgrade. The kernel documentation said to use 2.95
Nathan Coulson wrote:
We do use it in a few bootscripts, so I will use it here
Just to make sure it works before 3.2.1, I made up a beta version at
http://www.linuxfromscratch.org/~nathan/lfs-bootscripts/lfs-bootscripts-20050417.tar.bz2
Can you make sure the localnet script works Andrew?
That local
[EMAIL PROTECTED] wrote:
I suppose though we'll need 2 host compilers, we'll need a 3.4 for
the kernel builds etc
Why?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
48 matches
Mail list logo
