Hello, I have a reproducible behavior, where whenever revdep-rebuild finds packages to rebuild, it also wants to also rebuild a package with the name “false”, which of course does not exist. This causes emerge and with that revdep-rebuild to exit with an error. There are no other errors in the output. The line of what to recompile then looks like this for example: emerge --oneshot false media-plugins/kipi-plugins:4 It’s gentoolkit-0.3.0_rc8-r1. I wish I could give you more, but I have no idea how to track this down, or what information to give you, since I don’t know where this possibly could come from, other than revdep-rebuild itself. So tell me whatever you might need, and I see if I can provide it. :) Reproducible: Always Steps to Reproduce:
Please attach the complete content of /var/cache/revdep-rebuild/.
Hmm. Damn. I already deleted the files, so I could check if now nothing is broken anymore. Is there a way to re-trigger revdep-rebuild finding a broken package? Then I could provide the files.
Created attachment 219619 [details] 0_env.rr (no package to rebuild) Ok, I found the -k option for revdep-rebuild. I don’t know if this is helpful, but I will now post the files that it left in the /var/cache/revdep-rebuild/ directory.
Created attachment 219621 [details] 1_files.rr (no package to rebuild)
Created attachment 219623 [details] 2_ldpath.rr (no package to rebuild)
Created attachment 219625 [details] 3_errors.rr (no package to rebuild)
Hm, try 'revdep-rebuild -p' that should keep all files created by revdep-rebuild. Ensure the problem is still persistent and in this case maybe tar them and use omploader.org since the files are "huge".
(In reply to comment #7) > Hm, try 'revdep-rebuild -p' that should keep all files created by > revdep-rebuild. Nope. It doesn’t. I just tried it. But -k did at least half the job. > Ensure the problem is still persistent Yes, it is still persistent, as I had this for weeks (doing it every week). It requires at least one package to be broken though. That’s why I asked how to retrigger it. If I can make one package broken again, I will get the problem again. But how do I do that? > and in this case maybe tar them and use > omploader.org since the files are "huge". Sorry. I assumed they were small text files and did not look at the size. :) Will do.
(In reply to comment #8) > (In reply to comment #7) > > Hm, try 'revdep-rebuild -p' that should keep all files created by > > revdep-rebuild. > Nope. It doesn’t. I just tried it. But -k did at least half the job. -p keeps all files here. > > Ensure the problem is still persistent > Yes, it is still persistent, as I had this for weeks (doing it every week). It > requires at least one package to be broken though. That’s why I asked how to > retrigger it. > If I can make one package broken again, I will get the problem again. But how > do I do that? You could downgrade e.g. media-libs/jpeg to 6.x and remove the recent version. > > and in this case maybe tar them and use > > omploader.org since the files are "huge". > Sorry. I assumed they were small text files and did not look at the size. :) > Will do. No pronlem, was my mistake :)
Ok, this took me some time, since I had to trick emerge to not put jpeg into @preserved-rebuild. And because of course pretty much everything depends on jpeg. But here is the link to the revdep-rebuild output: http://navid.radiantempire.com/pub/revdep-rebuild-jpeg.tar.bz2 Alternative: https://navid.intranet-cyberwordz.dyndns.org/pub/revdep-rebuild-jpeg.tar.bz2 (Does not work right now.) This time “false” was definitely in the package list, as this output snippet proves: ⋮ These are the packages that would be merged, in order: Calculating dependencies ... done! emerge: there are no ebuilds to satisfy "false". * revdep-rebuild failed to emerge all packages. ⋮
I've seen this bug intermittently on one of my systems. Do you have SEARCH_DIRS_MASK set in /etc/make.conf? If you do, try commenting it out and see if the issue is still there.
Additionally, the system where I have seen the problem doesn't exhibit the issue with the latest version in subversion. You can install the latest version in subversion by putting the following in /etc/portage/package.keywords =app-portage/gentoolkit-9999 **
(In reply to comment #11) I just looked. Unfortunately not. (In reply to comment #12) > You can install the latest version in subversion by putting the following in /etc/portage/package.keywords > =app-portage/gentoolkit-9999 ** OK, worth a try. Before I do the whole >1-hour “revdep-rebuild -p”. again. ;)
The quick way to break and fix your system (I'm assuming portage-2.2 and unstable keywords) 1. emerge --buildpkgonly =media-libs/jpeg-7 =media-libs/jpeg-8 2. env FEATURES="-preserved-libs" emerge --usepkgonly =media-libs/jpeg-7 3. revdep-rebuild --verbose --pretend --ignore Look at results When finished 1. env FEATURES="-preserved-libs" emerge --usepkgonly =media-libs/jpeg-8
I’m already doing that. But it’s the revdep-rebuild step that takes so long. :) I just reached “Generated new 3_broken.rr” with the svn revdep-rebuild. So soon we’ll know.
Okay, I've done some more testing and debugging and this is appears to actually be Bug 300229. I will wait from confirmation from you before marking as a duplicate.
Yay! With the svn revdep-rebuild the problem is gone! Thanks very much! :D
I wonder when that patch will reach portage though. As I feel uncomfortable, having a 9999 package in the world file.
As soon as I cut an rc9 release, which I hope to be this week. However, I have some major real life issues going on that might interfere with that. You can also downgrade back and apply the patch at http://bugs.gentoo.org/attachment.cgi?id=215727 to have the problem fixed. Or you can downgrade and copy the current svn revdep-rebuild from http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/bin/ Finally, gentoolkit-9999 won't be updated unless you manually update it with emerge gentoolkit or emerge @live-rebuild
Ok. No stress. Real life is more important. :) If someone wants it quicker, he has to pay money. A lot. ;) I only do an update once a week anyway. So no problem here then. :)
On my system, revdep-rebuild wanted to emerge /usr/lib/openoffice as the first item because I had this in my /etc/make.conf: SEARCH_DIRS_MASK="/usr/lib/openoffice" and I didn't have a /usr/lib/openoffice directory. Commenting out the SEARCH_DIRS_MASK in /etc/make.conf fixed the problem for me.
Released in gentoolkit-0.3.0_rc9 and gentoolkit-0.2.4.6
