It would be appreciated if rhpkg could set up environment for build of a collection. For example, if you have scl-utils installed on a system you issue `rhpkg build`, the giturl it submits will be wrong, because it'll expand the %{scl} macro. I guess warnings would be nice or something like rhpkg build --scl, which would switch on more checks. I'm not sure what should be improved, because I'm not aware of functionality inside of rhpkg. It might be better if someone from release engineering improve it for regular developers.
*** Bug 905521 has been marked as a duplicate of this bug. ***
This bug should be definitely addressed soon. Everyone who's building software collections has to switch to brew at some point, because the builds would appear as conflicting (they won't conflict if one's lucky). If software collection is such an interesting and valuable product, we should be able to build it using official Package Source Control Tool such as rhpkg. It would also save me and Lubos from rel-eng some time debugging what might be wrong when it's already a known issue for almost 11 months (and for others that come across this for the first time).
We've just hit this again with RHSCL 1.1 python27 collection - python27-python NVR is the same as RHEL 7 python NVR, so we keep getting Could not execute build: python-2.7.5-12.el7 has already been built which is plainly wrong. Pavol, could you please do something about it? This has been reported for more than a year now.
(In reply to Bohuslav "Slavek" Kabrda from comment #3) > We've just hit this again with RHSCL 1.1 python27 collection - > python27-python NVR is the same as RHEL 7 python NVR, so we keep getting > > Could not execute build: python-2.7.5-12.el7 has already been built > > which is plainly wrong. Pavol, could you please do something about it? This > has been reported for more than a year now. This is different problem and will be addressed in Bug 1078947.
Fix will be made in underlying library - rpkg. giturl will be build from git remote from current tracking branch.
*** Bug 969460 has been marked as a duplicate of this bug. ***
*** Bug 844079 has been marked as a duplicate of this bug. ***
fedpkg-1.18-1.fc19,rpkg-1.26-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fedpkg-1.18-1.fc19,rpkg-1.26-1.fc19
fedpkg-1.18-1.fc20,rpkg-1.26-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedpkg-1.18-1.fc20,rpkg-1.26-1.fc20
fedpkg-1.18-1.el6,rpkg-1.26-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/fedpkg-1.18-1.el6,rpkg-1.26-1.el6
fedpkg-1.18-1.fc20, rpkg-1.26-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
fedpkg-1.18-1.fc19, rpkg-1.26-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
fedpkg-1.18-1.el6, rpkg-1.26-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 864736 has been marked as a duplicate of this bug. ***