Possible defect in instructions in ch6 e2fsprogs-1.41.7
The ../configure line in the SVN-20090706 book for e2fsprogs seems to not work correctly. With the new --disable-libblkid and --disable-libuuid, I get the following error: configure: error: external uuid library not found Which does and doesn't make sense to me. If I remove the offending --disable command and leave the one for libblkid, I get a similar error for it too. When I remove both of those extra commands, configure runs great and I can complete a make, make check, etc and install just fine from what I can tell. I noticed that this page just got updated in the changelog. James Robertson -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Possible defect in instructions in ch6 e2fsprogs-1.41.7
Bruce Dubbs wrote: > James Robertson wrote: > >> The ../configure line in the SVN-20090706 book for e2fsprogs seems to >> not work correctly. With the new --disable-libblkid and >> --disable-libuuid, I get the following error: >> >> configure: error: external uuid library not found >> >> Which does and doesn't make sense to me. If I remove the offending >> --disable command and leave the one for libblkid, I get a similar error >> for it too. >> >> When I remove both of those extra commands, configure runs great and I >> can complete a make, make check, etc and install just fine from what I >> can tell. >> > > Well we removed e2fsprogs in Chapter 5, so you must mean Chapter 6. In > Chapter > 6, we moved util-linux-ng-2.16-rc2 to immediately before e2fsprogs and > libuuid > and libblkid should be pickjed up from there. > > Worked for me when I tested it. > >-- Bruce > I am talking about ch6. Sorry about that. I wonder if Jim's util-linux-ng patch may be the issue for me. I deviated from the instructions and used it when compiling the rc2 based on his thread earlier (and of course, promptly forgot I did and did not mention it here either :) I will see about that and get back to the list. James Robertson -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-Linux _NG 2.16-rc2
Bruce Dubbs wrote: > +Jan wrote: >> Hey lfs-dev, >> >> I just ran through the development chapter 5 without any problems. >> Just on the subject of util-linux-ng, there's this small section in >> chapter 5 near the bottom: >> >> >> Install the shared libraries required by E2fsprogs: >> >> make -C shlibs/uuid install >> make -C shlibs/blkid install >> >> >> Since e2fsprogs is no longer installed in chapter 5, and util-linux-ng >> is built right before e2fsprogs in chapter 6, I think it's safe to >> remove this. > > Now that you point this out, I'm not sure any of the programs in > util-linux-ng > are needed in Chapter 6 before we get to the final installation of > util-linux-ng. > > The programs are mount, umount, more, and mkswap. The only thing I can think > of > that needs more is if the user is looking at man pages, but we don't install > man-db until after util-linux-ng. The other three are not needed by us > within > the chroot environment, but may be needed in one or more of the test programs. > > So now the question arises: Do we need util-linux-ng in Chapter 5? > >-- Bruce I think 'more' is an important program to keep for building ch6 in chroot. If you are sending output to log files and such, it makes doing at cat [filename] a must. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-Linux _NG 2.16-rc2
Bruce Dubbs wrote: > James Robertson wrote: > > >> I think 'more' is an important program to keep for building ch6 in >> chroot. If you are sending output to log files and such, it makes doing >> at cat [filename] a must. >> > > The user can either open another window or change to another virtual > termional, > cd to /mnt/lfs/wherever, and use the host's more or less. > > Pun intended. > >-- Bruce > That is certainly very true. Would we want to put some notes in the book about that kind of thing? For example maybe you need VIM or something too. Probably near the front where we talk about the essential pre-reading hint and such. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.4.1 imminent
Matthew Burgess wrote: > Hi, > > As mentioned at http://gcc.gnu.org/ml/gcc/2009-07/msg00411.html, > GCC-4.4.1 will be announced shortly. > > As such, do we want to squeeze this in to LFS-6.5? > > Regards, > > Matt. > I vote for inclusion. The more stable LFS as a foundation is the better IMHO. Even if we just boiled "stability" down to the tool chain and the kernel I would then still vote for a .1 inclusion to a stable book version. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Suggestion for the /etc/resolv.conf file
I would like to suggest a small addition to the book's base /etc/resolv.conf file. In some (many) cases, LFSers may find that their machines need to be on a network with multiple domains and they want to search them locally. If we add "search " to the cat command script and then a little bit of explanatory text we can help readers with that feature. Thanks James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5: 5.31. Stripping - extra 10MB of docs could go
Kevin Buckley wrote:
> LFS 6.5
> 5.31. Stripping
>
> At this point LFS says
>
> To save nearly 20 MB more, remove the documentation:
>
> rm -rf /tools/{info,man}
>
> however on my build, there seem to be close to another 10MB below these two
> directories that could also go ?
>
> 8.7M/tools/share/info
> 1.1M/tools/share/man
>
> $ ls /tools/share/info/
> bash.infogrep.info libc.info-11 libc.info-8 tar.info-1
> coreutils.info gzip.info libc.info-2 libc.info-9 tar.info-2
> dir info-stnd.info libc.info-3 m4.info texinfo
> find-maint.info info.info libc.info-4 m4.info-1texinfo-1
> find.infolibc.info libc.info-5 m4.info-2texinfo-2
> gawk.infolibc.info-1 libc.info-6 sed.info texinfo-3
> gawkinet.infolibc.info-10libc.info-7 tar.info
>
> $ ls /tools/share/man/man?
> /tools/share/man/man1:
> base64.1 echo.1 info.1 od.1 shred.1 tty.1
> basename.1 egrep.1 infokey.1 paste.1shuf.1 uname.1
> bash.1 env.1 install-info.1 pathchk.1 sleep.1 unexpand.1
> bashbug.1expand.1install.1 pdftexi2dvi.1 sort.1 uniq.1
> cat.1expr.1 join.1 pgawk.1split.1 unlink.1
> chcon.1 factor.1kill.1 pinky.1stat.1 updatedb.1
> chgrp.1 false.1 link.1 pr.1 stty.1 uptime.1
> chmod.1 fgrep.1 ln.1printenv.1 sum.1 users.1
> chown.1 find.1 locate.1printf.1 sync.1 vdir.1
> chroot.1 fmt.1 logname.1 ptx.1 tac.1 wc.1
> cksum.1 fold.1 ls.1pwd.1 tail.1 who.1
> comm.1 gawk.1 m4.1readlink.1 tee.1 whoami.1
> cp.1 grep.1 makeinfo.1 rm.1 test.1 xargs.1
> csplit.1 groups.1md5sum.1rmdir.1texi2dvi.1 yes.1
> cut.1gunzip.1mkdir.1 runcon.1 texi2pdf.1 zcat.1
> date.1 gzexe.1 mkfifo.1sed.1 texindex.1 zcmp.1
> dd.1 gzip.1 mknod.1 seq.1 timeout.1 zdiff.1
> df.1 head.1 mktemp.1sha1sum.1 touch.1 zforce.1
> dir.1hostid.1mv.1sha224sum.1tr.1zgrep.1
> dircolors.1 hostname.1 nice.1 sha256sum.1true.1 zless.1
> dirname.1id.1nl.1sha384sum.1truncate.1 zmore.1
> du.1 igawk.1 nohup.1 sha512sum.1tsort.1 znew.1
>
> /tools/share/man/man5:
> info.5 locatedb.5 texinfo.5
>
> Not sure why my stuff ended up there, and not directly below
> /tools/{info,man},
> I have followed the instructions up to now. I also find I only have 14.5 MB
> in the areas LFS suggests there'll be nearly 20MB in ?
>
> $ du -sh /tools/{info,man}
> 7.4M/tools/info
> 7.1M/tools/man
>
> Kevin
>
This is a old / long standing point that folks bring up now and again.
Since /tools is very temporary, the book has not historically worried
about the documentation that gets installed by the temp tools. In 6.5
we added the comments about this section being optional and also to
remove the info and man pages. I am running some iterative builds and
also have /tools/share/{info,man}
james [ /mnt/build_dir/tools ]$ du -sh ./share/{info,man}
8.7M./share/info
1.1M./share/man
I don't have the /tools/{info,man} directories any more on my test
machine, but you can see that I have more space used in
/tools/share/info that you do, so to statement about 20MB is relative I
think. In the end, it does not really matter. /tools is temporary and
most computers today have plenty of space. We could add another command
to get rid of the /tools/share/{info,man} for completeness, however.
James
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-6.5: 5.31. Stripping - extra 10MB of docs could go
Kevin Buckley wrote:
>> This is a old / long standing point that folks bring up now and again.
>> Since /tools is very temporary, the book has not historically worried
>> about the documentation that gets installed by the temp tools.
>>
>
> Indeed!
>
> The last time I built an LFS system from scratch (bit tautological
> that!), I'd found that there was extra stuff in, eg, /tools/share/doc.
>
> My old notes, where I highlighted the differences between a vanilla LFS
> install and the "My Distro, My Rules" one in an HTML copy I kept lying
> around, led me to go looking to see what was where when doing the
> latest build, whereupon I "discovered" the /tools/share/{info,man} stuff.
>
> Thought I might as well feed such info back into the community.
>
> Maybe a note in the book to the effect that
>
> "There may be other, uneeded, documentation that the example instructions
> here don't remove. Typically, Linux documentation tends to be installed below
> directories called 'info' and 'man'".
>
> would cover all the bases.
>
Agree, that would probably be a good idea. For what it is worth, this
is what I get on my test machine:
root [ /mnt/build_dir ]# du -sh tools/{,share}/{info,man}
7.4M /tools/info
7.5M /tools/man
8.7M /tools/share/info
1.1M /tools/share/man
24.7M total.
Would someone be willing to change the command on
http://www.linuxfromscratch.org/lfs/view/development/chapter05/stripping.html
to
rm -rvf /tools/{,share}/{info,man}
That will cover the two spots that doco may be placed in /tools. The verbiage
on the page covers the rest.
James
James
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-6.5: 5.31. Stripping - extra 10MB of docs could go
Bruce Dubbs wrote: > Done at revision 9063. >-- Bruce > Thanks Bruce! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Library requirements for Linux Standards Base
Bruce Dubbs wrote: > Bruce Dubbs wrote: > >> I've been investigating the Linux Standards Base core specification. >> >> 3. For the full spec, we also need libpam. Does this LSB core requirement >> justify promoting PAM from BLFS to LFS? >> > > Upon further review, the answer to this should be no. I've looked at the > Commands and Utilities required for the Base Core Specification > > http://dev.linux-foundation.org/betaspecs/booksets/LSB-Core-generic/LSB-Core-generic/toccommand.html > > and it includes several programs that we purposely do not include in LFS. > These > include, sendmail, lpr, cpio, crontab, at, install_initd, and remove_initd. > There is also an implied requirement for either rpm or dpkg. > > Clearly, the responsibility for making an LFS installation LSB compliant lies > in > the area of BLFS. I do think a page in LFS with an introduction to LSB would > be > appropriate, but the details of getting even base specification compliance > exceed what we do in LFS. > >-- Bruce > That makes a lot of sense Bruce. I agree with you that going full LSB is beyond what the base book is after based on this information. Would you suggest a specific section in the BLFS book about LSB and then steps to bring a machine into line? I am not a fan of requiring rpm or dpkg; seems the distros are pushing their weight around on that one. Then again, we can provide the steps to install them and if you happen to need to install something from rpm or deb then you have the tools to do so. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Library requirements for Linux Standards Base
Bruce Dubbs wrote: > I've been investigating the Linux Standards Base core specification. > > http://dev.linux-foundation.org/betaspecs/booksets/LSB-Core-IA32/LSB-Core-IA32.html#REQUIREMENTS > > 3. For the full spec, we also need libpam. Does this LSB core requirement > justify promoting PAM from BLFS to LFS? > > Comments? > >-- Bruce > For what its worth, I have thought a long time that having to recompile cracklib into shadow after LFS was a pita (or asking folks to deviate from the book). If we want to go full LSB compliant (which, like the FHS is a good thing) then maybe we pull cracklib and PAM over into LFS. This would certainly save recompile time and we could use the opportunity to help the community learn about PAM. We would also provide a well defined and secured logon authentication system in base LFS that follows the industry best practices right out of the box. We certainly would not go for the extra doco that the PAM package tarball has in it, we can save that for BLFS. My $0.02 James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RE： fsck.ext3:devices or resource bu sy while try to open /dev/sdb
This conversation would be better on lfs-support. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Standards Base
Bruce Dubbs wrote:
> I've been looking at LSB and in running a couple of basic checks find that we
> have some missing libraries and programs in LFS/BLFS to get to compliance.
> The
> discussion below is only a start. There may be more needed after I get their
> more comprehensive test suite running.
>
Thanks Bruce for thinking of this. Even though LFS is not a "distro" so
to speak, providing basic support for a distro-like install is always
good and a great educational value to our readers. I certainly think
that we can come up with a way to incorporate LSB concepts into the book
without totally changing the way we do things.
> Although I've installed several programs on top of my base LFS test system,
> the
> program check now gives me:
>
> Couldn't find at
> Couldn't find batch
>
I agree with Bryan K wrt at being installed when cron does just fine.
Why do the distros require the at package to be included in the
standard? This may be a rhetorical question, but I am curious.
> Couldn't find cpio
>
cpio is one of those standard unix utilites. I don't think it is any big
deal to provide it in BLFS. I am also an IBM AIX administrator and AIX
has cpio installed too. It has for years.
> Couldn't find crontab
>
I do the symlink thing in my build scripts for fcron to cron. I have
used cron for so long I did it so I wouldn't have to remember fcrontab
'cause I am lazy. I have never setup the /etc/cron.{hourly, daily,
weekly} directories, so I am not sure how all that might work for full
LSB compliance.
> Couldn't find install_initd
> Couldn't find java
>
Even though Bryan is not a fan of java, I use it a lot for stuff and
since we already have it in BLFS I think we are good here.
> Couldn't find lp
> Couldn't find lpr
>
I can totally see why these are in the LSB and since we provide this as
part of the lprng BLFS package, we are good to go.
> Couldn't find mailx
>
Provided already in BLFS, good to go.
> Couldn't find pax
>
I agree with Bryan on this one. Someone somewhere was on a kick to get
a third archiver. If we add to BLFS, then I think we are good.
> Couldn't find remove_initd
> Couldn't find sendmail
>
I honestly prefer sendmail, but I know lots of people also hate it and
prefer postfix. Doesn't the LSB just want an MTA? Maybe symlink
sendmail if you are a postfix'er?
> Couldn't find time
>
I agree with the group on this. What can't we just use bash's
built-in? Maybe I am missing something here.
> Couldn't find xdg-desktop-icon
> Couldn't find xdg-desktop-menu
> Couldn't find xdg-email
> Couldn't find xdg-icon-resource
> Couldn't find xdg-mime
> Couldn't find xdg-open
> Couldn't find xdg-screensaver
>
I have no commentary on stuff for x. I only use {B}LFS for servers.
> Of course, several of these are in BLFS, but many are not: xdg-utils, pax,
> cpio,
> at, batch, and gnu time jump out as being needed.
>
> Some (install_initd and remove_initd) are not familiar to me at all.
>
As noted by others, this is for the LSB compliant boot scripts. If we
go LSB, this is probably the biggest change to the LFS book I think as
it would require a total update/rewrite of the scripts. I am not afraid
of symlinks either, but managing them for the bootscripts can be a
pain. I actually use this tool (sysv-rc-conf) and instructions on a
base LFS.
# http://sourceforge.net/projects/sysv-rc-conf/
wget -nc -c
http://downloads.sourceforge.net/sysv-rc-conf/sysv-rc-conf-0.98.tar.gz
tar -xf sysv-rc-conf-0.98.tar.gz
cd sysv-rc-conf-0.98
sudo su -
echo "" | cpan YAML
echo "" | cpan Term::ReadKey
echo "" | cpan Curses
echo "" | cpan Curses::UI
echo "" | cpan Test::Pod
ln -sv /etc/rc.d/rcsysinit.d /etc/rc.d/rcS.d
exit
sed -i "s/\/etc\/rc/\/etc\/rc\.d\/rc/" sysv-rc-conf.pl
sed -i "s/\/etc\/init.d/\/etc\/rc.d\/init.d/" sysv-rc-conf.pl
sudo make install
cd ..
rm -rf sysv-rc-conf-0.98/
sudo su -
echo sysv-rc-conf-0.98 >> /etc/installed-software
exit
> We have fcron, but I'm not sure if we need to create a link from fcrontab to
> crontab or if Vixie cron is required.
>
> Should we be installing some of these (e.g. cpio, pax, Gnu time) in LFS?
>
> -
> The library requirements are a bit better. Right now I'm only missing:
>
I am not a good library person, so I have no commentary on this piece.
> <...>
>
> --
>
> What I want to do is to introduce LSB in the Preface of LFS and then continue
> with more discussion in BLFS "After LFS Configuration Issues". In the
> appropriate packages, add a comment that "This package is needed for LSB
> compliance." I some cases there are definite alternatives. For instance the
> sendmail requirement can be met with any of the MTA packages in BLFS.
>
I really like this approach. I think we can greatly enhance the
educational value of the books with this effort.
> --
>
> Comments and discussion are welcome.
>
>-- Bruce
>
Thanks All
James
--
http://linuxfromscratch.org/mail
Re: Linux Standards Base
Bruce Dubbs wrote: > Randy McMurchy wrote: > >> Dan Nicholson wrote: >> >> >>> The major reason for the existence of the LSB is to support ISVs who >>> want to distribute software for linux. They want to have some base to >>> be able to say "here's a package that will work on your system". If >>> you don't want or need to support that, the LSB is not for you. >>> >> Seems LFS is more the opposite, "give us the source and we make the >> package work for our system". And if so, perhaps we don't even need >> to be LSB compliant. >> > > In general, yes. However, I want to explain to users how to make their > system > LSB compliant and also explain why they might (or might not) want to do so. > >-- Bruce > > This is why I am in agreement with the whole idea. Continue to increase the educational value of the books with this endeavor. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: grub2 installation location
Bruce Dubbs wrote: > Matthew Burgess wrote: > >> On Wed, 28 Oct 2009 14:21:24 -0500, Bruce Dubbs >> wrote: >> >> >>> I'm thinking about moving grub back to Chapter 6 and then changing the >>> grub section in Chapter 8 to "Setting up the boot loader" to discuss >>> actually >>> installing grub into /boot and the MBR. >>> >>> My thought is that the importance and complexity of setting up the system >>> to boot warrants its own section. >>> >> I think this approach is sensible, Bruce. Ideally, I like to see all >> packages >> built, installed and configured within chapter 6, and thinking about this >> some >> more, I reckon we could do without chapter 8 completely. >> >> I think moving Grub to chapter 6 (complete with configuration instructions) >> and the kernel too would work just as well as it does now. The /etc/fstab >> page could move to the bootscripts section, as it's obviously of critical >> importance to the boot process. >> > > I don't like the idea of moving the kernel to Chapter 6. To me, that is the > culmination of the book. It should be last and basically have its own > chapter. > > I agree. I like the concept of compiling all programs except kernel in ch6 and then do the "final touches" in ch8 along with the kernel as a wrap up. There is a great deal of content around configuration of a base system that we could expand on if we wanted (I might write a hint to start the process). James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
Steve Prior wrote: > On 3/17/2010 2:14 PM, Jeremy Huntwork wrote: > >> Here's the site: http://dev.lightcube.us/~jhuntwork/LightCube/LFS-NG/ >> >> None of the links do anything, since it's just a mockup. >> >> -- JH >> > > Looks nice, but I don't think I'd put up a website these days that wasn't > using > a content management system (Drupal, Joomla, ...). > > Steve > I really like the new design, but agree with Steve here. I use Plone at work for an intranet and it is awesome and very easy to programatically add/delete/manage content on the site. It integrates with Trac (which our dev's use) and you can theme both to match look and feel. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Thinking forward LFS-7.0
On 3/14/2011 12:44 AM, DJ Lucas wrote: > On 03/14/2011 12:03 AM, Nathan Coulson wrote: >> > Yes, please! Another set of eyes and additional brain power is always > welcome! You should still have commit privs so feel free to help > yourself. The current 'stable' boot scripts are the remnants after we > ripped out the i18n additions. Though they are stable, they still > contain a lot of cruft such as boot_mesg which is largely unneeded. I > wound up doing a complete rewrite of rc and a single conditional > source of the configuration files in lsb-v3. IOW, at the cost of > possibly faster conditional logic, they only get sourced by the script > if running outside of rc in the lsb-v3 directory. I honestly don't > remember what the 'stty sane' issue was caused by, but I have never > been able to reproduce it since and saw no reason to source the files > in every single sub-shell. BTW, Dan's initd-tools has moved. He is > currently hosting them in his home directory on freedesktop.org. > boot_mesg was from me. It has long since been unneeded. I was attempting to provide a way to change how the boot messages were displayed on the screen. It can be pulled out at any time. I think any improvements in the boot scripts, link management and lsb compliance are all good items to v7. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
> > I'd like to discuss the direction of LFS with respect to where upstream > developers appear to be going. > > Currently we use sysvinit and udev as the basis of bringing up LFS. We > do not use an initd/initramfs or systemd. > > http://wiki.debian.org/InitrdReplacementOptions > http://en.wikipedia.org/wiki/Initrd > +1 I'm with Nathan and Jeremy. As a long time LFSer, I would like to see us go towards having our readers create an initramfs (not the older initrd). The educational value is very high here. If we go this route, we should probably update the kernel compilation instructions to help users go more module driven kernels than static. I have been module only with initrd for some time out on my builds. > > http://en.wikipedia.org/wiki/Systemd > http://0pointer.de/blog/projects/why.html > > -1 I don't think we are ready for this. I think that sysvinit is just fine for our needs. Many distros still go that way. I think the systemd devs have some good ideas, but its not for LFS IMO. -- > > There appears appears to be a movement to consolidate /bin and /usr/bin, > /lib and /usr/lib, and /sbin and /usr/sbin. > > https://fedoraproject.org/wiki/Features/UsrMove > +1 I have been doing this since LFS 5 - LOL. I never understood the need. I install to / and symlink the /usr to /. I think Nathan and I started on the same version of LFS 3.3. Keep up the good work guys! -- James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On Mar 1, 2012 2:49 PM, "Ken Moffat" wrote: > > Actually, we used to have a guy who did run production > servers - but he spent a lot of time keeping them up to date, and he > built on one machine and then rolled the binaries out to the others > after testing. LOL. I still do. I am much more efficient than in years past. LFS has provided me a very stable, modern and downright fast platform. FWIW I am currently running some test builds with Jeremy's proposed idea. I am pretty meticulous, so it will be a bit before I am ready to report back. James (yes I am still here!) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Util-Linux configure options
On Mon, Mar 5, 2012 at 5:21 PM, Andrew Benton wrote: > On Mon, 05 Mar 2012 16:00:38 -0600 > Bruce Dubbs wrote: > > > My proposal is to just skip 'arch' completely as I do not believe it is > > not used anywhere in LFS/BLFS. > > It is used in several places in BLFS (eg the pages for Liba52, nss and > nspr), but I'm sure uname -m will work just as well. > > We discussed the whole arch vs uname -m thing here http://linuxfromscratch.org/pipermail/lfs-dev/2012-February/065811.html and I thought the decision was to just go with the one in util linux and let it be. Seems to be we are re-hashing something not worth the effort. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] The jh branch has been merged
This is awesome news Bruce. This is a major accomplishment if you ask me. Good work by all in incorporating a big change to the toolchain build. My thinking is we might want to consider a new major version to the book. James On Wed, Apr 25, 2012 at 2:34 PM, Bruce Dubbs wrote: > I've just merged the jh branch into trunk. I had a little problem with > the svn > merge command so I baically did it manually. > > Please pay close attention to any new builds and give tell us any issues > you see > with instructions, text, or the xml. > > I have also updated the web site version of the book so there is no need > to wait > for the nightly build. > > -- Bruce > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] The jh branch has been merged
On Wed, Apr 25, 2012 at 4:26 PM, Bruce Dubbs wrote: > James Robertson wrote: > > This is awesome news Bruce. > > > > This is a major accomplishment if you ask me. Good work by all in > > incorporating a big change to the toolchain build. My thinking is we > might > > want to consider a new major version to the book. > > The major thanks need to go to JH. > Agreed 100%. Good work Jeremy. > > However I do not think the changes rise to a major version. It is, after > all, > only about 25 lines of instructions that changed. The most important > reason for > going from 6.8 to 7.0 was about the same as Linus rolling to 3.0 -- it was > time. > The complete rework of all the bootscripts and completely reorganizing > Chapter > 7 was a part of that too. > True that the overall change in instructions seems minor and we are still doing a very similar process with ch5. I just think the way we are doing it is a a big deal and worth more than a minor version. Not enough to make a huge stink over it or anything. I'll defer to your judgement, of course. Just a thought. > > -- Bruce > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On Sat, May 19, 2012 at 8:26 AM, Jeremy Huntwork < jhuntw...@lightcubesolutions.com> wrote: > I've been holding back bringing this up on-list for a while because I > intended to do the bulk of the work and then present a working system to > the community for comment and review. I still intend to do that, but > given some recent discussions, I think the time is right to bring this > up and see where it goes. > I have been watching this thread and it seems to have gone a bit dormant so maybe now is a good time to add my thoughts. First off - Jeremy, your contributions to this project continue to amaze me. Keep it up buddy. > > (Sorry for the cross posting, but since it involves both projects, I > wanted to make sure all saw it - if possible, please reply on lfs-dev.) > > Proposal: > > 1. Adjust LFS/BLFS to auto-generate build recipes for individual > packages that a packaging tool can use to create binary packages with > meta information included such as dependency tracking. > > 2. Store 'official' copies of those binary packages in a developer > package repository so that when developing (primarily BLFS) a dev can > automatically pull and install into a build environment the dependencies > he needs to build and create an individual package. > > 3. Create a standard workflow and tools whereby a developer can > accomplish #2 and edit the book accordingly in an efficient, reliable way. > OK so first let's make sure we are clear on goals, roles and responsibilities here. The thread seemed to float around a bit with some concerns about losing the "roll your own" control that the books give us. 1. Adding PM is NOT a replacement for the books. It should also be noted and clear that the purpose of this effort is not to turn (B)LFS into a binary distro. It is and always should be a cookbook so those that want can still roll their own. I really think that this effort should be a book development tool and cookbook for those wanting to learn about package management. I think the current books stay as is and PM is another off-shoot like cLFS. The books should stay independent as they have different goals. I am thinking that we attempt to leverage the (B)LFS book sources in some manner (maybe combine them into a super book) and then add the PM stuff to each page (build steps). If we go this route, we won't confuse goals and won't make the main books too hard to read. Remember we get new users all the time. Also by creating an off-shoot version of each book, we can go hog wild with educational text about package management strategies, procedures, etc and that text stays out of the main books (again because it is not the main book's goal). 2. PM is for book developers for the most part. Support for the binary packages and repository is to aid book developers. Non-book developers that want to use the packages for their own purposes can do so at any time, but the *-dev community does not support them for that purpose. If we keep these things separate, we can add value for those that are interested and reduce confusion and angst for those that are not. I am also thinking that if we leverage an "extension" of the main book sources for the PM branch, then we can leverage jhalfs (after an enhancement) or another parser to pulls the PM commands out of the book for rapid re-use. Questions about the binary repository came up. I too have some questions about that. What is the definition of 'official'? Who/What is 'official'? Who is going to vet submitted binaries? What is the standard we are going to follow? I would assume binaries compiled with commands right out of the books with no extra optimization flags and such, but that should be agreed upon. Yet another good reason for PM to be a separate book. We can have a whole chapter documenting this if we need to. The separate work things also aid #3 above as well. We can document the standard workflow, tool use, etc there. Things like what you need to get started building a book development environment, a reminder of selection criteria used for the PM tool of our choice (just to help us remember why a certain tool was picked as our memory fades), etc. One tool I think we will need is a spec file generator. This goes back to my thought about putting xml tags in the book source that is parsed out. > Rationale: > > (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a > huge undertaking - and it's a difficult beast to maintain. In order to > create a stable reference page in BLFS an editor has to have spent the > time to build all of LFS, tweak it, go through current BLFS, manually > install dependency packages and then carefully document the package he > builds. No two developers are guaranteed to have the same environment, > either, so accuracy and stability becomes an issue. > WRT BLFS book development specifically. Lots of commentary about dependencies - both build and run-time ones. Part of the PM project would be to sta
Re: [lfs-dev] Once more: Package Management
On Thu, May 31, 2012 at 5:40 PM, Jeremy Huntwork < jhuntw...@lightcubesolutions.com> wrote: > On 5/31/12 4:41 PM, James Robertson wrote: > > > 1. Adding PM is NOT a replacement for the books. It should also be > > noted and clear that the purpose of this effort is not to turn (B)LFS > > into a binary distro. It is and always should be a cookbook so those > > that want can still roll their own. I really think that this effort > > should be a book development tool and cookbook for those wanting to > > learn about package management. I think the current books stay as is > > and PM is another off-shoot like cLFS. The books should stay > > independent as they have different goals. I am thinking that we attempt > > to leverage the (B)LFS book sources in some manner (maybe combine them > > into a super book) and then add the PM stuff to each page (build > > steps). If we go this route, we won't confuse goals and won't make the > > main books too hard to read. Remember we get new users all the time. > > Also by creating an off-shoot version of each book, we can go hog wild > > with educational text about package management strategies, procedures, > > etc and that text stays out of the main books (again because it is not > > the main book's goal). > > Hmm, possibly. I'm wary of new projects/books (given their life span) > but I also see the value in what you're saying about keeping the book > unchanged. > I understand. I think the value is greater however than attempting to put what all I can see us wanting to put into this into the main books. > > > Questions about the binary repository came up. I too have some > > questions about that. What is the definition of 'official'? Who/What > > is 'official'? Who is going to vet submitted binaries? What is the > > standard we are going to follow? I would assume binaries compiled with > > commands right out of the books with no extra optimization flags and > > such, but that should be agreed upon. Yet another good reason for PM to > > be a separate book. We can have a whole chapter documenting this if we > > need to. > > Yep, all good questions. I don't know the answer yet. Perhaps the answer > is to do like I suggested in another message and show a proof of concept > first, then we can tackle the hard decisions as the concept gains ground. > Yes, I definitely think a poc is in order. Like many things, "if you build it, they will come" plays out nicely. I honestly think that a combined "super book" that leverages the build page source from each book is the best approach. That way we don't have to re-type (CnP) the main book source steps into the PM cookbook and then can add PM specific items like you suggested we add into the main books there. I am not sure how to do this exactly, but if we can figure it out it would make development of the book easier. We could then take some advantage of a single book and insert optional steps in from BLFS that make sense and also not have the direct break between books as the purpose is really to work with both to aid development. > > > The separate work things also aid #3 above as well. We can document the > > standard workflow, tool use, etc there. Things like what you need to > > get started building a book development environment, a reminder of > > selection criteria used for the PM tool of our choice (just to help us > > remember why a certain tool was picked as our memory fades), etc. One > > tool I think we will need is a spec file generator. This goes back to > > my thought about putting xml tags in the book source that is parsed out. > > Yep, the parser/generator will need to be one of the first things tackled. > > > WRT BLFS book development specifically. Lots of commentary about > > dependencies - both build and run-time ones. Part of the PM project > > would be to standardize how we create packages. My thinking is to > > create a package for the required deps and the come up with a way to > > generate other "versions" of a package with the run time deps built > > in. Keeping PM in a separate book will give us this option to document > > and explain. > > Not sure I'm following this exactly. Do you mind being a little more > specific or provide an example? > Sure. Lets take sudo as an example. What could be considered a simple program has 8 optional dependencies with 4 being "off book". I think we ignore those 4 and worry only for the 4 "in book" optional dependencies. The build instructions in the main BLFS book explicitly use two without configure parameters to get around no pam or an
Re: [lfs-dev] popt in the book?
> (perl is another one I'd love to see removed, but I'm not going to > seriously recommend that one :) ) > > You might start a flame war if you do that - LOL. Lots of folks still rely and use perl a lot. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Andy Benton
On Tue, Jul 31, 2012 at 4:25 PM, Bruce Dubbs wrote: > With great sadness, I have to report the passing of Andy Benton. > > Oh my and so young too. Thank you Andy for all your contributions and service to the projects. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: bootscript logging conundrum
DJ Lucas wrote: Archaic wrote: Does anyone have opinions? I would like to see it stay as it has actually proven useful on both headless and remote systems. The hack that I had proposed off list, after further review and slight modification, is actually a legitimate way of handling the events prior to sysklogd starting. rc mounts it's own tmpfs, used to capture the temporary bootlog file, which is then appended directly to the existing bootlog just before syslogd starts, after which, it can still be used for other bootscript accounting info and umounted when rc finishes it's job. BTW, just to clarify, I had refered to it as a 'hack' myself, not Archaic. That seems like a great idea. This should be put in/kept in IMO. Education is always good IMO for the book. I always see this as a plus. I also wanted interactive boot. I would like to see this as a feature as well. -- DJ Lucas Thanks James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: bootscript logging conundrum
Jeremy Huntwork wrote: James Robertson wrote: Education is always good IMO for the book. I always see this as a plus. I also wanted interactive boot. I would like to see this as a feature as well. James!! Good to see you're still around. I was getting worried. :) LOL, yea I am still here. I am doing my best to at least keep up with the lists. You guys have been doing great, so I have not felt the need to say anything. Work has me slammed right now. Hopefully by summer, it will settle some. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Text wrapping bug in bootscripts (on plain ASCII)
Alexander E. Patrakov wrote: Hello, Text wrapping is broken for multiline messages even on plain ASCII, as you can see on the attached screenshot (the problem with this bootscripts exiting unexpectedly is already fixed, but I am talking about wrong wrapping here, not the bad version of the autosshd bootscript). The line after the word "it" should not be broken. The reason here is that boot_mesg doesn't interpret the "\n" pair of characters as an end of the line (it's just two letters for character counting), but passes that to echo -e. Possible solutions: 1) Disable text wrapping at all. It cannot deal with kernel messages and unexpected program output anyway. 2) Handle "\n" correctly in boot_mesg when constructing lines and counting characters. 3) Never pass "\n" to boot_mesg. My vote goes for (1). Interesting. boot_mesg() handled \n's before just fine when I created it with Nathan. I wonder what has changed. I would really like to see us keep wrapping (2 above). I usually run frame buffer consoles at 1024x768 or larger and hate it when a message comes up formated for a 80x25 console - ugh. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bugzilla Interface Improvements
Matthew Burgess wrote:
Hi guys,
Matt, what you are after is supposed to be in there. Jeremy U I fixed
it years ago. We had to hack the perl code to get it to do that. It
must have gone away from an upgrade or something. You are supposed to
be able to confirm and accept and bug and it is supposed to assign it to
the logged on person. I still need the latest 2.16 code on the server
anyways. I am going to try and get to it this weekend. Life and work
keeps getting in the way.
James
--
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User -- #6981 -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer-- http://{blfs-}bugs.linuxfromscratch.org
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
BugZilla 2.18.1
All,
I have been playing with BZ 2.18.1 in my lab. I want to upgrade our two
instances as soon as possible - probably this evening if possible. The
product now supports a bug "move" function that lets you take bugs from
one bz instance and move it to another. Perfect for our needs of
merging the two together.
If you have comments or general suggestions, please post to the lfs-dev
list.
Thanks
James
--
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User -- #6981 -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer-- http://{blfs-}bugs.linuxfromscratch.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: BugZilla 2.18.1
James Robertson wrote: All, It has also come to my attention that not all are happy with the way bz is set up in our shop. The tool has an extensive template system that we can take advantage of as well to customize certain pieces. Post here if you have a wish list of some kind. Thanks James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BugZilla 2.18.1
James Robertson wrote:
All,
I have been playing with BZ 2.18.1 in my lab. I want to upgrade our two
instances as soon as possible - probably this evening if possible. The
product now supports a bug "move" function that lets you take bugs from
one bz instance and move it to another. Perfect for our needs of
merging the two together.
If you have comments or general suggestions, please post to the lfs-dev
list.
Thanks
James
OK, both instances have been updated to 2.18.1. I had to install three
perl modules to belg - GD::Text::Align, GD::Graph and PatchReader.
--
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User -- #6981 -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer-- http://{blfs-}bugs.linuxfromscratch.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Optional dependencies
Bruce Dubbs wrote: Yes, it is bug 767 opened 2004-05-14. I've been looking at the older bugs and have been thinking about making this one WONTFIX because of the manpower and time issues. Doing the research to figure out what the optional dependencies provide is probably an order of magnitude harder than just figuring out what the build process looks for. Please don't give up on it Bruce. How about on a package by package basis? I don't think all packages need this information or what is already shown in the book is self explanatory or good enough. Some packages already have a note inside parathenses that is helpful. Tag the really hard ones as BZ items individually and the next time an update occurs look into adding that content. Do it slowly over time so it won't hurt as much. Also, ask for help with gathering the data from folks, one at a time. The "helper" can do some digging and then post a response to the BZ and the next chance an editor gets they could put the content in the book. This would be a real nice addition to the book IMHO. I agree that big systems like GNOME and KDE arenot going to be easy, but a lot of the other stuff could be done without a ton of work. But, like I said, do it over time in a trickle sort of way so as not to kill yourself trying to do the entire book all at once. Just my $0.02 James -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [RFC] Add CrackLib to Chapter 6 LFS
Randy McMurchy wrote: Hi all, Hi Randy and All. First, I want to thank all participants to this thread for keeping it civil. I am so glad we could do that. My opinion/vote is -1. I feel that technically speaking, Randy, your idea is fine. It is good to have a more secure system. I also feel, however, that Cracklib does not fit into the LFS model. I have been doing LFS since 3.0. LFS has been about an *absolute* base functioning system which one can take and extend or whatever they want. It has also been about education. LFS has come so far to the better in both of these areas. We have a technically well designed and implemented build system for a base box. No mess, no fuss. And we have increased the educational value of the whole thing a whole lot. While Cracklib is a good library, it does not fit here. What if I don't want a password checker on my box? My answer to this is education and links to BLFS. I know you have already said in other parts of this thread that you don't like this idea and that the instructions would need work. OK, let's do that. We already have places in the book where we say "if you want you can do and go to BLFS here" Why can't we do that with Cracklib? I am not suggesting we do Linux PAM as well. I know many of you do not like it, so I am not even going to get into that. I know we currently have some potentially optional packages in there now, and it could be argued that we should pull them. In my opinion, let them be grandfathered in. They have been in so long it is not even funny. In closing, I say - Good Idea, but not for LFS. Thanks James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bugzilla updates
Randy McMurchy wrote:
Hi all,
Not sure who takes care of Bugzilla but if someone could add a
GCC4 category to the 'Versions' that are used to describe which
book the bug is noted in, it would be good. I added a bug that
is specific to the GGC4 branch, but could find no way to really
identify it as such.
I changed the "Cross-LFS" version to "Branch_Cross-LFS" and added a
"Branch_GCC4" version. I did so everyone could tell what Cross-LFS and
GCC4 were for.
James
--
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User -- #6981 -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer-- http://{blfs-}bugs.linuxfromscratch.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Shadow/CrackLib - A compromise?
Bruce Dubbs wrote: Archaic wrote: I think PAM is evil. ;) Smiley noted, but do you really think this? In many cases it is unnecessary, but it is really useful in others. For instance, in a distributed system it is the only way I know of to use LDAP centralized passwords. -- Bruce I agree with Bruce. PAM does have its issues, but if you want to use LDAP and Kerberos, it is your only option. BTW - I would also agree that PAM is and never should be LFS material. It is great where it is at. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Some improvements to the init.d/functions script
David Fix wrote: Yes to WARN. :) +1 for this James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: This is the end
Jeremy Huntwork wrote: Thanks Jeremy. You will be missed. Have fun in your new endevours. James -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
