View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000262||AlmaLinux-8||rpm||public||2022-06-07 09:09||2022-08-16 19:41|
|Summary||0000262: recurring issue: base and appstream repositories cannot be synchronized using pulp-rpm|
|Description||I use pulp-rpm (v3) to synchronize the base and appstream repos from http://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os/ and https://repo.almalinux.org/almalinux/8/AppStream/x86_64/os/ respectively.|
I try to run the sync script once a week. Sometimes it works, sometimes it fails with the following error:
"Incoming and existing advisories have the same id and timestamp but different and intersecting package lists, and neither package list is a proper subset of the other. At least one of the advisories is wrong. To allow this behavior, set ALLOW_AUTOMATIC_UNSAFE_ADVISORY_CONFLICT_RESOLUTION = True (q.v.) in your configuration. Advisory id: ALSA-2019:2720"
(This advisory ID may not always be the same.)
I have learnt that deleting and recreating the pulp repository "solves" the problem but I lose the previous versions - keeping these would be one of the purposes of pulp.
|Steps To Reproduce||- create repository and remote in pulp-rpm (like this: https://docs.pulpproject.org/pulp_rpm/workflows/create_sync_publish.html )|
- synchronize the repository with the remote once a week
- sometimes it works, sometimes it fails. I failed at least 5 times in the last 12 months. It failed twice in the last month.
|Additional Information||I have several other (non-AlmaLinux) repositories in pulp and they do work.|
I only have seen this type of error with AlmaLinux repos.
I work on Pulp and a few other users have complained about this as well, both in the past and recently with this specific advisory (hence why I'm here).
This warning gets triggered when the advisory in the remote repo was changed at least once *after* being pushed but without changing the updated date metadata, and doing some weird things with the package list that make it difficult to decide what to make of it. I'm not sure what the specifics are in this case, however.
If someone has access to figure out what changed between the first and second revision of that advisory, I can try to provide some guidance on what ought to be done on your side (or if it seems reasonable, try to relax the restriction a bit on our side).