configs: Rawhide to accept GPG key from future Fedora Rawhide+1

[praiskup]

Fixes: #1338

[keszybz]

Thanks! My only qualm is what happens if the key doesn't exist yet? We don't want any kind of warning or error in that case. Hmm, I think we get an error if they key doesn't exist:

cannot open file: (2) - No such file or directory [/usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-46-primary]

I think this should be wrapped in a check whether the key actually exists.

[praiskup]

Good point, I installed this fatal error into the branching script:

File /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-43-primary not found!

The new Fedora Rawhide (42) requires a GPG key for Fedora 43,
which must be generated by Fedora Infrastructure team and shipped in the
distribution-gpg-keys.rpm package.  This either has not happened yet, the
package is outdated, or it is not even installed on this box.

[praiskup]

This time, F42 key was generated on 2024-02-12.
The plan was to have it about ~14 days before signing rawhide with f41 key, which IMO happened (the mass rebuild took a bit more time). Not sure.
Mock-core-configs with branched F40 2024-02-14. Which was admittedly too late, it would be nice to do that 14 days earlier next time.

[xsuchy]

I have to say that I am not happy for this PR. IMO this will bring a new issue when we submit new config earlier than before branching (missing key).
I would rather resolve it by dynamically using number for rawhide. Likely using python-fedora-distro-aliases https://github.com/rpm-software-management/fedora-distro-aliases In such case we would not need to touch rawhide config after branching at all!

[praiskup]

"fedora-repos update with the new keys is available in updates-testing" is though something different, I think that we should have a new entry in the F41 schedule like

Generate Fedora N+2 key and ship in fedora-repos

Somewhere in the Fedora 41 schedule. To have a guidance that assures everything works.

[praiskup]

I have to say that I am not happy for this PR. IMO this will bring a new issue
when we submit new config earlier than before branching (missing key).

If we can get a new step into the Fedora release schedule, then this problem
would be non-existing.

I would rather resolve it by dynamically using number for rawhide. Likely
using python-fedora-distro-aliases
https://github.com/rpm-software-management/fedora-distro-aliases In such case
we would not need to touch rawhide config after branching at all!

This is being tracked here #1328 - though :-/ it's going to be a big change in
the way mock and core-configs behave.

[xsuchy]

I tried this with DNF4 and DNF5 and it prints no error when the file does not exists and it is silently ignored. Not sure if this is generally good, but for our case it is good.
I changed my mind and I am +1

[packit-as-a-service]

We were not able to find or create Copr project packit/rpm-software-management-mock-1342 specified in the config with the following error:

Cannot create a new Copr project (owner=packit project=rpm-software-management-mock-1342 chroots=['fedora-rawhide-x86_64', 'fedora-40-x86_64']): Copr: 'packit/rpm-software-management-mock-1342' already exists. Copr HTTP response is 400 BAD REQUEST.

---

Unless the HTTP status code above is >= 500, please check your configuration for:

1. typos in owner and project name (groups need to be prefixed with @)
2. whether the project name doesn't contain not allowed characters (only letters, digits, underscores, dashes and dots must be used)
3. whether the project itself exists (Packit creates projects only in its own namespace)
4. whether Packit is allowed to build in your Copr project
5. whether your Copr project/group is not private

[xsuchy]

I manually rebased this and merged as 66ca1e4