Message ID | 1459264128-12761-1-git-send-email-kwolf@redhat.com |
---|---|
State | New |
Headers | show |
On 29 March 2016 at 16:08, Kevin Wolf <kwolf@redhat.com> wrote: > The following changes since commit b68a80139e37e806f004237e55311ebc42151434: > > Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20160324' into staging (2016-03-24 16:24:02 +0000) > > are available in the git repository at: > > > git://repo.or.cz/qemu/kevin.git tags/for-upstream > > for you to fetch changes up to b63f2a6772ca774ec58b2fc6e26fdeeda44a99c1: > > iotests: Test qemu-img convert -S 0 behavior (2016-03-29 16:30:13 +0200) > > ---------------------------------------------------------------- > Block layer patches Hi. I'm afraid this doesn't compile: /Users/pm215/src/qemu-for-merges/block/blkreplay.c:38:9: warning: implicit declaration of function 'error_propagate' is invalid in C99 [-Wimplicit-function-declaration] error_propagate(errp, local_err); ^ /Users/pm215/src/qemu-for-merges/block/crypto.c:68:9: warning: implicit declaration of function 'error_setg_errno' is invalid in C99 [-Wimplicit-function-declaration] error_setg_errno(errp, -ret, "Could not read encryption header"); ^ /Users/pm215/src/qemu-for-merges/block/crypto.c:116:66: error: use of undeclared identifier 'error_abort' qemu_opt_set_number(data->opts, BLOCK_OPT_SIZE, data->size, &error_abort); ^ /Users/pm215/src/qemu-for-merges/block/crypto.c:217:9: warning: implicit declaration of function 'error_setg' is invalid in C99 [-Wimplicit-function-declaration] error_setg(&local_err, "Unsupported block format %d", format); ^ /Users/pm215/src/qemu-for-merges/block/crypto.c:220:5: warning: implicit declaration of function 'error_propagate' is invalid in C99 [-Wimplicit-function-declaration] error_propagate(errp, local_err); ^ /Users/pm215/src/qemu-for-merges/block/crypto.c:296:50: error: use of undeclared identifier 'error_abort' opts = qemu_opts_create(opts_spec, NULL, 0, &error_abort); ^ Looks like you've also been hit by commit da34e65cb4025, which means you now need to explicitly include qapi/error.h if you need it. thanks -- PMM
Am 29.03.2016 um 21:56 hat Peter Maydell geschrieben: > On 29 March 2016 at 16:08, Kevin Wolf <kwolf@redhat.com> wrote: > > The following changes since commit b68a80139e37e806f004237e55311ebc42151434: > > > > Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20160324' into staging (2016-03-24 16:24:02 +0000) > > > > are available in the git repository at: > > > > > > git://repo.or.cz/qemu/kevin.git tags/for-upstream > > > > for you to fetch changes up to b63f2a6772ca774ec58b2fc6e26fdeeda44a99c1: > > > > iotests: Test qemu-img convert -S 0 behavior (2016-03-29 16:30:13 +0200) > > > > ---------------------------------------------------------------- > > Block layer patches > > Hi. I'm afraid this doesn't compile: > [...] > Looks like you've also been hit by commit da34e65cb4025, which > means you now need to explicitly include qapi/error.h if you need it. Ok, I can (and will, unless you tell me not to) send a v2 of the pull request; but generally speaking, wouldn't it make more sense and be easier for everyone involved (including yourself) if such merge conflicts where you know exactly what trivial fixup needs to be done were handled in the merge commit? Kevin
On 30 March 2016 at 09:57, Kevin Wolf <kwolf@redhat.com> wrote: > Am 29.03.2016 um 21:56 hat Peter Maydell geschrieben: >> Hi. I'm afraid this doesn't compile: >> [...] >> Looks like you've also been hit by commit da34e65cb4025, which >> means you now need to explicitly include qapi/error.h if you need it. > > Ok, I can (and will, unless you tell me not to) send a v2 of the pull > request; but generally speaking, wouldn't it make more sense and be > easier for everyone involved (including yourself) if such merge > conflicts where you know exactly what trivial fixup needs to be done > were handled in the merge commit? Sometimes, yes, but I often prefer not to for two reasons: (1) I often have a big queue of merges to process and time spent by me trying to by-hand fix up bad merges is time not spent processing somebody else's merge (2) I may be able to get the merge to compile but my testing process for the affected code is likely to be much less comprehensive than the submaintainer's So mostly I reserve fixes during the merge for trivial textual-only conflicts. thanks -- PMM
Am 30.03.2016 um 13:29 hat Peter Maydell geschrieben: > On 30 March 2016 at 09:57, Kevin Wolf <kwolf@redhat.com> wrote: > > Am 29.03.2016 um 21:56 hat Peter Maydell geschrieben: > >> Hi. I'm afraid this doesn't compile: > >> [...] > >> Looks like you've also been hit by commit da34e65cb4025, which > >> means you now need to explicitly include qapi/error.h if you need it. > > > > Ok, I can (and will, unless you tell me not to) send a v2 of the pull > > request; but generally speaking, wouldn't it make more sense and be > > easier for everyone involved (including yourself) if such merge > > conflicts where you know exactly what trivial fixup needs to be done > > were handled in the merge commit? > > Sometimes, yes, but I often prefer not to for two reasons: > (1) I often have a big queue of merges to process and time > spent by me trying to by-hand fix up bad merges is time not > spent processing somebody else's merge Right, but so is time spent for sending an email describing the problem and later processing a v2. In more complicated cases that certainly still saves time for you and you should continue to do that. I was talking only about the really obvious cases where you already tell me in your email what the exact problem is and how I need to fix it. > (2) I may be able to get the merge to compile but my testing > process for the affected code is likely to be much less > comprehensive than the submaintainer's Okay, that's a fair point. Kevin