#6225 Undefined %epoch problem in Rawhide broken deps report
Closed 2 years ago Opened 5 years ago by mschwendt.

This has been sent to devel@ and test@ list but hasn't seen a reply from anyone with insight yet:


For over a month, a broken "blktap" package had been in Rawhide without being discovered by the broken deps report. Meanwhile, a fixed blktap package has been released into Rawhide, but the broken deps report likely still suffers from the problem as described below.

What creates the Rawhide broken deps report nowadays?
Is it able to discover undefined %{epoch} values in dependencies?


Broken deps for x86_64

Surprisingly, the report is incomplete and doesn't find some unresolvable
dependencies. DNF doesn't either.

An undefined %{epoch} in a dependency is not found. This has been reported
to blktap: https://bugzilla.redhat.com/1248912

Note how DNF tells "Dependencies resolved", but later fails during the
transaction check. How could it resolve the unexpanded "%{epoch}" earlier?

$ rpm -qpR blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64.rpm |grep ep
blktap(x86-64) = %{epoch}:3.0.0-3.fc23.git0.9.2

$ dnf install blktap-devel
Waiting for process with pid 2683 to finish.
Fedora - Rawhide - Developmental packages for t 1.3 MB/s | 43 MB 00:32
Last metadata expiration check performed 0:00:17 ago on Fri Jul 31 09:33:49 2015.
Dependencies resolved.
Package Arch Version Repository Size
blktap x86_64 3.0.0-3.fc23.git0.9.2 rawhide 245 k
blktap-devel x86_64 3.0.0-3.fc23.git0.9.2 rawhide 21 k

Transaction Summary

Install 2 Packages

Total download size: 266 k
Installed size: 793 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): blktap-devel-3.0.0-3.fc23.git0.9.2.x86_6 213 kB/s | 21 kB 00:00
(2/2): blktap-3.0.0-3.fc23.git0.9.2.x86_64.rpm 956 kB/s | 245 kB 00:00

Total 202 kB/s | 266 kB 00:01
Running transaction check
Error: transaction check vs depsolve:
blktap(x86-64) = %{epoch}:3.0.0-3.fc23.git0.9.2 is needed by blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue.

afaik it is spam-o-matic from mash that is called from here that creates the reports:

Perhaps repoclosure usage in spam-o-matic has been customised/replaced with "dnf repoclosure …"? That could be the connection to DNF.

there has been no changes in spam-o-matic to use dnf, it still uses yum. you likely should file bugs against yum and dnf. I suspect that yum and dnf are both doing something wrong. the failure I am guessing comes when rpm tests the transaction.

Metadata Update from @mschwendt:
- Issue set to the milestone: Fedora 22 Final

3 years ago

Metadata Update from @syeghiay:
- Issue close_status updated to: None

2 years ago

Metadata Update from @syeghiay:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.