On Fri, 2017-05-19 at 17:51 -0700, no-re...@patchew.org wrote:
> In file included from /tmp/qemu-test/src/hw/adc/aspeed_adc.c:15:0:
> /tmp/qemu-test/src/hw/adc/aspeed_adc.c: In function 'aspeed_adc_read':
> /tmp/qemu-test/src/hw/adc/aspeed_adc.c:106:34: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 3 has type 'hwaddr {aka
> long long unsigned int}' [-Werror=format=]
> qemu_log_mask(LOG_UNIMP, "%s: addr: 0x%lx, size: %u\n", __func__,
> addr,
> ^
> /tmp/qemu-test/src/include/qemu/log.h:94:22: note: in definition of macro
> 'qemu_log_mask'
> qemu_log(FMT, ## __VA_ARGS__); \
> ^~~
> /tmp/qemu-test/src/hw/adc/aspeed_adc.c: In function 'aspeed_adc_write':
> /tmp/qemu-test/src/hw/adc/aspeed_adc.c:162:34: error: format '%lu' expects
> argument of type 'long unsigned int', but argument 3 has type 'hwaddr {aka
> long long unsigned int}' [-Werror=format=]
> qemu_log_mask(LOG_UNIMP, "%s: %lu\n", __func__, addr);
> ^
> /tmp/qemu-test/src/include/qemu/log.h:94:22: note: in definition of macro
> 'qemu_log_mask'
> qemu_log(FMT, ## __VA_ARGS__); \
> ^~~
> cc1: all warnings being treated as errors
> /tmp/qemu-test/src/rules.mak:69: recipe for target 'hw/adc/aspeed_adc.o'
> failed
> make[1]: *** [hw/adc/aspeed_adc.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> CC aarch64-softmmu/hw/scsi/virtio-scsi-dataplane.o
> Makefile:327: recipe for target 'subdir-aarch64-softmmu' failed
> make: *** [subdir-aarch64-softmmu] Error 2
> make: *** Waiting for unfinished jobs
> GEN x86_64-softmmu/qemu-system-x86_64.exe
> tests/docker/Makefile.include:118: recipe for target 'docker-run' failed
> make[1]: *** [docker-run] Error 2
> make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-i73ef6w0/src'
> tests/docker/Makefile.include:149: recipe for target
> 'docker-run-test-mingw@fedora' failed
> > make: *** [docker-run-test-mingw@fedora] Error 2
> === OUTPUT END ===
>
> Test command exited with code: 2
I'll fix the format string issues in v2 along with any other issues
identified in review.
Separately, is it necessary for the bot to send the entirety of the
build output? Can we make it a bit smarter to send just the error with
some small amount of context? Maybe send the full log as an attachment?
Or host it and link to it from the email? It's a bit tedious having to
scroll through all that output to find the error at the bottom.
Cheers,
Andrew
signature.asc
Description: This is a digitally signed message part