On Tue, 12/05 16:11, David Gibson wrote: > On Tue, Dec 05, 2017 at 01:05:58PM +0800, Fam Zheng wrote: > > On Tue, 12/05 06:49, Michael S. Tsirkin wrote: > > > On Wed, Nov 29, 2017 at 05:18:47PM +0800, Fam Zheng wrote: > > > > On Wed, 11/29 01:02, no-re...@patchew.org wrote: > > > > > /tmp/cc3Czn0R.s: Fatal error: can't write 3947 bytes to section > > > > > .debug_str of hw/arm/virt-acpi-build.o because: 'No space left on > > > > > device' > > > > > > > > Hmm, the host is shared and what I have is a normal user account, so > > > > there is no > > > > control over disk space availability. Anyway this is completely > > > > unrelated to > > > > this series. Sorry for the noise. > > > > > > > > Fam > > > > > > Could you disable this until you have the time to detect disk full > > > errors? You are training people to ignore this bot, not a good thing. > > > > > > > Thanks for the suggestion. I've added a string match to the notification > > condition. The problem is disk is only one factor, I dream of an AI that > > can be > > trained to tell which errors are geniune bugs of the patch and which are > > environment failures... :) > > Another approach would be to have a "known good" build that runs every > so often. If the known good build fails, the bot disables itself (and > tells you to investigate). Obviously there are ways that could not > work as well, but it should catch a fair range of spurious failures.
Interesting idea, yes. A slightly simplified way is to test the "base" of the series and only report errors if the base can pass. Fam