Bug 14479 - bitbake initally shows zero tasks
Summary: bitbake initally shows zero tasks
Status: RESOLVED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 4.99
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2021-07-13 14:25 UTC by Frans Meulenbroeks
Modified: 2021-09-11 21:40 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Frans Meulenbroeks 2021-07-13 14:25:12 UTC 

    


    


      



        
          Comment 1
        

        
          Frans Meulenbroeks

        

        
        

        
          2021-07-13 14:28:05 UTC
        

      






Oops, pressed enter before adding text

When starting a build I got


NOTE: Executing Tasks
Currently  8 running tasks (0 of 0) 100% |                                     |
0: systemd-compat-units-1.0-r29 do_populate_sysroot_setscene - 0s 

The 0 of 0 part is very odd as there are several running tasks.

After the setscene tasks are completed the 0 numbers changed.
But the initial 0 of 0 looks quite odd

    


    


      



        
          Comment 2
        

        
          Richard Purdie

        

        
        

        
          2021-07-15 14:44:16 UTC
        

      






The numbers refer to task numbers, not setscene task numbers. This problem is harder to solve than you'd think as now we have hash equivalence, setscene tasks can be discounted and marked as failed, then run when hash equivalence adds task availability.

    


    


      



        
          Comment 3
        

        
          Richard Purdie

        

        
        

        
          2021-09-10 18:59:48 UTC
        

      






I've sent a patch to the mailing list which should improve this situation by cleaning up runqueue's task handling