On Thu, 22 Oct 2015 08:41:58 -0400 (EDT), Tomas Mlcoch wrote:
> 1)
> There were several points of failure:
> * Developer who made a typo in spec file which results into bad dependency.
> * rpmbuild which built an rpm with broken dependency.
> * Fedora's automated depcheck that wasn't able to find
- Original Message -
> On Tue, 1 Sep 2015 11:58:07 -0400 (EDT), Tomas Mlcoch wrote:
>
> > RPM itself expects epoch to be number:
> > https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/lib/rpmvercmp.c#L124-L143
> >
> > YUM expects epoch to be integ
On Tue, 1 Sep 2015 11:58:07 -0400 (EDT), Tomas Mlcoch wrote:
> RPM itself expects epoch to be number:
> https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/lib/rpmvercmp.c#L124-L143
>
> YUM expects epoch to be integral number:
> https://github.com/rpm-soft
- Original Message -
> On Fri, 28 Aug 2015 04:12:20 -0400 (EDT), Tomas Mlcoch wrote:
>
> > > On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
> > >
> > > > We discussed with Jan Silhan yesterday. It looks like something broken
> > > > in
> > > > createrepo/createrepo_c in F22. S
On Fri, 28 Aug 2015 18:06:27 +0200, Ralf Corsepius wrote:
> >>> See:
> >>>
> >>>
> >>> https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html
> >>>
> >>> https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html
> >>
> >> Bugs ... an undefined epoch is supp
On 08/28/2015 05:32 PM, Michael Schwendt wrote:
On Fri, 28 Aug 2015 16:36:51 +0200, Ralf Corsepius wrote:
See:
https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html
https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html
Bugs ... an undefined epoch i
On Fri, 28 Aug 2015 16:36:51 +0200, Ralf Corsepius wrote:
> > See:
> >
> >https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html
> >https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html
>
> Bugs ... an undefined epoch is supposed to be treated as 0.
No,
On 08/28/2015 02:18 PM, Michael Schwendt wrote:
On Fri, 28 Aug 2015 13:59:12 +0200, Ralf Corsepius wrote:
The version tags "ver" and "rel" attributes may also be non-numerical.
Why not "epoch", too?
I haven't looked into the sources, but IIRC, inside of rpm, while rel,
ver etc. are strings, e
On Fri, 28 Aug 2015 13:59:12 +0200, Ralf Corsepius wrote:
> > The version tags "ver" and "rel" attributes may also be non-numerical.
> > Why not "epoch", too?
>
> I haven't looked into the sources, but IIRC, inside of rpm, while rel,
> ver etc. are strings, epoch is an integer.
See:
https://
On 08/28/2015 01:15 PM, Michael Schwendt wrote:
The version tags "ver" and "rel" attributes may also be non-numerical.
Why not "epoch", too?
I haven't looked into the sources, but IIRC, inside of rpm, while rel,
ver etc. are strings, epoch is an integer.
AFAIR, there are APIs which return th
On Fri, 28 Aug 2015 04:12:20 -0400 (EDT), Tomas Mlcoch wrote:
> > On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
> >
> > > We discussed with Jan Silhan yesterday. It looks like something broken in
> > > createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
> > >
> >
- Original Message -
> On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
>
> > We discussed with Jan Silhan yesterday. It looks like something broken in
> > createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
> >
> > LOG: https://ignatenkobrain.fedorapeople.or
On Thu, 2015-08-06 at 18:37 +0200, Michael Schwendt wrote:
> On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
>
> > We discussed with Jan Silhan yesterday. It looks like something broken in
> > createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
> >
> > LOG: https://
On Thu, 6 Aug 2015 18:00:23 +, Zbigniew Jędrzejewski-Szmek wrote:
> > It couldn't find a comment in the source that would tell whether this
> > is by design.
>
> Does this really matter? If it's by design, then the design is wrong.
> If not, than the implementation is wrong.
It doesn't matter
On Thu, Aug 06, 2015 at 06:37:29PM +0200, Michael Schwendt wrote:
> On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
>
> > We discussed with Jan Silhan yesterday. It looks like something broken in
> > createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
> >
> > LOG: h
On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
> We discussed with Jan Silhan yesterday. It looks like something broken in
> createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
>
> LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log
>
> Also CCing Jan.
Wow
We discussed with Jan Silhan yesterday. It looks like something broken in
createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log
Also CCing Jan.
On Thu, Aug 6, 2015 at 4:03 PM Michael Schwendt wrote:
> On Wed, 5 Aug
On Wed, 5 Aug 2015 10:26:38 -0600, Kevin Fenzi wrote:
> There is a dnf repoclosure plugin, but not sure how well it works off
> hand.
It seems to be completely broken. :-(
It reports lots of available shared libs as unresolved deps.
-> https://mschwendt.fedorapeople.org/tmp/f22-dnf-repoclosure
On Tue, 4 Aug 2015 22:47:31 +0200
Michael Schwendt wrote:
> 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 k
On Wed, 5 Aug 2015 14:00:59 +0300, Igor Gnatenko wrote:
> > How to reproduce:
> >
> > 1. Use Fedora 22.
> > 2. dnf install blktap-devel --disablerepo=updates-testing
> Can you send debugdata from dnf?
> # dnf install blktap-devel --disablerepo=updates-testing --debugsolver
> and then archive '
On Wed, Aug 5, 2015 at 1:58 PM, Michael Schwendt wrote:
> On Wed, 5 Aug 2015 13:47:42 +0300, Igor Gnatenko wrote:
>
>> I can't reproduce this issue.
>
> Believe me, you can. You only created a completely different test-case,
> which may not suffer from the same problem.
>
> How to reproduce:
>
>
On Wed, 5 Aug 2015 13:47:42 +0300, Igor Gnatenko wrote:
> I can't reproduce this issue.
Believe me, you can. You only created a completely different test-case,
which may not suffer from the same problem.
How to reproduce:
1. Use Fedora 22.
2. dnf install blktap-devel --disablerepo=updates-t
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.x8
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
On Fri, Jul 31, 2015 at 3:43 AM, Michael Schwendt wrote:
> On Thu, 30 Jul 2015 12:42:29 +, Fedora Rawhide Report 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 d
On Thu, 30 Jul 2015 12:42:29 +, Fedora Rawhide Report 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://bugz
Il 30/07/2015 14:42, Fedora Rawhide Report ha scritto:
Removed package: deltaspike-1.2.1-3.fc23
Removed package: openwebbeans-1.2.0-6.fc23
why these was removed?
they are already built for F23, please revert these changes!
deltaspike http://koji.fedoraproject.org/koji/taskinfo?taskID=1008414
Compose started at Thu Jul 30 05:15:03 UTC 2015
Broken deps for i386
--
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires
mvn(org.apache.juddi:ju
28 matches
Mail list logo
