RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 751249 - can't build qconf for epel
Summary: can't build qconf for epel
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum-utils
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-04 03:30 UTC by Ivan Romanov
Modified: 2014-01-21 06:24 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-16 21:08:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ivan Romanov 2011-11-04 03:30:27 UTC 
Description of problem:
Can't do a scratch build.

How reproducible:
always

Steps to Reproduce:
fedpkg clone qconf
cd qconf
fedpkg switch-branch el6
fedpkg scratch-build
  
Actual results:
koji.fedoraproject.org/koji/taskinfo?taskID=3485988

Expected results:
Builded binary packages on koji

Additional info:
It package was sucesfully builded for Fedora. This problem actually only for epel6
Comment 1 Kevin Fenzi 2011-11-04 03:35:02 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
Comment 3 Ivan Romanov 2011-12-31 18:08:55 UTC 
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?
Comment 4 Rex Dieter 2012-01-01 17:41:15 UTC 
rhel6 inherited an old fedora qt packaging buglet where qt3-devel included Provides: qt-devel
Comment 5 Ivan Romanov 2012-01-01 17:58:34 UTC 
Thanks for your explanation. Now bug can be closed. A don't see "Not a bug" button. Where it?
Comment 6 Rex Dieter 2012-01-01 20:46:09 UTC 
status:  resolved->notabug
Comment 7 Rex Dieter 2012-01-01 20:48:55 UTC 
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).
Comment 8 Kevin Kofler 2012-01-02 01:24:00 UTC 
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.
Comment 9 Ivan Romanov 2012-01-02 03:53:46 UTC 
(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.
Comment 10 Ivan Romanov 2012-01-02 03:58:47 UTC 
(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.
Comment 11 Kevin Kofler 2012-01-02 11:02:30 UTC 
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…
Comment 12 Ivan Romanov 2012-01-02 11:26:14 UTC 
Oh. Really. It was my wrong. I used BuildRequires: qt-devel >= 4.4.0.
Comment 13 Ivan Romanov 2012-01-02 11:47:04 UTC 
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?
Comment 14 Rex Dieter 2012-01-03 02:26:49 UTC 
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
Comment 15 James Antill 2012-01-16 21:08:29 UTC 
Given comment #4 onwards, I think this is NoB, right?
Note You need to log in before you can comment on or make changes to this bug.