| Summary: | x11-drivers/ati-drivers not compatible with xorg-server-1.7.1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fabio Coatti <fabio.coatti> |
| Component: | Current packages | Assignee: | Luca Barbato <lu_zero> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anm.mlist01, artie.ziff, boltomli, fcoiffie, heracher, ilzogoiby, jarausch, kuba.iluvatar, njdoyle+bugs, order+gentoo, pacho, peter_sliepenbeek, strowi, vomacko, vyacheslavovich, x11 |
| Priority: | High | Keywords: | InOverlay, InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 308521 | ||
|
Description
Fabio Coatti
2009-10-27 12:57:34 UTC
The Catalyst driver doesn't support 1.7. It will probably take a while until they support it. 1.7 must be masked in ati-drivers (I don't like pointing fingers, but this should have happened already; it's a well known fact that Catalyst does *not* support 1.7.) *** Bug 290746 has been marked as a duplicate of this bug. *** It seems xorg-server dependencies are wrong (resulting in X 1.7 stuff getting happily installed without any blockers, breaking your system :D). ati-drivers users must also mask the following (and maybe more, probably depends on what else your USE flags pull in):
>=x11-base/xorg-server-1.7
>=x11-proto/xcmiscproto-1.2.0
>=x11-proto/bigreqsproto-1.1.0
>=x11-proto/xf86driproto-2.1.0
>=x11-proto/xf86bigfontproto-1.2.0
>=x11-base/xorg-drivers-1.7
>=x11-proto/xextproto-7.1.1
>=x11-proto/fixesproto-4.1.1
>=x11-proto/inputproto-2.0
>=x11-libs/libX11-1.3.2
>=x11-libs/libXext-1.1.1
>=x11-libs/libXi-1.3
>=x11-apps/xinput-1.5.0
>=x11-proto/xf86vidmodeproto-2.3
>=x11-libs/libXxf86vm-1.1.0
>=x11-proto/recordproto-1.14
>=x11-libs/libXtst-1.1.0
>=x11-proto/scrnsaverproto-1.2.0
>=x11-libs/libXScrnSaver-1.2.0
>=x11-proto/xineramaproto-1.2
>=x11-libs/libXinerama-1.1
>=x11-proto/xf86dgaproto-2.1
>=x11-libs/libXxf86dga-1.1.1
wow, nice list :) but the thing that should be taken care is the fact that if I install xorg-1.7 and then i switch back to 1.6, the compilation fails regardless of the presence of ati-drivers, so maybe the things are two: 1- prevent ati binary drivers to allow the installation of xorg 1.7 2- fix the dependencies in xorg ebuild so to avoid to build 1.6 with packages that can work only with 1.7 (imho, of course) I used a similar list as N.Chantziaras, I masked all the versions of the packages that were installed with the updated portage this morning, and I could recompile xorg-server-1.6.5. It wasn't without trouble as I had to unmerge some packages due to file collisions, and resume the current merge. But now the fglrx drivers are functionning again, so this solution works, until Ati releases a new driver supporting xorg-server 1.7. A bit more info: If you already upgraded to 1.7 and can't downgrade to 1.6 again, first mask the packages I listed above, and then try to "emerge -a1" (the "1" is important in order not to mess up your world file) the following packages: =x11-proto/inputproto-1.5.1 =x11-proto/bigreqsproto-1.0.2 =x11-proto/recordproto-1.13.2 =x11-proto/scrnsaverproto-1.1.0 =x11-proto/xcmiscproto-1.1.2 =x11-proto/xf86dgaproto-2.0.3 =x11-proto/xf86vidmodeproto-2.2.2 =x11-proto/xineramaproto-1.1.2 =x11-base/xorg-drivers-1.6 =x11-proto/fixesproto-4.0 =x11-proto/xf86bigfontproto-1.1.2 =x11-proto/xf86driproto-2.0.4 =x11-proto/xextproto-7.0.5 =x11-libs/libX11-1.2.2 =x11-libs/libXext-1.0.5 =x11-libs/libXi-1.2.1 =x11-libs/libXtst-1.0.3 =x11-libs/libXScrnSaver-1.1.3 =x11-libs/libXinerama-1.0.3 =x11-libs/libXxf86dga-1.0.2 =x11-libs/libXxf86vm-1.0.2 =x11-apps/xinput-1.4.2 =x11-base/xorg-server-1.6.5 You will get conflicts along the way. When there's a conflict, "emerge -C" the conflicting package (it will be the one installed by xorg 1.7). Keep going and bit by bit this will remove 1.7 and restore 1.6 again. When finished, do an "emerge -a1 $(qlist -Iv x11-drivers)" followed by an "emerge -auD --with-bdeps=y world". If the latter wants to pull in xorg 1.7 stuff again, mask it. Keep going until nothing from 1.7 gets pulled in. An "emerge -a --depclean" might also be a good idea to get rid of some possibly left behind 1.7 deps. (In reply to comment #1) > (I don't like pointing fingers, but this > should have happened already; it's a well known fact that Catalyst does *not* > support 1.7.) I went ahead and did the finger pointing (i.e. bug assigned and CCed lu_zero and scarabeus). Not sure what the easiest/best solution is here, whether the masking should be done in ati-drivers or xorg-drivers or else, but this needs to be fixed before dupes start pouring. The list of packages and their dependencies isn't trivial so it may be better managed by the x11 people than the ati ones. Denis. Fixed. Blockers updated. emerge -u world still wants to pull stuff from xorg 1.7, even when masking ">=x11-base/xorg-server-1.7". Should I open another bug for this? While the blocking happened too late for me {I dealt with this yesterday - thanks to Nikos for his guidance!}, I do want to point out that the rollback might leave you with "opengl" pointing at "xorg" instead of "ati"
If you need to roll back to xorg-server-1.6.5 {and friends}, don't forget to run "eselect opengl list" to confirm that you're still pointing where you want to be.
Otherwise you might be left scratching your head wondering why the screen is frozen black and just what you did wrong. I had to ssh from another box and reboot before several times before I thought to check my opengl settings.
(In reply to comment #9) > emerge -u world still wants to pull stuff from xorg 1.7, even when masking > ">=x11-base/xorg-server-1.7". Should I open another bug for this? No, that's the exact same bug which wasn't fixed properly. Here's the list of the necessary blockers: !>=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 It should be the same as what Nikos posted above except it's all sorted in alphabetical order ready to be pasted in the ebuild. Denis. Blockers added to xorg-server-1.6.5. So now it should be done :] Reopening since it is still issue Exactly. I just synced portage, and here is what I get:
________________________________________
⋮
[blocks B ] >=x11-base/xorg-server-1.7.0 (">=x11-base/xorg-server-1.7.0"
is blocking x11-drivers/ati-drivers-9.10)
⋮
Conflict: 1 block (1 unsatisfied)
⋮
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
('ebuild', '/', 'x11-base/xorg-server-1.7.1', 'merge') pulled in by
>=x11-base/xorg-server-1.5.99.901 required by ('installed', '/', >'x11-drivers/xf86-input-mouse-1.5.0', 'nomerge')
>=x11-base/xorg-server-1.6 required by ('ebuild', '/', >'x11-drivers/xf86-input-joystick-1.5.0', 'merge')
>=x11-base/xorg-server-1.1.1-r1 required by ('ebuild', '/', >'x11-wm/compiz-0.8.4', 'merge')
(and 7 more)
('installed', '/', 'x11-drivers/ati-drivers-9.10', 'nomerge') pulled in by
x11-drivers/ati-drivers required by ('ebuild', '/', 'x11-base/xorg-drivers-1.7', 'merge')
x11-drivers/ati-drivers required by @world
________________________________________
You don’t expect me to resolve that mess myself, do you? ^^
What do I do, to be able to update my system again? As this blocks emerge completely.
I suppose you would have to downgrade to a lower version of xorg-server, since xorg-server-1.7.1 doesn't seem to want to work with fglrx (which is why ati-drivers is so heavily masked). I tried unmerging, and then building a previous version of xorg-server, but the compilation kept on failing -- so I'm stuck with 1.7.1 for the time being, without hardware acceleration. Whoever's end this problem lies with, this needs to be fixed, pronto. (In reply to comment #15) > I suppose you would have to downgrade to a lower version of xorg-server, since > xorg-server-1.7.1 doesn't seem to want to work with fglrx Uuum, I haven’n upgraded yet, and am using 1.6.5 right now. But it wants to upgrade to 1.7.x despite ati-drivers-9.10 being installed. As a temporary solution put this into package.mask ## ati-drivers sucker =x11-proto/xf86vidmodeproto-2.3 =x11-proto/xineramaproto-1.2 =x11-base/xorg-drivers-1.7 =x11-base/xorg-server-1.7.1 =x11-proto/recordproto-1.14 =x11-libs/libX11-1.3.2 =x11-proto/fixesproto-4.1.1 =x11-proto/xextproto-7.1.1 =x11-libs/libXext-1.1.1 =x11-proto/inputproto-2.0 =x11-libs/libXi-1.3 =x11-apps/xinput-1.5.0 =x11-libs/libXxf86vm-1.1.0 =x11-libs/libXxf86dga-1.1.1 =x11-libs/libXinerama-1.1 =x11-libs/libXtst-1.1.0 =x11-libs/libXScrnSaver-1.2.0 =x11-proto/scrnsaverproto-1.2.0 (In reply to comment #17) > As a temporary solution put this into package.mask Hey, thank you! This brought me further. :) But unfortunately, now I get: ________________________________________ [blocks B ] <x11-libs/libXtst-1.0.99.2 ("<x11-libs/libXtst-1.0.99.2" is blocking x11-proto/recordproto-1.14) [blocks B ] <x11-libs/libXxf86dga-1.0.99.1 ("<x11-libs/libXxf86dga-1.0.99.1" is blocking x11-proto/xf86dgaproto-2.1) ⋮ Conflict: 4 blocks (1 unsatisfied) ⋮ * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('ebuild', '/', 'x11-libs/libXxf86dga-1.0.2', 'merge') pulled in by x11-libs/libXxf86dga required by ('installed', '/', 'x11-apps/xdpyinfo-1.1.0', 'nomerge') x11-libs/libXxf86dga required by ('installed', '/', 'x11-apps/xf86dga-1.0.2', 'nomerge') x11-libs/libXxf86dga required by ('installed', '/', 'media-video/mplayer-1.0_rc4_p20091026-r1', 'nomerge') ________________________________________ Dunno if it’s related though. Pasting it just in case. I definitely still can’t update the system :/ (In reply to comment #15) > I suppose you would have to downgrade to a lower version of xorg-server, since > xorg-server-1.7.1 doesn't seem to want to work with fglrx (which is why > ati-drivers is so heavily masked). [...] > Whoever's end this problem lies with, this needs to be fixed, pronto. It's not xorg-server that doesn't play nice with fglrx, it's the other way around. If you want to blame someone, blame ATI/AMD for their binary driver. Our X11 policy is very clear, we're not holding X back because of binary drivers. We've done that in the past and it was a horrible mistake, one we won't be making again. Now, on our side, the problem with portage is that we can't have ranged deps. So you'll have to use a package.mask. That's how portage is, and that's probably not going to happen, this feature was already discussed and turned down. So all of you quit moaning and try the open-source driver instead. ATI _is_ doing a much better job at improving the OSS driver than their binary one... Thanks BTW, here's the proper package.mask entry you should be using if you want to stay with xorg-server 1.6. https://bugs.gentoo.org/show_bug.cgi?id=291312#c12 Thanks (In reply to comment #19) > (In reply to comment #15) While I competely and totaly agree with you everything you said, this still does not help me much. I would love to switch to the open ati xorg driver. But until it supports 3D + composite + multiple monitors + proper video acceleration, I'm pretty much forced to stay with the closed source driver. Despite it just having support for my setup and running stable since the last version. And despite the videos looking crappy if I don’t reset xv every time I start playing a video. I'm just one of those who fell into the trap of buying a modern ATi card. And I can’t just buy another one, because I need the money for food. ^^ So realistically, you may not care much. And I understand that. But I still would like to use my computer. ^^ I hope you understand that. :) Because nobody in its right mind would blame xorg for this mess. You're offering great software, for it being free, anyway. :) (In reply to comment #20) > BTW, here's the proper package.mask entry you should be using if you want to > stay with xorg-server 1.6. But is it normal that this "proper" list wants a massive list of 21 downgrades on my xorg-server-1.6.5 system? Including downgrading to 1.6 instead of 1.6.5. I don’t think I want to risk executing that… We rely on portage to aid us at masking required packages. If we can't even rely on portage...
The problem is not that we must mask stuff ourselves. That's a given with portage. The problem is only that once you mask the blockers, portage does *not* produce any more blockers. What I mean is this:
User wants to update world. At first, portage barks with:
[blocks B ] >=x11-base/xorg-server-1.7.0 (">=x11-base/xorg-server-1.7.0" is blocking x11-drivers/ati-drivers-9.10)
The block is correct, so the user goes and masks >=x11-base/xorg-server-1.7. Then tries to update again and portage proceeds with:
[ebuild U ] x11-proto/xcmiscproto-1.2.0 [1.1.2]
[ebuild U ] x11-proto/bigreqsproto-1.1.0 [1.0.2]
[ebuild U ] x11-proto/xf86driproto-2.1.0 [2.0.4]
[ebuild U ] x11-proto/xf86bigfontproto-1.2.0 [1.1.2]
[ebuild U ] x11-base/xorg-drivers-1.7 [1.6]
[ebuild U ] x11-proto/xextproto-7.1.1 [7.0.5]
[ebuild U ] x11-proto/fixesproto-4.1.1 [4.0]
[ebuild U ] x11-proto/inputproto-2.0 [1.5.1]
[ebuild U ] x11-libs/libX11-1.3.2 [1.2.2] USE="-test%"
[ebuild U ] x11-libs/libXext-1.1.1 [1.0.5]
[blocks b ] <x11-libs/libXext-1.0.99 ("<x11-libs/libXext-1.0.99" is blocking x11-proto/xextproto-7.1.1)
[ebuild U ] x11-libs/libXi-1.3 [1.2.1]
[blocks b ] <x11-libs/libXi-1.2.99 ("<x11-libs/libXi-1.2.99" is blocking x11-proto/inputproto-2.0)
[ebuild U ] x11-apps/xinput-1.5.0 [1.4.2]
[ebuild U ] x11-proto/xf86vidmodeproto-2.3 [2.2.2]
[ebuild U ] x11-libs/libXxf86vm-1.1.0 [1.0.2]
[blocks b ] <x11-libs/libXxf86vm-1.0.99.1 ("<x11-libs/libXxf86vm-1.0.99.1" is blocking x11-proto/xf86vidmodeproto-2.3)
[ebuild U ] x11-proto/recordproto-1.14 [1.13.2]
[ebuild U ] x11-libs/libXtst-1.1.0 [1.0.3]
[blocks b ] <x11-libs/libXtst-1.0.99.2 ("<x11-libs/libXtst-1.0.99.2" is blocking x11-proto/recordproto-1.14)
[ebuild U ] x11-proto/scrnsaverproto-1.2.0 [1.1.0]
[ebuild U ] x11-libs/libXScrnSaver-1.2.0 [1.1.3]
[blocks b ] <x11-libs/libXScrnSaver-1.2 ("<x11-libs/libXScrnSaver-1.2" is blocking x11-proto/scrnsaverproto-1.2.0)
[ebuild U ] x11-proto/xineramaproto-1.2 [1.1.2]
[ebuild U ] x11-libs/libXinerama-1.1 [1.0.3]
[blocks b ] <x11-libs/libXinerama-1.0.99.1 ("<x11-libs/libXinerama-1.0.99.1" is blocking x11-proto/xineramaproto-1.2)
[ebuild U ] x11-proto/xf86dgaproto-2.1 [2.0.3]
[ebuild U ] x11-libs/libXxf86dga-1.1.1 [1.0.2]
[blocks b ] <x11-libs/libXxf86dga-1.0.99.1 ("<x11-libs/libXxf86dga-1.0.99.1" is blocking x11-proto/xf86dgaproto-2.1)
All of those blocks are soft, meaning portage will do the update even though none of those packages are supposed to be emerged with an xorg-server older than 1.7, thus breaking the user's system.
The correct behavior would be to produce real blocks so the user can use that info to mask the remaining stuff.
The current behavior is wrong, no matter how you look at it. We need to rely on portage to know what works together with what version. If we can't do that, we wouldn't be using portage in the first place but install manually from tarballs instead.
The ebuild for ati-drivers is just fine, mind you. The problem are the dependencies of the other packages. They're either missing or are completely wrong.
(In reply to comment #21) > I would love to switch to the open ati xorg driver. But > until it supports 3D + composite + multiple monitors + proper video > acceleration, I'm pretty much forced to stay with the closed source driver. Please do give the OSS drivers at some point, they're improving quickly and, depending on your chip, some/all of those features might already be working. > So realistically, you may not care much. And I understand that. But I still > would like to use my computer. ^^ I hope you understand that. :) > Because nobody in its right mind would blame xorg for this mess. You're > offering great software, for it being free, anyway. :) I just wanted to make our policy clear so that there are no misunderstandings. :) I do care about binary-driver users and I'm not the only one, it's just that there's just nothing I can do. Hence our policy. > But is it normal that this "proper" list wants a massive list of 21 downgrades > on my xorg-server-1.6.5 system? > Including downgrading to 1.6 instead of 1.6.5. That's what we had in portage just a few weeks ago when 1.7 was still masked. You're not the first one to use this mask entry, it's safe. Cheers (In reply to comment #23) > The ebuild for ati-drivers is just fine, mind you. The problem are the > dependencies of the other packages. They're either missing or are completely > wrong. Again, we can't fix that easily because ebuilds don't support ranged deps. Thanks (In reply to comment #25) > Again, we can't fix that easily because ebuilds don't support ranged deps. Which they don’t want to build in, right? So if you supply the patch to put that feature into portage, the ebuild that uses it, and the ebuilds using those ranged deps, we create an overlay "portage-actually-usable", put it all in there, and tell certain people what we think of it? ^^ (In reply to comment #24) > That's what we had in portage just a few weeks ago when 1.7 was still masked. > You're not the first one to use this mask entry, it's safe. Safe perhaps. But what about it downgrading to 1.6 instead of 1.6.5? I don’t get that one. Is there a real reason it wants to do that? (In reply to comment #18) > (In reply to comment #17) > > As a temporary solution put this into package.mask > But unfortunately, now I get: [snip] As a workaround this should be safe: quickpkg x11-libs/libXtst x11-proto/recordproto x11-libs/libXxf86dga x11-proto/xf86dgaproto then emerge -C x11-libs/libXtst x11-proto/recordproto x11-libs/libXxf86dga x11-proto/xf86dgaproto an then the emerge -DuvaN world should work. These .99 packages are not in portage anymore. Unmerging them and reemerging world should work. It worked for me an my snippet of package.mask is my current config to avoid pulling 1.7* in. regards, Sebastian (In reply to comment #24) > Please do give the OSS drivers at some point, they're improving quickly and, > depending on your chip, some/all of those features might already be working. I would love to. Even without direct 3d-rendering I would prefer OSS. BUT: my notebooks graphiccard is between 10-20°C hotter and STR works only when I sacrify a chicken at night and pray to Krautling the great german technodemon. It's a no-go at this time. (In reply to comment #27) > Safe perhaps. But what about it downgrading to 1.6 instead of 1.6.5? I don’t > get that one. Is there a real reason it wants to do that? I don't see what you're worried about here. The list in the other bug report blocks 1.7.1 and above : >=x11-base/xorg-server-1.7.1 1.6.5 being the "latest" version prior to 1.7.1 currently available in portage, that's what you'll get. Thanks (In reply to comment #30) > 1.6.5 being the "latest" version prior to 1.7.1 currently available in portage, > that's what you'll get. Because of a glitch in Portage, that was not the case until I re-synced and updated Portage. I wanted to install 1.6 (WITHOUT THE ".5"!!!!!) <-- HERE, LOOK THERE! NO ".5"!!! SO NO 1.6.5!!. ;) Sorry for not making that 100% clear before. :D But now all is good on that side. So let’s forget about it. Thanks anyway. [OT] (In reply to comment #29) > BUT: my > notebooks graphiccard is between 10-20°C hotter and STR works only when I > sacrify a chicken at night and pray to Krautling the great german technodemon. Of course it doesn’t work then! You should pray to the allmighty Technoviking! :P (*ouch* Sorry, this was impossible to resist.) (In reply to comment #25) > Again, we can't fix that easily because ebuilds don't support ranged deps. Interestingly, I saw some ebuilds in the kde3 overlay use (unsupported) ranged deps. Seems like there is something out there that does it. :) (In reply to comment #20) > BTW, here's the proper package.mask entry you should be using if you want to > stay with xorg-server 1.6. > https://bugs.gentoo.org/show_bug.cgi?id=291312#c12 Hey, I tried that one this morning. It took me until now to repair the system. That’s 6.5 hours. :( It created a giant mess, that I could only resolve trough manual deletion of files in /usr/include/X11/extensions/ (like XInput.h), manual re-ordering of the package installation order, re-syncing, updating portage, and downgrading compiz and its tools. I know that you meant good. But whoever created that mess, could at least be a bit sorry. We can help too, if it’s too much for one person. (In reply to comment #32) > [OT] > > (In reply to comment #29) > > BUT: my > > notebooks graphiccard is between 10-20°C hotter and STR works only when I > > sacrify a chicken at night and pray to Krautling the great german technodemon. > > Of course it doesn’t work then! You should pray to the allmighty > Technoviking! :P Bah! The well know, at least for a few decades, german megalomania sez to me: I'm right. Always! Liebe Grüße, Sebastian Hi guys,
I have some problems here... my video card is an X1650 and I know the latest drivers that support it is the 9.3; following this thread I've installed xorg-server 1.6.5 and ati-drivers-8.593 correctly, but now the fglrx complains about the X version, here is my Xorg.0.log output:
(II) LoadModule: "fglrx"
(II) Loading /usr/lib64/xorg/modules/drivers//fglrx_drv.so
(II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
compiled for 1.4.99.906, module version = 8.59.2
Module class: X.Org Video Driver
[atiddxSetup] X version mismatch - detected X.org 7.1.5.0, required X.org 7.4.-1.906
(II) UnloadModule: "fglrx"
(II) Unloading /usr/lib64/xorg/modules/drivers//fglrx_drv.so
(EE) Failed to load module "fglrx" (module requirement mismatch, 0)
(EE) No drivers available.
since the latest xorg-server version before 1.7.1 is 1.6.5, I really don't know what to do to have the module loaded properly! Please help me to solve this out.
Thanks
(In reply to comment #36) Hey, for your card, I recommend that you install xorg’s driver. which is enabled by putting VIDEO_CARDS="radeon" in your /etc/make.conf. (And then using e.g. “emerge -auDNtv world”) For your card, that driver is in a really great state. Much better than fglrx. With actual support. That way you can save yourself from the horrible unreliable, outdated and incompatible mess that is fglrx. Be happy you aren’t forced to use it, like me. :) (In reply to comment #37) > (In reply to comment #36) > Hey, for your card, I recommend that you install xorg’s driver. which is > enabled by putting VIDEO_CARDS="radeon" in your /etc/make.conf. (And then using > e.g. “emerge -auDNtv world”) For your card, that driver is in a really > great state. Much better than fglrx. With actual support. That way you can save > yourself from the horrible unreliable, outdated and incompatible mess that is > fglrx. Be happy you aren’t forced to use it, like me. :) > Yeah I know that, but since I've changed to OSS drivers most of the games fail to detect correctly my video card, so I wanted to reinstall the proprietary one to fix this games problem. (In reply to comment #38) > but since I've changed to OSS drivers most of the games fail > to detect correctly my video card, so I wanted to reinstall the proprietary one > to fix this games problem. That would be the first time that using fglrx would “fix” anything. :D I think the problem is, that you want to install very old fglrx drivers (which does not mean that is wrong, as long as they fit your card), but maybe still a too modern xorg-server. If possible, I’d try to find out, to which versions of xorg those old drivers are actually compatible. including things like event drivers. !!! All ebuilds that could satisfy ">=x11-proto/xf86driproto-2.0.4" have been masked. !!! One of the following masked packages is required to complete your request: - x11-proto/xf86driproto-2.1.0 (masked by: package.mask) -- cuprum xf86driproto # ls ChangeLog Manifest metadata.xml xf86driproto-2.1.0.ebuild -- Great job guys keep up the good work!! [/sarcasm] But seriously what part of xorg-1.7 breaking ati-drivers made someone think it'd be a good time to remove xorg-1.6.5 dependencies from portage? I want you to die in a fire. (In reply to comment #40) The same part that made them remove KDE 3.5? [/sarcasm] ^^ (In reply to comment #40) > !!! All ebuilds that could satisfy ">=x11-proto/xf86driproto-2.0.4" have been > masked. > !!! One of the following masked packages is required to complete your request: > - x11-proto/xf86driproto-2.1.0 (masked by: package.mask) > > -- > > cuprum xf86driproto # ls > ChangeLog Manifest metadata.xml xf86driproto-2.1.0.ebuild > > -- > > Great job guys keep up the good work!! [/sarcasm] > > But seriously what part of xorg-1.7 breaking ati-drivers made someone think > it'd be a good time to remove xorg-1.6.5 dependencies from portage? I want you > to die in a fire. > Perhaps a bit harsh, then. I haven't had any file conflicts by unmasking xfdriproto-2.1.0 as of yet. Will try to update after full emerge completes, but if this is the case users may want to try omitting >=x11-proto/xf86driproto-2.1.0 from their xorg-1.6.5 package.mask. Particularly as they have no other option. (In reply to comment #42) > Particularly as they have no other option. This sounds very evil. I guess you did not intend it. But it does. Actually there is an option. (In reply to comment #40) You can always get old ebuilds back via: http://sources.gentoo.org/viewcvs.py/gentoo-x86/ They are always still in the history if you show the dead files. But in this case… There you go: http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-proto/xf86driproto/xf86driproto-2.0.4.ebuild?hideattic=0&rev=1.13&view=log You’re welcome! :D (In reply to comment #43) > (In reply to comment #42) > > Particularly as they have no other option. > > This sounds very evil. I guess you did not intend it. But it does. > > Actually there is an option. > (In reply to comment #40) > You can always get old ebuilds back via: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/ > They are always still in the history if you show the dead files. > But in this case… There you go: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-proto/xf86driproto/xf86driproto-2.0.4.ebuild?hideattic=0&rev=1.13&view=log > > You’re welcome! :D > Touche, I suppose it's obvious I meant that as "option [within current portage]" or perhaps "option [that doesn't involve additional frustration]". Thank you for the link, though, I will try that if the 2.10 build breaks things. Well, if I can tell if it breaks things. Hard to be sure with ati-drivers, if only they could be nuked from orbit... (In reply to comment #44) > Thank you for the link, though, I will try that if the 2.10 build breaks > things. Xorg-server 1.6 should still build correctly as it's the current stable server. If not, that's a legitimate bug. (Although I think we'd have heard about it by now) > Well, if I can tell if it breaks things. Hard to be sure with > ati-drivers, if only they could be nuked from orbit... We're working on that, trust me. Just remember to be pissed at ATi/AMD for the whole fglrx situtation, there's nothing _we_ can do to fix it and we won't let it hold us hostage. We've already made that mistake in the past, we will _not_ do it twice. Thanks Maybe someone wants to give the 10.3 preview a try: http://support.amd.com/us/kbarticles/Pages/WHQL-Catalyst-driver-for-Radeon-HD5830.aspx Note: You would have to modify the ebuild to account for the differences in packaging. Don't execute the installer directly, this will break eselect opengl. bug 310367 may solve this. take a look at it Yes, it was apparently fixed in x11-drivers/ati-drivers-8.721 (In reply to comment #48) > Yes, it was apparently fixed in x11-drivers/ati-drivers-8.721 > CONFIRMED We also have 10.3 stable in portage now (In reply to comment #50) > We also have 10.3 stable in portage now By judging the ebuild, 10.3 is still _not_ compatible with xorg-server-1.7? (In reply to comment #51) > > By judging the ebuild, 10.3 is still _not_ compatible with xorg-server-1.7? > xorg-server-1.7 crashed again, when i upgraded to 10.3. Only ati-drivers-8.721 works with xorg-server-1.7 ati-drivers-10.3 does not work with xorg-server-1.7 It appears that I can take the driver from the 8.721 installer and use it in my gentoo ati-driver-10.3 ebuild; essentially faking out portage until the awesome Gentoo process has time to work its downstream magic! I extracted the fglrx driver package from the ati-driver-installer-8.703-x86.x86_64.run file. Where would I find the fglrx package in gentoo? I want to replace that one and update any chksums, etc, which the ebuild may have recorded. Am I missing anything? thank you! cat package.mask >=mail-client/thunderbird-3.0.3 >=x11-plugins/enigmail-1.0.1-r1 # xorg-server <-> ati-drivers >=x11-base/xorg-server-1.7 >=x11-proto/xcmiscproto-1.2.0 >=x11-proto/bigreqsproto-1.1.0 >=x11-proto/xf86driproto-2.1.0 >=x11-proto/xf86bigfontproto-1.2.0 >=x11-base/xorg-drivers-1.7 >=x11-proto/xextproto-7.1.1 >=x11-proto/fixesproto-4.1.1 >=x11-proto/inputproto-2.0 >=x11-libs/libX11-1.3.2 >=x11-libs/libXext-1.1.1 >=x11-libs/libXi-1.3 >=x11-apps/xinput-1.5.0 >=x11-proto/xf86vidmodeproto-2.3 >=x11-libs/libXxf86vm-1.1.0 >=x11-proto/recordproto-1.14 >=x11-libs/libXtst-1.1.0 >=x11-proto/scrnsaverproto-1.2.0 >=x11-libs/libXScrnSaver-1.2.0 >=x11-proto/xineramaproto-1.2 >=x11-libs/libXinerama-1.1 >=x11-proto/xf86dgaproto-2.1 >=x11-libs/libXxf86dga-1.1.1 emerge --pretend --oneshot x11-drivers/ati-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-power/acpid-2.0.4-r2 [ebuild N ] media-libs/mesa-7.7.1 USE="nptl xcb -debug (-gallium) -motif -pic (-selinux)" VIDEO_CARDS="radeon -intel -mach64 -mga -none -nouveau -r128 -radeonhd -savage -sis (-sunffb) -svga -tdfx -via" [ebuild N ] x11-base/xorg-server-1.6.5-r1 USE="hal ipv6 nptl xorg -debug -dmx -kdrive -minimal -sdl -tslib" [ebuild N ] x11-drivers/ati-drivers-9.11 USE="modules (multilib) -debug" [blocks B ] <x11-base/xorg-server-1.7 ("<x11-base/xorg-server-1.7" is blocking media-libs/mesa-7.7.1) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('ebuild', '/', 'x11-base/xorg-server-1.6.5-r1', 'merge') pulled in by >=x11-base/xorg-server-1.5.3-r7 required by ('ebuild', '/', 'x11-drivers/ati-drivers-9.11', 'merge') For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked !!! The following installed packages are masked: - x11-proto/xf86driproto-2.1.0 (masked by: package.mask) - x11-proto/xineramaproto-1.2 (masked by: package.mask) - x11-libs/libX11-1.3.3 (masked by: package.mask) - x11-base/xorg-drivers-1.7 (masked by: package.mask) - x11-libs/libXext-1.1.1 (masked by: package.mask) - x11-libs/libXinerama-1.1 (masked by: package.mask) - x11-proto/xf86vidmodeproto-2.3 (masked by: package.mask) - x11-proto/bigreqsproto-1.1.0 (masked by: package.mask) - x11-proto/xextproto-7.1.1 (masked by: package.mask) - x11-proto/xf86dgaproto-2.1 (masked by: package.mask) - x11-proto/fixesproto-4.1.1 (masked by: package.mask) - x11-proto/inputproto-2.0 (masked by: package.mask) - x11-libs/libXxf86vm-1.1.0 (masked by: package.mask) - x11-proto/recordproto-1.14 (masked by: package.mask) - x11-libs/libXi-1.3 (masked by: package.mask) - x11-proto/scrnsaverproto-1.2.0 (masked by: package.mask) - x11-proto/xcmiscproto-1.2.0 (masked by: package.mask) - x11-libs/libXtst-1.1.0 (masked by: package.mask) Can anybody help? My system is broken and some directions in this issue do not solve the problem! (In reply to comment #55) > [blocks B ] <x11-base/xorg-server-1.7 ("<x11-base/xorg-server-1.7" is > blocking media-libs/mesa-7.7.1) This tells you that mesa-7.7.1 requires x11-base/xorg-server-1.7 or higher which you have masked. You have to mask >media-libs/mesa-7.5.9 as well. By the way, why do you want to mask xorg-server-1.7.x (currently 1.7.6 is even stable) ? I emerged the latest stable release of xorg-server (1.7.6). However for the ati-drivers I had to unmask the latest version (10.6) with the file 'package.mask' and content 'x11-drivers/ati-drivers ~amd64' (read for '~' a tilde). Earlier versions of ati-drivers resulted in a lot of messages containing the word 'blocking'. Thanks for the reply. (In reply to comment #57) > I emerged the latest stable release of xorg-server (1.7.6). However for the > ati-drivers I had to unmask the latest version (10.6) with the file > 'package.mask' and content 'x11-drivers/ati-drivers ~amd64' (read for '~' a > tilde). So, what's wrong with ati-drivers-10.6 ? I'm running x11-drivers/ati-drivers-10.6 with x11-base/xorg-server-1.7.7 just fine. (It will probably work with the stable x11-base/xorg-server-1.7.6, as well) (In reply to comment #58) > So, what's wrong with ati-drivers-10.6 ? > I'm running x11-drivers/ati-drivers-10.6 with x11-base/xorg-server-1.7.7 > just fine. (It will probably work with the stable x11-base/xorg-server-1.7.6, > as well) > Nothing is wrong. I merely state that for a working combination of xorg-server and ati-drivers I had to unmask ati-drivers (with the stable x11-base/xorg-server-1.7.6). |
