(cc: editors with recent visibility, to make sure you know what I'm offering to do)
2009/7/19 Bruce Dubbs <[email protected]>: > 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 > changed: > > 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 gutenprint). 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. ĸen -- After tragedy, and farce, "OMG poneys!" -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
