Bug 751249
| Summary: | can't build qconf for epel | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ivan Romanov <drizt72> |
| Component: | yum-utils | Assignee: | James Antill <james.antill> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | drizt72, kevin, kevin, pknirsch, rdieter |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-16 21:08:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ivan Romanov
2011-11-04 03:30:27 UTC
This looks like an odd yum-utils (yum-builddep) issue. From the build logs: DEBUG util.py:281: Executing command: /usr/bin/yum-builddep --installroot /var/lib/mock/dist-6E-epel-build-1173536-185355/root/ '/var/lib/mock/dist-6E-epel-build-1173536-185355/root///builddir/build/SRPMS/qconf-1.4-2.el6.src.rpm' DEBUG util.py:247: Getting requirements for qconf-1.4-2.el6.src DEBUG util.py:247: --> qt3-devel-3.3.8b-29.el6.x86_64 But the dep is: Buildrequires: qt-devel >= 4.4.0 and so it should really pull in: qt-devel.x86_64 1:4.6.2-17.el6_1.1 rhel-x86_64-server-6 Solved! I used Buildrequires: qt-devel >= 4.4.0 Now I use Buildrequires: qt-devel >= 1:4.4.0 I wonder why in Fedora all ok? rhel6 inherited an old fedora qt packaging buglet where qt3-devel included Provides: qt-devel Thanks for your explanation. Now bug can be closed. A don't see "Not a bug" button. Where it? status: resolved->notabug Not sure how/why this bug ended up being under yum-utils component... oh well, only it's owner (or reporter?) can change items now it seems (not me anyway). FYI, the recommendation is actually to use: BuildRequires: qt4-devel >= 4.4.0 The qt4-devel virtual Provides has no Epoch, works even on EL5 where the default was Qt 3 (though you won't find 4.4.0 in the official repositories, because EL5 shipped with 4.2.1) and will keep working in the future when the default will be Qt 5. (In reply to comment #7) > Not sure how/why this bug ended up being under yum-utils component... oh well, > only it's owner (or reporter?) can change items now it seems (not me anyway). One man (I forgot who and where) said me that issue for yum-utils. I haven't 'resolved' button. (In reply to comment #8) > FYI, the recommendation is actually to use: > BuildRequires: qt4-devel >= 4.4.0 > The qt4-devel virtual Provides has no Epoch, works even on EL5 where the > default was Qt 3 (though you won't find 4.4.0 in the official repositories, > because EL5 shipped with 4.2.1) and will keep working in the future when the > default will be Qt 5. With BuildRequires: qt4-devel >= 4.4.0 I can't rebuild my package for EL6. So ... which BuildRequires i should use for my package? Hm ... Is my way bad? I didn't understand your explanation about it. The bug got (incorrectly) filed against RHEL (it's a problem with the Fedora specfile of qconf and so should be filed against Fedora rawhide, component qconf), which unfortunately means only RH employees can touch it.
> With BuildRequires: qt4-devel >= 4.4.0 I can't rebuild my package for EL6.
Huh? The RHEL6 qt package should also have that Provides…
Oh. Really. It was my wrong. I used BuildRequires: qt-devel >= 4.4.0. Rex. Thank you. But how did you get access to my repo??? And what is mean %{?_qt4_version:Requires: qt4%{?_isa} >= %{_qt4_version}}. What for this?
access => provenpackager
As to what that line does, is it adds an arch'd (%%_isa) minimal runtime dependency for the version of qt(4) it was built against, ie, if built against qt-4.7.4, would end up being
Requires: qt4%{?_isa} > 4.7.4
Given comment #4 onwards, I think this is NoB, right? |