| View previous topic :: View next topic |
| Author |
Message |
Atmmac
Tux's lil' helper
Joined: 17 Oct 2013
Posts: 130
Location: Watertown, MA
|
 Posted: Mon Jan 25, 2016 3:30 pm Post subject: xorg slot conflict |
 |
|
Any thoughts on this. Driving me crazy...
| Code: | Calculating dependencies... done!
[ebuild U ] dev-python/backports-ssl-match-hostname-3.5.0.1-r1 [3.5.0.1]
[ebuild U ] dev-python/ssl-fetch-0.4 [0.3]
[ebuild U ] virtual/jdk-1.8.0-r1 [1.8.0]
[ebuild U ] virtual/jre-1.8.0-r1 [1.8.0]
[ebuild NS ] sys-kernel/gentoo-sources-4.3.4 [4.1.6, 4.1.13, 4.1.15, 4.3.3-r1] USE="-build -experimental -kdbus -symlink"
[ebuild U ] sys-apps/openrc-0.20.4 [0.20.3]
[ebuild U ] sys-fs/lvm2-2.02.136-r1 [2.02.136] USE="-corosync% -openais%"
[ebuild U ] net-print/cups-filters-1.8.1 [1.6.0]
[ebuild U ] x11-drivers/xf86-video-intel-2.99.917_p20160122 [2.99.917-r2]
[ebuild U ] x11-base/xorg-server-1.18.0 [1.17.4]
[ebuild U ] x11-drivers/xf86-input-evdev-2.10.1 [2.9.2]
[ebuild U ] x11-base/xorg-drivers-1.18-r1 [1.17]
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
x11-base/xorg-server:0
(x11-base/xorg-server-1.17.4:0/1.17.4::gentoo, installed) pulled in by
<x11-base/xorg-server-1.17.99:= required by (x11-drivers/nvidia-drivers-361.18-r1:0/361::gentoo, installed)
^ ^^^^^^^ ^
x11-base/xorg-server:0/1.17.4= required by (x11-drivers/xf86-input-keyboard-1.8.1:0/0::gentoo, installed)
^^^^^^^^^^
(and 3 more with the same problems)
(x11-base/xorg-server-1.18.0:0/1.18.0::gentoo, ebuild scheduled for merge) pulled in by
>=x11-base/xorg-server-1.18[udev] required by (x11-drivers/xf86-input-evdev-2.10.1:0/0::gentoo, ebuild scheduled for merge)
^^ |
|
|
| Back to top |
|
 |
