tickets #45857

packages stuck in finished state for several hrs

Added by aplanas over 2 years ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Hi and happy 2019!

I have in my home (home:aplanas) several packages that, once compiled, do not
move to success. Lets take two:

I waited for more that six hours yesterday for the first package, a medium
size Python package (salt). So far I wait for 40 minutes for this package,
even if the finished state shows a success final state (you can see it in the

I do not know very well the architecture of OBS, but I believe that there is
some scheduler that needs to pick this package and move it to the next state.
I guess that this scheduler is waiting for something else, so it cannot move
it to the success state, even if the RPMs are already there. I wonder what it
is and what I can do to make this process faster, as I need to iterate fast
for this package.

Thanks for the help!

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany


#1 Updated by cboltz over 2 years ago

  • Category set to OBS
  • Assignee set to opensuse-admin-obs
  • Private changed from Yes to No

#2 Updated by lrupp over 1 year ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

The source code of OBS is available at - is running the master branch.

Depending on the available hardware resources and the current queues, it might indeed take quite some time for a package to get picked up for building.

A good overview can be found at the bottom of - which, for example, shows that armv7l packages might need up to 3 days to get picked up, while it takes around 5 minutes for x86_6. This is a current snapshot and the values might be different in a few.minutes again. But I think it explains that hardware IS a key part.

On the other side, there might be a possibility to optimize the code as well...

In any case: contributions are welcome!

Sorry for not being able to really help and just pointing on areas for improvement. But without investment (HW and/or time for development), there is not much we can do.


Also available in: Atom PDF