Description of problem: Vast numbers of dependencies are not installed. This is exactly like bug 242279 except I was installing i386 and I used pirut rather than yumex to download all the additional stuff I wanted on my system. Version-Release number of selected component (if applicable): pirut-1.3.7-1.fc7 yum-utils-1.1.4-1.fc7 yum-metadata-parser-1.1.0-2.fc7 yum-updatesd-3.2.0-1.fc7 yum-3.2.0-1.fc7 How reproducible: This is the 2nd time it happened. Steps to Reproduce: 1. install fedora 7, add livna repo 2. run Add/Remove software 3. search for and select gobs of additional things you want installed 4. hit the "Apply" button. Actual results: Installs lots of stuff, but also misses lots of dependencies (see the attached run of: package-cleanup --problems Expected results: should automatically download dependencies. Additional info: A lot of this was from the livna repo, but other parts are from the fedora repo and it missed dependencies in both, so I don't think it is merely a busted repo. Since I've now seen the same bug happen with yumex and pirut, it seems likely it is really some underlying yum issue, but I submit it against pirut since that was the tool I was running.
Created attachment 156028 [details] package-cleanup --problems output
It has been suggested I should change the category to yum (since this happened on both pirut and yumex), so I'm doing that. Just to add some additional info, I'd point out this wasn't an upgrade, but a clean install from scratch. Some related discussion on the fedora-list can be found starting here: https://www.redhat.com/archives/fedora-list/2007-June/msg00822.html To me, the most relevant facts seem to be these: I asked pirut (or yumex in my first bugzilla) to install some packages. It claimed to have installed them. Yet package-cleanup --problems then shows there are missing dependencies (as well as a manual rpm -q -R showing the dependencies do indeed exist in the rpm). A manual "yum install" of the missing dependencies is able to find and install them using the same set of repos the first install used. Therefore, the rpms I requested did include valid dependencies, the repos did include those dependent rpms, yet the installer didn't install them. Thus my conclusion there is a bug somewhere :-). P.S. It did tell me it was installing some additional packages to satisfy dependencies, so it didn't miss all of them, just some of them.
Tom, would you be able to post the messages, yum log and the last two rpmlogs as attachments {maybe bzip2'ed}. /var/log/messages {and .1 if you installed before Sunday} /var/log/yum.log {" "} /var/log/rpmpkgs {" "} What we should see in the yum log is where you were adding packages - we'll then be able to see if it missed a cleanup process.
I can't get to the logs till after work, but I'll attach them when I get home. Meanwhile, I notice over in the fedora-list someone else had a problem with pirut installing eclipse after a clean f7 install - same sort of missing dependencies, so if you have a nice clean f7 laying around somewhere, it might be simpler to reproduce by doing that than to wait for my (much more complicated) logs.
Were you installing or updating packages that were already installed?
This was definitely installing new stuff, not updates. The sequence I went through was: install all optional packages for all groups, except no virtualization and none of the extra languages (since I can't read anything but english anyway :-). get notified there are updates after booting up, go ahead and install them. install the livna-release-7.rpm from livna.org Then run Add/Remove software (pirut) on my freshly genned system to get a lot of additional stuff I use. Run it in search mode, and click on the things it finds, then say "Apply". It was after this finished that lots of dependencies were missing. My notes for the stuff I want to install are a bit fuzzy, but here's the list I search for: hddtemp, gkrellm and hddtemp and themes plugins for gkrellm mplayer, transcode, ffmpeg, vlc, etc. (add most anything searching for "dvd" finds to get dvd libs for decrypting, navigating, etc.. ktorrent neverball unrar claws-mail & friends (claws plugins, bogofilter, etc) kernel-doc avidemux dvdauthor dvdstyler emacs-el gnomad2 lesstif & associated rpms qt4 apcupsd yum-utils rpmdevtools unifdef system-config-bind dhcp expect ksh compat-libstdc++-296.i386 sparse kdegames Now I'll go dig up those logs and add them as attachments.
Created attachment 156138 [details] bziped /var/log/messages from i386 installation This is the messages log file from the i386 Fedora 7 installation. It hasn't been up much since the install, so there is no messages.1 file yet.
Created attachment 156140 [details] bziped /var/log/yum.log file This is the yum.log file from the same i386 F7 install. Note that there are no missing packages on the system anymore because I manually installed all the ones package-cleanup told me were missing via an extra run of yum, but there should be a gap in the timestamps between the initial install and the later manual install. Cron hasn't had a chance to build the rpm package list yet. When I can get booted over to the i386 system, I'll manually run the cron job and add the list.
Created attachment 156144 [details] bziped /var/log/rpmpkgs file Manually ran the /etc/cron.daily.rpm script, here's the resulting rpmpkgs list.
Poking around in the yum.log file, I see this entry is the first missing dependency I had to install, everything before this was from the pirut run: Jun 03 14:27:47 Installed: libXp.i386 1.0.0-8 I was trying to build a little motif app I have and it wouldn't link, but libXp should have been dragged in by lesstif and/or lesstif-devel dependencies. Anyway, once I realized that was missing I ran package-cleanup --problems and created a list of missing dependencies to pass to yum install, and most everything following the libXp entries was from that call to yum.
Hmmm... I might be on to something here. When you did this in pirut, did you say okay and then cancel and go back and add more stuff? I've reproduced at least that way... now to find the root cause and it's possible that it manifests in other cases too
I don't remember doing that. What I mostly remember doing was putting in one search term, hitting search button, selecting various items, then typing a new search term in the field and hitting search again to select yet more items. Perhaps constantly changing the search term is similar to OK/Cancel.
I don't think that changing the search term shouldn't trigger this, but it could be manifesting oddly. I'm building pirut-1.3.8 right now for the devel tree and will be pushing it for F7-updates after a few days of sitting in rawhide. If you could try to reproduce with it, that would be good. Since with the changes in it, I can't reproduce a problem
Could this be related/duplicate to/of bug # 242299? I tried this with speedcrunch (needs qt4). With pirut-1.3.7-1.fc7 no deps are installed if I cancel it the first time. With pirut-1.3.8-1.fc8 the deps are always shown, it's ok but plain yum is still not (after transaction reset I can install speedcrunch without qt4).
You know, after reading bug 242299, my memory may be improving. It is possible that I had some conflicts reported on my initial attempt to install, so I removed one or two things from the install list and tried again. I seem to recall lsdvd conflicting with something in one install and gallery2 conflicts in the other. These may well be the same bugs.
I look like it have something to do with cancel a already depsolved transaction and adding/removing some packages and running a new depsolve. If I do the following in yumex : Add 'xfce-utils' to the queue and process it, then i got a confirmation dialog with all the dependencies to 'xfce-utils', if i press 'Cancel' and go back to the package list and add 'k3b' and process the queue again, i get a confirmation dialog missing a lot of dependencies. Jeremy: It look like there is some problems to clear, some of the datastructures in yum. del self.ts & del self.tsInfo deletes the object, but some of sub object declared inside the objects lives on. I made a patch to yumex a couple of days ago where i had to do do the following to avoid some strange error about 'can't work on a closed database'. I had to do the following to avoid the errors. self.repos.repos = {} del self.repos the: del self.repos was not enough.
Same happened here. I did a clean install. Started pirut to select more packages I got some error message I think about unsigned packages. Went back and unselected unsigned packages: tkcvs, scons, notecase Clicked "Apply". Looks like all packages were installed without dependencies.
Okay, based on comments #15 and #17, this is fixed with pirut 1.3.8 and also fixed better with yum 3.2.1.
*** Bug 243581 has been marked as a duplicate of this bug. ***
I don't know if I should add here or start a new bug. This morning at home I updated my desktop using sudo yum update which updated many things including the kernel. Update ran fine, I rebooted and am running the new kernel. I used my home mirror of fedora which is a mirror of my work mirror, i.e., they are in sync, same files, etc. Got to work and tried to update my desktop there and the update fails because the kernel needs new mkinitrd which doesn't seem to available. I look at home and mkinitrd was not updated and yet the kernel was updated. Both systems are running FC7 i386. I just tried to update my laptop at work and it's going to install the new kernel without installing the mkinitrd update. I just thought of one difference. The system that is failing to update accesses the update data using a file:///URI over nfs instead of an http:///URI. Both systems that use http:// don't require the mkinitrd update while the one that uses file:// does. I have not yet updated the laptop and could hold off doing so for a while if you wanted me to test something.
*** Bug 244379 has been marked as a duplicate of this bug. ***
*** Bug 245755 has been marked as a duplicate of this bug. ***
Created attachment 157986 [details] Clear Depsolve.deps This patch fixes the remaining problem about the outdated deps cache as described in #245755.
Be aware that the above patch may (approximatly) double the run time of yum. And although it fixes the problem for the pirut use case the cache can still get outdated if tsInfo.remove() is called during .resolveDep() (doesn't happen yet) Better solution would be to remove the cache completely and do caching at places where the cache can be kept up2date or does not get invalidated at all.
*** Bug 249221 has been marked as a duplicate of this bug. ***
pirut-1.3.9-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
*** Bug 242748 has been marked as a duplicate of this bug. ***
Yes - the problem persists with pirut-1.3.9-1.fc7 Still reproducable using the steps in my dupe bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243581
*** Bug 248690 has been marked as a duplicate of this bug. ***
pirut-1.3.9-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 251842 has been marked as a duplicate of this bug. ***
*** Bug 343771 has been marked as a duplicate of this bug. ***
*** Bug 246787 has been marked as a duplicate of this bug. ***