Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1055718 - Unable to update gloox when 0ad is installed
Summary: Unable to update gloox when 0ad is installed
Alias: None
Product: Fedora
Classification: Fedora
Component: gloox
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Pavel Alexeev
QA Contact: Fedora Extras Quality Assurance
Depends On: 1055806 1055807 1055808
TreeView+ depends on / blocked
Reported: 2014-01-20 19:50 UTC by Branislav Blaškovič
Modified: 2014-07-12 16:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-07-12 16:40:18 UTC

Attachments (Terms of Use)

Description Branislav Blaškovič 2014-01-20 19:50:00 UTC
Description of problem:
gloox-1.0.9-1.fc20.x86_64 does not provide It provided it in version gloox-1.0.3-1.fc20.x86_64

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
 - Try to update the old gloox while 0ad is installed
 - Try to install 0ad when new gloox is installed

---> Package gloox.x86_64 1:1.0.3-1.fc20 will be updated
--> Processing Dependency: for package: 0ad-0.0.15-1.fc20.x86_64
---> Package gloox.x86_64 1:1.0.9-1.fc20 will be an update
--> Finished Dependency Resolution
Error: Package: 0ad-0.0.15-1.fc20.x86_64 (@updates)
           Removing: 1:gloox-1.0.3-1.fc20.x86_64 (@fedora)
           Updated By: 1:gloox-1.0.9-1.fc20.x86_64 (updates)


---> Package 0ad.x86_64 0:0.0.15-1.fc20 will be installed
--> Processing Dependency: for package: 0ad-0.0.15-1.fc20.x86_64
--> Finished Dependency Resolution
Error: Package: 0ad-0.0.15-1.fc20.x86_64 (updates)
           Available: 1:gloox-1.0.3-1.fc20.x86_64 (fedora)
           Installed: 1:gloox-1.0.9-1.fc20.x86_64 (@updates)

Comment 1 Michael Schwendt 2014-01-20 20:16:06 UTC
That's unannounced library SONAME change in the following update, which breaks dependencies and has not been tested painstakingly:

Since it has been pushed to stable already, it cannot be withdrawn, and 0ad will need a rebuild.

Comment 2 Michael Schwendt 2014-01-20 20:21:51 UTC
A simple "repoquery --whatrequires gloox" would have revealed existing dependencies:

  # repoquery --whatrequires ''

But apparently, only licq has been rebuilt:

  # repoquery --whatrequires ''

Comment 3 Christopher Meng 2014-01-21 00:38:11 UTC
0ad maintainer should be awared of this update months ago, Pahan has tried his best to build and push the update.

0ad needs to be rebuilt, I've done this for licq. fatrat maintainer will do this soon later.

See bug 1034994.

Comment 4 Miroslav Suchý 2014-01-21 00:42:44 UTC
Nothing can be done here (beside that hubbitus will try to remember it for next time). Therefore closing.
Real work now must be done by innocent maintainers in dependent bugs.

Comment 5 Michael Schwendt 2014-01-21 10:53:55 UTC
Yes, please notice

and don't push such upgrades if dependencies aren't ready. There has not been a tracking ticket for the upgrade and not for the rebuilds either. In case the packager of dependency doesn't respond, it may be necessary to ask for help on @devel list.

Comment 6 Branislav Blaškovič 2014-01-21 11:01:29 UTC
So what is the next step to get this solved?

Comment 7 Branislav Blaškovič 2014-01-21 11:06:06 UTC
Oh I can see that somebody rebuilt 0ad in bug 1055806. Thank you for solving this.

Comment 8 Paulo Andrade 2014-04-18 14:24:07 UTC
Is this bug still open by mistake or am I missing something?

I am about to build an updated 0ad (with a patch to work with
miniupnpc 1.9) for newer miniupnpc...

Comment 9 Pavel Alexeev 2014-04-19 12:19:18 UTC
It seems as error what it still does not closed.

Note You need to log in before you can comment on or make changes to this bug.