On 2 November 2016 at 04:35, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Nov 01, 2016 at 03:22:01PM +0000, Peter Maydell wrote: >> On 30 October 2016 at 21:23, Michael S. Tsirkin <m...@redhat.com> wrote: >> > The following changes since commit >> > 5b2ecabaeabc17f032197246c4846b9ba95ba8a6: >> > >> > Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20161028-1' >> > into staging (2016-10-28 17:59:04 +0100) >> > >> > are available in the git repository at: >> > >> > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream >> > >> > for you to fetch changes up to f082ec0225bd15c71e0b4697d2df3af7bad65d7f: >> > >> > acpi: fix assert failure caused by commit 35c5a52d (2016-10-30 20:06:25 >> > +0200) >> > >> > ---------------------------------------------------------------- >> > virtio, pc: fixes and features >> > >> > nvdimm hotplug support >> > virtio migration and ioeventfd rework >> > virtio crypto device >> > ipmi fixes >> > >> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> >> > >> >> Hi; this fails to build on OSX with format string issues: >> >> /Users/pm215/src/qemu-for-merges/hw/virtio/virtio-crypto.c:770:20: >> error: format specifies type 'unsign >> ed short' but the argument has type 'uint32_t' (aka 'unsigned int') >> [-Werror,-Wformat] >> vcrypto->max_queues, VIRTIO_QUEUE_MAX); >> ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /Users/pm215/src/qemu-for-merges/include/qapi/error.h:163:35: note: >> expanded from macro 'error_setg' >> (fmt), ## __VA_ARGS__) >> ^ >> >> Fun fact: in struct vhost_dev, max_queues is a uint64_t; >> in struct VirtIONet it is a uint16_t; and in VirtIOCrypto >> it is a uint32_t... >> >> thanks >> -- PMM > > Just to make sure : I fixed that and pushed to > same tag. I don't think it makes sense to repost the pull > request - pls take it from > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
You should always repost at least the cover-letter part of a fresh pull request, because otherwise it is likely to not be caught by the email filters that find pull requests. (In this case I've handed over pull request processing to Stefan, so the question would be whether his filters notice.) thanks -- PMM
