Re: [lfs-dev] LFS SVN and Systemd Report
On Thu, May 31, 2012 at 5:21 AM, Andrew Benton a...@benton.eu.com wrote: On Thu, 31 May 2012 00:58:08 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: Actually, for some of us they *are* scary. I thought I was making some progress (persuaded autoreconf to complete without errors using the attached -A.patch), but then configure went into an infinite loop spewing out '=no' lines. That's around the check to see if we only want udev. But after the test for whether to build static libraries I also got the same result from trying to make Dan's patch work, just after checking whether to build the static libraries it started spewing out '=no' lines. If I redirected it to a file (to try and see the start) the file quickly grew to be enormous. To me, the problem with autofoo isn't that it's scary it's just that it's obscure and difficult to follow. I agree that the autofoo approach is the one most likely to be accepted upstream but Bruce's more direct approach seems to be paying dividends in the short term. Here's an update. I forgot that [] are quotes in autoconf, so you usually end up using test instead. I still didn't test it works all the way, but I think configure should run. Allow me to get on my soapbox here for a minute. Nearly all the energy in LFS is used on building packages and all the associated issues with bootstrapping systems. Ask yourself, what percentage of the packages you're building use the autotools? 50%? 75%? 90%? The percentage is high regardless. IMO, if what you're interested in is building packages, then learning the process the build is created would be a great investment. I see so much time spent here trying to work around build issues and basically guessing at how the build works. I almost never see someone actually diagnose the issue at the root when the autotools are involved. The autotools are unusual, but they really aren't that complex. One of my real oh moments when I was still building LFS was when I saw an analysis Greg did of a configure bug and realized that it really wasn't that complex at all. At Xorg a guy showed up and wanted to help on build issues but had never seen the autotools before. Within a few months he was squashing bugs all over the place and now he's basically the expert there. It's a really handy skill set because of the ubiquity of the autotools. The documentation is very good: http://www.gnu.org/software/autoconf/manual/ http://www.gnu.org/software/automake/manual/ http://www.gnu.org/software/libtool/manual/ Old, but will teach you the basics: http://sources.redhat.com/autobook/ I will now return to lurking. -- Dan udev-only.patch Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/31/12, Andrew Benton a...@benton.eu.com wrote: On Thu, 31 May 2012 14:05:19 +0100 Dan Nicholson dbn.li...@gmail.com wrote: Here's an update. I forgot that [] are quotes in autoconf, so you usually end up using test instead. I still didn't test it works all the way, but I think configure should run. Withthis patch automake fails with: Makefile.am:1447: Cannot apply `+=' because `MANPAGES' is not defined in Makefile.am:1447: the following conditions: Makefile.am:1447: UDEV_ONLY Makefile.am:1447: Either define `MANPAGES' in these conditions, or use Makefile.am:1447: `+=' in the same conditions as the definitions. Makefile.am:1511: Cannot apply `+=' because `bin_PROGRAMS' is not defined in Makefile.am:1511: the following conditions: Makefile.am:1511: UDEV_ONLY Makefile.am:1511: Either define `bin_PROGRAMS' in these conditions, or use Makefile.am:1511: `+=' in the same conditions as the definitions. Makefile.am:2773: Cannot apply `+=' because `rootlibexec_PROGRAMS' is not defined in Makefile.am:2773: the following conditions: Makefile.am:2773: ENABLE_LOGIND and UDEV_ONLY Makefile.am:2773: Either define `rootlibexec_PROGRAMS' in these conditions, or use Makefile.am:2773: `+=' in the same conditions as the definitions. I can fix that by making some changes to Makefile.am (see the attached diff) so that autoreconf now completes without error. However, when I try to run ./configure --enable-udev-only I get: checking for library containing clock_gettime... -lrt checking for library containing dlsym... -ldl checking for library containing cap_init... no configure: error: *** POSIX caps library not found Congratulations, you're off and running with the autotools! A couple notes here: 1. I definitely did not get that patch to a working state. I only was just trying to get it going in the right direction. 2. Bryan has sent a couple patches to the hotplug list to decouple things a bit. One of them has to do with getting a capability include out of a udev file. You probably want to have a look at those to not duplicate work. 3. Here it seems that the capability system is being included unconditionally. save_LIBS=$LIBS LIBS= AC_SEARCH_LIBS([cap_init], [cap], [], [AC_MSG_ERROR([*** POSIX caps library not found])]) AC_CHECK_HEADERS([sys/capability.h], [], [AC_MSG_ERROR([*** POSIX caps headers not found])]) CAP_LIBS=$LIBS LIBS=$save_LIBS AC_SUBST(CAP_LIBS) The 5th argument of AC_SEARCH_LIBS and 4th argument of AC_CHECK_HEADERS are action-not-found. I.e., what to do if you didn't find a libcap library providing cap_init or the sys/capability.h header. You could wrap those AC_MSG_ERRORs in $enable_udev_only, but I think you could probably wrap this whole section in an if test $enable_udev_only = no block. You will need Bryan's patches to untangle capabilities from the shared sources, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On Mon, May 28, 2012 at 1:00 PM, Jeremy Huntwork jhuntw...@lightcubesolutions.com wrote: On 5/28/12 2:52 PM, Bruce Dubbs wrote: The problem is that none of these libraries are used for udev. On a recent blfs system, where the systemd dependent libraries are installed, I as able to build and looked at the executables and libraries. AFAIK, the only ones are /bin/udevadm, /usr/lib/systemd/systemd-udevd, /lib/libudev.so.1.0.0 and /usr/lib/udev/*. Perhaps the best solution is to complain loudly to upstream and hope that enough do so that they build into the package the ability to build and install only the udev components as they said would be possible. Have any of you guys considered actually making patches and sending them upstream? The autotools are not that scary. Having been both upstream and downstream, my guess is that those guys will accept patches that allow a udev-only build, but they just don't have any interest in doing that work themselves. I'm sure there are more than a few people around who are interested in that scenario (they're already showing up on the hotplug list) who would test and push for the patches. If it's that critical to keep systemd out of LFS, then you'd probably be best served by taking control of the situation. IMO. Here's an untested patch to get you started. -- Dan udev-only.patch Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: pkg-config tests
On Sun, Sep 4, 2011 at 12:59 PM, Bryan Kadzban
br...@kadzban.is-a-geek.net wrote:
Bruce Dubbs wrote:
Doing some debugging, I'm making some progress. I made some debug
printouts and in the first case got:
required_pkgconfig_version 999.999
but in the second
required_pkgconfig_version a=b
(which for some reason returns a positive number for
compare_versions (0.26, a=b) but that's a nonsense comparison due to
the invalid command line parsing.
rpmvercmp() is screwy (in pkg.c). It compares the two as numbers (since
the first char of the first string is a digit), but ends up doing it
piecewise: comparing 0 to (since the first char of the second arg
is not a digit). This triggers a line preceded with a comment pointing
at RH bugzilla, bug 50977 -- the code returns 1 if the first item was
numeric, and -1 otherwise.
But the real bug is below.
I'm continuing to check.
This looked interesting, so I started digging as well. I think I found it.
poptGetNextOption, after it invokes the callback for
--define-variable=a=b (the operation of which sets the longArg local
variable), does not reset longArg to NULL. So on the next time through
its loop (after invoking the --define-variable callback, before invoking
the --atleast-pkgconfig-version callback), on line 389 of popt.c, sets
con-os-nextArg to longArg (the old a=b string). What it should do
is set nextArg to nextCharArg (the next item on the command line). This
happens if longArg is NULL.
Adding a longArg = NULL; as the first line of the while (!done) {
loop makes the tests pass. I don't *think* it breaks anything else, but
I don't know for sure.
Short patch attached. It can probably be turned into a sed.
diff -Naur pkg-config-0.26/popt/popt.c pkg-config-0.26-patched/popt/popt.c
--- pkg-config-0.26/popt/popt.c 2011-05-15 02:06:06.0 -0700
+++ pkg-config-0.26-patched/popt/popt.c 2011-09-04 12:44:26.0 -0700
@@ -297,6 +297,8 @@
int singleDash;
while (!done) {
+ longArg = NULL;
+
while (!con-os-nextCharArg con-os-next == con-os-argc
con-os con-optionStack)
con-os--;
Nice! Someone reported this issue upstream, which is why I added the
test. I tried looking through current popt for a fix, but it's
diverged quite a bit. Can you make this a real patch with description?
Sooner or later popt will be removed completely and we'll just use
glib instead, but it hasn't happened yet. I think this is the patch
for that:
http://cgit.freedesktop.org/~dbn/pkg-config/commit/?h=glib2id=503670a7390f436bc173e68e9d97e1aadee5c679
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Stripping in Chapter 6
On Tue, Oct 25, 2011 at 3:57 PM, Jeremy Huntwork
jhuntw...@lightcubesolutions.com wrote:
There appears to be a somewhat bogus statement in section 6.63
Stripping Again. It says there:
If disk space is very tight, the --strip-all option can be used on
the binaries in /{,usr/}{bin,sbin} to gain several more megabytes. Do
not use this option on libraries—they will be destroyed.
The statement that libs will be destroyed by --strip-all may be
correct for chapter 5 libs due to the adjustments we've made (and will
yet make) in chapter 6, the nature of the varying environments.
However, by the end of chapter 6 I don't believe that statement is
true any more.
Looks like you are indeed right about shared libraries. strip removes
the regular symbol table, but doesn't touch the dynamic symbol table.
Here's an example.
# Create some separate directories
mkdir full stripped
# Make a simple shared and static library
cat dragon.c EOF
#include stdio.h
void dragons(void)
{
printf(Here be dragons!\n);
}
EOF
gcc -c -o dragon.o -fPIC dragon.c
gcc -o full/libdragon.so -shared dragon.o
ar r full/libdragon.a dragon.o
ranlib full/libdragon.a
# Make stripped copies of the libraries
cp full/* stripped/
strip --strip-all stripped/*
# Look at the symbol tables of the shared libraries
# Notice that the .symtab section of the stripped library
# is gone, but the .dynsym sections are identical
readelf -s */libdragon.so
# Look at the symbol tables of the static libraries
# Notice that the stripped library has no symbols left
readelf -s */libdragon.a
# Make a test app
cat test.c EOF
extern void dragons(void);
int main(void)
{
dragons();
return 0;
}
EOF
# Build and run against stripped shared library
# Notice that it runs fine
gcc -o test test.c -Lstripped -ldragon
LD_LIBRARY_PATH=stripped ./test
# Now try again with the stripped static library
# Notice that it fails to build
gcc -o test test.c stripped/libdragon.a
So, it seems that --strip-all will only destroy your static libraries.
I couldn't find any way to strip the .dynsym section out of the
generated binaries. Then later I found this:
http://www.technovelty.org/linux/strip.html
Interesting stuff.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: links in Matt's emails
On Thu, Aug 18, 2011 at 1:53 AM, akhiezer lf...@cruziero.com wrote: Matt, For a long time now, links in your posts often include the full-stop (aka 'period') in the linked text - see e.g. the links in your post: http://linuxfromscratch.org/pipermail/lfs-book/2011-August/026906.html When one clicks on the links, a 404 or similar error happens, cos the '.' is interpreted as part of the url; and it kindof 'requires' manual correction - which is a pain. Happens here in Firefox, Seamonkey, and mailx . I think this is actually a trac bug or a mailman bug rather than on Matt's end. You can see that mail is just a forward from the activity in the ticket. http://wiki.linuxfromscratch.org/lfs/ticket/2914 If you look at the links there, they are correctly ending before the trailing punctuation. However, in the generated mail (at least in the mailman archives), the punctuation has been included in the URL. One of the admins would have to hunt that down. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: perl-5.14.1
On Sun, Jun 26, 2011 at 2:35 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Nathan Coulson wrote: silly question, but what was the reason for only installing part of perl? I know we don't need it, but we rarely go out of our way to just install what we need in chapter 5's packages. Well, it's an interesting question. Looking back, lfs was installing a partial Chapter 5 perl in May 2003, perhaps earlier. I don't remember the details, but I suppose it was for efficiency reasons. IIRC, this was a DIYism that we borrowed from Greg. Essentially, perl with all the modules distributed in the tarball is much more than what's necessary for bootstrapping. Furthermore, perl will by default build all the modules for dynamic loading. By passing -Dstatic_ext=..., you're building only the necessary extensions and then linking them statically into the perl executable. It's less space and build time, but it's also a little more robust since you can't get into a situation where perl is looking in the wrong spot for these modules. So, it's really an optimization only. Just FYI, to keep that optimization but just add AutoSplit, you can just add cpan/AutoLoader/pm_to_blib to the make line. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbs bruce.du...@gmail.com wrote: DJ Lucas wrote: On 05/30/2011 12:34 PM, Bruce Dubbs wrote: In the latest svn, the bootscripts are lfs-bootscripts-20110424. I get an error: make[1]: /usr/lib/lsb/install_initd: Command not found This was identified a week ago by xinglp, but I don't see a fix. -- Bruce Either need to roll back the inadvertent commit to the bootscripts tarball job or move forward with the patch I sent in. Let me know if I should do this. I'd appreciate it if you could do a revert. I took a look at the patch and it installs initd-tools as yet another package. I looked at the source to initd-tools and I don't understand why we need a C program to do that. It could be done in a shell script. That would require some effort to create, but would be much easier to maintain. Perhaps I can try writing the script after the middle of next month. We have a big deadline coming up. After that, I think I've earned about a year of comp time. Try writing as a shell script, Bruce. DJ did before and found that my C version was much, much faster. Parsing the dependencies and building a tree in an interpreted language with no data structures is a nightmare. In C it's a linked list of structs. Just my opinion, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using the LSB Bootscripts
On Tue, May 10, 2011 at 6:39 AM, Jeremy Huntwork jhuntw...@lightcubesolutions.com wrote: On 5/10/11 8:25 AM, DJ Lucas wrote: * Most important, pull as much as possible of the items below from LightCube OS's files to ease merging and keep the diffs to a minimum so that they are easily shared across distributions. * Move ifup and ifdown scripts to /sbin. * Move network service scripts to /lib/services (there was one minor objection here, should that be /lib/network-services or /lib/network? I don't really have any preference here, /lib/services is fine by me). * Move network configuration files to /etc/network. * Move network (hostname value) and clock config into /etc/default/rc.site (default to UTC?) * Use /etc/default for rc configuration files (remaining items in /etc/sysconfig currently). All fine from my perspective. :) * Add initd-tools to book - This is required for the new scripts. Jeremy what is the status on this in LightCube OS? I remember a few months ago about you possibly taking over maintenance of them, adding a service binary/script and such? At last check, Dan did not have them in an RCS, which is not an issue for now, just curious about the future of the tools. The tarball and homepage are available in Dan's home directory on freedesktop.org if we need for the book. Dan? I never got around to adding these into a repository, but I could do so. I'd be happy to maintain them. I'll need to schedule some time to get the infrastructure together for them and then post links. I nominate you as the new maintainer. :) Since I don't roll my own anymore I don't actually use the programs, but DJ has used them and they worked for me at one point. I put the repo on freedesktop.org in git://anongit.freedesktop.org/~dbn/initd-tools. I updated the webpage with the relevant info, but it'll take a little longer for cgit to display the repo. http://people.freedesktop.org/~dbn/initd-tools/ Let me know if I can help. This was my first major C project, so you might find some ugly code in there. Good luck! -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Menu configuration
On Wed, Mar 23, 2011 at 10:00 AM, Lars Nielsen l...@mit-web.dk wrote: Hey, Maybe a little off-topic. :-s Can I use the c code from the menu/ folder in jhalfs in my own project to make a similar configuration menu? Are there some extra documantation to this ncurses based menu-system? I'm pretty sure it was taken from busybox which in turn was taken from linux's Kconfig system. You can certainly use it yourself if the license is permissible (almost certainly GPL). The code is in the linux tarball under scripts/kconfig, and there's docs in Documentation/kbuild. -- Dan -- 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 Wed, Mar 16, 2011 at 3:22 PM, Steve Jones s...@slohj.org wrote: On Mon, 14 Mar 2011, DJ Lucas wrote: On 03/14/2011 12:03 AM, Nathan Coulson wrote: On Sun, Mar 13, 2011 at 9:45 PM, DJ Lucas d...@linuxfromscratch.org mailto:d...@linuxfromscratch.org wrote: On 03/13/2011 11:39 PM, DJ Lucas wrote: * LSB Compliance - For LFS we are nearly there anyway. * Dynamic boot script - No more static list of links, this kind of ties into LSB Bootscripts, but there are other options. Again, these two go hand in hand for me. In the current lfs-bootscripts tarball, I've been working on and using exclusively the contrib/lsb-v3 boot scripts for over 3 years now. They are an extension of something that Nathan Coulson and Alexander Patrakov had started on. These are completely lsb-v4 compliant as well and are IMO a huge improvement over the current boot scripts. I've been using Dan Nicholson's initd-tools package to provide the install_initd and remove_initd programs. Aside from the fact that there is no longer any need to maintain a list of symlinks for startup order, they add a lot of niceties, including boot-logging and conditional startup for trouble-shooting. ah, I miss the bootscript days. I'll have to take a look, and find out what I have been missing out on 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. Do you have the link to initd-tools. I've searched all morning and can't find anything. I'm thinking of trying the LSB scripts on my next build now that linux=2.6.38 is out. http://people.freedesktop.org/~dbn/initd-tools/ I haven't migrated the git repo over there yet, but I also haven't made any more commits since the last release. :) -- Dan -- 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 Mon, Mar 14, 2011 at 6:56 PM, Bruce Dubbs bruce.du...@gmail.com wrote: * LSB Compliance - For LFS we are nearly there anyway. So, since you have raised this, what do you think needs to be done that is a major change ? More to the point, should we really care ? I don't have any interest in letting people run binaries. * Dynamic boot script - No more static list of links, this kind of ties into LSB Bootscripts, but there are other options. I don't know what you mean by this ? It's the first time I've heard the phrase dynamic boot script. I hope this isn't anything to do with upstart or systemd, what I've seen of those fills me with a mixture of horror and disgust ;) I've looked at this and made some posts about it in 2009. LSB is a 'trailing' standard and many new capabilities (e.g. Qt4, KDE4, etc are not adequately addressed in LSB. We already address parts of LSB in section iv. We also mention building non-wide Ncurses libraries. I am not opposed to reworking the bootscripts to be more consistent with LSB and setting things up to build the boot order into the scripts instead of the Makefile. Is this enough to relabel LFS to 7.0 instead of 6.x? Perhaps, but I would lean towards no. It's actually pretty simple and can really enlightening to think through the dependencies of the scripts. I actually think that once you start doing it, you'll wonder why you weren't doing it before. Especially once you get into BLFS bootscripts, it can be a real pain to get the order right for running the scripts. Right now the LFS bootscript order is hardcoded in the Makefile, and the reasons for that order have almost certainly been lost to time. Doesn't the process of entering the script dependencies in the script and having a program order them for you make sense? -- Dan -- 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 Mon, Mar 14, 2011 at 1:50 PM, Robert Xu rob...@gmail.com wrote: On Mon, Mar 14, 2011 at 16:45, Ken Moffat k...@linuxfromscratch.org wrote: On Sun, Mar 13, 2011 at 11:39:04PM -0500, DJ Lucas wrote: * Dynamic boot script - No more static list of links, this kind of ties into LSB Bootscripts, but there are other options. I don't know what you mean by this ? It's the first time I've heard the phrase dynamic boot script. I hope this isn't anything to do with upstart or systemd, what I've seen of those fills me with a mixture of horror and disgust ;) The LSB bootscripts work similar to insserv on (newer) Debian and SuSE, right? Yeah. Instead of hardcoding the symlink order as is done in the bootscripts Makefile, dependencies are added to the header of the script and a tool creates the links for you, ensuring that the dependencies are satisfied. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg plans (Was: Re: problem with groff 1.21)
On Wed, Jan 12, 2011 at 6:12 PM, DJ Lucas d...@linuxfromscratch.org wrote: On 01/12/2011 05:45 PM, Ken Moffat wrote: I've no idea where BLFS is going in the move to 7.6 - my (old) radeons work well in everything except mesa-demos, but then I no longer build a lot of the old things (many of the 'apps' still listed in BLFS, also the old core fonts - I'm all TTF here). Moved to BLFS-Dev... BLFS hopefully will move to 7.6-1 this weekend (time permitting). I've tested on both x86 and x86_64 and it seems to be solid on my hardware. I've done both /opt/X11 and /usr installations on x86, but only /usr on x86_64 (the /opt/X11 prefix will require a lib64 - lib symlink). While I've done a complete U-turn on my intentions, I also plan to suggest that we do only system installations in the book for everything after this release, and move instructions to the wiki if we choose to support packages installed elsewhere (the maintenance burden of Trinity and Gnome using /opt is far too much to handle reliably (and later KDE4?)). I plan to add a warning box in the book for this release mentioning the $XORG_PREFIX/lib64 - lib symlink. Mesa Demos will be gone from the book and the Configuring Xorg will be one page. Old fonts will remain as they are still listed as part of the Xorg distribution. I'm curious why you want to get rid of the demos. Surely everyone goes to glxinfo and glxgears to see if 3D is working, right? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscript future
On Mon, Aug 23, 2010 at 2:12 AM, Jeremy Huntwork
jhuntw...@lightcubesolutions.com wrote:
On 8/11/10 12:40 AM, DJ Lucas wrote:
Actually, for LSB compliance, the 'distribution supplied boot scripts'
need not use /lib/lsb/init-functions at all. All that is required is
that the scripts provide the LSB header information, and can therefor be
manipulated by {install,remove}_initd. That said, I have been working
on a replacement for the LFS bootscripts for some time, and have a fully
compliant set in LFS/trunk/BOOK/bootscripts/contrib/lsb-v3/, with quite
a few of the BLFS scripts completed as well in
BLFS/bootscripts/contrib/lsb-v3/.
Awesome work. I've been playing with them and they will definitely fit
my needs. They're a huge improvement over the current LFS bootscripts.
I did encounter a syntax error, however. The sendsignals script is
missing ' ; then' after a leading if in two places. This sed fixes it:
sed -i 's...@\]@ ; then@' init.d/sendsignals
dynamic. I think they are ready for prime time, everyone should really
should give them a try on your next build.
I'd be pretty happy if these went into LFS.
As far as chkconfig, I'm personally not a fan, just because it
duplicates the purpose of the LSB tools, but it does allow you to change
started runlevels which the LSB tools do not (I'm pretty sure that would
conflict with Dan's tools, so if we did that, we'd need to use what RH
and others use for the install_initd and remove_initd tools (which
require python IIRC). IMO, it would be easier to just edit the runlevel
header information in the script rather than using chkconfig.
I can do without chkconfig. I do miss the ability to list what is
enabled, and only mildly miss the ability to enable/disable specific
run-levels for a given service.
Having said that, assuming it doesn't break any LSB compliance, I'd be
happy to add those features into Dan's tools. As it is, if I begin using
them in earnest, I may just take over maintenance of them.
Feel free to! :) It was more of a scratch an itch project, but I
don't actually use them anymore so what I'm doing doesn't even count
as maintenance. There's definitely some ugly code in there from being
a C noob, so you could learn it just by scoping the code for
janitorial work.
http://git.dwcab.com/cgit/initd-tools.git/
Oh, man, some of those commits are pretty embarrassing. It should be
LSB compliant, though. That was the point all that time back.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: ntp init script
On Mon, Aug 23, 2010 at 3:30 PM, Jeremy Huntwork jhuntw...@lightcubesolutions.com wrote: On 8/23/10 6:10 PM, Bruce Dubbs wrote: What if the ntp server provided is down like in the 2nd entry above? Or (for who knows what reason) outgoing ICMP packets are blocked where you have no control? This problem is not easily solved. Understood and agreed. Again, I think that initial set of the date shouldn't be part of the bootscript. It's definitely not necessary and slows down the boot even when the network is immediately available. ntpd will slew the time back into sync without forcing an inital sync and will respond to the network becoming available if it's not initially there. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ssl certs - not found by epiphany-2.30
On Tue, Jun 22, 2010 at 8:44 AM, Ken Moffat zarniwhoo...@googlemail.com wrote: (yeah, I know the book is still using gnome-2.28). In openssl we put the certs in /etc/ssl/ca-bundle.crt. I haven't yet identified what else is using these, but epiphany is looking for /etc/pki/tls/certs/ca-bundle.crt and /etc/ssl/certs/ca-certificates.crt. I can fix this by passing --with-ca-file=/etc/ssl/ca-bundle.crt but ti makes me wonder if we are putting them in the wrong place. I don't think so. Fedora just happens to put them in /etc/pki/tls/certs/ca-bundle.crt, but I believe Debian/Ubuntu does something different. If you build wget, you'll see a different default. I think you just have to make sure the packages use the certs where you put them. Any pointers to investigating this ? At the moment I'm unclear is it's us or the epiphany devs who are mistaken (or, perhaps, some distros use one name, and others use a different name). I think the latter. :) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: the issue of environment value $PS1 set under Ubuntu 10.04
On Fri, Jun 4, 2010 at 1:40 AM, littlebat dashing.m...@gmail.com wrote:
This issue was posted onto lfs-support mailing list yesterday (see:
http://linuxfromscratch.org/pipermail/lfs-support/2010-June/038814.html ),
unluckly I disabled the mail delivery of LFS mailing list some days ago, so I
can't continue discuss it on the lfs-support mailing list. And, I consider it
is a bug of LFS6.6 book, so I start a new thread on the lfs-dev list to
discuss it.
I am using Ubuntu 10.04 as the LFS building host. When I set environment with
the instructions at: 4.4. Setting Up the Environment:
http://www.linuxfromscratch.org/lfs/view/6.6/chapter04/settingenvironment.html
, I found the commands provided by LFS book can't set $PS1 value under
Ubuntu 10.04 host properly. The commands is below:
code
cat ~/.bash_profile EOF
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF
/code
The issue is Ubuntu has a system-wide .bashrc file for interactive bash(1)
shells, it is /etc/bash.bashrc. $PS1 has been set to
PS1='${debian_chroot:+($debian_chroot)}...@\h:\w\$ ' in this file. When the
command above invoke /bin/bash to start a new interactive bash shells,
/etc/bash.bashrc will invoked first, this $PS1 value will be seted. So, $PS1
keep as the format like l...@u1004b2-desktop:~$ , not the format excepted
by LFS6.6 book like lfs:~$ .
Looks like debian and ubuntu hosts have the SYS_BASHRC definition set,
which will source /etc/bash.bashrc before ~/.bashrc on non-interactive
logins. Seems like the easiest fix is to move the PS1 setting to
~lfs/.bashrc, but it probably doesn't affect anything to leave the
ubuntu settings.
On the other hand, the whole point of that setup is to get full
control over the shell environment, and now you have arbitrary things
being set from /etc/bash.bashrc. Probably the only true way to avoid
this is to build your own bash and run it. The other way is to run the
interactive shell with --posix and ENV set.
cat ~/.bash_profile EOF
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' ENV=$HOME/.bashrc
/bin/bash --posix
EOF
Of course, you lose all the nice bashisms, though.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [spammer]
On Thu, Apr 15, 2010 at 11:57 AM, Bruce Dubbs bruce.du...@gmail.com wrote: srinivas Eranti wrote: LinkedIn This user has been block from the list. That might be a little hasty. When you sign up for LinkedIn, it tries really hard to send invitations to everyone in your contacts. He may have done this inadvertently without realizing everyone it was being sent to. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Radeon DRM
On Fri, Mar 5, 2010 at 3:24 AM, Andrew Benton b3n...@gmail.com wrote: On 05/03/10 09:38, Duncan Baynes wrote: Hello, Just built a 64bit lfs 6.6, everything went smoothly, excellent work as always! I've been playing around with the 2.6.33 kernel including the new radeon driver. The results are pretty awesome. I now have a high resolution console that is a pleasure to use. I was thinking it might be a nice feature to add as an option... probably as a hint. The basic path is as follows: 1) compile the 2.6.33 kernel with firmware support, initramfs and the radeon driver enabled 2) create an initrd image for the kernel (there is a hint for this already) 3) decompress initrd image, mount it and insert the firmware bin for your card You don't need to use and initrd, you can compile the firmware into the kernel. If it's firmware that comes with the kernel use the option CONFIG_FIRMWARE_IN_KERNEL=y And if you want to use firmware that doesn't come with the kernel, copy it into the firmware folder in the kernel source and use the option CONFIG_EXTRA_FIRMWARE=name-of-firmware My system hangs early in the boot process if I enable kernel mode setting. From the kernel's help page This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX (radeon up to X1950). Works is underway to provide support for R6XX, R7XX and newer hardware (radeon from HD2XXX to HD4XXX). I live in hope Does it hang, or do you just get a blank screen? If you're using kernel modesetting (KMS), fbcon needs to be loaded to get the console up. Most of the distros are just building it into the kernel so it doesn't have to be modprobe'd. I think it's CONFIG_FRAMEBUFFER_CONSOLE. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Backporting Nouveau to the 2.6.32.* kernel
On Sun, Feb 21, 2010 at 2:49 PM, Andrew Benton b3n...@gmail.com wrote: On 21/02/10 20:57, Agathoklis D. Hatzimanikas wrote: I don't think this can be done for the current LFS release that will ship with 2.6.32. The Book already says that the latest available 2.6.32.x should be used. The backported patch, it might be applied to 2.6.32.8 but probably it won't apply to the next minor releases of 2.6.32. I think this ticket should wait for the next LFS release that will update to 2.6.33 and then a BLFS ticket is justified. Generally speaking, I disagree to backport such huge stuff in the kernel, unless it's for a security issue. But the 2.6.32 is already a long term supported kernel, which means in my mind, no new features added but only bug fixes, so this job is already done by the kernel team. I agree. Although Nouveau is in 2.6.33 it's still in the staging area, it's not in the kernel proper. I like Nouveau, I started using it on some of our computers a couple of months ago. It allows me to use some Nvidia cards that wouldn't work with the nv driver. Google earth works really well. If someone wants to use Nouveau they should just use a 2.6.33 kernel. It shouldn't be too hard for someone who's done LFS More importantly, fedora is able to backport nouveau and other drm features because they have the drm maintainer, Dave Airlie, to make things work. They also employ one of the nouveau developers, Ben Skeggs, to make nouveau work. LFS has nobody like this and shouldn't pretend to be able to support it. LFS should only include work like this when upstream blesses it and puts it into stable releases. I know the radeon developers weren't happy when distros started enabling the experimental kms features and they got flooded with bug reports about things breaking. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Standards Base
On Mon, Oct 26, 2009 at 10:16 PM, Bryan Kadzban br...@kadzban.is-a-geek.net wrote: Bruce Dubbs wrote: Couldn't find install_initd See bootscripts/contrib/lsb-v3 in the book repository for this one. Personally, since I never use this interface (since symlinks don't confuse me :-P ), I don't want it, but... Note that I believe it also requires either symlinks, or moving all the bootscripts around -- /etc/init.d/, /etc/rc?.d/, etc. not all those same paths under /etc/rc.d/ where they stay out of the way of /etc tab completion. That may not be a strict LSB requirement, but I think I remember DJ talking about it at one point when doing the lsb-v3 thing. The point here is that a 3rd party package doesn't need to know how your init implementation works. It supplies a script that says what runlevels and dependencies are needed in the header. Then it can put the script in /etc/init.d and call install_initd. That's it. Whether you're using symlinks in rc.d or using something like upstart in compat mode, the 3rd party doesn't need to know or care about it. 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. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Standards Base
On Mon, Oct 26, 2009 at 8:43 PM, Bruce Dubbs bruce.du...@gmail.com 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. 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 Couldn't find cpio Couldn't find crontab Couldn't find install_initd Couldn't find java Couldn't find lp Couldn't find lpr Couldn't find mailx Couldn't find pax Couldn't find remove_initd Couldn't find sendmail Couldn't find time 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 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. I haven't touched it in a while, but that's exactly why I wrote this: http://www.dwcab.com/projects/initd-tools/ DJ has built up LSB style init scripts for LFS. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils i18n patch prevents dash from building
On Sat, Aug 15, 2009 at 7:53 AM, Matthew Burgessmatt...@linuxfromscratch.org wrote: Hi, Following a thread on blfs-support[0], it looks like the i18n patch for Coreutils causes a problem during compilation of Dash in BLFS. The attached builtins file produces the following output when we compile Coreutils with the i18n patch: $ LANG=en_GB.UTF-8 $ sort -u -k 3,3 builtins 0 . -s dotcmd $ LANG=en_GB $ sort -u -k 3,3 builtins 21 local -a localcmd 14 export -as exportcmd 3 alias -au aliascmd 7 chdir cdcmd 10 echo echocmd 18 hash hashcmd 22 printf printfcmd 23 pwd pwdcmd 0 . -s dotcmd 2 [ testcmd 33 type typecmd 4 bg -u bgcmd 34 ulimit ulimitcmd If the i18n patch isn't applied, then the LANG setting has no effect on sort's output, always outputting the correct data as per the en_GB listing above. So, what do we want to do? Just remove the sort-related hunks of the i18n patch, drop the patch altogether, or try and fix this bug? I can easily do either of the 1st 2, but trying to fix the bug is beyond my limited C abilities. I thought the mk_builtins script (or whatever it's called) runs sort with LC_COLLATE=C? Can you check (this came up before because I was building with en_US.UTF-8 and the sorting was wrong)? The whole operation is pretty simple. There are a set of shell builtins in a text file, and the script sorts it and creates a binary tree in a .h suitable to be built into dash. At least, that was the problem before. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils i18n patch prevents dash from building
On Sat, Aug 15, 2009 at 8:54 AM, Matthew Burgessmatt...@linuxfromscratch.org wrote: On Sat, 15 Aug 2009 08:13:38 -0700, Dan Nicholson dbn.li...@gmail.com wrote: On Sat, Aug 15, 2009 at 7:53 AM, Matthew Burgessmatt...@linuxfromscratch.org wrote: Hi, Following a thread on blfs-support[0], it looks like the i18n patch for Coreutils causes a problem during compilation of Dash in BLFS. The attached builtins file produces the following output when we compile Coreutils with the i18n patch: $ LANG=en_GB.UTF-8 $ sort -u -k 3,3 builtins 0 . -s dotcmd $ LANG=en_GB $ sort -u -k 3,3 builtins 21 local -a localcmd 14 export -as exportcmd 3 alias -au aliascmd 7 chdir cdcmd 10 echo echocmd 18 hash hashcmd 22 printf printfcmd 23 pwd pwdcmd 0 . -s dotcmd 2 [ testcmd 33 type typecmd 4 bg -u bgcmd 34 ulimit ulimitcmd If the i18n patch isn't applied, then the LANG setting has no effect on sort's output, always outputting the correct data as per the en_GB listing above. So, what do we want to do? Just remove the sort-related hunks of the i18n patch, drop the patch altogether, or try and fix this bug? I can easily do either of the 1st 2, but trying to fix the bug is beyond my limited C abilities. I thought the mk_builtins script (or whatever it's called) runs sort with LC_COLLATE=C? Can you check (this came up before because I was building with en_US.UTF-8 and the sorting was wrong)? Ah, it does, but only on an earlier invocation of sort! So, I guess, for now, BLFS could have a patch to dash to add LC_COLLATE=C to the other call to sort in src/mkbuiltins. Yeah, I'd send that upstream and cc Herbert Xu. Longer-term though, we certainly need to fix up our patch in LFS though. I'd expect it produce the same output in both en_GB and en_GB.UTF-8 locales. Are you sure that's correct, though? They will only definitely have the same output if en_GB and en_GB.UTF-8 are the same locale. UTF-8 locales usually have different collating rules. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 3 concurrent instances of udevd
On Tue, Jul 21, 2009 at 3:27 PM, Matthew Burgessmatt...@linuxfromscratch.org wrote: Hi, On a newly built LFS-6.5-RC1 (with file-5.03 Linux-2.6.30.2) I see 3 instances of `/sbin/udevd --daemon' running at the same time. Process 498, parent 1 Process 543, parent 498 Process 544, parent 498 Is this what 'NEWS' in the tarball refers to as 'worker' processes, or are we not configuring/starting Udev-145 correctly? I'm pretty sure those are the workers. They also played around with a threaded version, but I think this one performed better. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
On Sun, May 24, 2009 at 10:51 PM, Bryan Kadzban br...@kadzban.is-a-geek.net wrote: Bruce Dubbs wrote: --enable-kernel=VERSION compile for compatibility with kernel not older than VERSION Yes: abort any program at startup if the current kernel version is less than VERSION, and also remove any workarounds included in the glibc sources for kernels older than VERSION (if any). but I found http://www.mail-archive.com/arch-dev-pub...@archlinux.org/msg08016.html which says: The minimum kernel version required for glibc was bumped from 2.6.16 to 2.6.18 That's an Arch decision (made by their maintainer), not something that applies to glibc itself. :-) See: http://repos.archlinux.org/viewvc.cgi/glibc/repos/core-x86_64/PKGBUILD?r1=36985r2=39100 for the actual change in their PKGBUILD script. (The section labeled line 62.) A more authoritative measure here would be to follow fedora since they are the glibc maintainers. Unfortunately, there's no real rationale, but their version is 2.6.18 made with this change: http://cvs.fedoraproject.org/viewvc/rpms/glibc/devel/glibc.spec?view=diffr1=1.376r2=1.377 Probably would be best to investigate why that is before making a change like that. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
On Tue, May 26, 2009 at 12:40 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Dan Nicholson wrote: On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs bruce.du...@gmail.com wrote: Using 2.6.18 appears to potentially affect binaries built against kernels older than that and run on a LFS-6.5 or later system. I don't see where that would be an issue. I don't think it affects binaries. It only affects what kernel you're running. You can have an ancient binary, and so long as the binary format and interfaces are still supported on the system you're running, it should be fine. It sounds like you are agreeing with me. An ancient binary will not run if the support is not built into glibc. But I think we're disagreeing on what the support is. A binary compiled on LFS-6.0 will be ELF, which is the same. Likewise, glibc and the kernel provide excellent backwards compatibility in interfaces (regardless of what --enable-kernel setting was used for the LFS-6.0 glibc). So, there's a near 100% chance that an LFS-6.0 binary will run on LFS-6.5, and the --enable-kernel setting has no bearing on that. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: zdiff problem
On Sun, May 17, 2009 at 6:49 PM, Bruce Dubbs bruce.du...@gmail.com wrote: I'm trying to address ticket #2315 that says zdiff doesn't work. I confirmed this by creating two files with a one line difference and compressing them: gzip file1 gzip file2 But 'zdiff file1.gz file2.gz' gives no output. Older versions of the script work properly. The code in the script is really convoluted. I found an error report in the gzip archives about this: http://lists.gnu.org/archive/html/bug-gzip/2008-02/msg2.html I note that there was never a reply to the message and that was over a year ago. The bug-gzip list unfortunately is pretty dead. I subscribed to it to submit a patch for this specific problem, but I never got around to submitting the patch or unsubscribing. :) The problem code looks like: gzip_status=$( exec 41 (gzip -cdfq -- $1 4-; echo $? 4) 3- | ( (gzip -cdfq -- $2 4-; echo $? 4) 3- 5- /dev/null | eval $cmp /dev/fd/5 -) 50 ) When I look at /dev/fd, I only have 0 through 3 (and on RH and Ubuntu other systems too, but none use gzip-1.3.12). /dev/fd/ is just a symlink to the current process file descriptors. Typically you have 0, 1 and 2 for stdin, stdout and stderr. But a process can open up any more it wants. In this case, fd 5 is opened by the redirection. The fix appears to be changing the last line above to eval $cmp /dev/fd/5 - 3) 50 added We can fix this with this with the following: sed -i 's/5 -)/5 \3)/' zdiff but I don't understand what is really going one here. Should I make this change? Comments? I think that's right looking at the rest of the script (I agree it's a pretty hairy script). I wish I could find the patch I made before, but I can't seem to locate it now. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
The time has come
Hi everyone, I'm sure those of you that are actively involved in LFS have noticed that my participation has been non-existent for quite some time now. So, this should probably not shock anyone, but I think it's time that I step away from my duties as an editor for LFS and BLFS. I still enjoy reading about LFS and think that it's a really great project (especially for education), but my interests have moved elsewhere. As I've spent more time poking and prodding the software over the years, I've become less interested in the packaging of the software and more interested in the development of the software. Time spent developing has been cutting into the packaging side more and more to the point where the only packages I typically build from source now are the ones I'm developing or need the development version of. In a sense, I've moved upstream a bit and spend time working on various other projects that LFS consumes. Primarily, I've been working on Xorg. So, if you follow the software that's used in LFS, this is probably not the last you'll see of me. I'll probably stay subscribed to the -dev lists and poke in from time to time, too. I really appreciate everything that the LFS community has done for me over the years. This was the project that introduced me to the world of open source software. This was also the project were I contributed to and the first I got commit access to. I've learned a ton about the FOSS ecosystem through LFS. There are a lot of people in the LFS world that have made an impact on me over the years. I had a lot of fun working here because of the people. One person I have to single out is Jeremy Huntwork. He nurtured my early contributions, was the one to push for my commit rights, and really made developing LFS a fun place for me to be. I hope no one else takes that as a slight. Anyway, thanks for the opportunity and all the experiences. Feel free to remove my commit rights on the servers and my name from the books. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
On Fri, Mar 20, 2009 at 4:44 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
Dan Nicholson wrote:
On Fri, Mar 20, 2009 at 11:15 AM, Bruce Dubbs bruce.du...@gmail.com wrote:
Dan Nicholson wrote:
A while back I sanitized the bootscripts for POSIX sh compatibility, and
I think DJ has been maintaining that goal. I think it's a nice (and
obtainable) goal to target since having sh != bash can save on bloat.
Save on bloat? For what? My copy of bash is 500K. dash is about 80K.
Right, bash is 4 times the size of dash. That adds up when you're forking the
shell a hundred times or whatever during boot.
Come on Dan. You know better than that. When you fork a program, the code
segment is not duplicated, but only any necessary data. For that, there would
be no significant difference between bash and dash.
I don't honestly know how much memory is duplicated or not. Here's a
loop of shells that simply fork, do nothing and exit.
$ time { for n in {0..100}; do /bin/bash -c :; done; }
real0m0.431s
user0m0.227s
sys 0m0.191s
$ time { for n in {0..100}; do /bin/dash -c :; done; }
real0m0.159s
user0m0.048s
sys 0m0.120s
Clearly, it is taking more time for the bash shell. I know you are
going to say we're only talking about hundredths of seconds for each
run, so why should we care. But it's more than double relatively.
If you were looking at a system (not just a computer system) and you
found that one part took twice the resources and twice as long to
start up as another part offering similar functionality, why would you
dismiss it? Maybe the original part offers better features than the
replacement, but that doesn't mean the other facts can be ignored.
The last time I tested, it shaved like 4 seconds off boot using dash instead
of bash.
http://linuxfromscratch.org/pipermail/lfs-support/2008-February/034192.html
I use bash all the time and I wouldn't consider using a minimal posix shell
for my login shell. For any non-trivial script, I use bash. However, for a
generic shell script, I don't know why you couldn't make it posix compliant.
That allows people to have flexibility without much loss. The bootscripts are
pretty simple.
As you mention, bootscripts are pretty simple and in no way are a stress test.
Four seconds doesn't seem very significant to me. It's not enough to notice
unless you are doing a timing test.
4 seconds out of 18 total is something I consider very significant.
For you, maybe it's not, but you are free to keep /bin/bash as
/bin/sh. However, you agree that the bootscripts are simple, so why do
you need to use bash again?
Let's just forget about it. I think this is the second or third time
we've had this conversation and I think we just say the same things
back and forth.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: no libidn/ in glibc-2.9
On Fri, Mar 20, 2009 at 5:51 AM, Matthew Burgess matt...@linuxfromscratch.org wrote: On Fri, 20 Mar 2009 13:46:16 +0100 (MET), Alexander Kozlov akoz...@nada.kth.se wrote: You are right, libidn is not mentioned in the book, my fault. There is libidn/ directory in the snapshot source tree which is absent in glibc-2.9 release. Is this something to worry about? No, I don't think so. From the comment in the book source, most packages require the libidn package from GNU (see BLFS for instructions), rather than Glibc's implementation. So, the fact that Glibc's libidn directory is missing is unlikely to affect anything, I think. The point of having libidn in glibc is not to expose it to applications. It's to add support for reading internationalized domain names from nss (i.e., libnss_dns). Then all your normal C calls like gethostbyname work with internationalized names. However, I would guess that most applications that want to deal with internationalized domain names don't expect to have that support from the system's C libraries. Instead, they'd probably link against the standalone version. So, it probably doesn't hurt that bad, but it is a useful feature that should probably be kept. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
On Fri, Mar 20, 2009 at 8:38 AM, Matthew Burgess matt...@linuxfromscratch.org wrote: Given that LFS only installs bash, does any of this matter? :) A while back I sanitized the bootscripts for POSIX sh compatibility, and I think DJ has been maintaining that goal. I think it's a nice (and obtainable) goal to target since having sh != bash can save on bloat. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
On Fri, Mar 20, 2009 at 11:15 AM, Bruce Dubbs bruce.du...@gmail.com wrote: Dan Nicholson wrote: A while back I sanitized the bootscripts for POSIX sh compatibility, and I think DJ has been maintaining that goal. I think it's a nice (and obtainable) goal to target since having sh != bash can save on bloat. Save on bloat? For what? My copy of bash is 500K. dash is about 80K. Right, bash is 4 times the size of dash. That adds up when you're forking the shell a hundred times or whatever during boot. The last time I tested, it shaved like 4 seconds off boot using dash instead of bash. http://linuxfromscratch.org/pipermail/lfs-support/2008-February/034192.html I use bash all the time and I wouldn't consider using a minimal posix shell for my login shell. For any non-trivial script, I use bash. However, for a generic shell script, I don't know why you couldn't make it posix compliant. That allows people to have flexibility without much loss. The bootscripts are pretty simple. Of course, you can keep bash as /bin/sh if you like. Or make it zsh or ksh or dash or posh... -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
On Mon, Jan 19, 2009 at 12:29 AM, Jim Gifford c...@jg555.com wrote: Greg Schafer wrote: Jim Gifford wrote: Again Greg provide us more information about the ICA, it seems to be your own creation? 1. Read this post from Dan Nicholson: http://article.gmane.org/gmane.linux.lfs.devel/8120 2. Look at the comments in the gsbuild scripts from DIY 3. Look at the jhalfs implementation (Note: I haven't) 4. Ask Ryan to explain it to you Regards Greg Ok, so there is not technical background for these tests. For all we know they could provide bogus errors. I need some good technical facts, not hear say. I have searched and searched trying to find merit in this type of comparison, I can't find anything at all. How is it hearsay? Plenty of people (Greg, myself, Jeremy, Manuel, Matthew, etc.) here have used this analysis to identify issues in the build. The current ordering of the packages in LFS was determined almost entirely through use of ICA. It's really not magical at all and has a very straightforward technical implementation. The fact that Greg calls it ICA is really just an implementation detail. 1. Repeatedly build your system and keep a copy of each build. 2. Use diff/cmp to compare each build. This will highlight if bootstrapping has introduced any differences. I can't really think of any simpler way to determine if the bootstrapping technique has problems. The same thing happens during the gcc bootstrap process, and I don't see that being called meritless. The alternative is just to ignore any potential issues until something becomes broken. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
On Mon, Jan 19, 2009 at 12:13 PM, Jim Gifford c...@jg555.com wrote: Dan Nicholson wrote: How is it hearsay? Plenty of people (Greg, myself, Jeremy, Manuel, Matthew, etc.) here have used this analysis to identify issues in the build. The current ordering of the packages in LFS was determined almost entirely through use of ICA. Why aren't any of the big distro's doing this type of test. There distro's had to start from something simliar to what they have. Except for probably Gentoo, none of the distros really care about bootstrapping systems. I would imagine Gentoo does have some regression test, but I've never looked. Most distros just build packages against the current toolchain, though. I can't really think of any simpler way to determine if the bootstrapping technique has problems. The same thing happens during the gcc bootstrap process, and I don't see that being called meritless. The alternative is just to ignore any potential issues until something becomes broken. I do not disagree with you, but I want to get the facts. Greg is not impartial, so I have to through his results out. As far as the rest I trust their feedback, but in order to make it a good test. I have to get the results myself and validate them. If this is a method we are going to use to test the purity of a build, we need to have people that just check that instead of saying it passes. Publish the results good or bad. Give feedback to those who are designed this *LFS style systems. Maybe this is something we can fully document and put out to the Linux Community. Sure. Again, though, there isn't really much of a community for bootstrapping systems. I'm guessing that many of the people that care about this are following this discussion. The gsbuild, jhalfs and farce implementations are all using the same techniques, I believe. So, there already is a bit of standardization. Try it for yourself, though. Just read the two do_ica_prep and do_ica_work in gsbuild. I think you'll see that it's pretty unambiguous and that you could easily augment your build platform to do it. http://cvs.diy-linux.org/index.cgi/gsbuild/common-sh.functions?rev=HEADcontent-type=text/vnd.viewcvs-markup -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: expat 2.0.1 patch
On Wed, Jan 14, 2009 at 11:54 AM, Dan Moore moore...@suncup.net wrote: Installation of expat on BLFS 6.3/SVN doesn't include a expat.pc file for pkgconfig. As a result, some downstream installs think that expat is missing from the system. This patch (tested on expat-2.0.1) corrects this issue. (The basis for the patch was another one that I found, but it was incomplete and caused an error during make -- this one works). http://www.suncup.net/miscdocs/expat-2.0.1-pkgconfig.patch FWIW, I sent a patch to the expat list that was applied. There just hasn't been a release since then. http://mail.libexpat.org/pipermail/expat-checkins/2007-September/001084.html -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: CLFS Bashing - Fork?? When??
On Wed, Dec 24, 2008 at 12:36 PM, Jim Gifford c...@jg555.com wrote: We are not a fork, never have been. How is it _not_ a fork? CLFS has different goals, a different structure, runs on its own servers and contributes nothing (until 2 days ago) back to its supposed parent project, LFS. I see no other way to describe CLFS than a fork. Now, there's nothing wrong with being a fork. Tons of successful open source projects were spawned from forks. You and Ryan had different goals about what you wanted to do and weren't getting that back into LFS. So you took up stake elsewhere and everyone moved on. The only bad thing is the splintering of resources, but that was happening anyway. We can call CLFS whatever we want, but by typical open source project standards, it is definitely a fork. I don't intend that as bashing in any way and admire what you guys have done. Really. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS antics
On Wed, Dec 24, 2008 at 12:58 AM, Greg Schafer gscha...@zip.com.au wrote: If the LFS project had any kind of leadership with any kind of backbone, there'd be serious consequences for this kind of divisive behavior. While I agree with your sentiments about Cross LFS creating a native book, what could the LFS leaders really do? CLFS forked a long time ago. Nobody can tell them what they can and can't do. That ship has sailed. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Freeglut requires GL/gl*.h
On Mon, Dec 15, 2008 at 1:21 PM, Matthew Burgess matt...@linuxfromscratch.org wrote: Hi all. I'm running through an Xorg-7.4 build, but have hit a problem. Firstly, there's a slight inconsistency: The Xorg Apps page says that MesaGlut is recommended. But, visiting the MesaGlut page suggests that FreeGlut is recommended, due to licensing issues with MesaGlut. I'm pretty sure BLFS has it backwards. No one really works on either of the GLUTs, but Mesa's has the troublesome license. I'm pretty sure all the distros use FreeGLUT. Now, FreeGlut states that it is dependent on the entire 'X Window System', but that won't be completed for some 7 packages (plus deps), which includes the apps, fonts, and drivers, all fairly substantially sized. Ignoring that advice completely (hey, it's my distro, I get to keep all the broken pieces!), I decided to compile it immediately after xbitmaps-1.0.1. This results in: error: GL/gl.h: No such file or directory error: GL/glu.h: No such file or directory error: GL/glx.h: No such file or directory FreeGLUT depends on the GL implementation, which is Mesa. So, you'd have to install Mesa then FreeGLUT. FWIW, nothing else in the Xorg stack uses GLUT, so you can definitely postpone FreeGLUT until later. The GL headers come from Mesa. Does anyone have any info on what, exactly, Freeglut requires? My initial googling suggests that Xorg Drivers will provide GL/gl*.h, but does that then mean I need to rebuild the whole lot again, or just the Xorg Apps? GLUT is the GL Utility Toolkit. It's just convenience utilities on top of GL which makes developing GL applications easier (apparently). There are a couple free implementations available: Mesa's GLUT with the troublesome license, or FreeGLUT, which was started to address this license problem (I think). -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xkeyboard-config and intltool
On Tue, Dec 2, 2008 at 9:28 AM, Jeremy Huntwork [EMAIL PROTECTED] wrote: Hi, I see on the xkeyboard-config page that intltool is listed as an optional dependency, but if I try building the current instructions as is without intltool, I get the following configure error: checking for intltool = 0.30... ./configure: line 3519: intltool-update: command not found found configure: error: Your intltool is too old. You need intltool 0.30 or later. make[2]: *** [compile-stage2] Error 1 Can anyone confirm or deny this? Wow, the autoconf macros for newer intltool have been totally changed. Now you actually need intltool to be installed. That's pretty unfortunate: http://bugzilla.gnome.org/show_bug.cgi?id=490620 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg-server and pixman
On Tue, Dec 2, 2008 at 11:35 AM, Jeremy Huntwork [EMAIL PROTECTED] wrote: Hello, I know there has been a lot of discussion on Xorg lately, so sorry if this is bringing up a known issue, but xorg-server also appears to require pixman now. The instructions in BLFS svn break for me at xorg-server because pixman is missing. If I build and install pixman as per the instructions in the Xorg Libraries section, then xorg-server builds fine. Should be enough to just add the file name of the latest pixman file to the lib wget file. Yeah, pixman is now required for both the xserver and cairo. I thought DJ added it, but maybe I'm just guessing. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Aiming for 7.0
On Tue, Dec 2, 2008 at 9:10 AM, Matthew Burgess [EMAIL PROTECTED] wrote: On Tue, 02 Dec 2008 05:07:25 -0500, Jeremy Huntwork [EMAIL PROTECTED] wrote: Anything else? Ticket #2284 - radical plan would be to just drop udev-config completely, then any reported issues should be passed upstream and fixed there. I really don't see anything special about LFS that means it should have to customise Udev beyond upstream's default config :-) I think this would be nice. With recent udev, all the changes (except for Bryan's documentation) could be easily contained in a small patch. That would be doubly useful when you just want to know how does LFS' udev differ from upstream. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: perl-5.10.0
On Tue, Oct 28, 2008 at 8:32 PM, Bruce Dubbs [EMAIL PROTECTED] wrote:
I'm puzzling over two tickets concerning perl: 2071 and 2227
It looks like 2071 says that we need to add -Dvendorprefix=/usr to the
configuration process, but configure.gnu doesn't support it.
Dan mentions that he uses:
sh ./Configure -des \
-Dprefix=/usr \
-Dsiteprefix=/usr \
-Dvendorprefix=/usr \
-Doptimize=${CFLAGS} \
${LDFLAGS:+-Dldflags=$LDFLAGS} \
-Dscriptdir=/usr/bin \
-Dman1dir=/usr/share/man/man1 \
-Dman3dir=/usr/share/man/man3pm \
-Dhtml1dir=/usr/share/doc/perl5/html1 \
-Dhtml3dir=/usr/share/doc/perl5/html3 \
-Dpager=/usr/bin/less -isR \
-Dmyhostname=localhost \
[EMAIL PROTECTED]
Are there any comments about this? Should I just drop in these instructions?
Yeah, configure.gnu only supports a limited set of options. If you
look at what configure.gnu does, it just translates --prefix
(autotools style) and a few others to -D Configure style and then runs
it with -d -e -s (-des getopt style).
So, first thing is, I'd suggest just running `./Configure -des' (looks
like perl-5.10.0 makes Configure executable) instead of using the poor
compat interface configure.gnu. Just my opinion, but Configure
supports the full range of perl build options, and I think we can
understand -Dprefix vs. --prefix. The other big advantage of using
Configure is that using configure.gnu triggered some sort of caching
that had caused issues with people rerunning the command. Not sure if
that's an issue anymore.
I wouldn't suggest hauling in all the options I listed above. Just
-Dvendorprefix=/usr is good enough for this ticket. But I'll just
quickly explain what the others do.
-Dsiteprefix=/usr: not necessary since it defaults to prefix, but I
just wanted to be clear since I'm also setting prefix and vendorprefix
-Doptimize: set the CFLAGS you want; not appropriate for vanilla LFS
-Dscriptdir=/usr/bin: this is where public executables go. I don't
know exactly what that means, but the default goes looking for
directories like /usr/share/scripts and /usr/share/bin. I just wanted
to make it consistent.
-Dman3dir=/usr/share/man/man3pm: I'd given man an extra 3pm section to
search so I could keep perl module documentation away from library
documenation
-Dhtml1dir/html3dir: These are normally unset, but they define
directories to put HTML documentation. I don't remember if they
actually do much.
-Dmyhostname/-Dperladmin: These default to `hostname` and
[EMAIL PROTECTED] Since the machine and user for the build aren't
relevant for me, I just set them to generic names.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: ICA/Farce
On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer [EMAIL PROTECTED] wrote: I've never looked at jhalfs but I understand it implements my ICA algorithms. My own scripts have been getting exceptionally clean results lately now that the randomness in GCC builds has apparently gone as of GCC 4.3. I'll happily check any results you can post up. I'm obviously out of the loop on building toolchains, but the most recent ICA issues with gcc was that a checksum of the .o files was built into the gcc binary. Since DIY uses LDFLAGS=-s, the .o files are stripped as they're linked. The checksum for the .o files is then always the same since the debug symbols are gone when the checksum is taken. In LFS, the stripping is always done after the fact, but by then the checksum has been built into the binary. But, that was a couple releases ago. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA/Farce
On Mon, Oct 27, 2008 at 2:59 AM, TheOldFellow [EMAIL PROTECTED] wrote: What I meant to say was that I, for one, would be grateful for any additional documentation of the subject. It's pretty straightforward, although I might butcher some of the terminology. The main goal is to see if the bootstrapping introduces any differences in the build. So, you want to compare the boostrapped build to a build that has been done against a totally in-place system. Actually, as Greg says, the best results come from using 3 builds - then you can see whether any differences are repeatable. So, you have: Build 1: Bootstrapped against /tools Build 2: Built against in-place bootstrapped system Build 3: Built against in-place system After Build 3, there's no reason to keep building since it would just be the same as the 2 - 3 build. Using 2 builds is useful if you know what you're looking for, but 3 builds truly ensures that you don't get false positives in the diffs. The actual implementation mostly involves preparing to diff/cmp, and is probably better explained by the comments in gsbuild. Look at the bottom of the functions file for do_ica_prep() and do_ica_work(). http://cvs.diy-linux.org/index.cgi/gsbuild/common-sh.functions?rev=HEADcontent-type=text/vnd.viewcvs-markup -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA/Farce
On Mon, Oct 27, 2008 at 7:57 AM, Gilles Espinasse [EMAIL PROTECTED] wrote: Instead to gunzip all .gz files, would it not better to submit patches that add -n when gzip run so the files in use will really be the same? I should say I have made some patches like that but have not reported because it was against old version and not current version of packages. I suppose you could. And how do you handle binary files that include a building timestamp string (like libc and perl)? Normally, those packages always differ because of the time string include. I have made hack patches removing timestamps on libc, perl and a few other packages. But I suspect my hack have no chance to be accepted upstream (maybe except the gzip -n changes). http://ipcop.cvs.sourceforge.net/viewvc/ipcop/ipcop/src/patches/glibc-2.3.3_notimestamp.patch?revision=1.1.2.1view=markuppathrev=IPCOP_v1_4_0 http://ipcop.cvs.sourceforge.net/viewvc/ipcop/ipcop/src/patches/perl-5.8.5-notimestamp.patch?view=logpathrev=IPCOP_v1_4_0 Right. I was doing the same when I was doing ICA regularly. Something like sed -i -e 's/__TIME__/now/' -e 's/__DATE__/today/' But then you start introducing changes to programs just for your own profiling. Usually, you just look at the textual diff and see if the difference is just due to a date/timestamp. In farce, Ken had some functions that would skip these stamps, but I don't recall how he implemented that. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg-7.4
On Sat, Oct 18, 2008 at 12:03 PM, DJ Lucas [EMAIL PROTECTED] wrote: xf86-video-intel is probably a big problem. It fails specifically because of changes in libdrm. Hopefully 2.4.3 is out soon. I haven't investigated the others because I do not even know what they are. Ah, you're treading into new kernel memory manager (GEM) territory. There are a bunch of new userspace APIs for the intel memory manager to allow for some of the graphics operations to be done in the kernel (amongst other things). I would expect another intel driver to be released to accommodate the API changes released just last week in libdrm-2.4.0. On the other hand, unless you're using Eric Anholt's drm-intel-next kernel tree, none of the kernel interfaces are actually there to make the new libdrm release useful. These have been proposed for linux-2.6.28, but I don't think they've been merged yet. So, sticking with libdrm-2.3.1 for now is definitely the safe option. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg-7.4
On Sun, Oct 19, 2008 at 4:38 PM, Nathan Coulson [EMAIL PROTECTED] wrote: oh, btw pre Xorg 7.4, there was the dri2 stuff. That was removed before releasing Xorg 7.4. Mesa 3d 7.1 used dri2, while Mesa 7.2 had that removed. The dri2 stuff was dependent on the TTM memory manager, which is gone in favor of GEM now, and that's why it got disabled in xorg-server-1.5.x/mesa-7.2.x. It will be back soon as it solves a lot of the DRI issues. I wouldn't expect to see it stabilized until Xorg-7.5, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Teminal issues in -dev
On Thu, Oct 16, 2008 at 8:16 AM, Jeremy Huntwork [EMAIL PROTECTED] wrote: The real issue is that the --bind mount of /dev is unmounted as are /proc and /sys. (BTW, this issue would also affect any attempt to use the grub installed in chroot, since that needs the devices corresponding to your HDs available.) So maybe the better option is to allow a user to specify if they don't want those filesystem's unmounted. Of course you'd have to include proper warnings at the end of the build or such... What I was thinking is just to add a couple make targets for this case: devices: mount -v --bind /dev $(LFS)/dev mount -vt devpts devpts $(LFS)/dev/pts mount -vt tmpfs shm $(LFS)/dev/shm mount -vt proc proc $(LFS)/proc mount -vt sysfs sysfs $(LFS)/sys teardown: umount -v $(LFS)/dev/pts umount -v $(LFS)/dev/shm umount -v $(LFS)/proc umount -v $(LFS)/sys chroot: devices chroot $(LFS) /tools/bin/env -i \ HOME=/root TERM=$TERM PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /tools/bin/bash --login $(MAKE) teardown At the end of the build, a message could be output: Done building packages. To continue preparing the system as described in Chapter 7, run: make chroot Or whatever (I suck at UI). Those targets would probably need to be made more robust (and handle gaining root privilege), but you get the idea. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.8-20080929 build fails in Chapter 5
On Wed, Oct 15, 2008 at 11:58 AM, Robert Connolly [EMAIL PROTECTED] wrote: --disable-libssp in GCC pass1 is best. Last time I looked at the test in gcc/configure, it checks /usr/include/features.h for the Glibc version. So you will probably need --disable-libssp in GCC pass2 too, because gcc/configure is going to check your host again, and you'll run into the same conflict in the chroot. --disable-libssp prevents libssp from being built, and removes -lssp from gcc specs, so -fstack-protector will only work if you have libssp built in to libc. Alternatively, you can skip the check by setting the cache value: gcc_cv_libc_provides_ssp=yes/no http://gcc.gnu.org/viewcvs/branches/gcc-4_3-branch/gcc/configure.ac?view=markup This shows that it will set the glibc header dir to /usr/include and search for features.h there unless you use --with-sysroot. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Teminal issues in -dev
On Wed, Oct 15, 2008 at 3:10 PM, Bruce Dubbs [EMAIL PROTECTED] wrote: After jhalfs completed, I followed the instructions to chroot and set the root passwd. I used: /usr/sbin/chroot $LFS /usr/bin/env -i \ HOME=/root TERM=linux PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /bin/bash --login It's been a while and I don't remember -- The login is in / and not /root. IS that normal? Yes. `/bin/bash --login' doesn't change the directory, and when it's run, the current directory is / (in the chroot). A session manager like login, ssh or a display manager specifically do this for you. Try looking at the cwd symlink in /proc/$pid for your session leader process. I can't use less or passwd. less displays the file and immediately terminates. passwd gives: # passwd Changing password for root Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. Bad password: too short. Warning: weak password (enter it again to use it anyway). Password changed. You need devices, specifically /dev/tty for passwd (see getpass(3)). jhalfs tears down the chroot when it's done, and the only way to get it back is to do it manually like in the book. This has come up a bunch of times in the past. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Chapter 6 Coreutils installation
On Sun, Oct 12, 2008 at 9:34 AM, Randy McMurchy
[EMAIL PROTECTED] wrote:
Robert Connolly wrote these words on 10/12/08 11:27 CST:
There may not be a technical reason for installing Coreutils early, just that
it's one of the most heavily used packages.
I know there was much work put into rearranging the build order of
the various packages so that as much as possible would be built in
alphabetical order.
I'm trying to figure out why the binaries in /tools/{,s}bin wouldn't
work. I'm sure there's a good reason, I'd just like to know what it
is. :-)
Same with the Sed package, why couldn't /tools/bin/sed be adequate
until Sed is built in Chapter 6?
Usually the reason is because the path to the tools gets built into
another script/program. In the dependencies appendix, it says that sed
must be built before e2fsprogs. I think it's mk_cmds that hardcodes
the location of sed, but that's just a guess.
I think coreutils must be built before bash because of something that
gets substituted into bashbug.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Chapter 6 Coreutils installation
On Sun, Oct 12, 2008 at 9:56 AM, Randy McMurchy [EMAIL PROTECTED] wrote: Dan Nicholson wrote these words on 10/12/08 11:46 CST: Usually the reason is because the path to the tools gets built into another script/program. In the dependencies appendix, it says that sed must be built before e2fsprogs. I think it's mk_cmds that hardcodes the location of sed, but that's just a guess. I think coreutils must be built before bash because of something that gets substituted into bashbug. I was out at the barn feeding the animals and I thought the same exact thing. That some *broken* packages have hard-coded paths to /usr. But it's been a long time since we alphabetized the installation and almost every package has been updated since. I wonder if that brokenness has been fixed. Worth a jhalfs try to see if we can move coreutils and sed into alphabetic order. If it's an autotooled package, you can usually figure it out pretty fast in the package. Looking at e2fsprogs, I see AC_PATH_PROG(SED, sed, sed) in configure.in. So, it's going to subsitute for values of @[EMAIL PROTECTED] grep points to: ./lib/ss/mk_cmds.sh.in:[EMAIL PROTECTED]@ So, you can probably knock that one out with: sed -i 's,@SED@,/bin/sed,' lib/ss/mk_cmds.sh.in Or just drop the /bin and let sed be found from PATH. Repeat for file, libtool, and shadow. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev Rules
On Sun, Oct 12, 2008 at 6:44 PM, Randy McMurchy [EMAIL PROTECTED] wrote: DJ Lucas wrote: Sorry...already reopened as I didn't see Bruce's comment about closing it. Closed it again. Well anyway, Dan posted a link to the conversation upstream. http://thread.gmane.org/gmane.linux.hotplug.devel/12895 Bottom line, it is still left to opinion for now. However, I too am leaning towards /lib/udev/rules.d myself for both rule sets. Taken from the README: Count me as sitting on the fence with no preference. If anything, I lean to going with what the maintainers prefer. If the rules are not meant to be edited, then I'm indifferent. A lot of them are really not meant to be edited by systems administrators even. Take the libusb rule: exposing it as configuration only opens you up to breaking your system. And the nice thing with this separation is that you can still use /etc/udev/rules.d if you find something you want to tweak like group settings or permissions or an extra symlink. One of the big drivers of that change is that DeviceKit (the next generation HAL) will just merge all it's rules in with udev. So instead of having the whole FDI file setup like now, DeviceKit will put all its rules (analogous to the hal-info tarball) into /lib/udev/rules.d and piggyback off of udev. Right now, HAL recreates a lot of what udev is already doing, so the developers are aiming for a much tighter integration between the two systems. Count my vote to whatever the majority agrees upon. We can always open the ticket again. But discussion should occur here, and not in -book. One thing brought up in the hotplug thread by Scott James Remnant (one of the Ubuntu developers) is the question of why these non-configurable defaults aren't just set in the kernel. I think that's a very valid question, but for now we just sort of rely on udev setting up a sane /dev that applications expect. But I'm probably in the same camp where it's not that important to me. If people feel strongly that they want to keep all the rules in /etc/udev/rules.d, I don't really mind. Here's me, sitting on the fence, leaning towards Kay Seivers (sp?). Sievers. :) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: iana-etc with STRIP=yes
On Tue, Oct 7, 2008 at 8:54 AM, Randy McMurchy
[EMAIL PROTECTED] wrote:
Valter Douglas Lisbôa Jr. wrote:
Not a major issue, but a recent thread shows using the make STRIP=yes on
iana-etc to cut out comments and accelerate the port search on port
resolution. In the new LSF does anyone remember to put this on the book?
Not sure about the accelerate the port search on port resolution.
Here's a quote from Seth's (the maintainer) site:
To throw out the useful comments in generated files (useful for embedded
installations), use:
make STRIP=yes
He doesn't mention anything about acceleration. He says it's
useful for embedded systems. Do you have a URL of this thread?
Whenever you do a getservbyname(), the glibc resolver has to parse out
/etc/services. This happens when you use http, and the resolver has
to decide what port number to use. Likewise, when some program
specifies tcp, the glibc resolver has to parse /etc/protocols to
decide what protocol number that corresponds to. So, cutting out the
comments just makes the parsing faster. I saw a discussion of this a
while ago on a fedora list, but I can't find the link now.
You can test this yourself with getent and then try again with a
stripped down /etc/services (I didn't bother).
$ time { for ((n = 0; n 100; n++)); do getent services http
/dev/null; done; }
real0m0.098s
user0m0.033s
sys 0m0.065s
I happen to think the comments are more beneficial than any speedup,
but that's just my preference.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: iana-etc with STRIP=yes
On Tue, Oct 7, 2008 at 9:28 AM, Gilles Espinasse [EMAIL PROTECTED] wrote: Worst case for the search is with a protocol that is not in the file. I don't know what happen when resolution fail. Any idea? It returns an error and stops? I can't imagine what else it could do if it didn't know about the service. $ getent services barf $ echo $? 2 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: iana-etc with STRIP=yes
On Tue, Oct 7, 2008 at 9:40 AM, Jeremy Huntwork [EMAIL PROTECTED] wrote: Dan Nicholson wrote: $ getent services barf $ echo $? 2 You mean you don't have the barf service on your system? I thought that was pretty standard... :) barf is my standard make this program fail input. I've yet to come across any conflicts with that assumption. :) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
On Mon, Oct 6, 2008 at 8:55 AM, Jeremy Huntwork [EMAIL PROTECTED] wrote: Philipp Christian Loewner wrote: From what I understand about it, building GMP and MPFR as separate packages is the preferred method, but the bootstrap build will fail to locate these programs in the /tools directory in the first stage. Hmmm. I read through that thread already, but I didn't see any reasoning for why the current approach. I don't know why installing them as separate packages is preferable. Some things to consider: * Only GCC needs them. Just for the record, I know guile can use an external libgmp: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820 Google shows that clamav and openswan use it, too. I don't know if that's compelling enough, but I thought it should be known. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 64bit - thoughts
On Wed, Oct 1, 2008 at 7:44 PM, DJ Lucas [EMAIL PROTECTED] wrote:
From what I've seen of it, I guess there is no concept of
{,/usr}/{,s}bin64 or /usr/include64 like there is for the lib dirs (or
the alternate). I mean a total separation of the system, side by side
would be ideal IMO.
I think a lot of people are confused about multiarch systems in this
sense. The purpose of multiarch is not to have multiple parallel
systems targeted for different architectures running natively on a
single machine. The purpose of multiarch is to allow execution of code
targeted for different architectures. It serves no purpose to have an
executable targetting both x86 and x86_64 on the same machine. The
idea being that when you run `grep', it doesn't matter if it's 64 bits
or not. Obviously, there are some programs that will behave
differently depending on the target architecture, like compilers and
other build tools. These are special cases, though.
On the other hand, to allow code for multiple architectures to be
executed, you do need parallel installation of libraries/start
files/linkers targeted to each architecture. This is why we have
/lib64 and not /bin64. In order for me to build and execute an xterm
for either x86 or x86_64, I'll need toolchain and library support from
libc through Xlib and friends in both */lib and */lib64. However, once
I've built xterm, I don't care what architecture it is as long as I
can execute it.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS 64bit - thoughts
On Thu, Oct 2, 2008 at 8:47 AM, Ken Moffat [EMAIL PROTECTED] wrote: On Wed, Oct 01, 2008 at 09:44:51PM -0500, DJ Lucas wrote: I can't really add a lot here as I haven't tried it yet. I think pure-64 is ideal, but from what little I've looked into it, that is just not possible.yet, not to mention that it breaks the LSB goal. Maybe not possible for your particular use case. I've been using pure64 on one of my boxes for a long time. (No proprietary plugins - I've long since dropped realplayer, flash either works with gnash (usually, old flash) or it's no loss to me, and I don't need to access other proprietary formats.) On ppc64 I do stick with multilib, because the box performs like a dog, and compiling 32-bit ppc is sometimes less difficult than 64-bit (a mac G5 has to have a 64-bit kernel). Ken has it exactly right. Since you're making a custom system, it's entirely up to you whether it's worth supporting multiple architectures. The LSB, on the other hand, is trying to foster a standard environment for people to target Linux applications to. Multiarch makes that standard environment more flexible. Whether you want your custom system to support this flexibility is entirely up to you and will most likely be influenced by whether you find it necessary to support 3rd party binaries that only target a specific architecture. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
initd-tools-0.1.1
Hi, This is the initial announcement for the initd-tools project. It aims to implement the install_initd and remove_initd programs described in the LSB 3.2: http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html The implementation aims for a SysV initialization scheme using the /etc/rc*.d directories. More information can be found on the webpage: http://www.dwcab.com/projects/initd-tools/ This also serves as the release announcement for version 0.1.1. http://www.dwcab.com/downloads/initd-tools/initd-tools-0.1.1.tar.gz MD5: fc2d08377f40ebfa54c9bbbc175ec21c initd-tools-0.1.1.tar.gz It mostly seems to be working, but there is still a bug in the Should-Stop code as well as many other bugs that probably have not been uncovered in my limited testing. Please use with caution and backup your /etc/init.d and /etc/rc*.d directories before using install_initd and remove_initd. Let me know if you have any interest or issues with the code. For now, you can just email me about it at this address. If there's enough interest, we can try to set up a mailing list and bug tracker. Enjoy! -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: DJ's gcc-4.3.1 book
On Sun, Aug 31, 2008 at 10:31 AM, TheOldFellow [EMAIL PROTECTED] wrote: Just a progress report. Nothing much to say though, it seems solid as a rock. I've been running Apache/PHP/MySQL/Joomla on it all week - zero-issues. Today I built Xorg7-almost7.4 using the very latest stuff that seems to work OK, including Mesa-7.1 and Xorg-Server-1.4.00.906, everything compiled and runs fine (except the bits I screwed up). Fluxbox-1.0.0 needs a patch to account for the GCC cleanup of where headers go. Did you try the new mesa ./configure support? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cp foo{,.bak} not always supported
On Mon, Jun 2, 2008 at 12:29 AM, Alexander E. Patrakov
[EMAIL PROTECTED] wrote:
2008/6/1, Gilles Espinasse [EMAIL PROTECTED]:
cp configure{,.bak}
cp: missing destination file operand after `configure{,.bak}'
Try `cp --help' for more information.
This simply can't happen if the user follows the book to the letter.
Look at
http://www.linuxfromscratch.org/lfs/view/development/chapter04/addinguser.html:
useradd -s /bin/bash -g lfs -m -k /dev/null lfs
See bash here? On the next page, /bin/bash is also explicitly called
in ~/.bash_profile.
So: the bug report is invalid.
+1
Guys, please remember the difference between running commands
interactively (using the _login_ shell, which we, and Ubuntu, set to
/bin/bash) and executing a shell script with the /bin/sh interpreter.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Moving 'setclock' to earlier in the boot sequence
On Tue, May 27, 2008 at 12:10 PM, Nathan Coulson [EMAIL PROTECTED] wrote: On Sun, May 25, 2008 at 8:07 PM, Gerard Beekmans [EMAIL PROTECTED] wrote: Please see http://wiki.linuxfromscratch.org/lfs/ticket/2160 The ticket is about a potential issue with bootscripts and from it came a suggestion to move the setclock call to earlier in the sequence. It would help to address the issue but also having the system clock set accurately earlier is good for other things. Is there any reason why we wouldn't want the system clock set properly using the 'setclock' script right after modules are loaded and udev is setup? If there are no technical objections this will become a new Trac ticket. Gerard Dependencies: -The setclock script depends on /etc/sysconfig/clock, and possibly the udev system being loaded. I think setclock has to come after udev for /dev/rtc. From hwclock(8): hwclock Uses many different ways to get and set Hardware Clock values. The most normal way is to do I/O to the device special file /dev/rtc, which is presumed to be driven by the rtc device driver. However, this method is not always available. Problem: We wish to address the issue of cleanfs not doing it's job, preferrably by checking against the mounting date of /proc. Resolution Suggestion: -I was taking a closer look at this issue, and I think moving it before mountkernfs would be an ideal time. I dont recall if setclock needed a devicenode or not, but I cant see any reason why we cant add a static devicenode for this. This is where we mount /proc, and that is what cleanfs decides to check against. Impact: - possible creation of a static devicenode. I think it's always the right thing to get the kernel file systems mounted, modules loaded and devices created as soon as possible. I don't believe the cleanfs issue is important enough to merit wedging the setclock script in front of those steps. I'd personally rather change cleanfs to operate in a different way that's independent of those 3 services. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving 'setclock' to earlier in the boot sequence
On Tue, May 27, 2008 at 1:04 PM, Gerard Beekmans [EMAIL PROTECTED] wrote: I think it's always the right thing to get the kernel file systems mounted, modules loaded and devices created as soon as possible. I don't believe the cleanfs issue is important enough to merit wedging the setclock script in front of those steps. I'd personally rather change cleanfs to operate in a different way that's independent of those 3 services. Look at it this way as well. If you wanted to keep track of boot logs and whatnot with timestamps, they are pretty useless if the time is wrong. Of course there's the argument that you then will want to sync with an NTP server as well while you're at it. However, to at least set the CMOS clock to proper time (with timezone conversion if needed), is a step up to get the boot logging a bit more accurate. But syslogd is started well after setclock. Furthermore, /var is not guaranteed to be writable until after mountfs runs, which is after setclock, too. So, logging should be fine now and with any of the proposed changes. Unless you mean something else by boot logging. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
On Wed, May 21, 2008 at 9:00 PM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Gerard Beekmans wrote: So to summarize simply using the %configure macro won't run it like we'd want the configure script to be run. Yeah. %configure would do a lot more than ./configure. Not that that's a bad thing, but it creates a difference between the two scenarios and could lead to one person having the package working correctly and one not. Can't it be overridden or introduce our own %configure-like macro that does run things like the book does? You can override all the macros or not use them at all. Why not just say somewhere on the PM page that we don't use the %configure and similar macros in our spec files (and call ./configure directly instead) because we want 100% correspondence between commands in no-PM and RPM versions of LFS? Right, that's why I was saying you'd probably want to minimize the macro usage in general. However, from the perspective of someone using RPM, I really want to use the macros. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
On Wed, May 21, 2008 at 9:11 PM, Bruce Dubbs [EMAIL PROTECTED] wrote: Gerard Beekmans wrote: for any bog standard autotooled package: %configure Looks simple enough: it runs ./configure for you. However, there's a So to summarize simply using the %configure macro won't run it like we'd want the configure script to be run. Can't it be overridden or introduce our own %configure-like macro that does run things like the book does? I guess I don't understand. Are we going to create a source RPM for every package and then install from that? I didn't think that was our intention. This seems to be the knotty problem. Just how are we going to *use* PM in LFS? If you're a non-PM person, you create a script from the commands in the book. If you're a PM person, you create a spec file or rules file or whatever else is the input format to your package manager. I don't think we want to get in the business of distributing any of the PM outputs. Just that we provide all the necessary inputs. For an RPM, that's sources and a spec file. For something simple like tar-based, it's just sources and a script. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
On Sun, May 18, 2008 at 6:54 PM, Gerard Beekmans [EMAIL PROTECTED] wrote: Dan, you have done a lot of work with RPM spec files for LFS. Is there anything you wish to add to what Alexander said back then and your own reply to it? Alexander may have said this, but one thing to keep in mind is that once you start writing RPM specs, you really want to start using the macros that come with RPM (or that you write yourself). For example, for any bog standard autotooled package: %configure Looks simple enough: it runs ./configure for you. However, there's a lot of extra arguments passed such as setting --prefix to the default compiled in %_prefix value (usually /usr) and passing --host and --build to set the architecture you want. It also exports the CFLAGS as configured in the macros. This is great for consistency when you're doing everything in RPM. For LFS, though, this could cause inconsistencies between the RPM and non-RPM instructions. You can take the approach that macro usage will be minimized, but then you lose some of the power of RPM. All in all, though, I think it could work. There is a lot of power that comes out of the box with RPM (e.g., it will glean requirements for the binaries automatically). You'd need to be careful that the PM'd versions of the packages don't stray from the regular commands too much. But I don't think that thought is constrained to RPM. For the case of RPM, I think you'd want to cripple it a bit until all the issues are ironed out. But it should be pretty easy to do that in the global configuration. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap (Was: Re: As promised: LFS compilation summary)
On Thu, May 8, 2008 at 6:52 PM, Jeremy Huntwork [EMAIL PROTECTED] wrote: I think that the prevailing attitude here is rather anti GRUB2. Mostly because development on it seems to focus on items perceived as useless and bloat for a boot loader. I haven't piped in on this at all, but I'd just like to say that I really, really want to be pro-grub2. I periodically peruse the grub-devel archives hoping to see that a 2.0 release is imminent. I find it ridiculous that there's no currently supported grub. But, anyway, I'm still x86 all the time, so grub-0.9.7 is good enough for me. I'll be curious how this plays out, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
On Tue, Apr 29, 2008 at 11:51 PM, Jeremy Huntwork [EMAIL PROTECTED] wrote: Hello, So I finally got a free evening and the energy to sit down and get conceptual. This is the result: http://linuxfromscratch.org/~jhuntwork/php-test/ That's awesome! My only concern with the multiple paths is with duplicating changes. Like, you found a typo in one of the commands and you have to change it in 4 spots. But I'd take that tradeoff here for the gain in coolness. :) -- Dan P.S. Sorry for not helping you with this. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
On Wed, Apr 30, 2008 at 2:13 AM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Jeremy Huntwork wrote: Hello, So I finally got a free evening and the energy to sit down and get conceptual. This is the result: http://linuxfromscratch.org/~jhuntwork/php-test/ Before replying about all that you see is wrong with it ;) keep the following in mind: This is a rough draft! A proof-of-concept only, designed to show possibilities and open up discussion/ideas. Think stick-figure. Glibc is not the best example for discussion. I requested such sample page for bash, not for glibc, for a reason: bash needs a specific patch in the RPM case, and I don't see the way to force such PM-specific instructions in the current framework. Although even for glibc, there is something to discuss: There are definitely always going to be improvements made on the package management side relative to the simple LFS commands. Let's not let that derail the overall picture here. However... * making one big RPM package with both the shared library and its headers is technically incorrect (this is not so severe for glibc, but think about gradual updates from libssl.so.0.9.8 to libssl.so.0.9.9, and that's impossible without removing a lot of dependent packages if one doesn't package the conflicting headers in a separate RPM file); * the current framework doesn't allow for such split; I agree that there are major advantages to splitting the libraries out of the package, but why can't you just update the whole openssl package to get the library update? In fact, the -devel split you're talking about where the bare .so links and the headers are in a separate package wouldn't affect a library update in any way. In most cases, the .so.* links are part of the main package anyway (including openssl). * editors that don't use a package manager have to be taught about this. I think it would always be the case that some people aren't going to care about the package management side. The editors that _do_ use a package manager have to be responsible for keeping the pages maintained. If an option to use dpkg was added, I probably wouldn't spend any time looking at it, but I would expect that their would be interested people who would tweak instructions in the way that most benefits dpkg. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
On Wed, Apr 30, 2008 at 6:35 AM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Dan Nicholson wrote: I agree that there are major advantages to splitting the libraries out of the package, but why can't you just update the whole openssl package to get the library update? In fact, the -devel split you're talking about where the bare .so links and the headers are in a separate package wouldn't affect a library update in any way. In most cases, the .so.* links are part of the main package anyway (including openssl). Think about the way dependencies are expressed. The automatic dependnecy extractor says: package cryptofoo [that was built before openssl upgrade] depends on libssl.so.0.9.8 due to library dependencies. If you attempt to upgrade the whole openssl library to 0.9.9 (i.e. a binary incompatible release--that's important) without the split, the package manager will not be able to do this, because the new package does not provide libssl.so.0.9.8 and thus the cryptofoo package's dependencies are not satisfied with the new openssl package. I.e., with such incompatible upgrades, it is convenient to have the following installed during the transitions: old openssl dynamic libraries without the .so symlinks, new openssl dynamic libraries with the .so symlinks, new headers. You can't have all three at the same time without splitting the package (assuming that the package manager knows about file conflicts). I certainly agree that it's best to handle situations like that, but does RPM even support it? I.e., if I split off a libssl subpackage that just has libssl.so.0.9.8, would RPM even allow me to install a newer version of libssl in parallel without --force or something? I don't know much here, but it seems that Fedora is getting along fine without putting libraries in separate subpackages. On the other hand, I notice that Debian/Ubuntu always splits the libraries into separate packages. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS - DESTDIR Style (minor update)
On Sun, Apr 27, 2008 at 9:06 PM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Randy McMurchy wrote: Cc: to BLFS-Dev Alexander E. Patrakov wrote these words on 03/31/08 10:44 CST: Bruce Dubbs wrote: The implication of going to DESTDIR for LFS would imply doing the same for BLFS. Some of the BLFS packages are not DESTDIR friendly. I can't remember which ones off the top of my head, but I do recall some that ignore DESTDIR, at least partially. All perl modules. See http://linuxfromscratch.org/pipermail/lfs-dev/2007-December/060640.html This message is after-the-fact and not really relevant to the previous discussion. It is however, interesting. I just installed a Perl Module and not only was it native DESTDIR friendly and multilib friendly, it installed files depending on the native arch of the machine. I cannot confirm this. Both with perl-5.8.8 and 5.10.0, the package installs files into the DESTDIR, but it installs wrong files. See the URL above, I can add nothing to what is already said there. If you insist on your point, please provide full command lines starting with perl Makefile.PL, and look into the .packlist and perllocal.pod inside the DESTDIR. This doesn't solve .packlist, but try: make DESTDIR=/somewhere pure_vendor_install That puts the module in vendor_lib and suppresses perllocal.pod. Or, `perl Makefile.pl INSTALLDIRS=vendor' and `make ... pure_install'. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: asm/page.h
On Tue, Apr 22, 2008 at 12:12 PM, Jeremy Huntwork [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 01:09:10PM -0600, Jeremy Huntwork wrote: I removed the line where it includes the header and Perl built successfully and all tests passed. This is also what Gentoo does: https://bugs.gentoo.org/show_bug.cgi?id=168312 However, there's likely a better and more robust solution. I haven't dug any deeper yet. Actually, removing the line may just be good enough. PAGE_SIZE doesn't really seem to be used anywhere relevant: grep PAGE_SIZE . -R ./ext/IPC/SysV/SysV.xs:/* Required in BSDI to get PAGE_SIZE definition for SHMLBA. ./os2/os2.c: PAGE_SIZE, ./os2/Changes: MAX_WAIT, MIN_SLICE, MAX_SLICE, PAGE_SIZE, ./pod/perl571delta.pod:For getpagesize(), though you should prefer POSIX::sysconf(_SC_PAGE_SIZE)) ./README.os2: MAX_WAIT, MIN_SLICE, MAX_SLICE, PAGE_SIZE, ./perlio.c:#if defined(HAS_SYSCONF) (defined(_SC_PAGESIZE) || defined(_SC_PAGE_SIZE)) ./perlio.c: page_size = sysconf(_SC_PAGE_SIZE); Cool. I guess it's just an extraneous #include in SysV.xs. Here's everything defined in my 2.6.22 asm/page.h (on x86): #define PAGE_SHIFT 12 #define PAGE_SIZE (1UL PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) #define LARGE_PAGE_MASK (~(LARGE_PAGE_SIZE-1)) #define LARGE_PAGE_SIZE (1UL PMD_SHIFT) So, I suppose you could grep for some regex (PAGE_(SHIFT|SIZE|MASK)) of those macros to be safe. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8518 - in trunk/BOOK: . chapter01 prologue
On Fri, Apr 11, 2008 at 11:49 PM, J. Greenlees [EMAIL PROTECTED] wrote: Dan Nicholson wrote: bash - Not needed for actual building, but glibc's ldd and tzselect need either bash or ksh to work. The values will be substituted at configure time. I don't know what happens without them, and it's probably not that important in Ch. 5 if those utilities aren't there. However, we create the LFS user with /bin/bash as the login shell, and this can't be substituted as is because we set up the environment through the bash initialization files. Yet another minor issue with PCLinuxOS as a build environment, the environment set up following the book is not a login shell. [ only mentioning it as a f.w.i.w. ] Sure it is. You switch to the lfs user with `su - lfs'. That creates a login shell using the shell listed in the passwd database. If PCLinuxOS' su doesn't follow that trend, I don't know if there's a lot we can do about that. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
On Thu, Apr 3, 2008 at 8:15 PM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Dan Nicholson wrote: You really need gawk, not mawk. Then please add gawk and bison in Chapter 5 before binutils, to accomodate Debian-based LiveCDs and PCLinuxOS, respectively. The host requirements specify _Gawk_ 3.0. I really would prefer people just check the host requirements instead of shoehorning temporary packages at the beginning of the chapter. For an automated environment, maybe, but it would just be clutter in the book. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
On Thu, Apr 3, 2008 at 11:51 PM, J. Greenlees [EMAIL PROTECTED] wrote: Alexander E. Patrakov wrote: Dan Nicholson wrote: You really need gawk, not mawk. Then please add gawk and bison in Chapter 5 before binutils, to accomodate Debian-based LiveCDs and PCLinuxOS, respectively. and here I was thinking that a note that bison is required to be installed if using PCLinuxOS as host would be sufficient. The distro does fine by adding their package. [ fewer changes to build process needed thn ] If anything, it would be a note at the beginning of Ch. 5 to please not skip the host system requirements page. I don't think we need to special case things here. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
On Fri, Apr 4, 2008 at 7:28 AM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Dan Nicholson wrote: On Thu, Apr 3, 2008 at 8:15 PM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Dan Nicholson wrote: You really need gawk, not mawk. Then please add gawk and bison in Chapter 5 before binutils, to accomodate Debian-based LiveCDs and PCLinuxOS, respectively. The host requirements specify _Gawk_ 3.0. I really would prefer people just check the host requirements instead of shoehorning temporary packages at the beginning of the chapter. For an automated environment, maybe, but it would just be clutter in the book. For a regular distro, I would agree. For a third-party LiveCD, I disagree. I still don't think instructions should be special for this situation. If you chose a host that doesn't provide the necessary development environment and doesn't provide the means to acquire the necessary environment, then that probably wasn't the best choice. Instead, I'd rather that the hostreqs page said If you're host doesn't contain the necessary requirements and doesn't provide a means to acquire them, see the instructions in Ch. 6 as a guide to building them. Today it's bison and gawk. Maybe tomorrow it's make or flex. The entire point of the Host System Requirements page is to establish a baseline from where to start. I don't think it's wise to start adding workarounds for that unless there's a really compelling reason. IMO, these are compelling enough reasons. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Upstream patches
On Wed, Apr 2, 2008 at 7:08 PM, DJ Lucas [EMAIL PROTECTED] wrote: Jeremy Huntwork wrote: Randy McMurchy wrote: Upstream is notorious for changing the patch content but not changing the name. And we don't see changes. This can only be a bad thing. There is nothing gained by changing the patch and calling it an LFS patch. This can only be a losing situation (upstream changes it, but we have no way of knowing it). As I mentioned in the Trac ticket, if they are in the habit of changing the patch without changing the name, and we link directly to them, essentially we open ourselves up to a situation where we link to an untested (by us) patch. At least if we make a snapshot of what they released, and we commit it after testing (as I did with this one) then we are working with a known patch. That is kind of a disturbing point about the way BLFS handles upstream patches. I've CC'd blfs-dev too. If the replacement patch is created with a different -P option, our instructions are broken. Also, what about the recent CRLF issues? These kinds of problems disappear if we host the patch in our own repository, excluding the unlikely event (or rather likely as history has proven) that an upstream patch is updated--which is just plain wrong anyway as they should have version numbers attached to them, or at very least, a date. Additionally, our testing is against a known version of the source. Another weak argument at best, but all other distributions maintain their own patch sets in their source packages. To be fair, the BDB patches are individual with version numbers, i.e. patch.4.5.20.1, patch.4.5.20.2, etc. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
On Thu, Apr 3, 2008 at 2:47 PM, Jeremy Huntwork [EMAIL PROTECTED] wrote: 'mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed (bad class -- [], [^] or [) /[^ mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ] mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, ,' Interesting. What is the host system you're using? I'm guessing it's Ubuntu. You really need gawk, not mawk. This came up on libc-alpha a few months ago, but Drepper wouldn't budge on making it more portable. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN Linux Headers Installation
On Wed, Mar 26, 2008 at 7:38 PM, Randy McMurchy [EMAIL PROTECTED] wrote: First of all, thanks to Dan for the cluebat about how gcc bootstraps by default now. I didn't know that. Perhaps it could be mentioned. I was thinking that if you're reading the book for the first time, then having a conversation about why you're not running make bootstrap would be out of place. But there are probably enough old timers reading the book that they have the context where not seeing make bootstrap is odd. I could go either way. However, I've noted the following commands (they've probably always been there, just never bothered to noticed) in the Linux Headers installation (both Chapter 5 and 6): make mrproper make headers_check make INSTALL_HDR_PATH=dest headers_install Throughout the boot, every command is described in detail as to what it does. None of these 3 commands is even mentioned as to what it does (both Chapters 5 and 6). For instance, I've been following LFS for a long time, but this is the first time I've seen the INSTALL_HDR_PATH=dest in the book. I don't have a clue what it does, and still don't after doing it. Just have to blindly follow along, without any knowledge of what I just did. Granted it should be a given that the API headers are being installed, but folks should be given a chance to understand the commands. Yeah, the kernel headers don't install as smoothly as other packages. When you run make headers_install, it first removes $(INSTALL_HDR_PATH)/include, not what you would want if INSTALL_HDR_PATH=/usr and you have other headers there. That could definitely use an explanation. For make mrproper, that could probably offloaded with a pointer to Ch. 8.3 where it's explained for the kernel. make headers_check is the testsuite, but also encompasses headers_install. I think you can drop it and go straight to headers_install, but I seem to remember that it does some other important things, too. It's very possible that it could just be treated as the optional testsuite command. I opened ticket #2167 to track this. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: man_db.conf in /usr/etc
On Sun, Mar 30, 2008 at 5:16 AM, Bryan Kadzban
[EMAIL PROTECTED] wrote:
It looks like mandb is sticking the configuration file in the /usr
folder.
Without looking at man-db's configury, I'd assume that it would fix it
if we simply set --sysconfdir=/etc? If it's that simple, I'm all for it.
I looked yesterday, the fix is as simple as --sysconfdir=/etc. I just
forgot to respond. Basically, there's a --with-config-file option now
that defaults to ${sysconfdir}/man_db.conf.
Fixing it now...
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-SVN: 6.45. Man-DB-2.5.1
On Sat, Mar 29, 2008 at 4:17 AM, George [EMAIL PROTECTED] wrote: Hi Posting this to the dev list as it isn't really a breakage. After building man-db.2.5.1 folowing the SVN version of the LFS book, I notice that man_db.conf is being installed to /usr/etc instead of /etc. Checking against my only previous LFS build (6.2 stable) I find that man_db.conf is in /etc on that box. (But, as I didn't keep notes on the LFS part of the install I can't say for sure if that was down to the build, or me adding a --sysconfdir=/etc and just not remembering...) It looks like they made it configurable in the new release, so you just need to pass --sysconfdir=/etc. Thanks. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Wed, Mar 19, 2008 at 11:52 AM, J. Greenlees [EMAIL PROTECTED] wrote: With the LSB: Why would a BASE standrd not stop at the absolute minimum needed for a functioning system? The addition of package management [ for example ] to the LSB has made in no longer a BASE standard. If extras are going to be included, then call it a Linux DISTRO Standard, not a Base Standard. [ I for one ignore the LSB because it is not what it claims to be, a BASE for Linux.] LFS and DIY are much closer to being a base in the lack of extra software. This isn't a proper channel for an LSB discussion, but the entire purpose of the LSB is to allow third parties to create software packages for standard Linux systems. Where LFS and DIY stop are far too minimal for this purpose. For example, how would it be possible for Google to package Picasa for Linux if all that was guaranteed was what comes in LFS? If you aren't concerned with allowing 3rd party packages, then there is no reason to pursue the LSB at all. As for the use of RPM, you can see more recent articles and discussions on the LSB lists on the topic of package management. It is an extremely difficult topic to pursue given the myriad of packagers on the various distros. I believe that the current approach is to try to create a generic shim layer with backends for the specific package managers including RPM, dpkg, etc. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Wed, Mar 19, 2008 at 12:23 PM, Robert Daniels [EMAIL PROTECTED] wrote: On Wednesday 19 March 2008 13:52:56 J. Greenlees wrote: snip lots of stuff I agree with Anything that should be adopted by all distros must remain non-controversial to truly be acceptable by all, the more specific the LSB gets, the less respect many people will have for it. Specific in software over the true base system being the issue. The LSB, to my mind, is too extensive. I share the concern over RPM. While RPM is not absolutely required by the LSB, it is quite clearly favored; this is a problem. I don't think it's true that RPM is favored. I believe RPM was just a fully implemented package manager used on more than a few systems at the time the LSB was written. See more background here: http://www.linux.com/feature/59502 I don't have the understanding to say whether other items in the LSB Core spec are needed/useful, but they certainly look extensive. The LSB Desktop spec is worse. Unless I'm reading it wrong, it -requires- the presence of GTK, Qt3, AND Qt4. This is antithetical to construction of a lean system. I understand the inclusion of selected fd.o specs and software, but this document simply goes to far. I see little need to go much further than the POSIX specification and the FHS. I think you're overlooking the purpose of the LSB. It has nothing to do with being a lean system. It has to do with providing a standard set of interfaces for 3rd parties to use. What if a company wants to provide a proprietary GUI app for their hardware? What toolkit are they allowed to use and have it work on Linux systems? If this doesn't sound like the kind of scenario you're interested in, then it's not worth trying to be LSB compliant. However, the need does exist, and there are definitely big players who would benefit from the LSB. Think about distributing your software that works with RHEL x, RHEL y, SuSE z, ... vs. works with LSB 3.2.0. In the context of *LFS, I don't think it really makes any sense to pursue the LSB. I don't think anyone here has more than a curious interest in supporting these scenarios. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Wed, Mar 19, 2008 at 1:35 PM, Robert Daniels [EMAIL PROTECTED] wrote: On Wednesday 19 March 2008 15:53:12 Dan Nicholson wrote: This isn't a proper channel for an LSB discussion, but the entire I would think the LSB Meeting would be the appropriate forum, and Bruce did ask for input on topics to bring up. (and I don't mean this in the whiny, argumentative way it looks, I'm just not sure how else to say it.) No problem. I think my previous reply might have been a bit aggressive, so sorry for that. purpose of the LSB is to allow third parties to create software packages for standard Linux systems. Where LFS and DIY stop are far too minimal for this purpose. For example, how would it be possible for Google to package Picasa for Linux if all that was guaranteed was what comes in LFS? If you aren't concerned with allowing 3rd party packages, then there is no reason to pursue the LSB at all. Package it however they happen to package it now. Just be sure the dependencies are documented. Beyond that, it should be the responsibility of the distro to package these dependencies and install them according to FHS rules. That's how things currently go, but it's a big mess. Let's say I've developed my proprietary app on RHEL and now I want to sell it to some company running Ubuntu. If I want it to be directly installable for them, I have to port the packaging to dpkg and figure out what the dependencies are named on Ubuntu at the least. What if I want to sell it to another company where they use neither RPM nor dpkg? Now I've got 3 packages to maintain. Or, you could write a script that handles the details of the install. OK, except now the binaries are not handled by the native package manager and you require the sysadmin to be familiar with your unusual install method. In both cases, you still need to confirm the package works on systems X, Y and Z for each release or your customers get angry. As for the use of RPM, you can see more recent articles and discussions on the LSB lists on the topic of package management. It is an extremely difficult topic to pursue given the myriad of packagers on the various distros. I believe that the current approach is to try to create a generic shim layer with backends for the specific package managers including RPM, dpkg, etc. As in PackageKit? Not necessarily PackageKit itself, but the idea of it. This would not be so bad at all. Yep, except PackageKit has a simpler job. It just abstracts the details of the package to the user interface. All the details are just handled in the backends. The packages themselves are still distributed in their native formats. This LSB work would also require a new package format and conversion into the native format before handing off to the system's package manager. And now I see your reply to my previous mail. I can understand why vendors would want a more comprehensive specification, but I still don't see what would be wrong with just documenting the dependencies of the binary package. Because people really want it to be as easy as here's the Linux package, install it and go just like you can do on Windows or Mac. The important thing to remember is that not every Linux user is a power user who is intimately familiar with topics like service initialization, GUI toolkits, packaging, etc. Perhaps there is something of a user element too. Maybe the LSB requires the extra software, which could be considered cruft, to protect users too dumb and/or lazy to read documentation to get dependency information, and to protect vendors from spurious support requests from said users. If that's at least part of the reasoning, I think I might be beginning to understand. If it's me or you, then I would say too dumb and/or lazy. If it's my mom, then I say those are details she definitely shouldn't care about. I certainly understand the notion of the informed person clicking the I know what I'm doing checkbox, but I think the LSB is helping to make Just Works attainable for mere mortals. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UDev Problems
On Tue, Mar 11, 2008 at 3:03 PM, Nathan Coulson [EMAIL PROTECTED] wrote: I was just looking at cd udev-config-20080217, and I noticed there were a few things that made nonroot users not work by default. /dev/zero and /dev/null were 660, and until I reverted to the old lfs rules file, I could not run urxvt (I never figured out which device it wanted). also, the mouse devices were in /dev instead of /dev/input. Linux 2.6.24.3 (.2 headers), udev 113, anything else is LFS Development as of the date of this email Someone brought this up to me off list and I forgot to report it here. Shouldn't the new rules only be used with newer udev so they work in conjunction with udev's default rules? I.e., doesn't the book need to be updated to udev-115+ or revert to the last udev-config release? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
On Tue, Mar 4, 2008 at 9:16 PM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Still, please provide them. With only 8 editors who answered the poll, the correlation coefficients involving the I am an editor checkbox have an expected relative error of 35%, and you can bring this down to 33% (just a joke - the error of estimating the error is of course larger than those 2%). What package management requirements the book uses aren't really that important to me, which is why I didn't answer. I'd much rather just follow what the community wants. But, if you're interested in what I consider important from a package manager, you can probably put an X in every box. After messing around with my own package manager and finding out all the limitations, I realized I really do want all those features provided by the big guys, even at the sacrifice of some automation. I personally lean towards RPM because I'm most familiar with Fedora and I conceptually like the idea of keeping all the information in a single file, unlike dpkg where you have a splattering of files. But I wouldn't be opposed to any package manager that people want to use, no matter how simplistic. I'm always free to do what I want to do. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
On Wed, Mar 5, 2008 at 1:35 AM, Alexander E. Patrakov
[EMAIL PROTECTED] wrote:
- It has a lot of legacy features that were oriented to the old
versions of autoconf (see, for example, how the %makeinstall macro
expands--BTW RedHat doesn't use this macro)
Nobody uses this anymore, but it can be useful in the case of a
Makefile with hardcoded directories.
http://gitweb.dwcab.com/?p=pound.git;a=blob;f=jpeg/jpeg.spec;hb=HEAD
- The %configure macro interferes (ore, more correctly, duplicates or
overlaps in functionality) with config.site files, but the
autogenerated spec files are not expected to use this macro, so this
is likely to be a non-issue. However, in this case, setting the
default CFLAGS from RPM macros, as documented, will stop working.
I don't consider this a bad thing since your rpm macros essentially
deprecate config.site. echo '%_prefix /usr/local' ~/.rpmmacros.
Also, you can easily write your own %configure replacement if you
prefer config.site:
cat /etc/rpm/macros.lfs EOF
%configure \
export CFLAGS=${CFLAGS:-%optflags}; \
export CXXFLAGS=${CXXFLAGS:-%optflags}; \
export CONFIG_SITE=/path/to/config.site; \
./configure
EOF
I'm pretty sure that Mandriva and SUSE override the default
%configure. I'm personally considering overriding it so that I can
specify the shell to call configure with since a lot of them have
bashisms.
I don't want to hijack this thread into a merits of RPM thread, but
just wanted to comment on those two points.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Poll about package management
On Wed, Mar 5, 2008 at 4:35 PM, Greg Schafer [EMAIL PROTECTED] wrote: You seem to be striving for perfection. When I want all the bells and whistles I run a mainstream distro. It is simply too labour intensive to have the lot on a self built system. I looked at the amount of effort Dan has apparently put into his RPM based system and weeped :-( :) I was telling Jeremy that when I started converting all my specs to RPM, I figured it'd take a month or two just hammering through the conversion. That started in October and has seemingly no end in sight. But now that I've gotten this far, you can be damn sure that I'll at least enjoy my one click[1] installs for a few months before I abandon ship. Looking back, I probably should have just loaded up Fedora, but I just can't do it. I like having things under my control a little too much. -- Dan [1] http://packagekit.org/pk-screenshots.html -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-SVN: 6.9. Glibc-2.7
On Sat, Mar 1, 2008 at 1:33 PM, Jonathan Oksman [EMAIL PROTECTED] wrote: I'm working through the current development LFS book and one section struck me as a bit odd. In 6.9. Glibc-2.7: The ldd shell script contains Bash-specific syntax. Change its default program interpreter to /bin/bash in case another /bin/sh is installed as described in the Shells chapter of the BLFS book: sed -i 's|@BASH@|/bin/bash|' elf/ldd.bash.in I'm building a 'by the book' lfs system right now, and looking at my toolchain's ldd (which did not have this substitution in chapter 5) it appears to be using bash by default. Using dash as an example alternative sh, this raises a few questions to my mind: The issue is that ldd is a bash script. When you run ./configure, the BASH variable is set to /bin/sh (this is what happens when you call bash as /bin/sh). This is substituted as the interpreter for ldd. That's fine for now as /bin/sh points to bash. However, if you later change /bin/sh to be !bash, things break. Instead of substituting configure's interpretation of what the path to bash is, we just force it to be /bin/bash. That will always work as /bin/bash is certainly the bash shell. I suppose this could be a problem in Ch. 5 since glibc will encode the path to bash from the host system. But that's not a problem outside the chroot. Inside the chroot, you'll have ldd replace early in the glibc installation. This has been fixed upstream to use a better search for the bash interpreter that won't use the BASH variable, which is set by the shell. I don't recall when this went in, but the sed might not be needed anymore with glibc-2.7. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM: proof of concept
On Sun, Mar 2, 2008 at 7:07 AM, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Hello, I have digged up the archives of LeafOS lists and extracted RPM instructions and spec files from them. Spec files up to and including Chapter 6 bash are attached (slightly modified). Dan: sorry for ignoring your superior work. I had used Alexander's specs as a jumping off point for creating an RPM-based distro after I realized that I wanted far better package management than what I was doing with a bash tool I'd written. Anyway, everything is here: http://pound.dwcab.com/repo/ http://gitweb.dwcab.com/?p=pound.git;a=summary The bootstrapping method is basically exactly as Alexander has described it. There are definitely bugs, but it seems to work mostly well (if you're on an x86 and your hardware is exactly like mine :) I hadn't actually been really running it, though, as I'd mostly been repackaging from my old spec files. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning an overall direction for LFS
On Fri, Feb 29, 2008 at 1:20 AM, Alan Lord [EMAIL PROTECTED] wrote: Bruce Dubbs wrote: Jeremy Huntwork wrote: snip / Merging the projects is a good idea, but I think, for the sake of customization and flexibility, it will still be good to break down LFS into 'modules' as Alan Lord suggested. I'm having a problem understanding this concept. If one wants a web server, then you only need LFS and a few packages from BLFS. If you want a workstation, then you need LFS and quite a few more packages from BLFS. What's a module besides a list of packages for a particular application? BLFS is set up to be able to jump around as necessary. I must be missing something because I see a module as fundamentally LFS and a list of links in BLFS. Bruce, my modular idea was more about training modules rather than sets of packages... Here's the original suggestion I made: --- So perhaps the LFS project becomes some sort of course (and I use the term loosely). The modules of which, could be something like: * Learning the basics (Command Line, cmmi, security, toolchain, blah blah) * Scripting/Automating (A subject about how LFS gets built, the tools, the processes involved etc) [This is where PM would probably go too] * Basic Useful Applications (A sort of mini BLFS where we get networking, X and maybe Firefox/TB type apps installed) * Building your Distro (Completing the core build-out adding your chosen apps and utilities and configuring) * Making your Distro distributable (How to make a liveCD of your distro, how to make an installer script...) I think it would be really cool if this is how it worked. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning an overall direction for LFS
On Thu, Feb 28, 2008 at 5:23 PM, Jeremy Huntwork [EMAIL PROTECTED] wrote: snip Nice job bringing it all together. I agree with everything you said and think that it would be a huge win for everyone if the project could be reinvented in this way. I'm especially a huge fan of the modules idea: Focus on the part you want to focus on. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD or No LiveCD?
On Mon, Feb 25, 2008 at 9:12 AM, Bruce Dubbs [EMAIL PROTECTED] wrote: Perfect is the enemy of good enough. I'd agree with that. It's a fact: bugs will happen. Obviously it stinks if someone tries boot and their hard drive isn't detected, but the LiveCD does work for a lot of people. I don't see a real good reason to kill it off unless there are no interested parties left. If there are no active developers, all the more opportunity for new people to get involved. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.7.2. possible minor omission
On Jan 22, 2008 11:29 AM, Matthew Burgess [EMAIL PROTECTED] wrote: On Tue, 22 Jan 2008 12:21:22 -0600, Clyde Forrester [EMAIL PROTECTED] wrote: I'm using the Live 6.3 At 6.7.2. I noticed that the 'video' headers were included, but not mentioned. Thanks for the report, Clyde. I notice that on my kernel, 2.6.23.14, only sisfb.h gets installed there. As such, I wonder whether the installation of that header is actually a bug. I know Dan and Bryan have some experience with the kernel and its headers. Maybe they can shed some light, or get hold of an opinion from upstream? That's probably a gross overstatement of my experience with the kernel headers :) I believe sisfb.h is proper public API. I don't know who uses it (DirectFB shows up on Google code search), but that's been exported from the kernel pretty much since David Woodhouse added the headers_install stuff. Additionally, it appears 2.6.24 will have two more headers in there, uvesa.h and edid.h. So, I'd suspect the video/ headers are proper API for Linux and don't conflict with anything else, like glibc. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc-2.7: awk should be gawk, not mawk
On Jan 15, 2008 11:30 PM, Petr Ovtchenkov [EMAIL PROTECTED] wrote:
On Tuesday 15 January 2008 21:57, Dan Nicholson wrote:
The glibc configure script uses the macro AC_PROG_AWK. This looks for
gawk first in the path before falling back to mawk, nawk or awk. So,
while it's not enforced, if you follow the LFS host requirements, it
will work.
Really?
grep -r awk glibc-2.7 | grep -v gawk
...
glibc-2.7/elf/Makefile: | awk '($$7 ~ /^UND(|EF)$$/ $$1 != 0: $$4
!= REGISTER) { print; p=1 } END { exit p != 0 }'
I forgot about that. This is the one that breaks things. It's been
changed upstream to use $(AWK), I believe. So, it seems like we'll
either have to ensure that awk = gawk somehow or patch the Makefile to
use $(AWK). The second one seems easier:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/elf/Makefile.diff?r1=1.320r2=1.321cvsroot=glibc
Probably just `sed -i 's/awk/$(AWK)/' elf/Makefile'.
...
glibc-2.7/nss/db-Makefile:AWK = awk
...
glibc-2.7/manual/tsort.awk:#! /usr/bin/awk -f
...
glibc-2.7/sysdeps/ia64/fpu/import_intel_libm: awk -f import_file.awk
FUNC=$1 $2 $3
glibc-2.7/sysdeps/ia64/fpu/import_intel_libm: awk -f import_file.awk
LICENSE_ONLY=y $2 $3
(for reference only: my problem begin when awk - mawk fail on regexp on
first line of
listing above [in glibc-2.7/elf/Makefile]).
I don't know details about the others, but I'm pretty sure
elf/Makefile is the one that's causing the problems with non-POSIX
syntax.
--
Dan
--
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
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 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc-2.7: awk should be gawk, not mawk
On Jan 15, 2008 11:11 AM, Bruce Dubbs [EMAIL PROTECTED] wrote: Dan Nicholson wrote: As for using POSIX compatible awk, see this recent helpful thread: http://sourceware.org/ml/libc-alpha/2007-12/msg00020.html Ulrich Drepper really comes across as unreasonable, doesn't he? Unless your name is Jakub Jelinek or Roland McGrath :) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
