Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Jeremy Huntwork wrote: echo CFLAGS += -march=i686 configparms snip Everything went smoothly, so unless anyone has any objections, this is the method I'll be dropping in, except using i486, of course. I won't commit for the next hour or so, however, so that will give at least some time for other comments or objections. 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. As mentioned previously, GCC-4.2.x tunes for `-mtune=generic' by default. That means, at least for the Ch 6 Glibc, you really should be using these CFLAGS -march=i486 -mtune=generic. I will be adding something similar to DIY soon (but slightly more complicated due to multiple version support). 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
[LFS Trac] #2075: LFS mentions old version of French manual pages
#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: http://wiki.linuxfromscratch.org/lfs/ticket/2075 LFS Trac http://wiki.linuxfromscratch.org/lfs/ 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: Updates to the book
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
Re: Which list for Ticket reports?
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: Which list for Ticket reports?
-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
[LFS Trac] #2076: Inconsistent permissions for floppy devices
#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: http://wiki.linuxfromscratch.org/lfs/ticket/2076 LFS Trac http://wiki.linuxfromscratch.org/lfs/ 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: [LFS Trac] #2076: Inconsistent permissions for floppy devices
#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: http://wiki.linuxfromscratch.org/lfs/ticket/2076#comment:1 LFS Trac http://wiki.linuxfromscratch.org/lfs/ 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
Choosing appropriate keymaps and fonts
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: Choosing appropriate keymaps and fonts
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
Re: Choosing appropriate keymaps and fonts
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
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
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: Which list for Ticket reports?
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 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: --with-arch=i486 (was Re: Merging the jh branch to trunk)
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: 7.0 Goals (top level bootstrap)
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
