Jonathan Berry wrote:
On 2/4/06, Claude Jones <cjones@xxxxxxxxxxx> wrote:
On Saturday 04 February 2006 13:01, Dave Jones wrote:
On Sat, Feb 04, 2006 at 12:50:08PM -0500, cjones@xxxxxxxxxxx wrote:
> On Friday 03 February 2006 23:14, Claude Jones wrote:
> > On Fri February 3 2006 9:19 pm, Dave Jones wrote:
> > > x86-64 ? If so, yes.
> > >
> > > Dave
> >
> > Doesn't ring a bell. I'll post them tomorrow when I'm back in the
> > office. Thanks.
>
> Here's what I've got
>
> rpm -qa | grep glibc
> glibc-devel-2.3.90-30
> glibc-devel-2.3.90-34
> glibc-2.3.90-34
> glibc-2.3.90-30
> glibc-common-2.3.90-34
I'll ask again. Is this an x86-64 ? If so, having two glibc's is normal.
Dave
Sorry, I blocked on your question. No, it's definitely not an x86-64 machine.
I'm seeing a similar thing on my x86_64 box:
# rpm -qa | grep glibc | sort
glibc-2.3.90-30.i686
glibc-2.3.90-30.x86_64
glibc-2.3.90-34.i686
glibc-2.3.90-34.x86_64
glibc-common-2.3.90-30.x86_64
glibc-common-2.3.90-34.x86_64
glibc-devel-2.3.90-30.i386
glibc-devel-2.3.90-30.x86_64
glibc-devel-2.3.90-34.i386
glibc-devel-2.3.90-34.x86_64
glibc-headers-2.3.90-30.x86_64
glibc-headers-2.3.90-34.x86_64
glibc-kernheaders-3.0-4.x86_64
I have both versions for both architectures, heh. The update that
pulled in the 2.3.90-34 versions went rather rough. I had to
constantly go kill off gcj-dbtool because otherwise yum would just sit
there. I guess there is no telling what might be broken as a result
of that...
Jonathan
So was a bug report made regarding gcj-dbtool? I do not have this
program installed and did not suffer the wrath from the package lockup.
Killing yum in process during the installation phase will result in no
cleanup after install. Probably packages downloaded to upgrade and were
not upgraded because of the kill were never installed. Packages before
gcj-dbtool probably only have multiple version entries in the rpmdb and
are probably only entries for the earlier program on your system and the
database entries for the older version need only to be erased. Verifying
the later packages is still a good idea to ensure that all of the new
packages are intact.
Jim
--
The person who can smile when something goes wrong has thought of
someone to blame it on.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list