Re: Running rawhide mockbuild on Fedora 33 fails with GPG check

[Matt Domsch via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx>]

One problem is mock doesn't have the right GPG key for rawhide at this point.  It's easy to fix.

# ls -al /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-*

...

-rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary
-rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary
-rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary
lrwxrwxrwx. 1 root root   29 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary -> RPM-GPG-KEY-fedora-35-primary

# cd /usr/share/distribution-gpg-keys/fedora/
# rm RPM-GPG-KEY-fedora-rawhide-primary
rm: remove symbolic link 'RPM-GPG-KEY-fedora-rawhide-primary'? y
# ln -s RPM-GPG-KEY-fedora-36-primary RPM-GPG-KEY-fedora-rawhide-primary

Furthermore,  /etc/mock/templates/fedora-rawhide.tpl has hard-coded version 35 which needs to bump to 36.

There's a second problem, that fedora-review claims to take a --mock-config= option, but it seems not to work. It always wants to build for rawhide.

Thanks,

Matt

On Sun, Aug 15, 2021 at 7:06 AM Otto Urpelainen <oturpe@xxxxxx> wrote:

Sérgio Basto kirjoitti 15.8.2021 klo 3.12:
> Hi,
>
> I'm seeing the same problem,  for a quick fix, we need update
> /etc/mock/templates/fedora-rawhide.tpl line 12 with
> config_opts['releasever'] = '36', as reference [1] ...
>
> We need a new mock-core-configs package with configurations for "Fedora
> 35 branched" some work in progress here [2]

Having followed the Fedora process for some time now, I have noticed
that issues of this kind happen at every branching.

I wonder if more things could work like dist-git branches already do,
where rawhide is always rawhide, branching does not affect it, and
branched releases receive a new configuration at the moment of
branching? Opposed to that, Mock and other places follow a model where
rawhide is Fedora N+1 and branching means a) reconfiguring rawhide as
Fedora N+2 and b) creating a new configuration for the actual Fedora
N+1. The need to do a) means that rawhide easily breaks when branching
occurs.

When you branch B off from A, it is understandable that B won't be
completely functional until the branching is completed. But there should
be no reason for A to stop working, simply because there should not be
any reason to modify A at all.

I am not very familiar with Mock internals, but I suppose that Mock is
*not* one of the places where such change of approach would be easy. I
suppose it has a relation with dist tags, and if you changed rawhide's
dist tag from 'fc(n+1)' to 'rawhide', you should probably do mass
rebuild only after branching to get dist tag right in the branched
release. And you would probably have to consider a lot of other things, too.

But there are also places where it would be easy to avoid breakage
simply calling rawhide, 'rawhide': At least the thing where a Toolbox
container build from f34 image can be either actually Fedora 34 or
Fedora Rawhide, depending on things [1].

[1]: https://github.com/containers/toolbox/issues/722
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure