Josh DuBois <j...@joshdubois.com> writes: > On Aug 3, 2020, at 4:08 AM, Markus Armbruster <arm...@redhat.com> wrote: >> >>> >>> - prior to db25d56c014aa1a96319c663e0a60346a223b31e, just like today, >>> QEMU built with simple tracing will always produce a trace-<pid> file, >>> regardless of whether the user asks for traces at runtime. >> >> When you send a patch with a Fixes: tag, consider cc'ing people involved >> in the commit being fixed. I might have spotted the regression. > > Sure, this makes sense. > >> I missed the CLI issue. I just wanted my directories not littered with >> trace files ;) >> >> Stefan, what shall we do for 5.1? >> >> If we keep littering, the annoyance will make me drop the trace backend >> "simple" from my build tests. I might even remember to put it back when >> the fix arrives. > > I haven't seen another response, but I just noticed a 'last call' for 5.1. > If this means something is going to get excluded from regular build tests, > that seems important - I for one have no objection to simply reverting this - > 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4 <-- my "fix."
These are just my local build test. Our CI is not affected. Reverting is up to Stefan. > I will try to send a better fix along sometime soonish, but I probably won't > get to that before 5.1. If the nuisance of the trace-<pid> files is causing > real-world problems for someone actually doing regular development, that > seems more important than the command line issue, to me. Just my $0.02. > > Cheers, and sorry if your build dirs do end up littered again. Sorry for breaking your use case, and looking forward to your fix for your fix!
