---
- branch: MAIN
  date: Tue Nov 28 02:56:44 UTC 2017
  files:
  - new: '1.69'
    old: '1.68'
    path: src/distrib/utils/embedded/mkimage
    pathrev: src/distrib/utils/embedded/mkimage@1.69
    type: modified
  - new: '1.20'
    old: '1.19'
    path: src/distrib/utils/embedded/conf/armv7.conf
    pathrev: src/distrib/utils/embedded/conf/armv7.conf@1.20
    type: modified
  - new: '1.32'
    old: '1.31'
    path: src/distrib/utils/embedded/conf/rpi.conf
    pathrev: src/distrib/utils/embedded/conf/rpi.conf@1.32
    type: modified
  - new: '1.10'
    old: '1.9'
    path: src/distrib/utils/embedded/conf/rpi_inst.conf
    pathrev: src/distrib/utils/embedded/conf/rpi_inst.conf@1.10
    type: modified
  - new: '1.8'
    old: '1.7'
    path: src/distrib/utils/embedded/conf/x86.conf
    pathrev: src/distrib/utils/embedded/conf/x86.conf@1.8
    type: modified
  id: 20171128T025644Z.ae7d55fd31581ee5510bcff66386e344b5d2070e
  log: |
    Be more precise about exactly what fails when something does.

    Relying upon set -e to abort things is sort of OK (it is not
    a recommended option to use in general - too many odd special cases),
    but only if user can work out from the "build failed" what actually
    went wrong.

    Tested only on amd64 build (for this, i386 is the same) - if anyone
    has problems on builds for other systems, please let me know.  However
    the changes affect only failure paths, the most likely problem would
    be for a build to fail to halt on an error, and I hope I have avoided
    that.  There should be no difference at all to error-free builds.
  module: src
  subject: 'CVS commit: src/distrib/utils/embedded'
  unixtime: '1511837804'
  user: kre