see attachment
Created attachment 76612 [details, diff] revdep-rebuild_overflow.patch please check and add to the main tree after updating DBUS I unable to revdep and recompile all my system w/o this patch
still bad code... wait for new one
I created new patch
Created attachment 76687 [details] gentoolkit-0.2.2_pre2-r1.ebuild fixed ebuild
Created attachment 76689 [details, diff] revdep-rebuild-overflow.patch more correct patch to fix bug
Created attachment 82654 [details, diff] revdep-rebuild fgrep overflow fix (ver2) I didn't have luck with the above patch, but a small re-ordering fixed it on my system. This patch applies to stable and unstable gentoolkit. Is this the correct fix?
Also, this bug is the same as bug 38751: http://bugs.gentoo.org/show_bug.cgi?id=38751 This one has been a long standing irritation for me, so it would be nice if somebody closed it ;-)
Latest patch works for me, but why is this problem never resolved correctly? This is the fifth or sixth patch for the same problem. Yet more reason for the fall of gentoo and the rise of ubuntu!
(In reply to comment #9) > Latest patch works for me, but why is this problem never resolved correctly? > This is the fifth or sixth patch for the same problem. > Yet more reason for the fall of gentoo and the rise of ubuntu! > Give me millions of dollars in backing so that I can pay people to do the work; otherwise please try to be patient with the developers. We are busy people just as you are.
Comment #9 is a bit out-of-line. Ubuntu certainly has its place, but I really prefer Gentoo for the all-out flexibility. And I've certainly received great support from the Gentoo devs in the past: a large amount of my "bugs" were fixed in less than a day. revdep-rebuild is a relatively non-trivial piece of software: it needs to interface with portage internals that you and I normally don't worry about. Plus, the above patch is far from perfect: a large number of broken binaries (as opposed to a large number of installed packages) will still trigger an overflow. Maybe replace $(cat <xxxx>) with a $(head -n 100 <xxx>) and tell the user to re-run revdep-rebuild for the rest? Then again, there might be a more elegant way to do it, and the only thing stopping me from seeing it is trying to implement it in one line ;-) The coolest way to fix it would actually be to have an arbitrary large command-line buffer ;-)
(In reply to comment #8) > Also, this bug is the same as bug 38751: Right, and marking as such. (In reply to comment #11) > Plus, the above patch is far from perfect: a large number of broken binaries > (as opposed to a large number of installed packages) will still trigger an > overflow. Maybe replace $(cat <xxxx>) with a $(head -n 100 <xxx>) and tell the > user to re-run revdep-rebuild for the rest? I have a patch (many months old, so may not apply to current revdep-rebuild cleanly) in bug #38751 which shouldn't have these problems, but as I noted in the bug, I've never been bitten by this problem myself, so I can't be completely sure. *** This bug has been marked as a duplicate of 38751 ***
The last patch don't fix the problem for me :(
