| Summary: | x11-base/xorg-server-1.6.5 Fails to compile | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Steve Warren <warrensg2001> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | foontala, zsojka |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
environment build.log after insallinig x11-libs/libXinerama-1.1 environment after installing x11-libs/libXinerama-1.1 |
||
|
Description
Steve Warren
2009-10-31 15:43:03 UTC
Created attachment 208861 [details]
build.log
Created attachment 208862 [details]
environment
Do you have libXinerama installed? # equery b panoramiXext.h on my system shows the file belongs to x11-libs/libXinerama-1.1. Maybe the xorg-server ebuild is missing this dependency.
I didn't have x11-libs/libXinerama-1.1, so I installed livXinerama and now
xorg-server fails with:
In file included from ../Xext/panoramiX.h:44,
from dispatch.c:134:
/usr/include/X11/extensions/panoramiXext.h:49: error: expected ')' before '*'
token
/usr/include/X11/extensions/panoramiXext.h:54: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'XPanoramiXQueryVersion'
/usr/include/X11/extensions/panoramiXext.h:64: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'XPanoramiXGetState'
/usr/include/X11/extensions/panoramiXext.h:70: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'XPanoramiXGetScreenCount'
/usr/include/X11/extensions/panoramiXext.h:76: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'XPanoramiXGetScreenSize'
dispatch.c: In function 'ProcCloseFont':
dispatch.c:1117: warning: 'SecurityLookupIDByType' is deprecated (declared at
../include/resource.h:268)
make[2]: *** [dispatch.lo] Error 1
Created attachment 208867 [details]
build.log after insallinig x11-libs/libXinerama-1.1
Created attachment 208869 [details]
environment after installing x11-libs/libXinerama-1.1
*** Bug 291319 has been marked as a duplicate of this bug. *** *** Bug 291319 has been marked as a duplicate of this bug. *** This seems to affect xorg-server-1.6.5 only. After removing all nvidia stuff, emerge jumped directly to xorg-server-1.7.1, which compiled without issues. Google found this post: http://www.mail-archive.com/xorg@lists.freedesktop.org/msg04615.html , but I'm not quite sure what to make of it. Unfortunately there are no nvidia drivers that will work with xorg-server-1.7.1, which meant that xorg-server-1.7.1 is not a fix. The most up to date nvidia driver for my card is 173.14.20 with no idea when there will be a 173.14.21 and nvidia is not talking. Have you tried the nv driver from xorg as a temporary alternative? If you want to go back to xorg-server 1.6, you need to add the following list to your portage.mask list :
>=x11-apps/xinput-1.5.0
>=x11-base/xorg-drivers-1.7
>=x11-base/xorg-server-1.7.1
>=x11-libs/libX11-1.3.2
>=x11-libs/libXScrnSaver-1.2.0
>=x11-libs/libXext-1.1.1
>=x11-libs/libXi-1.3
>=x11-libs/libXinerama-1.1
>=x11-libs/libXtst-1.1.0
>=x11-libs/libXxf86dga-1.1.1
>=x11-libs/libXxf86vm-1.1.0
>=x11-proto/bigreqsproto-1.1.0
>=x11-proto/fixesproto-4.1.1
>=x11-proto/inputproto-2.0
>=x11-proto/recordproto-1.14
>=x11-proto/scrnsaverproto-1.2.0
>=x11-proto/xcmiscproto-1.2.0
>=x11-proto/xextproto-7.1.1
>=x11-proto/xf86bigfontproto-1.2.0
>=x11-proto/xf86dgaproto-2.1
>=x11-proto/xf86driproto-2.1.0
>=x11-proto/xf86vidmodeproto-2.3
>=x11-proto/xineramaproto-1.2
Better yet, fully upgrade your system to 1.7 with "emerge -DuNa world".
Thanks
I'm running into this issue doing a re-emerge of my entire system. Please explain why this is "RESOLVED INVALID". There should be blocks/deps in place that prevent any of the xorg-server 1.7 pieces from being installed if it is discovered that nvidia-drivers (or whatever) will not work with that version. Similar situations have occurred before. I don't understand why this is different. (In reply to comment #13) > Please explain why this is "RESOLVED INVALID". There should be blocks/deps in > place that prevent any of the xorg-server 1.7 pieces from being installed if it > is discovered that nvidia-drivers (or whatever) will not work with that > version. Portage wants to pull both xorg-server 1.7 and nvidia-drivers, but the blocker in place tells portage to stop. Portage cannot pick which one you want, xorg 1.7 or nvidia-drivers. That's up to _you_ to tell portage which one you want. > Similar situations have occurred before. I don't understand why this > is different. Right and like last times, you have to put masks. The only difference here is that you need to use the list we provided for package.mask. Thanks (In reply to comment #14) > Portage wants to pull both xorg-server 1.7 and nvidia-drivers, but the blocker > in place tells portage to stop. Portage cannot pick which one you want, xorg > 1.7 or nvidia-drivers. That's up to _you_ to tell portage which one you want. > > > Similar situations have occurred before. I don't understand why this > > is different. > > Right and like last times, you have to put masks. The only difference here is > that you need to use the list we provided for package.mask. > > Thanks > In those past situations, emerge basically 'shouts' that the situation cannot be resolved by displaying hard blocks and listing all the affected packages pulling in the deps. At least then we know we have to take a look somewhere for information and decide how to handle it. This time, I never saw a single block and had no clue xorg-server-1.7 even existed until xorg-server-1.6.5 failed to compile. All these items you show that need to be masked for xorg-server-1.6.5 actually are installed and seemingly working fine with my existing setup. I only ran into this issue when trying to rebuild xorg-server. So, no, this time is definitely not like those past situations. The solution in my mind is to put the proper deps into xorg-server-1.6.5 and wherever else so it won't pull in these items that are supposed to be masked. Conversely, put deps into these newer items that prevent them from being installed if xorg-server-1.6.5 is present. Maybe both. Again, that can't happen because ebuilds don't support range dependencies (for example "need libXi >=1.2 and <2.0") So no, there's nothing we can do here. We expect people to upgrade to all the latest ~arch packages, other mixes are really hard to support, especially with the current EAPIs. Thanks I'm not sure if I got this right, but wouldn't something like RDEPEND !>x11-libs/libXinerama-1.0.3 in the xorg-server-1.6.5 ebuild or RDEPEND !>x11-base/xorg-server-1.6.5 in the libXinerama-1.1 ebuild (and the others) have prevented this and led to more meaningful messages? Without nividia-drivers that work with xorg-server-1.7.1 going to 1.7.1 is not an option. Why should I prefer the 2d nv driver that has less functionality to the nvidia 3d driver that makes for more functionality? It seems to me that xorg-server-1.7.1 would downgrade the usefulness of my computer at this time. (In reply to comment #18) > Without nividia-drivers that work with xorg-server-1.7.1 going to 1.7.1 is not > an option. Why should I prefer the 2d nv driver that has less functionality to > the nvidia 3d driver that makes for more functionality? It seems to me that > xorg-server-1.7.1 would downgrade the usefulness of my computer at this time. > > If you have a supported card, unmask the following: x11-drivers/nvidia-drivers-190.42-r2 media-video/nvidia-settings-190.42 if you use this Both work fine for me with an 8600 GT. Check with nVidia to see if there will be any updates to the older drivers to support the newer ABI.
>
> If you have a supported card, unmask the following:
> x11-drivers/nvidia-drivers-190.42-r2
> media-video/nvidia-settings-190.42 if you use this
>
> Both work fine for me with an 8600 GT. Check with nVidia to see if there will
> be any updates to the older drivers to support the newer ABI.
>
My card is a 5950 ULTRA which is supported with x11-drivers/nvidia-drivers-173.14.20. Until nvidia releases a new driver xorg-server is useless to me. xorg-server-1.6.5 is the highest ~x86 that I can use.
*** Bug 291892 has been marked as a duplicate of this bug. *** *** Bug 291857 has been marked as a duplicate of this bug. *** > In those past situations, emerge basically 'shouts' that the situation cannot
> be resolved by displaying hard blocks and listing all the affected packages
> pulling in the deps. At least then we know we have to take a look somewhere
> for information and decide how to handle it.
>
> This time, I never saw a single block and had no clue xorg-server-1.7 even
> existed until xorg-server-1.6.5 failed to compile. All these items you show
> that need to be masked for xorg-server-1.6.5 actually are installed and
> seemingly working fine with my existing setup. I only ran into this issue when
> trying to rebuild xorg-server.
>
> So, no, this time is definitely not like those past situations. The solution
> in my mind is to put the proper deps into xorg-server-1.6.5 and wherever else
> so it won't pull in these items that are supposed to be masked. Conversely,
> put deps into these newer items that prevent them from being installed if
> xorg-server-1.6.5 is present. Maybe both.
>
I have the same issue you have been suffering but IMHO i think that the message
Gentoo gives as feedback in my case is very clear:
Actual Results:
!!! One or more updates have been skipped due to a dependency conflict:
x11-base/xorg-server:0
('ebuild', '/', 'x11-base/xorg-server-1.7.1', 'merge') conflicts with
<x11-base/xorg-server-1.6.99 required by ('installed', '/',
'x11-drivers/nvidia-drivers-96.43.13', 'nomerge')
I think that as Remi Cardona said: "That's up to _you_ to tell portage which
one you want." and at least you can look around to see if others have the same
problem and that you discover once again that closed source is a pain in the
neck for all of us... ;)
Again, i would like to thank the gentoo team for the help in this issue, but
IMHO i think that recommending nv driver isn't quite a great solution in the
21st century. 90% of the users will want 3d support so i think that maybe a new
USE flag could be great... something like legacy-nvidia. With this USE flag,
portage could understand that this users don't want to upgrade to
xorg-server-1.7.1
Ok, it is only an idea and i don't really know if this would work.
(In reply to comment #14) > Portage wants to pull both xorg-server 1.7 and nvidia-drivers, but the blocker > in place tells portage to stop. Portage cannot pick which one you want, xorg > 1.7 or nvidia-drivers. That's up to _you_ to tell portage which one you want. excuses, excuses, excuses ... I HAVE TOLD to portage that I want nvidia-drivers by explicitly emerging them which leads to nvidia-drivers being recorded in "world" I have NOT told to portage that I want xorg-server (of any version) - it was pulled in as dependency it is NOT my job to manually resolve dependencies, it is portage's job (In reply to comment #24) > excuses, excuses, excuses ... Then send us patches instead of complaining. I have done _everything_ portage allows me to do. So thanks for the token of gratitude, you make me glow. (In reply to comment #25) > (In reply to comment #24) > > excuses, excuses, excuses ... > Then send us patches instead of complaining. I'm not a Python programmer everyone has his role and no one can do everything - I contribute to F/OSS by testing, some translations and Fedora packaging (competition! heretic! burn him! :-) > I have done _everything_ portage allows me to do. then it is portage what needs to be improved; what is the bug number I can vote for? > So thanks for the token of gratitude, you make me glow. the point is not what you are doing for the packaging; in no way I am saying that I am not grateful for all the work that the developers, including you, do for us, the users the point is that you are telling us there is no bug while users keep running into it - sorry, no gratitude for this you could choose to say "sorry guys, it is really hard for us to support it, please use this workaround, WONTFIX" instead of "it is your fault that portage is unable to resolve the dependecies correctly, INVALID" sorry for me being a bit impolite, but I got hurt first but this leads to nowhere; I'm just explaining my attitude, take it or leave it so, to be constructive: what is wrong with the solution proposed within comment #17? (In reply to comment #12) > If you want to go back to xorg-server 1.6, you need to add the following list > to your portage.mask list : > > >=x11-apps/xinput-1.5.0 > >=x11-base/xorg-drivers-1.7 > >=x11-base/xorg-server-1.7.1 > >=x11-libs/libX11-1.3.2 > >=x11-libs/libXScrnSaver-1.2.0 > >=x11-libs/libXext-1.1.1 > >=x11-libs/libXi-1.3 > >=x11-libs/libXinerama-1.1 > >=x11-libs/libXtst-1.1.0 > >=x11-libs/libXxf86dga-1.1.1 > >=x11-libs/libXxf86vm-1.1.0 > >=x11-proto/bigreqsproto-1.1.0 > >=x11-proto/fixesproto-4.1.1 > >=x11-proto/inputproto-2.0 > >=x11-proto/recordproto-1.14 > >=x11-proto/scrnsaverproto-1.2.0 > >=x11-proto/xcmiscproto-1.2.0 > >=x11-proto/xextproto-7.1.1 > >=x11-proto/xf86bigfontproto-1.2.0 > >=x11-proto/xf86dgaproto-2.1 > >=x11-proto/xf86driproto-2.1.0 > >=x11-proto/xf86vidmodeproto-2.3 > >=x11-proto/xineramaproto-1.2 > > Better yet, fully upgrade your system to 1.7 with "emerge -DuNa world". > > Thanks > Thanks remi, this mask list is exactly what I needed. Although the resolution may be by nature a bit harsh, Wontfix ( ie: cant be fixed for whatever reason and cite the reason ) will hopefully have less user-spite. *** Bug 292669 has been marked as a duplicate of this bug. *** I might be misunderstanding something, but ebuild for ati-drivers does have a dual dependency for xorg-serrver and it works just as expected. So why is it not possible to add deps to xorg-server ebuild in the same way?
RDEPEND="
!>=x11-base/xorg-server-1.7.0
>=x11-base/xorg-server-1.5.3-r7
"
*** Bug 295267 has been marked as a duplicate of this bug. *** *** Bug 296077 has been marked as a duplicate of this bug. *** *** Bug 296077 has been marked as a duplicate of this bug. *** *** Bug 296077 has been marked as a duplicate of this bug. *** *** Bug 296077 has been marked as a duplicate of this bug. *** *** Bug 296077 has been marked as a duplicate of this bug. *** *** Bug 296077 has been marked as a duplicate of this bug. *** Sorry for all the noise folks, I'll just un-CC you in case there are more duped bugs (or if the war waging in bug #296077 doesn't settle down). Cheers :) *** Bug 301351 has been marked as a duplicate of this bug. *** Three months after the initial report, I've run into the same bug. It's definitely a PITA, so I don't see why it is "RESOLVED" or "INVALID". Just my one cent. I also got bit with this one. There is nothing we can do? On my system I needed to mask these as well: >=x11-libs/libdmx-1.1.0 >=x11-proto/dmxproto-2.3 (In reply to comment #12) > If you want to go back to xorg-server 1.6, you need to add the following list > to your portage.mask list : > > >=x11-apps/xinput-1.5.0 > >=x11-base/xorg-drivers-1.7 > >=x11-base/xorg-server-1.7.1 > >=x11-libs/libX11-1.3.2 > >=x11-libs/libXScrnSaver-1.2.0 > >=x11-libs/libXext-1.1.1 > >=x11-libs/libXi-1.3 > >=x11-libs/libXinerama-1.1 > >=x11-libs/libXtst-1.1.0 > >=x11-libs/libXxf86dga-1.1.1 > >=x11-libs/libXxf86vm-1.1.0 > >=x11-proto/bigreqsproto-1.1.0 > >=x11-proto/fixesproto-4.1.1 > >=x11-proto/inputproto-2.0 > >=x11-proto/recordproto-1.14 > >=x11-proto/scrnsaverproto-1.2.0 > >=x11-proto/xcmiscproto-1.2.0 > >=x11-proto/xextproto-7.1.1 > >=x11-proto/xf86bigfontproto-1.2.0 > >=x11-proto/xf86dgaproto-2.1 > >=x11-proto/xf86driproto-2.1.0 > >=x11-proto/xf86vidmodeproto-2.3 > >=x11-proto/xineramaproto-1.2 > > Better yet, fully upgrade your system to 1.7 with "emerge -DuNa world". > > Thanks > |
