[Aboriginal] The hw- target stuff is probably bit-rotted.

[David Seikel]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110526/a70c73cc/attachment-0003.pgp>