Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to sign fedora-repos and fedora-release packages by older key to allow smooth updates?
Vít
On 3/11/19 7:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to sign fedora-repos and fedora-release packages by older key to allow smooth updates?
I was able to update by first manually updating the keys via:
cd /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages rpm -Uvh \ fedora-gpg-keys-31-0.1.noarch.rpm \ fedora-release-31-0.1.noarch.rpm \ fedora-release-common-31-0.1.noarch.rpm \ fedora-repos-31-0.1.noarch.rpm \ fedora-repos-rawhide-31-0.1.noarch.rpm
Then I was able to do a normal "dnf update --refresh".
Note that your package directory location may be slightly different. I don't know if the "rawhide-2d95c80a1fa0a67d" part is consistent or just where mine happened to be. But if you search for one of the "keys" packages inside the dnf cache area you should be able to find it.
Steve
Hi,
I suspect it's a chicken and egg issue: * Look at /etc/yum.repos.d/fedora-rawhide.repo * You can see the line: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch * But "$releasever" is determined by the version of "fedora-release" package. * So dnf, tries to (re)import f30 gpg key. * The import is OK, but doesn't help, because packages are signed with f31 key.
I cannot test it now, since I already did the "manual upgrade" workaround yesterday. Anyone that want to check it: * Temporarily edit "gpgkey" and modify "$releasever" to "31" * Use dnf to upgrade and check if it imports the new GPG key and work correctly.
Bye,
On 11/03/19 12:31 +0100, Vít Ondruch wrote:
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Good question; have observed this over several (if not all since to-be-f26 based Rawhide) jumps like that, and always have solved this inconvenience by hand and moved on.
GPG signatures related must-do consequence of branching for those using mock with the branched + Rawhide targets is also to update mock-core-configs, which is currently also not very straightforward and could perhaps be handled more gracefully: https://bugzilla.redhat.com/show_bug.cgi?id=1686869
On 11/03/19 15:01 +0100, Jan Pokorný wrote:
On 11/03/19 12:31 +0100, Vít Ondruch wrote:
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Good question; have observed this over several (if not all since to-be-f26 based Rawhide) jumps like that, and always have solved this inconvenience by hand and moved on.
GPG signatures related must-do consequence of branching for those using mock with the branched + Rawhide targets is also to update mock-core-configs, which is currently also not very straightforward and could perhaps be handled more gracefully: https://bugzilla.redhat.com/show_bug.cgi?id=1686869
Actually, fedora:rawhide container from Docker Hub (in CI scenario here) is affected with this problem as well (cannot update with the new-key-signed f30/f31 packages because of this, making the CI procedure fail[*]).
Should not at least the "official container images" follow the branching point automatically and promptly to prevent GPG signature imposed disruptions ASAP?
[*] https://gitlab.com/poki/pacemaker/-/jobs/175445117
On 11/03/19 18:05 +0100, Jan Pokorný wrote:
On 11/03/19 15:01 +0100, Jan Pokorný wrote:
On 11/03/19 12:31 +0100, Vít Ondruch wrote:
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Good question; have observed this over several (if not all since to-be-f26 based Rawhide) jumps like that, and always have solved this inconvenience by hand and moved on.
GPG signatures related must-do consequence of branching for those using mock with the branched + Rawhide targets is also to update mock-core-configs, which is currently also not very straightforward and could perhaps be handled more gracefully: https://bugzilla.redhat.com/show_bug.cgi?id=1686869
Actually, fedora:rawhide container from Docker Hub (in CI scenario here) is affected with this problem as well (cannot update with the new-key-signed f30/f31 packages because of this, making the CI procedure fail[*]).
Should not at least the "official container images" follow the branching point automatically and promptly to prevent GPG signature imposed disruptions ASAP?
Not sure if this is thanks to the images indeed being periodically updated (image's sha256 changed from 1c2065c021750bfa8b1530d2cce08dffda03f0fbe5fba4f21b29fc8e909954a9 to eff97b05aaa6ef5b3444fc95cc8b340266ea63474dca3f557f07ccfd70f1fee1 between failed vs. successful run), but everything is back to normal now, and this symptom of the failed "dnf update" with fedora:rawhide went away, too:
Importing GPG key 0xCFC659B9: Userid : "Fedora (30) fedora-30-primary@fedoraproject.org" Fingerprint: F1D8 EC98 F241 AAF2 0DF6 9420 EF3C 111F CFC6 59B9 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-30-x86_64 Key imported successfully Import of key(s) didn't help, wrong key(s)?
All in all, Would be preferred if this was glitch-free all the time.
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
* branching * f30 repos gets the f31 key * you update your f30-repos * you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to sign fedora-repos and fedora-release packages by older key to allow smooth updates?
The f30 repos should already include the f31 key.
https://src.fedoraproject.org/rpms/fedora-repos/c/81ae6bcd584818d890f7939658...
You can also get it from there: https://src.fedoraproject.org/rpms/fedora-repos/raw/f30/f/RPM-GPG-KEY-fedora...
kevin
On Mon, Mar 11, 2019 at 7:30 PM Kevin Fenzi kevin@scrye.com wrote:
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
I'm having a similar problem, but with Silverblue / rawhide.
I installed the system when rawhide was still f30, but now I can't run "rpm-ostree upgrade" anymore, due to this error:
Enabled rpm-md repositories: rawhide Updating metadata for 'rawhide'... done error: Failed to download gpg key for repo 'rawhide': Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]
So I'm *VERY* sure that I didn't mess with the system myself (since it's a Silverblue installation), but still it's broken due to the missing GPG keys.
Fabio
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there.
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to sign fedora-repos and fedora-release packages by older key to allow smooth updates?
The f30 repos should already include the f31 key.
https://src.fedoraproject.org/rpms/fedora-repos/c/81ae6bcd584818d890f7939658...
You can also get it from there:
https://src.fedoraproject.org/rpms/fedora-repos/raw/f30/f/RPM-GPG-KEY-fedora...
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Mar 11, 2019, at 2:46 PM, Fabio Valentini wrote:
I'm having a similar problem, but with Silverblue / rawhide.
I installed the system when rawhide was still f30, but now I can't run "rpm-ostree upgrade" anymore, due to this error:
Enabled rpm-md repositories: rawhide Updating metadata for 'rawhide'... done error: Failed to download gpg key for repo 'rawhide': Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]
Hi, edit /etc/ostree/remotes.d/fedora-workstation.conf to look like this:
https://github.com/coreos/fedora-coreos-tracker/issues/143#issuecomment-4611...
This will fix the GPG key issue and also give you much faster updates. We have work in flight to try to ship this by default.
On Tue, Mar 12, 2019 at 1:55 PM Colin Walters walters@verbum.org wrote:
On Mon, Mar 11, 2019, at 2:46 PM, Fabio Valentini wrote:
I'm having a similar problem, but with Silverblue / rawhide.
I installed the system when rawhide was still f30, but now I can't run "rpm-ostree upgrade" anymore, due to this error:
Enabled rpm-md repositories: rawhide Updating metadata for 'rawhide'... done error: Failed to download gpg key for repo 'rawhide': Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]
Hi, edit /etc/ostree/remotes.d/fedora-workstation.conf to look like this:
https://github.com/coreos/fedora-coreos-tracker/issues/143#issuecomment-4611...
This will fix the GPG key issue and also give you much faster updates. We have work in flight to try to ship this by default.
Thanks for the response, but that didn't help with dnf failing the GPG check. I think ugrading from f30-rawhide to f31-rawhide is broken in general - I had to disable gpgchecks for _both_ the ostree remote and the rawhide dnf repo to make `rpm-ostree upgrade` succeed.
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 3/11/19 11:45 AM, Fabio Valentini wrote:
I'm having a similar problem, but with Silverblue / rawhide.
I installed the system when rawhide was still f30, but now I can't run "rpm-ostree upgrade" anymore, due to this error:
Enabled rpm-md repositories: rawhide Updating metadata for 'rawhide'... done error: Failed to download gpg key for repo 'rawhide': Curl error (37):
Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64]
So I'm *VERY* sure that I didn't mess with the system myself (since it's a Silverblue installation), but still it's broken due to the missing GPG keys.
Yeah, so the problem is that you were on f30 and then braching happend and suddenly you were on f31 before you had a chance to pick up the updated fedora-repos-30 with the 31 key in it.
We need to revamp this entirely, and as luck would have it, we have a plan:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
How does this plan work with silverblue? Not sure... could use some input from them.
kevin
Dne 12. 03. 19 v 19:49 Kevin Fenzi napsal(a):
We need to revamp this entirely, and as luck would have it, we have a plan:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I am afraid that this will not help in this situation, because even if $releasever will be equal to "rawhide" you still will have in repo file: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
which will have prior the branching *content* of F30 gpg key. Then after branching (let say 4 weeks later) you will run 'dnf upgrade'. It will try to download new fedodra-gpg-keys package, which will be signed by F31 gpg key. IMO the only solution to this is: * create new gpg keys several months before branching and add it to fedodra-gpg-keys package and * gpgkey in repo file lists both gpg keys or * sign rpm packages in rawhide by both keys - and I'm afraid our infrastructure is not ready for this.
Miroslav
On 3/13/19 3:33 AM, Miroslav Suchý wrote:
Dne 12. 03. 19 v 19:49 Kevin Fenzi napsal(a):
We need to revamp this entirely, and as luck would have it, we have a plan:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I am afraid that this will not help in this situation, because even if $releasever will be equal to "rawhide" you still will have in repo file: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch> which will have prior the branching *content* of F30 gpg key. Then after branching (let say 4 weeks later) you will run 'dnf upgrade'. It will try to download new fedodra-gpg-keys package, which will be signed by F31 gpg key.
Yeah.
IMO the only solution to this is:
- create new gpg keys several months before branching and add it to fedodra-gpg-keys package and
Yep. We should do this, but note that this only partly solves it. What if I have a rawhide machine from when rawhide was f29 say or older and decide to try and update it? :) Of course you should always update your rawhide machines frequently.
but it would help. We could even just generate them always at least a release in advance. ie, make sure the f32 key goes out with f30.
- gpgkey in repo file lists both gpg keys
So, you mean current rawhide should list the f31 key and the (not yet made) f32 key? yeah, we could do that I think. I haven't tested, but man dnf.conf implies you can specify multiple keys per repo.
or
- sign rpm packages in rawhide by both keys - and I'm afraid our infrastructure is not ready for this.
I persued this. Our infrastructure is fine with it... but rpm isn't. https://github.com/rpm-software-management/rpm/issues/189
kevin
On Tue, Mar 12, 2019, at 2:50 PM, Kevin Fenzi wrote:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
How does this plan work with silverblue? Not sure... could use some input from them.
It's the same model for Fedora CoreOS btw; so terminology may be "ostree-based systems" or so.
An important thing to bear in mind here is there's a big difference between "dnf" and "libdnf" in this particular respect: https://github.com/rpm-software-management/libdnf/issues/43
rpm-ostree (and PackageKit) link libdnf. "dnf" today is still in progress of using libdnf in various places, and last I looked dnf still uses GPG code derived from yum.
So for anything using libdnf which auto-imports all keys in /etc/pki/rpm-gpg, AFAIK the only thing we need to do is ship the new version N+1 key as an update to version N systems.
Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
They got the f31 key in -0.4, but the *signed* package with this key without subsequent changes to the repositories done in -0.5 is not available anywhere.
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
I did this try 30-0.5 of course, but this is wrong, since installing this package makes F30 from my Rawhide, that is not what I want.
May the the whole problem is, that fedora-gpg-keys has to be updated together with fedora-repos?
~~~
$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide --enablerepo=updates-testing --release 30 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019. Dependencies resolved.
Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and fedora-gpg-keys-30-0.2.noarch - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys = 30-0.2, but none of the providers can be installed - cannot install the best update candidate for package fedora-gpg-keys-30-0.2.noarch - problem with installed package fedora-repos-30-0.2.noarch ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): fedora-gpg-keys noarch 30-0.5 @commandline 102 k
Transaction Summary ============================================================================================================================================================================================== Skip 1 Package
Nothing to do. Complete!
~~~
Which is not what you expect?
Vít
Dne 12. 03. 19 v 12:14 Vít Ondruch napsal(a):
Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
They got the f31 key in -0.4, but the *signed* package with this key without subsequent changes to the repositories done in -0.5 is not available anywhere.
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
I did this try 30-0.5 of course, but this is wrong, since installing this package makes F30 from my Rawhide, that is not what I want.
May the the whole problem is, that fedora-gpg-keys has to be updated together with fedora-repos?
$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide --enablerepo=updates-testing --release 30 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019. Dependencies resolved. Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and fedora-gpg-keys-30-0.2.noarch - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys = 30-0.2, but none of the providers can be installed - cannot install the best update candidate for package fedora-gpg-keys-30-0.2.noarch - problem with installed package fedora-repos-30-0.2.noarch ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): fedora-gpg-keys noarch 30-0.5 @commandline 102 k Transaction Summary ============================================================================================================================================================================================== Skip 1 Package Nothing to do. Complete!
Which is not what you expect?
https://src.fedoraproject.org/rpms/fedora-repos/pull-request/29
V.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dne 12. 03. 19 v 12:46 Vít Ondruch napsal(a):
Dne 12. 03. 19 v 12:14 Vít Ondruch napsal(a):
Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
They got the f31 key in -0.4, but the *signed* package with this key without subsequent changes to the repositories done in -0.5 is not available anywhere.
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
I did this try 30-0.5 of course, but this is wrong, since installing this package makes F30 from my Rawhide, that is not what I want.
I should have better explained this. Updating fedora-repos and fedora-repos-rawhide together with fedora-gpg-keys to this specific version makes F30 from Rawhide by disabling the "rawhide" repo (and enabling the fedora repo, which should not be problem at all). Then all the packages from F30 are taken including fedora-release, which then make F30 from Rawhide.
V.
May the the whole problem is, that fedora-gpg-keys has to be updated together with fedora-repos?
$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide --enablerepo=updates-testing --release 30 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019. Dependencies resolved. Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and fedora-gpg-keys-30-0.2.noarch - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys = 30-0.2, but none of the providers can be installed - cannot install the best update candidate for package fedora-gpg-keys-30-0.2.noarch - problem with installed package fedora-repos-30-0.2.noarch ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): fedora-gpg-keys noarch 30-0.5 @commandline 102 k Transaction Summary ============================================================================================================================================================================================== Skip 1 Package Nothing to do. Complete!
Which is not what you expect?
https://src.fedoraproject.org/rpms/fedora-repos/pull-request/29
V.
On 3/12/19 4:14 AM, Vít Ondruch wrote:
Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
They got the f31 key in -0.4, but the *signed* package with this key without subsequent changes to the repositories done in -0.5 is not available anywhere.
Thats due to compose issues. A compose completed last night so this should be there now?
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
I did this try 30-0.5 of course, but this is wrong, since installing this package makes F30 from my Rawhide, that is not what I want.
May the the whole problem is, that fedora-gpg-keys has to be updated together with fedora-repos?
The problem is that we are calling rawhide two things and have seperate config for it. Once we call it 'rawhide' instead of a number and use the same config as other branches I think most of these problems will go away.
$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide --enablerepo=updates-testing --release 30 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019. Dependencies resolved.
Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and fedora-gpg-keys-30-0.2.noarch - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys = 30-0.2, but none of the providers can be installed - cannot install the best update candidate for package fedora-gpg-keys-30-0.2.noarch - problem with installed package fedora-repos-30-0.2.noarch ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): fedora-gpg-keys noarch 30-0.5 @commandline 102 k
Transaction Summary
Skip 1 Package
Nothing to do. Complete!
Which is not what you expect?
Try again with --enablerepo=fedora ? You need the base repo not just updates-testing?
kevin
Ok, so the process which worked for me was:
~~~
$ sudo dnf update https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/...
$ sudo dnf update --enablerepo=rawhide fedora-gpg-keys --release 31
~~~
But what I really hate about is that after the first step, my system becomes F30. Yes, the other step changes it back to Rawhide, but in the meantime, all the repos I had disabled (such as rawhide-modular) are enabled again, because there is unnecessary fiddling with repositories.
I submitted https://src.fedoraproject.org/rpms/fedora-repos/pull-request/29, which would enable the process to simplify and avoid the issues with the repo files to either:
~~~
$ sudo dnf update https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/...
~~~
or even to:
~~~
$ sudo dnf update --disablerepo=* --enablerepo=updates{,-testing} fedora-gpg-keys
~~~
I have not tested the latter.
I wish the PR was merged, because the strict relation between repos and gpg-keys serves no purpose IMO.
Vít
Dne 12. 03. 19 v 19:53 Kevin Fenzi napsal(a):
On 3/12/19 4:14 AM, Vít Ondruch wrote:
Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
They got the f31 key in -0.4, but the *signed* package with this key without subsequent changes to the repositories done in -0.5 is not available anywhere.
Thats due to compose issues. A compose completed last night so this should be there now?
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
I did this try 30-0.5 of course, but this is wrong, since installing this package makes F30 from my Rawhide, that is not what I want.
May the the whole problem is, that fedora-gpg-keys has to be updated together with fedora-repos?
The problem is that we are calling rawhide two things and have seperate config for it. Once we call it 'rawhide' instead of a number and use the same config as other branches I think most of these problems will go away.
$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide --enablerepo=updates-testing --release 30 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019. Dependencies resolved.
Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and fedora-gpg-keys-30-0.2.noarch - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys = 30-0.2, but none of the providers can be installed - cannot install the best update candidate for package fedora-gpg-keys-30-0.2.noarch - problem with installed package fedora-repos-30-0.2.noarch ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): fedora-gpg-keys noarch 30-0.5 @commandline 102 k
Transaction Summary
Skip 1 Package
Nothing to do. Complete!
Which is not what you expect?
Try again with --enablerepo=fedora ? You need the base repo not just updates-testing?
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dne 13. 03. 19 v 11:49 Vít Ondruch napsal(a):
Ok, so the process which worked for me was:
$ sudo dnf update https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-{gpg-keys,repos{,-rawhide}}-30-0.5.noarch.rpm $ sudo dnf update --enablerepo=rawhide fedora-gpg-keys --release 31
But what I really hate about is that after the first step, my system becomes F30. Yes, the other step changes it back to Rawhide, but in the meantime, all the repos I had disabled (such as rawhide-modular) are enabled again, because there is unnecessary fiddling with repositories.
I submitted https://src.fedoraproject.org/rpms/fedora-repos/pull-request/29, which would enable the process to simplify and avoid the issues with the repo files to either:
So this was merged (thx), but not released up until this point (:-[), so the struggle with updating Rawhide continues. But hopefully, this will be better with f32 branch.
Vít
$ sudo dnf update https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-gpg-keys-30-0.5.noarch.rpm
or even to:
$ sudo dnf update --disablerepo=* --enablerepo=updates{,-testing} fedora-gpg-keys
I have not tested the latter.
I wish the PR was merged, because the strict relation between repos and gpg-keys serves no purpose IMO.
Vít
Dne 12. 03. 19 v 19:53 Kevin Fenzi napsal(a):
On 3/12/19 4:14 AM, Vít Ondruch wrote:
Dne 11. 03. 19 v 19:29 Kevin Fenzi napsal(a):
On 3/11/19 4:31 AM, Vít Ondruch wrote:
Hi,
Can somebody please enlighten me, how to update Rawhide after branching and not using --nogpgcheck?
Can you expand on the case here?
What should happen is:
- branching
- f30 repos gets the f31 key
They got the f31 key in -0.4, but the *signed* package with this key without subsequent changes to the repositories done in -0.5 is not available anywhere.
Thats due to compose issues. A compose completed last night so this should be there now?
- you update your f30-repos
- you jump to rawhide and dnf just imports the key.
How did you get on rawhide?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is the package which is still "rawhide" package and has "f31" keys. But this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Yeah, no longer shipped packages have their signed packages removed after a while to save space. You just want any newer one there. https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... for example.
I did this try 30-0.5 of course, but this is wrong, since installing this package makes F30 from my Rawhide, that is not what I want.
May the the whole problem is, that fedora-gpg-keys has to be updated together with fedora-repos?
The problem is that we are calling rawhide two things and have seperate config for it. Once we call it 'rawhide' instead of a number and use the same config as other branches I think most of these problems will go away.
$ LC_ALL=C.UTF-8 sudo dnf update --disablerepo=rawhide --enablerepo=updates-testing --release 30 https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/... Last metadata expiration check: 0:01:12 ago on Tue Mar 12 12:12:22 2019. Dependencies resolved.
Problem: cannot install both fedora-gpg-keys-30-0.5.noarch and fedora-gpg-keys-30-0.2.noarch - package fedora-repos-30-0.2.noarch requires fedora-gpg-keys = 30-0.2, but none of the providers can be installed - cannot install the best update candidate for package fedora-gpg-keys-30-0.2.noarch - problem with installed package fedora-repos-30-0.2.noarch ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): fedora-gpg-keys noarch 30-0.5 @commandline 102 k
Transaction Summary
Skip 1 Package
Nothing to do. Complete!
Which is not what you expect?
Try again with --enablerepo=fedora ? You need the base repo not just updates-testing?
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org