Re: 7.0 Goals (top level bootstrap)

[Greg Schafer]

Robert Connolly wrote:

> With HLFS I'm leaning towards bootstrapping the chroot toolchain. It's how 
> the 
> GCC developers would want it.

You cannot speak for the GCC developers, so please don't. IMHO you are WAY
off the mark anyway.

> I don't know if LFS has also considered the top level makefile build method 
> being promoted by GCC/GNU, so that GCC and Binutils are built together in the 
> same tree. The difference here is that Binutils is also bootstrapped like 
> GCC.

I have considered it, but ruled it out for obvious reasons. What's more, I
don't know why you think this is something new. Building "combined tree"
toolchains has been an integral part of the top level build system ever
since the Cygnus Solutions days. What *is* new is the fact that the
assembler and linker can now also be bootstrapped as part of the 3-stage
GCC bootstrap process.

You have apparently overlooked the obvious fact that combined tree builds
are designed for *developers* working from svn trunk. They are clearly not
suitable for builds based on tarballs which is what we as *consumers* are
using. Just look at the hacks you have to use to create the combined tree.
If the big distros ever start using a combined tree, that's when we should
look at it IMHO.

Regards
Greg
-- 
http://www.diy-linux.org/

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals (top level bootstrap)

[Robert Connolly]

With HLFS I'm leaning towards bootstrapping the chroot toolchain. It's how the 
GCC developers would want it.

I don't know if LFS has also considered the top level makefile build method 
being promoted by GCC/GNU, so that GCC and Binutils are built together in the 
same tree. The difference here is that Binutils is also bootstrapped like 
GCC.

They're both related. GCC wants to reduce bug reports related to the host 
system. By boostrapping as many host dependencies as possible, or all of 
them, dependency problems are reduced or eliminated. This is in the LFS 
spirit of escaping the host system to build a new one.

For the moment I don't think the top level makefile system is perfected, but 
building GCC and Binutils together is fairly straight foreward. With GCC-4.2 
and Binutils-2.18, Binutils' libiberty needs to be used to replace GCC's (if 
any of you want to test this).

Perhaps this is an LFS-8.0 idea, but I think it's worth discussion because 
it's how the GCC, Binutils, and GNU, projects are going towards.

robert

On Monday September 17 2007 12:20:01 am Greg Schafer wrote:
> Another thing, this has now become decidedly harder with GCC-4.2 because
> of configure arguments. ie: we now have to pass --disable-bootstrap to
> prevent the bootstrap, but configure strings get embedded into at least
> some of the executables which stuffs up binary comparisons. I might have
> to come up with some other way of comparing the builds, possibly using the
> same technique as the GCC bootstrap itself, which essentially compares
> object files in the build dirs.
>
> Regards
> Greg
> --
> http://www.diy-linux.org/




pgpciFNN2ttSG.pgp
Description: PGP signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals

[Greg Schafer]

Greg Schafer wrote:

> It all looked fine last time I tested, but I'll re-test with current
> sources and see what turns up.

Another thing, this has now become decidedly harder with GCC-4.2 because
of configure arguments. ie: we now have to pass --disable-bootstrap to
prevent the bootstrap, but configure strings get embedded into at least
some of the executables which stuffs up binary comparisons. I might have
to come up with some other way of comparing the builds, possibly using the
same technique as the GCC bootstrap itself, which essentially compares
object files in the build dirs.

Regards
Greg
-- 
http://www.diy-linux.org/

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals

[Jeremy Huntwork]

Greg Schafer wrote:
> Just to confirm, the -fomit-frame-pointer thing only applies on x86 arch.
> It all looked fine last time I tested, but I'll re-test with current
> sources and see what turns up.

Hrm. That could be it. I read the link you provided earlier, but didn't 
catch that it seemed to be x86 specific. My tests were run under a 
64-bit host as I was running through the jh branch again, so I'll have 
to retry in x86 and see if it again differs.

Thanks,

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals

[Greg Schafer]

Jeremy Huntwork wrote:

> *sigh* Are you sure you're not reading my post backwards?

