No supported Python for x11-libs/libxcb-1.16::portage-stable

Hu · Moderator Joined: 06 Mar 2007 Posts: 21639

Welcome to the forums. This package appears to be from an overlay, so the proper forum is Unsupported Software. Moved.

This system appears to be both badly out of date and heavily customized, likely some sort of ChromeOS derivative. It should not still be using Portage 2.x; the oldest still in tree is 3.0.45, and 3.0.51 is stable for amd64. Python 3.8 is also suspicious. The current stable is 3.11.5.

None of your core packages seem to come from ::gentoo. Although we may be able to help you, you might be better served seeking support from whoever installed this extensively customized system. For your specific problem, the issue is that the ebuild is incompatible with the Python eclass it is using. The ebuild likely needs an update. This should be reported to the maintainer of ::portage-stable, which is almost certainly not the Gentoo project. According to your emerge --info output, this repository is at /mnt/host/source/src/third_party/portage-stable.

yetebeda · n00b Joined: 26 Nov 2023 Posts: 2

Thank you! Hu.

I think I am now closer to the root cause of the issue, but I still have question that I'll ask at the end.

Here is the package I am trying to build. I am using emerge-rex for a board specific build.

$ BOARD=rex
$ emerge-${BOARD} libxcb # i.e. emerge-rex libxcb

As can be seen from my original post, this is the dependency that portage was complaining about
>=x11-base/xcb-proto-1.16.0[python_targets_python3_8(-),python_single_target_python3_8(+)]

After a while of poking around I did "emerge --search" and "emerge-rex --search" on the problematic package (i.e. xcb-proto)
and that took me closer to the root cause of the issue.

The "Latest version installed" for the two was different as can be seen below.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21639

Portage has no support for board-specific packages. emerge-$BOARD does not exist in standard Gentoo. This is something custom set up on the system in question, probably as part of the ChromiumOS overlay. Since this is not standard, I cannot say what emerge-rex does differently from Portage, and therefore can only speculate generally about the problem. If I were to guess, this might be done using the PORTAGE_CONFIGROOT support, and emerge-$BOARD is a wrapper that sets up PORTAGE_CONFIGROOT, ROOT, or similar variables, and then runs emerge.

I think that the original error about supported Python implementations should not be affected by the steps described in your second post. It is a consistency error between the implementations provided in the ebuild versus the ones supported by the eclass. I would expect that the only fix for it is to sync one or both of those to a newer version where someone fixed the relevant code. Since it is an error in the ebuild/eclass, it should be independent of whether you are running the board-specific or the general emerge. The only way I can see for your change to have an impact is if emerge-$BOARD uses a different set of ebuilds than plain emerge (which can be done using standard Portage configuration), and the board-specific ebuilds were implemented correctly, but the generic ebuilds were broken.