On Wed, Dec 16, 2020 at 09:49:38AM +0100, Pierre Labastie wrote: > On Wed, 2020-12-16 at 00:48 +0000, Ken Moffat wrote: > > I've been building a lot of blfs with jhalfs. but because the > > filesystem is only 25GB I figured that at various stages I should > > tar up the system so that I could revert to an earlier, less full, > > system. That went ok, so after looking at texlive etc (10GB in > > itself) I restored to a system with xorg, fluxbox, xfce, and the > > epiphany, firefox and seamonkey browsers. > > > > Now I need to see which packages I have not yet tried to build.
(...) > > I'd noticed once or twice when trying brief configurations in the > > menu that an old target would show up as TARGET0, but after going > > back in it cleared itself out, unsure if that is related to this (or > > maybe Config.in is supposed to only show items which have not been > > installed ?). > > > > Is there any way to *force* Config.in to get refreshed/regenerated > > to show everything ? > > > > Normally Config.in is regenerated when running make, if either: > - the instpkg file has changed (this happens each time a package is > successfully built) > - one of the books has changed (as a result of "make update" or editing > it) > - in the rare cases where one of the .xsl files or other utility script > has changed in the blfs_root tree. > > Of course, if you just run "make", Config.in is regenerated, but then > the menu is displayed. > > If you just want to regenerate Config.in, type "make $(pwd)/Config.in" > (the $(pwd) is needed because this is how the target is defined in the > Makefile). > > Not sure about your "TARGET_0" observation. Normally, if Config.in has > changed, and you save the configuration when exiting the menu, this > shouldn't happen. > For Config.in, *IF* I go ahead with this approach (I'm having doubts since so much manual intervention is required to clean up unwanted configuration, or to allow rebuilds) I think that I'll maybe just copy Config.in at the start. Ideally I would try to build everything in one go (should be feasible if I get a new machine, but needs at least a 40GB filesystem). Meanwhile, I selected everything which had not already been built (not sure if it will actually fit on this filesystem). I'm now getting fed up with the number of packages which are being rebuilt. At the moment it is (re) building llvm and has (among others) xorg-server, nspr, nss, js78, rusti to do although these are already present in instpkg.xml. As with 'TARGET_0' above, maybe there is a race somewhere (I'm using make -j8 although if I get a new box to do this the number will be higher). > Note that packages.xml has the whole list of packages (with their > dependencies, which is another story), there is one tag "inst-version", > which is present if the package is installed, and not present if the > package is not installed. packages.xml gets regenerated in the same > cases when Config.in is. Again, you can issue "make > $(pwd)/packages.xml", if you just want to regenerate it. > > Enjoy :) > > Pierre > This is turning into a very masochistic form of enjoyment. I hope to report my current changes to generated scripts later (quite a lot are because I don't want to actually run some of these things if I do boot the created system), but at the moment that is getting further and further distant. Meanwhile, I'm hoping to prove if my current variation for mounting shm on an LFS-style sysv build (i.e. one where /dev/shm is a symlink to /run/shm) will work - first test will be rebuilding python3 (that got puleld in by something), and if that succeeds then building thunderbird. Later, ĸen -- (The Balancing Monks) use small brass weights, none of them bigger than a fist. They work. Well, obviously they work. The world has not tipped up yet. -- The Thief Of Time -- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
