Re: 6.1 release branch, /etc/profile locale specification
On Wed, Apr 06, 2005 at 08:49:17AM +0600, Alexander E. Patrakov wrote: .. Alexander, thanks for all the input. As a native english speaker who only *occasionally* has need to write in Greek, I haven't spent much time investigating it and instead just use a TTF font that is encoded in 8859-1 and has a few microsoft symbols in it. I would like to get away from reliance on openoffice and would like to expand into UTF-8 so I could eventually write Greek text docs or html in vim instead. Not having much free time, could you suggest some docs to get me started? (X-posted to lfs-chat. Please reply there.) -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Boring statistics [ was Re: 6.1 release branch ]
On Fri, 1 Apr 2005, Matthew Burgess wrote: PS: SBUs, disk usage and package tarball size reports would be most welcome, from anyone with the necessary scripts to record them. I think the upgraded packages should be pretty accurate, but I've not done a full system build with them yet, so I don't think all stats are up-to-date. These usage (assumed maximum, i.e. generally space used after installing and before blowing away the source) and SBU figures are from a manual build on i586 (I had so much trouble with 6.0 I decided to walk myself through it this time before trying to update my scripts). This is a somewhat slow box ( 1 SBU = 18m25.2 ), with a slow disk, and using a sort of LFS-5.1 host (gcc-3.3.5, binutils-2.14.90.0.8). Worth spelling this out because a small change in the absolute SBU can change some of these values (e.g. pass 2 binutils is actually an exact 1.35 SBU here, rounded to 1.4). Also, of course, some changes on the host might change what gets built and tested in chapter 5 (e.g. missing makeinfo). Looking at the old packages in the book, I begin to think that chapter 5 space and time include running all tests, but chapter 6 don't! Needless to say, my chapter 5 only had the essentials, but chapter 6 had all the tests. My figures are all without CFLAGS, CXXFLAGS, LDFLAGS. We seem to have some inconsistencies creeping in to the presentation - from memory, LFS SBUs should have a resolution of 0.1 SBU and a minimum of 0.1 (I know BLFS goes for a finer resolution now, although I don't believe the figures are that repeatable even on an unloaded box). Also, I think the policy for space used is tenths of a megabyte between 1.0 MB and 10 MB, then whole megabytes - I can't remember what was agreed for packages taking less than a MB. No figures for tarball sizes, mine aren't all in the .bz2 format. Also, no figures for the kernel compile. I've put these all in one sequence, even those where I agree with the book, to make this easier to relate to the book. And I start to wish I hadn't started this, even just putting the data into this mail is time consuming. Anyone for trivial|quick|average|long (times) and tiny|small|average|big|glibc (space) ? Of course, somebody would still have to periodically time and measure to make sure packages were still in the correct category :-( Chapter 5 binutils pass 1 obviously 1.0 SBU, 200 MB here (book 194 MB) gcc pass 1 no comment on space, I used the full tarball, but only 3.9 SBU here, book suggests 4.4 (maybe it hasn't changed since static linking ?) linux-libc-headers-2.6.11.2 obviously 0.1 SBU, 27 MB (book 22 MB) glibc-2.3.4 without locales so only 5.3 SBU 304 MB, you may wish to include the time for some or all locales in the book. tcl-8.4.9 - tried the tests, but I can still only get up to 0.5 SBU (0.3 without), book has 0.9 SBU. Agree 23 MB. expect-5.43.0 (0.1 SBU, 4.0 MB - agree) dejagnu-1.4.4 0.1 SBU fairly obviously, but only 6.1 MB (book 8.6 MB) - like many of these differences, it isn't really worth sweating this, the space is immaterial, but it does make me wonder about some of these figures :) gcc-3.4.3 pass 2 - ok, I used a full tarball, which might add a slight overhead if it goes into directories then finds nothing to do, (although that doesn't seem to show up in pass 1), but mine took 17.1 SBU including the tests. binutils-2.15.94.0.2.2 with tests 1.4 SBU here (I'm not arguing against 1.5), space 144 MB (book 108 MB). gawk-3.1.4 0.2 SBU and 17 MB - agree. coreutils-5.2.1 - my figures are 0.5 SBU and 55 MB, I guess the book includes the tests. bzip2-1.0.3 0.1 SBU and 4.0 MB - book says 2.5 MB. gzip-1.3.5 0.1 SBU and 2.1 MB which is below the book's 2.5 MB. diffutils-2.8.1 0.1 SBU and 5.9 MB (book has 7.5 MB). findutils-4.2.20 I have 0.1 SBU and 8.7 MB, maybe the book includes time for the tests, but its 7.6 MB is low. make-3.80 0.1 SBU and 7.6 MB (book 0.2 and 8.8, again perhaps related to running tests). grep-2.5.1a without tests 0.1 SBU, 4.8 MB (book 0.1, 5.8 - might be related to running tests, but inconsistent with my chapter 6) sed-4.1.4 0.1 SBU, 6.1 MB (book 0.2, 5.2 - maybe the size is from a previous version) gettext-0.14.3 without tests 0.8 SBU, 62 MB (book 0.5 SBU, 55 MB) ncurses-5.4 0.5 SBU, 27 MB (book 0.7, 26) - again, one of hte not very important discrepancies patch-2.5.4 0.1 SBU, 1.5 MB (0.1, 1.9) ditto tar-1.15.1 without tests 0.2 SBU 13 MB (book 10 MB) texinfo-4.8 without tests 0.2 SBU and 16 MB - agree bash-3.0 without tests 0.3 SBU and 21 MB - book longer and bigger, maybe the tests m4 : I used 1.4.2 because that was in the book when this build started bison-2.0 without tests 0.1 SBU and 10.0 MB (book 0.6 and 10.6 - my chapter 6 figures imply 0.8 and 10.2 with tests) flex-2.5.31 without tests 0.1 SBU and 7.9 MB (book 0.6 and 10.6, possibly a dup of the bison values) util-linux-2.12q 0.1 SBU and 9 MB (book 0.2 and 16 MB) perl-5.8.6 0.5 SBU and 80 MB (book 0.8 and 74 MB)
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
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: 6.1 release branch
Bryan Kadzban wrote: So when I got to autoconf, it failed to build, because the chapter 5 Perl did not have Data::Dumper installed (and /usr/bin/perl was in /tools). Oops, missed some words: s/in/looking for it in/ signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Good grief, I'm replying to myself a lot today! Anyway, I just saw what I think is a typo in section 7.4 (in the intro): Device nodes do not require much disk space, so the memory that is used in negligable. That should have an 's/ in / is /' done to it, I think. Also, I missed this in 7.4.2 the first time around: When a new device connection is detected by the kernel, the kernel will generate a hotplug event and look at the file /proc/sys/kernel/hotplug to find out the userspace program that handles the device's connection. The udev initscript registered udev as this handler. It actually registers udevsend as the handler, not udev. udevsend serializes events and then passes them to udev, IIRC. Maybe make the end of the last sentence look like: registered udevsend (which runs udev) as this handler. instead? signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
On Fri, 1 Apr 2005, Matthew Burgess wrote: Matthew Burgess wrote: Until then, you'll have to wait until I render the book and post a link to it :) OK, it's now rendered and available at http://www.linuxfromscratch.org/lfs/view/testing/. Regards, Matt. Curse you, Red Baron! I've been doing a manual build on my K6 for most of this week, using svn-20050321 but with llh-2.6.11.2. I'd got to the latter part of chapter 6 (file), so it looked as if upgrading the book for the rest of it should be ok. e2fsprogs-1.37 fails `make check' (copied by hand from the other screen) make[1]: Entering directory `/usr/src/e2fsprogs-1.37/build/lib/e2p' LD tst_ostype In file included from ../../../lib/e2p/ostype.c:10: ../../../lib/e2p/e2p.h:5:28: ext2fs/ext2_fs.h: No such file or directory followed by a warning that struct ext2_super_block is declared inside parameter list and parse errors at __u32 and then EXT2_OS_LITES undeclared (par for the course for a missing file, I guess). Gotta go out now, this is just a preliminary heads-up. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Ken Moffat wrote: Did I miss the LFS editorial decision not to test package upgrades ? Ouch! There obviously was no such decision. I did do a 'make check' on the latest version but on my bastardised LFS-6.0 box (i.e. LFS-6.0 with various package upgrades). From that post: Note: if e2fsprogs is already installed on the system, the build error will not trigger. So that's why I never saw it. I simply don't have the time or resources to do a full rebuild every time a package gets upgraded. Thanks for the heads up though, I'll apply the fix later tonight. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Ken Moffat wrote: Confirmed that 1.36 ran check ok, diffed it and realised this is a new test. Google found one thread for e2fsprogs tst_ostype - the fix is at http://www.diy-linux.org/pipermail/diy-linux-dev/2005-March/000490.html Thanks, Greg. Did I miss the LFS editorial decision not to test package upgrades ? FWIW, Ryan asked me last night in IRC to forward a message to lfs-dev that contains a patch which solves this same issue, I believe. Sorry that I was a little slow on the ball. It's sitting in his home directory on belgarath, http://linuxfromscratch.org/~ryan/e2fsprogs-1.37-fix_tst_ostype-1.patch I'll include the actual content here, too. Ryan's message below: Matthew Burgess wrote: b) It fixes a problem reported against the 6.1 branch either on the mailing lists or bugzilla Well, heres a quick one e2fsprogs 1.37 tests are breaking cos of a braindead error where include paths are not being supplied to the build of tst_ostype quick patch attached Regards [R] diff -uNr e2fsprogs-1.37-orig/lib/e2p/Makefile.in e2fsprogs-1.37/lib/e2p/Makefile.in --- e2fsprogs-1.37-orig/lib/e2p/Makefile.in 2005-03-20 07:59:38.0 +1100 +++ e2fsprogs-1.37/lib/e2p/Makefile.in 2005-03-28 13:39:31.0 +1000 @@ -66,7 +66,7 @@ tst_ostype: $(srcdir)/ostype.c @echo LD $@ - @$(CC) -DTEST_PROGRAM -o tst_ostype $(srcdir)/ostype.c + @$(CC) $(ALL_CFLAGS) -DTEST_PROGRAM -o tst_ostype $(srcdir)/ostype.c check::tst_ostype ./tst_ostype == -- Jeremy H. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
On Sat, 2 Apr 2005, Matthew Burgess wrote: Ken Moffat wrote: On Sat, 2 Apr 2005, Matthew Burgess wrote: So that's why I never saw it. I simply don't have the time or resources to do a full rebuild every time a package gets upgraded. Hmm, now I've seen your comment that you hadn't built it all. On the contrary, my comment said that I *did* build e2fsprogs-1.37 and *did* run 'make check' on it. My build environment was such that the bug wasn't triggered though. I meant your comment in the earlier mail when you announced the branch. If I'd noted that at the time, I would have been less surprised. gcc-4 shouldn't pose too many problems - it's just a package upgrade albeit with slightly wider effects than most other upgrades. multi-arch and cross-lfs will pose more of a problem with regard to testing on those hosts and targets, but that is up to those with such hardware to deal with IMNSHO. It's gcc-4 that scares me for the first two or three months (looking at the bigger BLFS picture more than LFS). Some packages will be actively maintained and just need upgrading, some won't have any problems, but I worry how many other old but useful packages will break. But then, I still don't understand why we moved on from egcs-2.91.66 ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch, hotplug
Ken Moffat wrote: Me again, hotplug has `mkdir /var/log/hotplug' - I get cannot create directory `/var/log/hotplug': File exists Thanks Ken. Added to my TODO list. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess wrote: However, for such a trivial one-liner, I'd prefer to go with Greg's `sed' (or a variation thereof) - unless he's going to claim rights over it like he did with a previous effort. Don't be ridiculous. Last time it was a question of attribution. LFS has a poor record of crediting contributions. Just look at the list of past editors who were removed from the Acknowledgments section of recent LFS releases. You would never get away with this if LFS were a software package like GCC or Glibc, instead of a written document. Yes, kudos to Gerard for trying to rectify the problem. But I'm getting off-topic now.. sorry. This time Ken has already pointed out my post via Google. It's an obvious fix anyway. No problem. End of story. For the record, I submitted this e2fsprogs fix to upstream but haven't received any confirmation back yet. I might also submit it to the SF bugtracker but my last effort there has also gone unanswered.. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
6.1 release branch
Folks, I've just created the 6.1 release branch. For the incredibly impatient you can pull it from svn.linuxfromscratch.org/LFS/branches/6.1. Until then, you'll have to wait until I render the book and post a link to it :) The idea is that in roughly 2 weeks we'll release 6.1. So, can everyone please hammer this one to death and report all problems to this list and preferably also to bugzilla so we can keep track of them. Editors: Please *do not* commit to this branch unless: a) It's an obvious typo/spelling mistake b) It fixes a problem reported against the 6.1 branch either on the mailing lists or bugzilla c) The fix has already been applied to trunk/, and therefore the fix is just an 'svn merge' of the exact same change back onto this branch. Regards, Matt. PS: SBUs, disk usage and package tarball size reports would be most welcome, from anyone with the necessary scripts to record them. I think the upgraded packages should be pretty accurate, but I've not done a full system build with them yet, so I don't think all stats are up-to-date. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess wrote: Folks, I've just created the 6.1 release branch. For the incredibly impatient you can pull it from svn.linuxfromscratch.org/LFS/branches/6.1. Until then, you'll have to wait until I render the book and post a link to it :) The idea is that in roughly 2 weeks we'll release 6.1. So, can everyone please hammer this one to death and report all problems to this list and preferably also to bugzilla so we can keep track of them. Editors: Please *do not* commit to this branch unless: a) It's an obvious typo/spelling mistake b) It fixes a problem reported against the 6.1 branch either on the mailing lists or bugzilla c) The fix has already been applied to trunk/, and therefore the fix is just an 'svn merge' of the exact same change back onto this branch. Cool. Now, can we get a overview of where we're headed next? Just would like to see it listed somewhere for reference. ;) -- Jeremy Huntwork -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess escribió en lfs.dev el Viernes, 1 de Abril de 2005 20:22: Editors: Please *do not* commit to this branch unless: a) It's an obvious typo/spelling mistake b) It fixes a problem reported against the 6.1 branch either on the mailing lists or bugzilla c) The fix has already been applied to trunk/, and therefore the fix is just an 'svn merge' of the exact same change back onto this branch. d) Is a PDF look fix ;-) I will start that work the day 9 (I'm very busy at this moment doing the BLFS-6.0 translation). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
M.Canales.es wrote: d) Is a PDF look fix ;-) Of course. I will trust anything from anyone (as long as their name is Manuel :)) that touches stuff in the stylesheets/ directory as there is some serious black-magic juju going on in there :) However, rule c) still applies - i.e. if the fix is common to both trunk and the 6.1 branch, then trunk gets the fix first and it gets merged to the branch afterwards. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess wrote: I've just created the 6.1 release branch. For the incredibly impatient you can pull it from For testers, I just put together a 6.1-20050401 package tarball. It will be available on the mirrors shortly, as soon as they all sync. -- Justin R. Knierim LFS FTP Mirror -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess wrote: Until then, you'll have to wait until I render the book and post a link to it :) OK, it's now rendered and available at http://www.linuxfromscratch.org/lfs/view/testing/. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess wrote: The idea is that in roughly 2 weeks we'll release 6.1. So, can everyone please hammer this one to death and report all problems to this list and preferably also to bugzilla so we can keep track of them. Two issues I've seen so far: 1) The URL for less may not be right. Less-382 is not available at http://www.greenwoodsoftware.com/less/download.html -- I Googled and found it at ftp://ftp.gnu.org/gnu/less/ instead. Less-381 was available at greenwoodsoftware.com, just not 382. 2) The note in section 5.1 about patches may be correct, but it doesn't match what I usually do. The sentences in question: Warning messages about /offset/ or /fuzz/ may also be encountered when applying a patch. Do not worry about these warnings, as the patch was still successfully applied. I usually ignore warnings about offsets (offsets just mean the patch's context has moved), but I try to fix warnings about fuzz (which means patch had to actually *discard* some lines of context to find a match). I had one bad experience with a kernel patch that applied with fuzz a long time ago -- the patched kernel failed to compile. Maybe I'm the only one, but I thought I'd mention it. If I run into other issues, I'll post them then. I've just finished compiling binutils pass 1 (yes, by hand, I have a whole weekend ;-) ). signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Bryan Kadzban wrote: Matthew Burgess wrote: The idea is that in roughly 2 weeks we'll release 6.1. So, can everyone please hammer this one to death and report all problems to this list and preferably also to bugzilla so we can keep track of them. Two issues I've seen so far: 1) The URL for less may not be right. Less-382 is not available at http://www.greenwoodsoftware.com/less/download.html -- I Googled and found it at ftp://ftp.gnu.org/gnu/less/ instead. Archaic pointed out to me on IRC that less-382 *is* actually on the greenwoodsoftware.com site, it's just not listed on the download page. This link should work: http://www.greenwoodsoftware.com/less/less-382.tar.gz But it does raise the question in my mind at least, about which link should be included. Gnu.org in my experience is easy to navigate, consistent, fast and reliable. What do you all think? I've got the book ready to change if it's deemed that gnu.org is the better link. -- Jeremy Huntwork -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
On Fri, Apr 01, 2005 at 09:04:21PM -0500, Jeremy Huntwork wrote: http://www.greenwoodsoftware.com/less/less-382.tar.gz The book doesn't use explicit links to packages. GNU should be used, IMO. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
