Eclasses in layman overlays not picked up [SOLVED]

hansfn · n00b Joined: 21 Nov 2017 Posts: 27

Added: TL,DR: Make sure that the file extension of your eclasses are actually "eclass" and not "eclasss" ;-)

Hi!

We have a private overlay that we add using Layman. Nothing special there, works nicely. In the overlay we have some Qt 4 ebuilds that never was present in the central repository. These ebuilds fail now because the qt4 eclass files have been removed (1, 2) too. I expected it be easy to fix - just create an eclass directory in the overlay and copy the deleted Qt 4 files (from Git) into the directory. However, the inherit command still fails - the qt4 eclass files aren't found.

So, the question (not Qt4 specific) the becomes:

Is it correct that eclasses from (Layman) overlays should be available/inheritable without any special setup?
If it's supposed to work, how do I debug the problem?
If it's NOT supposed to work, what is the recommended work-around?

The system is up-to-date - synced and updated - so I have the newest versions of portage, layman and the rest. Running "emerge --regen" gives the same error about the qt4 eclass files not being found for the affected pacakage(s).

Thx for any help.

Anon-E-moose · Posted: Fri Aug 10, 2018 4:08 pm Post subject:

You probably need a file in /etc/portage/repos.conf, describing your overlay.

This one is from the deadbeef overlay that I use

hansfn · n00b Joined: 21 Nov 2017 Posts: 27

Thx for the feedback, but I have a working Layman setup (like you describe with a repos.conf directory and so on). I have successfully installed using the same ebuild before the qt4 eclass files were removed.

I forgot to mention that I use the default storage / overlay location for Layman - /var/lib/layman

Anon-E-moose · Posted: Fri Aug 10, 2018 5:25 pm Post subject:

The layman location is not the problem.

I just copied the qt4 eclass file into the local overlay and it picked it up.

You have something that's not pointing to the right place, but I don't know what.
Someone else more knowledgeable about portage and overlays can probably point out what.

Edit to add: might have something to do with egencache, although I didn't run it after it was removed from /usr/portage/eclass and I added it later to /usr/local/portage/eclass.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

hansfn · n00b Joined: 21 Nov 2017 Posts: 27

You are testing with a local/custom overlay, not a Layman overlay.

Added: I think I have made a stupid mistake - wrong file extension, "class" in stead of "eclass". Sorry for wasting your time and thank you for trying to help.

Anon-E-moose · Posted: Fri Aug 10, 2018 6:28 pm Post subject:

Maitreya · Guru Joined: 11 Jan 2006 Posts: 441

Might I suggest using eselect-repository.
It is a lot easier with this and saves on a lot of dependencies with layman.

hansfn · n00b Joined: 21 Nov 2017 Posts: 27

Redacted

The problem was in fact the file extension. An extra "s" had slipped in so I had "name.eclasss" in stead of "name.eclass". I would have liked it if Portage warned about garbage in the repository ...

PS! I switched to eselect-repository. Thx, Maitreya.

Anon-E-moose · Posted: Mon Aug 13, 2018 9:53 am Post subject:

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Maybe you should consider increasing your terminal font size?

Maitreya · Guru Joined: 11 Jan 2006 Posts: 441

hansfn · n00b Joined: 21 Nov 2017 Posts: 27

How does repoman help with the eclasses / eclass directory? I do you use repoman for the actual packages.

PS! The way I finally was able to track down my stupid mistake was to run emerge in debug mode - "emerge --debug -av package". It displayed all possible (absolute) paths for each eclass that was inheritted.