Re: Udev_update branch: /dev/pts and /dev/shm directories not created
Matthew Burgess wrote: > Alternatively, what purpose does populating /dev do at this stage? Instead of populating /dev why not just bind /dev to $LFS/dev. mount -o bind /dev $LFS/dev > Does something we build later on actually require devices in there > that we haven't yet got available to us? Grub requires the nodes for your hard drive to install the mbr and I know some packages in blfs that I would normaly install in the chroot require /dev/urandom. It might be openssh. -- 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
Archaic wrote: >If one is to follow the LFS book, one must have devices present prior to >installing the MBR. That alone is reason to sort out this problem. We >used mount --bind before. Perhaps it is time to bring it back. > > I agree with that. > But any and all post-LFS package building is irrelevant in this context. Not really, as bruce said he builds openssl/openssh in the chroot, I do also along with a whole system sometimes. openssh requires urandom and/or random in /dev for creating the keys. But you are half right because by the time anyone would get this far they *should* have already installed the grub mbr which requires the proper nodes in /dev such as [h,s]d[a-z]#. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #684: Must re-evaluate package order then document the rationale.
Gerard Beekmans wrote: > If a symlink allows us to leave grep in its proper location in the > alphabet, I don't see a problem with that. We just want to make sure > that grep's "make install" replaces the symlink rather than overwrite > the target in /tools. > As much as an alphabetical branch makes sense, moving a few packages out of order doesn't seem like a bad idea to me. I would rather satisfy the dependency with the actual package then create a symlink. > Seeing /tools isn't deleted until at the very end of Chapter 6, the > symlink method would be perfectly safe IMO. > > I don't see a technical reason for symlink vs. no symlink (and > subsequently moving the Grep package itself). I think it's a > preference what is considered "nicer." > I agree 100%. > A symlink is less work than moving the package itself and the move has > no added benefit as far as I can tell. > The only benefit is not having to create one more symlink at the beginning of the chapter. > I'm changing my vote from moving grep to symlink grep unless a valid > technical reason comes up that warrants not using a symlink. We should > still move libtool. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Jim Gifford wrote:
> I also noticed that LLH moves things from asm-generic and incorporates
> them into asm-{arch}, so that kinda of throws things off a little.
Just an idea, leave it seperate until the parsing is done then copy|move
the headers from asm-generic to asm-{arch}. This might be a little bit
speedier then to copy|move them first.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Wireless Tools
Bruce Dubbs wrote: > You can edit the wiki. Just register and log in. > > > Joe, Do you want me to put what I have so far into the wiki? I have my wireless service script at http://www.linuxfromscratch.org/~jciccone/wireless . My intentions are to put a link to that script and information on configuring it. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: PAM (from D-Bus/HAL discussion)
Randy McMurchy wrote: > But you never answered my question, what did you do to get inotify to > work on a stock LFS system. It is becoming clear to me now, but how > you're getting inotify to work is still a mystery to me. > I figured out why I have it, I have /usr/include/sys/inotify.h provided by glibc-2.4. gnome-vfs picked that up. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: PAM (from D-Bus/HAL discussion)
Randy McMurchy wrote: > On Fri, 2006-04-07 at 16:05 -0700, Dan Nicholson wrote: > > > But the "you don't need HAL thing" with others saying the userspace > app is dependent on HAL, just has me totally confused at this point. > > A lot of the packages don't *require* build and function, Building without dbus/hal can greatly cut the features down a but, eg. gnome/kde without hal basicly means no volume management. etc... -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Users and Groups
I put this page together with the users and groups from LFS and BLFS. The only addition I made to this page is a users groups with a gid of 100. Anyone that wants to set something in stone, this would be a good place to start. http://www.linuxfromscratch.org/~jciccone/users.html -- 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.
Robert Connolly wrote: > What is the status of the new belgarath hardware? > > P.S. > Has a macintosh (or other odder hardware) been considered? > Would 5 Macintosh Plus systems be enough? I think they have at least 1Mb of ram each and a low density floppy. -- 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
Bryan Kadzban wrote: > 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? > I'm unaware of what glibc-2.3.6 does. glibc-2.4 does install /usr/include/sys/inotify.h regardless of whether linux/inotify.h is found. -rw-r--r-- 1 root root 3251 2006-03-07 21:15 /usr/include/sys/inotify.h ls: /usr/include/linux/inotify.h: No such file or directory -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Need advices about make textinfo
Andrejs Spunitis wrote: > /mnt/src/texinfo-4.8/info/terminal.c:236: undefined reference to `tgoto' > /mnt/src/texinfo-4.8/info/terminal.c:236: undefined reference to `tputs' > Support questions should be directed to the lfs-support list. The symbols tgoto and tputs are from ncurses. You might want to check if ncurses is installed into /tools. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: > How robust is this? It would seem to work if there are two cdroms, but > does it generalize to the admittedly unusual case where there are more > than two? I'm not sure how the drives are recognized. I only have one > and it is at "/sys/bus/ide/drivers/ide-cdrom/0.0" What do the digits > before and after the dot stand for? bus.device as in hda => 0.0 ... hdd > => 1.1 ? > > Since my hard disk drive is sata and recognized as sda, would this work > if I have a cdrom on hda and hdb? Hard coding the 1 doesn't seem to be > right to me. > > It seems to actualy be very robust, I just created a virtual machine with a LOT of cdroms. lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom -> hdb lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom0 -> hdc lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom1 -> hdd lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom2 -> sr2 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom3 -> sr3 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom4 -> sr4 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom5 -> sr5 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom6 -> sr6 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom7 -> sr7 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom8 -> sr8 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: > > That's cool. What happens if there is a cdrom on hda too? > I put my harddrive on hdb and created a cdrom on hda. This has the same pattern as the last one. lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom -> hda lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom0 -> hdc lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom1 -> hdd lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom2 -> sr2 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom3 -> sr3 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom4 -> sr4 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom5 -> sr5 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom6 -> sr6 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom7 -> sr7 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom8 -> sr8 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: > > Joe, > I was asking about the situation where I have my hard disk on sda and > a cdrom on hda AND hdb. It's probably not a smart way to go, but its > possible. > > -- Bruce > I set my vm back to normal and it's doing some work now so I'm not going to test. But what would make sense is that /dev/hda will be /dev/cdrom /dev/hdb will be /dev/cdrom0 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unifying the Udev Rules Packages
Matthew Burgess wrote: > Rather than creating a whole new package, why don't you just list what > you don't like about the current LFS rules? Or has this been done > before and I missed it? As far as I know both sets of rules work exactly as they're intended to. There is nothing wrong with either set of rules. The only problem is that they're 2 almost completely different sets of rules in terms of their layout. Ideas have been shared to get them to the state they are know but they still have their differences. It would be nice from a debugging standpoint to have one common set of rules. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unifying the Udev Rules Packages
As I've been reading this thread I noticed one common theme. control.
The main problem that I think is holding us back is that some people
don't want to give up their control over *their* udev rules.
Yes, The packages are almost identical.
Yes, It would be easy to use cat to create extra rules specific to
different architectures in clfs.
Yes, Udev is a fast moving target.
These are all reason to create a common udev package. Instead of having
3 people working on the lfs udev package and 5 people working on the
clfs udev package. There could be 8 people working on the common udev
package and keeping that up to date and tested. It *could* exist in the
lfs repo but if it is not *just* lfs specific. Wouldn't it make more
sense to keep it in a seperate repo?
As Archaic just wrote in a recent email:
> But what about all the other changes? We need to discuss all differences
> and sort out which way to go every step
I think it would make a lot more sense to keep everything related to
udev in one place. The people that are given commit privileges wouldn't
be restricted to just the people in {c,h,}lfs but, rather to the people
that would like to work on the udev package.
The discussion of the udev package could happen on the lfs-dev list.
Maybe it would even have it's own mailing list and trac setup. As said
before, Udev is a fast moving target, 2 different packages trying to
achieve the exact same base (minus architecture specific rules) doesn't
make much sense.
As for ignoring the clfs package and using the lfs package, or
vice-versa. I don't think either one should be ignored but just
combined. The Makefile could be removed and replaced with cp commands to
copy the desired rules.
As I said in a previous email yesterday and in this email, there is
nothing wrong with either set of rules, There is only the existance of 2
different packages maintained by 2 different sets of people, where there
is no need for it. Both the people that worked on the lfs udev package
and the people that worked on the clfs udev package have seem to have a
solid understanding of writing udev rules. Lets put all those people
together.
I think a svn repo should be added for a common set of udev rules. I
will be willing to go through both the lfs rules and the clfs rules,
find all of the common rules, and mosh them together into one common
package. I don't think I will beable to get to it until the end of the
week, but by then, I hope there is a more solid decision.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Unifying the Udev Rules Packages
Archaic wrote: > On Tue, May 23, 2006 at 09:03:05PM -0400, Joe Ciccone wrote: > >> I think a svn repo should be added for a common set of udev rules. I >> will be willing to go through both the lfs rules and the clfs rules, >> find all of the common rules, and mosh them together into one common >> package. I don't think I will beable to get to it until the end of the >> week, but by then, I hope there is a more solid decision. >> > > Replying to you and Randy, everything you described has already been > started. The repo exists now in the LFS repo. Feel free to check it out > and also to look at my email that detailed all the changes currently > made. There's more in my working copy as well. Things like adding more > subsystem rules so a few more devices won't need to be enumerated. > > svn://linuxfromscratch.org/LFS/trunk/udev-config > > > I'm aware of that repo and the repo at svn://linuxfromscratch.org/cross-lfs/trunk/udev . My point is to combine these 2 directories and put them in a separate repo maintained by the people who have worked on both of these. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PROPOSAL -- new group to handle multi-project tasks
I agree with the ideas in this proposal. The one idea that I'm going back and forth on is whether the blfs-bootscripts should become part of the base scripts. >From one side, you'd only need one tarball. How often do the bootscripts get changed? It would possibly be easier to maintain. >From the other side, What if an update needs to get done and no-body is around to do it? Maybe more then just DJ and Nathan need to have access to the bootscripts. Maybe the people who write bootscripts need to have access to the bootscripts repo. So if a change is needed to be done a.s.a.p. it can be done. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts - Why combining is a bad thing
Chris Staub wrote: > Randy McMurchy wrote: >> Jim Gifford wrote these words on 05/30/06 11:56 CST: >> >> I know I said no more replies. But this is important. Jim, you just >> made my point for me. If these "consolidated" bootscripts need to be >> updated, what is the point in consolidating them? >> >> What text will be in the LFS book. "Here is the current LFS tarball >> to install after you complete LFS. It also has BLFS bootscripts in >> it, but they probably aren't current, so you'll need to get a >> different tarball for BLFS." :-( >> >> That is what we have now, two different tarballs. >> > > Yeah, that's what I'm thinking, though more because of potential user > confusion rather than technical issues. I agree that BLFS bootscripts > should be separate. As nice as it would be to have one tarball, and as unreal as that scenario seems, the possibility still does exist, I have to agree that the blfs bootscripts should remain seperate from the base bootscripts. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts - Why combining is a bad thing
Having everything in one repo but releasing the base scripts and the blfs scripts in 2 separate tarballs sounds good to me. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future plans for xLFS
Dan Nicholson wrote: > Cool. Any major differences? Did you guys ever have to deal with the > legendary "libtool can't handle sysroot" problem? Does the toolchain > adjustment change drastically? > > Don't rush to answer. I'm just a curious cat. > > -- > Dan I've probably done about a dozen builds by now and I haven't seen libtool puke yet. My personal goal is to beable to cross-compile myself a final-system with fluxbox on it for my PDA. Currently, there isn't a toolchain adjustment. First you install your linux headers. Then you build binutils. Then you install glibc headers (tricking glibc into thinking nptl for that arch exists). Then you build a cross-compiler for your arch and install glibc into the sysroot. In the end you have a toolchain where you can pass -L/usr/lib -lssl and ld will look for libssl.so in [sysroot]/usr/lib. It's a very interesting build process. I'm uploading the current book to http://www.linuxfromscratch.org/~jciccone/cross-lfs-2.0/ right now. Comments are always welcome. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatic tarball generation
While I was waiting for my internet to come back I sat down and wrote
this, Havn't tested it, But the idea is there if you want it.
#!/bin/bash
tmpdir=$(mktemp -d)
pushd $tmpdir
# Change the checkouts to file:///
svn co svn://svn.linuxfromscratch.org/LFS/trunk/BOOK
DATE=$(grep '/" \
-e "/lfs-bootscripts-md5/s/ \".*/ \"$(md5sum
${bootscripts_tar})\">/"
# Some crazy stuff to add a changelog entry here
svn ci -m "Automated: Updated to ${bootscripts}" BOOK
fi
udev_config="udev-config-${DATE}"
udev_config_tar="/path/to/download/${udev_config}"
if [ ! -f "${udev_config_tar} ]; then
svn co svn://svn.linuxfromscratch.org/LFS/trunk/udev-config
"${udev_config}"
find "${udev_config}" -name .svn -type d -exec rm -rf '{}' \;
tar cjf "${udev_config_tar}" "${udev_config}"
sed -i BOOK/packages.ent \
-e "/udev-config-size/s/ \".*/ \"$(du ${udev_config_tar})\">/" \
-e "/udev-config-md5/s/ \".*/ \"$(md5sum ${udev_config_tar})\">/"
# Some crazy stuff to add a changelog entry here
svn ci -m "Automated: Updated to ${udev_config}" BOOK
fi
popd
rm -rf $tmpdir
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Automatic tarball generation
Bruce Dubbs wrote: > The daily script for generating the book now automatically generates the > udev and bootscript tarballs. When making a change to either, the > packages.ent has to be updated manually with the version date and md5sum. > > I'd like to automate this further, but I don't know of a way to > determine the date of the last check in in a subtree. It would also > require a sed to packages.ent and a commit to the repository to keep the > xml in sync. > > Perhaps we can get back to this after 6.2 but its time to move on toward > the release. > > -- Bruce > You can get the date with this command or something similar: svn cat svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/general.ent | awk '//" here's what I would do: #!/bin/bash tmpdir=$(mktemp -d) cd $tmpdir svn co svn://svn.linuxfromscratch.org/LFS/trunk/BOOK svn co svn://svn.linuxfromscratch.org/LFS/trunk/udev svn co svn://svn.linuxfromscratch.org/LFS/trunk/bootscripts # Commit the book back -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatic tarball generation
Bruce Dubbs wrote: > Joe Ciccone wrote: > > >> You can get the date with this command or something similar: >> svn cat svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/general.ent | awk >> '/> > > Sure. I'm already doing that. The problem is detecting when a commit > was made since the entity was last changed. > > -- Bruce > You could always make the package anyway. Check the md5sum and if it's different change it in the book and copy it over to the downloads dir. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: fomit-frame-pointer sed in gcc pass2/3
Bruce Dubbs wrote: > Robert Connolly wrote: > >> This isn't a bug, but the line: >> >> sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' >> >> can be problematic if a user uses this command to modify other variables, >> because the -fomit-frame-pointer is appended to the end of the line. Some of >> the *FLAGS in GCC end with a \ character at the end of the first line, and >> this command won't work. I suggest we stop using the "$" (end-of-line) card, >> and use: >> >> sed 's/^XCFLAGS =/& -fomit-frame-pointer/' >> >> so that -fomit-frame-pointer will be added as the first argument, and the >> sed >> will work in any case. >> > > I'd be interested in other opinions. > > My initial reaction is that if users apply something to a location that > is not specified, they can live with the consequences. They can also > learn the meaning of a sed construct through making a mistake. > Why would you want to force someone down the road to making a mistake. I would bet that a lot of people would just c&p the command and move on, without giving it a second thought. Roberts change doesn't affect the people who have an empty line. But it will benefit the people who may already have something on that line. Forcing someone down the road to making a mistake does not seem like a reasonable decision to me. It'd probably be better to teach them why the sed is the way it is, not tell them that, "This command may not work for you, If in fact the change isn't made and this sed fails, please figure it out for yourself." A lot just simply wont or sign onto the irc server to ask how. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: fomit-frame-pointer sed in gcc pass2/3
Alex Merry wrote: > > But surely the only way anyone would have anything on that line is if > they'd already been doing something different to the book, in which case > (especially with the toolchain) they should be acutely aware of what the > instructions do and the possible implications of any changes to them. > > What if they were to miss the command but executed it anyway. Why do you insist on making stuff harder for people who want to deviate from the book a little tiny bit. > Robert was suggesting a change that would allow the sed to be applied to > other *FLAGS variables. When you consider the dangers in constructing and > running commands you don't fully understand in the compilations of > toolchain packages, it seems to me that it would be sensible to actively > discourage such an activity. > No, His suggested sed would still only affect that one line. I'll even copy it from his origional email so you can look at it again. sed 's/^XCFLAGS =/& -fomit-frame-pointer/' It will still only modify the line starting with "XCFLAGS =" > In fact, I believe Robert misunderstood the sed, thinking it was > something like 's/^XCFLAGS =.*$/& -fomit-frame-pointer/'. If they tried > to adapt, say, XFOOFLAGS using this method and XFOOFLAGS looked like: > XFOOFLAGS = -blah -foo \ > -bar > then the sed 's/^XFOOFLAGS =$/& -baz/' would do precisely nothing. So > users trying this method who don't know what they're doing end up doing > nothing rather than screwing up their compilation. > Let's quote something from the lfs book. In section 1.5.1 there is a note that states exactly the following, " Deviating from this book does /not/ mean that we will not help you. After all, LFS is about personal preference. Being upfront about any changes to the established procedure helps us evaluate and determine possible causes of your problem." There is no reason for this sed to have the $ in it. I may apply a patch to gcc that adds a value to that line. This is deviation from the book, but in fact, the sed with the $ in it will render the command useless if I update this line myself. Why make it hard for people who want to deviate from the book when in section 1.5.1 it says that lfs is about personal preference. Maybe my personal preference is to add something to the XCFLAGS line before I run the sed but, I overlook what the sed does. It just simply doesn't make sense to me to change the command to benefit others without sacrificing anything! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: bash patch in chapter 5
Bruce Dubbs wrote: >> p.s.: I haven't actually verified that the LFS patch fixes the issue, >> since I'm not through with my current build yet. All I know is that the >> Gentoo patches fix this issue (and have done so for some time now). >> > > Please verify that the existing patch does indeed fix the issue. I > don't want to add a new patch to 6.2 for this issue, but using the > existing patch would be OK. > > The lfs patch does in fact fix the issue. [EMAIL PROTECTED] ~ $ echo "$(echo $';foo')" ;foo I don't see a need to patch bash because I've never had a problem, I can only speak for myself on this one. But, If it's going to benefit some people it couldn't hurt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS environment with newer kernels; Thumbs Down.
Dan Nicholson wrote: > I believe it would work with kernels back to 2.6.15, 2.6.16 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Mounting Virtual Kernel File Systems
Peter wrote: > I would use this in place of what is > in 6.2.3. Mounting Virtual Kernel File Systems. > I want to take care of the mount error that is > possible by resetting the build from > scratch without a reboot because the > book does not explicitly create pts and shm > and leaves it up to mount --bind. > In your /dev directory on your host, you *should* have /dev/pts and /dev/shm. If you don't... That's just weird. The book *should not* have to create pts and shm in $LFS/dev. If those *mount points* exist in /dev then they will exist in $LFS/dev after the mount --bind. Creating them before you mount --bind doesn't make any sense because the mount --bind will put /dev on $LFS/dev causing all the contents of $LFS/dev before the mount --bind to be hidden. So, if your host doesn't have these directories, which I doubt it doesn't. Then they should be created *just before* mounting $LFS/dev/pts and $LFS/dev/shm. But not before mounting $LFS/dev. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Build Logs for 6.2
Someone just signed onto IRC and asked when the build logs are going to be available. http://www.linuxfromscratch.org/lfs/build-logs/6.2/ - Appears to be empty. I don't normally run test-suites or I'd send you my logs. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Possible Udev Rule Bug?
In 25-lfs.rules there is, KERNEL=="fb[0-9]*", MODE="0620",GROUP="video" Shouldn't the mode be 0660? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Possible Udev Rule Bug?
Alex Merry wrote: > However, some programs use read access. links appears to use read access > to scroll the screen. > > > And that is the program that was reported to not work with a regular user in graphic mode. I told the person to change it to 660 and it worked after that. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: linux-2.6.17 and openat
Testing this patch right now but, I'm fairly certain that it's going to work. If you want the short and sweet version see the attached patch, else read on. Looking at "sysdeps/unix/sysv/linux/openat.c" on line 31 I see. #if !defined OPENAT && !defined __ASSUME_ATFCTS # define OPENAT openat This is the only place where OPENAT is defined with a conditional. __ASSUME_ATFCTS is defined in "sysdeps/unix/sysv/linux/kernel-features.h" with this block of code, That chunk starting on line 464. This is the last think in the file. /* The *at syscalls were introduced just after 2.6.16-rc1. Due to the way the kernel versions are advertised we can only rely on 2.6.17 to have the code. */ #if __LINUX_KERNEL_VERSION >= 0x020611 \ && (defined __i386__ || defined __x86_64__) # define __ASSUME_ATFCTS1 #endif The kernel version for 2.6.17 is 0x20611. Now, We just need to figure out when __ASSUME_ATFCTS became independent. So I went to take a look at, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/kernel-features.h?cvsroot=glibc and got some good info. I know that in rev 1.91 __ASSUME_ATFCTS was added to "sysdeps/unix/sysv/linux/kernel-features.h" So, In the past say rev 1.1 of "sysdeps/unix/sysv/linux/openat.c" OPENAT was set with the following, #ifndef OPENAT #define OPENAT openat The change happened between rev 1.2 and 1.3 of that file, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/openat.c.diff?cvsroot=glibc&only_with_tag=MAIN&r1=text&tr1=1.2&r2=text&tr2=1.3&f=u , The description is just "Use syscall if available." which leaves me in the dark about that. But if my logic isn't flawed, the #define OPENAT openat needs to be put in it's own ifndef below the #if !defined OPENAT && !defined __ASSUME_ATFCTS. See the patch. The things people do on their time off! Submitted By: Joe Ciccone <[EMAIL PROTECTED]> Date: 2006-08-17 Initial Package Version: 2.4 Upstream Status: Unknown Origin: Joe Ciccone Description: Fixes the logic that decides if OPENAT gets defined or not. diff -Naur glibc-2.4.orig/sysdeps/unix/sysv/linux/openat.c glibc-2.4/sysdeps/unix/sysv/linux/openat.c --- glibc-2.4.orig/sysdeps/unix/sysv/linux/openat.c 2006-03-01 00:32:42.0 -0500 +++ glibc-2.4/sysdeps/unix/sysv/linux/openat.c 2006-08-17 11:22:16.0 -0400 @@ -29,8 +29,6 @@ #if !defined OPENAT && !defined __ASSUME_ATFCTS -# define OPENAT openat - /* Set errno after a failed call. If BUF is not null, it is a /proc/self/fd/ path name we just tried to use. */ void @@ -63,6 +61,9 @@ int __have_atfcts; #endif +#ifndef OPENAT +# define OPENAT openat +#endif #define OPENAT_NOT_CANCEL CONCAT (OPENAT) #define CONCAT(name) CONCAT2 (name) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Dead Project? (I hope not)
Randy McMurchy wrote: > Hi all, > > Noted that there is some minor trivial updates to CLFS recently, the > occasional package updates to LFS, and updates to jalfs (which is only > as good as the [x]LFS books), there really is no development going > on at all any more within the LFS project. > CLFS is in a package freeze due to the pending release. That's why their hasn't been any updates, A Lot of testing is still being done. I lost count of how many builds I did today (through X11). > Discussion (you know, where people interact and contribute different > thoughts and ideas) is almost nil on the lists and commits have come > to a slow crawl. > There really hasn't been much technical discussion on the lists recently, There hasn't been any major changes in a while. I think it's about time that LFS gets bumped up to gcc-4.1.1 and glibc-2.4. And switches to a newer linux-headers package. BLFS will only need a few patches to support gcc-4.1.x which I probably already have in my public_html directory on linuxfromscratch.org and cross-lfs.org. > This only means there is total apathy within the project, and nobody > really cares any more. > I really hope that this isn't the case. > I am really concerned about the health of the entire overall project. > Recently there was a call for funds to replace the Belgarath server. > Funds were raised in a matter of days. For all practical purposes, > anyone who contributed money, wasted it. That call for funds (and the > raising of it) was *many* months ago. There has been no effort to even > explain where the donated money went (other than someone bought some > hardware, and has it, but won't commit the couple of hours it would > take to put it online). > That is one thing that really tics me off. Belgarth is on its knees and the new server, if there even is one, is probably sitting in the bottom of someones closet. I think it's safe to say at this point that there isn't a new server at all. > The entire LFS project seems to be in the toilet. Am I the only one > that thinks this? Am I over reacting? > > Is there anyone else concerned about the health of the project? > I love this project, I never want to see it go under. But, Unfortunately I don't think you're over-reacting. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Dead Project? (I hope not)
Matthew Burgess wrote: > > Glibc I've not upgraded because I was put off by upstream's > recommendation not to run it in production environments coupled with a > couple of bugs I've read about on the lfs lists. They've probably > been fixed by patches, but I've lost track of those! If anyone can > recall what's required to get glibc-2.4 in the book, I'll gladly put > it in. This patch definitely needs to be added. http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.4-iconv_fix-1.patch The openat patch really only applies if you're building glibc with --enable-kernel=2.6.17. (uses 2.6.0 currently.) So It doesn't need to be added, Just mentioning it for the people that may want to. http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.4-openat-3.patch The 2 patches that are on the page now, glibc-2.3.6-linux_types-1.patch and glibc-2.3.6-inotify-1.patch can be dropped. Inotify is built in 2.4 and I built xorg-7.1 twice last night without the linux_types patch. It looks like there is a command to copy the inotify header to /usr/include/sys which can also be dropped. Other then the fact that I have no idea if there are any problems with libidn (I don't use it), that looks like about it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: linux-2.6.17 and openat
Moshe wrote: > Hi Joe, > > If you are testing the openat patch, > please do not forget to change > the __OPENAT () definition from K&R style: > > __OPENAT (fd, file, oflag) > int fd; > const char *file; > int oflag; > > to the variadic function: > > __OPENAT (int fd, const char *file, int oflag, ...) > > or you will not be able to compile the openat.c file. > This is the patch that has proved its self to work (on x86, x86_64, mips, and alpha). I see no reason to convert the function from K&R (whatever that is). That statement has nothing wrong with it. http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.4-openat-3.patch -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Dead Project? (I hope not)
Dennis J Perkins wrote: > > Maybe replacing sysvinit with runit (?) or something similar for faster > booting? Might be better as a hint or BLFS, altho I would prefer having > a choice of packages when sysvinit is installed. That would probably > cause problems with the bootscripts tho. > > Tape my mouth shut if I'm wrong here but this would probably be a good thing to put in the wiki. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: xLFS Book Licenses
Bruce Dubbs wrote: > He and Ryan are proposing the Open Publication License, > http://www.opencontent.org/openpub, for all the books. I've looked at > it and it seems to meet the standards of having a recognized license and > protecting the books. If it is the community's decision, I have no > problem with using this in BLFS. It is used by several organizations > including: > I honestly don't know one license from the other. But the OPL looks like it would protect LFS from being published by a 3rd party. Which is really the main thing in my eyes. > In addition to the main license, I also feel that the books should dual > license the code (scripts and config files) in the the books with a very > open license such as the AFL currently in BLFS or a BSD type of license. > The reason is to basically leave the instructions unencumbered. For > instance, IMO, the output of jhalfs should not have the requirements of > the OPL, but with only one license there would be unnecessary overhead > if the instructions are extracted from the books. > > Ryan suggested the GPL for the code, but that has a lot of overhead that > I don't feel is necessary. For instance, there would be a need to put > relatively long GPL statements in each file in the bootscripts and the > need to include extra copyright files with the jhalfs output. > Just one scenario I'm curious about. Say I have a distro based on xLFS and I would like to give it away/sell it. How is that going to affect what I'm able to do (give away/sell). Under the OPL it looks like that wouldn't be possible to do either without the author(s) permission. Would the second license on code (scripts and config files) change this scenario? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc-2.4 / kernel-headers
Ken Moffat wrote: > On Mon, Sep 18, 2006 at 10:05:08PM +0200, Thomas Trepl wrote: > >>> ... Next major change will be the kernel headers. >>> That's another discussion, though. >>> >> I think we should start it! IMHO the -rc7 is what we can expect in 2.6.18. >> With the -rc7, I actually built a system on my laptop (500MHz-PIII yawn!). >> On >> my server, an installation using -rc5 is up and running (KDE, cdrtools, >> sound, Samba, Apache, PostgreSQL, xine, etc.pp...) >> >> > I'm just catching up on today's lkml, and almost the first mail was > a reply to a mail from last week saying that most arches fail the > validation (i.e. they include headers which aren't exported), saying > that there are even more problems - from the sound of it. x86 is one > of the problem arches. I'm sure that this will be fixed eventually, > but I think Linus needs a lot of persuasion that the headers matter, > so 2.6.18 might have problems. > > But thanks for the encouraging news that a desktop can be built > with those headers! Using the in-kernel headers is on my list of > things to try once we've got CLFS-1.0 out. I tested the in kernel headers on mips/alpha/sparc. There were a lot of problems. silo and aboot didn't want to build right. The build had so many errors in it, on all 3 of the archs, That I just walked away. I did have a succesful build on x86 and x86_64. I didn't test arm or hppa. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc-2.4 / kernel-headers
Ken Moffat wrote: > On Mon, Sep 18, 2006 at 07:13:27PM -0400, Joe Ciccone wrote: > >> I tested the in kernel headers on mips/alpha/sparc. There were a lot of >> problems. silo and aboot didn't want to build right. The build had so >> many errors in it, on all 3 of the archs, That I just walked away. I did >> have a succesful build on x86 and x86_64. I didn't test arm or hppa. >> >> > Joe, thanks for this datapoint. It's comments like this that make > me glad I've only got a limited variety of hardware. (/me recalls > how long it took to get a working config for my ibook on > ARCH=powerpc). > > More on-topic for this list, x86 now has two reports of successful > builds. Maybe LFS should reclaim its 'bleeding edge' position and > switch to the 2.6.18 headers as soon as the new kernel is out, then > let people here and in BLFS find out if anything is broken in use ? > After all, x86 is "common as muck" so if things don't work there, > they probably don't work at all ;) > The clfs headers package has built me a gnome/kde system on x86, x86_64 (pure64 and multilib), and alpha. A GPE arm system using kdrive as a X server. And a fairly full mips (multilib) and sparc (multilib) system. Glibc isn't too nptl friendly on hppa right now so I havn't gotten to far into a build, But there doesn't seem to be any header obvious header issues. If I had to choose a headers package. It would be the clfs headers package over what is in the kernel for now. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #1882: 3.2 All Packages, "Do not use version 2.6.17 or later kernels ..."
LFS Trac wrote: > #1882: 3.2 All Packages, "Do not use version 2.6.17 or later kernels ..." > > Thanks. That's a holdover from LFS-6.2. I'll change that. > I can't say I've ever seen serious incompatibilities in between kernel versions with bootscripts. "Potentional incompatibilities with the bootscripts" doesn't seem like a good explanation of why not to use 2.6.18 (Which I upgraded to this afternoon). The only incomatibility I can see is if you built glibc with --enable-kernel-2.6.17 and then tried to use 2.6.12. I can see some problems in that scenario. What kind of incompatibilities are we talking about? udev? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #1882: 3.2 All Packages, "Do not use version 2.6.17 or later kernels ..."
Bryan Kadzban wrote: > Joe Ciccone wrote: > >> What kind of incompatibilities are we talking about? udev? >> > > IIRC, yes -- I think we started doing that when some kernel changed the > layout of /sys. More recently, there's a kernel version floating around > somewhere that uses /sys/class/block instead of /sys/block for block > devices; that may break the udev script. I think it would make more sense to say udev bootscript and a reason, like the one mentioned above, instead of the bootscripts in general. The comment is open to a lot of interpretation. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: patch for /etc/rc.d/init.d/gpm from blfs-bootscripts-20060624
Dan Nicholson wrote:
> On 8/13/06, Christoph Feikes <[EMAIL PROTECTED]> wrote:
>> Hello!
>>
>> First I like to thank everyone involved for the excellent work on LFS
>> and BLFS!
>>
>> I'd like to suggest a little modification of "/etc/rc.d/init.d/gpm" from
>> "blfs-bootscripts-20060624.tar.bz2":
>
> Thanks for the submission, Christoph. Sorry for the extremely late reply.
>
>> -if [ -z "$MDEVICE" ] || [ -z "$PROTOCOL" ]
>> +if [ -z ${MDEVICE} ] || [ -z ${PROTOCOL} ]
>
> This needs to stay with the "" for sh compatibility unless either of
> these variables is empty. Bourne sh can't handle [ -z ], which is
> what would happen without the "".
>
>>
>> - loadproc /usr/sbin/gpm -m "$MDEVICE" -t "$PROTOCOL"
>> "$GPMOPTS"
>> + loadproc /usr/sbin/gpm -m ${MDEVICE} -t ${PROTOCOL}
>> ${GPMOPTS}
>> ;;
>>
>> stop)
>> --->8-->8---
>>
>> I replaced the double quotes witch curly braces. Then you can write eg
>> GPMOPTS="-B 321" in "/etc/sysconfig/mouse" to swap the mouse buttons...
>
> So, with the "", gpm doesn't handle the multiple arguments correctly?
> I actually don't think the {} are needed, but they can't hurt. Could
> you see what happens if you just have $MDEVICE, etc.
I think the "" should remain around MDEVICE and PROTOCOL because they
are meant to be single arguments. But GPMOPTS doesn't have to be a
single argument.
Lets say GPMOPTS = "-a -b". With the "" the command would be gpm "-a -b"
but without the "" the command would be gpm -a -b. There's a big
difference there. "-a -b" is one argument. -a -b is 2 arguments.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Mailing List Search
Trying to search the mailing lists resulted in a very large and bold, "Access Denied!" -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: IRC
Bruce Dubbs wrote: > TheOldFellow wrote: > >> Declan Naughton wrote: >> irc has not been installed on the new server yet. Its another opportunity for me to learn something new. :( >>> Why don't we just use Freenode? There is an established #lfs channel >>> there. Do we really need to run our own IRC server? >>> >>> >> Two reasons from me. >> >> 1) In days of yore, when LFS was in active development with tens of >> editors and other interested parties, we needed about five channels to >> sort out all the traffic. >> Not to mention the huge about of people in #lfs-support looking for help. >> 2) Bruce needs the practise :-) >> > > Yeah, yeah. OK, what server is preferred? > > How about ftp://ftp.funet.fi/pub/unix/irc/server/irc2.9.5.tgz ? > > -- Bruce > Unreal (http://www.unrealircd.com/) is a fairly good one. It's what I developed the resident bot on. Very configurable. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: (hostname) login:
Barius Drubeck wrote: > On Monday 29 January 2007 05:49, Marty _ wrote: > >> dont suppose anyone knows the general needed commands/utils for a >> successful login? >> i.e. i have '(hostname) login:' >> i type root >> waits 20-30 seconds >> and repeats. >> >> sulogin works inside the bootscripts. >> shadow has been installed. (and running, inside bootscripts to make >> certain) All the drives have been set up, fstab is fine, devices >> load successfully. >> >> Any ideas? >> > > I vaguely remember seeing something similar when experimenting with a > minimal chroot. IIRC the problem was that login couldn't locate the > shell (Bash) but I don't remember the exact mechanism. > > > Another possibility is that /etc/login.defs is missing or mis-configured. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bryan Kadzban wrote: > > On the topic of parallelizing the bootscripts, what do people think > about doing this? DJ has added some easily-parallelizable scripts to > the contrib/ directory in the bootscripts repo (basically, by making > them LSB compliant, you make them easy to run in parallel). Should we > look into making these scripts the default, perhaps for LFS 6.4 or 7? > (And should we actually run them in parallel or not?) > > I'm all for parallelizing the boot scripts. The only thing I'm having a hard time getting my head around is updating the screen with the status. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bruce Dubbs wrote: > > > I guess I still don't understand the need for this. I just did a test > on my laptop and it took 18 seconds from the time I pushed enter from > grub to a login prompt. This included udev, dbus, hal, sshd, nfsd, but > not X, ntp, or bringing up my wifi card. > > > 14 is still better then 18. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bryan Kadzban wrote: > > > That's part of what DJ's contrib/ LSB scripts help with. Instead of > printing "starting X...", then later printing either "OK" or "FAILED", > the LSB interface basically forces you to build the whole line in a > string, and then echo it all at once. This helps parallel scripts > because the normal console locking prevents different scripts from > stepping on each other. (At least, I hope it does.) It also lets you > do boot logging more easily. > > I guess that's probably the easiest way to go about it. I'd still rather see a way to view the progress. I guess the alternative would be to write a custom program to use as the interpreter instead of bash and have that program talk to itself via something (dbus maybe?) and update the screen using ncurses (scrollable boot log?). But I don't think that's a valid solution for LFS, but maybe hint or wiki material. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[Fwd: [Clfs-dev] Dead Link]
--- Begin Message --- Hello, I found dead Link(s) in the Documentation: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/nano.html The Link to this Page is dead: ftp://ftp.uni-koeln.de/editor/nano-2.0.1.tar.gz Thanks Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Clfs-dev mailing list Clfs-dev@lists.cross-lfs.org http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev --- End Message --- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: IRCD logs
Dan Nicholson wrote: > I was wondering if the IRC logs are available online. It doesn't look > like it to me, at least not at the old location: > > http://www.linuxfromscratch.org/~ircd/ > > But that makes sense since ircd is not in a home directory anymore on > quantum, but in /srv/ircd. I don't know if any extra setup is needed > in ircd or httpd.conf, but at least /srv/ircd has too restrictive > permissions for this to happen. > > I CC'd Joe since I'm pretty sure he has some experience here and may > have set up the old logging system. I believe it was Archaic that setup the old logging system. There was a bot that idled in each channel. This would be easy enough to do again. I'm not a fan of having public logs though. Many people idle 24/7 and have their client log, and I suggest that for anyone interested in finding out what's going on. Otherwise, if it's a log or die situation, I suppose I can set something up, but I would really like to keep them in a place where only people with a shell account on quantum can get to them. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Randy McMurchy wrote: > > I'm sitting on the fence here. On one hand, I like the idea of > individual indexes for packages/libraries/programs/etc. because > of the reduced sizes and faster loading times. But on the other > hand I don't want to have to open up multiple indexes to find > what I'm looking for. > Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 64-bit vs 32-bit
Bruce Dubbs wrote: > > Thanks Bryan. That is a very interesting result. It's only one data > point, but it tends to confirm other reports that I have seen that 64 > bit processing isn't significantly faster for most tasks. > > If you are running a server with > 4G Ram and very large data sets (i.e. > a large database) the additional memory address size would be a definite > advantage. Also if you are doing very compute intensive tasks such as > solving systems of differential equations (e.g. computational fluid > dynamics), 64-bit processing can make a difference. > > Until I see a need, I'm going to stick with 32-bit computing. YMMV > > > If you have a generic peice of code targeted to run on all x86 cpus (32bit and 64bit) regardless of the amount of registers / banks the processor has it's going to take just as long to get the job done, within a reasonable difference in time. But where you see a difference is when that piece of code is tailored to that processor. You can definitely also see a difference in math processing. I'll have to run some benchmarks. Probably be some time before I don't have my hands tied behind my back though. Personal Opinion: My AMD Athlon X2 4400+ (2.4ghz) seems to be just slightly faster then my P4 3ghz (Prescott). It takes probably almost 20-30 more minutes to build clfs-sysroot (through xorg) on my P4. Bear in mind that the LFS build on the P4 is substantially older then the CLFS build on my AMD. > > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Spam in trac tickets
Matthew Burgess wrote: > On Saturday 07 April 2007 18:03, Bruce Dubbs wrote: > >> I deleted spam from lfs-book and blfs-book, both mail and trac tickets, >> this morning. Do we need to make the books ticket system so only >> authorized (vice registered) users can create or modify tickets? >> > > Bruce, > > The LFS Trac is already configured to only allow authenticated users to > modify > or create tickets. I've not seen any ticket spam in lfs-book, maybe it's > just mail-spam that you had to delete this morning? > > The bots register and leave a comment. I cleaned 3 spam items out of the clfs trac this morning. I was hoping someone might have some helpful insight on libtool when i saw the email, but it was just spam :(. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-linux-ng
Dan Nicholson wrote: > A while back, the Fedora util-linux maintainer decided to fork > util-linux since upstream was basically dead and not accepting patches > back. So, here is util-linux-ng: > > http://userweb.kernel.org/~kzak/util-linux-ng/ > > It's very active, AFAICT. The first 2.13 release candidate was just announced. > > http://news.gmane.org/gmane.linux.utilities.util-linux-ng/ > > I suggest we move to this new package when 2.13 is released. Thoughts? > One thing that Chris brought up on IRC. for /tools, mount & umount now both depend on libblkid (from e2fsprogs) or libvolume_id (from udev). A quick way to just get blkid out of e2fsprogs: ./configure --prefix=/tools && make -C lib/blkid && make -C lib/blkid install. Then util linux is just: ./configure --prefix=/tools && make -C mount mount umount && make -C text-utils more && cp them into /tools. I definitely agree that all the *lfs books should move to this after it's released. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-linux-ng
Matthew Burgess wrote: > > Yeah, I saw this too. It's not the most popular of changes though (see > http://www.mail-archive.com/util-linux-ng%40vger.kernel.org/msg00350.html and > David Miller's reply). So, we might see a package agnostic filesystem > detection library, possibly even before util-linux-2.13 is out. Anyway, I > agree - from the comments and patches I've seen from a brief glance at the > mailing list archives for util-linux-ng, that package has been in need of a > lot of TLC for a long time now so we'd do well to pick up the new releases > > I like the suggestion in this email about creating a general library for detecting filesystem types. something e2fsprogs / udev / util-linux can all use. It'll be interesting to see where this goes. http://www.mail-archive.com/util-linux-ng%40vger.kernel.org/msg00368.html -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Gerard Beekmans wrote: > > A few people have already expressed the fact that platforms like x86_64 > are becoming more and more standard. We simply have to keep up with the > times. Adopting some/all of CLFS' methods into mainstream LFS will > happen sooner or later. > > Back in the day, LFS' chapter 5 made allowances for systems based on a > (very) old Glibc that wasn't compatible with the newer Glibc LFS was > installing. Along that same vein sooner or later we'll have to add > similar workarounds if one wants to end up with a 64 bit build. > > Or it will end up in an LFS Hint. Or we'll defer completely to CLFS. > LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: > On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: > >> LFS could be made to accommodate x86_64 (multilib) with very few changes >> and a bunch of new pages. Where multilib gets tricky is where lfs stops >> and blfs begins. With the introduction of pkg-config and all those fun >> *-config programs and hard coded library paths. >> > > And non-multilib is even fewer changes, and would be much easier for > BLFS to accomodate. I suppose the only concern is compliance with > standards and/or user expectations. I'm working on getting a LFS-style > native build done on x86_64 with as few changes as possible. I'll let > you know how it goes. > There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. You can have /lib64/ld-linux-x86_64.so.2 (symlink to /lib), /lib/ld-linux.so.2 (32bit), and /lib/ld-linux-x86_64.so.2 (64bit). Your 64bit libs in /lib. and your 32bit libs in /lib32 or some weird place lib /opt/emul_32/lib. A hint about using /opt/emul_32/lib for the specific purpose of running wine could definitely be written up. That would be useful for clfs too. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Dan Nicholson wrote: > On 7/20/07, Ken Moffat <[EMAIL PROTECTED]> wrote: > >> On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: >> >>> Here's the rendered book: >>> http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 >>> >>> >> You have correctly dropped grub from the list of packages (nobody >> has managed to build it successfully on a pure64 system), but it's >> still referenced in Chapter 8 - "Making the LFS System Bootable". >> > > The 1.9.x versions, too? > I'll have to check on the more recent versions. I know that 1.9.2 (the last time I tried) still needed a 32bit glibc. I don't have a pure64 build around but I think the new one (1.9.5) may work. grub2 is a completely different beast then grub legacy. Still no documentation. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Ken Moffat wrote: > > "all those nice 64 binary packages" - I suppose that means nvidia > or ati kernel modules ? I don't know of anything else that comes as > 64-bit without source. > > I know a few people use Opera too. I personally use a binary JDK if I need java. If someone wanted to use a binary firefox / seamonkey / thunderbird they'd fall in that group. It is definitaly a small group of people that would need that functionality, but it still exists. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Ken Moffat wrote: > >> >> > I'll give you java, so I have to accept there are binary 64-bit > applications. But I can't find any 64-bit binaries for firefox or > opera. > > > I could have sworn they existed but I just checked and couldn't find them either. So strike two more off the list. That still leaves java. Which is a major one. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bryan Kadzban wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Luca wrote: > >> Grub-0.9x is old Grub legacy and no-more maintained. >> > > According to their site, it is maintained, just no new features are > being added. (Though I'm not sure what sense of the word "maintained" > they're using then... but whatever. Presumably it just means they'd > still fix bugs if there are any.) > > >> Grub-1.x is new one [...] I tried it only x86 but there was a similar >> discussion in Debian for x86-64 arch support. >> > > Here's where I'm a bit confused. Why should grub need to switch the > processor into long mode? For one, the kernel already does that -- > IIRC, Linux expects to start in real mode. (I'm not sure if there are > any provisions to start in protected mode, for grub2, or not. I'm > pretty sure grub2 switches into protected mode, so if that's true and it > works, then there probably is some protocol to make it work.) > > Grub legacy sets up protected mode. Yes, the linux kernel can startup in protected mode, but any kernel that grub loads needs to setup protected mode. If the kernel doesn't setup protected modem you have the possibility of a triple fault (reboot). Grub sets up a GDT. If the kernel being loaded by grub overwrites the GDT created by grub before setting up one of it's own you'll get a triple fault. I learned that the hard way. > But for two, isn't 4G of virtual address space way more than enough for > grub to do whatever it needs to do? I mean, all it has to do is load up > a file or two off the host FS and jump to an address inside the memory > image of one of the files. That's not nearly complicated enough to > require more than 4G of memory. > Without setting up protected mode you can't access more then 1mb of physical memory, without pulling your hair out. > In short, I'm not sure the bootloader needs to be 64-bit. > > Now I can see making the grub shell (and other programs on the host) be > 64-bit. Even if that's way overkill IMO too, it would be necessary if > you're trying to do a pure64 system (because you won't have the 32-bit > ld.so). Is that all that's being discussed when people talk about > "x86-64 arch support"? > > The bootloader doesn't need to be 64bit, actually, 32bit would be ideal. The problem with grub legacy is that stage2 gets linked into the grub shell. stage2 can be compiled as a 32bit binary. But the grub shell would need to be 64bit, specifically because it requires a 64bit libc and optionally a 64bit libncurses (Can use a text interface). Grub legacy's design makes it virtually impossible to use on 64bit. > (Not that a pure64 system is all that useful if you need -- or want -- > to use Flash, but that's a different issue.) > > In any case, I had planned on doing some grub2 testing today, so > hopefully I'll be able to get it to work. I really do need to make and > test a bootable floppy first, though. :-) Grub2 should be able to work. I just compiled 1.95 with 64bit binaries and 32bit modules. Now all I would like to do is compile a pure64 system and try this. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Gnome-2.18: Ejecting CD/DVD ROMs
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 07/25/07 19:21 CST: > > >> Where is the `eject' program located? It is not in BLFS; at least it is >> not in the index. >> > > It is not in BLFS. It is referenced a couple of times in the book as > an optional component. It is truly CMMI. If I recall, it installs two > little programs in /usr/bin (eject is one) and respective man pages > and nothing else. > > That's the one, it's an optional runtime dep of gnome virtual file system. You can find it at, http://ca.geocities.com/[EMAIL PROTECTED]/eject.html . -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: should be back online now
IRC is still out. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: should be back online now
Dan Nicholson wrote: > On 9/23/07, Joe Ciccone <[EMAIL PROTECTED]> wrote: > >> IRC is still out. >> > > How about now? > It's back now. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Server is back online
There's gotta be something wrong with the ircd init script. It's still down -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Server is back online
Dan Nicholson wrote: > On 9/30/07, Joe Ciccone <[EMAIL PROTECTED]> wrote: > >> There's gotta be something wrong with the ircd init script. It's still down >> > > It just wasn't setup in rc*.d. Should be fixed now. > Thanks. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: sparc64 built from jh branch
Dan Nicholson wrote: > On 10/12/07, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > >> On Fri, Oct 12, 2007 at 06:30:11AM -0700, Dan Nicholson wrote: >> >>> What does that have to do with sparc64? You're the only person I know >>> that has one, so that means development and support is 100% you. And >>> the chances I get one are about the same as Richard moving back to >>> Texas :) >>> >> Ebay, $250. If you watch, you can find even better deals than that >> sometimes. >> > > Let me put that another way: the chances that I get any interest in > having one are slim :) But it's nice to know than one can be had > cheaply. > Lets not forget how long the builds take though. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #2094: Add a new section for build results
Jeremy Huntwork wrote: > Jim Gifford wrote: > >> and now your trying to get it in the mainline. To quote yourself your >> not a "hardcore developer", but your trying to influence the direction >> of LFS to meet your needs. >> > > Oh, lol. You're taking Justin's words and applying them to me. Nice! :) > > I'm definitely not worthy of any special recognition, but I will say > that after the many issues encountered with getting the jh branch fully > working, I understand far more about the toolchain than I ever did before. > > Here's another tip for you, (Greg helped me with this as he did with > several other things) if you're building 64-bit only the use of -m64 is > superfluous. > Right you are, The only reason it's left in the CLFS book is because mips defaults to n32, not 64. Plain and simple, Less XML. Plus it doesn't harm anything. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Thomas Pegg wrote: > Bruce Dubbs wrote: > >> Julio Meca Hansen wrote: >> > > >> I've lost the background on this. Looking at util-linux, why do we need >> it at all in Chapter 5? Can't we just build it once in Chapter 6 just >> before the first file that needs it? >> >> > From what I remember it was so we could mount /dev/pts and /dev/shm > inside of the chroot, but that's unnecessary now with the bind mount of > the host's /dev. There could be more that relies on mount, not sure what > though. > > For one thing you posted this message 3 times. mount --bind will not carry sub mounts. That's where mount --rbind comes in. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Julio Meca Hansen wrote: > As the wiki states, either e2fsprogs or udev needs to be installed in > chapter 5 if we're going to include the util-linux-ng package. > > After analysing the matter a bit, I've been testing with the > installation of e2fsprogs in chapter 5, this set of commands: > > mkdir -v build > cd build > > ../configure --prefix=/tools --enable-elf-shlibs --disable-evms > make libs > make install-libs > > will accomplish the tasks, it gives me no errors during compilation and > in chapter 6, I can install util-linux-ng without problems, not anyone > as far as I've been able to observe. > > hereby I would like to recommend its inclusion in chapter 5, so we can > get rid of ticket #2077. > > On a side-note. All you need is libuuid from e2fsprogs or libvolume_id from udev. libuuid is a bit easier to squeeze out all by itself. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Julio Meca Hansen wrote: > I saw in CLFS e2fsprogs is included so basically I kind-of copied the > installation instructions, but I suppose even if we don't need more than > liduuid, it won't do any harm to install the other associated libraries > Nope, not at all, just stating that libuuid or libvolume_id is all that's needed. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS Pastebin
What happened to pastebin.linuxfromscratch.org? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Chap. 5.6 - glibc-2.7 compilation error
Dan Nicholson wrote: > On Jan 16, 2008 3:16 PM, Ken Moffat <[EMAIL PROTECTED]> wrote: > >> On Wed, Jan 16, 2008 at 01:51:23PM -0600, Bruce Dubbs wrote: >> >>> Circul wrote: >>> >>> Try to compile glibc-2.6.1 - no errors, all compiled fine. What's wrong ? >>> Wrong list. Try lfs-support. >>> >>> -- Bruce >>> >>> >> I think he did, yesterday, but nobody has replied. Probably >> because nobody else is trying to build the development book on >> i586 at the moment. >> >> There was a similar problem on clfs, and there is an open ticket >> there, but I don't know the answer. >> > > On lfs-support, one guy said these patches from glibc CVS fixed the issue: > > http://linuxfromscratch.org/pipermail/lfs-support/2008-January/033985.html > http://sourceware.org/ml/libc-alpha/2007-10/msg3.html > http://sourceware.org/ml/glibc-cvs/2007-q4/msg00428.html > I made this patch from the link the guy left in the clfs ticket, Fixed it last night in clfs. http://svn.cross-lfs.org/svn/repos/patches/glibc/glibc-2.7-i586_chk-1.patch -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
dLFS PHP Code
I'm just curious what the code looks like. It looks a LOT like a parser I wrote working on a project with Jeremy almost a year ago. Link below. Obviously the concept is the same. If it is the same base code, all I ask is for attribution of the original idea, No more. http://cross-lfs.org/~jciccone/parser_test.php -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: dLFS PHP Code
Jeremy Huntwork wrote: > Joe Ciccone wrote: > >> I'm just curious what the code looks like. It looks a LOT like a parser >> I wrote working on a project with Jeremy almost a year ago. Link below. >> Obviously the concept is the same. If it is the same base code, all I >> ask is for attribution of the original idea, No more. >> >> http://cross-lfs.org/~jciccone/parser_test.php >> > > Hi Joe, > > Here's the current parser source: > > http://lightcubesolutions.com/~jhuntwork/dLFS/preview.phps > > I think you'll see it's quite a bit different from what you wrote. You > approached the problem differently, had a lot more functionality and > covered more cases. You actually analyzed the syntax on the page, which > was very impressive. :) I haven't done any syntax analyzing here other > than validating the XML with a built-in function. > Definitely nothing like my code. Though the concept is similar, How much different can it get. Clearly not based on the same code. > I don't believe I used any of your code, but regardless, I'd be happy to > add your name into the code as a source of inspiration, if you like. You > did excellent work in the other project, and I am very grateful for it. > No, I don't think so either, I just wanted to make sure. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
Jeremy Huntwork wrote: I've heard no recent talk of cutting a testing branch from trunk in preparation of a release, and in the meantime, I think we owe it to our readers to supply a stable LFS with all these known items fixed. I have personaly stopped building stable because stable isn't stable. I do not know if the world is ready for a stable release with gcc-4.0.2 but, a few upgrades are required. Joe Ciccone [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
Matthew Burgess wrote: > 1) Apply security patches to texinfo, util-linux, bzip2 and vim. > 2) Upgrade perl and zlib to fix their respective security vulnerabilities > 3) Patch glibc to fix the issue triggered by openSSH > 4) Do something with the udev configuration vs. /etc/group conflict > reported in bug 1639. 5) Upgrade binutils to 2.16.1 if possible to incorperate gcc4 hosts. An alternative would be to put a note in the book saying that if your host uses gcc4 please install gcc pass1 then binutils pass1 then gcc pass1. Joe Ciccone [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report
Jeremy Huntwork wrote: >Hi Guys, > >I just wanted to report on the status of the alphabetical branch as it >currently stands. For all intents and purposes, I believe it produces a >stable environment. I have built many, many packages on top of it and >it's working wonderfully. I have built my usual base BLFS packages, ie, >wget, subversion, Xorg, libxml2, libxslt, firefox, thunderbird. I've >also built e17 and all of GNOME (I built most of GNOME's optional >dependencies, too, including OpenLDAP). Not one complaint from any >package. I was considering starting on KDE now as well. > >I know some have expressed concerns about changing the package order and >they have suggested doing binary comparisons. I have yet to find out >exactly *how* to do that, so I'd be happy if someone could hit me with a >cluebat. > >Also, Gerard had previously mentioned moving vim up to earlier in the >build (for the sake of convenience.) While I agree it would be >convenient, that doesn't fall into the motivation for the package >re-order, namely alphabetical except for necessary dependencies. We get >by just fine through the course of the LFS build by using cat and sed. >If manual editing is needed at any point, it's possible to switch >terminals on your host and edit a file, or drop in Vim when you want. I >don't agree that it should move to the top of the build for general LFS >instructions. > >Any further thoughts or comments? How does the community feel about >getting these changes into trunk? > >-- >JH > > For binary comparisions you can use cmp, the man page has a lot of information and more info can be found at info cmp. Personaly, I think vim should be left twords the end, as you said if manual editing is needed they can switch vt/s or even leave the chroot and come back. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
Randy McMurchy wrote: >Jeremy Huntwork wrote these words on 12/11/05 19:43 CST: > > > >>The real thrust behind this research is to have a rationale for each >>package -- *why* it's built *when* it's built. IMO, that's 10 times >>better than just saying 'eh, the build order is a huge mess, we don't >>know why this package is before this other one, but it works so let's >>just leave it.' >> >> > >But, as far as I know, nobody except you thinks that. Right now, >I think the build order is because it was developed through years >of experience, trial and error and testing. And you are suggesting >to throw all that out the window and try a new build order, because >your (one person mind you) month or two of casually using a new build >order produces, what *you* say is a reliable build order. > >But, what about the thousands of builds before this that have proven >that the existing build works, and doesn't really need to be modified? > >Doesn't that history and years of experience amount to something >that should be dealt with before changing? > > > He isnt alone, I'm curious why the build order is the way it is now, and i'm curious if changing it around a bit can fix it and make a more stable system. Is that not worth investigating? I think it is. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
Bruce Dubbs wrote: >In BLFS, we do spend a lot of time determining dependencies, but we also >make the assumption that the LFS packages are installed. The LFS >dependencies are not listed for each package. > > > If the packages were to be listed, and have all the deps mapped out in a tree, you would beable to create a perfect build order the first time around. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: texindex causes segmentation faults
Bruce Dubbs wrote:
>Randy McMurchy wrote:
>
>
>>Hi all,
>>
>>I'm seeing a reproduceable issue with the current texinfo/teTeX
>>combination of LFS/BLFS packages. I don't know where to begin to
>>look so I'll describe symptoms and see if this rings a bell to
>>anyone.
>>
>>I see segmentation faults when using the texi2dvi and texi2pdf
>>programs. I'm using current LFS SVN (SVN-20051130) with teTeX-3.0.
>>
>>For a similar error I'm seeing, check out the error message at
>>the bottom of this page:
>>http://lists.gnu.org/archive/html/bug-automake/2005-10/msg4.html
>>
>>The seg-faults using texindex are reproduceable and consistently
>>happen when using texi2dvi to format .texi files.
>>
>>It is the texindex program which is ultimately seg-faulting.
>>
>>After building LFS using LFS SVN-20050831, I do not see these
>>segfaults. So, perhaps it is something with the most recent
>>Glibc/GCC combination of current SVN. The texinfo and teTeX package
>>versions are the same.
>>
>>Anyone with any knowledge about this, or if you can confirm this
>>seg-faulting behavior, please respond to this message.
>>
>>
>
>Randy,
>
> I traced this down a bit. The texindex program is created in the
>texinfo package in LFS. After analyzing the source :), I narrowed it
>down to:
>
>/* x.c */
>char *tempbase;
>int main (int argc, char **argv)
>{
> tempbase = mktemp ("txidxXX");
> return 0;
>}
>
>gcc -o x x.c
>./x
>Segmentation fault
>
>Changing to mkstemp also creates a segfault.
>
>glibc declares mktemp as:
>char *
>mktemp (template)
> char *template;
>{
> if (__gen_tempname (template, __GT_NOCREATE) < 0)
>/* We return the null string if we can't find a unique file name. */
>template[0] = '\0';
>
> return template;
>}
>
>The definition of __gen_tempname is in glibc sysdeps/posix/tempname.c.
>
>There is no change in this function from gcc-2.3.4.
>
>I suspect this is something to do with gcc4. Perhaps we need to elevate
>this to the gcc devs with a bug.
>
>In the meantime, I'll try to see if I can extrace the source from
>tempname.c and see if I can get it to segfault.
>
> -- Bruce
>
>
char *tempbase;
int main (int argc, char **argv)
{
char wtmp[] = "txidxXX";
tempbase = mktemp (wtmp);
return 0;
}
the program above doesnt segfault.
information was from:
http://lists.debian.org/debian-user/1999/10/msg02102.html
"Using the brackets ("[]") here forces the allocation of an array big
enough to hold the initializer value ("/tmp/tmpfileXX" with trailing
NUL character). With the "char *" you're only allocating a pointer and
telling it to point to a string constant (which is in read-only memory)."
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: coreutils (tail, head)
Bruce Dubbs wrote: >I thought this POSIX behavior was reverted in the current coreutils, but >apparently not. Do we need to add a patch? > > from the info coreutils tail page: Some older `tail' implementations also support an obsolete option `+COUNT' with the same meaning as `-+COUNT'. POSIX 1003.1-2001 (*note Standards conformance::) does not allow these options; use `-c COUNT' or `-n COUNT' instead. When I read that it tells me that this functionality used to be supported but isnt supported anymore because the new standards "do not allow these options". It seems that the sed randy posted will be needed. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merry Christmas
Randy McMurchy wrote: > (I'll leave it as an exercise for the readers to figure why we > >weren't supposed to drink.) > The Y2K hoax! and Merry Christmas to everyone. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: Implementing Trac [long]
Jeremy Huntwork wrote: >2) Keep our existing website, but use Trac for a development wiki and to >replace Bugzilla and ViewCVS. The wiki pages would only include >development works in progress, not the main website pages, similar to >how our previous wiki was set up. > >3) Keep everything as is, including ViewCVS and Bugzilla, and look for >an alternative wiki solution. > > I would definitaly not jump to 1 yet because its new and it's unknown how the community will react to it. I would keep everything entact as it is for now and try to use trac and see how it works before anything is deleted, removed, or moved. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: Implementing Trac [long]
Bruce Dubbs wrote: >1. Replace Bugzilla >2. Replace ViewCVS >3. Be a target for multilib/i18n issues. > >I do not think is should replace the general website. I'd prefer to >keep those pages static and archived in svn. > > I would opt to keep everything entact until everyone has agreed that it is a nice system, then as long as a bugzilla and some kind of viewcvs exists, It doesn't bother me. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RFC: Implementing Trac [long]
Jeremy Huntwork wrote: >Offer suggestions, please, on what you think would be a fair trial. I'm >sorry that my excitement about it carries me along sometimes. :) > > > Give it a run for its money, let the people that are going to use it, use it, and see how it works under a load with people using it, just a suggestion. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8
After doing some research on my own. I personaly would like to build without UTF-8 support because of the following problems that have been mentioned. 1. Man isn't UTF-8 ready yet, but support is planned. Man-DB seems like overkill for this application. 2. Groff isn't UTF-8 ready yet, but support is in the working. 3. A cd burned using a UTF-8 locale will only be readable in UTF-8 systems. 4. Various incompatibilities with the packages in BLFS that were mentioned in this thread and probably more that no-one has looked into yet. The most interesting thing from a programmers point of view is the way the characters are handled. This is the reason why incompatibilites exist. A non-UTF-8 character, char, is 4 bits whereas a UTF-8 character, wchar, is 32bits. It's hard to write code to properly support both types of locales. Also, wchar processing code is slightly slower then char processing code. Most programmers try to avoid it, including myself. One thing that makes me lean towords UTF-8 support is the fact that some locales only work with UTF-8. Right now, that is not enough to swing me. But, That does not mean that UTF-8 shouldn't be looked into for the future when UTF-8 becomes the standard, and no doubt it will eventualy because of languages like russian. Those people shouldn't be deprived of support for their languages, but at the same time its hard not to break what is already working. It might not be a bad idea to wait until upstream(groff, man, everything) supports UTF-8 better. I wish I had know all of this earlier because I could have presented it before the UTF-8 book merged. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8
Bruce Dubbs wrote: >Well ASCII is technically 7 bits, but most systems recognize Latin1 >which is 8 bits. > > I don't know why I said 4 bits, You are right. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Santized Kernel Headers
Jörg W Mittag wrote: > > - many major distributions include their own copies of sanitized > headers. > > > Many distros use patched 2.4 headers, Fedora is one example, but probably a bad one because they break all the rules anyway. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ImplementingTrac - Logo
I can tell you that the problem is in main.css in the #logo section, but, I have no clue how to fix it, I know that when I changed position: relative; to position: static; it showed up properly, but then the positioning was off. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
