Re: [PULL 00/13] qtests, kconfig and misc patches

[Thomas Huth]

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 <address@hidden> 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