Bug 988053 - yum-3.4.3-102.fc19.noarch prevents Koji builds
Summary: yum-3.4.3-102.fc19.noarch prevents Koji builds
Keywords:
Status: CLOSED DUPLICATE of bug 985681
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-24 15:41 UTC by Anthony Messina
Modified: 2013-07-25 08:50 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-25 07:54:14 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Anthony Messina 2013-07-24 15:41:36 UTC 
After ugprading to yum-3.4.3-102.fc19.noarch Koji builds fail with

"DEBUG util.py:264:  Existing lock /var/run/yum.pid: another copy is running as pid 6384."
Comment 1 Zdeněk Pavlas 2013-07-24 16:13:08 UTC 
There was only one change in 3.4.3-102, and it involves metadata handling, not locking.  Can you double check that this was not caused by yum-utils upgrade instead?

Repoquery locking code was added in yum-utils-1.1.31-15.fc19, so this is likely causing this- see BZ 985681.
Comment 2 Anthony Messina 2013-07-24 17:27:42 UTC 
(In reply to Zdeněk Pavlas from comment #1)
> There was only one change in 3.4.3-102, and it involves metadata handling,
> not locking.  Can you double check that this was not caused by yum-utils
> upgrade instead?
> 
> Repoquery locking code was added in yum-utils-1.1.31-15.fc19, so this is
> likely causing this- see BZ 985681.

Ok, I'll give it a shot, but from my yum.log, I haven't upgraded yum-utils in a while:

Feb 27 11:53:43 Updated: yum-utils-1.1.31-10.fc18.noarch

After reading BZ 985681, though, it seems like that is the issue.  I'm not sure why I haven't seen this until after this mornings updates:

Jul 24 08:42:46 Updated: kmod-libs-14-1.fc19.x86_64
Jul 24 08:42:46 Updated: kmod-14-1.fc19.x86_64
Jul 24 08:42:46 Updated: 2:vim-filesystem-7.3.1314-1.fc19.x86_64
Jul 24 08:42:48 Updated: 2:vim-common-7.3.1314-1.fc19.x86_64
Jul 24 08:42:48 Updated: 2:vim-enhanced-7.3.1314-1.fc19.x86_64
Jul 24 08:42:48 Updated: 1:autofs-5.0.7-28.fc19.x86_64
Jul 24 08:42:49 Updated: perl-PathTools-3.40-3.fc19.x86_64
Jul 24 08:42:49 Updated: 2:vim-minimal-7.3.1314-1.fc19.x86_64                                                                                                                                                                                
Jul 24 08:42:49 Updated: libsoup-2.42.2-2.fc19.x86_64                                                                                                                                                                                        
Jul 24 08:42:49 Updated: ppp-2.4.5-30.fc19.x86_64                                                                                                                                                                                            
Jul 24 08:42:49 Updated: qpdf-libs-5.0.0-1.fc19.x86_64                                                                                                                                                                                       
Jul 24 08:42:49 Updated: wget-1.14-8.fc19.x86_64                                                                                                                                                                                             
Jul 24 08:42:49 Updated: yum-3.4.3-102.fc19.noarch

Can you close this one then as related to BZ 985681?
Comment 3 Jan Zeleny 2013-07-25 07:54:14 UTC 
Closing as per comment 2

*** This bug has been marked as a duplicate of bug 985681 ***
Comment 4 Zdeněk Pavlas 2013-07-25 08:50:41 UTC 
> I'm not sure why I haven't seen this until after this mornings updates

More than one instance of repoquery must run simulatenously, so it probably needs some time to trigger this.
Note You need to log in before you can comment on or make changes to this bug.