Oops, sorry. I did indeed mis-read your post.

Well, if you're getting differences, you'll have to try and figure out
where they're coming from using ICA style techniques.

Just to confirm, the -fomit-frame-pointer thing only applies on x86 arch.
It all looked fine last time I tested, but I'll re-test with current
sources and see what turns up.

Regards
Greg
-- 
http://www.diy-linux.org/

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals

[Jeremy Huntwork]

Greg Schafer wrote:
> Jeremy Huntwork wrote:
> 
>> I've done a test. Hopefully I made the correct assumptions here:
>>
>> * Build as per usual up to gcc-pass2
>>
>> * Build gcc-pass2 according to instructions *execpt* do not add 
>> -fomit-frame-pointer to XCFLAGS in gcc/Makefile.in
> 
> ???
> 
> Um, you have it arse about dude. You need to *add* -fomit-frame-pointer to
> avoid differences. That's the whole point of the exercise. This was all
> explained in graphic detail here:

*sigh* Are you sure you're not reading my post backwards?

-fomit-frame-pointer *is* added by default to gcc-pass2, when we're 
*not* bootstrapping, so, the default instructions on pass2 include 
-fomit-frame-pointer and --disable-bootstrap.

To test the above against a bootstrapped build, I removed the 
-fomit-frame-pointer, (because in a bootstrap build it is there by 
default, yes?) and I removed the --disable-bootstrap flag.

The above should produce identical compilers right?

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals

[Greg Schafer]

Jeremy Huntwork wrote:

> I've done a test. Hopefully I made the correct assumptions here:
> 
> * Build as per usual up to gcc-pass2
> 
> * Build gcc-pass2 according to instructions *execpt* do not add 
> -fomit-frame-pointer to XCFLAGS in gcc/Makefile.in

???

Um, you have it arse about dude. You need to *add* -fomit-frame-pointer to
avoid differences. That's the whole point of the exercise. This was all
explained in graphic detail here:

http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg02080.html

Regards
Greg
-- 
http://www.diy-linux.org/

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: 7.0 Goals

[Jeremy Huntwork]

Greg Schafer wrote:
> The bottom line is this: the current build method works on the assumption
> that a non-bootstrapped GCC-Pass2 and Ch 6 GCC produce identical
> byte-for-byte compilers compared to what would have been produced had they
> been bootstrapped. This is a test I perform myself from time to time and
> it needs to be done every time we upgrade to a new major GCC version.

I've done a test. Hopefully I made the correct assumptions here:

* Build as per usual up to gcc-pass2

* Build gcc-pass2 according to instructions *execpt* do not add 
-fomit-frame-pointer to XCFLAGS in gcc/Makefile.in and do not use 
--disable-bootstrap. Use DESTDIR to install to $LFS/sources/gcc-bootstrap

* Clean and build gcc-pass2 exactly according to book instructions, 
meaning with -fomit-frame-pointer and --disable-bootsrap. Install to 
$LFS/sources/gcc-nobootstrap

* diff -r gcc-bootstrap gcc-nobootstrap

I'm getting differences on the binaries gcc, g++, c++ and cpp. The sizes 
are even different. I'm also getting differences on the libraries. If 
I'm testing this incorrectly, Greg, please let me know what needs to change.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [LFS Trac] #2077: Util-Linux-NG-2.13

[LFS Trac]

#2077: Util-Linux-NG-2.13
--+-
 Reporter:  [EMAIL PROTECTED]  |Owner:  [EMAIL PROTECTED]
 Type:  enhancement   |   Status:  new  

 Priority:  normal|Milestone:  7.0  

Component:  Book  |  Version:  SVN  

 Severity:  normal|   Resolution:   

 Keywords:|  
--+-
Comment (by [EMAIL PROTECTED]):

 See some similar discussion on the DIY dev list.

 http://www.diy-linux.org/pipermail/diy-linux-
 dev/2007-September/001091.html

 An important thing here is that since mount depends on either e2fsprogs or
 udev, one of them needs to be added to Ch. 5 if we want mount early in the
 chroot. There's not actually any strict reason to need mount, though,
 since we use the host's mount to setup the chroot.

