Bug 428847 - yum update fails since more than a week
yum update fails since more than a week
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
: 429041 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-15 11:30 EST by Thomas Gleixner
Modified: 2014-01-21 18:01 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-24 17:54:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Gleixner 2008-01-15 11:30:18 EST
Description of problem:

yum update fails since more than a week due to dependency problems.

How reproducible:

100%

Steps to Reproduce:

# yum update

Actual results:

Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
Package gnome-panel needs libpanel-applet-2.so.0()(64bit), this is not available.
Package gnome-python2-applet needs libpanel-applet-2.so.0()(64bit), this is not
available.
Package control-center needs libpanel-applet-2.so.0()(64bit), this is not available.
Package gnome-power-manager needs libpanel-applet-2.so.0()(64bit), this is not
available.
Package gnome-netstatus needs libpanel-applet-2.so.0()(64bit), this is not
available.
Package libgail-gnome needs libpanel-applet-2.so.0()(64bit), this is not available.
Package gnome-sharp needs libpanel-applet-2.so.0()(64bit), this is not available.
Package gnome-pilot needs libpanel-applet-2.so.0()(64bit), this is not available.
Package gnome-utils needs libpanel-applet-2.so.0()(64bit), this is not available.
Package fast-user-switch-applet needs libpanel-applet-2.so.0()(64bit), this is
not available.
Package gnome-applets needs libpanel-applet-2.so.0()(64bit), this is not available.
Package libpanelappletmm needs libpanel-applet-2.so.0()(64bit), this is not
available.

Expected results:

Success
Comment 1 Florian Festi 2008-01-16 03:52:37 EST
Hmm, this doesn't look good. Can you run "yum clean all" and try again, please.

Thanks!

If this fails the exact yum version would be helpful.
Comment 2 Thomas Gleixner 2008-01-16 08:13:57 EST
Aargh, your reply came too late.

Meanwhile I did a 

yum update yum

which updated a bunch of packages, but now yum killed itself :(

# yum list
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /usr/lib64/python2.5/site-packages/_sqlitecache.so: undefined symbol:
g_assertion_message_expr

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.5.1 (r251:54863, Jan  7 2008, 12:49:59) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-36)]
Comment 3 David Timms 2008-01-23 10:01:32 EST
I have noted same problem as Thomas Gleixner, as discussed:
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02247.html

Florian: 
I renamed my yum cache dirs so that yum wouldn't be able to find it. Same issue.

Seth:
seth vidal wrote:
> On Tue, 2008-01-22 at 08:49 -0500, seth vidal wrote:
> I rebuild yum-metadata-parser into rawhide. Nothing changed in it - just
> a rebuild - let's see if that makes things better.

# rpm -Uvh yum-metadata-parser-1.1.2-5.fc9.i386.rpm
Preparing...                ########################################### 
[100%]
   1:yum-metadata-parser    ########################################### 
[100%]
[root@localhost packages]# yum
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: 
g_assertion_message_expr

* so still the same.
===
rpm -Va yum\* rpm\* python\* sql\*|sort
S.5....T c /etc/yum.conf
[root@localhost packages]# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum/
keepcache=1
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
metadata_expire=1800
failovermethod=priority

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
==
Paul Howarth:
> Does updating glib2 to the version in Rawhide help?
version was a .fc8.

tried: glib2-2.15.2-1.fc9.i386.rpm {it didn't pull in any other packages}.
Now yum yums :-)

and workaround: rpm -Uvh
http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/glib2-2.15.3-1.fc9.i386.rpm
is still yummy.

So does that suggest yum or yum-metadata-parser needs a specific minimum version
of glib2 ?
versions:
$ rpm -qa yum\* rpm\* python\* sql\* \*gcc\* glib\*|sort
glib2-2.15.3-1.fc9
glibc-2.7.90-4
glibc-common-2.7.90-4
libgcc-4.1.2-33
python-2.5.1-21.fc9
python-iniparse-0.2.3-3.fc9
python-libs-2.5.1-21.fc9
python-numeric-24.2-6.fc8
python-setuptools-0.6c7-2.fc8
python-urlgrabber-3.0.0-3.fc8
rpm-4.4.2.2-13.fc9
rpm-libs-4.4.2.2-13.fc9
rpm-python-4.4.2.2-13.fc9
sqlite-3.5.4-2.fc9
yum-3.2.8-2.fc9
yum-metadata-parser-1.1.2-5.fc9
Comment 4 Seth Vidal 2008-01-24 12:59:27 EST
I think it suggests that glib2 changed a function w/o incrementing the library 
at all. y-m-p didn't change so the change to glib2 should have done _something_.

