[HOWTO] Keep using Rawhide after branching

[Vít Ondruch]

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

[Zdenek Dohnal]

Thanks for the Howto, Víťa! Helps a lot!

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C

[Petr Menšík]

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
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/f...

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 
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

[Daniel P. Berrangé]

On Tue, Aug 25, 2020 at 11:40:21AM +0200, Petr Menšík wrote:
>  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. 
When you say "rawhide container", where are you pulling the base image
from ?  If you're pulling from docker.io, then perhaps you are hitting
the same problem as me, which is that the image hasn't been updated in
over a month:

https://lists.fedoraproject.org/archives/list/[e-mail].o...


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Petr Menšík]

Hi Daniel,

I am not using any base in fact. I am using container by systemd-nspawn.
I have installed it long ago by command from man systemd-nspawn, Example
2. at the bottom.

Since then I am trying rolling updates to keep it Raw(hide). It fails
every release once branched, because signatures cannot be verified.

I just do dnf upgrade from time to time, when I check something there.

My main issue is I am too stubborn to turn off gpg verification.
Instead, I want verification working.

It seems branching was almost correct this time. But fedora-repos-33-0.9
does not contain arch symlinks. And rawhide contains packages already
signed by the new key. Either install first gpg keys from koji, or
disable gpg when upgrading fedora-gpg-keys.

Best Regards,
Petr

On 8/25/20 12:05 PM, Daniel P. Berrangé wrote:
>  On Tue, Aug 25, 2020 at 11:40:21AM +0200, Petr Menšík wrote:
> > 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.
>  
>  When you say "rawhide container", where are you pulling the base image
>  from ?  If you're pulling from docker.io, then perhaps you are hitting
>  the same problem as me, which is that the image hasn't been updated in
>  over a month:
>  
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  
>  
>  Regards,
>  Daniel
>   
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

[kevin]

On Tue, Aug 25, 2020 at 04:49:05PM +0200, Petr Menšík wrote:
>  Hi Daniel,
>  
>  I am not using any base in fact. I am using container by systemd-nspawn.
>  I have installed it long ago by command from man systemd-nspawn, Example
>  2. at the bottom.
>  
>  Since then I am trying rolling updates to keep it Raw(hide). It fails
>  every release once branched, because signatures cannot be verified.
>  
>  I just do dnf upgrade from time to time, when I check something there.
>  
>  My main issue is I am too stubborn to turn off gpg verification.
>  Instead, I want verification working.
>  
>  It seems branching was almost correct this time. But fedora-repos-33-0.9
>  does not contain arch symlinks. And rawhide contains packages already
>  signed by the new key. Either install first gpg keys from koji, or
>  disable gpg when upgrading fedora-gpg-keys. 
Right, aside from that bug/issue it should have worked to just update
fedora-gpg-keys and fedora-repos. 

kevin

[Vít Ondruch]

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.


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/f...
>
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Petr Menšík]

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. 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/f...
> >
> > 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
> > 
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

[Vít Ondruch]

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/f...
> >>
> >> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Adam Williamson]

On Fri, 2020-08-28 at 18:51 +0200, Vít Ondruch wrote:
>  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). 
The change to archmap in this commit:
https://src.fedoraproject.org/rpms/fedora-repos/c/5f02f474842d23a0217c111...
which landed between 0.9 and 0.10 (the versioning was fixed up in the
next commit).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Vít Ondruch]

Dne 28. 08. 20 v 19:09 Adam Williamson napsal(a):
>  On Fri, 2020-08-28 at 18:51 +0200, Vít Ondruch wrote:
> > 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).
>  The change to archmap in this commit:
>
> https://src.fedoraproject.org/rpms/fedora-repos/c/5f02f474842d23a0217c111...
>  which landed between 0.9 and 0.10 (the versioning was fixed up in the
>  next commit). 

Thx, right, I have missed that. Pretty confusing series of commits :(


Vít

[kevin]

On Fri, Aug 28, 2020 at 06:51:24PM +0200, Vít Ondruch wrote:
>  
>  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: 
the 0.9 one was broken. Incorrect. Had a bug. Mistaken. Not right. 
Not represenative of how the process is supposed to work. 

The 0.10 one was fixed and should behave as you note, and work to
upgrade to rawhide without disabling any gpg key. 

Sorry this time it wasn't correct. Mistakes happen. 

kevin

[Petr Menšík]

Okay, found more correct workaround, this time without required
ignoration of gpg signatures.

Just use:

(sudo) dnf --disablerepo rawhide --enablerepo updates \
           upgrade fedora-gpg-keys
(sudo) ln -s /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-{primary,$(arch)}
(sudo) dnf --repo rawhide --releasever 34 upgrade \
           fedora-gpg-keys fedora-repos fedora-repos-rawhide


Then just
(sudo) dnf upgrade

Correct key made it into updates, but no architecture symlinks were
provided.

On 8/25/20 11:40 AM, Petr Menšík wrote:
>  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
>  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/f...
>  
>  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 
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

[Mattia Verga]

Il 25/08/20 11:40, Petr Menšík ha scritto:
>  Hi Vít,
>
>  Unfortunately your workaround does not on my rawhide container.
>  ... 
I just did

~~~

$ sudo dnf update fedora-gpg-keys --nogpgcheck

$ sudo dnf update fedora-repos --release 34

~~~

[Petr Menšík]

Of course this would "solve" issue with GPG signature. It opens door for
man-in-the-middle attack without any protection. But I am aware there
are no many better fixes. There is one with arch symlink, allowing
continued GPG verification.

On 8/25/20 5:56 PM, Mattia Verga via devel wrote:
>  Il 25/08/20 11:40, Petr Menšík ha scritto:
> > Hi Vít,
> >
> > Unfortunately your workaround does not on my rawhide container.
> > ...
>  
>  I just did
>  
>  ~~~
>  
>  $ sudo dnf update fedora-gpg-keys --nogpgcheck
>  
>  $ sudo dnf update fedora-repos --release 34
>  
>  ~~~
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB