On Wed, Oct 28, 2026 at 10:01:10AM +0100, Jerome Forissier wrote:
> Hi Tom,
> 
> On 27/10/2026 18:33, Tom Rini wrote:
> > On Tue, Oct 27, 2026 at 05:02:12PM +0100, Jerome Forissier wrote:
> > 
> >> Some tests intentionally trigger diagnostics that the Python console
> >> parser treats as unexpected errors.
> >>
> >> Add helpers that silence these diagnostics while preserving the previous
> >> console state, allowing tests to hide expected errors without accessing
> >> global data directly.
> >>
> >> Signed-off-by: Jerome Forissier <[email protected]>
> >> ---
> >>  include/test/ut.h | 17 +++++++++++++++++
> >>  test/ut.c         | 15 +++++++++++++++
> >>  2 files changed, 32 insertions(+)
> >>
> >> I am proposing this patch as a prerequisite to merging the series "net:
> >> lwip: restore TFTP client and command parity" by James H. [1] which would
> >> otherwise introduce a CI error [2]. The error is fixed in pipeline 1762
> >> [3].
> >>
> >> [1] 
> >> https://lore.kernel.org/u-boot/20261024-submit-lwip-tftp-combined-v1-v2-0-0f663f735...@gmail.com/
> >> [2] 
> >> https://git.u-boot-project.org/u-boot/custodians/u-boot-net/-/jobs/128187#L3716
> >> [3] 
> >> https://git.u-boot-project.org/u-boot/custodians/u-boot-net/-/pipelines/1762
> > 
> > Sorry, what's the unexpected error line(s) in 2?
> > 
> 
> The failed test is tftp_test_protected_autostart(). The unexpected
> error is:
> 
>   ## Error: !
> 
> The test marks "autostart" read-only and then calls the TFTP download
> helpers, expecting them to fail [4]. The helpers reach netboot_run(),
> which tries to set "autostart" to "no" [5]. The environment code [6]
> consequently starts printing:
> 
>   ## Error: Can't overwrite "autostart"
> 
> The Python console parser defines "## Error: " as an error pattern [7].
> It registers that pattern in the list of bad console patterns [8].
> While waiting for the U-Boot prompt, run_command() matches the bad
> patterns and raises BootFail [9]. The match occurs as soon as the
> "## Error: " prefix is received, hence the truncated diagnostic followed
> by pytest's "!" failure marker.
> 
> The amended test fixes this by silencing the console only around the
> calls expected to fail and restoring its previous state afterwards [10].

Ah. But looking at test/py/tests/test_env.py we have a test doing:
def test_env_printenv_non_existent(state_test_env):
    """Test printenv error message for non-existant variables."""

    var = state_test_env.set_var
    c = state_test_env.ubman
    with c.disable_check('error_notification'):
        response = c.run_command('printenv %s' % var)
    assert response == '## Error: "%s" not defined' % var

So can we do something similar for this test?

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to