On Wednesday, 01 September 2004, at 09:44:19 (-0700), Michael Stenner wrote: > Yeah, that's crazy and a bit puzzling. Tell me about it. :-) > Sadly, there really isn't a good way to do that. You could, of > course, run it in a debugger. Other than that... try turning the > debug level WAY up to see if you can figure out what's going on just > by yum telling you what it's about to do. The next step would be to > go into the code and add extra logging to help pin it down. I've increased the debug/error levels to 9999. Running it interactively in the python debugger or under gdb would be difficult at best; the build process is entirely unattended and has no controlling tty. I have, however, been able to run yum under ltrace. Interestingly, the problem occured less frequently that way, but it still happened. The log files, as you can imagine, were somewhat large, and I was unable to get any useful info out of them. I can set that up again, though, if it would help you. > Perhaps. Basically, this is either a networking issue or it's not. > If it is, then it's my domain. In that case, I would ultimately be > able to debug it with a regular account. However, in order to > determine if it's a networking issue and WHERE, I'd need to run a > hacked-up version of yum as root. Clearly, this could adversely > affect your system. Perhaps, but it would essentially have to do so intentionally. The chroot jails are replicated from a pristine original prior to each package build; yum would have to break out of the jail to do anything harmful. > If you can do these initial stages, that would help. Try and find > out if it's hanging anywhere under a call into urlgrabber. If so, > find out what the args are. From there, I can play with it. The extent of my python hacking experience is beating anaconda into submission. Fortunately, what I've seen of the yum code is far more encouraging. I'll do my best to help, and I'll get back with you off-list regarding what I find. > Here's the thing, though. In the current way of doing things, yum > should KNOW it doesn't have an "expect" package because it's > downloaded headers.info. It's not like it needs to try fetching it > to find out it isn't available. (you have done a recent yum-arch, > right?). yum-arch is run after each and every build cycle, as is yum update. Discussions with gmkurtzer and jbj pointed toward the __db.* files in /var/lib/rpm, but eliminating those did not alleviate the issue (which is why I've been inclined to blame yum's network interaction even though issues over localhost seem unlikely at best). Thanks, Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@xxxxxxxxx> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "When my time is up, I want to know that I did one thing well: Love somebody. The rest of this is just an expression of that one thing." -- Julie Bowen (Aunt Gwen), "Dawson's Creek"
