Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 301274 - x11-base/xorg-server-1.7.4 flawed and impossible to revert to earlier versions.
Summary: x11-base/xorg-server-1.7.4 flawed and impossible to revert to earlier versions.
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High major with 1 vote (vote)
Assignee: Gentoo X packagers
Depends on:
Reported: 2010-01-17 12:47 UTC by Robert Bradbury
Modified: 2010-01-19 00:25 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Bradbury 2010-01-17 12:47:25 UTC
I'm running xorg-server on an Intel 915 and a MSI/Radeon 3450 and have been trying for a year or more to get things running on multiple terminals reliably.

Currently xorg-server-1.7.4 will from time to time hang on the Intel requiring a system reboot.  (Report will be filed later.)  It will also SEGV, apparently due to a stack overflow, when trying to perform some Xrandr operations.  When I switch to the Radeon configuration, I can get the Xrandr wide screen parts to work but switching virtual terminals sometimes kills the X-server.  In short 1.7.4 is a dog and I want to downgrade back to 1.7.3 or 1.7.2 where I was having many fewer problems.

Reproducible: Always

Steps to Reproduce:
1. emerge -x11-base/xorg-server-1.7.4 (works but frequently crashes X/hangs video)
2. emerge =x11-base/xorg-server-1.7.3 (fails -- no ebuild)
3. emerge =x11-base/xorg-server-1.6.5 (fails -- header file mismatches)

Actual Results:  
The problem is I can't downgrade X at all!

Expected Results:  
One should always be able to revert back to an earlier release of a major version (e.g. 1.7.4 -> 1.7.3) and also revert back to the last major version (e.g. 1.6.5).

This bug is about the specific problem that one cannot revert to earlier Xorg versions because the ebuilds are MISSING!  I have the packages (1.7.1, 1.7.2, 1.7.3, etc.) in my distfiles directory but the ebuilds have been purged from the portage tree.  The only thing one can try to do is revert to 1.6.5 (which didn't work too badly) or 1.6.3 which are 3-4 months old respectively.

The problem is that when one wants to build 1.6.x, due to the X driver protocol changes, one has to downgrade the X extensions and X drivers (at least evdev, intel and radeon for me).  But even then 1.6.5 will not build, apparently due to formatting problems with header files in /usr/include/X11/extensions.

I happen to have a Xorg-1.6.5 around (since it did work reasonably well I saved it) but one can't start it due to the driver incompatibilities.

So when one has an upgrade which changes protocols, e.g. 1.5 -> 1.6 (presumably), and 1.6 -> 1.7 (definately), one needs to go back and modify the earlier version ebuilds, e.g. 1.5 and 1.6 so they contstrain package dependencies to be < the package versions associated with the newest upgrade (people unfamiliar with the package numbering schemes are not going to know which versions need to be paired together).

In the meantime, the earlier 1.7.X ebuilds should be put back into the portage tree so people can use them to backpaddle from 1.7.4.

This bug can be marked as fixed when one can:
emerge =x11-base/xorg-server-1.7.4 (and get the proper dependencies compiled)
Run X (as best it works)
emerge =x11-base/xorg-server-1.6.5 (and get the proper packages downgraded before attempting to build the server; then either get auto-pre/post compiling of any matching drivers versions)
Run X (as it did then)
emerge =x11-base/xorg-server-1.7.3 (or some of the 9xx variants) to get back a relatively good server).
Comment 1 Rémi Cardona gentoo-dev 2010-01-19 00:25:41 UTC
Won't happen. 1.7.4 is a bugfix release compared to the previous 1.7 releases. Probably something else is causing your issues.

As for keeping many point releases around, that's just not going to happen, the burden is too great and we _want_ users to upgrade. We do keep previous releases around, but only for a few weeks, after which they get pruned.

If you're running ~arch, you're expected to upgrade Often (tm) and report bugs when something goes wrong.