Greetings;
I've now cleaned out teh /var/lib/rpm/__db* files and ran rebuilddb twice now, but starting smart --gui, and asking it to update me get this in the log window:
error: Traceback (most recent call last): error: error: File "/usr/lib/python2.4/site-packages/smart/interfaces/gtk/interactive.py", line 171, in callback error: exec code in globals error: error: File "<callback>", line 1, in ? error: error: File "/usr/lib/python2.4/site-packages/smart/interfaces/gtk/interactive.py", line 451, in upgradeAll error: if self.confirmChange(self._changeset, changeset): error: error: File "/usr/lib/python2.4/site-packages/smart/interfaces/gtk/interface.py", line 164, in confirmChange error: return self._changes.showChangeSet(changeset, keep=keep, confirm=True) error: error: File "/usr/lib/python2.4/site-packages/smart/interfaces/gtk/changes.py", line 188, in showChangeSet error: size = report.getInstallSize() - report.getRemoveSize() error: error: File "/usr/lib/python2.4/site-packages/smart/report.py", line 200, in getRemoveSize error: size = info.getInstalledSize() error: error: File "/usr/lib/python2.4/site-packages/smart/backends/rpm/header.py", line 87, in getInstalledSize error: return self._h[rpm.RPMTAG_SIZE] error: error: File "/usr/lib/python2.4/site-packages/smart/backends/rpm/header.py", line 58, in __get__ error: obj._h = obj._loader.getHeader(obj._package) error: error: File "/usr/lib/python2.4/site-packages/smart/backends/rpm/header.py", line 581, in getHeader error: return mi.next() error: error: StopIteration error:
Any hints as to what got a tummy ache here? The box was last updated about 24 hours ago.
Gene Heskett gene.heskett@verizon.net writes:
I've now cleaned out teh /var/lib/rpm/__db* files and ran rebuilddb twice now, but starting smart --gui, and asking it to update me get this in the log window:
Does "yum update" work correctly? If it also objects, it would point to some rpm db problem.
There seems to be a bug that leaves the rpm db scrambled. It happened a year ago and a month ago. The first time the db was permanently scrambled and I just waited till FC6 came out to reinstall from scratch. The second time rebuilddb seemed to fix everything up well enough to allow "yum update" to work. I always did wonder if I was missing something. Oh well, come f7 I'll reinstall from scratch again and that problem will be swept under the rug.
-wolfgang
On 4/1/07, Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200704@gmail.com wrote:
Gene Heskett gene.heskett@verizon.net writes:
I've now cleaned out teh /var/lib/rpm/__db* files and ran rebuilddb twice now, but starting smart --gui, and asking it to update me get this in the log window:
Does "yum update" work correctly? If it also objects, it would point to some rpm db problem.
There seems to be a bug that leaves the rpm db scrambled. It happened a year ago and a month ago. The first time the db was permanently scrambled and I just waited till FC6 came out to reinstall from scratch. The second time rebuilddb seemed to fix everything up well enough to allow "yum update" to work. I always did wonder if I was missing something. Oh well, come f7 I'll reinstall from scratch again and that problem will be swept under the rug.
-wolfgang
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Gene,
On my system "rpm -q python" produced two installed versions. Also two installed versions of python-devel were found. Try removing the older versions using rpm.
On Sunday 01 April 2007, Kam Leo wrote:
On 4/1/07, Wolfgang S. Rupprecht
wolfgang.rupprecht+gnus200704@gmail.com wrote:
Gene Heskett gene.heskett@verizon.net writes:
I've now cleaned out teh /var/lib/rpm/__db* files and ran rebuilddb twice now, but starting smart --gui, and asking it to update me get this in the log window:
Does "yum update" work correctly? If it also objects, it would point to some rpm db problem.
There seems to be a bug that leaves the rpm db scrambled. It happened a year ago and a month ago. The first time the db was permanently scrambled and I just waited till FC6 came out to reinstall from scratch. The second time rebuilddb seemed to fix everything up well enough to allow "yum update" to work. I always did wonder if I was missing something. Oh well, come f7 I'll reinstall from scratch again and that problem will be swept under the rug.
-wolfgang
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Gene,
On my system "rpm -q python" produced two installed versions. Also two installed versions of python-devel were found. Try removing the older versions using rpm.
Worth checking, but no, just one: root@coyote bad-kernel]# rpm -q python python-2.4.4-1.fc6
Thanks.
On Sunday 01 April 2007, Wolfgang S. Rupprecht wrote:
Gene Heskett gene.heskett@verizon.net writes:
I've now cleaned out teh /var/lib/rpm/__db* files and ran rebuilddb twice now, but starting smart --gui, and asking it to update me get this in the log window:
Does "yum update" work correctly? If it also objects, it would point to some rpm db problem.
I haven't tried that, but using yumex 1.92 as a last ditch, I attempted to have it update only azureus, but it cannot be co-erced into ignoring the openoffice-2.2 I put in a few days ago, and insists on overwriting it with 2.0.4, so I gave that up too. OOo-2.2 is sweet, just ignore the jre in the tarball and that all fits rather nicely.
But yum just did it, although it drug in kmdl stuff like a hungry cat in the night, for kernels I don't have on the system AFAIK.
Probably something python related.
Since then I'm also getting a message from k3b when I try to burn a disk, claiming that mmap can't get about 33.5megs of buffer memory, I assume for its circular write buffer, and I'd sure like to get that fixed. There's a gig of ram in this box and it hasn't touched swap in months.
I have another box in the shop that I need to repair with a livedvd boot, but I can't burn the friggin dvd now.
Does anyone have a clue what that might be? selinux is disabled.
There seems to be a bug that leaves the rpm db scrambled. It happened a year ago and a month ago. The first time the db was permanently scrambled and I just waited till FC6 came out to reinstall from scratch. The second time rebuilddb seemed to fix everything up well enough to allow "yum update" to work. I always did wonder if I was missing something. Oh well, come f7 I'll reinstall from scratch again and that problem will be swept under the rug.
I've had it scrambled several times, usually from pushing yumex to do something before it was done with the last operation. Its a bit touchy that way...
Thanks Wolfgang.
-wolfgang
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
On Mon April 2 2007, Gene Heskett wrote:
I've had it scrambled several times, usually from pushing yumex to do something before it was done with the last operation. Its a bit touchy that way...
One other thing that hasn't been mentioned - I once encountered some strange issues with Smart after some updates - I can't remember exactly what the messages were, but the effect was strange failures. I ended up removing it entirely, and then re-installing it; this was after using all the rpm tricks to clean up the database and so forth. It came right to life after the re-install...
On Monday, April 02, 2007 12:54 am Gene Heskett wrote:
I haven't tried that, but using yumex 1.92 as a last ditch, I attempted to have it update only azureus, but it cannot be co-erced into ignoring the openoffice-2.2 I put in a few days ago, and insists on overwriting it with 2.0.4, so I gave that up too. OOo-2.2 is sweet, just ignore the jre in the tarball and that all fits rather nicely.
Well, I found two ways of handling that particular problem: 1) Update to the latest version, and then install the downloaded version overtop of it; 2) Create your own RPM package (in this case, probably with the same name as the Extras package), and install it. Yum always uses the package with the highest version number unless dependencies force it not to (which I think is a MAJOR bug in Yum itself...).
-
Claude Jones -
Gene Heskett -
Kam Leo -
Kelly Miller -
Wolfgang S. Rupprecht