zarniwhoop73 at googlemail.com
Sun Jul 19 09:48:03 PDT 2009
(cc: editors with recent visibility, to make sure you know what I'm offering to
2009/7/19 Bruce Dubbs <bruce.dubbs at gmail.com>:
> Ken Moffat wrote:
>> As an alternative, replace "status" with 'last built against LFS version ...."
>> (and show the release or svn date) - that has benefit going forward that
>> it indicates what might not build with a current release, or might have
>> outdated space and time figures.
> I like this idea. We already have a line showing the last time the page was
> Last updated on 2008-10-13 09:49:44 -0500
> but this doesn't always mean that the package was tested then. Sometimes it's
> just a typo or other change that is made without rebuilding the package.
> We could easily put in another line:
> Last built and tested with LFS version 6.5
> immediately above or below the date stamp.
> -- Bruce
I'm trying to keep this simple, to get started quickly now that
people are doing 6.5 changes. How about, in the Package Information
a new first item: 'Last built and tested with LFS version xxx'.
I've thought a bit more about 6.4 : I can afford to build some packages
I hate, provided I throw them away at the end of the build. So, several
builds to confirm different things build. That means I might as well go
for the latest versions of gnome-2.24 (the packages that are in the book
and some or all of the later requirements such as rarian).
For kde, stick with 3.5.10. Other version upgrades where we are way
behind (e.g. gimp, ghostscript - and reduce to just gpl-ghostscript - and
So, revised proposal -
1. I'll add a "Last built and tested with LFS version " line to every package.
For the updates between October 2008 and June 2009 the version will be
6.4. For earlier changes it will be 'unknown'. For this month's changes
I'm starting to think 6.5 is appropriate to some of them (my own was for
6.4) - I guess the gdbm/berkeley changes are for 6.5 and will need to be
reverted in a 6.4 branch.
2. After I've done this and checked it renders, I'll branch for 6.4.
3. I'll get my grasping mitts onto tickets for 6.4, and probably create
a few new ones for things I had in mind. Specifically, a gnome-2.24
ticket. And move others like the current gnome ticket to 6.5. A new
dhcp-3.1-series ticket to fix the vulnerability, the dhcp-4 ticket can be
updated for the new fixed version and moved to 6.5.
4. Get the branch to render, and to be visible from
http://www.linuxfromscratch.org/blfs/read.html - I've no idea what
needs to be done (cron job ? which repo for the html ?)
5. Build, test, write up. Repeat until stupefied. I'm intending
to update the date separately, and to limit commits to either a
single package, or to related packages, in the hope that will
reduce the conflicts if people want to merge any of these in to
trunk. If nobody does, and I'm around, I'll do relevant ones
6. Status reports, when I have something to say.
To reiterate, I'm hoping to be absent for significant amounts of
time during August and September, so tentatively looking to do an
-rc in mid or late October.
After tragedy, and farce, "OMG poneys!"
More information about the blfs-dev