Changing $SUBJECT, my comments have nothing to do with Jinja and are barely relevant to the original problem.
On Tue, Sep 17, 2019 at 03:07:51PM -0500, Bruce Dubbs via blfs-support wrote: > > Just for comparison, I do things a bit differently. > It would be *so* boring if we all did everything alike - your setup sounds good and the space details are interesting. Just a few points while I wait for smartctl to test the (old) drive on the new machine, it dropped out briefly. > First, I do use an nfs mount for sources and scripts and logs, but I don't > build there: I forgot to mention that I don't build there (clearly, even untarring over nfs is slower than untarring locally, and building on nfs would be much slower than on a fast machine) although I do update buildscripts in my git trees, and my notes, over nfs. > > SOURCE TARGET FSTYPE SIZE USED AVAIL USE% > lfs84:/srv/src /usr/src nfs 246G 199.3G 34.2G 81% > > The reason it has 200G used is because I have a very long history of older > versions of packages and their histories. I have 875 directories in that > partition. > Using /usr/src is of course traditional (it still appears in lots of documentation). I recall that your normal user can build there. To be honest, I'm surprised that it's only 200G. Becsuse of how my 'backups' work (rsync to /staging, then rsync to "generation"s with hardlinks to save space, before sometimes getting written to external drives - and a weekly tarball of my main /home (including scripts and sources) I have to keep pruning things - currently 53GB for a weekly copy. > I do recommend using a separate /tmp for an LFS/BLFS environment. I used to > build in /tmp but not any more: > /dev/sdb14 /tmp ext4 29.4G 2G 25.9G 7% > If /tmp is a real filesystem, it loses the speed advantage from tmpfs. > I now build in a custom directory /build: > /dev/sdc4 /build ext4 491.2G 109.5G 356.7G 22% > Mmm, loads of room ;-) The great thing is that we can mount filesystems wherever we like - I use /scratch with particularly /scratch/ken and /scratch/working : the latter for my evil "I hope I know what I'm doing, I'll build as root" scripts :-p But for quick tests of updated regular-size packages, and for diffing them, a tmpfs seems a little quicker. We each have to tune our partitioning to our usage, and over time things change. > I don't delete packages after build because I keep them for possible > reference. If rebuilding a package, the previous build is removed first. > > I've started using 30G for the / partition. It is enough for all the BLFS > packages: > /dev/sda14 / ext4 29.4G 25.1G 2.8G 86% > That will be useful to know if/when I get back to more general testing (got to bring up the new ryzen 5 3400G - currently running 9.0 but I have not yet built Xorg - then source parts for a replacement home server, and deal with other real life issues). Meanwhile, if my profanities leak out in the next couple of days it will probably be from the KVM switch I bought (4-way HDMI/usb) - when it works it is fine for 1920x1080 but it keeps losing the video output when a machine goes idle, or on some reboots, and needs to be power cycled after both the monitor and machine are on - usually I can get to grub in time, but not always. Unfortunately, HDMI is designed for TV/film producers. In this case the supplied PC-KVM cables (HDMI and USB 2.0 combined cable) do NOT work to connect PC direct to monitor (one of my early "why doesn't this work?" tests). But they do work for PC-KVM if the PC and monitro are both powered on first. And choice of domestic KVM switches without VGA is limited. I ought to say "sorry for this 2-paragraph rant", but I'm not. ĸen (hope that looks ok, for some reason my consolefont seems to have not loaded). -- thread 'main' panicked at 'giraffe', /tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13 -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
