Bug 133045

I wonder if this is the always prefer 64 bit in a transaction.

Quick test, for a biarch package that you care little about (and has
no package requiring it) roll both back to an earlier version (or
update to a later rahwide version if available)

rpm --qf '%{name}-%{version}-%{release}.%{arch}\n' -q testpackage
rpm -Uvh testpackage.i386.rpm testpackage.x86_64.rpm
rpm --qf '%{name}-%{version}-%{release}.%{arch}\n' -q testpackage

Unfortunately, the only biarch packages I have installed is glibc, and
that's because grub requires it, and that obviously has things
requiring it. So, no rollbacks/upgrades possible in that scenario.

The reason for this is that I got bit by a bunch of biarch problems
with  FC2 and just removed all i386 packages (except for glibc, which
the x86-64 version of grub requires).

Now that I think about it, I know this also happened with the FC2
versions of anaconda & rpm, which predates the "always prefer Elf64"
changes.

After the FC2 upgrade, I remember that freetype.x86_64 had been
upgraded and but not freetype.i386, and this led me to notice that
none of the other i386 packages had been upgraded as well.

(I rebuild freetype with the TrueType bytecode interpreter enabled,
and the upgrade resulted in the 64-bit apps using ugly fonts while the
32-bit apps still displayed nicely hinted fonts.)

Sorry for the delayed bug report.

Please attach /var/log/rpmpkgs /var/log/rpmpkgs.1 and the anaconda
logs /root/upgrade.log.*

sorry /root/upgrade.log*

Created attachment 104108 [details]
upgrade.log, rpmpkgs, rpmpkgs.1

Here you go. upgrade.log.syslog was empty, so I omitted it.

Can not confirm that from the logs started with:

freetype-2.1.7-4.njm.1.x86_64.rpm
freetype-demos-2.1.7-4.njm.1.x86_64.rpm
freetype-devel-2.1.7-4.njm.1.x86_64.rpm
freetype-utils-2.1.7-4.njm.1.x86_64.rpm

update did

Upgrading freetype-2.1.9-1.x86_64.
Upgrading freetype-devel-2.1.9-1.x86_64.
Upgrading freetype-demos-2.1.9-1.x86_64.
Upgrading freetype-utils-2.1.9-1.x86_64.

reporting 

The following packages were available in this version but NOT upgraded:

freetype-2.1.9-1.i386.rpm

Then you rebuilt

freetype-2.1.9-1.njm.1.x86_64.rpm
freetype-demos-2.1.9-1.njm.1.x86_64.rpm
freetype-devel-2.1.9-1.njm.1.x86_64.rpm
freetype-utils-2.1.9-1.njm.1.x86_64.rpm
freetype-2.1.7-4.njm.1.x86_64.rpm

Are you 100% positive you had freetype.i386 installed?

I did when I upgraded from FC1 to FC2. Since then, I removed all i386
packages except glibc and libgcc.

(All that rambling about freetype was me remembering that I had this
exact same problem with the FC1 to FC2 upgrade, prior to the "always
prefer Elf64" changes to RPM.)

I'm just trying to clarify the bug details to a specific case, you state:

Upgrade from FC2 to FC3T2 - any i386 package not upgraded.

Pre upgrade (rpm:

glibc-devel-2.3.3-27.i386.rpm
libgcc-3.3.3-7.i386.rpm

upgrade log:

Upgrading glibc-devel-2.3.3-53.x86_64.
but says not doing this glibc-devel-2.3.3-53.i386.rpm

Post upgrade (rpmpkgs):

glibc-devel-2.3.3-54.i386.rpm
glibc-devel-2.3.3-54.x86_64.rpm

Did you install glibc-devel.i386 manually after the upgrade?

Yes, I manually updated glibc.i386, glibc-devel.i386, and libgcc.i386.

*** Bug 133820 has been marked as a duplicate of this bug. ***

I've created a fix for this on HEAD and will be out on next anaconda
roll - if you are available to test let me know here or better on
irc.freenode.net #fedora-bugweek nick: nasrat and I can supply an
updated python file for you to test.

Could you please attach the fix here? I can give it a try on ia64 and
x86-64.

Created attachment 104520 [details]
findpackageset

Assuming you are doing exploded nfs tree - create RHupdates/ at top of the
rawhide/fc3tX tree and put the attached python file in. eg:

.
|-- Fedora
|   |-- RPMS
|   `-- base
|-- RHupdates
|-- images


More details about updates are available in
/usr/share/anaconda-.../install-methods.txt (where ... is anaconda version).

Created attachment 104555 [details]
Python trace

I need this patch

--- findpackageset.py.rhel4	2004-09-29 12:02:03.000000000 -0700
+++ findpackageset.py	2004-09-29 16:21:49.426650553 -0700
@@ -94,6 +94,8 @@ def findpackageset(hdrlist, dbPath='/'):
  
     hdlist = availDict.values()
      
+    ts = rpm.TransactionSet(dbPath)
+
     # loop through packages and find ones which are a newer
     # version than what we have
     for ( name, arch ) in instDict.keys():

to avoid the crash on RHEL 4 b1. But now I got this Python crash

Thanks for catching that.  I overy entusiastically refactored it out
whilst still using it in obsolete handling. Fix in anaconda 10.0.3.8-1

The trace seems unrelated to this bug in particular - if it's
reproducible without the RHupdates on latest rawhide please file a
seperate bug.

I'll try and reproduce locally here.

Created attachment 104579 [details]
Simple testcase not requiring install

A simple test case that you can run with anaconda installed from rawhide today
(10.0.3.8-1)

It supports using a hdlist or generating one from a dir  of rpms on the fly

test-findpackageset.py --hdlist ./hdlist

The modified findpackageset.py works for me on x86-64. I
created a new boot.iso with the modified initrd.img which
has findpackageset.py under /tmp/updates. I used the new
boot.iso with the original RHEL 4 beta 1 ISOs.

Inspected twaugh's upgrade logs and rpm -qa before/after:

snippet:

Upgrading howl-libs-0.9.6-6.i386.
Upgrading howl-libs-0.9.6-6.x86_64.
Upgrading ORBit2-2.12.0-3.i386.
Upgrading ORBit2-2.12.0-3.x86_64.
Upgrading libbonobo-2.8.0-2.i386.
Upgrading libbonobo-2.8.0-2.x86_64.
...

biarch seems happy.