[Aboriginal] The hw- target stuff is probably bit-rotted.
onefang at gmail.com
Thu May 26 00:09:30 PDT 2011
On Thu, 26 May 2011 01:39:27 -0500 Rob Landley <rob at landley.net> wrote:
> On 05/25/2011 07:57 AM, David Seikel wrote:
> > On Mon, 18 Apr 2011 20:12:36 -0500 Rob Landley
> > <rlandley at parallels.com> wrote:
> >>> I seriously think that since that was the last grub legacy that
> >>> FSF published, that they went to the effort of breaking it. But,
> >>> never ascribe to malice what can be accounted for with stupidity.
> >> So back up a few versions.
> > Actually, the problem was that the LFS I was using included a later
> > grub version that was overwriting the source of the grub version I
> > was trying to install. This happens when the LFS included source
> > tarballs are unpacked at the end. I added in a line to remove the
> > internal grub tarball before unpacking the rest of LFS.
> You mean while running make-control-image.sh? Or are you extracting a
> tarball at native build time? (I dunno how closely what you're doing
> is based on my lfs-bootstrap... or not.)
Yep, make-control-image.sh. What I'm doing is based on lfs-bootstrap,
with a heap of the packages commented out of package-list, and a bunch
more tacked on the end. With suitable build scripts added, though some
of them are just links to generic-check.sh. The extra packages are
added to download.sh, where the above mentioned change was made.
> > That at least got rid of the --disable-nls problem, the patches
> > still did not apply.
> > The rest of my problems where - when building a disk image from
> > scratch, it pays to sync often. And some shitty hardware issues.
> I tend to make scripts that can be re-run to rebuild everything, and
> then do lots of unnecessary rebuilds which I write off as "regression
> testing". I've been in the situation of tweaking a system I can't
> reproduce, and "restore from backup" isn't an option if the problem is
> an old software package got silently corrupted 18 months ago and
> nobody's noticed up until now, and the build recipe that would allow
> you to replace it has to be worked out fromm scratch again, and
> nobody even remembers what it's used for...
> Erring on the side of "rebuild into a fresh directory, time for lunch"
> is much more comfortable for me. (Then again, almost all my builds
> are "build all". I even put a "make clean" step in my git bisects.
> Well, actually I put a "git clean -fdx && git checkout -f" in there,
> because distclean can have version skew. :P )
I have a tendency to do that to. For similar reasons, I tend to reboot
when a system update, or my own work, messes with anything that's used
for the boot up sequence. Something I'd rather know got broken when it
breaks, rather than months later when I will have less clue, and likely
a dire need for the system to just boot NOW dammit.
Plus, what better way to exercise the legendary laziness of a good
programmer than to start a long compile, then wonder to the other side
of my bedroom / office, and just relax on my bed for half an hour? B-)
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the Aboriginal