Thing is: qjackctl has long been sucessfully emerged, /var/tmp/portage/media-sound/qjackctl-0.3.3/ does no longer exist. Still, this error keeps popping up on every emerge run. I suspect it's stuck in some cache of some sort somewhere.

I'd be glad about any hint how to get rid of this error message.

Thanks,

-fberger

UPDATE:

This can temporarily be fixed by renaming the offending ebuild in /var/lib/layman/pro-audio/media-sound/qjackctl/ from `qjackctl-0.3.3.ebuild` to `qjackctl-0.3.3.ebuild~`.

Last edited by fberger on Sun Dec 23, 2012 7:31 pm; edited 1 time in total

Do you not have that overlay installed any more? Is this an extremely old system that you're belatedly updating? I have a couple of approaches to resolve the problem but want the answers to those two questions first.

The root of the issue is that there is an old ebuild (and an old installation) of qjackctl-0.3.3 in Portage's database.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

You will need to disable that overlay or at least that package for now. In order for it to work again, the ebuild has to either be migrated to the new qt4-r2 eclass or the old qt4 eclass will need to be included in the proaudio overlay._________________Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

Guilty here, I suppose. It's a very slim system, so I run emerge --world reluctantly, and rather update single packages here and there.

dol-sen wrote:

Code:

* qt4.eclass could not be found by inherit()

There's the main source of the problem. [...] You will need to disable that overlay or at least that package for now.

I'd rather not remove the overlay, as it's really useful otherwise.

How do I disable a single package? Do you mean unmerging the package? Will this fix this stuck error?

What I'd love to understand, apart from resolving the problem, is why portage keeps bugging me with what looks like an installation error for a package that has nothing to do with what I currently do with 'emerge'. In what step does it actually stumble over this again and again?

First, you could find the qt4.eclass in the attic and put it in "/usr/portage/eclass". You may get other complaints about missing files. Get them from the attic, too. That will allow Portage to do whatever it wants to do with the installed package (probably upgrade it). A subsequent "emerge --sync" will remove the old eclass(es) and your system will be totally clean.

Second, you could just manually erase the database entry for the out of date package. That would be,

Code:

rm -r /var/db/pkg/media-sound/qjackctl-0.3.3

This will leave behind the installed out-of-date package but will erase Portage's knowledge that it is installed. If it is a dependency of something else, Portage will install a new version and report on some collisions with the old version files. You can safely erase the reported collisions until Portage no longer complains.The first solution is preferred but there's a chance that it won't work because of compatibility issues with the old eclass and the new Portage. The second solution will ultimately succeed but is not preferred because it may leave behind cruft (files from the old package that didn't collide with the new version).

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

I did a third thing. I renamed the offending ebuild in /var/lib/layman/pro-audio/media-sound/qjackctl/ from `qjackctl-0.3.3.ebuild` to `qjackctl-0.3.3.ebuild~`.

Since then, no error reports upon using `emerge`.

I know that this is only a temporary fix.

I'm still not comprehending how portage is stumbling upon this every single run. Does it walk through the package tree and look for such errors every single time? Why does renaming (for portage's point of view: removing) the offending ebuild file fix it? After all, I didn't touch the database.

Perhaps dol-sen will comment because I'm not sure, but I don't believe that Portage parses every ebuild in the tree every time it's executed, nor even every ebuild for every installed package. I think Portage must want to do something with that package.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

Actually that level of detail in portage I don't know. This last question would be better explained by zmedico or genone.

I would guess that portage is needing to access data from the overlay, so needed to scan it for linking to needed eclasses and building a dependency tree for an installed pkg from that overlay.

The real fix for this problem is to pester the maintainer of the pro-audio overlay to update that ebuild or remove it due to the removal of the qt4.eclass_________________Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

How do I disable a single package? Do you mean unmerging the package? Will this fix this stuck error?

The error will go away if you just remove that single ebuild from the overlay. You can remove it manually, and maybe layman has a way to exclude it when you sync the overlay.

fberger wrote:

What I'd love to understand, apart from resolving the problem, is why portage keeps bugging me with what looks like an installation error for a package that has nothing to do with what I currently do with 'emerge'. In what step does it actually stumble over this again and again?

Any help will still be very much appreciated.

It happens because of the emerge --dynamic-deps option which is enabled by default. See `man emerge` for the docs on that option:

Quote:

--dynamic-deps < y | n >
In dependency calculations, substitute the dependencies of installed packages with the dependencies of corresponding unbuilt ebuilds from source repositories. This causes the effective dependencies of installed packages to vary dynamically when source ebuild dependencies are modified. This option is enabled by default.
WARNING: If you want to disable --dynamic-deps, then it may be necessary to first run fixpackages(1) in order to get the best results. The fixpackages(1) command performs two different operations that can also be performed separately by the `emaint --fix moveinst` and `emaint --fix movebin` commands (see emaint(1)).

This option is enable by default because there tend to be a fair number of ebuilds with poorly specified dependencies that lead to problems in dependency calculations (typically slot conflicts or missed updates) if we don't use dynamic deps._________________Zac