Oleg Vinichenko

that quote was for not putting python targets entries into make.conf (by anything python related meant). Of course, you can put them, it's allowed, as well as adding any other system-wide settings. by default the make.conf is empty.

right, that's the idea of having automatically setting of python stuff. yes, automated process, which is also gives ability for clean update (or downgrade) of python. For example from 3.4 to 3.6 in one single step. This is step beyond known python switch everyone used to have in gentoo. By a bad fortune i accidentally enabled this feature little bit earlier than it's planned, so my apologies for that.

run epro update

run epro update.

that's right if ego-1.1.3-r5 is installed and ego sync ran with this version, it also running epro update (with sync), which fixes. otherwise, manually running epro update will fix.

and epro update is required to run.

you shouldn't put anything into make.conf. you need to sync again and there should be ego update to 1.1.3-r5

that's me did a typo, it's fixed >3 hours ago

i getting weird things with xfce-4.13 updates and this looks like a broken bumps to me. a missing icon seems to fixed in: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=397045ca30cd2b111d55c6c2ac9b9e5ca0b7d065 however it just the one fix of a number of problems.

right, you can move the content of /usr/portage/distfiles into the new location /var/cache/portage/distfiles if the download is the concern (tarballs need to be refetched), other wise you shouldn't be much worry about it and delete old directories. eclean will work with the new location, then.

http://www.funtoo.org/News:Kits_Are_Go_(And_Ego_Needs_a_Manual_Bump)

if you use only prime branch, then use "ego sync" if you have some of kits with other branches enabled (such as master), do not use "ego sync" to update kits with other branches enabled, use following sequence of commands: cd /var/git/meta-repo git pull git submodule update chown -R portage:portage /var/git/meta-repo eix-sync does not update meta-repo, neither default branches nor any other branches. after manually updating meta-repo or if you use default branches and ego sync, you can use eix-update.

then, something else fixed the dunst for a topic starter

it was found that updating to libXrandr was the fix, it's in topic best answer.

notice, that portage has automatic detection of cpu's and automatically sets makeopts, if not set in make.conf. if required, then change the value (in make.conf)

but at least slot conflict is not present :) emerge -1 --nodeps =x11-drivers/xf86-input-evdev-2.9.2 then run update

eix sync is unaware of ego sync. it calls emerge --sync, and latter one does nothing. as said it can be fixed.

emerge --deselect xorg-server emerge -auDN @world

its possible, of course. but would be nice to know what's not working :)

and from my own experience, i have never used stable builds anywhere and there was no really major problems (like disastrous ones), maybe 2-3 only in last 10 years. so, a key is - when you know what to do with stable or unstable - you could expect things to work. if you don't know what to do, likely you'll trap into troubles regardless stable or unstable used. Sometimes updates can be frustrating, i agree. And for newcomers, of course, it's hard as they mostly driven by existing documentation, web, irc -which can be really wrong. The "stable" is what is controlled by matter of letter, in ebuilds, i can put "amd64" instead "~amd64" and it will be considered stable by package manager, which is of course far from real definition of stable. For example, back into not so old case (about 4 monthes), xorg-server-1.19 stabilized by gentoo, due to multiple security vulnerabilities in xorg itself and in it's core parts. xorg-1.19, in turn, found to be very unstable in certain conditions, so the security fixes diminished by the fact you have no working xorg. Those security fixes can be easily, and they are in Funtoo, backported into good known 1.17 version. of course, if 1.19 were ok for the one, he could choose using 1.19. Just trying to describe that stabilization and stable by means of packages, is a volatile term.

not necessarily, default branch could also contain ebuilds with stable and unstable ebuilds. by deviating into master (or other) branch unstable ebuilds will prevail, i believe.

emerge --sync does not work with meta-repo. use ego sync

appears that you are not using kde-plasma-5 mix-in enabled. it has this python sorted.

yes, in master branches, the ebuilds will be with keywords as they are, stable and unstable as gentoo puts them

ego sync does not support this, if you changed branch manually, use git pull and git submodule update inside xorg-kit directory.