asturm
Developer
Joined: 05 Apr 2007
Posts: 8942
|
| Posted: Mon Jan 25, 2016 3:36 pm Post subject: |
|
|
| Current nvidia-drivers version in tree does not accept xorg-server-1.18, so it is blocking the update. |
|
| Back to top |
|
|
axl
Veteran
Joined: 11 Oct 2002
Posts: 1144
Location: Romania
|
| Posted: Mon Jan 25, 2016 9:08 pm Post subject: |
|
|
| genstorm wrote: | | Current nvidia-drivers version in tree does not accept xorg-server-1.18, so it is blocking the update. |
yes. thank you very much. brilliant. i've been dancing around my tail for an hour. not understanding who is blocking who for what reason.
echo -e "\n>=x11-drivers/xf86-input-evdev-2.10\n=x11-base/xorg-server-1.18.0\n" > /etc/portage/package.mask/x86_64-pc-linux-gnu
or
echo -e "\n>=x11-drivers/xf86-input-evdev-2.10\n=x11-base/xorg-server-1.18.0\n" > /etc/portage/package.mask
TY. TYVM.
on a side note, i hate hacking my own gentoo. feels like trying to jailbreak myself out of myself. i do realize it's my own fault because i have nvidia drivers installed. 980 board  afaik nouveau people had a very depressing post about 9(6/7/ 0 boards. ( |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8942
|
| Posted: Mon Jan 25, 2016 9:16 pm Post subject: |
|
|
You're welcome. 
Fun how, despite threads like this, some people clinging to old packages think it would be a good idea to pin down versions like this all over the place, just to avoid removing old ebuilds... |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 493
|
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Thu Jan 28, 2016 10:22 pm Post subject: |
|
|
i masked the new xorg-server but it still complains. i wait until there is a new package and it is resovled itself.
portage should focus on the nvidia-binary blob version and restriction first, because anything depends on it when you use those. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8942
|
| Posted: Thu Jan 28, 2016 10:37 pm Post subject: |
|
|
| If it still complains, your mask might be wrong? Did you check that it works (and isn't actually undone by a package.unmask entry)? |
|
| Back to top |
|
|
emsy
n00b
Joined: 16 Dec 2011
Posts: 23
|
| Posted: Fri Jan 29, 2016 2:38 am Post subject: |
|
|
| Why is nvidia driver 361.18-r1 still requiring <xorg-server-1.17.99 when nvidia driver officially supports xorg 1.18 since 352.63? |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 493
|
| Posted: Fri Jan 29, 2016 3:41 am Post subject: |
|
|
Until it is fixed in the tree (which can take months), remove all the masks and edit nvidia-driver 361.18-r1.ebuild line <xorg-server-1.17.99 to <xorg-server-1.18.99.
You can automate this change by creating file /etc/portage/postsync.d/nvidia.sh to do the change after every emerge --sync
/etc/portage/postsync.d/nvidia.sh
| Code: |
#!/bin/bash
sed -i 's/xorg-server-1.17.99/xorg-server-1.18.99/' /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-361.18-r1.ebuild
ebuild /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-361.18-r1.ebuild digest
|
|
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Fri Jan 29, 2016 11:49 am Post subject: |
|
|
I wish someone reads this and changes portage behaviour in that way that the nvidia binary blob restriction has top priority.
without the nvidia binary blob nothing works, and the usual gamer, user, do want the nvidia binary blob.
highest priority nvidia binary blob
second priority kernel restrictions
third restriction xorg-server
others...
just out of completeness.
| Code: | ASUS-G75VW roman # emerge -s xorg-server
[ Results for search key : xorg-server ]
Searching...
* x11-base/xorg-server
Latest version available: 1.17.4
Latest version installed: 1.17.4
Size of files: 5.656 KiB
Homepage: http://xorg.freedesktop.org/
Description: X.Org X servers
License: MIT
[ Applications found : 1 ]
ASUS-G75VW roman # equery y xorg-server
Keywords for x11-base/xorg-server:
| | u |
| a a a n p r s | n |
| l m r h i m m i p i s p | e u s | r
| p d a m p a 6 i o p c s 3 a x | a s l | e
| h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | p e o | p
| a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | i d t | o
-------------+---------------------------------+--------------+-------
1.12.4-r5 | + + + o o + o ~ o + + o ~ ~ + + | 5 o 0/1.12.4 | gentoo
1.12.4-r7 | ~ + + o o ~ o ~ o + + o ~ ~ ~ + | 5 o | gentoo
-------------+---------------------------------+--------------+-------
1.15.2-r2 | + + + o + + o ~ o + + o ~ ~ + + | 5 o 0/1.15.2 | gentoo
1.15.2-r4 | ~ + + o + ~ o ~ o + + o ~ ~ ~ + | 5 o | gentoo
-------------+---------------------------------+--------------+-------
1.16.4 | + + + o + + o ~ o + + o ~ ~ + + | 5 o 0/1.16.1 | gentoo
1.16.4-r5 | ~ + + o + ~ o ~ o + + o ~ ~ ~ + | 5 o | gentoo
-------------+---------------------------------+--------------+-------
[I]1.17.4 | ~ + + ~ + ~ o ~ o + + o ~ ~ ~ + | 5 o 0/1.17.4 | gentoo
-------------+---------------------------------+--------------+-------
1.18.0 | ~ ~ ~ ~ ~ ~ o ~ o ~ ~ o ~ ~ ~ ~ | 5 o 0/1.18.0 | gentoo
ASUS-G75VW roman # emerge -pv xorg-server
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] x11-base/xorg-server-1.17.4:0/1.17.4::gentoo USE="dmx nptl suid udev xorg -doc -glamor -ipv6 -kdrive -libressl -minimal (-selinux) -static-libs -systemd -tslib -unwind -wayland -xephyr -xnest -xvfb" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
ASUS-G75VW roman # emerge -pv --update --keep-going --deep -N world
These are the packages that would be merged, in order:
Calculating dependencies... done!
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
x11-base/xorg-server:0
(x11-base/xorg-server-1.17.4:0/1.17.4::gentoo, installed) pulled in by
<x11-base/xorg-server-1.17.99:= required by (x11-drivers/nvidia-drivers-361.18-r1:0/361::gentoo, installed)
^ ^^^^^^^ ^
x11-base/xorg-server:0/1.17.4= required by (x11-drivers/xf86-input-mouse-1.9.1:0/0::gentoo, installed)
^^^^^^^^^^
(and 5 more with the same problems)
(x11-base/xorg-server-1.18.0:0/1.18.0::gentoo, ebuild scheduled for merge) pulled in by
>=x11-base/xorg-server-1.18[udev] required by (x11-drivers/xf86-input-evdev-2.10.1:0/0::gentoo, ebuild scheduled for merge)
^^ ^^^^
NOTE: Use the '--verbose-conflicts' option to display parents omitted above
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.
For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.
The following mask changes are necessary to proceed:
(see "package.unmask" in the portage(5) man page for more details)
# required by x11-drivers/xf86-input-evdev-2.10.1::gentoo
# required by x11-base/xorg-drivers-1.18-r1::gentoo[input_devices_evdev]
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
=x11-base/xorg-server-1.18.0
NOTE: The --autounmask-keep-masks option will prevent emerge
from creating package.unmask or ** keyword changes.
emerge: there are no ebuilds to satisfy "dev-java/icedtea-bin:8".
(dependency required by "virtual/jdk-1.8.0-r1::gentoo" [ebuild])
(dependency required by "virtual/jre-1.8.0-r1::gentoo" [ebuild])
(dependency required by "dev-java/log4j-1.2.17-r3::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
ASUS-G75VW roman # grep xorg-server /etc/portage/package.mask
=x11-base/xorg-server-1.18.0
|
I just wait until newer nvidia-driver is out and everything resolves itself and yes there are other nonsense of portage since that newer xorg-sever hits the tree.
i sort it out when i find a bit more time for it
...
portage complains, there is no ebuild for slot 8 for the ice java thing (i do not download the oracle java crap with the fetch restriction, it is hard masked)
--
and adding more nonsense paramter to portage which do nothing in my expierence is definitely the wrong way (personal opinion)
| Quote: | | NOTE: Use the '--verbose-conflicts' option to display parents omitted above |
we have backtrack, and than you read here, hey use backtrack with 1000 or 10000
now we have this verbose-conflicts. serious no idea when it was introduced.
suggestion
default behavour
gives crap (see above)
use loop with backtrack with much higher value
issue resolve yes => shows user output
no => use other stuff like verbose conflicts
issue resolve yes => shows user output
no => throw crap
...
windi installer blocks a box for an hour with doing nothing and in gentoo we can not let it resovle dependencies for 20-30 minutes?
...
i refuse to have an ebuild installed with a fetch restriction !
i do not care for oracle or its dependencies. that is such windows like to download software on a fishy homepage, and than see, the checksum does not match, was in gentoo very very often the case. and i do not want to waste my time to than see, the devs had another checksum as when i downloaded the same package. do not ask me which fetch restriction package i talked about, but that s my motivation to hard mask any fetch restricted package. when the checksum does not match, you can use it which is bad, redownload it and see the checksum is 99 percent of the cases the same..., and most of the time nowhere a checkusm.
only android rom developers provide checksum usually. |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4591
Location: Germany
|
| Posted: Sun Jan 31, 2016 8:49 pm Post subject: |
|
|
| This should be fixed now - see Bug 572730 |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8942
|
| Posted: Mon Feb 01, 2016 12:23 am Post subject: |
|
|
| tw04l124 wrote: | | I wish someone reads this and changes portage behaviour in that way that the nvidia binary blob restriction has top priority. |
Easy tw04l124, nvidia-drivers sure is important to some people, but it will never gain priority over all the other important packages that portage contains.
Portage is talking to you and giving you all you need to solve your blocker. For completeness, this line:
| Code: | | >=x11-base/xorg-server-1.18[udev] required by (x11-drivers/xf86-input-evdev-2.10.1:0/0::gentoo, ebuild scheduled for merge) |
and then again this line (in context with the following lines)
| Code: | | # required by x11-drivers/xf86-input-evdev-2.10.1::gentoo |
would have told you to additionally mask x11-drivers/xf86-input-evdev-2.10.1 since it requires >=x11-base/xorg-server-1.18. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Mon Feb 01, 2016 3:27 pm Post subject: |
|
|
agreed, but
| Code: | emerge -pv xorg-server
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] x11-base/xorg-server-1.17.4:0/1.17.4::gentoo USE="dmx nptl suid udev xorg -doc -glamor -ipv6 -kdrive -libressl -minimal (-selinux) -static-libs -systemd -tslib -unwind -wayland -xephyr -xnest -xvfb" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
|
already udev in the flags.
i will mask the other package, but i expected it would use the old stuff itself to resolve dependencies.
Broken by design, when it upgrades packages and than realize it can not downgrade packages to resolve dependencies. So the conclusion is, portage does not take any version in the tree into account when resolving dependencies, else it would just downgrade all packages regarding xorg-server and it dependencies until it is satisfied.
...
I kicked a 7 or 8 years old notebook, asus g70sg, the bucket. and until the last month, the open source driver never ever had the support which would make them useable at all. any livecd were some effects recognizeable, a bit sluggish. And i talk about the high end top gpu, like 9800m gts. Not a midrange gpu like 9600m or something lower. I booted over a hundred live-cds or more over hte years and there I could see, what the auto configured scripts will do to initialze the gpu.
The casual user will go with the binary blob driver, only a few will go with the open source drivers.
--
As I realized now, portage only takes into account the highest possible package.
When you mask that it complains again, and to see it is .1 or .0 is hardly recognizeable when you do not look carefully.
| Quote: | (x11-base/xorg-server-1.18.0:0/1.18.0::gentoo, ebuild scheduled for merge) pulled in by
>=x11-base/xorg-server-1.18[udev] required by (x11-drivers/xf86-input-evdev-2.10.1:0/0::gentoo, ebuild scheduled for merge)
^^ ^^^^
|
| Quote: |
x11-base/xorg-server:0
(x11-base/xorg-server-1.18.0:0/1.18.0::gentoo, ebuild scheduled for merge) pulled in by
>=x11-base/xorg-server-1.18[udev] required by (x11-drivers/xf86-input-evdev-2.10.0:0/0::gentoo, ebuild scheduled for merge)
^^ ^^^^
|
| Code: | tail -2 /etc/portage/package.mask
=x11-drivers/xf86-input-evdev-2.10.1
=x11-drivers/xf86-input-evdev-2.10.0
|
Now I have the same mess with boost (2 different versions needed) and
| Code: | emerge: there are no ebuilds to satisfy "dev-java/icedtea-bin:8".
|
Sigh.
Thanks for the hint. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3667
|
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8942
|
| Posted: Mon Feb 01, 2016 6:19 pm Post subject: |
|
|
| tw04l124 wrote: | | When you mask that it complains again, and to see it is .1 or .0 is hardly recognizeable when you do not look carefully. |
Look carefully, then. 
| tw04l124 wrote: | | Code: | | emerge: there are no ebuilds to satisfy "dev-java/icedtea-bin:8". |
|
...because you masked oracle-jdk-bin:1.8 but not virtual/jdk:1.8? |
|
| Back to top |
|
|
|
Portage & Programming
