State dump of the last few months [was: Re: Package freeze]

Bryan Kadzban bryan at
Sat Oct 18 14:02:53 PDT 2008

Hash: RIPEMD160

Bruce Dubbs wrote:
> Right now there are a few of tickets outstanding with regard to updated packages 
> or patches to packages that we need to address before a package freeze.  We need 
> to either agree to update or reset the target milestone to either 7.0 or future.
> 2226	Vim mandir patch ( really just an optimization )
> 2227	Perl-5.10.0 issues ( functional problems )
> 2233	Linux
> 2246	Tcl 8.5.5
> 2247	Texinfo 4.13a ( repackage due to maintainer error )
> 2248	E2FsProgs 1.41.3
> Are there issues with any of these or should we defer some?  My inclination is 
> to add them and then freeze.

Figures.  I just now get DSL up and running again (after moving across
the continent) so I have a decent enough Internet connection to
re-register my mail server in DNS and turn off vacation mode, and LFS is
about to start a package freeze.  Serves me right for being offline for
nearly two months, I guess.  I even missed all of DJ's and Randy's
package update spree!  :-(

(OTOH: Book development!  Yay!  \o/)

FWIW, I don't know of any issues with any of those changes, but I've
been offline for too long during the move and new-job stuff.  I did
catch up on the lfs-dev and lfs-book lists last night and today, at
least (which is why I subscribed my address to
- -dev before I left; it was already subscribed to -book).

As far as the book itself, I want to get an initramfs prototyped at some
point, but it's far too late for that to go into 6.4 (which is fine; I
was hoping to get it into 7.0 anyway).  The SVN repo I mentioned in
ticket #2033 is now back up as well, if anyone's trying to sync to it
(but nothing has happened recently).  Though I did have to re-issue its
cert since the old one expired, so the fingerprint in the bug is wrong
now.  It's d6:1a:63:58:04:58:72:00:36:ad:5a:f7:5c:e4:16:22:15:73:fb:13.

As far as udev goes, I was leery of the autoconf change because they
moved around lots of tools, but it looks like someone here figured out
that simply following the INSTALL file works.  (Duh, I should have
thought of that...)  So that's fine.

As far as udev-config goes, it looks like it got a single update to
override the floppy-devices script, which I think is fine.  (It's
simpler than how I was going to attack ticket #2076.)

As far as directory-for-udev-files goes, it looks like we're putting LFS
stuff into /etc and upstream stuff into /lib, which is probably the best
way to do it.  I was going to consider moving our stuff to /lib, but it
looks like that's already been decided, so never mind.  :-P

Let's see, which other messages did I save to comment on...

Ah yes -- STRIP=yes in iana-etc.  There was some discussion that this
might make various glibc lookups faster.  Count me as strongly opposed
to removing the comments (though it looks like that's what happened
anyway).  Somebody said that programs cache service name lookups at
start time, and they're absolutely right.  Someone else responded about
getservbyname being uncached by glibc, but guess what: getservbyname is
cached by *programs*, so glibc doesn't have to.  Programs don't call it
more than once (at startup), so it doesn't slow them down much.  The
time gains are miniscule, the space gains are tiny (assuming a system
that isn't embedded), and the loss of comments is a problem.

jhalfs -- I really need to download that and start using it...

sed/coreutils and hardcoded paths -- It's not entirely stupid to
hardcode a path.  If some (admittedly, stupid) user has their own ~/bin
at the *start* of their $PATH, and they have a hacked-up version of sed
sitting in there that doesn't actually work, I'd really rather not have
other scripts break.  It's the same reason you don't generally want to
use the exec*p functions from C in a secure program: you can't really
control $PATH.  Of course e2fsprogs probably isn't a "secure program"...

In short, I wouldn't say that embedding the path (found at compile time)
is poor behavior.  It's simply ensuring that whichever program you found
at compile time (and presumably tested the features of!) is the same
program that you'll be using at runtime, forever.  :-)

On a personal note, working at Google is fun!  And thanks a lot to the
couple of guys here that gave them recommendations (I won't name you
specifically, but you know who you are ;-) ).

Now, off to see where I left off with the initramfs oh so long ago...
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the lfs-dev mailing list