headers
DJ Lucas | 1 Oct 2004 01:13
Picon
Favicon

Re: Bootscripts -- BZ 774

Nathan Coulson wrote:
> On Wed, 29 Sep 2004 00:13:29 -0500, DJ Lucas <dj <at> linuxfromscratch.org> wrote:
> 
> hmm, forgot about this bug... [It was meant as a reminder for myself]
> (when the BLFS bootscripts were in the lfs-bootscripts tarball
> 
> by default, the path is set in functions, and I would assume there is
> a chance people dont install everything to /usr.  [some may use
> /usr/local].  I would therefore say no path is best in *most cases*
> 
> back when I brought this up though, someone mentioned sendmail needed
> full path [and maybe other programs], so then I just let it rest as
> is.
> 
> by error handling, [BTW, last I checked the NFS script didn't handle
> this right], just making sure scripts that handle multiple binaries
> dont have evaluate_retval only handling the last command or something.
> [in NFS's case, we start 3 programs, but the evaluate_retval's just
> keep overwriting one another].
> 

Okay guys, given that, leave them as is then?  Or do them all with no 
path except sendmail and openssh (and any others we find along the way)? 
  Or should there be an explicit path for everything?  Honestly, I 
really could care less which is chosen, I just want some reasoning for 
having some paths and others not; consistancy of some sorts.  Now with 
the recent discussion, I like full paths.  If you deviate from the book 
you are on your own unless the alternate installation prefix is given, 
then a note should be provided.  I want the bug closed, full paths seems 
best.  Any objections?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexander E. Patrakov | 1 Oct 2004 07:00
Picon

Re: i18n XML question

Matthew Burgess wrote:
> Alexander E. Patrakov wrote:
> 
>> There may be plans to add UTF-8 support to LFS. This breaks (wontfix) 
>> many packages in BLFS.
> 
> 
> Could you elaborate (preferably by example) of how adding UTF-8 support 
> breaks an application.

This example is for Linux console because I don't know which terminal 
emulator you use, and xterm is the hardest to configure. The example 
uses programs only from the bare LFS installation. The badly-behaning 
program is "watch" as it makes the assumption that a character occupies 
8 bits. However, in UTF-8, the number of bytes per character is not a 
constant.

First, create (as root) two Russian locales. You may skip this step if 
you have glibc newer than 20040701 and installed all supported locales 
during glibc installation.

localedef -i ru_RU -f koi8-r ru_RU.KOI8-R
localedef -i ru_RU -f UTF-8 ru_RU.UTF-8

Then, on the linux console, make sure that "df" and "watch" programs 
work for you in your locale.

watch df

You will see something like:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeremy Utley | 1 Oct 2004 07:24

Re: i18n XML question

Alexander E. Patrakov wrote:

>
> Well, Jeremy Utley didn't permit me to add "if"s, compilcations, and 
> instructions that can't be verified by the editors into the book. 
> There will be no UTF-8 support in LFS.
>
You *REALLY* need to stop doing this to people, Alexander.  I don't 
permit, or prevent, anyone from doing anything.  I simply told you I 
didn't think we wanted to start bloating the book with a bunch of "If 
you're in this locale, do this" type of things.  And it is definately 
true that we have no possible means of testing support for EVERY locale 
in LFS, so we, as LFS editors, can not guarantee it will work anywhere 
other than en_US, and perhaps en_GB, which are the ones that most LFSers 
use.

-J-

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 1 comment |
headers
Jim Gifford | 1 Oct 2004 07:28

Re: i18n XML question

Jeremy Utley wrote:

> Alexander E. Patrakov wrote:
>
>>
>> Well, Jeremy Utley didn't permit me to add "if"s, compilcations, and 
>> instructions that can't be verified by the editors into the book. 
>> There will be no UTF-8 support in LFS.
>>
> You *REALLY* need to stop doing this to people, Alexander.  I don't 
> permit, or prevent, anyone from doing anything.  I simply told you I 
> didn't think we wanted to start bloating the book with a bunch of "If 
> you're in this locale, do this" type of things.  And it is definately 
> true that we have no possible means of testing support for EVERY 
> locale in LFS, so we, as LFS editors, can not guarantee it will work 
> anywhere other than en_US, and perhaps en_GB, which are the ones that 
> most LFSers use.
>
> -J-
>
I will have to agree with Jeremy on this, why not create a simple hint 
to deal with this instance.

--

-- 
------
jim <at> linuxfromscratch.org
lfs <at> jg555.com

LFS User # 2577
Registered Linux User # 299986
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander E. Patrakov | 1 Oct 2004 08:34
Picon

Re: i18n XML question

Bruce Dubbs wrote:
> Alexander E. Patrakov wrote:
> 
>> There may be plans to add UTF-8 support to LFS. This breaks (wontfix) 
>> many packages in BLFS. The only visible way to address this problem is 
>> to just mark broken packages. Could you please suggest a canonical XML 
>> entity to be included as:
>>
>> &broken-in-utf;
>>
>> (like we already have &library-config;)
>>
>> In other words, what should this new entity expand to? 
> 
> I would be a good idea to do that.  Perhaps you can suggests some wording.

This package makes assumptions such as "each character occupies one byte 
of storage" and "each byte in a string is one character", that are not 
valid in multibyte locales (including UTF-8 ones). We recommend you not 
to install this package if you plan to use such locales, because it will 
not work properly.

> "no-utf-8-support.xml"  would be appropriate.  I'd also like to see a 
> list of which files you suggest are broken.

Incomplete list follows. (?) means "not tested but suspicious". All 
packages that depend on a broken package are also broken.

- (?) nano
- (?) ash
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Coulson | 1 Oct 2004 08:55
Picon

Re: Bootscripts -- BZ 774

On Thu, 30 Sep 2004 18:13:54 -0500, DJ Lucas <dj <at> linuxfromscratch.org> wrote:
> 
> 
> Nathan Coulson wrote:
> > On Wed, 29 Sep 2004 00:13:29 -0500, DJ Lucas <dj <at> linuxfromscratch.org> wrote:
> >
> > hmm, forgot about this bug... [It was meant as a reminder for myself]
> > (when the BLFS bootscripts were in the lfs-bootscripts tarball
> >
> > by default, the path is set in functions, and I would assume there is
> > a chance people dont install everything to /usr.  [some may use
> > /usr/local].  I would therefore say no path is best in *most cases*
> >
> > back when I brought this up though, someone mentioned sendmail needed
> > full path [and maybe other programs], so then I just let it rest as
> > is.
> >
> > by error handling, [BTW, last I checked the NFS script didn't handle
> > this right], just making sure scripts that handle multiple binaries
> > dont have evaluate_retval only handling the last command or something.
> > [in NFS's case, we start 3 programs, but the evaluate_retval's just
> > keep overwriting one another].
> >
> 
> Okay guys, given that, leave them as is then?  Or do them all with no
> path except sendmail and openssh (and any others we find along the way)?
>   Or should there be an explicit path for everything?  Honestly, I
> really could care less which is chosen, I just want some reasoning for
> having some paths and others not; consistancy of some sorts.  Now with
> the recent discussion, I like full paths.  If you deviate from the book
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dagmar d'Surreal | 1 Oct 2004 23:32

Re: FHS standards and GNOME

On Wed, 2004-09-29 at 20:38 -0500, Randy McMurchy wrote:
> Dagmar d'Surreal wrote:
> 
> > The problem is that it creates additional complexity, at the very least
> > requiring a minimum of four more environment changes to accomodate it.
> 
> People spend hours building a Linux system from scratch. Everything
> must be perfect. Then hours more installing additional applications,
> many of which require customizing configuration files.
> 
> And you say "additional complexity" because someone has to follow
> instructions to modify 4 files?
> 
> Please......

No, I said "at least 4 files".  Meaning a number greater than or equal
to four.

Considering that a very visible slice of the pie for problems building
Gnome stems from people overlooking one or more configuration arguments
that have to be specified differently, this change does cause problems,
and somewhere, there's a bit of documentation for BLFS stating that
changes/alterations of builds need to bring something significant to the
table before they'll be accepted.

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Dubbs | 2 Oct 2004 07:09

Re: Bootscripts -- BZ 774

DJ Lucas wrote:

>
> Okay guys, given that, leave them as is then?  Or do them all with no 
> path except sendmail and openssh (and any others we find along the 
> way)?  Or should there be an explicit path for everything?  Honestly, 
> I really could care less which is chosen, I just want some reasoning 
> for having some paths and others not; consistancy of some sorts.  Now 
> with the recent discussion, I like full paths.  If you deviate from 
> the book you are on your own unless the alternate installation prefix 
> is given, then a note should be provided.  I want the bug closed, full 
> paths seems best.  Any objections?
>

Nope.  That seems best to me.  It's more secure too.

  -- Bruce

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 1 comment |
headers
Jeremy Huntwork | 2 Oct 2004 20:44
Picon
Favicon
Gravatar

rp-pppoe & iproute2

Hey all,

I had a kind Canadian report a misconfiguration with my latest cd.
Seems that rp-pppoe isn't set up to play with iproute, but still uses
ifconfig in its scripts.  I haven't looked at them myself yet, though I
might soon.  Just wondering if anyone else is aware of this, and/or what
needs to be done to make them work together.

-- 
Jeremy Huntwork
http://www.jenacon.net

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 0 comments |
headers
Dagmar d'Surreal | 3 Oct 2004 01:08

Re: Bootscripts -- BZ 774

On Thu, 2004-09-30 at 18:13 -0500, DJ Lucas wrote:
> Nathan Coulson wrote:
> > On Wed, 29 Sep 2004 00:13:29 -0500, DJ Lucas <dj <at> linuxfromscratch.org> wrote:
> > 
> > hmm, forgot about this bug... [It was meant as a reminder for myself]
> > (when the BLFS bootscripts were in the lfs-bootscripts tarball
> > 
> > by default, the path is set in functions, and I would assume there is
> > a chance people dont install everything to /usr.  [some may use
> > /usr/local].  I would therefore say no path is best in *most cases*
> > 
> > back when I brought this up though, someone mentioned sendmail needed
> > full path [and maybe other programs], so then I just let it rest as
> > is.
> > 
> > by error handling, [BTW, last I checked the NFS script didn't handle
> > this right], just making sure scripts that handle multiple binaries
> > dont have evaluate_retval only handling the last command or something.
> > [in NFS's case, we start 3 programs, but the evaluate_retval's just
> > keep overwriting one another].
> > 
> 
> Okay guys, given that, leave them as is then?  Or do them all with no 
> path except sendmail and openssh (and any others we find along the way)? 
>   Or should there be an explicit path for everything?  Honestly, I 
> really could care less which is chosen, I just want some reasoning for 
> having some paths and others not; consistancy of some sorts.  Now with 
> the recent discussion, I like full paths.  If you deviate from the book 
> you are on your own unless the alternate installation prefix is given, 
> then a note should be provided.  I want the bug closed, full paths seems
(Continue reading)

Permalink | Reply | 0 comments |

Gmane