-- 
Ticket URL: 
LFS Trac 
Linux From Scratch: Your Distro, Your Rules.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[LFS Trac] #2077: Util-Linux-NG-2.13

[LFS Trac]

#2077: Util-Linux-NG-2.13
--+-
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.0   
   
Component:  Book  | Version:  SVN   
   
 Severity:  normal|Keywords:
   
--+-
 Util-Linux has been under new maintainership for some time now, under the
 name of Util-Linux-NG.  A stable version, 2.13, is now out.  See
 http://www.mail-archive.com/util-linux-ng%40vger.kernel.org/msg00583.html
 for the announcement email.  The tarball is at
 ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13.  Not build or
 boot tested yet, but visual inspection shows that both of our patches can
 be dropped if this version is used.

-- 
Ticket URL: 
LFS Trac 
Linux From Scratch: Your Distro, Your Rules.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Texinfo-4.11 and binutils

[Alexander Kozlov]

Hello!

(My first post here so please excuse me if it is OT or
misconfigured)

Binutils 2.17/2.18 configure script requires texinfo
4.4 or higher to be installed. The version checking
code works for versions 4.4 through 4.9 and breaks
with texinfo 4.11:

if ${MAKEINFO} --version \
   | egrep
'texinfo[^0-9]*([1-3][0-9]|4\.[4-9]|[5-9])' >/dev/null
2>&1; then
  :
else
  MAKEINFO="$MISSING makeinfo"
fi

To allow two-digit 4.xx subversions, one could change
the search pattern in binutils-*/configure to
something like

egrep
'texinfo[^0-9]*([1-3][0-9]|4\.([4-9]|[1-9][0-9])|[5-9])'

or disable the check completely.

Regards,
Alexander Kozlov.



  ___
Sök efter kärleken!
Hitta din tvillingsjäl på Yahoo! Dejting: http://se.meetic.yahoo.net
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Choosing appropriate keymaps and fonts

[Ken Moffat]

On Sun, Sep 16, 2007 at 12:37:13PM +0100, taipan67 wrote:
> 
> The 'euro2' thing still doesn't generate a Euro symbol, so that needs 
> work. I also chose iso-8859-15 instead of iso-8859-1 in the hope of 
> getting said Euro-symbol...
> 
 That was one of the things which drove me to play with console
fonts (the other was poor coverage for what I was likely to
encounter).  Please see
http://homepage.ntlworld.com/zarniwhoop/consolefonts/sigma.html if
you want wide coverage and don't mind a font that is less bold than
the usual vga fonts.

> Ken Moffat has composed a 'uk-utf8' keymap, but the download link 
> doesn't seem to work - Ken, is there any chance of another attempt to 
> make this available?

 I don't know what the problem is with the version at lfs (I'm
assuming it's a configuration issue), but another copy is at
http://homepage.ntlworld.com/zarniwhoop/console/uk-utf.map

 For anybody arriving here from google (hey, you never know!) - this
only works with kbd, not with console-tools.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)

[Jeremy Huntwork]

Greg Schafer wrote:
> One of the downsides of using `-march=' by itself is that it implies
> `-mtune='. Therefore you have just tuned your libc for i486. Not good.

The upgrade to Glibc is in place, which was my only intention for 
yesterday. Now that it is in place, the community can discuss what it 
wants to do for -mtune.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Choosing appropriate keymaps and fonts

[Alexander E. Patrakov]

Matthew Burgess wrote:
> Thanks for the information, Alexander.  Where are the newer version of kbd 
> being maintained?  I'll try and get around to making a patch along the lines 
> of what you posted above.  It might be wise to find an example of a non-UTF-8 
> keymap that is present in both kbd-1.12 and the latest upstream sources, so 
> that it's one less thing to update when the new version is released.
>   

Maybe French (with Euro)?

# Begin /etc/sysconfig/console

