Re: [OE-core] [PATCH][RESEND] sstate.bbclass: Always show a progress bar if an sstate summary is wanted

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2026-02-19 at 17:21 +0100, Peter Kjellerstedt via lists.openembedded.org wrote:
> In case sstate_checkhashes() is expected to show an sstate summary, then
> always show the process progress bar regardless of how long the task
> list is. Without this, the sstate summary could unintentionally
> overwrite another active progress bar.
> 
> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> ---
>  meta/classes-global/sstate.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-global/sstate.bbclass
> index 2fd29d7323..6f72490065 100644
> --- a/meta/classes-global/sstate.bbclass
> +++ b/meta/classes-global/sstate.bbclass
> @@ -1048,7 +1048,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True,
>  
>              ## thread-safe counter
>              cnt_tasks_done = itertools.count(start = 1)
> -            progress = len(tasklist) >= 100
> +            progress = summary or len(tasklist) >= 100
>              if progress:
>                  msg = "Checking sstate mirror object availability"
>                  bb.event.fire(bb.event.ProcessStarted(msg, len(tasklist)), d)

This has sat in the review queue for a while since I haven't found the
time to reply. I suspect you're going to disagree with me and I really
haven't had the time to have a discussion on it.

For reference, whilst the patch was removed from master-next, it is
still in the review queue here:

https://git.openembedded.org/openembedded-core-contrib/log/?h=master-backlog

(and mentioned in the status report about review call changes)

Since you're now forcing me to reply about this, I'm confused by what
"unintentionally overwrite" means in the commit message since it would
seemingly only do that if it shows progress and you're making it always
show progress. That would be in theory worse, but consistent.

The intent behind the "100" limit was to only show the progress bar if
there is a decent chunk of work to be done, rather than flash it onto
the screen then off again. I think that reasoning is still valid,
showing progress bars for things which happen more quickly than the
progress is useful for is a bit pointless.

So at the very least we need to be clear what the commit message means
but I'm not keen on the removal of the 100 limit.

There were other fixes around the progress bar handling and I am also
wondering if this issue was still relevant too.

Cheers,

Richard