Re: glibc-20050321
Robert Connolly wrote: Hi. Uhm, using glibc-20050321. Which binutils version? Since the error is coming from ld, I would suspect that it's binutils first (though that's basically a guess). 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
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: 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
/lfs/view/testing/ ?
FYI, the /lfs/view/testing/ URL disappeared a short while ago from the LFS web server. I keep getting 403 errors when browsing directly to it, and it doesn't show up at /lfs/view/ either. Was this a symlink that got clobbered by the book render perhaps? Or was it supposed to go away? Was it replaced by the 6.1-testing-20050401 link? -- because the SVN date on the old /testing/ book was 20050402, and the current SVN book is dated 20050404 (both are later). 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: /lfs/view/testing/ ?
Matthew Burgess wrote: Bryan Kadzban wrote: I keep getting 403 errors when browsing directly to it, and it doesn't show up at /lfs/view/ either. Yeah, sorry about that. I didn't update the version entities correctly to stop the render-lfs-book.sh script getting all confused. Should be fixed now. Looks like it is, thank you very much! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /var/log/btmp permission problem.
On Fri, Apr 08, 2005 at 02:30:02PM +0100, William Zhou wrote:
The message read as Excess permission or bad ownership on file
/var/log/btmp. After changing to 640, it stops complianting.
That's a little odd. From openssh-4.0p1/loginrec.c:
if((fst.st_mode (S_IRWXG | S_IRWXO)) || (fst.st_uid != 0)){
logit(Excess permission or bad ownership on file %s,
_PATH_BTMP);
goto out;
}
fst is a struct stat obtained from a stat call made on the btmp file.
st_mode is the set of permissions on the file. S_IRWXG is the RWX mask
for group according to the chmod(2) manpage, and S_IRWXO is the RWX
mask for other. ORing them together gives you a mask for all the
permissions given to anyone who is not the owner.
ANDing that mask with the st_mode will give you either 0044 (when the
permissions are 0644) or 0040 (when the permissions are 0640). This
value is always nonzero, so the if check should be succeeding in both
your cases (which means that sshd should be logging errors in both your
cases).
The only time sshd will refrain from logging this message is when no
permissions are granted to anyone except the owner, and when the owner
is root. Therefore, if we want to prevent this message from being
logged, we should be chmod 0600'ing the file, not 0640. (We create it
as root, so the owner should already be root.)
However, depending on the usage of the btmp file, it might be argued
that the LFS book is not the correct place to make this change -- maybe
the BLFS page on sshd would be better. I don't know if that's the case
(I rather suspect that it is not -- I don't think that allowing every
user to read all the bad login attempts is a good thing), but it is
possible.
pgpuoWl7uEMdV.pgp
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS 6.1-testing issues
Bruce Dubbs wrote: Bryan Kadzban wrote: None of your boot scripts (or your login scripts) set stty erase ^H, correct? You never know... Not unless it's done in the lfs-bootscripts. I don't believe it is, because my 6.1 system (using the lfs-bootscripts) doesn't do it. When I compiled the kernel, I turned off Legacy (BSD) PTY support. I'll build another kernel and add that back and see if that makes a difference. I don't think it will -- I have it off here too. But it'd be worth a shot. Did you say you were using some kind of framebuffer console? Does it help at all if you change that, or did you try that already? No. I do use vga=0x0f07 on the kernel line, but that shouldn't affect input. Well, in theory no, but if vesafb (or whatever) uses a different line discipline, it might. 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: Ready for gcc-4 cleaning up binutils source delete or not.
Matthew Burgess wrote: [EMAIL PROTECTED] wrote: I suppose though we'll need 2 host compilers, we'll need a 3.4 for the kernel builds etc Why? I'm just guessing here, but I would bet that it'll be similar to the gcc 2.95 / gcc 3.X upgrade. The kernel documentation said to use 2.95 (and still does, in fact), so that's what we did, until it started causing problems with the NPTL tests. 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: Warning: Do not remove the [xxx] build and/or source directories yet...
Tony Morgan wrote: However, what's missing is a second explicit notice along the lines of Ok - that [xxx] build directory we told you not to remove earlier - it's now safe to erase it. We won't be needing that particular build of [xxx] anymore. In Section 5.8, right after the Note about skipping the command if you don't have binutils: Now that the adjusted linker is installed, the Binutils build and source directories should be removed. And in Section 5.10, last sentence before the contents section: The source directories of both Tcl and Expect can now be removed. ;-) (You do need to keep the binutils-pass2 directories around until chapter 6. But the re-adjusting-the-toolchain section also has a sentence somewhere that says to delete them.) Maybe these should be made to stand out a bit more, using the Note formatting? 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: sysctl script at S90?
Matthew Burgess wrote: I'm hoping the dev.d scripts are all handled asynchrohously - i.e. udev doesn't wait for one to complete before kicking off the next, otherwise boot times might be significantly slowed down with all that spinning. Uh oh. ;-) udev-056 does indeed wait for each of the dev.d handlers to finish before starting the next one. This is handled inside run_program in udev_multiplex.c. (Both udev and udevstart call the udev_multiplex_directory function in that file, which calls run_program.) run_program forks, execs the handler in the child, and has the parent wait for it. However, I think the 1-second wait will probably be the worst case -- I don't think it'll spin around that loop more than once (if it does at all). Even the one-second wait could be reduced if there was a program that used directory-change notifications (inotify? maybe...) to sleep until a directory or file was created or modified, but I don't know of any such program. I'm fairly sure nothing like that is installed on a base LFS system. 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: sysctl script at S90?
Matthew Burgess wrote:
If someone could tell me where to dump the script for
tcp_window_scaling, I'd appreciate it. I've currently got it in
/etc/dev.d/net/ipv4/tcp_window_scaling.dev but it doesn't get called.
Well... this is odd. Nothing in dev.d gets called when a module is
loaded that creates a network interface (or at least, not when the
via-rhine module is loaded). I put a test.dev script (echo $DEVNAME
/home/me/logfile) into /etc/dev.d/default/, and it never ran. Same
if I put it into /etc/dev.d/net/ -- it never ran.
Maybe you need a line in the udev rules file that names the interface
before you can get a dev.d handler to be called? That'd be annoying if
it's true.
Or maybe udev ignores the hotplug events raised by network interface
drivers? It shouldn't do that, but I don't know for sure.
I was thinking /etc/dev.d/net/ would work (that's where the hotplug
agent is run from, which is supposed to call ifup -- though I don't have
that working either, since I have no need for it). My
/var/log/hotplug/events file gets a few entries when I add and remove
the via-rhine driver, and the DEVPATH is /class/net/eth0. So putting
the script in one of /etc/dev.d/{eth0,net,default} should work.
(That's also a reply to your question about where to look. udev runs
dev.d scripts based on the devname (the last part of DEVPATH -- eth0
in this case), the type (the part of DEVPATH after either /class/ or
/block/ -- net in this case), and default.)
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: Bashism in LFS-bootscripts
Alexander E. Patrakov wrote:
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 =.
Or should it be:
if [ $CUR_LENGTH -eq 0 ]; then
instead, to do a numeric comparison? (Either with or without the
quotes. It shouldn't matter unless $CUR_LENGTH might be unset.)
(OTOH, is that a bashism too? I'd hope not, but I don't know for sure.)
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: Bashism in LFS-bootscripts
Robert Russell wrote: On 5/19/05, Bryan Kadzban [EMAIL PROTECTED] wrote: We could use the enable builtin to disable the builtin versions in bash: enable -n test [ I'm (again) not sure about other shells, though... Wouldn't the binaries in /bin be used if the shell did not have builtins? Yes, but the problem would come in if there's some shell out there that does have test and [ builtins, but doesn't have an enable command that we can use to turn them off. For example, the ash(1) man page here: http://www.strw.leidenuniv.nl/cgi-bin/man?program=ashsection=1 doesn't say anything about an enable builtin in ash. It may be that there is no such builtin, which would cause problems if we did that. However, we might be able to do something with exec in a subshell instead (since exec won't run a builtin or function, only an executable): if ( exec [ -r file1 ] ) ; then do_whatever ; fi I can't decide if that's more or less ugly than: if /bin/[ -r file1 ] ; then do_whatever ; fi though. It is a few characters longer, for whatever that's worth. 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: [Fwd: [ANNOUNCE] udev 058 release]
Jim Gifford wrote: May needs some more changes for udev 058 and 2.6.12 kernel. Will check it out. Subject: [ANNOUNCE] udev 058 release From: Greg KH [EMAIL PROTECTED] Also, the rules file structure and use is changing again, in more powerful ways. For more details on this, and if you currently rely on the /etc/dev.d/ feature, please read the RELEASE-NOTES file in the main udev directory. A online version can be found here: http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;h=9b7fa3133013c4dfc1bc5d759cd198e8aafdef83;hb=5e65ab9a191268fec7cddf6b7d8c0fefd2a6b920;f=RELEASE-NOTES Hmmm... looks like dev.d is going away, to be replaced by individual keys in the rules file(s). For example, for the dev.rtc.max_user_freq sysctl that we were talking about a while ago, instead of putting that script into /etc/dev.d/rtc/, it looks like we could put it anywhere, and add a: KERNEL=rtc, RUN=/path/to/the/script to the udev rules file. For the net.eth0.ipv4.tcp_max_whatever_it_was sysctl, it should work to add a rule of KERNEL=eth0, RUN=/path/to/the/script, too. As long as the kernel's name will be set to eth0, anyway. (But I think that setting sysctls late -- at S90 -- is probably good anyway.) 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: [Fwd: [ANNOUNCE] udev 058 release]
Matthew Burgess wrote: Do we need a script for it though? I've not tested it yet (of course! :) ), but this is what I was thinking: KERNEL=rtc, ACTION=add, \ RUN=echo 1024 /proc/sys/dev/rtc/max-user-freq KERNEL=eth0, ACTION=add, \ RUN=echo 0 /proc/sys/net/ipv4/tcp_window_scaling; Obviously, there may be situations where a full-blown script is required, but I'd imagine for the majority of rules a simple one-liner like the above should do the job just fine. If udev allows redirection like that, then yes, it'll work. Otherwise we'd have to start up a shell and do the redirection that way (which is basically the same as a script anyway). (Of course, if the file doesn't exist yet, we're still hosed... but that's no different than before.) 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: Do we need Flex??
Jim Gifford wrote: Jim Gifford wrote: The only one I know if in BLFS is tetex. Correct me if I'm wrong. That is require flex. A lot of developers are moving away from flex. To what? I don't know of any other library that lets you build your own lexer. (Doesn't mean they don't exist, though -- and if they do, I'd like to know what they are.) If there is no other such library, then what do programs that need to parse text (like config files, for instance) use? Do they all just roll their own? That seems a bit wasteful. The obvious answer (for me anyway) to how do I parse a config file is use flex and bison to build a grammar. (Note also that since flex generates a .c file, it's usually run on a developer's machine, and the resulting C file is usually distributed as part of the package. But to link, the package might still require libl.a or libfl.a.) 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: /dev/mouse symlink and the udev rules file [Was 'Re: r175 - trunk' in the li
Marty _ wrote: Why doesnt someone do something sensible and mount devfs to /.devfs Uh... because we don't use devfs? ;-) Bring back the old devices style. udev does (almost completely, anyway), with the rules file(s) we use. One difference is that you won't see devices for drivers you don't load. But seriously, why dont we just mount the device somewhere else and just symlink them across when needed? What's the difference between a directory full of device nodes and a directory full of symlinks? 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: Do we need Flex??
Matthew Burgess wrote: Bryan Kadzban wrote: The obvious answer (for me anyway) to how do I parse a config file is use flex and bison to build a grammar. And the obvious answer to me (being a C++ kinda guy) is to use 'Spirit' from the boost libraries (http://www.boost.org/) :) Looks like it'd work well -- for C++ anyway... ;-) 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: /dev/mouse symlink and the udev rules file [Was 'Re: r175 - trunk' in the li
On Tue, May 24, 2005 at 12:33:39PM +0100, Marty _ wrote: never investigated udev to be quite honest, just thought it was another form of devfs from the guide. It is, in that it dynamically manages the /dev directory. But it does this using hotplug events from the kernel, not code inside the kernel. The default hotplug event seems to give udev a device name, and the default action for udev is to create a file in the udevdir (which we set to /dev) with that name, using the proper major, minor, and type (character vs. block). Some of these are overridden in the rules files (/dev/input/mouse* and /dev/input/mice, for example, and Alsa devices into /dev/snd), because even before devfs, the USB input devices were stuffed under /dev/input. /dev/mouse itself *seems* to be a de-facto standard. It looks like several distros created it so that they could distribute one gpm and X setup, but have it work with several different mouse types (PS/2, USB, busmouse, etc.). The PS/2 driver used to use /dev/psaux. None of that is necessary anymore with recent kernels -- ALL mouse drivers are supposed to use the kernel's input subsystem, which uses the /dev/input/* devices. So under 2.6, even loading the psaux driver will create a /dev/input/mouse0 and /dev/input/mice. Distros could just use /dev/input/mice instead of /dev/mouse. That does fall apart if you use a mouse that isn't supported by the kernel, but requires external drivers instead (some touchscreens apparently fall into this category). If those drivers don't use the kernel input subsystem, you'd need to use their device file. But whatever. To add to your note, there isnt a difference between the two, ive just got so used to slackware's /dev style I couldnt handle the entire directory tree the devfs mount produces. Then you'll probably be happy to know that udev doesn't do that, at least not by default. ;-) pgpsgmsjd5YAE.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Bruce Dubbs wrote: Has it been shown that the current method has leaks from the build system into the new LFS system? If so, I'm not aware of them. Can you point to anything specific? If you use a host with new binutils (2.15.x), but are building old binutils (2.14 was what was current when this issue came up), then after you install the old binutils, linking won't work anymore. gcc's specs file uses --as-needed, because 2.15.x supported it, but the ld from 2.14 will fail because it doesn't support it. This was happening about a year ago, and we eventually fixed it by upping the book's binutils to 2.15.whatever. But similar issues can come up again fairly easily (and will, every time binutils adds a new command line option), and upgrading core system packages (binutils, gcc, glibc) is not necessarily an easy fix if they do. It isn't trivial, in any case. The right fix, at least according to me, is to get complete separation from the host. I.e., cross-build everything, maybe including a kernel, then chroot or reboot (that's where the discussion is centering here, and I don't really care which option we go with -- I'll probably end up building a kernel, booting to it while still using my old system's FSes, then chrooting, because I'll be building on machines that I'm at), then continue. 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: flex-2.5.31
Matthew Burgess wrote: I suppose the 20 line scan.l hunk in it is redundant, though it's not going to save that much space in the grand scheme of things. It won't save space, but removing that file from the patch will prevent scan.c from being rebuilt. Which was (part of) the whole point. ;-) 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: LFS in a rut?
TheOldFellow wrote: Another random synaps when 'Boing!' - can we build Linux-from-Windows? Most of the Cross-LFS book would work if there was a way of building a bootable tool-base ... Cygwin? Can you build a Cygwin to Linux cross compiler? I'd guess so, but I've never tried it. 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: /etc/inputrc textual suggestion
Archaic wrote: FIXME: The following comment needs rewritten # Make sure we don't output everything on the 1 line set horizontal-scroll-mode Off Suggested: # Allow the command prompt to wrap to the next line set horizontal-scroll-mode Off How about: # Allow long commands to wrap to the next line or: # Allow commands longer than the terminal width to wrap to the next line ? 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: [Fwd: Re: r6218 - in trunk/BOOK: . chapter01 chapter05 prologue]
Jim Gifford wrote: Fixing this vulnerability required a change in the Application Binary Interface (ABI) of the kernel. This means that third party user installed modules might not work any more with the new kernel, so this fixed kernel has a new ABI version number. You have to recompile and reinstall all third party modules. I thought people had to do that anyway -- for all new kernels they install? 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: compilation ok, chroot fails
Roberto Nibali wrote: chroot(/var/tmp/LFS) = 0 chdir(/) = 0 execve(/tools/bin/env, [/tools/bin/env, -i, HOME=/root, TERM=linux, PS1=\\u:\\w\\$ , PATH=/bin:/usr/bin:/sbin:/usr/sb..., /tools/bin/bash, --login, +h], [/* 71 vars */]) = -1 ENOENT (No such file or directory) Looks like you maybe don't have a /var/tmp/LFS/tools/bin/env file, so after the code does the chroot, it can't find /tools/bin/env. Was /tools a symlink to /var/tmp/LFS/tools, like in the book? I'm not familiar with the lfs_next_to_existing_systems.txt hint, but did you follow that at all? I would think that if you did, you wouldn't be doing the chroot, though. 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: compilation ok, chroot fails
Roberto Nibali wrote: # /tools/lib/ld-linux.so.2 /tools/bin/env -i PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin /tools/bin/bash --login +h tset: unknown terminal type unknown Terminal type? linux # echo $? 0 # exit logout # So it seems to work, no? It does seem to work, but there's no chroot there either. Try another variant on the above: chroot $LFS /tools/lib/ld-linux.so.2 and then if that works (it'll print a usage message), try: chroot $LFS /tools/lib/ld-linux.so.2 /tools/bin/env -i PATH=$PATH TERM=$TERM /tools/bin/bash +h --login If that works, then double-check env's dynamic loader (run the readelf command on it). (This may be the wrong list now, though. Perhaps -support, since 6.1 is released? Unfortunately I don't really follow -support...) 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: GCC-4.0.1 patch (no_fixincludes)
Matthew Burgess wrote: we've got a fair few branches of LFS kicking around now. I think we could use something like GCC's Active Development Branches section of http://gcc.gnu.org/cvs.html to let people know about them. Or just point to http://www.linuxfromscratch.org/lfs/view/ That's where I go to see the currently-rendering branches, anyway. ;-) (Although actually, I can see how having some sort of explanation might be helpful. Would there be some way of automating that, though, so nobody has to remember to update the list of summaries whenever the rendered branch list changes? Perhaps have the render script pull a summary file out of each branch, and use its contents as the summary text?) 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: Shadow/CrackLib - A compromise?
Randy McMurchy wrote: In the Shadow instructions, a little note at the beginning of the package instructions saying that if you would like the system configured to support strong passwords, install CrackLib and add --with-libcrack to the configure script. It could probably be done in one sentence, two max, with a link to the BLFS CrackLib instructions. Maybe change support to either enforce or require (cracklib doesn't actually change the way passwords are hashed or anything; it just checks them against a dictionary). But yeah, this sounds like a good idea to me. :-) 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: LFS Bootscripts
S. Anthony Sequeira wrote: Since then I have always used the following when searching for a string in a ps listing, assuming that the search string is sys: $ ps -eadf | grep [s]ys root 1604 1 0 12:08 ?00:00:00 syslog-ng here is one that doesn't work: $ ps -eadf | grep sys root 1604 1 0 12:08 ?00:00:00 syslog-ng sherwin 14316 14297 0 20:53 pts/100:00:00 grep --color=auto sys HTH I usually just use ps -C syslog-ng, since I normally know the binary that I'm searching for. I think -C is a Linux extension; I don't think it works everywhere. But given that the bootscripts are *for* a Linux system, I don't think there's much harm in using it. 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: Coreutils binary locations
Matthew Burgess wrote: It appears as though 'tcsh' doesn't, but how many alternative shells should we even care about? Plus, tcsh is a C shell, not a Bourne shell. All the bootscripts are written for a Bourne shell, and will consequently fail horribly if run in csh or tcsh. ;-) So I don't think tcsh not supporting these builtins is a big deal. 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: Proposal: proactive search for autofoo bugs
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? 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). This probably won't tell us which packages needed it to run, but it will fix it. So maybe run the first pipeline first, and then run autoheader to fix the problem if the pipeline shows that something's wrong. 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: Proposal: proactive search for autofoo bugs
On Mon, Aug 15, 2005 at 06:24:50PM +0600, Alexander E. Patrakov wrote: Bryan Kadzban wrote: 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 :) The problem is that the AC_DEFINE / AC_DEFINE_UNQUOTED is not in gawk's configure.ac? In that case, you're right, this fix won't work. I was thinking that perhaps the developers had put the AC_DEFINE* in, but had never rerun autoheader before releasing. Sounds like that's not what happened. So never mind then. ;-) pgp5MZMPRUkek.pgp Description: PGP signature -- 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: Jürg Billeter wrote: If you're (or anybode else is) interested in this topic, I could explain our approach - simplified since event recorder got upstream. Yep, I'd be interested, though never having had to dabble with initramfs or initrd I've no idea on their potential complexity and therefore their suitability for LFS. I'd like to know too. I want to eventually move to an initrd or initramfs setup, and I'd like to move to a store the events, then replay them setup at the same time. To that end, knowing how to do it would be a good idea. ;-) 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: Remove inetutils from LFS [was Re: GCC-4.0.1]
On Mon, Aug 22, 2005 at 12:03:49PM -0400, Jason Gurtz wrote: On 8/21/2005 10:54, Matthew Burgess wrote: ping.c:63 - This program has to run SUID to ROOT to access the ICMP socket. That's crazy. Normal pings shouldn't require root. IIRC, the standard kernel socket interface simply has no way to send any kind of ICMP packet (echo-request included). Therefore, you need to open a raw socket, and write the headers yourself. To create a socket using PF_PACKET and SOCKTYPE_RAW (which I believe is the only way to send ICMP), you must be root. The socket() call will fail if you aren't root, and you pass those flags. It may be possible to use PF_PACKET and SOCKTYPE_DGRAM, but I don't know for sure. (That may require the caller to be root also). This isn't a requirement of the ping program. It's a requirement of the kernel. pgpYCoofaR5bz.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A small compact distro
Dom wrote: Got going, was all going well, and as I come to bunzip the libc-headers in the temporary system (yes, which is extremely early on in the process) and I ran out of space! Have you been deleting the package build directories? (Are those even on the same partition?) Are you building LFS on the same 4G partition as Slackware perhaps? 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: [RFC] Udev configuration changes
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. In order to create a PTY, the master process opens /dev/ptmx. That's the pseudo-terminal master file for every slave that gets created. Then you call grantpt() and unlockpt() on the returned FD, to do some magic. (It's in the manpage, but I'm too lazy to go look at it right now.) Then you call ptsname() on the FD, to get the slave device's name, and finally you can open that slave device. The devpts filesystem creates the *slaves*, not the master. The permissions in fstab must therefore be applied to only the slaves. (And I just tried it, too. I changed the owner and group of /dev/ptmx to root:root 0660, and tried running various programs that I know needed PTYs: $ xterm xterm: Error 32, errno 2: No such file or directory Reason: get_pty: not enough ptys $ /tools/bin/expect -c spawn ls spawn ls The system has no more ptys. Ask your system administrator to create more. while executing spawn ls $ (That last error looks familiar, in fact... ;-) ) printing devices - need non-LFS software to use it Not entirely correct either, although this is similar to the sound devices: If your printer supports PostScript natively, you can cat PS files to your printer device. In fact, even if it doesn't support PS, you can send the output of GhostScript to the printer device (this is one more package, but it's nothing on the order of cups or lprng). (I do this whenever I need to print anything -- I print it to a file, then run the file through GS with -sOutputFile=/dev/lp0.) For that matter, all the device categories that the current config file says devices go in their own directory (sound, input) will now be cluttering up /dev, which is (at least IMO) the Wrong Thing. Even if you can't use them yet, I wouldn't think you'd want 10-15 more devices sitting in the root of /dev -- which is a nonstandard directory for them, no less. 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: [RFC] Udev configuration changes
Archaic wrote: 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. I didn't try ssh. But I did try xterm and expect (both of which use PTYs), and both failed. (Although maybe this is the difference: I did not simply comment out the rule in my udev.conf and reboot. I did a chown 0:0 /dev/ptmx ; chmod 0660 /dev/ptmx as root, then changed to my normal user, then ran xterm and expect. So if my understanding of the default owner:group and permissions is wrong, that would cause my results to be different than yours.) (Wait a minute... sshd runs as root. PTYs work for root. I was not entirely clear in my message -- I should have said this change would break PTYs completely *for non-root users*; sorry for the confusion.) But even if ssh works (because it runs as root), as Alexander said, script requires PTYs, and we all know the expect testsuites do. (I've noticed a lot of BLFS packages have changed to building and testing as a non-root user. Maybe that doesn't matter because it's BLFS -- but script definitely does matter.) If your printer supports PostScript natively, you can cat PS files to your printer device. But you cannot do that without explicitly assigning a non-root user to the lp group. As it stands today, you're right. (But then, that's not non-LFS software either...) LFS will not have that group in the future so it wouldn't make sense to create a device with the same perms it would have by default. Oh, I see what you're saying. Yes, if the group is deleted, the rule might as well go. (From another of your posts in this thread:) Archaic wrote: And now that I think about a previous post that referred to cluttering of the /dev tree, the whole intention of devices is that they are not referenced by name, but by major and minor. Inside the kernel, yes (the kernel decides which code to dispatch a device syscall to based on the type, major, and minor numbers). But userspace requires the files to be in a standard place, because userspace doesn't have any other way of calling into the kernel (other than opening the device file, that is). (Besides, isn't a future kernel still going to remove the static device number allocations and move to a model where register_chrdev (or whatever) dynamically assigns the device numbers?) My reason for bringing that up was partially aesthetic, and partially because Documentation/devices.txt explicitly shows subdirectories for a lot of devices. I believe that just because the user hasn't installed gpm yet (for instance), doesn't mean they should be seeing non-standard device locations for these devices. The original proposal was there to remove groups from LFS, and the more I think about it, the more I'm not sure that's a good idea anymore either (someone else has said this, too), mostly for that reason. I am starting to think that device files are part of the kernel package, and as such, should be configured by LFS, since LFS installs the kernel. Gerard may disagree with this, obviously, and it sounds like he has in the past, so maybe it's a moot point anyway. 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: some minor bootscript things
[EMAIL PROTECTED] wrote: Are there any tcsh users here who could tell me which changes (if any) would be needed for that shell? I have a feeling it'd be way too many to ever make it work... basic things like doing ifs use a completely different syntax, so even your if-elif idea won't work for a C shell. Besides, a C shell is not required by any of the standards that I'm aware of (at least, not the parts of POSIX, SUS, etc. that deal with userland -- LSB might, but then again, I believe LSB also requires RPM). But a Bourne shell of some sort is required. 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: How to use the pkgsrc of NetBSD with LFS?
John Kelly wrote: On Sun, 18 Sep 2005 18:03:12 -0500, Randy McMurchy [EMAIL PROTECTED] wrote: I find it very useful to know how every file on the system was installed, and which package installed it. Why? I can't speak for Randy, but I've found it helpful many times when doing support (not lfs-support, though). Someone will be wondering how to do something, I'll say well you can just run $random_executable, and they'll say I don't have it; where did you get it from?. At that point, it's much easier to ask whatever package management scheme I have, than it is to remember everything. (Some executables are easy -- python, for instance -- but not all are.) 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: Time to remove hotplug?
On Mon, Sep 19, 2005 at 05:24:01PM +0100, Richard A Downing wrote: Anyone got a similar KDE photo? Not exactly, but this is a lame ASCII-art version, based on current BLFS (SVN) dependencies: All other KDE-* packages | | || +---+---+---++ | kdebase | kdelibs | arts ++ Qt Glib (!) || Xpkg-config pgpbL6LrRx5uu.pgp Description: PGP signature -- 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
Alexander E. Patrakov wrote: 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. You've already commented that this isn't 100% accurate (because of the livecd), but I'd like to add a case where a single-machine installation *does* require support for a blacklist. My machine uses an nvidia-chipset 3D card. I therefore have their (binary only) driver kernel module installed. This module has a device table in it, so current LFS coldplug based module-loading *does* load the driver at boot time. (It gets added to modules.pcimap, and modinfo nvidia shows an alias to pci:v10DEd*sv*sd*bc03sc00i00*.) But I don't want the module loaded automatically at boot time. Most of the time, my machine boots up only to record some video off my TV card, then sits doing very little for most of the day (until I come home from work and startx). I was seeing a few kernel oopses while doing heavy FS activity during this recording, so I blacklisted the nvidia driver to get it to stop auto-loading, so I could see whether the oopses continued. (They did, BTW. I think the culprit may have been a race condition in the ext3 driver, because a later kernel update has cut down on the oopses dramatically. But I still want the nvidia driver blacklisted, because it might still cause other issues.) Yes, this means I have to manually load one module before I startx. But that was a small price to pay for removing non-open-source code from my kernel at the time the oopses were happening. So in general: A case where a single-machine installation requires blacklist support would be where the machine's admin specifically wants hotplug (or whatever) to ignore a certain module, so the admin can load it manually only when it's needed. 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
initramfs - why not?
I just upgraded my kernel to 2.6.14, and I remember discussions about that version, udeveventrecorder, initramfs, and getting rid of coldplug -- and the whole hotplug package -- happening several times now. What I'm wondering is, for anyone that doesn't think an initramfs is good, why do you think that? The way I see it, it's another part of a Linux system (more specifically, the kernel) that we haven't really touched on before because it wasn't needed. With a move like replacing coldplug, it might become necessary, which I guess I see as just another opportunity to teach readers more about Linux -- in this case, what happens in early userspace, before init gets started. (But I'm still not entirely sure whether it *is* needed or not, or whether it's even what upstream recommends anymore. If not, then I wouldn't put an initramfs in just to teach about it; IMO the system should be used for something if it's there.) (From what I remember of the various options that Alexander has proposed in the past, the initramfs seems to be the cleanest anyway. Why walk sysfs, like udevstart does in v6.1, when you can just save the events as the various built-in drivers create their kobjects? Same with loading modules -- why try to regenerate the lost events, when you can just save the originals?) I do remember some objections about requiring cpio to be installed on the host -- but an initramfs doesn't. True, one option is to have cpio installed on the host, then making a cpio.gz archive, then pointing the kernel at that while configuring it. But another option is to have the usr/gen_init_cpio binary from the kernel create the cpio archive for us, and that doesn't (maybe doesn't always) require the cpio binary. We can either have a directory which the gen_init_cpio binary will create a cpio archive from (this may require cpio, I haven't tested it), or we can write a control file, which gen_init_cpio will interpret (I've done this on a system without cpio, and it works). The file's format is given by running usr/gen_init_cpio --help from the top level directory of the kernel source tree. The kernel documentation (early-userspace/README) recommends using klibc, but that's not strictly required either. As long as you don't do name lookups in the other binaries (or otherwise require the nss stuff), glibc will work fine. Yes, it'll be about 700K bigger, but what's 700K of RAM that's used by files that will be deleted soon anyway? Not much, IMO. We could even have an LFS-specific initramfs package that extracts into a directory containing everything -- the control file (containing references to LFS's bash, glibc, some basic devices, the udev files that are needed, and a couple other executables), the /init shell script, and that would be about it -- and give a sort of overview of the way it works on the page where we use it compiling the kernel. The initramfs itself is certainly something that I'd have loved to learn about from the LFS book (figuring out how to put one together, how it does what it does, etc.). I admit, I may be different than most people that way, but I don't know. (I'm also not sure I got everything I need in my initramfs, but that's what this upcoming reboot is for. ;-) ) 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: initramfs - why not?
Zachary Kotlarek wrote: with an initrd I'd need to maintain a whole set of binaries and libraries in a file systems that doesn't get used except for the first 5 seconds after boot. While there are certainly things you can do with an initrd I've never seen the benefits as outweighing the hassle of creating and maintaining the filesystem. Well, initramfs, not initrd. They are different: 1) I believe an initramfs is mounted earlier than an initrd would be 2) an initramfs would do more than just load required modules 3) there is no FS on the initramfs image (it's just a cpio-format file) There may be more differences, but I can't think of them ATM. It would be fairly easy to use whatever executables are on the system at the time the kernel gets compiled. Yes, they are copies, not symlinks, but they would update every time the kernel gets recompiled. (Not that replacing the system glibc is always a good idea anyway, but whatever. Other stuff that got upgraded would be updated in the initramfs.) And it wouldn't be in a separate file like an initrd is; it would be built right into the kernel binary. It wouldn't use appreciably more RAM after it was done doing its thing, though, because the last thing it would do before chrooting into the final system and exec'ing /sbin/init would be to delete all the files it holds (except udev's logged events, which would be deleted after being replayed). The system would be left with one root directory, and one dentry for the target directory of the chroot -- the directory containing the real root FS. The kernel binary would be too big for a floppy boot, but 2.6 doesn't support directly booting from a floppy anymore either. I'm not sure how there would be any maintenance, I guess. The process of creating the image is hard to figure out (or at least, it was hard for me to figure out), but that's what the book would be teaching. Maybe I should try to write a hint 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: initramfs - why not?
Jim Gifford wrote: Have they ever figured out how when your build a kernel to add the modules that your building into the initramf? So you can have a complete modular system? I don't know. If modules_install would get run before the initramfs image creation, then you could use the /lib/modules/whatever directory as the source for the modules. But it doesn't. If MODPOST ran before the initramfs, you could copy the modules from their current place in the tree, but I don't know for sure that that happens either. There is an insmod binary in klibc, so it should be *possible*, I just don't know how easy it is. 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: [Fwd: recent changes to udev]
Matthew Burgess wrote: Hi folks, This, from linux-hotplug-devel sounds quite encouraging. Well, so much for my initramfs system... ;-) And I was getting close to getting the hint text figured out, too. Ah well, it happens, I guess. At one point, trying to fake the environment to look like a real event was so silly, that I just added a uevent file to every kobject directory in /sys, which sends the netlink message again to udevd... That way, the whole coldplug is about 40 lines of shell script in the udev boot script on SUSE now. It just writes to every uevent file it finds, which will trigger the event to load modules, setup the device and create the device node at boot time. This script needs some improvement, but works nice for a first cut. That definitely does sound much cleaner. It's not exactly as pure as storing the original events, but since the kernel code can regenerate all the info anyway, IMO this way does make more sense. /lib/udev/devices/ Real device nodes! Created with mknod, with the proper permissions and ownership set. A bunch of symlinks and nodes as a workaround for virtual devices or broken kernel drivers. The whole content of this directory will be copied over to the tmpfs mounted /dev at every boot time. Hey, this sounds like a good solution for the nvidia driver. (It had to remove its sysfs class kobjects, because that interface got changed to EXPORT_SYMBOL_GPL. So instead of registering kobjects in their kernel driver, they ended up having their X driver create the device nodes directly. This way, they could just stick them into /lib/udev/devices when the driver gets installed.) 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: Glibc Test Suite
Dan Nicholson wrote: I've never gotten the math test failures in LFS (haven't been around long, though). What CPU do you use? They only ever showed up on Athlon XP CPUs, IIRC (though it is possible that other CPUs did cause a failure; I know my Athlon XPs caused it). That includes -O3 -march=pentium3 optimization. Looks like you use a P3 then? Those definitely did *not* show the failure before. 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: Glibc Test Suite
Matthew Burgess wrote: Bryan Kadzban wrote: What CPU do you use? They only ever showed up on Athlon XP CPUs, IIRC (though it is possible that other CPUs did cause a failure; I know my Athlon XPs caused it). They don't show up with my Athlon XP 2400+ - my test results are exactly the same as Randy's. Now? I believe they probably are the same (I haven't built LFS recently at all). Previously, though? I definitely saw them before, with both an Athlon XP 1800+ and an XP 2500+. I never saw them with a P3-800, though, and that was my point -- on a P3, they never showed up. If Dan is using a P3, then I would not expect him to see the failure. 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: Glibc Test Suite
Bryan Kadzban wrote: If Dan is using a P3, then I would not expect him to see the failure. I should have said: I would not expect him to see the failure, whether or not it got fixed for the Athlon XPs. 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
Kernel headers [Was: Re: User IDs and Group IDs]
Andrew Benton wrote: That doesn't sound too dangerous to me. Except that the kernel headers use different names (and possibly different types, although the types have to be the same size) from what userspace needs to use. For instance, see: http://groups.google.com/group/linux.kernel/browse_frm/thread/68d34c0d6c10d414/c6f44e82a0b5731a?tvc=1 The IPv6 multicast request structure inside the kernel is different from what RFC2553 says programs should use. But it doesn't matter (so it won't get fixed, because it's not a bug), because the various elements of the structure are the same size. Just the names are wrong. And as Linus says in there: There aren't that many things that are actually useful in the kernel headers anyway. Most of them (like the IPv6 stuff) are really specified in other places in the first place. For IPv6, the person who started that thread should have taken the RFC and made a structure declaration from it, not used the (internal) kernel interface(s) directly. If it is wrong to use the kernel headers why don't the kernel developers include fixed headers in with the kernel source? Because the linux-libc-headers project already exists. (Now, this wasn't a valid answer until recently, but until 2.5.something, glibc *could* use raw kernel headers without too many issues.) 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: More control...hint integration discussion
On Mon, Nov 28, 2005 at 09:48:41AM -0700, Dennis J Perkins wrote: Isn't DESTDIR something that the autoconf package automatically provides? Well, automake (not autoconf), but yes. Which means almost all packages used by LFS and BLFS should be able to use it. All except the ones that don't believe in automake for whatever reason. ;-) (Note that there are packages that use autoconf without automake -- IIRC, WineX CVS used to do this, and it might do it still, so it's at least one. These packages may or may not support DESTDIR on their own. automake packages support it because automake creates the Makefile.in's install: pseudo-rule, and that pseudo-rule supports DESTDIR.) pgpAEVwnvn8aW.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: clarify __ Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2.6.14.x)
Bernd Feldmeier wrote: a) dependency of kernel version and linux-libc-header version None whatsoever. These are two different packages, with two different reasons for existing. l-l-h is based on the kernel headers, but you can use any version of either of them (well, no, that isn't quite right: your kernel version has to be = your l-l-h version, because the kernel contains backwards compatibility code, but it does not have to be ==). b) problems occuring Problems when you try to do what? If you upgrade l-l-h (and the kernel) without recompiling glibc, any programs you compile against the new l-l-h headers could break when they try to call functions in the glibc that never got changed. (See Linus's comments, which have been linked to by several people in this thread.) If you upgrade the kernel without upgrading l-l-h or glibc, then you have no problems. The kernel keeps all sorts of back-compat code in so that programs (and libraries, i.e. glibc) that use older versions of its userspace ABI can still work. If you upgrade the kernel without upgrading l-l-h or glibc, *and* you need to compile a program that (1) needs a feature present in the new kernel, but (2) does not include its own local header for that feature, then you won't be able to compile the program. But this is a bug in the program, not a reason to keep kernel and l-l-h versions in sync. When you're using a brand-new feature, you better be keeping your own version of that feature's header files, so you can compile against slightly older glibcs. c) real meaning of sanatized headers (why ...) Because the headers right out of the kernel contain all kinds of cruft that userspace doesn't need to see or use. (Plus they're bigger, so compilation takes slightly longer.) Plus they use the *wrong* names for several structures and structure members (IPv6), and therefore will *never* work with RFC-compliant user programs. d) creating our own up-to-date header version IMO, that's way too much work, since it's already being done by l-l-h. e) libc + kernel interface calls I'm not sure what you mean here... 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: Fix for checkfs display on boot
[EMAIL PROTECTED] wrote: and the screen display will look something like this (excerpt): Mounting root file system in read-only mode... [ OK ] Checking file systems... /dev/hdb4: clean, 133764/960992 files, 921705/1919767 blocks (check in [ OK ]) Remounting root file system in read-write mode... [ OK ] Not on my system. ;-) I run vesafb @ 1280x1024, so I have a 160-column display, so this isn't an issue. Also, if you have more than one FS being checked, it's not a problem for any except the last. *Also*, if your filesystem's size is a different order of magnitude, then you'll see either more or less of the check in X days/mounts message. That being said, I don't know whether just use *fb is a good solution either. I doubt it. If it were possible to read whatever's on the display, then perhaps echo_ok (and friends) could check that the positions they're going to write to are empty before writing, and skipping the $CURS_UP if they're not empty. But I'm not sure whether that's even possible, let alone a good idea. (It could also break the parallel bootscripts that someone was working on a while ago.) 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: Fix for checkfs display on boot
DJ Lucas wrote: The other (and easier) solution is to echo mounting..., capture output of mount and grep for the check message, if then spit the message to screen and add another line (echo) and then echo_ok. Or possibly case instead of grep, but yeah, that sounds like a decent idea. Have to make sure that the check message is happening on the last line of fsck's output, though (because with multiple FSes, it may not be). I'd also like a check (for just this line) that sees if the length of the text is too long before blindly echoing, but (as you said) wc is possibly unavailable, and broken in multibyte locales. So that probably isn't going to happen. It'd be nice for the *fb users, though, to take up one line fewer. Oh well. 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: udev-076 setup (was Re: Post LFS-6.1.1 plans)
Matthew Burgess wrote:
I added the following (shamelessly nicked from the Redhat examples
shipped in the udev tarball):
ACTION==add, SUBSYSTEM==usb, MODALIAS==*, \
RUN+=/sbin/modprobe $modalias
Shouldn't that be:
... MODALIAS=?* ...
Or is that only for environment variables (ENV{...})?
The udev RELEASE-NOTES file says that in udev 064:
* will not fail anymore, if the key does not exist or is empty.
but I don't know if that's only for ENV{...} or if it's for everything.
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: udev-076 setup (was Re: Post LFS-6.1.1 plans)
Matthew Burgess wrote:
What's wrong with the /{proc,dev}/bus/usb permissions?
The way I understand it (and Alexander, correct me if I'm wrong), the
permissions we apply by default to those directories allow read/write
for all members of a fixed group.
If one specific user needs access to only one type of device (say, a
scanner), but not other devices (say, the console mouse), they can't do
it with our current permissions. Root has to make them a member of that
group, and open up all devices to them.
Now, that doesn't bother *me* at all, because I'm the only user on this
system. But it is an issue that should be fixed for others who do have
multiple users on their system, and who might need to do this.
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: Bash testsuite should not be run as root
Jeremy Herbison wrote: I don't know how running as root skews the results, though. I know the tests all pass as-is. It's possible that they do something that's maybe-unsafe when they get run as root. I don't know for sure, though; I haven't looked into it at all. Just saying that this is one possibility. 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: adding 2.6.15 to trunk
Jeremy Herbison wrote: Now won't udev require headers for the new functionality? What new functionality? Possibly the new netlink socket stuff? udev-071 compiled just fine against l-l-h version 2.6.11.2 when I moved to it from -056 a few months back. Now, that's not the most recent version of udev (like I said, it was a few months ago), but I don't see anything in the RELEASE-NOTES file for -072 through -078 that looks like it would require newer headers, either. But I don't read linux-hotplug-devel or linux-kernel, either, so I may be missing something here. 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: RFC: GDBM or Berkeley DB?
Archaic wrote: In order to make LFS usable in UTF-8 locales, and different man program was chosen, man-DB. That program requires a database backend. It can support GDBM or Berkeley DB. Let me play dumb here for a minute: Why? ;-) Would it be possible to do something similar to what we did with IPRoute2, and just patch (or sed) out the database backend requirement? Or is the database used for more than just storing manpage indexes? Debian (or at least Knoppix) uses man-db, as has already been mentioned in this thread. It runs a daily cron job to do something with this database, and that job seems to iterate through all the manpages on the system. So I believe it's just indexing the pages or something, so that stuff like man -k can be fast. But I don't think we would necessarily require that; if we just treat man-db as man but with builtin hacks for UTF-8 support, and patch out the database requirement, wouldn't that work? Assuming the patch out part is feasible, anyway. 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: LFS-Alphabetical ICA/Farce Results
Dan Nicholson wrote: Did LFS use to build bison and flex in /tools? When we used HJL binutils (before FSF binutils supported TLS/NPTL), yes. HJL binutils require bison and flex (or at least, they used to). 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: Package Management
Jeremy Huntwork wrote: I think we need to bring something up in LFS. If a user decides he wants to use a package manager, he's not going to want to find out about his options *after* he's already built his core system and moved on to BLFS. The minute a user starts building packages that will be in the final system, he should be able to use a package manager, if he so desires. Definitely agreed. Any package management really should be used during the book's chapter 6, otherwise you get a bunch of files that you can't see which package they came from. (I saw this with the pkg-user hint; I had finished with the LFS book when I found it, but by that time it was too late to create all the extra users and change the ownership of all the files.) 1) Recommend it, put it in the book, with instructions how to do it, a la all the packages in LFS. 2) Present the alternatives and let the readers make a choice. 3) Simply mention the guiding philosophy and let readers find different solutions and choose what works for them. I'm not reading what's there as a specific endorsement of one particular package manager. I read it as If you want a package manager *that's geared to LFS*, then try this one. It's a conditional recommendation. Basically, the first part is Randy's option 2 (present the alternatives) -- it's just that the BLFS book is doing the presentation. The second sentence could perhaps go, since it's mentioned on the BLFS page, but I guess I don't see how it's hurting anything. 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: UTF-8 book is ready for merging
Pasha Zubkov wrote: Alexander E. Patrakov пишет: Pasha Zubkov wrote: Hello, this patch fix UTF-8 issue with `watch` at least in ru_RU.UTF-8 and be_BY.UTF-8. Rejected, breaks ru_RU.KOI8-R. Added test for UTF-8. Why not just use getwc(), and use wchar_t's in all cases? You'd have to modify the output to convert back to multibyte characters (specifically, LC_CTYPE-encoding characters; they may not actually have more than one byte per character), but it looks like add_wch does that already. 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: UTF-8 book is ready for merging
Pasha Zubkov wrote: Bryan Kadzban пишет: Why not just use getwc(), and use wchar_t's in all cases? You'd have to modify the output to convert back to multibyte characters (specifically, LC_CTYPE-encoding characters; they may not actually have more than one byte per character), but it looks like add_wch does that already. Just after a stream is associated with a pipe by the popen() function, the stream is byte-oriented. Where is that quoted from? I was not aware that there was a difference between byte-oriented and wide-oriented streams. I thought getwc did the conversion between LC_CTYPE charset and wide-char itself, though I see the getwc manpage only says that it is reasonable to expect this in the absence of additional information passed to the fopen call. This Debian i18n page seems to imply that it should work (see 6.3), and it's what I was going from: http://www.debian.org/doc/manuals/intro-i18n/ch-locale.en.html But if there is a difference, then the iconv sample on that page (see 6.5) could be a better choice than hardcoding the UTF-8 conversion, and (therefore) only working in a UTF-8 charset environment. (Plus, you don't know what the user will set LC_CTYPE to; it might be utf8, it might be utf-8, it might be UTF8, and any of these will break the patch.) 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: UTF-8 book is ready for merging
On Tue, Jan 03, 2006 at 03:13:52PM +0200, Pasha Zubkov wrote: Where is that quoted from? http://docs.hp.com/en/B9106-90012/orientation.5.html This is for HP-UX, but it's true for glibc to. Ah. Between this and your glibc link below, I'll agree with you -- fgetwc or getwc on a popen()ed stream won't work right. But I wonder if you can freopen() a popen()ed stream? If so, you could first freopen() it, then fwide() the new stream; then you'd get automatic handling of any locale. But if there is a difference, then the iconv sample on that page (see 6.5) could be a better choice than hardcoding the UTF-8 conversion, and (therefore) only working in a UTF-8 charset environment. Sorry for that, i'm not a C programmer :) :-) (Plus, you don't know what the user will set LC_CTYPE to; it might be utf8, it might be utf-8, it might be UTF8, and any of these will break the patch.) Standard recomends using UTF-8. Yes, but we've had some issues before when people don't -- I believe it was with some X programs. They hardcoded either LC_MESSAGES or LC_CTYPE values, and subsequently broke when someone used a different string than what they were expecting. Or something like that. Hardcoding the value for LC_CTYPE or LC_MESSAGES is *never* a good idea. Just let iconv() handle LC_CTYPE for you, and let gettext() handle LC_MESSAGES. (Yes, you have to use nl_langinfo() to get a string to pass to iconv_open -- but I believe anything that nl_langinfo returns is supposed to be valid for iconv_open.) pgpnreA7cyCSn.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: More ICA
On Fri, Jan 06, 2006 at 12:57:01PM +, Ken Moffat wrote: On Thu, 5 Jan 2006, Dan Nicholson wrote: Maybe. Do you know how the hostcat command is used in perl? No idea, and I'm not keen to dig into perl. The binaries are accepted after stripping and converting hte dates to tokens, but some more comparison won't hurt. Well, the perl Configure script used to have some verbiage in it about the gethostname() function not returning the correct hostname in all cases (something about but it can't be changed for political reasons). In that case, it offered an option to use the external hostname binary or the /etc/hosts file when a program asked for the current hostname. Maybe the hostcat stuff is related to that. (Current perl Configure scripts seem to just use the hostname command, and don't bother with gethostname() at all.) Or actually, the Perl documentation[1] says it's part of the system that allows programs to find out how Perl was configured. The command in the string is supposed to produce the text of the /etc/hosts file, but I'm not sure what purpose that would necessarily serve. Hmm... It doesn't seem to be used in my LFS 5.something system, but said system is quite old (and I only grepped through stuff in /usr/lib and /usr/bin, I didn't check package build scripts, etc.). I can't check my other (LFS 6.0-pre, IIRC) system at the moment. Regardless, it is a difference, that (IMO at least) should be fixed. The perl installation instructions already have the user create a hosts file before running the perl tests. Maybe it would be a good idea to create it earlier (before ./configure.gnu), then overwrite it when the user sets up networking later (section 7.11). Or remove it after installing Perl. [1] http://www.perl.com/doc/manual/html/lib/Config.html#item_hostcat pgpFiGW4kRonQ.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB and Berkeley DB
Richard A Downing wrote: Can someone point me to the discussion thread that decided this change of man package? I want to review the reasons to make my own decision on it. http://linuxfromscratch.org/pipermail/lfs-dev/2005-December/054909.html That's not the thread that decided it, but it's the best explanation I've seen of exactly what's wrong with man, and why man-db works. (In other words, it's the reasons you want to review.) In short: Regular man requires all sorts of hacks from the user before it will work in a UTF-8-charset locale. man-db knows all the hacks, and can build a correct pipeline automatically based on the contents of the shell $LANG variable. (I would assume that it follows the normal rules of the LC_* variables: check $LANG first, then $LC_CTYPE, then $LC_ALL, with later variables overriding earlier ones. But I don't know that for sure.) 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: PCRE
Jeremy Herbison wrote: I, and I'm guessing many others, build PCRE right before Grep in chapter 6. I don't. I've never *built* pcre (though it was probably *installed* on most of the Mandrake setups I used to use, years ago). But then, I don't usually use Perl, so I don't really miss much when I don't have Perl-compatible regex support, either. It's an optional dependency of Apache, but since Apache has its own copy that it can use, I don't install pcre. AFAIK it's not needed (or even optionally used) for anything else that I usually install. I'm probably weird, though. ;-) 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: file's config files
Robertus Ario Jatmiko wrote: For your information, that file is not static after all. I added a new entry to the magic file: The question is not *can* you add stuff to the magic file. The question is are you *supposed* to add stuff to the magic file. From the comment in the magic file itself, you are not. Re-read what you quoted: # Machine-generated from src/cmd/file/magdir/*; edit there only! Upstream *clearly* does not want the magic file to be edited directly; they want new definitions to be put into the source instead. Presumably this is so the new definitions are available for others too. It does not surprise me that it works to edit the file, BTW. But that doesn't mean it's an approved action. 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: UTF-8
On Fri, Jan 20, 2006 at 06:34:20AM -0800, Dan Nicholson wrote: So, if you're following this thread and you have a strong feeling that you'd like the UTF-8 changes to be added in as the default or prefer them to be stored in an appendix, please make your opinion known. +1 for make UTF-8 capability the default. If that means we need to use man-db + BDB, I have no problem with that. But if others do take issue with adding those packages, then I'm also OK with waiting a couple months until plain old man and groff work in UTF-8. (Note that I haven't yet missed not having UTF-8 support; I use US-ASCII for about everything anyway. But I do realize how much of an issue it's getting to be, and I want a system that will work with UTF-8-charset files (and manpages, etc.) by default. If nothing else, so I can test the i18n that I'm doing to the few programs I write.) (Copied to cross-lfs also; I'm not sure if this will matter over there or not, but oh well.) pgpnevtGyQhb6.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Santized Kernel Headers
DJ Lucas wrote: What are the known issues agains the released version/cvs? What's been done so far? If you mean what are the known issues against the released llh package (not the kernel headers themselves), I'd really like to know that too. I've seen several references to udev needing newer headers, but so far no one has ever explained *why* it needs new headers (what the required changes are). Just a quick line like it needs the new struct uevent would be fine; right now, I know of nothing that llh 2.6.12 doesn't do properly. (Well, I take that back: I now remember that inotify isn't in 2.6.12. So other than that then; I want to know what I won't be able to do with udev if I keep my current setup, which is based on llh-2.6.12.) 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: ImplementingTrac - Logo
John Miller wrote: Okay, sorry for the noise, its just when I tried to save the page to my computer to fiddle with the coding, IE actually removed the closing /. Thought that might have been causing the problem. Yes, and if there was a [meta http-equiv=content-type content=text/html; charset=iso8859-1 /] tag in the HTML file's [head] section, then (at least some versions of) IE will change the charset to be windows-1252 when you save the document. I wish I could find where I originally read this, but I can't anymore. :-( It seemed to be that either Microsoft didn't want people using the ISO charset name in their own pages (but rather windows-1252), or they're just really, really stupid. Moral of the story: File - Save Page As *CAN* modify the document! 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: Redundancy in ncurses installation
Chris Staub wrote:
The Chapter 6 ncurses instructions in the LFS dev book have this
construction:
for lib in curses ncurses form panel menu ; do \
rm -vf /usr/lib/lib${lib}.so ; \
echo INPUT(-l${lib}w) /usr/lib/lib${lib}.so ; \
ln -sfv lib${lib}w.a /usr/lib/lib${lib}.a ; \
done
That rm /usr/lib/lib... line is not needed. If any of those files
exist, they will be replaced on the next command (echo INPUT...) anyway.
This is NOT safe if either of those library files are currently linked
into any process that's running!
As a test, I used libX11.so.6* from /usr/X11R6/lib, and xcalc, because I
could control when xcalc ran code inside that library (by moving my
mouse into the window that xcalc brought up).
Here's the test. In one xterm:
cd /tmp
cp -a /usr/X11R6/lib/libX11.so.6* .
export LD_LIBRARY_PATH=/tmp
xcalc
Then, in a second xterm:
cd /tmp
echo INPUT(-l/usr/X11R6/lib/libX11.so.6) libX11.so.6.2
Then, move the mouse over the xcalc window. (If you're recreating the
test, you might have to actually click on the window to give it the
focus, depending on which WM you're using.) At this point, xcalc gives
a bus error, i.e. a segfault, because its in-memory copy of
libX11.so.6.2 has been overwritten in place.
If a file is in use, it is NOT safe to just truncate and overwrite it.
You have to remove it, then recreate it. (If I rm libX11.so.6.2 first,
everything works fine.)
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: Redundancy in ncurses installation
Alexander E. Patrakov wrote: Bryan Kadzban wrote: This is NOT safe if either of those library files are currently linked into any process that's running! They are not used. Certainly :) The used file may be /lib/libncursesw.so.5 (which is a symlink pointing to 5.5). If it's a symlink, then it *won't* be linked into any running process. The target of the symlink (libncursesw.so.5.5) may be, though. (/proc/PID/maps is helpful here -- in some cases anyway.) The (completely different) file affected by echo is /usr/lib/libncurses.so (note: this is not a symlink), which is used only by /usr/bin/ld while building packages. Ah, I see. I must have seen the .so part, but then read .so.5 or .so.5.2 or something. OK, never mind then. :-) (They might be used if a compile is running, however that can't happen in the book as it is now.) 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: Re-adding *startfile_prefix_spec
Dan Nicholson wrote: In the adjustment, though, he uses `gcc -dumpmachine`, though. This is probably wise since you don't know what MACHTYPE is from the host's bash. In fact, this might be a good idea for both adjustments. I don't know how reliable MACHTYPE is, but I'm speculating since I don't know how it's determined. Well, the standard solution to this (e.g. on non-bash/non-gcc systems) is to use the output of the GNU config.guess script. AFAIK that's what both bash and gcc do to generate that string. However, they may use different versions of the script, so they may end up with different values, and if we compare the host's bash or gcc to the /tools one, they may also be different (for instance, Mandrake systems used to do this; I don't know whether they still do). 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: Udev_update branch: /dev/pts and /dev/shm directories not created
Matthew Burgess wrote:
I'm still concerned that we won't load all modules correctly though;
some of the distro rules load various SCSI modules dependent on the
SYSFS{type} variable. I'd appreciate it if someone with the
necessary hardware could test to see what does or doesn't work.
Oh -- the load sd_mod for SCSI disk device type rules? Yeah, I don't
know for sure how to handle that one; I don't use SCSI. (I wish I did,
just for its reliability. But that's another issue.)
It should work to have the generic modprobe $modalias rule for all
ACTION=add, MODALIAS=?* uevents, but then also have other rules for
SCSI disks, SCSI tapes, SCSI CD-ROMs, and SCSI whatever other devices.
The modprobe sd_mod rule that's in the rendered udev_update branch
right now looks like it's orthogonal to the MODALIAS=?* rule; it's not
like the sd_mod rule is overriding the MODALIAS rule or anything. It
should be possible to just add extra rules that depend only on the
SYSFS{type} values, and load the right SCSI modules.
Looking at the RedHat rules file[1] shows the following mappings of the
various SYSFS{type} values to device types and modules:
SYSFS{type} Device Module
--- -- --
0,7,14Disk sd_mod
1 Tape st (or osst, depending on the tape device)
2,3 Generic sg_mod
4,5 CDsr_mod
6 Scanner sg_mod (still a generic device)
8,9 Generic sg_mod
I don't know about other values; I'd like to know where to find out how
they're allocated, though.
[1]
http://diploid.med.unc.edu/cgi-bin/dwww?type=filelocation=/usr/share/doc/udev/examples/redhat.rules.gz
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: Udev_update branch: /dev/pts and /dev/shm directories not created
Richard A Downing wrote: I tried Jim Gifford's Cross-lfs udev patches, and they work fine, so that's what I'm going with for now. I'm not familiar with these patches, and I can't seem to find them in the (x86 at least) cross-lfs book. Where are they? Seeing the patches might help figure out what the issue is. 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: Comments on Trac ticket mails
On Thu, Feb 23, 2006 at 11:20:02AM -0500, Jeremy Huntwork wrote: If the text is not US-ASCII and the content-transfer-encoding is quoted-printable, all non-ASCII bytes are converted to the =XY notation, where X and Y are hex digits. ASCII pats of the message are readable with vim this way, but non-ASCII requires Mutt. If viewability with vim is an absolute requirement, use the 8bit content-transfer-encoding. Looking through the python code, it appears I can set the variable [mime_encoding] to be either 'base64', 'quoted-printable', or 'none'. 'base64' is assumed unless you specify something else. 'none' will be regarded as ASCII only, and if the script encounters any non-ASCII characters, it will bail. I'm not sure how likely it is to encounter non-ASCII chars. Perhaps if someone includes them in their comments? What's the best thing to do here? IMO, use quoted-printable; here's why: 1) The vast majority of characters in bug reports will be 7-bit ASCII. Even if we do allow other character sets in the submission form (which AFAIK we do), most of the characters that get typed in will be valid 7-bit ASCII (English letters and Arabic numerals). 2) 'Base64' is totally unreadable unless you have a mail client available, or you know how to decode base64. Yes, most people have a mail client available most of the time, but if there's another option that doesn't break something else, but which does still allow most of the mail to be read without a mail client, I'd go with that other option. 3) 'None' will die if the user puts in a non-ASCII character. IMO, that's not good. Whether the users will try it or not is another question, though. (Additionally: What if we start adding bugs regarding the UTF-8 support, after it gets officially put into the book? Those bug reports will almost assuredly require more than 7-bit ASCII, at least for some characters. More than zero. OTOH, we can change this setting later, too.) 3) 'Quoted-printable' will avoid failing in the case of a non-ASCII character. It'll still be mostly readable without a mail client, though (because most characters are 7-bit ASCII) -- IMO, that's the best of both worlds. I would also say that viewability with Vim is nice but not absolutely required; that's why I wouldn't recommend hacking Trac to support 8bit. (I use Vim once in a while instead of Mutt, too. But not often, because I do have Mutt installed.) pgpPgKfm2ObRT.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bugs in udev_update branch
On Fri, Feb 24, 2006 at 05:29:07PM +0500, Alexander E. Patrakov wrote: As written, this is incorrect. Increasing the logging verbosity achieves nothing, because udev runs before syslogd. Proposed solution: 1) Implement some restart target in the udev initscript that kills old udevd, starts a new one, pokes sysfs and waits for udev to process uevents. This would be also useful for Suspend2, BTW. 2) Tell the reader to increase the logging verbosity and call this target, so that everything gets logged. With the caveat that I think we should somehow tell the user that restart will be expensive, this sounds like a good idea. (Stopping udevd and starting a new instance won't take a long time, but poking all the uevent files and running all the helpers/rules/etc. will.) It should be easy enough to have only start and restart targets, and have the restart target do a killall udevd (or whatever), then simply run $0 start (perhaps after waiting for a second). pgp4YblqsjRS7.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bugs in udev_update branch
Alexander E. Patrakov wrote: No, that won't work. We want to mount tmpfs on /dev for start, but not for restart. True, unless we unmount it first (thus removing all devices). Well, actually we probably can't unmount it, because at least /dev/console will be open. OK, so how about restart does the killall udevd (or whatever), then udevd --daemon, then walk_sysfs. That's not too much harder. The only thing it'll miss is the static device nodes in /lib/udev/devices, but those shouldn't have disappeared anyway (hopefully). If it looks like that would be a problem, we can add the cp -ar to the restart target, too. 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: Bugs in udev_update branch
On Mon, Feb 27, 2006 at 07:03:04AM -0700, Archaic wrote: It is done before udev is started. It just happens to be done in the same script that starts udev and currently that is the most logical. We can't do it in the mountfs script because udev must run before that. We could do it in the mountkernfs script, but it gains us nothing and also makes the name mountkernfs inaccurate. I think what Dimitry meant was why don't we use a new script. Which sounds like a good idea, except that all this stuff is related to udev. About the only good way that I can see to make it another script is to name them udev1 and udev2; that screams horrible hack to me, though I don't exactly know why. If we can just make the restart target specific enough to work (instead of the standard $0 stop / sleep 1 / $0 start, just make it run the commands that it needs to run), I think going with that would be better. pgpqW78I0xV97.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
Archaic wrote: From what I've read, inotify is the only thing that keeps popping up and a patch will satisify that. Not quite true anymore; 2.6.16 also includes some new syscalls (openat and friends) that will (may? probably will) require changes in the userspace headers. There may be other reasons too; I'm not sure. I know of inotify and an issue with kd.h and X.org[1] as of 2.6.15, but there may be others. Now, yes, we could patch these into llh (actually, Mariusz may welcome us doing a patch like that, if we give it to him as well; it might be worth a shot at least). But it's more than just inotify. [1] http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/07.html 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: RFC - Raw Kernel Headers
On Mon, Mar 13, 2006 at 04:39:11PM +, Florian Schanda wrote: On Monday 13 March 2006 16:10, Florian Schanda wrote: On Wednesday 08 March 2006 04:21, Jim Gifford wrote: available at http://ftp.jg555.com/headers/headers. You can replace the long sed with the following: -e 's/\bu8/__u8/g' \ -e 's/\bu16/__u16/g' \ -e 's/\bu32/__u32/g' \ -e 's/\bu64/__u64/g' \ -e 's/\bs8/__s8/g' \ -e 's/\bs16/__s16/g' \ -e 's/\bs32/__s32/g' \ -e 's/\bs64/__s64/g' \ -e 's/\b__iomem//g' \ Or even better/shorter: -e 's/\b[us]\(8\|16\|32\|64\)/__/g' \ -e 's/\b__iomem//g' \ Why not use \ (start of word anchor) instead of \b (whatever \b is)? pgpGxCHsKkwM4.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers -- Comparison Script Added
Greg Schafer wrote: echo '/* empty */' linux/compiler.h Hmm... Is this really necessary? I've been running Alexander's tests (http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html) on the output of Jim's script, and right now, it looks like include/linux/byteorder/swab.h is choking on __attribute_const__, which compiler.h nicely defines to empty for us. We could remove all the __attribute_const__ strings like we do __iomem, but why duplicate all that effort? (Of course, the removal of __iomem makes compiler.h fail to compile as well, since it defines __iomem to nothing. But removing the __iomem string just makes that line become #define , which gcc chokes on. I would think that in both cases, it'd be cleaner to add an #include linux/compiler.h instead of removing the offending string on our own. Unless there's some issue with linux/compiler.h that I don't see. That's entirely possible -- I'm a fairly decent C programmer, but I don't really have a great handle on the kernel.) 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: RFC - Raw Kernel Headers -- Comparison Script Added
Greg Schafer wrote:
Bryan Kadzban wrote:
I've been running Alexander's tests
(http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html)
I agree with Alexander that every userspace header should be
compilable by itself (at least in an ideal world). Note that current
LLH fails this criteria. Also note there are many kernel headers
simply not shipped with LLH.
I should have been a bit more specific: I wasn't filtering out headers
that aren't in LLH (and I wasn't going to compile dosemu either). I
was, however, only checking the stuff in include/linux and
include/asm-i386. (I've attached the script I run, if anyone's
interested. Run it from the same directory you run Jim's script. It
takes 2 params, the kernel version to test and the architecture to
symlink asm to (it symlinks asm to e.g. asm-i386 so that #include
asm/whatever from the other headers doesn't pull in stuff from
/usr/include/asm).)
#!/bin/bash
if [ -z $1 -o -z $2 -o $1 == -h -o $1 == -? ] ; then
echo Usage: $0 kernel-version arch 21
exit 1
fi
echo Starting tests...
rm -f linux-headers-$1/include/asm
ln -sv asm-$2 linux-headers-$1/include/asm
base=`pwd`
headers=`find linux-headers-$1/include/linux/ linux-headers-$1/include/asm/
-type f -name '*.h'`
gccver=`gcc -dumpversion`
for header in $headers ; do
file=${header##linux-headers-$1/include/}
echo #include $file thistest.c
if ! gcc -c -I$base/linux-headers-$1/include -Werror -o thistest.o
thistest.c ; then
echo $header ($file) failed.
exit 1
fi
if ! gcc -c -I$base/linux-headers-$1/include -Werror -ansi -o
thistest.o thistest.c ; then
echo $header ($file) failed.
exit 1
fi
done
rm -f thistest.c thistest.o
echo All headers passed.
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: RFC - Raw Kernel Headers -- Comparison Script Added
Bryan Kadzban wrote: gccver=`gcc -dumpversion` Oops, that doesn't need to be there anymore... (I attempted at one point to add -nostdinc to the gcc command line, so I needed to add the system header location (/usr/lib/gcc/$MACHTYPE/$gccver/include) to the search path. That seemed to fail, and I never pulled this out of the script.) 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: RFC - Raw Kernel Headers -- Comparison Script Added
On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote: a=$(echo -ne '\001') b=$(echo -ne '\002') These can probably be simplified to: a=$'\001' b=$'\002' pushd $KERNEL_PATH/include I don't think you need to pushd at the start and then popd at the end of the script. The script's environment (including its current working directory) will already be thrown away when it exits; doing a cd will be just as good. # delete the headers marked for removal rm -rvf $REMOVE_HEADERS This might run out of argv space; it might be better to: for file in $REMOVE_HEADERS ; do rm -rvf $file ; done or something similar with find/xargs. Moving on to the test script: for header in $(find $DIRECTORIES -name *.h) do for noheader in $NO_TEST_HEADERS do [ $header != $noheader ] || continue 2 done Would this be a little more clear if the sense of the [ was reversed? [ $header == $noheader ] continue 2 would be how I'd do it. I doubt it matters much, though. Alternately, it might be possible to exclude $NO_TEST_HEADERS from the find; something like: args= for noheader in $NO_TEST_HEADERS ; do args=$args -not -name $(basename $noheader) done for header in $(find $DIRECTORIES -name *.h $args) do # ... done might work, although I haven't actually tested it. It might also not be specific enough; if linux/x.h and asm/x.h both exist, and linux/x.h needs to be excluded but asm/x.h doesn't, this will exclude both. So maybe the way you have it (or with the sense of the test reversed) would be best. echo -e #include $header /tmp/linux-glibc-headers-test.c gcc -I$KERNEL_PATH/include -Werror -S -o - /tmp/linux-glibc-headers-test.c /dev/null echo o $header succeeded || echo o $header failed I was going to say should you perhaps be using -c instead of -S?. But after some thinking, the only difference is that -c runs the assembler, and we don't care whether the assembly that cc1 outputs is valid. As long as cc1 doesn't exit with an error, that means that there are no missing constants, types, etc. So good enough. pgpjIcZM8rR1Z.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers -- Compatibility scripts
DJ Lucas wrote:
for FILE in `echo
linux/{acct.h,quota.h,resource.h,socket.h,stat.h,time.h,timex.h,un.h,wait.h}`
Er, hang on here -- why are the echo and the backquotes in there? (I
should note that they're in Jürg's script as well.) They gain nothing,
and waste at least one process. (I believe this is one of the Useless
Uses of Backticks, but I could be wrong on that.)
When you use brace expansion, the shell doesn't omit files that don't
exist (like it does when you use pathname expansion, i.e. globbing). So
the braces get expanded by the shell into:
linux/acct.h linux/quota.h linux/resource.h ...
all the time, whether or not those files exist. Then the echo runs, as
do the backquotes, and you get this for command out:
for FILE in linux/acct.h linux/quota.h linux/resource.h ...
So there's really no point in having the backquotes or the echo; just
make this be:
for FILE in linux/{acct.h,quota.h,resource.h,...}
And likewise for all the other loops in the script. That's at least a
little better in terms of number of processes.
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: RFC - Raw Kernel Headers -- Compatibility scripts
Jürg Billeter wrote:
It's right that they gain nothing in the for loops. I've added the
backticks to the REMOVE_HEADERS lines on purpose, though, as the
shell doesn't expand braces when defining variables but probably
there is a better way to get expanded variables, don't know.
Hmm... You seem to be correct. About the only way I can get this to
work without the echo and backticks (or $(...)) is to stick an `eval
echo $REMOVE_HEADERS` as the argument of the rm command. But that's
not any better, I don't think. It's too bad that there's no way to tell
the shell to do brace expansion when assigning variables. (Normally it
does brace expansion before parameter expansion, so there's no way to do
it when substituting the variable back in.)
I suppose you could do:
for file in linux/{acct.h,...} ; do
REMOVE_HEADERS=$REMOVE_HEADERS $file
done
instead of each of your REMOVE_HEADERS=... lines, but that seems more
wasteful somehow.
(Also note that it doesn't seem to be the quotes that prevent the brace
expansion in the first place, it seems to be the variable assignment.
Even if you do a test like:
VAR=x{1,2,3,4,5}
, without the quotes, then when you echo $VAR, you get x{1,2,3,4,5}, not
x1 x2 x3 x4 x5. So you'd still need the echo for that no matter how you
set up REMOVE_HEADERS.)
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
udev_update: udevtrigger binary, replacement for walk_sysfs?
From the udev-088 RELEASE-NOTES file: - udev 088 other stuff about persistent links for certain device types Provide udevtrigger program to request events on coldplug. The shell script is much too slow with thousends [sic] of devices. - Looking at the source, it appears that this program does everything that our current walk_sysfs shell function does. It does class/mem and class/tty first, it does block/md, /block/dm-*, block/class/md, and block/class/dm-* last, and it does everything else in between. (Though it does /sys/bus, /sys/block, then /sys/class, where we do class before block. Probably doesn't matter though, as long as /sys/bus is done first. I also see that /sys/block is going to move to /sys/class/block; this hopefully won't be a problem either, but I don't know for sure; it shouldn't affect the binary, but it might affect our script.) Could we move to this instead of our current shell function? Alexander, you probably already know about this; are there any issues with it? 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: the story on udevtrigger?
Ken Moffat wrote: Udev-088 (which has this) only got into the udev_update branch yesterday. I created ticket 1756 against the bootscripts (referring back to the ticket for 088 containing Alexander's comments on this). I'm sure that the bootscripts maintainer will welcome tested patches :) Minimally tested (i.e., I've booted maybe 10-20 times and have never seen an issue) patch is attached. This is not a full udev_update build, though; it's a 2.6.16 kernel with udev 088 on an LFS 6.1 (well, mostly) machine. So maybe my testing isn't worth a whole lot. Still, here's the script patch. ;-) --- udev2006-03-21 20:04:34.0 -0500 +++ /etc/rc.d/init.d/udev 2006-03-31 18:10:39.0 -0500 @@ -122,7 +122,7 @@ # Now traverse /sys in order to coldplug devices that have # already been discovered mkdir -p /dev/.udev/queue - walk_sysfs + /sbin/udevtrigger # More uevents may have been triggered during the walk of sysfs, # so wait until they've been processed. 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: the story on udevtrigger?
Bryan Kadzban wrote: Minimally tested (i.e., I've booted maybe 10-20 times and have never seen an issue) patch is attached. Er, some comments on it. I didn't remove the walk_sysfs function since my original intent was to revert the script if it failed and I couldn't get it to work. But it worked the first time around (well, after a change I'll talk about later), and I seem to have forgotten to remove the function. I didn't do any testing regarding changing the timeout used by the wait_for_uevents function, either. But udevtrigger is pretty much a drop-in replacement for walk_sysfs. - As for the one change I had to make: I had to fix my /etc/modprobe.conf so that the full path to modprobe was used in the snd-pcm install rule. The udev_update book currently says this will work: install snd-pcm modprobe -i snd-pcm ; modprobe snd-pcm-oss ; true but it will not. You need to have /sbin/modprobe in there, otherwise you'll get unresolved symbol errors when udevd loads the module. 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: Binutils doesn't configure in stage2
Jeremy Huntwork wrote: So. For some reason which I haven't spotted yet, binutils in pass2 isn't creating the binary ld-new, but a bash script, which says in its header: # ld-new - temporary wrapper script for .libs/ld-new # Generated by ltmain.sh - GNU libtool 1.4a-GCC3.0 (1.641.2.256 2001/05/28 20:09:07 with GCC-local changes) # # The ld-new program cannot be directly executed until all the libtool # libraries that it depends on are installed. # # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. Ah, the joys of libtool... ;-) If you want a dynamically-linked ld (probably not required), and you want to copy it out of the source directory, then you're going to need to change the: cp -v ld/ld-new /tools/bin line to be: cp -v ld/.libs/ld-new /tools/bin instead. (At least I'm fairly sure the directory's name is .libs) That file should be an actual binary, not a wrapper script built by libtool. (The wrapper script is built so that ld-new can be run from the current directory, for tests and stuff like that. libtool --mode=install will grab the binary out of the .libs/ subdirectory and copy that to the target directory, instead of copying the wrapper script.) I'm not sure which method is better, actually (static ld versus copying out of the .libs/ subdirectory). But the latter should be possible. 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: merging and consolidating
M.Canales.es wrote: Confirmed :-/ Using mount -bind: 2 tests succeeded 79 tests failed Using the old method to populate $LFS/dev: 81 tests succeeded 0 tests failed The build logs don't show differences beyond ok or failed for each test. I have keeped both build trees, if you need some info from them. Any idea which tests succeeded / failed? What happens if you build with the non-bind-mounted /dev tree, but then test with a bind-mounted /dev tree? (I.e., make a copy of the 81 tests succeeded tree, bind-mount /dev, and rerun its testsuite.) How is your source /dev directory (the source for the bind-mount, that is) set up -- is it static, or udev? (Or devfs?) 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: merging and consolidating
M.Canales.es wrote: Well, all that is beyond my capabilities. Real developers should to try to solve this issue. Not that I'm necessarily a real developer, but I do understand C, so I'll see if I can replicate the failing environment here and do some tests. I have e2fsprogs, but the rest (the chroot and bind-mount stuff) might take a while. What I know is that all that is due the mount --bind change and has no relation with the merge of alphabetical stuff into the udev_update branch, the doing the commit now. I'm guessing right now that it's likely a combination of the bind-mount and the chroot. If we went with Alexander's manually create all the block devices approach[1] instead of the bind-mount, we likely wouldn't have this issue either, though that is just a guess. [1] http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056447.html 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: LFS needs a new server.
Matt Darcy wrote: Bruce Dubbs wrote: I am soliciting donations to the LFS Server Fund. We only need $1000 US. Please consider giving whatever you can afford. Bruce, After speaking to Archaic, I understand your about $500 short of the new dell box. I think - through my business I maybe able to cover that, If not (or if it's more than that, or whatever), I probably can. :-) 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: udev-089 moves some things around
On Fri, Apr 14, 2006 at 09:59:48AM -0600, Archaic wrote: Moved: /sbin/ata_idto /lib/udev/ata_id /sbin/cdrom_id to /lib/udev/cdrom_id /sbin/edd_idto /lib/udev/edd_id /sbin/usb_idto /lib/udev/usb_id /sbin/vol_idto /lib/udev/vol_id Added: /lib/udev/scsi_id /lib/libvolume_id.so.0 /lib/libvolume_id.so.0.61.0 /usr/include/libvolume_id.h /usr/lib/libvolume_id.a /usr/lib/libvolume_id.so /usr/lib/pkgconfig/libvolume_id.pc Note also that the extras/ directory contained a path_id shell script. The etc/udev/60-persistent-storage.rules file contains rules to run this script (in udev-088, it ran the script from /sbin, and -089 runs it from /lib/udev) and create /dev/disk/by-path/* symlinks so you can refer to a disk or partition by its shortest physical path. We don't have an equivalent to anything in this persistent-storage rules file, but we do install all of the helpers -- except, in udev-088, path_id. path_id didn't have its own subdirectory under extras/ in udev-088, and it didn't have its own Makefile either, so there was no way to install it using udev's own build process. But in -089, it does have both of these. So when the book upgrades to -089, I think we should add extras/path_id to the EXTRAS variable in the build and install commands, so we have this script installed. I also personally think we should install the sample persistent storage rules file, so that these helpers get used and stable symlinks get created (in my own builds, I will definitely install it). But that may not be deemed necessary for a base system. pgpelvSsJWSuS.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Fwd: Host System Requirements Page]
Bruce Dubbs wrote: I rewrote this page. Tell me what you think. http://anduin.linuxfromscratch.org/~bdubbs/lfs-book/prologue/hostreqs.html Couple issues I see. First: If the host kernel is either 2.6.x, or it was not compiled using a GCC-3.0 (or later) compiler, you will have to replace the kernel... I think that should read something like: If the host kernel is *older than* 2.6.x, or it was not compiled using a GCC-3.0 (or later) compiler, you will have to replace the kernel... Second, I'm not so sure that gcc-2.95.3 is valid anymore. Certainly it isn't valid for the kernel; it might be less confusing to just require gcc-3.x (or greater) for the entire system. Last, the version-check.sh script doesn't work with my coreutils 5.2.1 installation. chown --version | head -n 1 says chown (coreutils) 5.2.1, but cut is trying to display the fourth space-separated field. There is no such field, so it displays nothing. I hope that this was just a typo (and it should be cut -d -f3 instead), but it is possible that not all coreutils chown programs give the same format output. 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: Measuring disk usage and build time.
M.Canales.es wrote: What I can't undestart is that the book SBU values are smallest that mine :-? Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not, those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot longer than gcc 3.4's did, then that could explain the higher SBUs when building gcc 4. Of course this won't affect other packages unless gcc 4 also compiles slower and binutils was built with gcc 3. (There was another issue with SBUs way back when the book first moved to gcc 3. IIRC gcc 2 compiled stuff faster than gcc 3, so a gcc2 distro built the static bash (or binutils, whichever it was) faster than a gcc3 distro did. And since chapter 6 used gcc 3, the SBU numbers got skewed when the user used one the wrong host compiler.) 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: Measuring disk usage and build time.
Dan Nicholson wrote: The situation you describe doesn't seem like it would have that drastic of an effect on more than a couple packages. IIRC, it really only had an effect on the large packages (gcc, glibc, etc.). And (again IIRC) it wasn't drastic; it was on the order of an SBU or so. So you're right: not drastic, and not many packages. I don't know how widespread the differences here are; I'd chalk most of it up to just not having updated the SBU numbers since 6.1.1. 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: Rally the Troops LFS/BLFS/CLFS/Livecd too
(Resending because I think I used the wrong From: address last time around.) Andrew Benton wrote: install the raw kernel headers from the 2.6.16 kernel in /tools/glibc-kernheaders and compile glibc against them. For userspace, keep using the 2.6.12 sanitised llc headers. Works for me. It worked well for LFS-6.0. It's a tried and tested method that builds glibc against the current kernel API. How will your non-glibc userspace packages use inotify? Yes, glibc has support for its syscalls, but the LLH headers do not, and AFAIK glibc doesn't install headers for it; userspace programs therefore won't be able to detect support for it, and likely won't use it. (Note that this isn't an issue with the openat syscall and ones like it; with those, the only change is a new syscall number, which glibc is able to abstract away. But inotify has a syscall, plus a few constants, plus at least one struct -- inotify_event.) I'm not so sure that your proposed solution is going to provide all the capabilities of the kernel to userspace programs. OTOH, many of these programs have to have a way to fall back to something different if they run on a kernel that doesn't support them, so in theory it shouldn't break any of these programs. 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
