Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi folks,

I can't reproduce this issue.
$ sudo dnf install
https://kojipkgs.fedoraproject.org//packages/blktap/3.0.0/3.fc23.git0.9.2/x86_64/blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/blktap/3.0.0/3.fc23.git0.9.2/x86_64/blktap-3.0.0-3.fc23.git0.9.2.x86_64.rpm
-C
Last metadata expiration check performed 1:22:41 ago on Wed Aug  5
11:51:08 2015.
The downloaded packages were saved in cache till the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'
Error: nothing provides blktap(x86-64) =
%{epoch}:3.0.0-3.fc23.git0.9.2 needed by
blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages)

Please let us know:
$ rpm -q libsolv hawkey dnf
$ sudo dnf install blktap-devel --debugsolver (it will create
'debugdata' directory which we want)

On Tue, Aug 4, 2015 at 11:47 PM, Michael Schwendt <mschwendt@xxxxxxxxx> wrote:
> On Fri, 31 Jul 2015 03:51:12 -0400, Christopher Meng wrote:
>
>> >> 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?
>>
>> I'm confused as well, I never saw any problem in this package before.
>
> Obviously. ;)  If the Rawhide broken deps report had found it, breakage could
> have been avoided.
>
> A different try:
>
>   https://fedorahosted.org/rel-eng/ticket/6225
>
> Or file it in the infrastructure tracker instead? I don't know. There are lots
> of active tickets in both.
>
> And what about DNF? Are the DNF developers interesting in looking into
> it, too? Or is by design that the "Dependencies resolved" step doesn't
> discover the unresolvable dependency?
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
-Igor Gnatenko
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux