Instead use a *.report file for each component and add data as we
go, culminating in the built image simply catting the report to the
screen to show the user what is about to occur.
This is on the path towards removing all variables from the autoexec
template - which would make it simpler to reuse the same template for
other commands (e.g the x200 series does not use dosflash.exe)
As two examples - When looking at the release notes for the x200 laptop,
they have the same "uc" name as the cdrom image. The release notes for
the x270 laptop also has the same name as the cdrom image, but they use
neither the "uc" nor the "us" suffixes.
So, it seemed simplest to be the least smart and just download whatever
matches the cdrom image name.
This has the drawback that we sometimes end up with text files that tell
you how to use the windows .exe installer - but I am hoping that the
people reading these release notes will be able to realise that not all
instructions should be followed...
This also documents the new .extract make targets and moves the direct
loopback mount option entirely into the documentation. It has been
moved because I want to discourage people from using it - I consider
it to be a higher risk with no good return for this risk.
Avoids `mv` fail and in turn `make` fail.
```
for i in *.img.d; do mv $i/006_battery_validate.patch $i/006_battery_validate.patch.OFF; done
mv: cannot stat 't430.G1HT35WW.img.d/006_battery_validate.patch': No such file or directory
mv: cannot stat 't430s.G7HT39WW.img.d/006_battery_validate.patch': No such file or directory
mv: cannot stat 't530.G4HT39WW.img.d/006_battery_validate.patch': No such file or directory
mv: cannot stat 'w530.G4HT39WW.img.d/006_battery_validate.patch': No such file or directory
mv: cannot stat 'x230.G2HT35WW.img.d/006_battery_validate.patch': No such file or directory
mv: cannot stat 'x230t.GCHT25WW.img.d/006_battery_validate.patch': No such file or directory
Makefile:126: recipe for target 'patch_disable_battery' failed
make: *** [patch_disable_battery] Error 1
```
Note that this has the disadvantage that the resulting patched ISO images
are no longer easily diffable - the sectors used to store the patched
firmware will be changed by the mcopy program.
Since it turns out that the ISO image diff files were basically never
used, this is not a big issue - it mainly makes it harder to do QA on
the output.
Hamish Coleman
Robin Schneider