UNICODE="1"
KEYMAP="fr-latin9"
LEGACY_CHARSET="iso-8859-15"
BROKEN_COMPOSE=0
FONT="lat0-16"

# End /etc/sysconfig/console

While verifying this, I also found that BROKEN_COMPOSE=0 is needed but 
it is not a documented option (a candidate for the errata). Please add 
the following to the errata page:

"The BROKEN_COMPOSE option for the /etc/sysconfig/console file is not 
documented, although it is necessary in some setups. The console 
bootscript, by default, assumes that composing and dead keys are broken 
in the UTF-8 keyboard mode, and clears the composition table in this 
mode. To stop it from doing this, add BROKEN_COMPOSE=0 to 
/etc/sysconfig/console. Note that composing and dead keys are indeed 
broken in UTF-8 keyboard mode if the keymap attempts to produce 
characters outside the Latin-1 range by this method."

Please also decide what to do with this default in the SVN book. Maybe 
drop the BROKEN_COMPOSE logic completely from the bootscript, even 
though this means that e.g. Czech keymap starts producing wrong 
characters instead of nothing when one tries to use dead keys? It worked 
with LFS-6.2, BTW, and the removal of the kernel patch was in fact a 
test whether the community would scream or LFS developers would notice a 
wrong step (thus confirming that they understand the issue). Neither 
happened. Sorry for announcing my sabotage attempt too late.

And BTW, the Polish example in the book is wrong (replace the "lat2a-16" 
font with "lat2-16" because of the wrong screen font map) - sorry for 
this mistake.

>
> So, in a UTF-8 environment, I don't need to supply a '-m' switch, correct?  
> That seems to be what the following suggests, as well (running an unpatched 
> 2.6.22.6 kernel here).
>   

Correct - but it will be needed with the 2.6.23-rc6 kernel, because the 
same patch as in LFS-6.2 got applied, and the argument of this switch is 
used for conversion of dead keys (and Czech works with UTF-8, BTW).

As for the kbd-1.13 URL, here it is: 
ftp://ftp.altlinux.org/pub/people/legion/kbd/kbd-1.13.tar.bz2

-- 
Alexander E. Patrakov
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Which list for Ticket reports?

[Jeremy Huntwork]

M.Canales.es wrote:
> El Sábado, 15 de Septiembre de 2007 22:17, Jeremy Huntwork escribió:
> 
>> Well, let's try this out then. If people scream we can change it back.
>>
> 
> I don't care about to what list the ticket posts are send, but please, send 
> it 
> to only one of them.

The reason it is going to both is because 'lfs-book' is listed in the 
owner field for default tickets, and existing tickets send updates to 
all emails gleaned in the tickets.

As I said, I can change it back if everyone hates it.

--
JH


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Choosing appropriate keymaps and fonts

[Matthew Burgess]

On Sun, 16 Sep 2007 16:47:01 +0600, "Alexander E. Patrakov" <[EMAIL PROTECTED]> 
wrote:
> Matthew Burgess wrote:
>
>> I think what is needed here is to look in /lib/kbd/consoletrans and pick
> a suitable [charset]_to_uni.trans file.
> 
> No, the character sets for converting the keymaps are built into the
> "dumpkeys" program, and the full list is available in the "dumpkeys
> --help" output.

Thanks, I realised that once I tried booting with that incorrect setting.
 
>> "There is no pre-made UTF-8 Russian keyamp, therefore it has to be
> produced by converting the existing KOI8-R character set as illustrated
> below (available non-Unicode to Unicode character set mappings are
> available in /lib/kbd/consoletrans):"
>>
> 
> No. Maybe: "There is no pre-made UTF-8 Russian keyamp, therefore it has
> to be produced by converting the existing KOI8-R keymap as illustrated
> below. Correct spelling for source character set names for the
> LEGACY_CHARSET option are available in the dumpkeys --help output."
> 
> Or maybe move the "Correct spelling..." sentence to the description of
> the LEGACY_CHARSET option description.
> 
> Basically, the reader has to know that the existing Russian keymap is
> for KOI8-R users, and that the correct spelling of this character set
> name for dumpkeys is "koi8-r".
>
> And BTW, the next version of kbd does have a UTF-8 Russian keymap (as
> "ru"), so we may need another example.

Thanks for the information, Alexander.  Where are the newer version of kbd 
being maintained?  I'll try and get around to making a patch along the lines of 
what you posted above.  It might be wise to find an example of a non-UTF-8 
keymap that is present in both kbd-1.12 and the latest upstream sources, so 
that it's one less thing to update when the new version is released.
 
>> Similarly, for fonts, how do I determine which ones are UTF-8 capable
> and what flags I need to pass to setfont, via the FONT variable, so that it
> will display correctly?
>>
> 
> All *.psfu.gz fonts are supposed to be displayed correctly, because
> every font has the screen font map in it that maps font positions to
> Unicode

So, in a UTF-8 environment, I don't need to supply a '-m' switch, correct?  
That seems to be what the following suggests, as well (running an unpatched 
2.6.22.6 kernel here).

> FONT="lat1-16 -m 8859-1"   # Suboptimal - no Euro sign, and the -m
> option was used only by the patched 2.6.16 kernel in LFS-6.2 (for dead
> keys and composing)

Thanks,

Matt.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Choosing appropriate keymaps and fonts

[Alexander E. Patrakov]

taipan67 wrote:
> The 'euro2' thing still doesn't generate a Euro symbol,
>   

That's why:

> FONT="LatArCyrHeb-16"
>   

It does not contain the Euro sign. Use the "lat0-16" font instead.

-- 
Alexander E. Patrakov
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Choosing appropriate keymaps and fonts

[taipan67]

Matthew Burgess wrote:
> Hi,
>
> How does one go about choosing the correct keymaps and fonts for their 
> system?  I've read over chapter07/console.html several times but still have a 
> couple of questions.
>
> What I'm trying to do is configure a system to have a UK keymap and have a 
> UTF-8 capable console.
>
>   
This is what i have at the moment to achieve the same objective :-

UNICODE="1"
KEYMAP="uk"
KEYMAP_CORRECTIONS="euro2 windowkeys"
LEGACY_CHARSET="iso-8859-15"
FONT="LatArCyrHeb-16"

The 'euro2' thing still doesn't generate a Euro symbol, so that needs 
work. I also chose iso-8859-15 instead of iso-8859-1 in the hope of 
getting said Euro-symbol...

Ken Moffat has composed a 'uk-utf8' keymap, but the download link 
doesn't seem to work - Ken, is there any chance of another attempt to 
make this available?
> Similarly, for fonts, how do I determine which ones are UTF-8 capable and 
> what flags I need to pass to setfont, via the FONT variable, so that it will 
> display correctly?
>
> Thanks,
>
> Matt.
>
>   
As Alexander said, fonts with a 'psfu' suffix are supposed to be 
unicode-compatible.

Hope that helps, taipan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Choosing appropriate keymaps and fonts

[Alexander E. Patrakov]

Matthew Burgess wrote:
> Hi,
>
> How does one go about choosing the correct keymaps and fonts for their 
> system?  I've read over chapter07/console.html several times but still have a 
> couple of questions.
>
> What I'm trying to do is configure a system to have a UK keymap and have a 
> UTF-8 capable console.  So far, I've got:
>
> UNICODE="1"
> KEYMAP="uk"
>
> However, as you'll note, unlike the Belgian keymap mentioned in the book, the 
> UK keymap doesn't have a UTF-8 variant.  I'm told I need to choose a 
> LEGACY_CHARSET so that the bootscript will convert it to UTF-8 on the fly.  
> The example for the ru_ms keymap is to convert the KOI8-R keymap, but I can't 
> find any such keymap on my system.
>
> I think what is needed here is to look in /lib/kbd/consoletrans and pick a 
> suitable [charset]_to_uni.trans file.

No, the character sets for converting the keymaps are built into the 
"dumpkeys" program, and the full list is available in the "dumpkeys 
--help" output.

>   So, I think I need '8859-1' in my LEGACY_CHARSET variable, right?
>   

