Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a): > No, unfortunately the key is there, but the package is incomplete. > > If you have enabled gpg signatures verification, it would fail. At least > it does to me. > > Check it with: > > rpm -ql fedora-gpg-keys | grep fedora-34-$(arch) > > It just does not provide correct key.
Actually, yesterday I did update of another system with my approach and you are right that the fedora-gpg-keys-33-0.9 did not contained the proper links to the key. However, the fedora-gpg-keys-33-0.10 works just fine (not really sure what caused the difference). I did precisely: ~~~ $ sudo dnf update --disablerepo=rawhide --enablerepo=fedora fedora-gpg-keys --release 33 $ sudo dnf update fedora-repos\* --release 34 ~~~ Vít > The same issue is there for f31 > and f32. When you create platform link yourself, then you can upgrade > without turning off signature verification. > > I got mad it always breaks and prepared automated test [1]. Hope next > time rolling rawhide would be possible. I report issue with that every > release and got tired of it. It is a bit better now, but not great. > > 1. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/76 > 2. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/77 > > > On 8/25/20 12:16 PM, Vít Ondruch wrote: >> Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a): >>> Hi Vít, >>> >>> Unfortunately your workaround does not on my rawhide container. I think >>> the problem is in missing gpg keys from fedora-gpg-keys, which do not >>> contain also architecture specific keys. >>> >>> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys >>> fedora-repos-33-0.9.noarch >>> fedora-repos-rawhide-33-0.9.noarch >>> fedora-gpg-keys-33-0.9.noarch >>> >>> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update >>> fedora-gpg-keys >> >> The `--enablerepo=rawhide` is the issue IMO. >> >> You should understand, that Rawhide up to the branching point was F33 >> and signed by F33 key. So first you need to update to at least >> fedora-gpg-keys-33-0.9.noarch.rpm (and note the '33' there), which is >> signed by known F33 key but already contains the F34 key. Since that >> point you can use F34 packages signed by F34 key. > No, it should have worked this way, but it did not. Made pull request > for f32 update [2]. It should be done also for f31, if there is still > time for that. > >> >> Vít >> >> >>> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020. >>> Dependencies resolved. >>> ===================================================================================================================================== >>> Package Architecture >>> Version Repository Size >>> ===================================================================================================================================== >>> Upgrading: >>> fedora-gpg-keys noarch >>> 34-0.2 rawhide 105 k >>> >>> Transaction Summary >>> ===================================================================================================================================== >>> Upgrade 1 Package >>> >>> Total size: 105 k >>> Downloading Packages: >>> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded >>> >>> warning: >>> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm: >>> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY >>> Fedora - Rawhide - Developmental packages for the next Fedora release >>> 1.6 MB/s | 1.6 kB 00:00 >>> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64 >>> (0x9570FF31) is already installed >>> The GPG keys listed for the "Fedora - Rawhide - Developmental packages >>> for the next Fedora release" repository are already installed but they >>> are not correct for this package. >>> Check that the correct key URLs are configured for this repository.. >>> Failing package is: fedora-gpg-keys-34-0.2.noarch >>> GPG Keys are configured as: >>> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64 >>> The downloaded packages were saved in cache until the next successful >>> transaction. >>> You can remove cached packages by executing 'dnf clean packages'. >>> Error: GPG check FAILED >>> >>> I have complained two release before and this is still the same. It >>> always break on new release. The only option now is to install it by >>> hand from koji, where it is not yet signed (yuck!) >>> >>> # dnf install >>> https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm >>> >>> Then your commands would work, followed by normal upgrade. >>> >>> Filled bug #1872248 for it. It should finally work without user even >>> fiddling with gpg keys manually. Is there some pressure to keep users >>> from using rawhide? >>> >>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248 >>> >>> On 8/17/20 1:42 PM, Vít Ondruch wrote: >>>> Just as a reminder to all Rawhide users, this is the easiest way to keep >>>> using Rawhide after branching: >>>> >>>> >>>> ~~~ >>>> >>>> $ sudo dnf update fedora-gpg-keys >>>> >>>> $ sudo dnf update fedora-repos --release 34 >>>> >>>> ~~~ >>>> >>>> >>>> Unfortunately, there has been no progress on [1] during past months. >>>> >>>> >>>> >>>> Vít >>>> >>>> >>>> >>>> [1] https://pagure.io/releng/issue/7445 > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
