tickets #45857
closedpackages stuck in finished state for several hrs
100%
Description
Hi and happy 2019!
I have in my home (home:aplanas) several packages that, once compiled, do not
move to success. Lets take two:
https://build.opensuse.org/package/show/
home:aplanas:branches:systemsmanagement:saltstack:testing/salt
https://build.opensuse.org/package/show/home:aplanas:Images/test-image-iso
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
logs)
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
Updated by cboltz over 5 years ago
- Category set to OBS
- Assignee set to opensuse-admin-obs
- Private changed from Yes to No
Updated by lrupp over 4 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
The source code of OBS is available at https://github.com/openSUSE/open-build-service - build.opensuse.org 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 https://build.opensuse.org/monitor/old - 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.
Regards,
Lars