Randy McMurchy wrote:
Either way, I don't see why we couldn't release a UTF-8 ready version
of LFS, and a BLFS that is as best as we can do (with a caveat up
front stating that the UTF-8 implementation is incomplete, and my not
work correctly.
Agreed. UTF-8 has been present but broken in LFS f
Alexander E. Patrakov wrote these words on 02/10/06 03:25 CST:
> I do not blame BLFS.
Thanks for personally clarifying this issue.
> I am just saying that it is a huge (but doable!)
> job for me to verify all BLFS packages. My point is that if we release
> both LFS and BLFS now,
I didn't rea
Alexander E. Patrakov wrote:
Justin R. Knierim wrote:
Nevermind, I just tried with the 6.2-pre3 LiveCD and I can't
reproduce the error either. Sorry for the noise, I can't figure it out.
The issue is probably that the old root password contained some
non-ASCII character, and someone recent
Randy McMurchy wrote:
Justin R. Knierim wrote these words on 02/09/06 09:50 CST:
IMO he isn't blaming BLFS for problems with UTF-8.
Then you and I read plain English differently. IMO, the following
statement directly conflicts with what you say above:
"But it is indeed better to say
Justin R. Knierim wrote:
Nevermind, I just tried with the 6.2-pre3 LiveCD and I can't reproduce
the error either. Sorry for the noise, I can't figure it out.
The issue is probably that the old root password contained some
non-ASCII character, and someone recently changed the password to pure
Justin R. Knierim wrote:
Hmm, strange. I wasn't using the German profile when I reported that
problem, it was the normal en_US.UTF-8. Anyways, I'll try it again
tonight and see what I can find.
Nevermind, I just tried with the 6.2-pre3 LiveCD and I can't reproduce
the error either. Sorry
Jeremy Huntwork wrote:
Worked fine here... I will note that, seeing that I'm using a german
locale, my keys were a bit askew. The 'z' and the 'y' were reversed
and the '-' was where the '/' key is. Other than that, it worked fine.
Hmm, strange. I wasn't using the German profile when I report
Justin R. Knierim wrote:
Jeremy Huntwork wrote:
I tried looking for the error using a recently built LFS LiveCD. I've
been using en_US.UTF-8 as a locale with it recently, and ssh both
incoming and outgoing has worked fine for me.
Logging in is fine. Once you are in, try "su - root".
Worke
Jeremy Huntwork wrote:
I tried looking for the error using a recently built LFS LiveCD. I've
been using en_US.UTF-8 as a locale with it recently, and ssh both
incoming and outgoing has worked fine for me.
Logging in is fine. Once you are in, try "su - root".
Justin
--
http://linuxfromscratc
Joel Miller wrote:
I'd like some clarification on one point then. IIRC, I read in a post by
Alexander that the changes to the book made it so that ssh would no
longer connect properly to non UTF-8 systems. In order to do that you
had to run ssh through screen. This would be a *massive* inconven
Chris Staub wrote:
Joel Miller wrote:
Jeremy Huntwork wrote:
And to further clarify, an LFS machine as it currently is does *not*
automatically use UTF-8. The changes to the LFS book are so that the
LFS system *can* use UTF-8 properly if a user requires it. IMO, this is
I'd like some clarif
Joel Miller wrote:
Jeremy Huntwork wrote:
And to further clarify, an LFS machine as it currently is does *not*
automatically use UTF-8. The changes to the LFS book are so that the
LFS system *can* use UTF-8 properly if a user requires it. IMO, this is
I'd like some clarification on one point
Joel Miller wrote:
Jeremy Huntwork wrote:
And to further clarify, an LFS machine as it currently is does *not*
automatically use UTF-8. The changes to the LFS book are so that the
LFS system *can* use UTF-8 properly if a user requires it. IMO, this is
I'd like some clarification on one point
Jeremy Huntwork wrote:
And to further clarify, an LFS machine as it currently is does *not*
automatically use UTF-8. The changes to the LFS book are so that the
LFS system *can* use UTF-8 properly if a user requires it. IMO, this is
I'd like some clarification on one point then. IIRC, I read
Jeremy Huntwork wrote:
On Thu, Feb 09, 2006 at 10:50:44AM -0600, Bruce Dubbs wrote:
My only problem with LFS on the issue is that LFS traditionally has not
offered choices. That is, there is only "one true path" through the
book. This makes users who do not need or want UTF-8 proceed on the
On Thu, Feb 09, 2006 at 10:50:44AM -0600, Bruce Dubbs wrote:
> My only problem with LFS on the issue is that LFS traditionally has not
> offered choices. That is, there is only "one true path" through the
> book. This makes users who do not need or want UTF-8 proceed on their
> own. IMO, this is
Justin Knierim wrote:
> There
> are other problems, such as people not wanting the bloat, english
> speakers not seeing the need, etc.
Just to clarify: As an English (only) speaker, I really don't want
UTF-8 on *my* system. As a BLFS developer, I certainly understand the
desire and need for U
Randy McMurchy wrote:
Justin R. Knierim wrote these words on 02/09/06 09:50 CST:
IMO he isn't blaming BLFS for problems with UTF-8.
Then you and I read plain English differently. IMO, the following
statement directly conflicts with what you say above:
Arg, need to re-read emails be
Justin R. Knierim wrote these words on 02/09/06 09:50 CST:
> IMO he isn't blaming BLFS for problems with UTF-8.
Then you and I read plain English differently. IMO, the following
statement directly conflicts with what you say above:
"But it is indeed better to say "no" to UTF-8 support now, becau
Randy McMurchy wrote:
IMO he isn't blaming BLFS for problems with UTF-8. Alexander has
publically stated that after adding UTF-8 to LFS, that maybe it really
isn't ready for the main book. Even asking to revert it or put it in an
experimental branch.
http://archives.linuxfromscratch.org/m
Alexander E. Patrakov wrote these words on 02/08/06 22:52 CST:
> The blacklist approach ("If a package is not listed
> here, it means there are no known locale specific issues or problems
> with that package" on
> http://www.linuxfromscratch.org/blfs/view/svn/introduction/locale-issues.html)
>
Alexander E. Patrakov wrote these words on 02/08/06 22:52 CST:
> But it is indeed better to say "no" to UTF-8 support now, because of
> BLFS issues and because UTF-8 support is a property of the whole system,
> not just its base. The blacklist approach ("If a package is not listed
> here, it me
Greg Schafer wrote:
Correct. However, the problem is with Readline and not Bash.
You are of course right. Thanks for the correction. I noticed this in
Chapter 5 as a difference between Glibc-based LFS and uClibc-based HLFS.
That's why I thought it's bash.
Now grep the Readline source for N
Alexander E. Patrakov wrote:
> some tme ago I imported from DIY linux the statement that none of the
> locales are really required. As it stands now, this statement is wrong.
> When checking whether the ctype macros accept non-ascii characters, Bash
> configure script attempts to set the en_US.
Hello,
some tme ago I imported from DIY linux the statement that none of the
locales are really required. As it stands now, this statement is wrong.
When checking whether the ctype macros accept non-ascii characters, Bash
configure script attempts to set the en_US.ISO8859-1 locale. However, it
25 matches
Mail list logo
