Re: UTF-8 book is ready for merging
Bryan Kadzban пишет: Just after a stream is associated with a pipe by the popen() function, the stream is byte-oriented. Where is that quoted from? http://docs.hp.com/en/B9106-90012/orientation.5.html This is for HP-UX, but it's true for glibc to. I was not aware that there was a difference between byte-oriented and wide-oriented streams. I thought getwc did the conversion between LC_CTYPE charset and wide-char itself, though I see the getwc manpage only says that it is reasonable to expect this in the absence of additional information passed to the fopen call. This Debian i18n page seems to imply that it should work (see 6.3), and it's what I was going from: http://www.debian.org/doc/manuals/intro-i18n/ch-locale.en.html getwc() crashes application on byte-oriented stream. Some info can be found in glibc manual: http://www.gnu.org/software/libc/manual/html_node/Streams-and-I18N.html But if there is a difference, then the iconv sample on that page (see 6.5) could be a better choice than hardcoding the UTF-8 conversion, and (therefore) only working in a UTF-8 charset environment. Sorry for that, i'm not a C programmer :) (Plus, you don't know what the user will set LC_CTYPE to; it might be utf8, it might be utf-8, it might be UTF8, and any of these will break the patch.) Standard recomends using UTF-8. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Can ncurses be removed from Chapter 5?
On 1/2/06, Richard A Downing [EMAIL PROTECTED] wrote: On Mon, 02 Jan 2006 15:51:01 -0500 Chris Staub [EMAIL PROTECTED] wrote: I'm just looking for ways to reduce the temp-system in /tools as much as possible. I can see a point to removing packages from the chapter 5 build if it doesn't cause problems later As someone who is currently running a set of tests on this branch, I would say I generally agree with Richard. Furthermore, removing packages from /tools will probably give you a subtly lower quality end product. Most of the packages in /tools are only there to satisfy dependencies of Ch. 6. Not just, remove x and you can't build y, but remove x and you will end up with a different y than before. This is one thing ICA highlights. In fact, I'm really close to proposing adding more packages to /tools. I just need some more ammunition before I try to slay that beast. In the case of ncurses and util-linux, I would say that I could deal with losing some functionality in early Ch. 6, but I'd need to see some evidence that removing ncurses didn't the alter final product. Anyway, keep up the good work, Chris. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Alphabetical ICA/Farce Results
On 1/2/06, Greg Schafer [EMAIL PROTECTED] wrote: Looks pretty good. I'm pretty sure you'll find perl, vim and nscd are different due to timestamps embedded into the binaries. You can easily confirm this by using `strings' and `diff' eg: strings cmp/iter1/*/nscd 1 strings cmp/iter2/*/nscd 2 diff 1 2 I'll check these guys out sometime in the next few days. On the other hand, bison is a problem which must be explained. I don't see bison differences in the DIY build. This is where keeping the build and/or src dirs is valuable in finding the root cause. I've got a pretty good inkling what the issue is here. DIY builds bison and flex in temptools. LFS doesn't. I moved up flex before bison because bison will use flex if it's there, but I think there's some circular dependency stuff that's only gonna be solved if at lease bison is added to /tools. For evidence, here's a diff of the build logs between iter1 and iter2 for bison: --- iter1/bison-2.1.log 2005-12-29 11:50:40.0 -0800 +++ iter2/bison-2.1.log 2005-12-29 13:28:54.0 -0800 @@ -79,8 +79,7 @@ checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes -checking for bison... no -checking for byacc... no +checking for bison... bison -y checking for ranlib... ranlib checking for gm4... no checking for gnum4... no One last thing, forget about .gch differences. The nature of PCH where it tries to map a data file into a suitable memory region within the OS's VM will always end up random. Thanks for the info. I was basically ignoring all the stdc++ and gch stuff under the guess that there was some random phenomena involved. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LONG] Commentary and policy text in the UTF-8 patch
On 12/31/05, Jeremy Huntwork [EMAIL PROTECTED] wrote: Dan, Can you do me a favor and create a bug for this in bugzilla please? Also, if you could create a patch for the LFS book, it would make it even easier to get it in. ;) OK, there's now a bug: http://bugs.linuxfromscratch.org/show_bug.cgi?id=1675 Please take a look at the bug. I'm leaning towards Greg's solution because it's the most accurate, but there's a minor drawback of assuming the dynamic linker is named ld-linux.so.2. After a couple people comment, I'll make a patch to the book. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 (not really) / IOCharSet/ CodePage
Randy McMurchy wrote: And I've now probably pissed him off so badly that I won't get his full attention to this message. However, in hopes that he'll provide what I need here, I think we can put all these differences behind us. No offence taken at all, and no need to say sorry. It's just housework that does take time, and relatives that ask me to do useful things right now instead of sitting in front of the computer. And the conference on physics, for which I must obtain some results before it starts. 1) First, tell me how I can check the iocharset setting of a mounted device. Please know that I am in a default EN/en locale and don't have a clue how to check for other locales. The check is easy, cat /proc/mounts. This lists iocharset and codepage for FAT volumes even if you didn't specify them explictly. Ther real problem is to prove that they came from HAL, not from the kernel defaults. As you indicated further, you are going to do this by switching iocharset and codepage to some non-default value. 2) The iocharset in #1 must not have a bearing on what codepage I may have set (I do understand this is only relevant on older DOS filesystems) iocharset and codepage are set completely independently of each other. Any combination is accepted by the kernel, even if that doesn't make much sense. iocharset is used for conversion between the encoding the user sees (indicated by the value of this parameter) and UCS-2 (as used on disk for long names). codepage is used only for short names understandable by DOS. 3) The default iocharset/codepage settings on mounted devices are normal for me (iso8859-1 and 437). I do not know what to look for if I change them. This is important for the next items. If you are lazy, cat /proc/mounts. That gives a definite answer and is sufficient to determine that the setup works. If you are not lazy, cat /proc/mounts and read further. I want you to create a ru_RU.KOI8-R Linux setup (LFS-6.0 or later works fine, no need for the UTF-8 patch). That's in fact very simple: 0) For the X Window System, install Microsoft fonts (http://corefonts.sf.net/) or DejaVu fonts (http://dejavu.sf.net/) and read this mail again, using KMail or Thunderbird. Then, recompile your kernel if you don't have support for CP866, CP437, ISO8859-1 and KOI8-R iocharsets (modules are OK). CONFIG_NLS=y CONFIG_NLS_DEFAULT=cp437 # the default CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_KOI8_R=m 1) In /etc/sysconfig/console, put: KEYMAP=ru-ms FONT=cyr-sun16 -m koi8-r 2) In /etc/profile or /etc/profile.d/i18n, put: export LANG=ru_RU.KOI8-R # Randy doesn't speak Russian and wants to see English messages export LC_MESSAGES=C export [EMAIL PROTECTED] 3) In xorg.conf, the keyboard-related section should look like this: Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us,ru(winkeys) Option XkbOptionsgrp:alt_shift_toggle,grp_led:scroll EndSection 4) Reboot into runlevel 3, then run startx if you really want that now (note: I don't say run kdm because I am not really sure if it sets locale-related variables properly). Run the date command, the screenshot of the correct output is attached (you want to look at the month abbreviation, Янв). To input Rusian characters in the Linux console, press and release the right Ctrl key, then type something. Then press and release the right Ctrl key again to switch back to Latin layout. In X, the combination Alt+Shift switches between Latin and Cyrillic layouts, try that too. Then create a Russian MS-DOS setup by taking a Win95 OSR2 or Win98 boot floppy and modifying the system startup files. Be sure that the line endings are DOS (CR+LF), not UNIX (CR). 1) In config.sys, put: device=display.sys con=(ega,,1) country=007,866,country.sys DEVICE=HIMEM.SYS 2) In autoexec.bat, put: mode con cp prepare=((866) ega3.cpi) mode con cp select=866 keyb ru,,keybrd3.sys In DOS, the way to switch between Latin and Cyrillic layouts is different. RightShift + RightCtrl switches to Cyrillic, LeftShift + LeftCtrl back to Latin. Then make another floppy containing the file named ФАЙЛ.TXT (compressed image attached, bzcat rusfile.flp.bz2 /dev/fd0). If you want instructions how to create this floppy from scratch with Win2K (even with the English version), say so. 4) I want to set the iocharset of a mounted device to something other than my default, and see if it works. Insert a floppy with the Russian file, then, as root: mount -t vfat -o iocharset=koi8r,codepage=866 /dev/fd0 /media/floppy ls /media/floppy # should print: ФАЙЛ.TXT cat /proc/mounts umount /media/floppy Then try without the iocharset option and see .TXT instead of ФАЙЛ.TXT. 5) I then want to test an older DOS
Re: UTF-8 book is ready for merging
Pasha Zubkov wrote: Standard recomends using UTF-8. where? which standard? If LSB or openi18n aka li18nux2000, I don't count that because their sample implementation misbehaves. As for the patch, I will not accept anything that cotnatis the if utf-8 part. Use mbrtowc() to assemble bytes to wide characters in all locales. If you want, I will do this for you the day after tomorrow (I am rather busy now). -- Alexander E. Patrakov Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11 Use my GMail or linuxfromscratch address instead -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LONG] Commentary and policy text in the UTF-8 patch
On Tue, Jan 03, 2006 at 07:23:20AM -0800, Dan Nicholson wrote: OK, there's now a bug: http://bugs.linuxfromscratch.org/show_bug.cgi?id=1675 Please take a look at the bug. I'm leaning towards Greg's solution because it's the most accurate, but there's a minor drawback of assuming the dynamic linker is named ld-linux.so.2. After a couple people comment, I'll make a patch to the book. Thanks, Dan. I've been away on vacation for the past week and a half, which is why my emails have been so sparse and brief. I'll be arriving home today, so within the next day or two, I should be able to review all the work you've done. :) Thanks, -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 book is ready for merging
On Tue, Jan 03, 2006 at 03:13:52PM +0200, Pasha Zubkov wrote: Where is that quoted from? http://docs.hp.com/en/B9106-90012/orientation.5.html This is for HP-UX, but it's true for glibc to. Ah. Between this and your glibc link below, I'll agree with you -- fgetwc or getwc on a popen()ed stream won't work right. But I wonder if you can freopen() a popen()ed stream? If so, you could first freopen() it, then fwide() the new stream; then you'd get automatic handling of any locale. But if there is a difference, then the iconv sample on that page (see 6.5) could be a better choice than hardcoding the UTF-8 conversion, and (therefore) only working in a UTF-8 charset environment. Sorry for that, i'm not a C programmer :) :-) (Plus, you don't know what the user will set LC_CTYPE to; it might be utf8, it might be utf-8, it might be UTF8, and any of these will break the patch.) Standard recomends using UTF-8. Yes, but we've had some issues before when people don't -- I believe it was with some X programs. They hardcoded either LC_MESSAGES or LC_CTYPE values, and subsequently broke when someone used a different string than what they were expecting. Or something like that. Hardcoding the value for LC_CTYPE or LC_MESSAGES is *never* a good idea. Just let iconv() handle LC_CTYPE for you, and let gettext() handle LC_MESSAGES. (Yes, you have to use nl_langinfo() to get a string to pass to iconv_open -- but I believe anything that nl_langinfo returns is supposed to be valid for iconv_open.) pgpnreA7cyCSn.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Can ncurses be removed from Chapter 5?
Chris Staub [EMAIL PROTECTED] writes: I'm just looking for ways to reduce the temp-system in /tools as much as possible. I've built LFS systems before without having ncurses there and it works fine. I believe the only issue is texinfo - many programs in chapter 6 need it to build their info pages, but I believe they only need the makeinfo program, which doesn't require ncurses. Of course I'm testing this myself, but I was wondering if anyone else had any opinions. As I remember the ncurses package is the place were terminfo database live. Are you realy not need the terminfo when you chrooted in chap. 6? Note: this would also necessitate removing more from the chap. 5 util-linux, but AFAIK nothing in chap. 6 needs it - it's just there for the user's convenience (though I never need it myself). I hate more --- I prefer less instead. and for now bash use more when completion list not fit at the screen... (or it use pager, listed in the enviroment?). I dont know is this a right behavior (becouse this need addition key pressing)... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 book is ready for merging
Bryan Kadzban wrote: (Yes, you have to use nl_langinfo() to get a string to pass to iconv_open and if the destination is the internal representation of wchar_t, that's called mbrtowc() :) -- Alexander E. Patrakov Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11 Use my GMail or linuxfromscratch address instead -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management
Tushar Teredesai wrote: On 12/29/05, Randy McMurchy [EMAIL PROTECTED] wrote: Yes, that is probably best. As has been said by everyone, package management is something that needs to be implemented at the beginning of Chapter 6 in LFS. I think everyone is in agreement there. Can someone bugzilla this so that it is not forgotten? I went to our bugzilla to add this if no one else had already. Guess what quips.cgi decided to pull up for the quote? Package managers are for wimps! -Archaic -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
zlib patch
Sometime back I added a patch to the patches repository that adds -fPIC to the compiler flags when compiling shared library. Additionally it allows building the shared and static library in a single pass. See: http://www.linuxfromscratch.org/patches/downloads/zlib/zlib-1.2.2-fPIC-1.patch. Though the patch is for 1.2.2 it also applies to 1.2.3. The installation instructions are: ./configure --prefix=/usr --shared make make install Should the patch be added to the book? -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
