On Wed, Feb 20, 2008 at 04:28:58PM -0700, [EMAIL PROTECTED] wrote: > In preparation for v3 and the upcoming openvsa changes, > rearrange the VSA fetching code. We now fetch an > uncompressed blob, and do the compressing within buildrom. > I'm mainly concentrating on v2 right now (this is not quite > v3 friendly), but it will be. > > Also, work around a hopefully temporary bug on the AMD > servers.
That workaround did not work for me, see a modified version below that fixes the build. > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ buildrom-devel/packages/geodevsa/amdvsa.inc 2008-02-20 > 16:10:05.000000000 -0700 > @@ -0,0 +1,21 @@ > +# Target file for the AMD VSA binary - included from geodevsa.mk > + > +AMDVSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ > +AMDVSA_BIN=amd_vsa_lx_1.01.bin > + > +# 2008-02-19 - the AMD URL above is broken, when trying to wget > +# amd_vsa_lx_1.01.bin.gz it arrives uncompressed instead. This > +# breakage is expected to be fixed; but to properly > +# handle this temporary situation without breakage down the line, > +# we do the unsual check of the file type below: > +# Jordan > + > +$(SOURCE_DIR)/$(AMDVSA_BIN): > + @ echo "Fetching the AMD VSA binary..." > + wget -P $(SOURCE_DIR) $(AMDVSA_URL)/$(AMDVSA_BIN).gz -O [EMAIL > PROTECTED] > + @ if file [EMAIL PROTECTED] | grep -q "COM executable"; then \ > + mv [EMAIL PROTECTED] $@; else gunzip -q [EMAIL PROTECTED]; fi The above did not work for me (I just got 'data' as output from 'file'). I think this is perhaps a more reliable: @ if file [EMAIL PROTECTED] | grep -q "gzip"; then \ gunzip -q [EMAIL PROTECTED]; else mv [EMAIL PROTECTED] $@; fi It fixes the build for me. Thanks, Ward. -- Ward Vandewege <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot

