jhan

I would do like the message suggests and check if the packages net-libs/gssdp net-libs/gupnp are installed. They are required for gupnp-idg

OK, it seems the problem is a config script with pango that has hardcoded include paths: https://github.com/eiskaltdcpp/eiskaltdcpp/issues/413 https://gitlab.gnome.org/GNOME/pango/issues/387 After some tests there seem to be two solutions: - Patching the include path for kde-gtk-config to also include /usr/include/harfbuzz/ - Updating to kde-gtk-config-5.17.4 which does seem to have resolved that problem. But that would require to update most kde packages to 5.64.0 as well. Please open up a bug report at bug.funtoo.org with this information, so that the problem can get fixed one way or the other.

Do you have media-libs/harfbuzz installed?

The question is not if it can be fetched from the git repository but why you are getting that message. As there is no ebuild pango-9999 the problem is probably that some other ebuild is requesting a pango version that is higher than currently available in the tree. So, what did you try to emerge as you got that error and what does the build log say?

Not if you emerge gimp with the USE flag '-python' pygtk is only required for gimp if you use python, as stated in the ebuild: python? ( ${PYTHON_DEPS} =dev-python/pygtk-2.10.4:2[${PYTHON_USEDEP}] =dev-python/pycairo-1.0.2[${PYTHON_USEDEP}] ) And to my knowledge you only loose the ability to use python based plugins. Everything else should work.

A few more packages is still progress. And removing kde-plasma does not ensure success. But there are other ways you can try to get it working. Try equery d qtgui to see what other packages you have installed that depend on qtgui. Installing one of those might trick portage to update qtgui. You could also try uninstalling just kiconthemes. Or you can drop the parameter -D from emerge doing just a emerge -auN @world Probably some other things you can try (like installing single packages,...) but overall my experience is that working with a couple with those techniques is helpful. Always trying a world update in between to see if it works or not.

I would try to update world first: emerge -auDN @world If that still wants to install kiconthemes before updating qtgui, try emerge -auDN @world --exclude kiconthemes Not sure if that won't lead to other conflicts but you can always play around with the exclude parameter (or multiple). Or try installing other packages first to reduce the number of updates needed.

Look at line 101-102 in the log: ^[[01m^[[K/var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp:^[[m^[[K In function ‘^[[01m^[[Kvoid setBreezeFallback()^[[m^[[K’: ^[[01m^[[K/var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp:80:12:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[K‘^[[01m^[[KsetFallbackThemeName^[[m^[[K’ is not a member of ‘^[[01m^[[KQIcon^[[m^[[K’ or a bit clearer: /var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp: In function void setBreezeFallback(): /var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp:80:12: error: setFallbackThemeName is not a member of QIcon Which doesn't help much but points you in another direction. As QIcon seems to be provided by dev-qt/qtgui, this should be the next point to check. My successful test was with dev-qt/qtgui-5.12.3-r1. What version of qtgui do you have installed? As you migrated from funtoo 1.3, it could be that thus package is not yet upgraded.

Those messages don't help either, as they are just warnings. They also appeared in the test install I did in a container just now, which completed successfully. The actual error has to be still higher up. And as the log file is not that large, it probably should be enough to provide the first part of it, if you can't find the error on your own.

The message is only the final error. The real error is usually a bit higher up in the log file. Have a look and see if you can find another error.

I would say that your are looking for the functionality of versionator.eclass or eapi7-ver.eclass. versionator.eclass can be found at https://code.funtoo.org/bitbucket/projects/AUTO/repos/gentoo-staging/browse/eclass/versionator.eclass eapi7-ver.eclass at https://code.funtoo.org/bitbucket/projects/AUTO/repos/gentoo-staging/browse/eclass/eapi7-ver.eclass

I would say, looking at the code in the ebuild: REQUIRED_USE="?? ( elogind systemd )" CDEPEND=" >=dev-libs/glib-2.44:2 sys-auth/polkit elogind? ( >=sys-auth/elogind-229.4 ) introspection? ( >=dev-libs/gobject-introspection-0.9.12:= ) systemd? ( >=sys-apps/systemd-186:0= ) !systemd? ( !elogind? ( sys-auth/consolekit ) ) that it is more like that: - Either none or one of the required use USE flags need to be enabled but not both: https://devmanual.gentoo.org/ebuild-writing/variables/index.html#required_use - If USE flag systemd is set sys-apps/systemd is required - If USE flag elogind is set sys-auth/elogind is required - If systemd USE flag is not set and elogind USE flag is not set then sys-auth/consolekit is required So the question here is, why is the systemd USE flag triggered in the first place because the packages depending on accountservice sicota@farout /data/incoming $ equery d -a sys-apps/accountsservice * These packages depend on sys-apps/accountsservice: gnome-base/gdm-3.32.0 (>=sys-apps/accountsservice-0.6.12) gnome-base/gnome-control-center-3.32.2 (>=sys-apps/accountsservice-0.6.39) gnome-base/gnome-shell-3.32.2-r4 (>=sys-apps/accountsservice-0.6.14[introspection]) gnome-extra/cinnamon-desktop-3.6.2 (sys-apps/accountsservice) kde-plasma/user-manager-5.15.5 (sys-apps/accountsservice) kde-plasma/user-manager-5.16.1 (sys-apps/accountsservice) mate-base/mate-control-center-1.22.1 (accountsservice ? sys-apps/accountsservice) mate-extra/mate-polkit-1.22.0 (accountsservice ? sys-apps/accountsservice) mate-extra/mate-polkit-1.22.0-r1 (accountsservice ? sys-apps/accountsservice) x11-misc/lightdm-1.26.0-r1 (gnome ? sys-apps/accountsservice) x11-misc/lightdm-1.28.0 (gnome ? sys-apps/accountsservice) x11-misc/lightdm-1.30.0 (gnome ? sys-apps/accountsservice) x11-misc/mugshot-0.4.1 (sys-apps/accountsservice) sicota@farout /data/incoming $ do not require systemd to be set. And looking at the output of an emerge -pv kde-meta on my system the accountsservice line looks like: [ebuild N ] sys-apps/accountsservice-0.6.54-r1::gnome-kit USE="-doc -elogind -introspection (-selinux) (-systemd)" 91 KiB with systemd USE flag masked and elogind USE flag turned off. The mask for systemd is the default setting for the epro flavor "core" and also the mix-in no-systemd. To find out why the systemd USE flag is set we would need the output of: - epro - emerge -pv kde-meta

That is interesting, as I see that field only in English, no matter which language I choose from the language menu.

That can depend on many factors. Did you set PYTHON_SINGLE_TARGET or PYTHON_TARGETS somewhere? There are also some programs that still don't have the USE flag for python3_7 or just don't support it yet. But if your 'emerge -pv --depclean =dev-lang/python-3.6* ' output does not show more packages, that should not be the case.

As plasma also has the wayland USE flag, I said it might be good to try to build the system without this USE flag first. To not have a "mixed state", where one part supports wayland and one not. As far as I know, wayland is not yet ready for "general use", there are too many things that don't work yet or still need the use of XWayland, depending on the desktop environment you want to use. Gnome seems to be working fine, KDE plasma e.g still has some problems (https://community.kde.org/Plasma/Wayland_Showstoppers) and no idea about the others. At the moment I wouldn't use it as my normal desktop, unless I have tested all applications under it first, probably on another computer. And if you say that Xorg+KDE seems to get stuck, how far does it get? How are you starting it? Any messages in the Xorg protocol or dmesg?