On Wed, Sep 14, 2005 at 11:53:48PM -0700, Jim Gifford wrote:
> Matt, one thing I think everyone here has forgot, what about cross-lfs.
> How will the change affect us.
If you have concerns, ideas, or comments, please post them.
--
Archaic
Want control, education, and security from your operati
What's up?
Английский Разговорный с преподавателями из США.
Каждому по скидке!
Мы ждём Вашего звонка в Москве:
105 пять-один-восемь-шесть
238-33-86
Leonarder Pudov Gourley
Martin Nowak Oliveira Przybyl
Ronco Safronyuk Rasmussen Beresnev
--
http://linuxfromscratch.org/mailman/listinfo/lfs-
After some discussion with Gerard, he has requested I prepare a proposal
to the LFS community concerning the Cross-LFS book.
Up to this point work on Cross-LFS has been done with the idea that,
eventually, its features would be merged into the main LFS book. I would
like at this time to propos
Jim Gifford wrote:
I would like at this time to propose that we create a separate project for
Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for wanting
to do so:
Agreed in priniciple, though I have a couple of nits to pick...
Why waste the LFS community's time searching for a bu
Matthew Burgess wrote:
Jim Gifford wrote:
I would like at this time to propose that we create a separate project
for Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for
wanting to do so:
Agreed in priniciple
Me too. It's nearly its own project now as it is.
I'd rather see th
Hi.
For stunnel tcpwrappers are just listed as optional. But compiling stunnel
without installed tcpwrappers leads (at least on my machine) to an linker
error about not knowing -lwrap.
Issuing --disable-libwrap to the configure line helps. So I suggest either
making tcpwrappers an required pac
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 versions, etc?
Depending on the outcome of thi
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 versio
El Jueves, 15 de Septiembre de 2005 19:06, Jim Gifford escribió:
> After some discussion with Gerard, he has requested I prepare a proposal
> to the LFS community concerning the Cross-LFS book.
>
> Up to this point work on Cross-LFS has been done with the idea that,
> eventually, its features would
On Thu, Sep 15, 2005 at 08:33:59PM +0200, 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 boo
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 = target-trip
One of things I've been mulling over is maybe have cross-lfs just build
the toolchains, but the rest of the stuff, currently the temp-system and
final-system of Cross-LFS, could be the future LFS book that supports
multiple architectures.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User
El Jueves, 15 de Septiembre de 2005 22:56, Jim Gifford escribió:
> One of things I've been mulling over is maybe have cross-lfs just build
> the toolchains, but the rest of the stuff, currently the temp-system and
> final-system of Cross-LFS, could be the future LFS book that supports
> multiple ar
Jim Gifford wrote:
One of things I've been mulling over is maybe have cross-lfs just
build the toolchains, but the rest of the stuff, currently the
temp-system and final-system of Cross-LFS, could be the future LFS
book that supports multiple architectures.
I'll put my comments in now t
M.Canales.es wrote:
Yes, that is how I see it also. Both books could be almost indentical except
in how the tolchains are created and the way used to build the final system
(boot or chroot).
If we do this, we could remove chroot from the Cross-LFS, since it's
only there for same arch to sam
Jim Gifford wrote:
I would like at this time to propose that we create a separate project for
Cross-LFS, like ALFS, HLFS and BLFS.
That sounds like a good idea to me. +1
Justin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See
Hey guys,
As an experiment, the other night I changed the /bin/sh symlink from /bin/bash
to /usr/bin/zsh. It didn't go too well. The two main problems I picked up
were that first of all, zsh apparently doesn't need the column width
variables, and spits the dummy if they're present. The second th
On Fri, Sep 16, 2005 at 11:29:15AM +1000, [EMAIL PROTECTED] wrote:
>
> I'm assembling some patches, because sequethin and I had a look on IRC and it
> seems that zsh isn't the only shell affected by this - ksh was as well. What
> I wanted to ask though is, when I've got the patches working, where
> Before you send patches, they need to work on ash as well, which IIRC,
> is the closest representation of the original bourne shell.
Thanks. I will admit that my current fix is rather a blunt instrument, in the
sense that it simply checks to see if the /bin/sh symlink points to bash, and
if it
[EMAIL PROTECTED] wrote:
> The second thing is that it appears that the . abbreviation for the
> source command doesn't work in zsh's /bin/sh compatibility mode
> either.
Which is ... odd, because IIRC, ash and sh don't *have* a "source"
builtin. [1] All they have is ".", but if that doesn't work
[EMAIL PROTECTED] wrote:
> Are there any tcsh users here who could tell me which changes (if
> any) would be needed for that shell?
I have a feeling it'd be way too many to ever make it work... basic
things like doing "if"s use a completely different syntax, so even your
"if-elif" idea won't work
On 9/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> ... I'm only considering the five major ones here,
> too...tcsh, zsh, ksh, bash, and ash. Are there any tcsh users here who could
> tell me which changes (if any) would be needed for that shell?
honestly, far too many ... tcsh is a csh d
On Thu, Sep 15, 2005 at 10:08:50PM -0400, Joshua Murphy wrote:
>
> as a vaguely connected question, how would a person stuck using a
> university's ssh servers with LDAP change their login shell? other
> than the obvious running tcsh in login mode ... from .bash_profile or
> .bashrc (my current ha
On Fri, Sep 02, 2005 at 04:13:24PM +0200, Tobias Stoeckmann wrote:
>
> Instead of typing "install -d /usr/share/man/man{1,2,3,4,5,6,7,8}"
> the same thing could be done with "install -d /usr/share/man/man{1..8}".
Fixed. Thanks for the report!
--
Archaic
Want control, education, and security fr
On Thu, 15 Sep 2005 22:08:50 -0400, Joshua Murphy <[EMAIL PROTECTED]>
wrote:
>> tell me which changes (if any) would be needed for that shell?
>
>honestly, far too many ... tcsh is a csh derivative, the syntax and
>such is far removed form the bourne shells ... it would require a near
>full re-wri
On Sun, Sep 11, 2005 at 10:47:50PM -0400, John Kelly wrote:
>
> All this work to isolate the new system from the host distribution may
> seem excessive, but a full technical explanation is provided at the
> beginning of Chapter 5.
John and Eric, thanks for your input! Both issues were addressed i
26 matches
Mail list logo
