Oleg Vinichenko

and if you want portage to keep building, even if something failed in-between, then add --keep-going, it will will skip all failures and continue. That's, of course, if failed ebuild not used by other ebuilds further down in list, then the merge will stop.

added 1.9.6 version.

ok, thx for the information.

attached build.log is incomplete and shows no errors.

the flora repo looks the one. It is a community contribution repository for cases like this.

xdm init script has the option to use sddm. and also has some logic for consolekit service. And i suspect sddm has it's own logic for the consolekit. That's only after brief look, cannot tell more details.

are both problems observed also when starting XFCE4 with startx? I use xfce4/consolekit myself but without any login managers. sddm is known of having weird issues. For me it looks like there is a race condition between xdm/sddm and the consolekit. The latter one supposed to be integrated quite well as current developers of consolekit are xfce developers too. Try starting with startx to eliminate xdm/sddm as first candidates. make sure to remove xdm from openrc runlevel.

nginx-1.12.2 now added. This ebuild has number of corrections in it's configure as well as adding support for stream modules, absent in older ebuild versions. This is controlled by NGINX_MODULES_STREAM expand variable, which is added into profiles. 1.12.2 version also including CVE-2017-7529 fix. for the bleeding edge version followers, version 1.13.7 added. This ebuild has a dedicated SLOT called mainline, to follow upstream releases tags: https://nginx.org/ and is made that it cannot be co-installed with stable versions, such as 1.12.2. This will help to distinguish the releases by upstream classification. 1.13.7 version has no keywords, it is required to unmask by keywords to be able to test. Thanks, Oleg.

i cannot say about eix as i don't use it, but yes it can be indirectly good for eix. As jhan pointed, when ebuild installed , there are may various metadata about ebuild installed into /var/db/* including special file repository, which has all information about what repo ebuild installed from. --newrepo will rebuild those ebuilds that now changed it's origin, for example sys-libs/ncurses::gentoo will be sys-libs/ncruses::core-kit, so gentoo was a name of repository (and which was in /usr/portage). With rebuild you will get your /var/db correctly set. Which might fix eix (i can't tell)

sorry, --newrepo, it was typo with --new-repo

alright, Funtoo had this ebuild merged from a dedicated overlay, called funtoo-plex. Thats for ports-2012. Now it is set in merge-scripts for the meta-repo but not activated. So, i think, you report it on bugs.funtoo.org for inclusion.

what package is this?

if you change the gentoo values into core-kit, (gentoo:funtoo into core-kit:funtoo) the tools from gentoolkit will work. this problem is reported

please, report this on bugs.funtoo.org with complete emerge output

can you attach your parent file?

bus error would be an indication of some hardware problems still. for the .config, there ebuilds that looks for existence of /usr/src/linux, but those warnings should be harmless as normally they are for the runtime functionality. If the kernel sources needed for the bulding, then it should die during compilation. More information can be obtained from full build.log

fixed lxqt-panel.

this looks like a lxqt-panel problem, according to build.log. not likely your system problem.

sorry, you can report both issues. The build failure and the forum problem, separately :)

please report this on bugs.funtoo.org

thank you. yes, the ebuild has no keywords, so adding them is step prior to emerge. Yes, due to many modules enabled by default, during compilation disk space consuming picks around 18Gb, so 20Gb is set so that there is plenty of space.

debian-sources-4.13.10 added some time back, currently with no keywords set. Please, give it a test nd report back the problems encountered.

Such problems needed reported on bugs.funtoo.org so that they are fixed for everyone.

what instruction you followed, so we know?

no consolekit in boot and default runlevels does not necessarily mean this service is not started by some other services. There are service dependencies capabilities in openrc which could make the service start other service even if it's not explicitly enabled. But i think xdm, which is in your default level could be a problematic one.