On 10 August 2017 at 12:40, Stephen John Smoogen <smo...@gmail.com> wrote:

>
>
> The packages are there and the buildroots were rebuilt last night
>
> ./x86_64/rhel-7-server-rpms/Packages/qt5-qtbase-devel-5.6.2-1.el7.i686.rpm
> ./x86_64/rhel-7-server-rpms/Packages/qt5-qtbase-devel-5.6.
> 2-1.el7.x86_64.rpm
> ./x86_64/rhel-7-server-rpms/Packages/qt5-qtdeclarative-
> devel-5.6.2-1.el7.i686.rpm
> ./x86_64/rhel-7-server-rpms/Packages/qt5-qtdeclarative-
> devel-5.6.2-1.el7.x86_64.rpm
>
> I will see what is still fudged up.
>
>
>
To close off the email loop. The problem has to do with how Koji rates
certain repositories for pulling dependencies. I thought it would work like
a mockbuild and pull in the packages from the highest NVR. This doesn't
work in split repository repos like EPEL where some repos are considered
local and others remote. In the case of this, it is going to choose the
local over because you would normally want that in the usual build stream.
For EPEL this means that if there is a local package which matches the
requirement.. it gets pulled in even if the upstream build has a higher NVR.

Which is of course why we must retire packages in EPEL if they are in
RHEL... because while the new package had been seen by koji since April!?!,
the local EPEL builds for those were taking precedence. There are currently
69 srpms which are 'conflicting' with a RHEL package. I am working through
which ones are only needed for a particular arch and how we can deal with
that.





>
>
>> _______________________________________________
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>>
>
>
>
> --
> Stephen J Smoogen.
>
>


-- 
Stephen J Smoogen.
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Reply via email to