-----BEGIN PGP SIGNED MESSAGE----- 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 2.6.26.6 > 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 @linuxfromscratch.org 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... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI+k78S5vET1Wea5wRAz4zAKDQfp7Q4XsLmpYNYmMEfOWgVv+heQCfTnzw NHhdkjHDnAbzqRMDQbzY3k4= =wmHT -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
