Oct 6, 2016, 10:57 AM
Post #3 of 3
(2222 views)
Permalink
Daiajo Tibdixious posted on Thu, 06 Oct 2016 15:57:10 +1100 as excerpted:
> Doing this on phone as chromium update still going (in console mode).
>
> Ati-drivers-15.12-r1 requires xorg-server-1.17.4 or less, yet world
> update insists on pulling in xorg-server-1.8 which then pulls in masked
> versions of xf86-input-evdev & xf86-video-ati & and the emerge dies
> because the 2 versions of xorg-server can't co-exist.
>
> I want ati-drivers as my led screen does not look good with basic radeon
> driver.
>
> I am wondering why masked versions are being pulled in as nothing in
> package.accept_keywords nor package.unmask
>
> In world I just have xorg-x11 meta package. I'm wondering if I should
> replace that with specific packages. The ebuild does not suggest its
> pulling in the 1.8 version, but I may be miss-reading it.
>
> I have manually installed the latest stable versions of the affected
> packages & expect it to work.
I know you're on the phone, but please disable HTML mail for the mailing
lists, at least. Also, on phone or not, shouldn't affect your ability to
quote and then reply in context, /under/ the part you're referring to,
instead of above it, entirely out of context.
Did you really mean the very old xorg-server-1.8, which you specified
twice so I'd ordinarily think so, but it's _really_ old, older than the
oldest 1.12.4-r5 in the main tree, so it's hardly a sane guess, or the
newer 1.18.x? 1.8, whatever graveyard you might be pulling it from, is
certainly < 1.17.4, tho, while 1.18.x is certainly not...
Assuming you mean 1.18.x...
You're running into two incompatible requirements, causing emerge to die
in ordered to let you resolve things manually, as it can't figure out an
automatic resolution.
1) The xorg drivers (xf86-*) must be built to match the xorg-server
version they will be running with. For minor upgrades, this is usually
just an ABI incompatibility and the the same driver versions can be
rebuilt to match the new server version, but the xorg-server jump to 1.18
is an API jump as well, and requires newer versions of the drivers that
can handle that new API.
So that's what's pulling in the newer drivers. You can't upgrade the
server to 1.18.* without upgrading the drivers as well.
2) One of the problems with proprietary drivers is that they often lag
freedomware development in support of new APIs by some time, forcing
distros (and on metadistros such as gentoo that offer multiple versions
to choose from, users) to choose between holding back in ordered to
accommodate those still using the lagging proprietary drivers, at the
expense of allowing those using all freedomware use of the bugfixes and
newer features available in current versions, or moving forward at full
freedomware API change speed for those with all freedomware, while
inconveniencing and occasionally entirely dropping support for those who
choose to use proprietaryware that doesn't support the newer APIs. And
unlike freedomware, the community can't do anything to bring the lagging
proprietaryware support for the new APIs because it's proprietary and
won't let them at it -- the proprietaryware developers must do it
themselves, and hold hostage anyone using that software to their own
whims and schedules as to when that might be, including never, because
the code isn't available to the community for people to either make those
changes themselves or to pay someone else to do it (perhaps with a
kickstarter project or the like) if they can't.
This is what's happening here. Your ATI driver doesn't yet support those
new APIs in xorg-server-1.18.x, and thus won't load if you try to force
the driver to run with the new server.
Now normally, when faced with such a case portage will recognize that the
two versions can't be installed together and that your ati drivers only
work with the older version, and will resolve the problem by dropping the
newer version of xorg-server. However, in this case it's not doing so,
possibly because something else (shouldn't be the xorg metapackage, but
might be a newer version of... something else) actually requires the
newer version, or possibly due to some other bug.
Regardless, your only choice to keep your ATI driver working, unless
there's an upgrade to it you can unmask, is to continue with the older
xorg-server-1.17.x. You may still be able to upgrade the other xorg
drivers (the xf86-* stuff), or may not, but even if you can keep them, if
they were built against xorg-server-1.18.x, you'll have to rebuild them
against the older 1.17.x once it's remerged, in ordered to get them to
work with it.
Of course your other choice is to try the latest radeon or amdgpu driver
and see if it fixes the LED issue with your monitor that you mentioned,
allowing you to drop the proprietaryware ATI driver. If you haven't
tried it in awhile, it may indeed be fixed.
Meanwhile, the easiest way to ensure that portage doesn't consider xorg-
server-1.18, if you decide you need to stay with the ATI driver and
there's no upgrade yet to it to work with 1.18, would be to package.mask
=xorg-server-1.18* (or similar). Just don't forget to unmask it once a
newer ATI driver that supports it is available. =:^)
Of course as mentioned, since you've already manually tried 1.18 and the
other driver upgrades, you'll have to either rebuild them as well, or
downgrade them too, once you downgrade back to xorg-server-1.17.x.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman