Message ID | 20200203123811.8651-1-thuth@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: > > Hi Peter, > > the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: > > Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) > > are available in the Git repository at: > > https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 > > for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: > > trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) > > ---------------------------------------------------------------- > * Current qtests queue > * Some Kconfig updates > * Some trivial clean-ups here and there > ---------------------------------------------------------------- All the incremental rebuilds failed: Linux cam-vm-266 4.15.0-70-generic x86_64 From git://git-us.linaro.org/people/pmaydell/qemu-arm f31160c7d1..f9e931a1d9 staging -> pmaydell/staging make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' CC qga/main.o CC stubs/machine-init-done.o CC stubs/replay-user.o CC stubs/semihost.o CC qemu-img.o CC qemu-io.o CC chardev/char.o make: *** No rule to make target '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by 'aarch64-softmmu/config-devices.mak'. Stop. make: *** Waiting for unfinished jobs.... CC chardev/char-mux.o make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' thanks -- PMM
On 03/02/2020 15.04, Peter Maydell wrote: > On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: >> >> Hi Peter, >> >> the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: >> >> Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) >> >> are available in the Git repository at: >> >> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 >> >> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: >> >> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) >> >> ---------------------------------------------------------------- >> * Current qtests queue >> * Some Kconfig updates >> * Some trivial clean-ups here and there >> ---------------------------------------------------------------- > > All the incremental rebuilds failed: > > Linux cam-vm-266 4.15.0-70-generic x86_64 > From git://git-us.linaro.org/people/pmaydell/qemu-arm > f31160c7d1..f9e931a1d9 staging -> pmaydell/staging > make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' > make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' > make[1]: Nothing to be done for 'all'. > make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' > CC qga/main.o > CC stubs/machine-init-done.o > CC stubs/replay-user.o > CC stubs/semihost.o > CC qemu-img.o > CC qemu-io.o > CC chardev/char.o > make: *** No rule to make target > '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by > 'aarch64-softmmu/config-devices.mak'. Stop. > make: *** Waiting for unfinished jobs.... > CC chardev/char-mux.o > make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' Oh, they are still failing??? Why are there still references to hw/bt/Kconfig in these config-devices.mak files, I'd expect that they would have been regenerated at least once during the past week? Thomas
On 03/02/2020 15.30, Thomas Huth wrote: > On 03/02/2020 15.04, Peter Maydell wrote: >> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: >>> >>> Hi Peter, >>> >>> the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: >>> >>> Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) >>> >>> are available in the Git repository at: >>> >>> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 >>> >>> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: >>> >>> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) >>> >>> ---------------------------------------------------------------- >>> * Current qtests queue >>> * Some Kconfig updates >>> * Some trivial clean-ups here and there >>> ---------------------------------------------------------------- >> >> All the incremental rebuilds failed: >> >> Linux cam-vm-266 4.15.0-70-generic x86_64 >> From git://git-us.linaro.org/people/pmaydell/qemu-arm >> f31160c7d1..f9e931a1d9 staging -> pmaydell/staging >> make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' >> make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' >> make[1]: Nothing to be done for 'all'. >> make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' >> CC qga/main.o >> CC stubs/machine-init-done.o >> CC stubs/replay-user.o >> CC stubs/semihost.o >> CC qemu-img.o >> CC qemu-io.o >> CC chardev/char.o >> make: *** No rule to make target >> '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by >> 'aarch64-softmmu/config-devices.mak'. Stop. >> make: *** Waiting for unfinished jobs.... >> CC chardev/char-mux.o >> make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' > > Oh, they are still failing??? Why are there still references to > hw/bt/Kconfig in these config-devices.mak files, I'd expect that they > would have been regenerated at least once during the past week? What timestamp do the */config-devices.mak files have on your system? Could you please also execute a "grep -r bt/Kconfig *" to see whether there is still anything else stale around? Thomas
On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote: > > On 03/02/2020 15.04, Peter Maydell wrote: > > On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: > >> > >> Hi Peter, > >> > >> the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: > >> > >> Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) > >> > >> are available in the Git repository at: > >> > >> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 > >> > >> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: > >> > >> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) > >> > >> ---------------------------------------------------------------- > >> * Current qtests queue > >> * Some Kconfig updates > >> * Some trivial clean-ups here and there > >> ---------------------------------------------------------------- > > > > All the incremental rebuilds failed: > > > > Linux cam-vm-266 4.15.0-70-generic x86_64 > > From git://git-us.linaro.org/people/pmaydell/qemu-arm > > f31160c7d1..f9e931a1d9 staging -> pmaydell/staging > > make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' > > make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' > > make[1]: Nothing to be done for 'all'. > > make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' > > CC qga/main.o > > CC stubs/machine-init-done.o > > CC stubs/replay-user.o > > CC stubs/semihost.o > > CC qemu-img.o > > CC qemu-io.o > > CC chardev/char.o > > make: *** No rule to make target > > '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by > > 'aarch64-softmmu/config-devices.mak'. Stop. > > make: *** Waiting for unfinished jobs.... > > CC chardev/char-mux.o > > make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' > > Oh, they are still failing??? Why are there still references to > hw/bt/Kconfig in these config-devices.mak files, I'd expect that they > would have been regenerated at least once during the past week? build/all/aarch64-softmmu/config-devices.mak.d was most recently touched this morning, and it still includes hw/bt/Kconfig in its dependency list. I think this is because minikconf will still put a Kconfig file into the .d file it generates even if the Kconfig file happens to be empty. And make doesn't have any rules that tell it that config-devices.mak.d need to be updated either: $ make -C build/all -n aarch64-softmmu/config-devices.mak.d make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/all' make[1]: Entering directory '/home/petmay01/linaro/qemu-for-merges/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/petmay01/linaro/qemu-for-merges/slirp' make: Nothing to be done for 'aarch64-softmmu/config-devices.mak.d'. make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/all' or that it needs to rerun minikconf, which would update the .mak.d. An extremely cheesy workaround would be if the commit which removes the hw/bt/Kconfig also touches configure; then Make will know it needs to rerun configure, which will (among other things) blow away all the config-devices.mak.d and force rerunning of minikconf. I don't know what the correct additional makefile magic would be that would cause us to automatically get deletion of a Kconfig file right; maybe Paolo does? thanks -- PMM
On 03/02/2020 15.50, Peter Maydell wrote: > On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote: >> >> On 03/02/2020 15.04, Peter Maydell wrote: >>> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: >>>> >>>> Hi Peter, >>>> >>>> the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: >>>> >>>> Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) >>>> >>>> are available in the Git repository at: >>>> >>>> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 >>>> >>>> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: >>>> >>>> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) >>>> >>>> ---------------------------------------------------------------- >>>> * Current qtests queue >>>> * Some Kconfig updates >>>> * Some trivial clean-ups here and there >>>> ---------------------------------------------------------------- >>> >>> All the incremental rebuilds failed: >>> >>> Linux cam-vm-266 4.15.0-70-generic x86_64 >>> From git://git-us.linaro.org/people/pmaydell/qemu-arm >>> f31160c7d1..f9e931a1d9 staging -> pmaydell/staging >>> make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' >>> make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' >>> make[1]: Nothing to be done for 'all'. >>> make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' >>> CC qga/main.o >>> CC stubs/machine-init-done.o >>> CC stubs/replay-user.o >>> CC stubs/semihost.o >>> CC qemu-img.o >>> CC qemu-io.o >>> CC chardev/char.o >>> make: *** No rule to make target >>> '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by >>> 'aarch64-softmmu/config-devices.mak'. Stop. >>> make: *** Waiting for unfinished jobs.... >>> CC chardev/char-mux.o >>> make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' >> >> Oh, they are still failing??? Why are there still references to >> hw/bt/Kconfig in these config-devices.mak files, I'd expect that they >> would have been regenerated at least once during the past week? > > build/all/aarch64-softmmu/config-devices.mak.d was most recently > touched this morning, and it still includes hw/bt/Kconfig in its > dependency list. I think this is because minikconf will still put > a Kconfig file into the .d file it generates even if the Kconfig > file happens to be empty. Oh, that's very weird. minikconf should only do that if the file is included somewhere, but the inclusion of hw/bt/Kconfig has been removed in 1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3 already, so this really should not happen anymore... Thomas
On 03/02/2020 15.57, Thomas Huth wrote: > On 03/02/2020 15.50, Peter Maydell wrote: >> On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote: >>> >>> On 03/02/2020 15.04, Peter Maydell wrote: >>>> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: >>>>> >>>>> Hi Peter, >>>>> >>>>> the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: >>>>> >>>>> Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) >>>>> >>>>> are available in the Git repository at: >>>>> >>>>> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 >>>>> >>>>> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: >>>>> >>>>> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) >>>>> >>>>> ---------------------------------------------------------------- >>>>> * Current qtests queue >>>>> * Some Kconfig updates >>>>> * Some trivial clean-ups here and there >>>>> ---------------------------------------------------------------- >>>> >>>> All the incremental rebuilds failed: >>>> >>>> Linux cam-vm-266 4.15.0-70-generic x86_64 >>>> From git://git-us.linaro.org/people/pmaydell/qemu-arm >>>> f31160c7d1..f9e931a1d9 staging -> pmaydell/staging >>>> make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' >>>> make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' >>>> make[1]: Nothing to be done for 'all'. >>>> make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' >>>> CC qga/main.o >>>> CC stubs/machine-init-done.o >>>> CC stubs/replay-user.o >>>> CC stubs/semihost.o >>>> CC qemu-img.o >>>> CC qemu-io.o >>>> CC chardev/char.o >>>> make: *** No rule to make target >>>> '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by >>>> 'aarch64-softmmu/config-devices.mak'. Stop. >>>> make: *** Waiting for unfinished jobs.... >>>> CC chardev/char-mux.o >>>> make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' >>> >>> Oh, they are still failing??? Why are there still references to >>> hw/bt/Kconfig in these config-devices.mak files, I'd expect that they >>> would have been regenerated at least once during the past week? >> >> build/all/aarch64-softmmu/config-devices.mak.d was most recently >> touched this morning, and it still includes hw/bt/Kconfig in its >> dependency list. I think this is because minikconf will still put >> a Kconfig file into the .d file it generates even if the Kconfig >> file happens to be empty. > > Oh, that's very weird. minikconf should only do that if the file is > included somewhere, but the inclusion of hw/bt/Kconfig has been removed > in 1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3 already, so this really > should not happen anymore... D'oh, MINIKCONF_INPUTS uses hw/*/Kconfig as wildcard ... that's why it still shows up ... darn, I need to think about how to get rid of this in a nice way... Thomas
On 03/02/20 15:50, Peter Maydell wrote: > > An extremely cheesy workaround would be if the commit which > removes the hw/bt/Kconfig also touches configure; then Make > will know it needs to rerun configure, which will (among > other things) blow away all the config-devices.mak.d and > force rerunning of minikconf. > > I don't know what the correct additional makefile magic > would be that would cause us to automatically get deletion > of a Kconfig file right; maybe Paolo does? Nope, sorry. :( Paolo
On 03/02/20 16:17, Paolo Bonzini wrote: > On 03/02/20 15:50, Peter Maydell wrote: >> >> An extremely cheesy workaround would be if the commit which >> removes the hw/bt/Kconfig also touches configure; then Make >> will know it needs to rerun configure, which will (among >> other things) blow away all the config-devices.mak.d and >> force rerunning of minikconf. >> >> I don't know what the correct additional makefile magic >> would be that would cause us to automatically get deletion >> of a Kconfig file right; maybe Paolo does? > > Nope, sorry. :( Wait, hw/*/Kconfig should not have to be added to minikconf.py's arguments. There are "source" lines in hw/Kconfig to do so. It does not fail because minikconf skips multiple includes of the same file, but it should be possible to remove it. Paolo
On Mon, Feb 03, 2020 at 02:50:07PM +0000, Peter Maydell wrote: > On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote: > > > > On 03/02/2020 15.04, Peter Maydell wrote: > > > On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@redhat.com> wrote: > > >> > > >> Hi Peter, > > >> > > >> the following changes since commit 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: > > >> > > >> Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 17:37:00 +0000) > > >> > > >> are available in the Git repository at: > > >> > > >> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 > > >> > > >> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: > > >> > > >> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) > > >> > > >> ---------------------------------------------------------------- > > >> * Current qtests queue > > >> * Some Kconfig updates > > >> * Some trivial clean-ups here and there > > >> ---------------------------------------------------------------- > > > > > > All the incremental rebuilds failed: > > > > > > Linux cam-vm-266 4.15.0-70-generic x86_64 > > > From git://git-us.linaro.org/people/pmaydell/qemu-arm > > > f31160c7d1..f9e931a1d9 staging -> pmaydell/staging > > > make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' > > > make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' > > > make[1]: Nothing to be done for 'all'. > > > make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' > > > CC qga/main.o > > > CC stubs/machine-init-done.o > > > CC stubs/replay-user.o > > > CC stubs/semihost.o > > > CC qemu-img.o > > > CC qemu-io.o > > > CC chardev/char.o > > > make: *** No rule to make target > > > '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by > > > 'aarch64-softmmu/config-devices.mak'. Stop. > > > make: *** Waiting for unfinished jobs.... > > > CC chardev/char-mux.o > > > make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' > > > > Oh, they are still failing??? Why are there still references to > > hw/bt/Kconfig in these config-devices.mak files, I'd expect that they > > would have been regenerated at least once during the past week? > > build/all/aarch64-softmmu/config-devices.mak.d was most recently > touched this morning, and it still includes hw/bt/Kconfig in its > dependency list. I think this is because minikconf will still put > a Kconfig file into the .d file it generates even if the Kconfig > file happens to be empty. > > And make doesn't have any rules that tell it that config-devices.mak.d > need to be updated either: > $ make -C build/all -n aarch64-softmmu/config-devices.mak.d > make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/all' > make[1]: Entering directory '/home/petmay01/linaro/qemu-for-merges/slirp' > make[1]: Nothing to be done for 'all'. > make[1]: Leaving directory '/home/petmay01/linaro/qemu-for-merges/slirp' > make: Nothing to be done for 'aarch64-softmmu/config-devices.mak.d'. > make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/all' > > or that it needs to rerun minikconf, which would update the .mak.d. > > An extremely cheesy workaround would be if the commit which > removes the hw/bt/Kconfig also touches configure; then Make > will know it needs to rerun configure, which will (among > other things) blow away all the config-devices.mak.d and > force rerunning of minikconf. > > I don't know what the correct additional makefile magic > would be that would cause us to automatically get deletion > of a Kconfig file right; maybe Paolo does? I guess this would need some munging of config-host.mak rule in the Makefile. config-host.mak would need to depend on something which scan for references to deleted Kconfig files, and then forces a re-run of config.status in some manner. Don't know how we'd write such a beast off hand though. Regards, Daniel
On 03/02/2020 16.29, Paolo Bonzini wrote: > On 03/02/20 16:17, Paolo Bonzini wrote: >> On 03/02/20 15:50, Peter Maydell wrote: >>> >>> An extremely cheesy workaround would be if the commit which >>> removes the hw/bt/Kconfig also touches configure; then Make >>> will know it needs to rerun configure, which will (among >>> other things) blow away all the config-devices.mak.d and >>> force rerunning of minikconf. >>> >>> I don't know what the correct additional makefile magic >>> would be that would cause us to automatically get deletion >>> of a Kconfig file right; maybe Paolo does? >> >> Nope, sorry. :( > > Wait, hw/*/Kconfig should not have to be added to minikconf.py's > arguments. There are "source" lines in hw/Kconfig to do so. It does > not fail because minikconf skips multiple includes of the same file, but > it should be possible to remove it. Right, I came to the same conclusion. Patch is on the way... Thomas