This bug is for tracking createrepo_c issue. We expect createrepo_c will be fixed soon but for the time being we have patched createrepo_c for Internal Copr purposes. Adding Fedora copr maintainer to CC, because it looks like createrepo_c is is not (yet) rebuilt for F25 in copr repo, while upstream plans to migrate to F25 soon. Thanks to Kamil Dudka for re-reporting this issue.
Michale, is that still necessary to use --ignore-lock option?
Note for myself: I can see that removing package on frontend leads to several "delete" asynchronous actions on backend. Each of them might lead to re-createrepo, and I bet at least there we might face some race-conditions.
This has been fixed in createrepo_c epel7 and fedora26+: https://src.fedoraproject.org/rpms/createrepo_c/c/6a445f4aa70d5b34820425f6502335efff3c3ff0?branch=master https://src.fedoraproject.org/rpms/createrepo_c/c/886dc79f77b09443d8973055cdee473acc85a6cb?branch=epel7 Since internal copr runs on F26 now, there's no need to track this anymore. There's still opened question whether the --ignore-lock is needed on copr backend so I'm switching this against upstream component.
Created attachment 1347182 [details] Stacktrace from createrepo_c
We still use f25 createrepo_c. Version : 0.10.0 Release : 6.pr64and66.fc25 That's why the error is still there. --ignore-lock Expert (risky) option: Ignore an existing .repodata/. (Remove the existing .repodata/ and create an empty new one to serve as a lock for other createrepo intances. For the repo‐ data generation, a different temporary dir with the name in format .repodata.time.microseconds.pid/ will be used). NOTE: Use this option on your own risk! If two createrepos run simultaneously, then the state of the generated metadata is not guaranted - it can be inconsistent and wrong. I am not understanding the whole thing here but according to last sentence, I think the --ignore-lock should be removed.
Fixed by https://pagure.io/copr/copr/c/995042811bd4e5042d256e2ccde03a305e14713f?branch=master
(In reply to clime from comment #5) > I am not understanding the whole thing here but according to last sentence, > I think the --ignore-lock should be removed. Absolutely, thank you. If there's any issue with concurrency, and the locks (huge delays), copr should make sure the concurrency doesn't happen (by e.g. converting createrepo command into proper task -- maintained by frontend, and executed by backend).
New COPR stack has been deployed.