No, iso-8859-1.

> If the above is correct, I think the following change might be suitable for 
> the book:
>
> "There is no pre-made UTF-8 Russian keyamp, therefore it has to be produced 
> by converting the existing KOI8-R keymap as illustrated below:"
>
> becomes
>
> "There is no pre-made UTF-8 Russian keyamp, therefore it has to be produced 
> by converting the existing KOI8-R character set as illustrated below 
> (available non-Unicode to Unicode character set mappings are available in 
> /lib/kbd/consoletrans):"
>   

No. Maybe: "There is no pre-made UTF-8 Russian keyamp, therefore it has 
to be produced by converting the existing KOI8-R keymap as illustrated 
below. Correct spelling for source character set names for the 
LEGACY_CHARSET option are available in the dumpkeys --help output."

Or maybe move the "Correct spelling..." sentence to the description of 
the LEGACY_CHARSET option description.

Basically, the reader has to know that the existing Russian keymap is 
for KOI8-R users, and that the correct spelling of this character set 
name for dumpkeys is "koi8-r".

And BTW, the next version of kbd does have a UTF-8 Russian keymap (as 
"ru"), so we may need another example.

> Similarly, for fonts, how do I determine which ones are UTF-8 capable and 
> what flags I need to pass to setfont, via the FONT variable, so that it will 
> display correctly?
>   

All *.psfu.gz fonts are supposed to be displayed correctly, because 
every font has the screen font map in it that maps font positions to 
Unicode (and in non-UTF-8 environments, the application charset map, 
supploed via the -m switch, also matters - it maps application output 
bytes to Unicode). However, there are a few fonts with a wrong screen 
font map, e.g. lat2a-16.

The LiveCD defaults to the following for en_GB.UTF-8:

KEYMAP="uk"
UNICODE=1
BROKEN_COMPOSE=0
FONT="lat1-16 -m 8859-1"   # Suboptimal - no Euro sign, and the -m 
option was used only by the patched 2.6.16 kernel in LFS-6.2 (for dead 
keys and composing)
LEGACY_CGARSET="iso-8859-1"

-- 
Alexander E. Patrakov
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Choosing appropriate keymaps and fonts

[Matthew Burgess]

Hi,

How does one go about choosing the correct keymaps and fonts for their system?  
I've read over chapter07/console.html several times but still have a couple of 
questions.

What I'm trying to do is configure a system to have a UK keymap and have a 
UTF-8 capable console.  So far, I've got:

UNICODE="1"
KEYMAP="uk"

However, as you'll note, unlike the Belgian keymap mentioned in the book, the 
UK keymap doesn't have a UTF-8 variant.  I'm told I need to choose a 
LEGACY_CHARSET so that the bootscript will convert it to UTF-8 on the fly.  The 
example for the ru_ms keymap is to convert the KOI8-R keymap, but I can't find 
any such keymap on my system.

I think what is needed here is to look in /lib/kbd/consoletrans and pick a 
suitable [charset]_to_uni.trans file.  So, I think I need '8859-1' in my 
LEGACY_CHARSET variable, right?

If the above is correct, I think the following change might be suitable for the 
book:

"There is no pre-made UTF-8 Russian keyamp, therefore it has to be produced by 
converting the existing KOI8-R keymap as illustrated below:"

becomes

"There is no pre-made UTF-8 Russian keyamp, therefore it has to be produced by 
converting the existing KOI8-R character set as illustrated below (available 
non-Unicode to Unicode character set mappings are available in 
/lib/kbd/consoletrans):"

Similarly, for fonts, how do I determine which ones are UTF-8 capable and what 
flags I need to pass to setfont, via the FONT variable, so that it will display 
correctly?

Thanks,

Matt.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [LFS Trac] #2076: Inconsistent permissions for floppy devices

[LFS Trac]

#2076: Inconsistent permissions for floppy devices
+---
 Reporter:  [EMAIL PROTECTED]  |Owner:  [EMAIL PROTECTED]
 Type:  task|   Status:  new
  
 Priority:  normal  |Milestone:  7.0
  
