I upgraded to the latest stable intel GMA driver, and found that it was having trouble with xorg 1.5. I tried downgrading, but the ebuilds failed to compile, with some sort of xf86mm.h error, which turns out was caused by libdrm-2.4.5. Masking and downgrading to libdrm-2.3.0 fixed the issue. Reproducible: Always Steps to Reproduce: 1. Emerge libdrm-2.3.0 2. Try emerging older xf86-video-intel (2.1.1 and 2.2.1 failed when I tried) Actual Results: Ebuild fails during compilation step
remi: Dep on <x11-libs/libdrm-2.4 ?
(In reply to comment #1) > remi: Dep on <x11-libs/libdrm-2.4 ? > anything below 2.5.1-r1 seems to have compilation issues with the latest libdrm.
The ideal here would be ranged deps. But the real bug here is this : (In reply to comment #0) > I upgraded to the latest stable intel GMA driver, and found that it was having > trouble with xorg 1.5. If you have issues with the latest stable intel driver, you should file a bug for that instead. I have no plans to change old ebuilds anymore. I'm just keeping them around in case of emergency, nothing more. Please update your system to the latest X stack and file a bug if you have issues then. Thanks
(In reply to comment #3) > I have no plans to change old ebuilds anymore. I'm just > keeping them around in case of emergency, nothing more. I can't imagine an ebuild is ever a true emergency, but with the latest driver, I've got bug 266198 which prevents MythTV from even starting, then once I work around that by disabling acceleration, I've got bug 263414 which causes my system to completely lock up and require a reboot should I attempt to play any sort of video. If that's not enough, this new driver also corrupts the screen in a wonderfully animated manner should I try to use a virtual screen wider than 1664 pixels and then switch to another console and then back to X11, or if I use that virtual screen size and then simply put my computer to sleep and then wake it up again. Now, if I do either of those things, I have to restart X11 before it is usable again, which usually means restarting a lot of applications too. So to sum things up, "emerge --update world" replaced xf86-video-intel-2.1.1, which worked just fine, with xf86-video-intel-2.6.3-r1, which probably never should have been marked as stable, just like the six versions between those two were apparently never marked as stable, since I never had to deal with any of them. Is that the kind of "emergency" you're keeping the old ebuilds around for? I can certainly understand not wanting to maintain the ability to downgrade so that people never have to report bugs, but when a downgrade is necessary to restore a system to its previous functional state so that it can be used until those bugs are fixed, I'm not sure what is more "emergency" than that.
(In reply to comment #4) > Is that the kind of "emergency" you're keeping the old ebuilds around for? I > can certainly understand not wanting to maintain the ability to downgrade so > that people never have to report bugs, but when a downgrade is necessary to > restore a system to its previous functional state so that it can be used until > those bugs are fixed, I'm not sure what is more "emergency" than that. Simply because portage doesn't support ranged deps, if you want to downgrade xf86-video-intel back to, say, 2.4, it's going to be your job to downgrade libdrm and mesa as well. Portage doesn't cover that specific use case and given the current state of affairs, I doubt it ever will. There's little else I can do, except tell you that fixing bugs in the latest version is much more important and worthwhile than trying to have a clean downgrade path. For the record, I think you should find 2.4 along with libdrm 2.3.x and mesa 7.2 quite stable. Thanks
