On 28/10/2026 16:08, Tom Rini wrote:
> 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?
>
Absolutely. Simon G. mentioned this too. I will use
disable_check('error_notification') where appropriate in James'
series.
Thanks,
--
Jerome
