Re: Managed hotplug events
(sorry, something is wrong again with the news server, thus the private CC:) Matthew Burgess wrote: Alexander E. Patrakov wrote: When the modified udev bootscript sets /sbin/udevsend as a handler, everything is ready. I thought the necessary changes had already got into the bootscripts repository. If not, please submit a bug report to bugzilla, preferably with a patch too. You are right, most of changes are already done. What remains is reported at: http://bugs.linuxfromscratch.org/show_bug.cgi?id=1068 -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch, /etc/profile locale specification
Matthew Burgess wrote: Alexander E. Patrakov wrote: So it's better to change the book to say ISO-8859-1. Easy enough to do, added to my (ever growing) TODO for 6.1. Also some people say it's better to remove LC_ALL (i.e. set only LANG) and I tend to agree with them now. Please do that before LFS 6.1 comes out. But then according to your post titled [POST-6.1] Console script with UTF-8 support you state: Don't forget to set LANG and LC_ALL properly in /etc/profile. So, which is it to be? only LANG. I added LC_ALL to that statement only on the basis of its presence in the book at that moment. The situation is: 1) LANG that sets the default for all locale categories but can be overridden 2) LC_CTYPE, LC_MESSAGES, ... override LANG for their respective locale categories 3) LC_ALL overrides every other locale variable So setting LC_ALL by default is harmless, but it generates questions like I want proper character classification, but still English messages. I have tried setting LC_MESSAGES to C but that doesn't work. The answer is that he has to unset LC_ALL. Sorry for that confusion. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2 potentially 6.1 related questions
Matthew Burgess wrote: Hi folks, In both sets of grep's instructions we use the '--with-included-regex' to prevent grep from using potentially buggy regex code from glibc. Now, I can understand this in chapter 5 where the host's glibc can't be guaranteed to work. However, in chapter 6 we have a known version of glibc. The question is, does anyone know whether recent versions of glibc still have the buggy regex code, and how can we test/verify it (is running grep's own testsuite enough to spot any problems)? The testsuite passes in both cases (LFS 6.0), but that means absolutely nothing. As you can see, the testsuite has one test commented out because it would take infinite time to finish with glibc regex (uclibc apparently doesn't have that bug -- but that information is not verified by me, just copied from Gentoo's ebuild). In both cases, grep also suffers from the -o and -i options together don't work bug. Distros apply a patch against this bug, but they don't notice that the patch in fact doesn't help :( Testcase (fails even with the patch): echo aABb | grep -o -i ab One of the variants of this non-working patch is located at: http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-apps/grep/files/grep-2.5.1-oi.patch.bz2?rev=1.1 BTW I think someone (maybe myself, but that would be slow) should investigate the way distros build grep. Gentoo applies just too many patches so one can't seriously consider the grep package trouble-free. At least one patch has to be added (maybe post-6.1) for eliminating important UTF-8 bug: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/grep/files/2.5.1-utf8-case.patch?rev=1.1 -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch, /etc/profile locale specification
Alexander E. Patrakov wrote: Matthew Burgess wrote: Alexander E. Patrakov wrote: So it's better to change the book to say ISO-8859-1. Hmm, but as Ken pointed out, 'locale -a' (which we point out on that same page) lists 'en_GB.iso88591', so I've a feeling us setting it to 'ISO-8859-1' may just confuse folks. If there's stuff out there that incorrectly expects something else, it needs reporting as a bug IMO. So, are there any compelling reasons for us not setting it to 'en_GB.iso88591'? Nothing wrong with it now (when UTF-8 is not supported), as long as we mention that en_GB.iso88591 and en_GB.ISO-8859-1 are synonims (so that people see both forms). But when we add support for UTF-8, we will have to say that en_GB.UTF-8 is the only correct variant (en_GB.utf8 confuses at least ncurses). Found a better solution (but please reword so that I know that you understand it). The list of all locales supported by Glibc can be obtained by running the following command: locale -a Locale names returned by that command (like en_GB.iso88591) are recognized by Glibc, but some applications may require different spelling of the character encoding name. To find out the canonical name of the character encoding, execute the command like the one below: LC_ALL=en_GB.iso88591 locale charmap It will print: ISO-8859-1. Therefore, the preferred name of that locale is en_GB.ISO-8859-1. Glibc treats that as a synonim for en_GB.iso88591. There is, however, one more issue I want to have fixed. On glibc page, we have two variants of locale installation commands: one is make localedata/install-locales, the other is a series of localedef commands. I want to express the fact that the second variant is the preferred one if the reader knows exactly the list of locales he needs. The reason is the unfixed portion of http://blfs-bugs.linuxfromscratch.org/show_bug.cgi?id=909 -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
gettext nitpick
gettext 0.14.4 requires creation of one more locale on glibc page checking for a traditional french locale... fr_FR checking for a french Unicode locale... fr_FR.UTF-8 -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gettext nitpick
Matthew Burgess wrote: Alexander E. Patrakov wrote: gettext 0.14.4 requires creation of one more locale on glibc page I took a quick look at the configure script and couldn't determin what effects having those 2 locales has, i.e. what features of gettext rely on those locales. I'm assuming it's just some tests, but I'd love to know for sure. Yes, that's just tests. Every test is executed (internally) twice if it is locale-sensitive. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[POST-6.1] translated output of bootscripts
Hello, a tarball of translated bootscripts matching the latest SVN official LFS bootscripts is available at: http://ums.usu.ru/~patrakov/iLFS-bootscripts-20050424.tar.gz For English speakers, it's a drop-in replacement with identical functionality. Installation: make -C po make install make -C po install Differences from the official bootscripts: 1) UTF-8 support on console. For details, see: http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-April/050987.html UNICODE=1 is incompatible with non-bash as /bin/sh - but UTF-8 users won't use other shells anyway since they are incompatible with UTF-8 by themselves. Text wrapping works in UTF-8 in the same degree as with ASCII, i.e. is as broken even on pure ASCII messages as it is in the original bootscripts. Testcase: add an exit 1 bootscript that triggers the you should not see this error message and look at the incorrect wrapping in English locale. Note that the LFS book is not 100% compatible with UTF-8, e.g. some known important bugfixes are missing from grep and awk and the ncurses library is compiled in such a way that it doesn't understand UTF-8. 2) Russian and Spanish translations (thanks Manuel). To see Russian translation: in /etc/sysconfig/console, uncomment Russian section in /etc/sysconfig/rc, add the following line: LANG=ru_RU.KOI8-R 3) Possibility to add a translation to your language. It's not that hard, only 107 messages to translate. To do that: cd po make msginit vim your_language.po make add your LANG line to /etc/sysconfig/rc, reboot the system for testing mail your_language.po file to me or to lfs-dev Possible future improvements: 1) Move the console startup link to S15console. This would show more translated messages, but would also require recompilation of kbd-1.12 in order to move keymaps and screen fonts to /lib/kbd. 2) Translate BLFS bootscripts also. Will do that after discussion of translated LFS bootscripts. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Text wrapping bug in bootscripts (on plain ASCII)
James Robertson wrote:
I usually run frame buffer consoles at
1024x768 or larger and hate it when a message comes up formated for a
80x25 console - ugh.
On the other hand, I have trouble following long lines (more than, say,
90 characters) after reading thoughts of Donald Knuth on the optimal
line length (he says 66 characters). Anyway, if you can fix the
function, you are welcome. Allowed assumptions:
You can even make an assumption that all characters are one cell wide,
because the plain linux console assumes the same. However, you cannot
assume that one character is one byte.
For counting characters in $STRING, the ${#STRING} construction can be
used. It won't work with non-bash in UTF-8 locales correctly, but the
only (AFAIK) shell that supports UTF-8 is bash. So it's safe to assume
that non-bash just won't be used in UTF-8 locales.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Text wrapping bug in bootscripts (on plain ASCII)
Nathan Coulson wrote:
BTW, does the # work under ash? [the Counting Characters part, not
the international part. (Internationalzation for someone who wants to
use ash, is probably not a major concern)]
Then ${#STRING} construction works properly in ash in all 8-bit locales.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: sysctl script at S90?
Matthew Burgess wrote: Bryan Kadzban wrote: At least /proc/sys/dev/rtc/max-user-freq does not exist until the rtc module is loaded. (As long as enhanced real-time clock is configured as a module, anyway. Build it into the kernel and the problem goes away. ;-P ) Well, not for me it didn't. RTC is compiled in, and I still had problems. I assumed this was because the /dev/rtc device hadn't been created that early (because of udev) and therefore the corresponding /proc entry wasn't available until that point. Please redo your analysis. The existence of a /dev entry and udev has absolutely no relation to /proc contents. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Useless note on Ch5 glibc page
Glibc page in Chapter 5 contains the following paragraph: During this stage the following warning might appear: configure: WARNING: *** These auxiliary programs are missing or *** incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions. The missing or incompatible msgfmt program is generally harmless, but it can sometimes cause issues when running the test suite. This msgfmt program is part of the Gettext package which the host distribution should provide. If msgfmt is present but deemed incompatible, upgrade the host system's Gettext package or continue without it and see if the test suite runs without problems regardless. The reader cannot see this. The reason is that he must have gettext installed on the host in order to build binutils earlier. Solutions: 1) Remove the note. 2) Pass --disable-nls to binutils in Chapter 5 in order to avoid dependency on gettext. I prefer (2), since we already disable translated messages at runtime by setting LC_ALL=POSIX. It's just illogical to compile binutils with (costly) support for translated error messages but never use this feature. Also, (2) is already implemented in cross-LFS, but the explanation it is not needed is not perfect. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Bashism in LFS-bootscripts
In /etc/rc.d/init.d/functions, we have:
# if CUR_LENGTH was set to zero, then end the line
if [ ${CUR_LENGTH} == 0 ]; then
echo
fi
== is a bash-specific pattern matching operator. In this context, it
should be replaced with a plain =.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: flex-2.5.31
David Jensen wrote: I poked at this for a couple days, and there are problems with the current flex build instructions: 1. The order of the files in flex-2.5.31-debian_fixes-2.patch may sometimes trigger regenerating scan.c, which causes the build to fail if flex is not already installed. -- Solution: Move the scan.c section of the patch to after the scan.l section. Build and install per the current instructions. Goto 2. The livecd scripts implement another solution: patch -Z -Np1 -i flex-2.5.31-debian_fixes-2.patch Note the -Z option which causes dates to be set from the patch. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Issues with pstree
(Sorry for possible duplicate, the smarthost in USU seems to have marked
my original message as SPAM or is just broken. I think I will eventially
have to move to some other E-Mail address, not related with USU).
Hello,
psmisc-21.6 has several issues in the pstree program:
1) In non-ISO-8859-1 8-bit locales on Linux console, pstree sends the
\033(0 escape sequence to the terminal. This means Use ISO-8859-1
translation table and therefore breaks the display of all national
characters after running pstree. (echo -e '\033(K' is the fix).
2)
http://sourceforge.net/tracker/index.php?func=detailaid=1195650group_id=15273;
atid=115273
Issue (1) is critical, since it makes pstree completely unusable on
Linux console in all non-ISO-8859-1 8-bit locales. Issue (2) is also
important, since it can turn the terminal session into garbage in any
locale (but, as opposed to (1), it is triggered rarely).
I have not noticed (1) for a long time because I always start KDM and
almost never work in the linux console. My fault.
One possible solution is to put a warning in the description of pstree
in the LFS book, i.e. don't use this program on linux console in
non-ISO-8859-1 locales - it will break the display of national characters.
Another solution is to patch pstree.
I have attached two patches to psmisc, please choose one of them or
both. The -1a patch just disables the use of VT100 line drawing
characters by default and thus avoids these two bugs and some others.
The -1b patch attempts to fix those two bugs, but I cannot call the fix
100% correct for xterm (it relies upon the undocumented fact that xterm
ignores the \033(K sequence). The -1a patch is IMHO a safer solution.
Please choose which of the solutions should go into LFS-6.1.
--
Alexander E. Patrakov
Submitted by: Alexander E. Patrakov
Date: 2005-06-05
Initial Package Version: 21.6
Upstream Status: Not Submitted - Hack
Origin: Alexander E. Patrakov
Description: This patch disables the use of VT100 line drwaing characters
by default in pstree. They are still accessible by runnung pstree -G.
Rationale: Use of VT100 line drawing characters is the origin of at least two
important bugs:
1) In non-ISO-8859-1 8-bit locales on Linux console, pstree sends the
\033(0 escape sequence to the terminal. This means Use ISO-8859-1 translation
table and therefore breaks the display of all national characters after
running pstree. (echo -e '\033(K' is the fix).
2) pstree may break line without turning off ACS mode. If this happens in the
last line of output, the subsequent bash prompt and everything else is turned
into meaningless line-drawing characters. Example:
http://sourceforge.net/tracker/index.php?func=detailaid=1195650group_id=15273atid=115273
There are other bugs, e. g. misaligning of line-drawing characters in Konsole
and cutting the line at less than 80 columns, that are also avoided by default
due to non-use of VT100 line drawing characters.
--- psmisc-21.6/src/pstree.c2005-06-05 10:43:16.0 +0600
+++ psmisc-21.6/src/pstree.c2005-06-05 10:49:07.0 +0600
@@ -757,7 +757,6 @@
const struct passwd *pw;
pid_t pid, highlight;
char termcap_area[1024];
- char *termname;
int c;
char *tmpstr;
@@ -788,15 +787,6 @@
if (!strcmp(nl_langinfo(CODESET), UTF-8)) {
/* Use UTF-8 symbols if the locale's character set is UTF-8. */
sym = sym_utf;
- } else if ((termname = getenv (TERM)) \
- (strlen (termname) 0) \
- (setupterm (NULL, 1 /* stdout */, NULL) == OK) \
- (tigetstr (acsc) 0)) {
-/*
- * Failing that, if TERM is defined, a non-null value, and the terminal
- * has the VT100 graphics charset, use it.
- */
-sym = sym_vt100;
} else {
/* Otherwise, fall back to ASCII. */
sym = sym_ascii;
Submitted by: Alexander E. Patrakov
Date: 2005-06-05
Initial Package Version: 21.6
Upstream Status: Not Submitted - Test version
Origin: Alexander E. Patrakov
Description: This patch fixes some (but not all) bugs resulting from improper
use of VT100 line drawing characters by pstree.
Detalils: Use of VT100 line drawing characters is the origin of at least two
important bugs:
1) In non-ISO-8859-1 8-bit locales on Linux console, pstree sends the
\033(0 escape sequence to the terminal. This means Use ISO-8859-1 translation
table and therefore breaks the display of all national characters after
running pstree. (echo -e '\033(K' is the fix).
2) pstree may break line without turning off ACS mode. If this happens in the
last line of output, the subsequent bash prompt and everything else is turned
into meaningless line-drawing characters. Example:
http://sourceforge.net/tracker/index.php?func=detailaid=1195650group_id=15273atid=115273
These two bugs are fixed, but the fix is not 100% correct: VT_END contains two
escape sequences, one for linux console and one for xterm. The patch relies
upon the fact that each of those two terminals ignores the escape sequence
Issues with pstree
Hello,
psmisc-21.6 has several issues in the pstree program:
1) In non-ISO-8859-1 8-bit locales on Linux console, pstree sends the
\033(0 escape sequence to the terminal. This means Use ISO-8859-1
translation table and therefore breaks the display of all national
characters after running pstree. (echo -e '\033(K' is the fix).
2)
http://sourceforge.net/tracker/index.php?func=detailaid=1195650group_id=15273;
atid=115273
Issue (1) is critical, since it makes pstree completely unusable on
Linux console in all non-ISO-8859-1 8-bit locales. Issue (2) is also
important, since it can turn the terminal session into garbage in any
locale (but, as opposed to (1), it is triggered rarely).
I have not noticed (1) for a long time because I always start KDM and
almost never work in the linux console. My fault.
One possible solution is to put a warning in the description of pstree
in the LFS book, i.e. don't use this program on linux console in
non-ISO-8859-1 locales - it will break the display of national characters.
Another solution is to patch pstree.
I have attached two patches to psmisc, please choose one of them or
both. The -1a patch just disables the use of VT100 line drawing
characters by default and thus avoids these two bugs and some others.
The -1b patch attempts to fix those two bugs, but I cannot call the fix
100% correct for xterm (it relies upon the undocumented fact that xterm
ignores the \033(K sequence). The -1a patch is IMHO a safer solution.
Please choose which of the solutions should go into LFS-6.1.
--
Alexander E. Patrakov
Submitted by: Alexander E. Patrakov
Date: 2005-06-05
Initial Package Version: 21.6
Upstream Status: Not Submitted - Hack
Origin: Alexander E. Patrakov
Description: This patch disables the use of VT100 line drwaing characters
by default in pstree. They are still accessible by runnung pstree -G.
Rationale: Use of VT100 line drawing characters is the origin of at least two
important bugs:
1) In non-ISO-8859-1 8-bit locales on Linux console, pstree sends the
\033(0 escape sequence to the terminal. This means Use ISO-8859-1 translation
table and therefore breaks the display of all national characters after
running pstree. (echo -e '\033(K' is the fix).
2) pstree may break line without turning off ACS mode. If this happens in the
last line of output, the subsequent bash prompt and everything else is turned
into meaningless line-drawing characters. Example:
http://sourceforge.net/tracker/index.php?func=detailaid=1195650group_id=15273atid=115273
There are other bugs, e. g. misaligning of line-drawing characters in Konsole
and cutting the line at less than 80 columns, that are also avoided by default
due to non-use of VT100 line drawing characters.
--- psmisc-21.6/src/pstree.c2005-06-05 10:43:16.0 +0600
+++ psmisc-21.6/src/pstree.c2005-06-05 10:49:07.0 +0600
@@ -757,7 +757,6 @@
const struct passwd *pw;
pid_t pid, highlight;
char termcap_area[1024];
- char *termname;
int c;
char *tmpstr;
@@ -788,15 +787,6 @@
if (!strcmp(nl_langinfo(CODESET), UTF-8)) {
/* Use UTF-8 symbols if the locale's character set is UTF-8. */
sym = sym_utf;
- } else if ((termname = getenv (TERM)) \
- (strlen (termname) 0) \
- (setupterm (NULL, 1 /* stdout */, NULL) == OK) \
- (tigetstr (acsc) 0)) {
-/*
- * Failing that, if TERM is defined, a non-null value, and the terminal
- * has the VT100 graphics charset, use it.
- */
-sym = sym_vt100;
} else {
/* Otherwise, fall back to ASCII. */
sym = sym_ascii;
Submitted by: Alexander E. Patrakov
Date: 2005-06-05
Initial Package Version: 21.6
Upstream Status: Not Submitted - Test version
Origin: Alexander E. Patrakov
Description: This patch fixes some (but not all) bugs resulting from improper
use of VT100 line drawing characters by pstree.
Detalils: Use of VT100 line drawing characters is the origin of at least two
important bugs:
1) In non-ISO-8859-1 8-bit locales on Linux console, pstree sends the
\033(0 escape sequence to the terminal. This means Use ISO-8859-1 translation
table and therefore breaks the display of all national characters after
running pstree. (echo -e '\033(K' is the fix).
2) pstree may break line without turning off ACS mode. If this happens in the
last line of output, the subsequent bash prompt and everything else is turned
into meaningless line-drawing characters. Example:
http://sourceforge.net/tracker/index.php?func=detailaid=1195650group_id=15273atid=115273
These two bugs are fixed, but the fix is not 100% correct: VT_END contains two
escape sequences, one for linux console and one for xterm. The patch relies
upon the fact that each of those two terminals ignores the escape sequence for
the other terminal type.
There are other, unfixed bugs, e. g. misaligning of line-drawing characters
in Konsole and cutting the line at less than 80 columns.
--- psmisc-21.6/src/pstree.c.orig
Re: LiveCD glibc test error during LFS build
Kronuz MB wrote: Hello, I'm using lfslivecd-x86-6.1-1-pre3.iso and the latest LFS from SVN and I got an error from the glibc tests (tst-cancel16: Timed out: killed the child process). Patrakov suggested I should use mount -t tmpfs tmpfs /tmp before compiling glibc and it worked. I'm just reporting this apparently fixed the issue. He said this might be related to unionfs. (that was in Chapter 5 only) It was indeed a unionfs bug. Worked around in r216 for the Live CD. To LFS developers: since the latest Knoppix also uses unionfs as a root filesystem, it may have the same problem in Chapter 5. Cannot test this with Knoppix right now because of bandwidth issues. Maybe someone should add this to the list of known Chapter 5 glibc testsuite failures. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD glibc test error during LFS build
I wrote: To LFS developers: since the latest Knoppix also uses unionfs as a root filesystem, it may have the same problem in Chapter 5. Cannot test this with Knoppix right now because of bandwidth issues. Tested, no failure here because /tmp is not on unionfs in Knoppix 3.9. Maybe someone should add this to the list of known Chapter 5 glibc testsuite failures. No need to do so, because the only known bad host so far is our -pre3 Live CD. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
UTF-8 and LSB testsuite
Hello, LFS currently fails the formal LSB testsuite even in the parts that are relevant to LFS. The testsuite is available at: http://www.linuxbase.org/download/#test_suites ftp://ftp.freestandards.org/pub/lsb/test_suites/released-2.0.0/source/runtime/lsb-runtime-test-2.0.6-2.src.rpm ftp://ftp.freestandards.org/pub/lsb/test_suites/beta/source/runtime/lsb-runtime-test-3.0.0-3.src.rpm Dependencies: byacc ftp://invisible-island.net/byacc/byacc-20050505.tgz, ed, pax (optional) The li18nux2k-level1 part of the testsuite exhibits nearly 50 failures on what's currently in the Live CD repository. This number can be brought down to 7 by applying patches from the following page: http://www.openi18n.org/subgroups/utildev/dli18npatch2.html I applied patches to diffutils, grep and coreutils (with one easily fixable reject in src/sort.c). I propose to add those patches to LFS-7.0 because they fix real problems, even though their upstream status is rejected because of code duplication. The remaining failures are: T.nl_langinfo: Verify this function returns a pointer to an empty stringif item contains an invalid setting. Cannot use LTP_IL2.UTF-8 locale. T.strfmon: Verify this function replaces conversion specifier i with the double argument is formatted according to the locale's international currency format. (differences in whitespace only--AEP). T.wcsftime: Verify this function replaces conversion specifier `Z' with the time zone or name or abbreviation. unexpected signal 11 (SIGSEGV) received. Those above are glibc failures. Will retest with 2.3.5. T.join: When -t option is not specified, verify blank characters according to the current locale are used as input field separators. (segmentation fault). looks like a problem with the patch. The remaining are cpio failures, off-topic on this list. Will post them to blfs-dev separately after further investigation. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 in LFS. New console script by Alexander E. Patrakov
Pasha Zubkov wrote:
Alexander, thanks for your console script. I think we need extend
command that applies to all consoles. Here is example, it's not use
console config file, but show idea.
openvt -f -w -c ${TTY#tty} -- \
/bin/sh -c kbd_mode -u \
echo -n -e '\033%G' \
setfont LatArCyrHeb-16
Without executing setfont in all consoles by console script we got only
first console to work properly. And need execute setfont in another
consoles by hand. So, I guess this all-consoles-command must be extended
by setfont.
Is it on plain text console or with a framebuffer?
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: grep: --with-included-regex: must be dropped for 6.1
Archaic wrote: On Tue, Jun 14, 2005 at 03:49:05PM -0500, Tushar Teredesai wrote: Reason b is correct. But a is not. grep links against the glibc that was built in /tools. Doh!. Thanks. Totally spaced it when writing that. Lucky that b is still relevant. ;) It's correct but irrelevant. Results in the C locale are the same woth and without included regex. Compilation time and size of the grep binary are not. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Updated console scripts for LFS 6.1 and 7.0
Hello,
Pasha Zubkov found that the font isn't being correctly set on
framebuffer consoles. This bug also affects LFS-6.1-testing.
I have attached fixed console scripts for LFS-6.1 and 7.0 (the
difference is that in the 6.1 script all UTF-8-related stuff is omitted).
Now these scripts work for both text-mode and framebuffer consoles.
The -I '\033(K' agetty switch can be dropped from /etc/inittab in
LFS-6.1 with this version of the console script.
--
Alexander E. Patrakov
#!/bin/sh
# Begin $rc_base/init.d/console
#
# Description : Sets keymap and screen font
#
# Authors : Gerard Beekmans - [EMAIL PROTECTED]
# Alexander E. Patrakov
#
# Version : 00.03
#
# Notes :
#
. /etc/sysconfig/rc
. ${rc_functions}
# Native English speakers probably don't have /etc/sysconfig/console at all
if [ -f /etc/sysconfig/console ]
then
. /etc/sysconfig/console
fi
is_true() {
[ $1 = 1 ] || [ $1 = yes ] || [ $1 = true ]
}
failed=0
trap failed=1 ERR
case ${1} in
start)
boot_mesg Setting up Linux console...
# There should be no bogus failures below this line!
# Figure out if a framebuffer console is used
[ -d /sys/class/graphics/fb0 ] USE_FB=1 || USE_FB=0
MODE_COMMAND=echo -en '[EMAIL PROTECTED](K' kbd_mode -a
# On framebuffer consoles, font has to be set for each vt
! is_true ${USE_FB} || [ -z ${FONT} ] ||
MODE_COMMAND=${MODE_COMMAND} setfont ${FONT}
# Apply that command to all consoles mentioned in
# /etc/inittab.
for TTY in `grep '^[^#].*respawn:/sbin/agetty' /etc/inittab |
grep -o '\btty[[:digit:]]*\b'`
do
openvt -f -w -c ${TTY#tty} -- \
/bin/sh -c ${MODE_COMMAND}
done
# Set the font and the keymap
is_true ${USE_FB} || [ -z ${FONT} ] || setfont $FONT
[ -z ${KEYMAP} ] || loadkeys ${KEYMAP} /dev/null
[ -z ${KEYMAP_CORRECTIONS} ] ||
loadkeys ${KEYMAP_CORRECTIONS} /dev/null
# If any of the commands above failed, the trap at the
# top would set $failed to 1
( exit $failed )
evaluate_retval
;;
*)
echo $Usage: ${0} {start}
exit 1
;;
esac
# End $rc_base/init.d/console
#!/bin/sh
# Begin $rc_base/init.d/console
#
# Description : Sets keymap and screen font
#
# Authors : Gerard Beekmans - [EMAIL PROTECTED]
# Alexander E. Patrakov
#
# Version : 00.03
#
# Notes :
#
. /etc/sysconfig/rc
. ${rc_functions}
# Native English speakers probably don't have /etc/sysconfig/console at all
if [ -f /etc/sysconfig/console ]
then
. /etc/sysconfig/console
fi
is_true() {
[ $1 = 1 ] || [ $1 = yes ] || [ $1 = true ]
}
failed=0
trap failed=1 ERR
case ${1} in
start)
boot_mesg Setting up Linux console...
# There should be no bogus failures below this line!
# Figure out if a framebuffer console is used
[ -d /sys/class/graphics/fb0 ] USE_FB=1 || USE_FB=0
# Figure out the command to set the console into the
# desired mode
is_true ${UNICODE}
MODE_COMMAND=echo -en '\033%G' kbd_mode -u ||
MODE_COMMAND=echo -en '[EMAIL PROTECTED](K'
kbd_mode -a
# On framebuffer consoles, font has to be set for each vt
! is_true ${USE_FB} || [ -z ${FONT} ] ||
MODE_COMMAND=${MODE_COMMAND} setfont ${FONT}
# Apply that command to all consoles mentioned in
# /etc/inittab. Important: in the UTF-8 mode this should
# happen before setfont, otherwise a kernel bug will
# show up and the unicode map of the font will not be
# used.
# FIXME: Fedora Core also initializes two spare consoles
# - do we want that?
for TTY in `grep '^[^#].*respawn:/sbin/agetty' /etc/inittab |
grep -o '\btty[[:digit:]]*\b'`
do
openvt -f -w -c ${TTY#tty} -- \
/bin/sh -c ${MODE_COMMAND}
done
# Set the font and the keymap
Re: i18n appendix was [Bug 1516] Font set improperly on framebuffer console]
Jim Gifford wrote: Should we create an appendix with the necessary settings for different languages, of course after we get some validation that they work. Alex could you help out on such on effort, since i18n is your expertise? Yes, of course, this is already partially implemented for the Live CD (LANG - FONT mapping is done). The LANG - KEYMAP mapping can be obtained from Debian installer. However, I don't think it is really needed for LFS 6.x book. Reason: the book already spells out the assumption that the reader knows the correct parameters for loadkeys and setfont, and there is no plan to support languages needing more than loadkeys + setfont + LANG in LFS 6.x timeframe. BTW the assumption above is in fact incorrect, because in some distros the user just clicks through the dialogs to configure his regional settings without understanding that these dialogs set LANG and parameters for loadkeys and setfont. But I think that such dumb users are out of our control and out of the book audience. If you know any way to improve the situation, please share your opinion. One more question: for mounting Windows-related filesystems (VFAT, ISO9660+JOULIET, NTFS, SMBFS) non-English users have to compile NLS modules for the kernel and either modify the default NLS option in the kernel config or add options to the mount command or fstab, e.g.: mount -t iocharset=koi8-r /dev/cdrom /media/cdrom Sould this be mentioned in the book? Where? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[Fwd: biggger changes in the next udev version]
Forwarding a message from linux-hotplug-devel list. ---BeginMessage--- We merged now the recent changes for udev to the upstream repository: http://kernel.org/git/gitweb.cgi?p=linux/hotplug/udev.git;a=summary It is a sync-up with the features of the currently shipped SUSE version along with some new features. The goal is to take over the complete kernel event processing and provide an efficient way to dispatch kernel events. Replacing the current shell script logic and the kernel forked helper with a netlink-daemon and a rule based event handling: o udevd listens to netlink events now. The first valid netlink event will make udevd ignore any message from udevsend that contains a SEQNUM, to avoid duplicate events. SUSE disables the forked events: echo /proc/sys/kernel/hotplug completely and uses only netlink to receive kernel events. For full support, it needs a patch for the broken input subsytem, that unfortunately still bypasses the driver core. o /etc/dev.d/ + /etc/hotplug.d/ directory multiplexing is completely removed from udev itself and must be emulated by calling small helper binaries provided in the extras folder: make EXTRAS=extras/run_directory/ will build udev_run_devd and udev_run_hotplugd, which can be called from a rule if needed: RUN+=/sbin/udev_run_hotplugd The recommended way to handle this is to convert all the calls from the directories to explicit udev rules and get completely rid of the multiplexing. (To catch a ttyUSB event, you now no longer need to fork and exit 300 tty instances you are not interested in, it is just one rule that matches exactly that device.) o udev handles now _all_ events not just events for class and block devices, this way it is possible to control the complete event behavior with udev rules. Especially useful for rules like: ACTION=add, DEVPATH=/devices/*, MODALIAS==*, RUN+=/sbin/modprobe $modalias o As used in the modalias rule, udev supports now textual substitution placeholder along with the usual format chars. This needs to be documented some day, for now it's only here: http://kernel.org/git/gitweb.cgi?p=linux/hotplug/udev.git;a=blob;f=udev_rules.c#l226 o The rule keys support now more operations. This is documented in the man page. It is possible now to add values to list-keys like the SYMLINK and RUN list with KEY+=value, to clear the list by assigning KEY=. Also final-assignments are supported by using KEY:=value, which will prevent changing the key by any later rule. o kernel 2.6.12 has the detached_state attribute removed from sysfs, which was used to recognize sysfs population. We switched that to wait for the bus link, which is only available in kernels after 2.6.11. Running this udev version on older kernels may cause a delay for some events and is not recommended. o A few binaries are added to the repository, which can be used to replay kernel events from initramfs instead of using coldplug. udevd can be instructed now to queue only events while the stored events from initramfs are filled into the udevd-queue. There is no documentation now besides the code itself. The additional binaries get compiled, but are not installed by default. Any testing, feedback and help is appreciated. Thanks, Kay --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel ---End Message--- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: i18n appendix was [Bug 1516] Font set improperly on framebuffer console]
Archaic wrote: We don't generally touch any kernel specific options except those that will most certainly break LFS by not having them enabled. Perhaps a one page i18n quick info section would be in order at the end of the book somewhere? Could you please suggest some wording that would help splitting bash profile between two pages, one dealing with INPUTRC=/etc/inputrc (in chapter 7) and the other one dealing with LANG? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
About the LINGUAS environment variable
I propose to add the following text (possibly with some edits) somewhere before Chapter 5 after LFS 6.1 goes out. Many packages provide the --disable-nls option to their configure scripts, and give the following help text for it: do not use Native Language Support. Native Language Support means not only translated messages, but also correct classification of characters, case mapping, sorting order, etc. Programs compiled with this switch disregard the LANG environment variable completely at runtime and either think that all non-ASCII characters (i.e. accented or national characters) are non-printable or use hard-coded defaults instead of functions provided by glibc in order to classify and sort them. The behaviour of disregarding LANG is not standards-compliant, therefore, it is recommended that you don't use this switch except when it is explicitly mentioned in this book. A way to save space on unneeded message translations without any negative effects upon other NLS aspects is to set the LINGUAS variable during the build. The contents of this variable should be a space-separated list of two-letter codes of languages, translations to which should be installed. E.g., to install only Italian and Spanish translations: export LINGUAS=it es Programs compiled in such a way are fully usable in other locales, and work correctly with user documents written in other languages. Just messages from a program itself will be in English. To install no translations, set LINGUAS to the empty value: export LINGUAS= If the LINGUAS variable isn't exported, all available translations are installed. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: About the LINGUAS environment variable
Tushar Teredesai wrote: On 6/22/05, Alexander E. Patrakov [EMAIL PROTECTED] wrote: export LINGUAS=it es Many moons ago I had tried this approach, but some packages failed during compilation. I did not dig deeper. Found it was easier to just remove the unwanted translations. Maybe the situation has changed now. Did a check by building the LFS part of the LiveCD (i.e. complete LFS minus kernel and bootscripts) with LINGUAS set to empty in Chapter 5 and to es ru xx in Chapter 6. The invalid xx language has been added just to provoke build errors. Results: 1) No build errors in LFS-testing. Will post partial BLFS results later if there is any interest. 2) The following packages in LFS don't obey LINGUAS even when it is set to non-empty value: libstdc++, kbd. They install all translations, which is harmless. 3) wget, gcc and glibc install all translations when LINGUAS is set to empty value. Easily worked around by setting LINGUAS to something invalid like xx. WARNING: the test isn't really clean because the current LiveCD buildscripts forget to set LC_ALL to POSIX in Chapter 6. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: About the LINGUAS environment variable
Alexander E. Patrakov wrote: 1) No build errors in LFS-testing. Will post partial BLFS results later On the Live CD, the following packages create unwanted translations when LINGUAS is set to ru es xx: eject kbd libstdc++ subversion util-linux wget - This can be fixed by upgrading to 1.10 No build failures. See the full package list in the main Makefile: http://svn.linuxfromscratch.org/viewcvs.cgi/*checkout*/x86/trunk/Makefile?rev=266root=livecd -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: xi:include tags in the cross-lfs book
M.Canales.es wrote:
It failed on their current form. The xpointer expesions used aren't useful for
moving targets. That is the big issue: if there is a change on the nodes
position in the target file, the xpointers that point to that file wll be
wrong.
I think that the biggest trouble is that xpointer expressions include
some meaningless offset numbers like para[2] instead of assigning a
meaningful name to the exact text to be copied to another page.
Unfortunately, I am not familiar with XML at all, so all of the below is
pseudocode:
{mark name=some-warning}{para}here goes a warning{/para}{/mark}
...
{reuse name=some-warning/}
Is it possible to implement?
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: sh compliance problems
DJ Lucas wrote: mountkernfs script succeeds, however it leaves behind messages (merged) when sh is a symlink to ash. '' does not redirect. Suggest '21'. Also, I'm not sure what version of hotplug right this second, but the math early on in the following files is also broken with ash symlinked to /bin/sh. hotplug-2004_09_23.tar.bz2, old so I don't know if the problem still exists or not...any takers? /etc/hotplug/input.agent /etc/hotplug/pci.agent /etc/hotplug/pnp.rc /etc/hotplug/usb.agent All of the above works fine when sh is a symlink to zsh or bash (as expected). Please change the book so that #!/bin/bash, not #!/bin/sh, appears at the top of those scripts. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: sh compliance problems
DJ Lucas wrote: Yes, I had thought about suggesting that, however held it for a few reasons, the most important is that we don't install ash in LFS. Not breaking BLFS is IMHO more important. Also with hotplug-ng coming... Forget about hotplug-ng. It's already dead, to be replaced with the initramfs-based early hotplug event replay mechanism in udev-060. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gawk-3.1.4: wrong charset for Italian translation
Archaic wrote: On Fri, Jul 08, 2005 at 05:05:41PM +0600, Alexander E. Patrakov wrote: gawk-3.1.4/it.po specifies ISO-8859-8 as its charset, which is wrong (should be ISO-8859-1). Please add the following correction to the book, Chapter 6: Has this been sent upstream? Probably, by Debian. That's where I got the fix from. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Groff/man versions and UTF-8
Hello, Since there may be a version of LFS that supports UTF-8 and other multibyte encodings in the future, that version has to provide the man program that can display manual pages in UTF-8 locales. However, man-1.x and groff-1.19.x suck. See below. The solution is either to apply two workarounds below, or (better) switch to Debian-patched groff-1.18.1.1 (for -Tnippon and -Tascii8 devices) and Debian-patched man-db (it automagically uses the proper device and trailing iconv pipe if needed). This also means addition of db or gdbm to the book because man-db depends on one of those two database packages. Please vote if we should go with man-db or with the workarounds below. 1) The book currently provides -lang en as a part of man ./configure string. Readers will see that man --help produces this line: Cannot open the message catalog man for locale de_DE.UTF-8 (NLSPATH=none) Some readers will add something like -lang en,de (or even -lang all) to work around that and then will get an installation that displays unreadable squares instead of readable accented letters in de_DE.UTF-8 locale (de_DE.ISO-8859-1 works fine). Worse, in ru_RU.UTF-8 the entire output of man --help is a sequence of unreadable squares! The reason is that man still uses the old catgets translation mechanism instaed of gettext and thus doesn't preform recoding from translator's charset to the user's one. Solution: explain the problem (previous sentence) and add +lang none to man's ./configure line. Then, man will always display its help text and error messages in English, and will never complain about missing message catalogs. 2) The default groff setup produces pages full of garbage in UTF-8 locales instead of translated manuals (this also happened in RedHat Linux 8). Proper groff setup is cumbersome and will take a lot of space in the book text. It must be noted that, among many possible setups implemented by distros, the one most compatible with BLFS and beyond-BLFS packages is chosen. In the approach below, BLFS instructions just produce working manual pages. For other possible setups, it is needed to add instructions for recoding translated manual pages to each BLFS package, and that is not possible due to BLFS size. Decision tree for the proper NROFF line in /etc/man.conf is below, explanation is in the man-i18n hint: I) if the manual pages for your locale (as supplied with source packages like shadow) are not stored in ISO-8859-1, goto III II) NROFF /usr/bin/nroff -mandoc (note the missing -Tlatin1) and you can view manual pages in both C, your_locale and your_locale.UTF-8. Done, and you are lucky. III) If your locale is a Japanese or Korean one, go away. LFS doesn't provide you with working groff. man-1.x assumes Debian-patched groff here because of -Tnippon. Or, be sure to delete all Japanese and Korean manual pages, and English ones will be presented to you instead. IV) NROFF /usr/bin/nroff -Tlatin -mandoc | /usr/bin/iconv -f OLDCHARSET where OLDCHARSET is the charset in which manual pages for your language are stored on disk (i.e. KOI8-R should be written instead of OLDCHARSET for viewing Russian manual pages). Yes, this is a gross hack. Here groff is fooled into thinking that the manual page and the output are in ISO-8859-1 (so that no conversions take place in groff), and the trailing iconv pipe converts from the translator's charset to the user's one. It is a no-op in non-UTF-8 locales where those two are in fact the same. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: charset/language/fluxbox
Matthew Burgess wrote: Thomas Trepl wrote: Mr. Patrakov asked me to put a small list of combinations of LC_ALL/LANG to that list here. I'm quite sure he wouldn't have pointed you to the wrong list. BLFS, not LFS, installs fluxbox. Please report this to blfs-dev or (probably better) blfs-support@linuxfromscratch.org instead. No. I meant lfs-dev. I suspected that the new text about locales at http://www.linuxfromscratch.org/lfs/view/6.1/chapter07/profile.html is still wrong. Judging from the message, it is evident that Thomas Trepl has never tried [EMAIL PROTECTED] (case-sensitive), LC_ALL unset (that's what the book recommends now). If that works, there is no need to change the text. My testing here shows that X accepts such locale name. Background: glibc treats charset names in the locale names case-insensitively and ignores hyphens. So, [EMAIL PROTECTED] and [EMAIL PROTECTED] are the same thing for glibc. But not for applications/libraries that parse locale names themselves, without the help from glibc. Xlib is one of those picky libraries, and fluxbox is just a victim. LFS should provide readers with the means to guess the locale name that will be accepted by such picky packages. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: charset/language/fluxbox
steve crosby wrote: Something like: Some applications and libraries that use locale information directly instead of through the glibc interface incorrectly rely on the LC variables you have set above being case-sensitive. No, because case-sensitivity of locale names is not part of any standard. You should run the locale -something command to get the correct value to use for the LC variables to work around issues with these broken applications and libraries. Unfortunately, as the latest report from Thomas indicates, this method is also flawed. The best known suggestion so far is to look into glibc-2.3.4/localedata/SUPPORTED (the first column) and /usr/X11R6/lib/X11/locale/locale.alias, then try everything until both glibc is happy (i.e. locale charmap prints the proper charmap) and Xlib doesn't object. For Thomas' case, the proper solution is to use [EMAIL PROTECTED] I'm assuming the Xlib maintainers have been notified of the problem as well? No, and they won't fix that. There are many other libc-like libraries on non-Linux UNIX-like OSes that don't offer the locale mechanism exactly in the way like glibc does. But distro-makers do patch the /usr/X11R6/lib/X11/locale/locale.alias file. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: charset/language/fluxbox
steve crosby wrote: I'm assuming the Xlib maintainers have been notified of the problem as well? Yes, and I think that the problem should be in fact solved on the BLFS side. Please see xorg-6.8.2-locale_names-1.patch that I just submitted: http://archives.linuxfromscratch.org/mail-archives/blfs-dev/2005-July/010401.html -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap
TheOldFellow wrote: Anderson Lizardo wrote: TheOldFellow wrote: Matthew Burgess wrote: I also wanted to get some internationalisation work sorted out for LFS, so where are the non-8bit-language (indeed, apart from Manuel and Alex, where are the non-ASCII) volunteers to test this? It's all very well to Hey, I'm non-ASCII too ;-). Well so you are! (Sorry) In fact, as a Brit, I deplore the 'assumption' that 'English means American' that gets into so much software. OK, we have some i18n 8-bit users, but multibyte? I see some names than might be Chinese on the list occasionally. Some of the users for which 8-bit encodings work might still prefer UTF-8 for compatibility with RedHat (at the cost of incompatibility with the rest of the world). Also UTF-8 support is a requirement for LSB certification. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gawk-3.1.4: wrong charset for Italian translation
Matthew Burgess wrote: Alexander E. Patrakov wrote: Archaic wrote: Has this been sent upstream? Probably, by Debian. That's where I got the fix from. Has anyone else managed to find any archives of the bug-gawk mailing list, which is where bug reports are supposed to be sent. At least that's what README in the gawk-3.1.4 tarball says, and it even states: The advantage to using this address is that bug reports are archived at GNU Central. http://lists.gnu.org/archive/html/bug-gnu-utils/ And what about online CVS access (ala viewcvs or similar), or even instructions on how to download current sources using the CVS client? Unfortunately, only this (contains a link to a recent beta): http://lists.gnu.org/archive/html/bug-gnu-utils/2005-07/msg00084.html http://www.skeeve.com/gawk-3.1.4m.tar.bz2 http://www.skeeve.com/gawk/ (guessed) gave me a 403 error, so I guess that the latest sources are kept secret. So I confirm that the Italian charset has been fixed, and that RedHat patches that fix gawk-3.1.4 bugs give rejects (aka upstream fixed this differently). The manyfiles test from the builtin testsuite fails. The problem with UTF-8 recently reported on the lfs-dev (the testcase used GPG_ERR_*) is no longer present. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bash Docs
Randy McMurchy wrote: The only bash docs installed right now are in man and info format. These files are difficult to print, as well as being difficult to search through. Printing the manual page is easy: man -t bash bash.ps lpr bash.ps This gives 64 letter pages or 60 A4 pages of documentation. Converting to HTML: groff -Thtml -mandoc /usr/share/man/man1/bash.1 /tmp/bash.html -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
libcurses.so - libncurses.so symlink and ldconfig
Hello,
The LFS-6.1 book creates the /usr/lib/libcurses.so - libncurses.so
symlink during ncurses installation. A possible problem is that ldconfig
also looks at that symlink. So after running the following commands as root:
cd /usr/lib ; /sbin/ldconfig ; ls -l lib{n,}curses*
the result is something like:
lrwxrwxrwx 1 root root 12 Jun 23 12:02 libcurses.a - libncurses.a
lrwxrwxrwx 1 root root 13 Jun 23 12:03 libcurses.so - libncurses.so
-rw-r--r-- 1 root root 103046 Jun 23 12:03 libncurses++.a
-rw-r--r-- 1 root root 369990 Jun 23 12:02 libncurses.a
lrwxrwxrwx 1 root root 25 Jun 23 12:03 libncurses.so -
../../lib/libncurses.so.5
lrwxrwxrwx 1 root root 12 Jun 23 12:14 libncurses.so.5 - libcurses.so
Note the last symlink (created by ldconfig). I don't know if it is a
real problem (but it sometimes shows e.g. in ldd /bin/bash on
glibc-2.3.5 based systems). If this symlink is indeed bad, it can be
removed and the libcurses.so - libncurses.so symlink can be replaced
with a simple linker script:
rm libncurses.so.5
rm libcurses.so
echo 'INPUT(-lncurses)' libcurses.so
If the symlink is a non-problem, sorry for the noise.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
lfslivecd-x86-6.x-utf8-r0 released
Hello, The first semi-official LFS Live CD that supports UTF-8 (for European languages only) is now available. You can download the image without sources from: http://ums.usu.ru/~patrakov/lfslivecd/lfslivecd-x86-6.x-utf8-r0-nosrc.iso The image with (non-UTF-8) LFS-6.1 sources included is: http://ums.usu.ru/~patrakov/lfslivecd/lfslivecd-x86-6.x-utf8-r0.iso Or, you can build this yourself, the scripts can be checked out from SVN: svn co svn://svn.linuxfromscratch.org/livecd/x86/branches/utf8 \ lfs-livecd Mirrors for the ISO images are more than welcome. The following package replacements were made: GNU groff 1.19.1 replaced with Debian Groff 1.18.1.1-8 man replaced with man-db (but the command that displays manual pages is still called man) gdbm added because man-db depends upon either gdbm or db links replaced with w3m slrn replaced with tin slang removed because nothing depends on it All ncurses programs are recompiled against libncursesw.so.5 The console bootscript was modified Any regression in non-UTF-8 locale support WRT the official LFS-6.1 CD must be reported on the livecd list as a severe bug. The LI18NUX2000-Level1 testsuite passes on the CD if you mount /home as a tmpfs instead of unionfs and unset the TZ environment variable. === That CD was created largely due to Archaic's idea that a sample implementation will help me push UTF-8 to the book. Well, a usable sample implementation is there, but I don't think it helps much and that UTF-8 in the main LFS book (i.e. not a branch) is a good idea. The issue is that problems related to packages not on the CD (e.g. inability to print UTF-8 documents from the command line without packages beyond BLFS) and migration issues are not covered by this sample implementation at all. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] On LFS' Package Selection Policy
Matthew Burgess wrote: 1) Are the utilities and/or interfaces the package provides mandated by any of the following standards? * Linux Standard Base (LSB-3.0) I'd rather not mention this (very strict) standard without reading it. It requires both other mentioned standards and also UTF-8, PAM and RPM. Also it sometimes stiffles the progress (aka new versions of libraries don't pass the testsuite). This is not likely what most want in the main LFS book. A separate book or branch is probably OK. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] On LFS' Package Selection Policy
Jeremy Huntwork wrote: Matthew Burgess wrote: Thoughts, comments, suggestions? I like it. It's essentially all the questions we've been asking already, but it's nice to have it listed as such. Does this mean we go back and run all our current packages through the ringer now? :P Which reminds me, we might want to consider what to do about hotplug in the near future. The latest version is nearly a year old and hotplug-ng seems to be dead (Alexander pointed this out to me). hotplug-ng _is_ dead, superseded by the MODALIAS environment variable available in hotplug events and sysfs in linux = 2.6.12 and some udev magic. As to hotplug and udev, there is the following argument against them: any troubleshooting on the lists or on IRC starts with building a non-modular kernel, i.e. essentially with getting those packages out of the way. Thus, the educational value is at least dubious. I hope that avdantages (like hardware autodetection and persistent names for USB storage devices) overweigh this, but your opinion may be different. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Pushing UTF-8 support into LFS
Hello, a sample LFS-like system that supports UTF-8 is available on a live CD. So, it may be a good idea to create an experimental branch of the LFS book that incorporates the same changes. LFS built according to that branch should work in both UTF-8 and traitional locales. So, patches that make things work in UTF-8 but break the non-UTF-8 case are a no-go. Summary of changes (including those that are on the official non-UTF-8 CD) is below. Details for each package (and screenshots that illustrate the problems) will be available on request. REQUIRED: sharutils: added to chapter 5 because the ncurses rollup shell script wants uudecode. Ncurses: upgraded to 20050319 version (or at least applied the -altcharset-1 patch), built with --enable-widec. Compatibility linker scripts are created so that apps that want -lncurses are actually linked against -lncursesw. LFS Bootscripts: the console script is rewritten. sysklogd: the logic that treats bytes 0x80-0x9f as unprintable characters should be disabled, a patch is available. coreutils: big patch from RedHat. Unfortunately, with bad bug history. gawk: either a big patch from RedHat or a beta version (but it fails one test in its testsuite). When gawk-3.1.5 is released, no patches will be needed. Expect more bugs to show up in dfa.c. grep: big patch from RedHat. Expect more bugs to show up in dfa.c. GNU Groff-1.19.1: replaced with Debian Groff 1.18.1.1-8 gdbm: added to LFS as a dependency of man-db man: replaced with man-db diffutils: patch from RedHat linux: a patch is necessary for dead keys to work in UTF-8 mode. LOW PRIORITY LFS: glibc: the CD uses a patch that alters the list of supported locales. no_NO and vi_VN.TCVN removals are bugfixes, the rest of the patch is a cosmetic tweak. libidn is nice too but also optional. kbd: a patch is available that fixes all known keymaps that have backspace/delete problem, so that KEYMAP_CORRECTIONS are rarely needed. texinfo: a minor patch exists that forces a fallback to English interface in multibyte locales. readline: almost works as-is. RedHat also applies patches for the wrapping problem and for segfault in lftp. vim: some of the upstream patches fix problems in multibyte locales. I applied all upstream fixed on the CD. Also it is necessary to remove translated non-ISO-8859-1 tutorials because they are unreadable in UTF-8 locales. BLFS PACKAGES ON THE CD: cdrtools: a patch for mkisofs is needed in order to create Windows-readable CDs. Also the name of the author is transliterated so that non-ISO-8859-1 users can read it. thunderbird, firefox: a patch is available that works around the problem with displaying dates in expired certificate dialog and with gpg messages in Enigmail. Needed for all non-ISO-8859-1 locales. xfce: one Chinese message is mis-marked as Russian. A patch is available and accepted upstream. Xorg: there's a patch that makes Xorg understand more glibc locale names. nALFS: a patch is necessary to in order to display line drawing characters on Linux console properly. GPM: built --without-curses, if you want mouse support on linux console please build ncurses --with-gpm instead. OTHER TASKS FOR BLFS: mark broken packages that should not be installed on a system that supports UTF-8. BUGS ON THE CD: see -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Pushing UTF-8 support into LFS
I wrote: BUGS ON THE CD: see http://svn.linuxfromscratch.org/viewcvs.cgi/x86/branches/utf8/BUGS?rev=549root=livecdview=markup -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Bootscripts
DJ Lucas wrote:
Never mind. $$ is not actually incrementing, but I don't know what
processes pidof is finding when running that script. Creating a second
functions script with only statusproc and getpids using the same 'pidof
-o $$ -o $PPID -x ${1}' gives the proper result. It looks as if pidof
it's finding it's own PID but that can't be either because it does not
find itself in the second example. I'm at a loss. Will revisit after
some sleep.
Is that because of stty sane at the bottom of the functions file?
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Cross LFS Pure 64bit Book
John Miller wrote: I have a question about the pure 64bit x86_64 bit book. During the installation of grub you use the following instruction: CC=gcc -m32 -static ./configure --prefix=/usr However because this is a pure 64bit build their are no 32 bit libraries or the capability for gcc to build 32 bit correct? Or am I missing something? AFAIK, for pure64 builds, lilo should be used instead of grub. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposal: proactive search for autofoo bugs
Anderson Lizardo wrote: I suggest you use grep ^HAVE_ instead of only grep HAVE, so you reduce the false positives. SANE for instance use macros like WE_HAVE_* which I suppose are not to be listed. So here goes a slightly modified snnipet, which does not create a temp file: ifnames `find . -name \*.c -o -name \*.h` | grep ^HAVE_ | \ grep -v HAVE_CONFIG_H | cut -d -f1 | while read a; do \ grep -q $a config.h.in || echo $a is missing; done Thanks for improvements. If I understand correctly the issue, if e.g. the macro HAVE_XXX is not defined on config.h, then the code sorrounded by #ifdef HAVE_XXX ... #endif will never get compiled (except if someone adds -DHAVE_XXX to CPPFLAGS), right? yes. Might it be the case that some of this code is actually old/deprecated and just needs to be removed? After all, it's never compiled, who would need it... The two cases (forgotten config.h.in entry and obsolete code) cannot be distinguished from each other automatically. One of them is a bug. It might also be good to report the problems upstream where possible. Sure. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
On the recent removal of Bison from Chapter 5
Hello, Bison has been removed from Chapter 5 recently. This prevents me from fixing a Coreutils bug with the following patch: http://www.linuxfromscratch.org/~alexander/patches/coreutils-5.2.1-dateseconds-1.patch The reason is that the patch modifies the gedtade.y file, and the Makefile wants to generate getdate.c from it. There are two possible solutions: 1) Patch the generated file: http://www.linuxfromscratch.org/~alexander/patches/coreutils-5.2.1-dateseconds-2.patch 2) Install Bison in Chapter 5. I prefer (2) since patching generated files is not a good idea in general. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposal: proactive search for autofoo bugs
Bryan Kadzban wrote: Alexander E. Patrakov wrote: The two cases (forgotten config.h.in entry and obsolete code) cannot be distinguished from each other automatically. One of them is a bug. I thought manually setting up config.h.in was obsolete -- aren't people supposed to be using AC_DEFINE/AC_DEFINE_UNQUOTED in their configure.ac file, and then have autoheader take those declarations and turn them into config.h.in files? Correct. But it's easier for the script to base its checks on the contents of config.h.in, not configure.ac. Depending on the developers' version of autoheader, it might be possible to fix this by just running it on either configure.ac or configure.in (for the packages that still use the old filename). No, if the relevant check is not in configure.ac. Please provide the sequence of autocommands that actually fix the gawk-3.1.5 bug :) -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Matthew Burgess wrote: Andrew Benton wrote: so do we need the hotplug scripts? Will they ever be used for anything? Is it ever called? I don't think all device subsystems are udev-compatible at the moment (the 'input' subsystem rings a bell here). Additionally, I don't think we handle 'coldplug' events correctly, somewhat ironically, without the 'hotplug' scripts around. Alexander will no doubt correct me on the above though :) Well, the main two reasons for including hotplug were: 1) Coldplugging (this includes not only loading modules, but also setting permissions on /proc/bus/usb/xxx/yyy by e.g. SANE and gPhoto2 -- but BLFS uses the usb group hack instead of those hotplug handlers) 2) Hotplugging. Hotplugging can be done by Udev now, and it calls /etc/hotplug.d/whatever just as good old /sbin/hotplug did. But in /etc/hotplug.d are scripts from the Hotplug package (they calll agents in /etc/hotplug). Of course they can be replaced with udev rules from hotplug-light, http://www.bofh.it/~md/debian/ (requires linux = 2.6.12, for installation instructions view debian/rules) Coldplugging is a bit more problematic. hotplug-light does load modules, but does not recreate USB hotplug events correctly. This breaks chmodding pseudofiles in /proc/bus/usb/xxx/yyy when USB host controller is compiled as a non-module, and thus it will make my scanner inaccessible for non-root when BLFS finally moves from the obsolete usb group hack to the proper hotplug handlers. There are two solutions discussed not long ago upstream. One is to make an initramfs that captures all early hotplug events, starting from the event with SEQNUM=0, and then replays those events when the root fs is mounted (basically, a better reimplementation of http://bugs.linuxfromscratch.org/show_bug.cgi?id=868 ). This is already available with recent udev releases. In this approach, there's no concept of coldplugging at all. The downside is that races are almost unavoidable. Another solution is to put event replaying logic into udevstart. The downside is that approach is fragile WRT changes in the correspondence between hotplug variable names and sysfs attributes. Also, there were some objections on the list, like this is not the task of udevstart, please at least put it into a separate binary. Noe that there's no implementation of this in the existing udev versions. As for the input susbystem calling /sbin/hotplug directly and not duplicating events on the netlink socket, that's OK if you don't rely upon input module autoloading (e.g. for psmouse). Back to the original question: Hotplug is not needed for a minimal system. Its use in LFS is limited to hardware detection facilities (compare /etc/sysconfig/modules in LFS-6.1 with LFS-6.0), and BLFS doesn't use hotplug yet. But it is useful. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Jürg Billeter wrote: (about udev workflow) If you need more details or see potential problems, just mail. Thanks. When I said about races that are hard to avoid, I just meant I have to inspect this because there were races in the past. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remove inetutils from LFS [was Re: GCC-4.0.1]
Bruce Dubbs wrote: Personally, I would like to use the ping and perhaps ping6 programs from iputils and move ncftp from blfs to lfs. ncftp has no prereqs. Why ncftp? I vote for Lynx for the following reasons: 1) It would also allow the reader to read the BLFS book :) 2) It supports HTTP 3) It is an optional dependency of Man-DB (to be used instead of Man in the UTF-8 branch of the LFS book) -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --disable-nls
Greg Schafer wrote: Alexander E. Patrakov wrote: No, it was added deliberately in order to avoid binutils dependency on the host gettext. So Binutils won't build with NLS if Gettext is missing on the host? Right. Hmmm, interesting. Is this a FSF or HJL thing or both? I've just noticed that Binutils-pass2 also has --disable-nls. Hmm, OK. That is certainly good reason to pass '--disable-nls'. This is at least for HJL. Not tested with FSF. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remove inetutils from LFS [was Re: GCC-4.0.1]
Jeremy Huntwork wrote: Alexander E. Patrakov wrote: 3) It is an optional dependency of Man-DB (to be used instead of Man in the UTF-8 branch of the LFS book) Hrm? Has there been some decision there I've missed? No decision yet, but a proposal :) UTF-8 branch of the book doesn't exist yet, but I am working at the patch to XML sources of the book at home. You can also see that Man-DB is already used instead of Man in UTF-8 related branches of the Live CD. Man requires some non-trivial configuration in UTF-8 locales (see man-i18n hint), while Man-DB works out of the box (this is a sufficient reason to keep Man-DB on the UTF-8 CD even if LFS doesn't accept that). Also, Man forgets to recode its output (e.g. translations of What manual page do you want?) from the translator's charset to the reader's charset. This leads to unreadable text (well, LFS passes -lang en and thus doesn't have this problem by default, but it's better to pass +lang none in order to avoid messages about missing translations). Maintainer knows about the problem, but it is not going to be solved anytime soon. On the other hand, Man-DB uses gettext instead of catgets and thus gets this recoding for free. Fedora, as usual, applied the patch to Man that fixes man's output for UTF-8 users but breaks it for non-UTF-8 users. For LFS, such regression is not acceptable. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sed assumptions
Randy McMurchy wrote: Ken, be more deliberate. Say this instead. The book needs to be fixed at the GCC-Pass2 instructions in Chapter 5 because it uses what may be an unsupported sed command. Better yet, just jump in there and fix it yourself. :-) Will that really help? At some time in that past glibc build system used sed -i. Are you sure that other Ch5 packages don't do the same? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Pushing UTF-8 support into LFS
Tushar Teredesai wrote: On 8/6/05, Alexander E. Patrakov [EMAIL PROTECTED] wrote: a sample LFS-like system that supports UTF-8 is available on a live CD. So, it may be a good idea to create an experimental branch of the LFS book that incorporates the same changes. LFS built according to that branch should work in both UTF-8 and traitional locales. So, patches that make things work in UTF-8 but break the non-UTF-8 case are a no-go. Are there plans to incorporate UTF-8 support into LFS and BLFS? Only after September, 4. I am busy with the classroom before that date. After that, I will send a patch to the XML sources of the book if there are no objections. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc4 - proposed changes to glibc check
Ken Moffat wrote: Thanks, I'm only really concerned about chapter 6 at the moment. I seem to remember somebody (Alexander, perhaps) suggesting that the correct method is to install the required locales, which for me equates to the minimal locales. I'll go with all locales if that turns out to be the official recommendation. I did recommend installing only wanted locales, but that's a workaround for BLFS bug. The bug is that GDM chooses (not well supported) UTF-8 locales in preference to non-UTF-8 ones if one selects a non-default language on the login screen. Since there will be a branch that adds some patches to address UTF-8 problems, this will become a non-issue for that branch. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bug in LFS?
Jeremy Huntwork wrote: Using the same driver, so must be a hardware specific thing. It's not a very old machine either... No, it is not the same driver, because the UDMA line is missing. My guess so far is: 1) If the relevant IDE chipset driver is present in the kernel, locking works. 2) If the generic IDE driver is used because the proper one is missing, locking doesn't work. Of course I should have checked it before posting, but I have very little time now. A test would be to configure the relevant IDE chipset out of the kernel and see if locking breaks. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Udev configuration changes
Archaic wrote: On Tue, Sep 13, 2005 at 06:35:52PM -0400, Bryan Kadzban wrote: Matthew Burgess wrote: ### RATIONALE FOR REMOVAL ### ptmx - isn't directly accessed by a user. /etc/fstab dictates pty perms That's incorrect; this change would break PTYs completely. And apparently your statement is also incorrect because ssh can properly create ptys all day long with the proper permissions. So apparently a closer look into both scenarios is warranted. LFS installs the script program. PTYs must be available for it to work. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: some minor bootscript things
Archaic wrote: Before you send patches, they need to work on ash as well, which IIRC, is the closest representation of the original bourne shell. But do we need a closest implementation of the original bourne shell or something that strives to be POSIX-compliant as much as possible? In the latter case, take a look at posh: http://freshmeat.net/projects/posh/ -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Character problems from the 0906 GCC4 build
William Harrington wrote: Hello all, Maybe someone else has this problem or can provide some kinda of direction: Problem: Strange characters using en_US using the GCC4-20050906 book. example: lmsensors output with en_US or en_US.utf8: CPU: +25°C (low = +0°C, high = +75°C) lmsesnsors output with en_US.iso88591: CPU: +25 C (low =+0 C, high = +75 C) I've had to build the kernel with LC_ALL=C becuase of the strange characters affecting the kernel build, also other source code to stdout will show the same weird character:  That's because you forgot to configure the terminal properly. Standard LFS bootscripts do not have the possibility of putting the Linux console in UTF-8 mode, and many LFS utils (including grep and gawk) misbehave in UTF-8 locales. This will be fixed in LFS only after upstream does it (i.e. in a year or so unless LFS is going to change the notion of upstream to RedHat). This is NOT a gcc4 problem. The degree sign is two bytes in UTF-8: 0xC2 0xB0. When sent to a console that expects ISO-8859-1, that results in the ° output because 0xC2 is ° and 0xB0 is the degree sign. You should direct the output to the terminal that understands UTF-8, and LFS doesn't provide you with this thing. The rest of the report is ignored because you didn't specify the important information: 1) Verify that the locales are properly installed: send the output of locale charmap command in all of the mentioned locales. BTW en_US.utf8 is incorrect, should be en_US.UTF-8 (otherwise the ncurses library misinterprets this string). 2) Glibc version and the list of applied patches. That's because of the strange fact that the output is the same in en_US and en_US.utf8. 3) Are you on Linux console or some (which?) terminal emulator? If on Linux console, which version of LFS-bootscripts and what's in /etc/sysconfig/console? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[OT] Urlich Drepper's viewpoint on LSB
Do you still think the LSB has some value? http://www.livejournal.com/users/udrepper/8511.html -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Time to remove hotplug?
Matthew Burgess wrote: Incidentally, I'd love for someone to draw a nice looking graphic to show how kernel events, udev, hotplug, modules, etc. are all related and how they function together. If a similar graphic could be drawn without the hotplug component in there, a direct comparison would be possible. Any takers? :) The attached gzipped SVG file contains both (open it with Inkscape and print on A4 paper). Common things = gray, added = green, removed = red. Note that /sbin/hotplug is NOT on this diagram, because we immediately set the hotplug handler in /proc/sys/kernel/hotplug to /sbin/udevsend (the time window between mounting the root fs and setting hotplug handler to /sbin/udevsend is ignored). Also, as a kernel driver author, I can say that my framebuffer driver gets sysfs and udev support for free when I call register_framebuffer(). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Time to remove hotplug?
Andrew Benton wrote: If a package in BLFS depends on Hotplug, perhaps a page about hotplug can be added to BLFS? For what it's worth, libusb compiles and works fine for me without the hotplug scripts. Sorry, I was not clear enough in my previous reply. Dependency on hotplug is not acceptable because hotplug's initscript conflicts with udeveventrecorder or whatever from udev you want to handle the cold-plugging case. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
UTF-8 book is ready
Hello, a patch that adds UTF-8 support to LFS is available at: http://www.linuxfromscratch.org/~alexander/patches/lfs_book-r6890-utf8-1.patch The rendered book is available at: http://www.linuxfromscratch.org/~alexander/lfs-book/ Note that there was at least one case where SVN silently merged things incorrectly (chapter05/gawk.xml, already fixed), so read with caution and ignore duplicate commands, if any. What's missing is an exact list of problems with solutions, exact blacklist of BLFS packages, and an instruction how to convert filenames in your home directory to/from UTF-8 (without this, national characters in filenames are unreadable in UTF-8 locales). In fact, I think that the patch made the book much worse for beginners, it adds stuff that hides educational value, and that not all editors understand. A current _documented_ limitation that UTF-8 is not supported, IMHO, better fits with the style of the book. Thus, I object to merging this into trunk until enough questions are asked. A branch is always OK. -- Alexander E. Patrakov -- 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
David Ciecierski wrote: The worst part is that even if you put a lot of work into having UTF-8 support, many packages will not support it, crash or do other nasties. Ideally, BLFS should have warnings on each broken package's page suggesting the readers to avoid its installation if UTF-8 locales are used. Is this sufficient? Of course, for cdrtools there will be a patch since this package is too important to just drop. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc fixcincludes
Greg Schafer wrote: sed -i.bak 's,\./fixinc\.sh,-c true,' gcc/Makefile.in It works for GCC-3.4.x, GCC-4.x and I feel confident in predicting it will continue working well into the future. Of course, the caveat for LFS is that `sed -i' is not guaranteed to be available for GCC-Pass2. I think that it is guaranteed there, because it would have barfed earlier (in glibc Makefiles, unless they fixed that). Anyway, LFS is faulty here because it doesn't explain the minimum required versions of host sortware except the kernel. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Current udev/hotplug setup is broken
Hello, while testing the utf8-newmake CD, I found that it (unlike utf8-r0 CD) won't load usb-storage and sd-mod modules if I plug in my USB MP3 player. The reason is that udev no longer runs programs in /etc/hotplug.d (in particular, usb.agent and scsi.agent). This has also been noticed twice in BLFS: once due to ALSA volume restoration, and the second time due to HAL/D-BUS thingy. Please build the compatibility helper, run_directory: make EXTRAS=extras/run_directory/ and add the following rule: RUN+=/sbin/udev_run_hotplugd I know this is a legacy setup, but the proper pure-udev setup that breaks nothing in BLFS requires linux-2.6.14, patched libusb and mandatory initramfs (and thus cpio-2.6 in LFS) which is IMHO too early to implement. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Current udev/hotplug setup is broken
Tushar Teredesai wrote: On 9/30/05, Alexander E. Patrakov [EMAIL PROTECTED] wrote: I know this is a legacy setup, but the proper pure-udev setup that breaks nothing in BLFS requires linux-2.6.14, patched libusb and mandatory initramfs (and thus cpio-2.6 in LFS) which is IMHO too early to implement. How about a hint then? Later. One hint is alerady pending (printing from windows to CUPS). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Current udev/hotplug setup is broken
Alexander E. Patrakov wrote: Hello, while testing the utf8-newmake CD, I found that it (unlike utf8-r0 CD) won't load usb-storage and sd-mod modules if I plug in my USB MP3 player. The reason is that udev no longer runs programs in /etc/hotplug.d (in particular, usb.agent and scsi.agent). This has also been noticed twice in BLFS: once due to ALSA volume restoration, and the second time due to HAL/D-BUS thingy. Please build the compatibility helper, run_directory: make EXTRAS=extras/run_directory/ and add the following rule: RUN+=/sbin/udev_run_hotplugd Spoke too soon. Corrected instructions: make EXTRAS=extras/run_directory/ make EXTRAS=extras/run_directory/ install # Udev-070 Makefile has a bug here: wrong program is instaled install -m755 extras/run_directory/udev_run_hotplugd /sbin cp ../udev-config-3.rules /etc/udev/rules.d/25-lfs.rules echo 'RUN+=/sbin/udev_run_hotplugd' /etc/udev/rules.d/25-lfs.rules echo 'RUN+=/sbin/udev_run_devd' /etc/udev/rules.d/25-lfs.rules install -m644 -D docs/writing_udev_rules/index.html \ /usr/share/doc/udev-070/index.html Confirmed working on the utf8-newmake CD. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [OT] Re: Commit 6803 contains invalid char on commit log
Alexander E. Patrakov wrote: I suggest dumping and restoring. With my toy repository at file:///home/patrakov/svn-test, the sequence of actions is: snip I understand that with fsfs this sequence of actions may be suboptimal. With fsfs, that's as easy as editing /home/svn/repositories/LFS/db/revprops/6803 on belgarath. Don't forget to change V 160 to V 161. BTW it looks like I have enough permissions to do that :) Do you want me to fix the log or prefer doing that yourself? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [OT] Re: Commit 6803 contains invalid char on commit log
Anderson Lizardo wrote: Alexander E. Patrakov wrote: With fsfs, that's as easy as editing /home/svn/repositories/LFS/db/revprops/6803 on belgarath. Don't forget to change V 160 to V 161. BTW it looks like I have enough permissions to do that :) Do you want me to fix the log or prefer doing that yourself? Go ahead and fix it :) Done. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
glibc bug in LFS-6.1 and its nALFS profile (was: Help for building LiveCD)
Steve Prior wrote: Alexander - any chance of an upcoming revision of the LFS-6.1 Live CD which uses glibc 2.3.5 to resolve the ssh privsep issue? (aka http://blfs-bugs.linuxfromscratch.org/show_bug.cgi?id=1534, it's a good candidate for the LFS errata page.) Tough question. The problem while Jeremy Huntwork was the project leader was that exactly the same versions of packages had to be used in the book and on the LiveCD (with the exception of ncurses because of xterm -lc compatibility needed for i18n purposes). I'd rather ask Justin to build the 6.1-4 CD with the following fixes: * binutils md5sum issue resolved * glibc-2.3.4 with the patch from http://sources.redhat.com/ml/libc-hacker/2005-02/msg5.html This, however, still brings up the issue that the nALFS profile on the CD doesn't contain the glibc patch, so this CD would be rather useless right now. I CC:ed the ALFS list, let's see if they do something for us first. In the meanwhile, you can just use the 6.x-utf8-r0 CD: it contains glibc-2.3.5, but it is not based on any released LFS book. But it still contains a profile that builds glibc-2.3.4 without the patch :( -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
Jeremy Huntwork wrote: Ken Moffat wrote: I haven't been paying a lot of attention to this thread, but I thought somebody mentioned a glibc upgrade to 2.3.5 ? Now, that version worked fine for me (but then, so did 2.3.4, and even openssh on x86), but I don't think it's been tested in the context of BLFS-stable ? Sure, we all used it with gcc-3.4.4, but BLFS-dev has moved on to gcc-4. If somebody cuts a 6.1.1 branch with glibc-2.3.5 and gcc-3.4.4, that all needs to be tested. I was thinking of the suggestion that Alexander made in the BLFS bugzilla: using the glibc 2.3.4 patch. About that particular bug, though, I'd like to ask again, what steps are necessary to reproduce it? I've never seen it and I've used the 6.1-x LiveCDs extensively which supposedly contain the bug. To reproduce: install openssh 4.x on the 6.1 livecd (currently we use 3.9 there because of this bug). Change the root password. Start the ssh daemon. Attempt to connect to this server using the correct password. You will not be able to get to a shell prompt because connection closed unexpectedly. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: FC4 host (was Re: [RFC] LFS-6.1.1)
Greg Schafer wrote:
Alexander E. Patrakov wrote:
5) Blacklist Fedora Core 4 since it can't build binutils.
Huh? Stable or development LFS?
Stable, i.e. 6.1
Could you please supply details of the problem?
This is from the current development LFS LiveCD, not FC4, but I assume
the problem is the same:
make[3]: Entering directory `/tmp/binutils-build/gas'
gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.15.94.0.2.2/gas -I.
-D_GNU_SOURCE -I. -I../../binutils-2.15.94.0.2.2/gas -I../bfd
-I../../binutils-2.15.94.0.2.2/gas/config
-I../../binutils-2.15.94.0.2.2/gas/../include
-I../../binutils-2.15.94.0.2.2/gas/..
-I../../binutils-2.15.94.0.2.2/gas/../bfd
-I../../binutils-2.15.94.0.2.2/gas/../intl -I../intl
-DLOCALEDIR=\/tools/share/locale\ -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -g -O2 -c ../../binutils-2.15.94.0.2.2/gas/app.c
In file included from ./targ-cpu.h:1,
from ../../binutils-2.15.94.0.2.2/gas/config/obj-elf.h:42,
from ./obj-format.h:1,
from ../../binutils-2.15.94.0.2.2/gas/config/te-linux.h:4,
from ./targ-env.h:1,
from ../../binutils-2.15.94.0.2.2/gas/as.h:625,
from ../../binutils-2.15.94.0.2.2/gas/app.c:30:
../../binutils-2.15.94.0.2.2/gas/config/tc-i386.h:443: error: array type
has incomplete element type
make[3]: *** [app.o] Error 1
Does passing --disable-werror help?
No, as there is no -Werror on gcc command line, and compilation passed
past many warnings above that error.
Or maybe we just need to add
the required GCC4 patches to the Binutils version used in stable LFS as
errata.
In binutils-2.16.1, they moved struct relax_type definition from
gas/tc.h to gas/as.h. See backport in the attached patch. This does help
compiling binutils. If there are no other problems further in the build,
please include the patch into 6.1.1 instead of blacklisting gcc4-based
hosts.
I'm a bit mystified as I have received successful bootstrap reports of the
DIY build from FC4 using pretty much the same packages as current
development LFS.
But the problem is in the stable LFS.
Blacklisting any current distro is a major cop-out IMHO. We should be
giving top priority to fixing these kinds of host bootstrap problems.
Probably you are right that such known host bootstrap problems should
be fixed in stable dot releases. The main problem here is that they pop
up only after the release, and there's no way to predict them. Some
warning about the possibility of unknown downgrade issues of this kind
is still appropriate. Let's see if today's DIY-linux buildability
survives after FC5 or FC6 comes out.
BTW also the following text should be changed in the book:
--disable-nls
This disables internationalization as i18n is not needed for the
temporary tools.
Should be:
This avoids the dependency on gettext being installed on the host.
--
Alexander E. Patrakov
Submitted By: Alexander E. Patrakov
Date: 2005-10-10
Initial Package Version: 2.15.94.0.2.2
Upstream Status: Backport from 2.16.1
Origin: Alexander E. Patrakov
Description: Fixes compilation by gcc4 (e.g. from Fedora Core 4 hosts)
--- binutils-2.15.94.0.2.2/gas/tc.h 2004-11-22 20:33:31.0 +
+++ binutils-2.16.1/gas/tc.h2005-02-17 13:46:00.0 +
@@ -24,25 +25,6 @@
extern const pseudo_typeS md_pseudo_table[];
-/* JF moved this here from as.h under the theory that nobody except MACHINE.c
- and write.c care about it anyway. */
-
-struct relax_type
-{
- /* Forward reach. Signed number. 0. */
- long rlx_forward;
- /* Backward reach. Signed number. 0. */
- long rlx_backward;
-
- /* Bytes length of this address. */
- unsigned char rlx_length;
-
- /* Next longer relax-state. 0 means there is no 'next' relax-state. */
- relax_substateT rlx_more;
-};
-
-typedef struct relax_type relax_typeS;
-
extern const int md_reloc_size;/* Size of a relocation record. */
char * md_atof (int, char *, int *);
--- binutils-2.15.94.0.2.2/gas/as.h 2004-09-15 19:05:03.0 +
+++ binutils-2.16.1/gas/as.h2005-04-13 17:58:40.0 +
@@ -397,6 +384,22 @@
/* Enough bits for address, but still an integer type.
Could be a problem, cross-assembling for 64-bit machines. */
typedef addressT relax_addressT;
+
+struct relax_type
+{
+ /* Forward reach. Signed number. 0. */
+ offsetT rlx_forward;
+ /* Backward reach. Signed number. 0. */
+ offsetT rlx_backward;
+
+ /* Bytes length of this address. */
+ unsigned char rlx_length;
+
+ /* Next longer relax-state. 0 means there is no 'next' relax-state. */
+ relax_substateT rlx_more;
+};
+
+typedef struct relax_type relax_typeS;
/* main program as.c (command arguments etc). */
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
Jim Gifford wrote: The test case does not give any errors. at all. In cross-lfs we use the glibc-snapshot from 20050926, which this problem has been fixed. You are right, the dlopen-in-chroot problem shouldn't exist in that snapshot. Do I understand correctly that you meant there is also some other bug that can lead to similar ssh failures? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: On removing hotplug from LFS
I wrote some not very accurate things: We do need the new blacklist keyword, in order to emulate the old hotplug blacklist functionality. It is a different question whether LFS targets only single-machine installations (where blacklists are never useful) or also allows to tar up LFS and untar it on a different computer. The LiveCD definitely needs the blacklisting functionality, in order to be able to distinguish between 8139too vs 8139cp and e100 vs eepro100 modules. A replacement for udevstart that walks the entire /sys filesystem (including /sys/bus), thus mostly replacing the old hotplug initscript, is called udevsynthetize (see below). Not 100% accurate: udevstart parses udev rules by itself (that's safe), and udevsynthetize submits messages to udevd for parsing (that's racy). Also the keywords binding of the driver to devices are missing from my mail. Another thing: on request, I will post relevant parts of a sample driver for a simple PCI device (S3 trio 3D/2x video card) here and will do detailed analysis of its sysfs interaction. Alternatively, I can do that for radeonfb or any other well-written PCI/AGP framebuffer driver. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
M.Canales.es wrote:
Hi!
I'm very happy to announce that jhalfs is now able to build a full LFS SVN
system (or any other LFS XML sources based in current LFS SVN) in a very
simple way and using the actual commands found in the XML sources.
The sources can be downloaded via
svn co svn://svn.linuxfromscratch.org/ALFS/jhalfs/trunk
Testers are needed to find possible bugs, features request, code improvements,
make better build logs, etc...
Feature request: don't hardcode target numbers. E.g., in my UTF-8 book,
a new package (gdbm) has been added, thus causing number skew for all
packages after it. Thus, constructions of the following form fail:
if [ $i = 082-groff ] ; then {do something} ; fi.
Until this is fixed, I can't make my UTF-8 book compatible with jhalfs.
BTW, a similar problem will appear soon in trunk due to removal of hotplug.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
UTF-8 book updated
Hello, I have done svn up in my copy of the UTF-8 book, upgraded to ncurses-5.5, improved jhalfs compatibility and fixed typos noticed by Chris Staub (thanks!). The rendered result is at: http://www.linuxfromscratch.org/~alexander/lfs-book/ Known bug (also in trunk): there is no text that explains the need for iocharset and codepage mount options for filesystems with DOS/Windows origin (vfat, isofs, smbfs, ntfs, cifs). A patch against DocBook source in trunk is also available: http://www.linuxfromscratch.org/~alexander/patches/lfs_book-r7003-utf8-1.patch This book itself is compatible with both UTF-8 and non-UTF-8 locales, but in UTF-8 locales some deviations from BLFS are needed. See the bottom of http://www.linuxfromscratch.org/~alexander/lfs-book/chapter07/profile.html for details. Right now I have no opinion whether this should be merged into trunk. UTF-8 locale support is pretty much a requirement for a modern Linux distro, but this adds some packages that absolutely cannot be upgraded before the corresponding distro does that: groff (we follow Debian's fork) and grep (RedHat has some patches that will appear only in 2.5.3). And of course functilnal incompatibility (aka package compiles but is unusable in UTF-8 locales) with the current BLFS. You can also help improving the book by reading the text, building LFS and asking questions. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
Jeremy Huntwork wrote: BTW, has anyone else tried this? The showstopper is in /home/lfs/.bash_profile: the su command starts a shell that, as a result, waits for user input. I deleted that file. Can't test any further because of problems with electrical power (aka brownout) in the house. My computer frequently spontaneously reboots (can't even build binutils), and there's no hope for a fix in the next two weeks because nobody is responsible for the faulty piece of line. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
Ken Moffat wrote: On Sun, 9 Oct 2005, Matthew Burgess wrote: 4) Do something with the udev configuration vs. /etc/group conflict reported in bug 1639. How about the udev version ? Should we stick with 056 or upgrade it to 070 ? (I seem to remember that something newer than 056 was needed for newer kernels at some point, but maybe that was only a problem when booting.) New kernels explicitly mention new udev in their README files. So, if we are going to use 2.6.12.x (is 2.6.11.12 still safe?) then we should also upgrade udev. But if udev is upgraded, please don't use broken instructions from trunk. See http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-September/053532.html -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
I wrote: M.Canales.es wrote: El Sábado, 15 de Octubre de 2005 04:54, Alexander E. Patrakov escribió: 1. For the UTF-8 book, it is also needed to download glibc-libidn-2.3.5.tar.bz2 from lfs-matrix. Please handle this similarly to glibc-linuxthreads and bash-doc tarballs. This and the groff-patchlevel issue should both be fixed now. Thanks. Can you verify it? I will do that tomorrow. Today I am busy with my LiveCD. Sorry, I could not do that. I bought an UPS, but many short periods of insufficient utility voltage have depleted its battery. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 in {,B}LFS
Richard A Downing wrote: Alexander E. Patrakov wrote: Richard A Downing wrote: there may well be some packages we should add that ONLY work in Chinese or Japanese in the longer term (we may be asked to do this by new friends, and we should be open to that idea). I emphasise though that this needs to be driven by those who can validate it, not by expecting Randy and Bruce and the rest of us to understand how Chinese syntax works (I can do Japanese at a pinch, though). Could you please download the latest UTF-8 livecd: http://ums.usu.ru/~patrakov/lfslivecd/lfslivecd-x86-6.x-utf8-r1-nosrc.iso and verify that Japanese (via Anthy + SCIM) works correctly in X? The setup differs from what is described in jlenv.txt hint because I wanted to aviod daemons as much as possible. Sorry for not including jfbterm. Alexander, When I say 'at a pinch', I mean: with quite a lot of trouble to set it up. The input method should authomatically be configured when you select Japanese from the menu during the boot process. Any need to configure anything else manually should be treated as a bug in this CD. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
Jim Gifford wrote: Translated for Cross-LFS would be. -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \ -Dprivlib=/usr/lib/perl5/5.8.7 \ -Dsitelib=/usr/lib/perl5/site_perl/5.8.7 \ -Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.7 \ -Darchlib=/usr/lib/perl5/5.8.7/x86_64-linux What bothers me is that there's no vendor_perl directory in the stock LFS installation. I agree with the rest for multilib. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev changes
Duncan Webb wrote:
Matthew Burgess wrote:
Forwarding from blfs-dev, where an ALSA related thread went just a
little off-topic for BLFS :)
2) Add these two rules to LFS default rules file:
ENV{UDEVD_EVENT}==1, RUN+=/sbin/udev_run_hotplugd
RUN+=/sbin/udev_run_devd
Don't think that RUN+=/sbin/udev_run_devd is requires for LFS as it
doesn't use devfs any more.
This is not for devfs! This is for compatibility with obsolete packages
that still install scriptlets into /etc/dev.d. I.e., after /dev/lp0 is
created, this rule executes the following scripts if they exist:
/etc/dev.d/lp0/*.dev
/etc/dev.d/printer/*.dev
/etc/dev.d/default/*.dev
This may be used in order to download firmware into certain printers
(/etc/dev.d/lp0/firmware.dev contains #!/bin/sh cat firmware /dev/lp0
then). More modern approach is to use RUN+=... rules instead of dev.d
scriptlets. BTW BLFS 6.1 uses a dev.d scriptlet for ALSA volume
restoration (BLFS SVN converted this to the RUN rule).
So you are right that LFS and BLFS SVN contain no such obsolete packages
that need /etc/dev.d.
I think that you can also add:
Add the rules to /etc/udev/rules.d/60-hotplug.rules
#
# usbfs-like device nodes
SUBSYSTEM=usb_device, PROGRAM=/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D', SYMLINK+=%c
Only after linux-2.6.14 please, and synchronously with patching libusb
in BLFS and removing the /proc/bus/usb mount. But those rules will of
course do no harm with earlier kernel.
# be backward compatible for a while with the /etc/dev.d and
/etc/hotplug.d/ systems
# run /etc/hotplug.d/ stuff only if we came from a hotplug event, not
for udevstart
ENV{UDEVD_EVENT}==1, RUN+=/sbin/udev_run_hotplugd
Correct. But that alone doesn't run /etc/dev.d stuff, you need
RUN+=/sbin/udev_run_devd for that.
I'm not 100% sure but I think that pciutils (plus
pcimodules-pciutils-2.1.11.diff patch) and usbutils are also needed.
They are needed with 2.4 kernels only (i.e.: not needed at all in LFS)
for hotplug to work correctly. All the needed information is gathered
from sysfs with 2.6 kernels.
To log hotplug events you could also add:
What's wrong with the current way to log events into
/var/log/hotplug/events?
BTW Acpid is also quite useful for laptops and powering down by a quick
press of the power button.
Sure! but that's on-topic for blfs-dev.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Udev changes
Duncan Webb wrote:
Alexander E. Patrakov wrote:
Duncan Webb wrote:
Matthew Burgess wrote:
# usbfs-like device nodes
SUBSYSTEM=usb_device, PROGRAM=/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D', SYMLINK+=%c
Only after linux-2.6.14 please, and synchronously with patching libusb
in BLFS and removing the /proc/bus/usb mount. But those rules will of
course do no harm with earlier kernel.
Well, linux-2.6.14 is out. But should this rule (that only adds a
symlink) be a part of LFS or BLFS? In this form plus GROUP=usb, I prefer
BLFS. If we change this rule to use NAME instead of SYMLINK (so that
/dev/bus/usb/1/2 is a device node, not a symlink to /dev/usbdev1.2),
then the answer should be exactly the same as for ALSA rules.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
binutils-2.16.1-posix-1.patch
Hello, the patch named binutils-2.16.1-posix-1.patch is currently used in cross-LFS, but not in the regular LFS. It fixes some calls to head and tail, for POSIX compliance. It has nothing to do with cross-compilation techniques and thus has to be present either in both cross and non-cross books, or in none. The question is whether both or none is the correct answer. AFAIK there are no hosts in the real world that don't understand tail -1, and the new version of coreutils says that disallowing this syntax was a mistake. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: config.site
Archaic wrote: One thing that sounds interesting is to not use it in LFS, but use it in BLFS. That way people learn both methods. If that is not feasible for BLFS, then I don't think it should be in just the LFS book as removes the need to do things manually. Repetition is good for learning while building LFS. Yes, in the current normal LFS, this config.site file can be really used for --prefix=/usr only. But let's move forward. There's no /usr/info, /usr/doc and /usr/man compatibility symlinks in FHS 2.3, and LFS still has them. In order to remove them, we must add --mandir and --infodir to each package (and thus teach people bad habit of typing long commands when shorter ones work), or use config.site. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: kmod.c
Jeremy Huntwork wrote:
Heya,
These instructions appear at least in the x86_64 Multilib CLFS book. (I
didn't check the others):
Also, ensure that the kernel does not attempt to pass hotplugging
events to userspace until userspace specifies that it is ready:
cp kernel/kmod.c{,.bak}
sed 's@/sbin/hotplug@/bin/true@' kernel/kmod.c.bak kernel/kmod.c
However, it looks like this has been removed from development LFS. From
my understanding this is no longer needed.
Comments anyone?
It was never needed if the root fs was mounted read-only in grub kernel
line.
With old LFS-bootscripts, mounting the root-fs read-write in grub kernel
line would result in
http://bugs.linuxfromscratch.org/show_bug.cgi?id=842 which at that time
rendered the system unbootable. Now that check is gone, so the system is
bootable, but such premature hotplug events would create junk devices
before tmpfs is mounted on /dev.
Note that the hotplug event for /dev/vcs0 is almost guaranteed to reach
/sbin/hotplug before /dev is mounted, because it is generated when
/sbin/init opens /dev/console for the rc script.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
udev-config-5.rules
Hello, there's a new (unofficial) udev-config-5.rules file on downloads.linuxfromscratch.org. One thing is still wrong with it. Sorry for not notifying in time. It creates /dev/device-mapper, while the proper name should be /dev/mapper/control. Rule: KERNEL==device-mapper, NAME=mapper/control Or even better: KERNEL==device-mapper, NAME= since this node can be created both by dmsetup mknodes and by vgmknodes. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bug 1642
Archaic wrote: After some time spent chatting with Alexander in IRC, here is my understanding of the initial part of the bug dealing with the SUPPORTED file: 1) make localedata/install-locales will run a localedef for every locale listed in the SUPPORTED file Correct. 2) if someone wants to go with the individual localedef commands, yet needs a locale not included in the book, they can get the command syntax from the SUPPORTED file (which makes it handy to have around) ex: there is a line in that file that says kk_KZ/PT154 so the localedef command would be localedef -i kk_KZ -f PT154 kk_KZ Yes. This combines the charset-independent locale description from /usr/share/i18n/locales/kk_KZ with the character map described in /usr/share/i18n/charmaps/PT154.gz, and appends the resulting kk_KZ locale to /usr/lib/locale/locale-archive. 3) The SUPPORTED file lists only the locales that are currently supported and somewhat tested by the glibc maintainers, however many others work that are not in the file. According to Patrakov, those others are best left as an advanced topic outside the book (would a link be apropo?) I'm not aware of those extra locales are for the more obscure country codes or what. Alex can probably shed some light on that. Yes, it's an advanced topic that cannot be covered fully in the book. But the fact is that one sometimes can run localedef and produce a fully-working locale not mentioned in the original contents of this file. I want this fact to be mentioned (and in fact it is already mentioned in the UTF-8 book). Of course those who make use of it are on their own. So basically, the question is whether or not the SUPPORTED file should be installed in /usr/share/i18n for documentational purposes and what, if anything, should be done for locales that aren't listed in the file, but work. Apparently, some distros patch the file before building glibc so that extra locales will be installed. After installation, though, SUPPORTED becomes only a doco file. The summary is correct. As for installation of this file as a documentation for future reference when choosing a locale, this may be sometimes useful when deciding whether to drop the charset field. No guarantees exist though. This is just a list of locales to try and see if they work. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bug 1642
Matthew Burgess wrote: I think it's reasonable to install the SUPPORTED file in /usr/share/i18n and explain its usefulness in the book. I don't think we should alter the file in any way - if there are other locales that happen to work, we'd need to enquire with upstream whether that's merely accidental, or whether they are officially supported (and therefore SUPPORTED needs to be updated). For 8-bit locales, that is not by accident. We can then ask folks to ensure that the locale our heuristic resulted in also appears in /usr/share/i18n/SUPPORTED. If it does, everything's great, if not, use the closest thing that *is* in the SUPPORTED file. The non-UTF-8 locale our heuristic results in will almost never appear in the SUPPORTED file as-is. In most cases, the charset field will be dropped. This will be a synonim for glibc, but may or may not be a synonim for other applications. However, just because it's in SUPPORTED doesn't mean to say that broken packages like Xlib will work, right? Unfortunately, right. If Xlib still doesn't work correctly with a SUPPORTED locale, what other options do we have? Trying the locale our heuristic resulted in (i.e. not dropping the charset field), googling, looking at what the host distro uses. Whatever it is (aside from patching Xlib), will surely result in recommending a non-SUPPORTED locale which I don't think we want to do. It is OK to recommend any locale (i.e. any synonim of a locale listed in the SUPPORTED file) if applications work. The main test is NOT to look into the SUPPORTED file. It is to run the example locale commands at the bottom of the proposed text, and to run an Xlib-based application. Unfortunately at least one case is known (against Xlib) where a locale listed in the SUPPORTED file doesn't work with Xlib, but the locale with an explicitly specified charset works. So the SUPPORTED file is mainly a hint that helps determine whether dropping the charset field is safe-for-glibc. So the summary is: The SUPPORTED file contents are just one more heuristic, known to be not 100% accurate. No single 100% accurate heuristic is known yet, and I am not sure if it exists at all. The UTF-8 LiveCD uses a table containing apparently-working locale values. Combining the two heuristics (i.e. trying both with the charset field in the canonical form, and, where this results in a synonim for glibc, without this field) is hoped to give good-enough results. It is even more important that readers should know how to detect failing locales, i.e. know the relevant error messages. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[Fwd: Re: Which version of 2.6.11 is most stable]
That's something to consider for 6.1.1 release. Looks like we really have to bump the kernel version or hunt for the security fixes ourselves :( -- Alexander E. Patrakov ---BeginMessage--- On Mon, Nov 07, 2005 at 03:38:13PM +0530, Mukund JB. wrote: Dear All, I am in the phase of development of a Linux BSP for 2.6.11 kernel. Which version of 2.6.11 kernel can be called best stable? In general where do i get this king of info? I serched in the www.lwn.net but i failed to get the required info. The latest, IOW 2.6.11.12 . But note that the 2.6.11 branch is no longer maintained since kernel 2.6.12 was released 5 months ago, and therefore lacks e.g. current security fixes. Regards, Mukund Jampala cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ---End Message--- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: kmod.c
Nathan Coulson wrote:
On 11/2/05, Alexander E. Patrakov [EMAIL PROTECTED] wrote:
Jeremy Huntwork wrote:
Heya,
These instructions appear at least in the x86_64 Multilib CLFS book. (I
didn't check the others):
Also, ensure that the kernel does not attempt to pass hotplugging
events to userspace until userspace specifies that it is ready:
cp kernel/kmod.c{,.bak}
sed 's@/sbin/hotplug@/bin/true@' kernel/kmod.c.bak kernel/kmod.c
However, it looks like this has been removed from development LFS. From
my understanding this is no longer needed.
Comments anyone?
It was never needed if the root fs was mounted read-only in grub kernel
line.
With old LFS-bootscripts, mounting the root-fs read-write in grub kernel
line would result in
http://bugs.linuxfromscratch.org/show_bug.cgi?id=842 which at that time
rendered the system unbootable. Now that check is gone, so the system is
bootable, but such premature hotplug events would create junk devices
before tmpfs is mounted on /dev.
Note that the hotplug event for /dev/vcs0 is almost guaranteed to reach
/sbin/hotplug before /dev is mounted, because it is generated when
/sbin/init opens /dev/console for the rc script.
--
Alexander E. Patrakov
--
What change did that anyway? AFAIK, nothing in the bootscripts
disables hotplugging until we get to the UDEV bootscript. [I also
remember everything from the earlier conversations leading up to this,
but I never got my answer back then]
I don't understand the question. Sorry if I answer something else.
Indeed, nothing in the bootscripts disables hotplugging until we get to
the udev bootscript. This means that such premature hotplug events do
reach udev and create junk device nodes not on tmpfs if there is rw in
the kernel line in menu.lst. Udev also creates its database not on tmpfs
under the same conditions. But now, without the check for udev database
in the udev initscript, creation of such junk is harmless (i.e.: the bug
is still there, but we ignore its consequences). Before we removed the
check, this would result in /dev not being mounted as tmpfs.
Anyway, after Linux-2.6.15 (or even earlier if we apply some patches) we
will remove the hotplug package and /sbin/hotplug (and therefore the
problem) won't exist then.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS Book indention
M.Canales.es wrote: UTF-8 .- Not yet in the official LFS repository (when will be added?), but is the most problematic one. Alexander, if you send to me a patch against current trunk, I will try to create an updated patch against the indented trunk. This will take a bit. For now, you can use http://www.linuxfromscratch.org/~alexander/patches/lfs_book-r7142-utf8-1.patch (there is no rendered book online yet). Note that the patched book is not 100% true: the i18n patch just appeared for coreutils-5.93, while the patched book says it is not available. I hope that I will fix this later today. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Book indention
Alexander E. Patrakov wrote: M.Canales.es wrote: UTF-8 .- Not yet in the official LFS repository (when will be added?), but is the most problematic one. Alexander, if you send to me a patch against current trunk, I will try to create an updated patch against the indented trunk. This will take a bit. For now, you can use http://www.linuxfromscratch.org/~alexander/patches/lfs_book-r7142-utf8-1.patch (there is no rendered book online yet). Note that the patched book is not 100% true: the i18n patch just appeared for coreutils-5.93, while the patched book says it is not available. I hope that I will fix this later today. Fixed. Please use http://www.linuxfromscratch.org/~alexander/patches/lfs_book-r7142-utf8-2.patch instead. Other changes are: * dropped no-longer-needed psmisc patch * XML fixes The rendered book is available at http://www.linuxfromscratch.org/~alexander/lfs-book/ -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Progress of the build order changes
Dan Nicholson wrote: I'm gonna go track down some old posts on the purity tests. Also, if you want to see how Greg does the binary diffing, you can download his build system and have a look through the shell scripts. There are a few functions related to ICA that basically make up the crux of the matter. Could you please tell me where they are stripping out dates from binaries? E.g. the build date is the only difference in /usr/sbin/nscd, as can be verified by the xxd tool. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: grub
Matthew Burgess wrote: Richard A Downing wrote: Is LILO still maintained? Your comments here worry me a lot about the competence of the team writing grub2. Looks like it is - http://home.san.rr.com/johninsd/pub/linux/lilo. The only advantage that I can see from Grub2 over Grub Legacy is it's usable on PPC, x86-64, x86-32 (I think) which means that cross-lfs has fewer bootloaders to worry about. I don't think LILO targets anything other than x86-32, and I'm not sure of its current build requirements. LILO needs only bin86 beyond what the book provides. Also there's a patch for LILO but not for the other bootloaders that allows booting from devices managed by non-standard partitioning schemes such as LVM2. Since my /dev/hda is managed by LVM2, I won't look at anything except LILO. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: grub
Matthew Burgess wrote: Richard A Downing wrote: Is LILO still maintained? Your comments here worry me a lot about the competence of the team writing grub2. Looks like it is - http://home.san.rr.com/johninsd/pub/linux/lilo. The only advantage that I can see from Grub2 over Grub Legacy is it's usable on PPC, x86-64, x86-32 (I think) which means that cross-lfs has fewer bootloaders to worry about. I don't think LILO targets anything other than x86-32, and I'm not sure of its current build requirements. LILO needs only bin86 beyond what the book provides. And it works on both x86 and x86_64. Also there's a patch for LILO but not for the other bootloaders that allows booting from devices managed by non-standard partitioning schemes such as LVM2. Since my /dev/hda is managed by LVM2, I won't look at anything except LILO. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl hard-coded /bin/less
Archaic wrote: On Tue, Nov 15, 2005 at 02:51:40PM -0800, Dan Nicholson wrote: ./configure.gnu --prefix=/usr -Dpager=/bin/less -isR If we remove the Dpager option, do you know if less defaults to /usr/bin/less -isR, or just /usr/bin/less/ Just the place where less is found, without -isR. This is needed for the perldoc script, that displas ^]... instead of showing bold text if the -Dpager=... option is not given. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
