Oleg Vinichenko

alright. actually there is newer version of kernel, which we need to update. for more device support (and Ryzen cpu;s too), so yes. update for the kernel is in progress.

we can fix the surface pro 4 problem. please report it.

i added the -r3 today. fix for the hostapd ebuild in progress.

no, this is no longer needed.

its ok now.

for the 1.17 xorg prime mesa-13.0.1 has got the fix.

okey, thx. was little bit confused about the service. does it work ok? for the dell xps 9365 problem it could be a regression in 2.3 version, another problem could be that update to sys-app/hwids is required so that fixes for acceleration matrix in 60-sensors.hwdb could fix. I saw some fixes for the dell xps mentioned in hwdb.

i remember this problem and will fix now

okey, so i guess you using systemd, right? i will add the init-script for the ii-sensor-proxy as it's mainly the goal of ebuild addition.

thx for testing. the service, you mean it is systemd service?

the build failure is not the same, now you need to rebuild dev-cpp/libcmis did you by chance updated gcc? please, show output of gcc-config -l

attach fresh build.log

5.4.0 is not masked, that's right.

try rebuilding app-text/hunspell prior to libreoffice merge.

the version for chromium specified in this thread can be compiled with the version of gcc in portage tree. that's 5.4.0

ebuild is already added into funtoo portage tree. gnome-extra/iio-sensor-proxy-2.3

i took the opportunity and added ebuild for testing. actually it is not really hardcoded as i previously thought.

you can try using systemd on a funtoo box, it's not forbidden, but officially systemd is not supported. for the ii-sensor-proxy, maybe there is an alternative software that does same.

that's right, but ebuilds are not added this way. gentoo adding whole update of kde-apps/plasma/frameworks and not partial categories or they do?

i know gentoo never updates kde parts asynchronously, so having a separate kits for kde-apps/frameworks/plasma doesn't seem a necessary step. this could change on their side, of course :)

packages are not flowing from master into prime branches. when new (testing) branch is created ebuilds/eclasses that creating a branch are coming from a certain snapshot of gentoo portage tree controlled by git SHA. it can be set to false, so it is not enabled by default but is available for testing, it can be set to true, when its ready to be used by default. a good thing is that users are actually allowed to do whatever they want with the branches, however the consequences might be various. when the problem happening with default prime branches, there are sa-called kit-fixups, which serve for fixing - it may involve minor ebuilds updates, not critical ebuild updates, security backports and other. so yes, branches are partially immutable

it is already implemented on portage level by using --pretend emerge --pretend --verbose pkgname ( -pv is a shortcut) will give you the list of ebuilds, including the pkgname emerge --onlydeps --pretend --versose pkgname ( -opv is a shortcut) will give you the list of dependencies of pkgname

this is reflected in: http://www.funtoo.org/News:Python_Multiplexing(And_another_Ego_update)

this is fixed 2 days ago