On 10 August 2017 at 12:40, Stephen John Smoogen <smooge@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-leave@lists.fedoraproject.org



--
Stephen J Smoogen.




--
Stephen J Smoogen.