reassigning.
Comment 5 James Antill 2008-01-24 14:59:20 EST
 Note that while upstream probably don't want to increment the major release,
they should accept adding versions on the new symbols ... which are picked up by
rpm and so would also solve this problem.
 See the ustr package in Fedora for a simple example, if you/they aren't sure
how to do that.
Comment 6 Matthias Clasen 2008-01-24 17:48:04 EST
I can reassure you that we (glib upstream) don't want symbol versions, thank you.

And symbol versions wouldn't have helped the least here anyway.

The problem is caused by old macros that expands to new symbols. 

Seth, I'm not sure why you reassigned this bug to glib2. 
What do you expect me to do ? I accept that the glib change is unfortunate, 
and I should perhaps have paid closer attention to avoid this problem. But
those macros are in rawhide now for better or worse, and the least invasive 
shortterm fix is to just require a new enough glib2 in yum-metadata-parser.
Comment 7 Seth Vidal 2008-01-24 17:54:36 EST
I reassigned it to glib b/c I wanted some input on what was going on. I got it.
I've added an explicit dep on glib > 2.14 to yum-metadata-parser's spec file in
rawhide.

Comment 8 Jeremy Katz 2008-01-24 17:59:41 EST
... and every other app that is built against the new glib2 and uses that
function.  I hit this yesterday doing a quick upgrade of nautilus (and not the
rest of rawhide) to fix a crasher.  :-/

I don't have an easy answer, but it is something which has occurred more than
once now.  And symbol versioning would improve things, but definitely would do
so at a cost on maintenance of glib (and I'm not going to go as far as to say it
really "fixes")
Comment 9 Matthias Clasen 2008-01-24 18:09:49 EST
> And symbol versioning would improve things

I honestly don't see how it would help here at all. Its a new symbol, not some
change in the semantic of an existing symbol. A symbols existence/nonexistence
is the one thing you can find out about it without resorting to symbol versions...

And yes, I'm going to look at what we can do to mend this issue before 2.16.
Comment 10 James Antill 2008-01-24 20:41:59 EST
> I can reassure you that we (glib upstream) don't want symbol versions, thank you.

 Fair enough, I guess. But Here's another BZ#429970

> And symbol versions wouldn't have helped the least here anyway.

 This is pretty much the problem version symbols solve, from a depsolving POV.
As I said ustr used version symbols and was in Fedora:

% repoquery -q ustr 
ustr-0:1.0.2-3.fc8.x86_64
% repoquery --provides ustr
libustr-1.0.so.1()(64bit)
libustr-1.0.so.1(USTR_1.0)(64bit)
libustr-1.0.so.1(USTR_1.0.1)(64bit)
libustr-1.0.so.1(USTR_1.0.2)(64bit)
ustr = 1.0.2-3.fc8
% repoquery --repoid=development -q ustr
ustr-0:1.0.3-2.fc9.x86_64
% repoquery --repoid=development --provides ustr
libustr-1.0.so.1()(64bit)
libustr-1.0.so.1(USTR_1.0)(64bit)
libustr-1.0.so.1(USTR_1.0.1)(64bit)
libustr-1.0.so.1(USTR_1.0.2)(64bit)
libustr-1.0.so.1(USTR_1.0.3)(64bit)
ustr = 1.0.3-2.fc9

...if you use a 1.0.3 symbol, you get a dep. on
libustr-1.0.so.1(USTR_1.0.3)(64bit) ... and yum can do the right thing.
Comment 11 James Antill 2008-01-24 20:49:17 EST
 Also if you look in scripts/ in ustr you'll find cmp_symbols_ver.sh ... which
does a diff. between the version file and the symbols in the library ... it's
not like you have to do this stuff by hand.
 But anyway...
Comment 12 Matthias Clasen 2008-01-24 20:56:43 EST
Ah, maybe I didn't have the full picture on how symbol versions interact with
rpms dependency collector, and symbol versions do indeed solve this.
Comment 13 seth vidal 2008-02-05 15:25:32 EST
*** Bug 429041 has been marked as a duplicate of this bug. ***

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