Pavel Raiskup

Related RPM discussion: https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1682313430

Triage time: - could we have systemd timer for checking updated keys? - could we a dnf plugin post-transaction? (but this woudl be too verbose and visible, slowing things down)...

New ticket against DNF4 https://github.com/rpm-software-management/dnf/issues/2075

``` [26/Sep/2023:15:59:45 +0000] "POST /coprs/g/python/python3.8/delete/ HTTP/1.1" 504 247 "https://copr.fedorainfracloud.org/coprs/g/python/python3.8/delete/" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0" [26/Sep/2023:15:59:57 +0000] "POST /coprs/g/python/python3.9/delete/ HTTP/1.1" 504 247 "https://copr.fedorainfracloud.org/coprs/g/python/python3.9/delete/" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101...

Triage time: Ok, so while we are generating just a single action for backend-action processor, we remove the builds from Frontend's database one-by-one, and this likely takes more than 30s...

The workaround we used for Python projects was to set `--delete-after-days 0`.

Right, we actually prolong keys... but the public key is only copied to backend from keygen with new builds. Plus note #2894

@xsuchy already copy-pastes all the pub keys into distribution-gpg-keys-copr.rpm. At this time, we could automatically update all the out-dated pub keys on the backend side?

FTR: We prolong "year before expiration" of the old key.

I suppose that having the logic implemented in python3-copr (or some even more minimalistic library), we could re-use the logic even in python3-dnf-plugins-core (DNF4). Note e.g. the decisions that need...