Closed QuLogic closed 3 years ago
Hmm, this was a (possibly bad?) workaround for wait-repo warning about nvr is being latest yet in the target tag.
Basically what it does now is first wait for the next new-repo and then immediately it checks for the build there.
Hence the Successfully waited 0:00 for R-cpp11-0.2.2-1.fc3?~bootstrap to appear
.
Why is it waiting for a new
f3?-build
repo? This sometimes takes ages, even though waiting for the package to appear would have been finished.
Can you say more about what you are seeing? So far this had worked for me but it is quite possible there is some fault in the logic. Not sure if we are on the same page here.
Maybe I should combine those outputs in fbrnch to "normalize" it. (The longer term plan is also to replace using the python client for wait-repo, since it is also flaky.)
Waiting for f33-build
(for example) takes much much longer. I'm building something right now and can run koji wait-repo f33-build --build=...
which returns immediately, while fbrnch
is still waiting.
I left something running today; it waited on f32-build
/f31-build
for 2 hours and timed out. But the builds were in the repo way before then.
Okay I dropped the double wait-repo hack anyway in git - though it ought to have worked IMHO. Thanks for raising this issue. (Still wonder why it failed sometimes.)
Anyway encouraged by this issue, I have now implemented and committed native wait-repo in fbrnch - and I am planning to build it soon in copr. :-)
This should be fixed now in the 0.6 build with native wait-repo.
Seems to be working much better now.
When I do
fbrnch parallel -B
, I see:Why is it waiting for a new
f3?-build
repo? This sometimes takes ages, even though waiting for the package to appear would have been finished.