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 <[email protected]> > --- > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#231435): https://lists.openembedded.org/g/openembedded-core/message/231435 Mute This Topic: https://lists.openembedded.org/mt/117894729/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
