On Tue, Oct 01, 2024 at 08:49:26AM +0100, Peter Robinson wrote: > On Tue, 1 Oct 2024 at 01:42, Tom Rini <tr...@konsulko.com> wrote: > > > > On Tue, Oct 01, 2024 at 01:38:56AM +0200, Heinrich Schuchardt wrote: > > > On 26.09.24 23:59, Simon Glass wrote: > > > > We don't want ANSI characters written in tests since it is a pain to > > > > check the output with ut_assert_nextline() et al. > > > > > > > > Provide a way to tests to request that ANSI characters not be sent. > > > > > > > > Add a proper function comment while we are here, to encourage others. > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > > > Please, consider prior review before resubmitting patches. > > > > > > As responded to all prior submissions: > > > > > > We want to test the code running on actual machines. > > > We don't want to have sandbox code everywhere. > > > > > > I cannot see any test that is not passing due to the current behavior. > > > > The pytests for the EFI selftests are unreliable for me, on Raspberry Pi > > 3, more often in 32bit mode than 64bit mode, but I feel like I see it > > there too. And when they fail, the console log is full of ANSI escape > > sequences. Is this specific test a test you run regularly on real > > hardware? > > Is it possible there's a bug in the RPi support somewhere that's > causing these issues that is triggered more easily with the ASCI > codes?
I don't think so, in that I thought I saw it on other platforms as well, but I don't have the logs anymore. I'll see if I can trigger a failure again. -- Tom
signature.asc
Description: PGP signature
