Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; UNIX) Opera 6.11 [en] Description of problem: When rebuilding a large src.rpm file with rpmbuild --rebuild <file> the proces prepares, compiles and installs ok the package in /var/tmp, then the creation of the binary rpm hangs with this message: getUname: too many uid's Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.download http://www.mozart-oz.org/download/mozart-ftp/store/1.2.5-2003-02-12/mozart-1.2.5.20030212-3.src.rpm 2.rpmbuild --rebuild mozart-1.2.5.20030212-3.src.rpm Actual Results: the binary rpm generation hangs with the the message: getUname: too many uid's Expected Results: It should have created mozart-1.2.5.20030212-3.i386.rpm Additional info: Computer: K7 Athlon 128MB RAM
The message getUname: too many uid's comes from execeeding an internal table of 1024 possible usernames. I believe you have a packaging bug, no package should need more than 1024 user4 id's.
Please, reopen this bug report. The problem that was reported NEVER occurred before and DOES NOT occur for everyone. I and others have successfully invoked rpmbuild --rebuild on the src rpm. Some people, however, have reported this getUname issue. I believe that the problem is with rpmbuild. Please, DO try to reproduce the problem. In all likelyhood, it won't happen for you (if it was a problem with the src rpm, it should). I am the packager for this src rpm, I can work with you and make whatever additional information you need available. What I cannot do, is reproduce the problem. If I could, I would have tried to debug rpmbuild by building from sources and running it under the debugger.
There IS a bug in rpm-build causing the problem: See #85346. There seems to ALSO be a packaging problem in that the wrong uid (my name instead of root) gets into the src rpm. My guess is that it is due to effect of login vs non-login root shell. I don't know if that should be considered a bug in rpm, but it sure isn't helping. We never had that problem before.