Component:  Book|  Version:  6.3
  
 Severity:  normal  |   Resolution: 
  
 Keywords:  |  
+---
Comment (by [EMAIL PROTECTED]):

 Or better, remove "-M 0640".

-- 
Ticket URL: 
LFS Trac 
Linux From Scratch: Your Distro, Your Rules.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[LFS Trac] #2076: Inconsistent permissions for floppy devices

[LFS Trac]

#2076: Inconsistent permissions for floppy devices
+---
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  task|  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0 
 
Component:  Book| Version:  6.3 
 
 Severity:  normal  |Keywords:  
 
+---
 /dev/fd0 has mode 0660, while /dev/fd0u1440 has mode 0640. Please change
 the create_floppy_devices udev rule by changing 0640 to 0660.

-- 
Ticket URL: 
LFS Trac 
Linux From Scratch: Your Distro, Your Rules.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Which list for Ticket reports?

[J. Greenlees]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

M.Canales.es wrote:
~snip~

> I don't care about to what list the ticket posts are send, but please, send 
> it 
> to only one of them.
> 

I agree, but also the cross posting that people do can be problematical.
Since some people use the To and CC fields interchangeably it seems, it
took a month of work to get filters to sort messages correctly for all
the lists. [ which I lost when the athlon xp system crashed a month ago.
:( ]


Jaqui

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7QDjylMakk+oQ1oRAoOXAJ43XmniazbgYdC0ikB3kQhrkEWypwCfRTkb
31z5djG8G2LAZXrziNdvLWk=
=ZdgF
-END PGP SIGNATURE-
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Which list for Ticket reports?

[M.Canales.es]

El Sábado, 15 de Septiembre de 2007 22:17, Jeremy Huntwork escribió:

>
> Well, let's try this out then. If people scream we can change it back.
>

I don't care about to what list the ticket posts are send, but please, send it 
to only one of them.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:   http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:   http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Which list for Ticket reports?

[TheOldFellow]

On Sat, 15 Sep 2007 16:17:41 -0400
Jeremy Huntwork <[EMAIL PROTECTED]> wrote:

> Well, let's try this out then. If people scream we can change it back.

Can't say I like it much.  It makes the list messy to read.  I think
it's just a change for changes sake, and we've had the other way for
years without problems.

There are many of us who follow the Dev list without needing to know the
fine detail - which is what the Book list is for.  It's easy to start a
discussion here when you do need it.

--
R.
Any apparent mistakes in this email are potentially deliberate.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Updates to the book

[M.Canales.es]

El Miércoles, 12 de Septiembre de 2007 19:33, Chris Staub escribió:
> Attached should be a patch to add ncurses5-config to the Ncurses program
> list, and several grammar/spelling fixes.

Applied on r8385, thanks :-)

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:   http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:   http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[LFS Trac] #2075: LFS mentions old version of French manual pages

[LFS Trac]

#2075: LFS mentions old version of French manual pages
+---
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  enhancement |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0 
 
Component:  Book| Version:  6.3 
 
 Severity:  normal  |Keywords:  
 
+---
 http://www.linuxfromscratch.org/lfs/view/6.3/chapter06/man-db.html uses
 http://ccb.club.fr/man/man-fr-1.58.0.tar.bz2 as an example of manual pages
 that can be copied to /usr/share/man/''language_code'' unchanged. However,
 this is a very old version of French manual pages. Newer French manual
 pages are available at http://manpagesfr.free.fr/download/man-pages-
 fr-2.40.0.tar.bz2, but they are in UTF-8.

 I propose to use updated French manual pages as an example of what should
 be done with UTF-8 manual pages, instead of the current Spanish example.
 The benefit is that a workaround for a packaging bug is not needed,
 because there is no packaging bug.

 German manual pages from http://www.infodrom.org/projects/manpages-
 de/download/manpages-de-0.5.tar.gz can be used as an example of manual
 pages that can be just copied.

-- 
Ticket URL: 
LFS Trac 
Linux From Scratch: Your Distro, Your Rules.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page