Rpmfusion-free-obsolete-packages can't update

I can update packages from rpm-free, but this one is giving me signature error.
Any ideas?

[SKIPPED] rpmfusion-free-obsolete-packages-38-1.fc38.noarch.rpm: Already downloaded                
Ejecutando verificación de operación
error: rpmdbNextIterator: omitiendo h#      15 
EncabezadoV3 RSA/SHA1 Signature, ID de clave d651ff2e: BAD
EncabezadoSHA256 digest: OK
EncabezadoSHA1 digest: OK
error: rpmdbNextIterator: omitiendo h#      15 
EncabezadoV3 RSA/SHA1 Signature, ID de clave d651ff2e: BAD
EncabezadoSHA256 digest: OK
EncabezadoSHA1 digest: OK

I already tried:

sudo dnf install rpmconf
sudo rpmconf -a
sudo dnf install remove-retired-packages
sudo dnf repoquery --unsatisfied
sudo dnf repoquery --duplicates
sudo dnf autoremove
sudo rpm --rebuilddb
sudo dnf distro-sync --allowerasing

I was just able to install and remove with dnf, maybe try re-downloading the package.

sudo dnf clean packages
sudo dnf update

Same result, note that I’m on Fedora 38

This looks to be a case of Popular third-party RPMs fail to install/update/remove due to security policies verification


disregard, didn’t think about the old package coming from F36.

Well, this is concerning.
I had to set SHA1 to update obsolete-packages from f36 to f38

Please keep in mind that F38 isn’t even in beta yet.

1 Like

Yeah, np. I was responding to the above post that was edited


I don’t mean to discourage people from trying pre-release versions… that’s how we find these things, after all.

1 Like

This hasn’t been likely caused by rpmfusion-free-obsolete-packages. Run

rpm -q --nosignature --querybynumber 15

to learn which package was blocking the transaction. (You can see the package id number 15 in the error).

Yes, I tried that and it was rpmfusion-free-obsolete-packages
It also was the only package left to update

Huh, that’s interesting. When I try it on F38, it installs just fine, and it seems to be signed with SHA256 and not SHA1…

$ rpm -q rpmfusion-free-obsolete-packages
$ rpm -qi rpmfusion-free-obsolete-packages | grep Signature
Signature   : RSA/SHA256, Sat 25 Feb 2023 08:41:52 AM CET, Key ID e06f8ecdd651ff2e

Oh I see, the problem was with the older package, which is actually F35-based:

$ rpm -q rpmfusion-free-obsolete-packages
$ rpm -qi rpmfusion-free-obsolete-packages | grep Signature
Signature   : RSA/SHA1, Sun 14 Nov 2021 03:40:36 PM CET, Key ID e06f8ecdd651ff2e

But if you have rpmfusion repos enabled during upgrade, this shouldn’t be a problem. The package update should still happen with the older security policy.

Have you disabled rpmfusion before upgrading to F38 and then re-enabled it? That would explain your experience.

Nope :man_shrugging:

I was able to reproduce this in a VM upgrading from F36 workstation.

Looking through the logs and dnf history it looks like it just ignored that package during the upgrade.

dnf history here: https://paste.centos.org/view/cc5def8a

Hmm, I don’t really know how these virtual packages work internally. But it would be really helpful if Rpmfusion maintainers rebuilt their *-obsoletes-packages for Fedora 36 and Fedora 37 using modern tooling, so that this problem doesn’t bite people on upgrade. Is anyone willing to report a bug to them?

This is resolved now, there was an update pushed for rpmfusion-free-obsolete-packages. RepoView: "RPM Fusion Fedora free 36 updates - x86_64"

Great, thanks for the update. The new package seems to have a modern SHA256 signature.