Oleg Vinichenko
-
Posts
619 -
Joined
-
Last visited
-
Days Won
53
Content Type
Profiles
Forums
Blogs
Posts posted by Oleg Vinichenko
-
-
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
-
Actually, I was able to upgrade @world by excluding only xf86-input-evdev. So I am fully updated except for some xorg-related stuff. Any ideas what I should do to update those? Am I going to have to unmerge them all, then emerge them again? (And hope that nothing goes wrong?)
# emerge -auDN @world
These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD ] x11-base/xorg-drivers-1.17 [1.18-r1] [ebuild UD ] x11-base/xorg-server-1.17.4-r2 [1.18.4] USE="nptl%*" [ebuild UD ] x11-drivers/xf86-input-evdev-2.9.2 [2.10.3] [blocks b ] >=x11-drivers/xf86-input-evdev-2.10 (">=x11-drivers/xf86-input-evdev-2.10" is blocking x11-base/xorg-server-1.17.4-r2) Oops! Conflicts have been encountered: >>> x11-drivers/xf86-video-nouveau-1.0.12:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-vesa-2.3.4:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-synaptics-1.8.3:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-keyboard-1.8.1:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-mouse-1.9.1:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-vmware-13.1.0:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= My candidates are: >>> x11-base/xorg-server-1.17.4-r2:0/1.17.4::xorg-kit, ebuild scheduled for merge has SLOT 0/1.17.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed has SLOT 0/1.18.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed, wants >=x11-base/xorg-drivers-1.18 My candidates are: >>> x11-base/xorg-drivers-1.17:0/0::xorg-kit, ebuild scheduled for merge has SLOT 0/0 >>> x11-base/xorg-drivers-1.18-r1:0/0::gentoo, installed has SLOT 0/0 We hope this informational output has been useful in identifying the problem. We are continually working to reduce conflicts. Do not hesitate to report a bug at https://bugs.funtoo.org. Thank you! :)mv /var/lib/portage/world /var/lib/portage/world.bak and try updating.
-
-
this is fixed 2 days ago
Evaluating Funtoo - questions
in General Help
Posted
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.