My current desktop system has an nVidia Corporation NV37GL [Quadro PCI-E Series] (rev a2) graphics card which is running stably with x11-base/xorg-server-1.5.3 (this is the version reported by eix that I have installed, though it doesn't seem to exist in the portage tree) and x11-drivers/xf86-video-nv-2.1.12. I can't make any guarantees that these two versions will play well with each other on somebody elses system or that my last problem, random lock ups, will happen if x11-base/xorg-server-1.3.0.0-r6 is used instead. Reproducible: Always
Let's go with 1.5.3 instead, however I'd want to fix bug #251242 first. If we can't fix it, we can go with 1.5.3 without the EXA backports. Thanks
[X] Vote for stabilization It is a big step forward and almost kills off that ancient xorg.conf. I don't have any errors to report with nvidia-drivers and xf86-video-ati. Now which bugs remain for xorg-x11-7.4 to solve until it can be thought of being marked stable?
There's the HAL issue. Devices that identify only as touchpads and not mice will not be recognized by evdev because of the current state of 10-x11-input.fdi. That needs a HAL patch.
Vote here for stabilization. Just upgraded to xorg-server-1.5.3-r1 and xorg-x11-7.4 and things went very smooth. No touchpad issues for me. I needed to use the xf86-video-intel-1.5.* drivers. Older versions of the intel drivers wouldn't compile for me. The current ebuild has version >=2.4.2-r1, which should be updated to >=1.5.1-r1.
I have a HAL problem as well where my ALPS touchpad is only being recognized as a mouse. "synclient -m" only provides the initial line of output for me - guessing it's something with the driver. Works fine with the current stable version of xorg-server
(In reply to comment #5) > I have a HAL problem as well where my ALPS touchpad is only being recognized as > a mouse. "synclient -m" only provides the initial line of output for me - > guessing it's something with the driver. Works fine with the current stable > version of xorg-server Please don't hijack this bug but please do open another one. Thanks
(In reply to comment #6) > > Please don't hijack this bug but please do open another one. > > Thanks > My apologies - was more of a reinforcement for comment #3 which mentioned HAL issues. I had no intentions of hijacking.
FYI, * Recent kernels (>=2.6.26?) require new ati-drivers (else the binary driver glue code does not compile) * New enough ati-drivers require xorg-server-1.5 So it would really be nice if xorg-server-1.5 at some point was considered stable. Having single packages from unstable is one thing, switching something as big and central as X is something else entirely...
indeed, plz stabilize!
Created attachment 183018 [details] Xorg Xserver 1.5.3 Stabilization List v1 Here's the list, it should be complete. I'll try to find "stable" testers to see what breaks. Thanks
Created attachment 183021 [details] List of ebuild versions (in my opinion) ok on amd64 I'm running xorg-server-1.5.3 on an otherwise stable amd64 system, with the minimum set of testing packages that I could find. Detailed package versions (w/r to x11.stable.list) see attachment. No problems so far. (Apart from the usual hassling getting fglrx and compiz to work, but it's fine now.)
(In reply to comment #10) > Created an attachment (id=183018) [edit] > Xorg Xserver 1.5.3 Stabilization List v1 > > Here's the list, it should be complete. I'll try to find "stable" testers to > see what breaks. > > Thanks > Are there specific package versions you would like us to test? I pulled my xorg-1.5.3 package list to unmask from the ebuild about a month ago, so I have most, if not all, of those packages installed. Things are running very well here using the intel drivers 1.5.x and synaptics touchpad. I haven't tried the 1.6 intel drivers yet. I have a few other unmasked packages in my packages.keywords, but nothing that should impact xorg.
The idea is to test the latest ~arch ebuilds, that's why I intentionally left out version numbers. This should should just be copied as-is into /etc/portage/package.keywords Glad to know things have been working fine for the both of you. Feel free to file bugs for any issues you might have. Thanks
Since I switched to 1.5.3-r2 using the testing radeon driver (x11-drivers/xf86-video-ati-6.10.0) (with an X1300/r500) I experience random lockups (amd64) which can only be resolved with the power button. http://bugs.gentoo.org/show_bug.cgi?id=259991 I don't yet use all packages from the stable list. Instead I simply checked which packages xorg 1.5.3 requires and keyworded those. I don't yet use mesa-7.3, since they say that 7.3 is a development release and will get fixes in 7.4 - for stable X we should stick with 7.2.
(In reply to comment #14) > I don't yet use all packages from the stable list. Instead I simply checked > which packages xorg 1.5.3 requires and keyworded those. Please try all the packages in the list instead. I'd much rather people tested the same set of packages rather than a bigger mess. > I don't yet use mesa-7.3, since they say that 7.3 is a development release and > will get fixes in 7.4 - for stable X we should stick with 7.2. Please do try mesa 7.3, don't let the odd-numbered release number fool you :) It should be quite stable. I'll try to push a 7.4 snapshot soon to gather some more feedback on this. And for all who are tempted to comment on this thread, please open new bugs instead as I'd like to keep the overall noise low so we can better focus on the stabilization itself. Thanks
Hi, x11-drivers/xf86-input-synaptics is probably missing in the list. -- Andrey
Created attachment 183169 [details] Xorg Xserver 1.5.3 Stabilization List v2 Nice catch, Andrey. Here's an updated list. Thanks
After putting the stable list v1 into package.keywords, I updated the following packets: x11-proto/dri2proto-1.99.3 media-libs/mesa-7.3 x11-libs/libSM-1.1.0 x11-libs/libXrandr-1.2.3 x11-libs/libXft-2.1.13 x11-libs/libXv-1.0.4 x11-proto/printproto-1.0.4 x11-apps/xev-1.0.3 x11-libs/libXScrnSaver-1.1.3 x11-libs/libXinerama-1.0.3 x11-apps/xkbcomp-1.0.5 x11-apps/xrandr-1.2.3 x11-wm/twm-1.0.4 x11-terms/xterm-241 x11-apps/mesa-progs-7.3 All updates did build. X still runs with the same quirks I had before building the packages (flickering and short periods of garbled output when logging into KDE4.2, xv video doesn't work, I actually have hardware accelleration :-) (ATI X1300)). I didn't yet experience a full crash with the new drivers. I don't have x11-drivers/xf86-input-synaptics installed, so this shoudl fit stable.list v2, too.
I tried to update. Compiling works. However X won't start after: #260325 X wont start: Couldn't bind memory for BO front buffer
Please stop commenting here, if you have any issues, please open *new* bugs. Thanks
appending lspci for completeness. # lspci 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782 Gigabit Ethernet (rev 03) 05:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 6c) 05:0a.0 Ethernet controller: 3Com Corporation 3cSOHO100-TX Hurricane (rev 30)
Hmm. Im so sorry. was wrong bug.
I was just wondering, why the x11.stable.list does not contain explicit version numbers for packages (e.g. "=x11-libs/libdrm-2.4.4") but instead make all version of a package stabe (x11-libs/libdrm). The un-versioned x11.stable.list may result in wrong merged package versions for all those users, who have overlays like the x11 overlay installed.
(In reply to comment #23) > I was just wondering, why the x11.stable.list does not contain explicit version > numbers for packages (e.g. "=x11-libs/libdrm-2.4.4") but instead make all > version of a package stabe (x11-libs/libdrm). Because I want users to try the latest ~arch but unmasked version of what we have in portage. If we fix bugs in -rX ebuilds or if upstream comes up with bug fix releases (like libdrm-2.4.5 for instance), I want users to try those versions too. > The un-versioned x11.stable.list may result in wrong merged package versions > for all those users, who have overlays like the x11 overlay installed. If you're a stable user *and* an x11 overlay user, you probably know what you're doing. ;) This list is meant for stable users and the final list given to arch teams will of course have version numbers. Thanks
Hi! I emerged xorg-server-1.5.3 after appending the above list to /etc/portage/package.keywords, and so far haven't experienced any problems. I can watch films with mplayer, play 3d games, watch tv with tvtime. My video card is an onboard nvidia "00:12.0 VGA compatible controller: nVidia Corporation GeForce 7025 (rev a2)" and I am using the latest ~amd64 nvidia-drivers. The only (little) annoyance is that the xorg server seems to disregard the following xorg.conf section: Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "bg" EndSection and my keyboard layout is always "us" at X start... Will google a bit to see how I can fix that.
(In reply to comment #24) > (In reply to comment #23) > > I was just wondering, why the x11.stable.list does not contain explicit version > > numbers for packages (e.g. "=x11-libs/libdrm-2.4.4") but instead make all > > version of a package stabe (x11-libs/libdrm). > > Because I want users to try the latest ~arch but unmasked version of what we > have in portage. If we fix bugs in -rX ebuilds or if upstream comes up with bug > fix releases (like libdrm-2.4.5 for instance), I want users to try those > versions too. > > > The un-versioned x11.stable.list may result in wrong merged package versions > > for all those users, who have overlays like the x11 overlay installed. > > If you're a stable user *and* an x11 overlay user, you probably know what > you're doing. ;) > > This list is meant for stable users and the final list given to arch teams will > of course have version numbers. > > Thanks > Ok. I was just curious. It is absolutely your decision which I respect. Maybe to get a good compromise one could use version ranges (<=x11-libs/libdrm-2.5). So newer version like -rX and micro releases would be possible, but major updated not. As a possibly scenario the not so experienced stable user, who wants to help with stabilizing xorg server, forgets to remove the keywords file and will later merge keyworded packages which are not be part of the stabilization set. Nevertheless feel free to ignore this comment. Sorry, for hijacking this ticket. Tobias
Applying x11.stable.list got me upgrading 16 packages I hadn't thought of before. After successful build my system remains 100% stable as it was before. I'm on amd64 but with quite a bunch of ~arch keywords though which might degrade the worth of my statement concerning stabilization. In short: gcc-4.3.2-r3, glibc-2.9-20081201, nvidia-drivers-180.35, hal-0.5.11-r8, udev-135-r4 Mouse and keyboard input is completely managed by hal and xf86-input-evdev-2.1.2 and just works great.
(In reply to comment #25) > and my keyboard layout is always "us" at X start... Will google a bit to see > how I can fix that. > If you built xorg-server with +hal, you might want to remove that input section from your xorg.conf and take a look into '/etc/hal/fdi/policy/10-x11-input.fdi'. That's the new place to configure your mouse and keyboard.
(In reply to comment #27) > Mouse and keyboard input is completely managed by hal and > xf86-input-evdev-2.1.2 and just works great. > As seems that evdev is the preferred (or, at least, the simpler) way for hal+linux users, maybe xorg-server ebuild could suggest adding evdev to INPUT_DEVICES when hal USE flag is enabled...
yes, I changed the layout to "de" in /etc/hal/fdi/policy/10-x11-input.fdi (which is a copy of /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi), and also changed it in the original. Still no success. I am just talking with a couple of guys on #gentoo-desktop, let's see what they can say. (In reply to comment #28) > (In reply to comment #25) > > and my keyboard layout is always "us" at X start... Will google a bit to see > > how I can fix that. > > > > If you built xorg-server with +hal, you might want to remove that input section > from your xorg.conf and take a look into > '/etc/hal/fdi/policy/10-x11-input.fdi'. That's the new place to configure your > mouse and keyboard. >
Stable list is missing x11-drivers/xf86-video-fbdev: !!! All ebuilds that could satisfy ">=x11-drivers/xf86-video-fbdev-0.4.0" have been masked. !!! One of the following masked packages is required to complete your request: - x11-drivers/xf86-video-fbdev-0.4.0 (masked by: ~amd64 keyword) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "x11-base/xorg-server-1.5.3-r2" [ebuild]) (dependency required by "x11-base/xorg-x11-7.2" [installed]) (dependency required by "world" [argument]) Also is missing newer xorg-x11 meta ebuild, but maybe this is intentional :-/
Also on almost stable amd64 (gcc-4.3, gentoo-sources-2.6.28). Everything compiled fine. I've experienced some hassle with evdev/hal, but after removing all input sections in Xorg.conf everything works just fine. I'm using the radeonhd driver. My working /etc/hal/fdi/policy/10-x11-input.fdi using german (de) keyboard layout and logiultrax-model: <?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.mouse"> <merge key="input.x11_driver" type="string">evdev</merge> </match> <match key="info.capabilities" contains="input.keys"> <merge key="input.x11_driver" type="string">evdev</merge> <merge key="input.xkb.model" type="string">logiultrax</merge> <merge key="input.xkb.layout" type="string">de</merge> </match> </device> </deviceinfo>
Created attachment 183253 [details] Xorg Xserver 1.5.3 Stabilization List v3 (In reply to comment #31) > Stable list is missing x11-drivers/xf86-video-fbdev: Done, here's an updated list. > Also is missing newer xorg-x11 meta ebuild, but maybe this is intentional :-/ Indeed, the meta will be updated later. It's just a convenience when installing X for the first time anyway. Thanks
x11-drivers/xf86-video-{v4l,fbdev} are missing as well on the list I guess. BR, Dustin
(In reply to comment #28) > (In reply to comment #25) > > and my keyboard layout is always "us" at X start... Will google a bit to see > > how I can fix that. > > > > If you built xorg-server with +hal, you might want to remove that input section > from your xorg.conf and take a look into > '/etc/hal/fdi/policy/10-x11-input.fdi'. That's the new place to configure your > mouse and keyboard. > Hopefully, when bug 225091 is finally resolved, this transition will be done automatically, for now, you can follow what xf86-input-evdev-2.1.3.ebuild suggests: elog "If your XKB (keyboard settings) stopped working," elog "you may uninstall this driver or move your XKB configuration." elog "Download an example from http://dev.gentoo.org/~compnerd/temp/hal-config-examples/" elog "(these will be installed with sys-apps/hal soon)," elog "and drop it into /etc/hal/fdi/policy/"
Just after updating to new X version, I have had to reconfigure my special keys using gnome-keybinding-properties (I am under gnome) because shortcuts have changed from "0xed" and similar to "XF86Audio*", Is it the normal behavior? I have also lost nvidia 3D acceleration, but I am currently investigating it :-(
(In reply to comment #36) > Just after updating to new X version, I have had to reconfigure my special keys > using gnome-keybinding-properties (I am under gnome) because shortcuts have > changed from "0xed" and similar to "XF86Audio*", Is it the normal behavior? Yes.
(In reply to comment #34) > x11-drivers/xf86-video-{v4l,fbdev} are missing as well on the list I guess. fbdev is in the new list I just posted, and v4l is unmaintained. It's not part of the list. (In reply to comment #35) > Hopefully, when bug 225091 is finally resolved, this transition will be done > automatically, for now, you can follow what xf86-input-evdev-2.1.3.ebuild > suggests: This bug is resolved: we won't migrate to HAL automatically. Users will have to take care of it themselves if they want input devices from HAL. > elog "If your XKB (keyboard settings) stopped working," > elog "you may uninstall this driver or move your XKB > configuration." > elog "Download an example from > http://dev.gentoo.org/~compnerd/temp/hal-config-examples/" > elog "(these will be installed with sys-apps/hal soon)," > elog "and drop it into /etc/hal/fdi/policy/" I think those files are shipped with HAL now, we should probably remove the elog message. (In reply to comment #36) > Just after updating to new X version, I have had to reconfigure my special keys > using gnome-keybinding-properties (I am under gnome) because shortcuts have > changed from "0xed" and similar to "XF86Audio*", Is it the normal behavior? You might want to reset Gnome keyboard properties before doing any fancy stuff. It could save you a lot of headaches down the road. > I have also lost nvidia 3D acceleration, but I am currently investigating it NVidia drivers are not the X team's responsibility. All I know is that there are updated drivers (even for older unsupported cards) that work fine with Xorg 1.5.3. Please open new bugs if you have issues. *NOTE* : please stop commenting here about bugs or configuration issues. I want to keep this bug *on* *topic* which is the stabilization list. *Nothing* *else*. Thanks
(In reply to comment #36) > I have also lost nvidia 3D acceleration, but I am currently investigating it > :-( > Solved after rerunning "eselect opengl set nvidia", as I also updated nvidia-driver while updating the other xorg stuff, I don't know who is the culprit as some other times in the past I have also suffered the lost of nvidia glx when updating having to manually re-enable it(In reply to comment #37) > (In reply to comment #36) > Yes. > Thanks :-) (In reply to comment #38) > This bug is resolved: we won't migrate to HAL automatically. Users will have to > take care of it themselves if they want input devices from HAL. Sad to hear it, but ok :-| > I think those files are shipped with HAL now, we should probably remove the > elog message. > No, they are not being shipped (at least with hal-0.5.11-r8) > You might want to reset Gnome keyboard properties before doing any fancy stuff. > It could save you a lot of headaches down the road. Is there any easy way of resetting all of them, for now, I simply manually reverted each key combination but, if there is an easier way, would be nice to know about it :-) > *NOTE* : please stop commenting here about bugs or configuration issues. I want > to keep this bug *on* *topic* which is the stabilization list. *Nothing* > *else*. > > Thanks > OK, sorry for the invonvenience
Everything's running fine here on amd64 with Stabilization List v3...
Please add 259991 to the dependencies, since I still get the freezes - and I think they are from the new radeon driver (xf86-video-ati). I began getting these freezes after upgrading to 6.10.0 (the downside of getting good graphics performance - that's why I don't go back :) ).
Everything's fine for me on amd64 & nvidia with Stabilization List v3
(In reply to comment #39) > (In reply to comment #36) > > I think those files are shipped with HAL now, we should probably remove the > > elog message. > > > > No, they are not being shipped (at least with hal-0.5.11-r8) comet $ ls /usr/share/doc/hal-0.5.11-r8/ AUTHORS.bz2 use-kbd-driver.fdi.bz2 ChangeLog.bz2 use-mouse-driver.fdi.bz2 NEWS.bz2 use-multiple-layouts.fdi.bz2 README.bz2 use-multiple-layouts-with-kbd.fdi.bz2 use-estonian-layout.fdi.bz2 You need USE=X.
I didn't know there wer provided under /usr/share/doc, thanks :-)
(In reply to comment #33) > Created an attachment (id=183253) [edit] > Xorg Xserver 1.5.3 Stabilization List v3 > please add x11-drivers/linuxwacom. without absolute positioning doesn't work. with the new version everything works fine, despite the warning that you need at least gcc 4.2.
Seems that a newer tslib is required: !!! All ebuilds that could satisfy "x11-libs/tslib" have been masked. !!! One of the following masked packages is required to complete your request: - x11-libs/tslib-1.0-r1 (masked by: ~amd64 keyword) - x11-libs/tslib-1.0 (masked by: ~amd64 keyword) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "x11-base/xorg-server-1.5.3-r2" [ebuild])
And also: ">=x11-drivers/xf86-input-mutouch-1.2.1" , ">=x11-drivers/xf86-input-hyperpen-1.2.0", ">=x11-drivers/xf86-input-fpit-1.2.0", ">=x11-drivers/xf86-input-summa-1.2.0", ">=x11-drivers/xf86-input-elographics-1.2.2", ">=x11-drivers/xf86-input-citron-2.2.1", ">=x11-drivers/xf86-input-microtouch-1.2.0", ">=x11-drivers/xf86-input-jamstudio-1.2.0", ">=x11-drivers/xf86-input-dynapro-1.1.2", ">=x11-drivers/xf86-input-magellan-1.2.0", ">=x11-drivers/xf86-input-calcomp-1.1.2", ">=x11-drivers/xf86-input-elo2300-1.1.2" , ">=x11-drivers/xf86-input-penmount-1.3.0", ">=x11-drivers/xf86-input-dmc-1.1.2", ">=x11-drivers/xf86-input-digitaledge-1.1.1", ">=x11-drivers/xf86-input-spaceorb-1.1.1", ">=x11-drivers/xf86-input-palmax-1.2.0", "x11-drivers/xf86-input-tslib", ">=x11-drivers/xf86-input-tek4957-1.2.0" ">=x11-drivers/xf86-video-voodoo-1.2.0" , ">=x11-drivers/xf86-video-sis-0.10.0", ">=x11-drivers/xf86-video-s3virge-1.10.1" , ">=x11-drivers/xf86-video-rendition-4.2.0", ">=x11-drivers/xf86-video-cirrus-1.2.1", ">=x11-drivers/ati-drivers-8.552-r2", ">=x11-drivers/xf86-video-apm-1.2.0", ">=x11-drivers/xf86-video-v4l-0.2.0" (if this is unmaintained maybe USE flag should be dropped), ">=x11-drivers/xf86-video-sisusb-0.9.0", ">=x11-drivers/xf86-video-siliconmotion-1.6.0" , ">=x11-drivers/xf86-video-s3-0.6.0", ">=x11-drivers/xf86-video-ark-0.7.0"
Those are all more or less unmaintained, that's why they didn't make it on the list. We're probably going to drop the USE flags from xorg-server at some point. The stabilization list is rather conservative when it comes to drivers. A lot of them are known to be broken (not to mention unused) and so I'd like to use the stabilization as a good opportunity to do some clean-ups. As a comparison, here are the X11 drivers that will be shipped in the next Ubuntu : http://packages.ubuntu.com/jaunty/x11/#xserver-xorg-input-acecad Fedora on the other hand seems to shipping a lot more drivers. I'll gladly add more if I get ever get paid to maintain them ;) Thanks
From my point of view, bug 236983 should block this one. I am also affected by it and attach fdi file provided in bug report fixes the issues Thanks
I updated to v3 of the stabilization list this weekend, and after a few days of use I haven't had any problems. Currently using: x11-base/xorg-server-1.5.3-r2 x11-drivers/xf86-video-intel-2.6.1 x11-drivers/xf86-input-synaptics-1.0.0 Just a note... I don't use tap click for synaptics, but I do have the Vertical Edge Scrollbar working fine.
Ah, yes, forgot to tell here: installed it a few days ago on stable amd64, compilation went fine, have been running it since then, haven't seen any issues (except some minor). The only thing that really annoys me is bug #260627.
Works fine on my amd64 with ati-drivers-8.582. I needed to add x11-drivers/xf86-video-v4l to x11.stable.list, though. Additionally, i needed to emerge evdev (as documented)
Using x11.stable.list we get x11-libs/libXrender-0.9.4 and x11-proto/renderproto-0.9.3. This leads to compilation errors for xulrunner (at least). See bug #259471.
(In reply to comment #53) > Using x11.stable.list we get x11-libs/libXrender-0.9.4 and > x11-proto/renderproto-0.9.3. This leads to compilation errors for xulrunner (at > least). See bug #259471. Damned, I forgot to take care of this one. Thanks for the reminder, I'll look into it ASAP.
Remi, Could you look into getting some set of patches to build against current libXfont in here? As it stands, I'm blocked from adding libXfont 1.4 to the tree.
(In reply to comment #55) > Could you look into getting some set of patches to build against current > libXfont in here? As it stands, I'm blocked from adding libXfont 1.4 to the > tree. I've just pushed xorg-server 1.5.3-r3 to allow this. It seems to Work For Me (tm) but it could definitely use a little more testing. Thanks
*** Bug 261552 has been marked as a duplicate of this bug. ***
Any plans to make use of slots and EAPI-2? The stabilization list would make a lot of sense if we could just stick a :7.4 at every package. Would be easier to recommend to all those poor KDE4.2 beginners too which already depend on xorg-server-1.5.3.
(In reply to comment #58) > Any plans to make use of slots and EAPI-2? The stabilization list would make a > lot of sense if we could just stick a :7.4 at every package. Would be easier to > recommend to all those poor KDE4.2 beginners too which already depend on > xorg-server-1.5.3. 1) maintenance nightmare for us 2) none of the packages are parallel-installable 3) most packages are supposed to work with multiple versions of the server So, for all those reasons (and probably a few more I can't think of), there will be no slotting of Xorg packages. Thanks
Agreed then, thanks for the quick reply. ;)
Here bug #260287 interrupted the upgrade, but as this is not a bug in the X server itself, but rather the pixman ebuild, it doesn't block stabilization. Everything else went fine (X86, GMA X4500HD, evdev + HAL).
Any thoughts about stabilizing this soon? 1.6.0 is already out there, 1.4* not stabilized... doesn't last any longer and debian stable is more recent than gentoo...
(In reply to comment #62) > Any thoughts about stabilizing this soon? > 1.6.0 is already out there, 1.4* not stabilized... doesn't last any longer and > debian stable is more recent than gentoo... Wow, thanks for the pep talk, I really appreciate it.
(In reply to comment #63) > (In reply to comment #62) > > Any thoughts about stabilizing this soon? > > 1.6.0 is already out there, 1.4* not stabilized... doesn't last any longer and > > debian stable is more recent than gentoo... > > Wow, thanks for the pep talk, I really appreciate it. > Translation: Don't comment unless you have something constructive to add to the conversation. Anything else is pure StopEnergy(TM). Please be patient, we're working on it.
I switched to xorg-server-1.5.3 using the v3 of the list. It has been about 8 days since that switch and everything seems stable (as long as composite is not used). This is on a x86 system on T61 with nvidia graphics.
Switched to v3 also with almost no problems. The synaptics driver wasn't rebuilt, so it didn't work after upgrading X. Perhaps a solution is to add x11-drivers/xf86-input-synaptics-1.0.0-r1 and make it depend on >=x11-base/xorg-server-1.5.3 ? That way it will be rebuilt after building X 1.5.3. Apart from that problem, everything including composite works perfectly.
(In reply to comment #66) > Switched to v3 also with almost no problems. The synaptics driver wasn't > rebuilt, so it didn't work after upgrading X. Perhaps a solution is to add > x11-drivers/xf86-input-synaptics-1.0.0-r1 and make it depend on > >=x11-base/xorg-server-1.5.3 ? That way it will be rebuilt after building X > 1.5.3. > Apart from that problem, everything including composite works perfectly. > At the end of emerge xorg-server it tells you to rebuild all your x11-drivers/ packages, people should really start to read that. ;)
Created attachment 185916 [details] Xorg Xserver 1.5.3 Stabilization List v4 This list only add tslib, xf86-input-tslib and linuxwacom. That's the final list for arch teams, which I'll be CCing in a minute.
Hi arches, I'm CCing you guys to give you a heads up on the Xorg stabilization. The "x11.stable.list" attachment contains the list of packages we'd like to see stabilized. Right now, there are no version numbers because I wanted tester to try the latest ~arch version. I don't really know how you guys will handle this, but if you could somehow start build testing all of this and give me some feedback, I'd appreciate it. I'll give you all the final stabilization list with target arches for each package (with a specified version number) within a day or two. Barring any major road block, I'd like to get this stabilization done soon so we can start on putting Xorg 1.6 in portage. Thanks in advance for all your work :)
Hi, I have switched to xorg-server-1.5.3 using the x11.stable.list-v3 about 10 days ago. I'm running my two machines (x86 and amd64, both ATI graphics) with no problems. Looking forward for stabilization.
I have several stable installations running with the v3 list for > 1 week with no problems. 2x x86, radeonhd (X1900XT, X1650) 1x x86, radeon (X800) 2x x86, intel (X3100, X4500) 1x amd64, nv (FX5200)
confirm amd64, nv works great
amd64, x11-drivers/xf86-video-ati-0.12.1, still random freezes. -> http://bugs.gentoo.org/show_bug.cgi?id=259991
It was mentioned above that a few of the drivers that are old / unmaintained won't be marked for stable on the xorg-server update, including the sis drivers. I have two machines that use the sis chipset, so I decided to build version 0.10.1 against xorg-server-1.5 anyway, and so far they seem to be performing well. The sis drivers are old but they might be a good candidate to add to the stable list. My intel machine has still been running rock solid using stable-list v3. I'll try an update to v4 soon.
Remi, It'd be nice if your list contained version numbers unless in every single situation you're looking for the latest version in the tree to go stable. That being said, I'm running the v3 list on my stable amd64 machine and will gladly mark the subset that I am currently using stable when I return from my business trip.
(In reply to comment #74) > The sis drivers are old but they might be a good candidate to add to the stable > list. Noted, maybe we'll do those later on. They're not our primary focus at the moment. > My intel machine has still been running rock solid using stable-list v3. I'll > try an update to v4 soon. Not much has changed. See what I wrote in comment #68. (In reply to comment #75) > It'd be nice if your list contained version numbers unless in every single > situation you're looking for the latest version in the tree to go stable. At the moment, that's the goal. I want the latest versions to be _tested_. However, the real list for arch teams will have version numbers. I'm pretty sure the latest version of mesa (7.4) won't be on it and will be stabilized later. Thanks
Alpha can't stabilize before there is a kernel fix for the pci resources. Such a patch exists, but the kernel maintainer for alpha hasn't submitted it. Yes, this is annoying, but we (the alpha team) can't do much more than what we've done already.
(In reply to comment #73) > amd64, x11-drivers/xf86-video-ati-0.12.1, still random freezes. > > -> http://bugs.gentoo.org/show_bug.cgi?id=259991 > Hi, this bug is no showstopper, i tracked it down to EXAVsync enabled. And even upstream dont recomend using it. So simply put: unless you mess with your config you wont get freezes.
May I ask about the meta-package 'x11-base/xorg-x11'? Shouldn't that be included in the stable list too? I'm doing a fresh install right now using stabilization list v4 and noticed that the latest stable version of xorg-x11 is still 7.2.
The meta-package is just that: a meta package. No need to change it now. We need to clean it up anyway, since upstream dropped quite a few deps from their official Xorg list. It'll come later on.
Sorry if this is the wrong place. On my macbook I've my "\" and "<" keys swapped. This issue could be resolved in older xorg-server using the "apple:badmap" XkbOption, but now (xorg-server-1.5.3-r5) adding "<merge key="input.x11_options.XkbOptions" type="strlist">apple:badmap</merge>" to my 10-x11-input.fdi file has no effects. I'm pretty sure that in an older 1.5.3-r* the option worked fine, but I don't remember the precise version. /var/log/Xorg.0.log report: (**) Option "xkb_options" "apple:badmap" and nothing else.
After upgrading to 1.5.3, I've had some issues with font rendering. Some websites (in Firefox) and some emails (in Thunderbird) show these kind of bugs: http://anymore.nl/tmp/xorg_153_fonts.png I've tried recompiling everying including GTK+ and Firefox, but it didn't help. Anyone recognizes this problem? Possibly something I did wrong or forgot to do?
(In reply to comment #81) > Sorry if this is the wrong place. Indeed, this is not the right place, file a new bug. (In reply to comment #82) > Anyone recognizes this problem? Possibly something I did wrong or forgot to do? So far, the one thing you did wrong was to high-jack this thread. Please both of you open new bugs so we can fix your issues without bothering the 50+ people who are CCed on this bug. Thanks
Hi, I am using X.org 1.5r* since at least two weaks on a Dell Latitude D830 with xf86-video-intel-2.6.*. It works pretty well, but I found two oddities: - StatusBar in Firefox is filled completely black from time to time, but only for a short moment - Diff viewing in Eclipse is sometimes unreadable due to strange artifacts which disappear when clicking inside the diff view Possibly some graphic driver incompatibility problems?! Another point is the new concept of using HAL which I appreciate but still was unable to find a straight forward tutorial, e.g. "how to convert from old to new X.org using HAL". Does anybody know such a tutorial? I am currently missing my touchpad's synaptics functionality :-(
Current x11.stable.list unmasks media-libs/mesa-7.4_rc1. That's a minor problem, I think. (In reply to comment #84) See Gentoo Wiki for info, there's pretty full tutorial on Synaptics, with and without HAL. It's not a place for such complaints, I belive. Sorry. > Another point is the new concept of using HAL which I appreciate but still was > unable to find a straight forward tutorial, e.g. "how to convert from old to > new X.org using HAL". > Does anybody know such a tutorial? I am currently missing my touchpad's > synaptics functionality :-(
(In reply to comment #85) > Current x11.stable.list unmasks media-libs/mesa-7.4_rc1. That's a minor > problem, I think. It's intended. 7.4 is a bugfix branch on top of 7.3. It has lots of patches, that's why I unmasked it. If I don't get many complaints, it'll go stable. If it causes trouble, 7.3-r1 will go stable instead. Thanks
xf86-video-intel-2.6* breaks things for users of KDE 4 and G965 chipsets. The problem is fixed upstream in master and 2.7 branch: http://bugs.freedesktop.org/show_bug.cgi?id=20527
(In reply to comment #87) > xf86-video-intel-2.6* breaks things for users of KDE 4 and G965 chipsets. The > problem is fixed upstream in master and 2.7 branch: > http://bugs.freedesktop.org/show_bug.cgi?id=20527 Please open a bug here and make it block this one so I don't forget to backport the patch into 2.6.3 Thanks :)
this is working here as well on a thinkpad T60 with a radeon mobility x1400 and radeonhd driver (the 1.2.4 ebuild) had a bit of an issue with the new hal/keyboard layout stuff, the laptop has an uk keyboard, and whereas before I had "uk" as XkbLayout in xorg.conf, now I had to put "gb" in 10-x11-input.fdi there's a difference in behaviour with regards to the chosen resolutions in dual monitor setup, and I would have thought that's a driver issue, except that I'm using the same driver/version as before; the new setup sucks less, but it's still not good, not sure whom I am supposed to open a bug to (radeonhd or x11 team).
> It's intended. 7.4 is a bugfix branch on top of 7.3. It has lots of patches, > that's why I unmasked it. If I don't get many complaints, it'll go stable. If > it causes trouble, 7.3-r1 will go stable instead. Hi Remi, Mesa 7.4 was released on 27 of March. Did you have a chance to try it? As I see it's a bugfix release BR, Mike.
(In reply to comment #90) > Hi Remi, > > Mesa 7.4 was released on 27 of March. Did you have a chance to try it? As I see > it's a bugfix release > > BR, Mike. > To me, mesa-7.4_rc2 was a huge stability improvement - I didn't have any X restart or black screen at start since using it. kwin4 compositing with UXA on my Intel GM45 is stable now and running for hours. With mesa-7.4_rc1 every startup resembled a roulette, and X would reset by no particular logic. I'm a bit ahead of the game though with 2.6.29, xorg-server-1.6.0 and KMS enabled, but I believe the problems with xf86-video-intel-2.6.x were UXA-related.
You should open a different bug for your problem as, for example, mesa-7.4_rc behaves properly for me
(In reply to comment #92) > You should open a different bug for your problem as, for example, mesa-7.4_rc > behaves properly for me > I don't think there's much point in opening a bug for a past rc release issue which has already been solved in the final version. But I wanted to share my mesa-7.4 experience and I think it's a very good idea to include it for stabilization. As a bugfix release it should solve more problems than introduce new ones.
Created attachment 186696 [details] Xorg Xserver 1.5.3 Stabilization List v5
Created attachment 186698 [details] Xorg Xserver 1.5.3 Stabilization List v5 Hi arches, this is the final list. _Once_the_news_item_is_published_, please stabilize the latest available ebuild for each package in it except for mesa and xf86-input-evdev where specific versions are noted. Thanks
*** Bug 258419 has been marked as a duplicate of this bug. ***
kde-misc/ksynaptics should be masked for removal (bug 237521). Thanks!
Hi all During the upgrade I've observed one issue. I use generic mouse driver. Just after upgrade it doesn't work (driver plugin cannot be loaded by xorg-server). The problem can be solved by reemerging of xf86-input-mouse (emerge -1 xf86-input-mouse). I think it can be related with the packages compilation order. BR, Mike.
(In reply to comment #98) > The problem can be solved by reemerging of xf86-input-mouse (emerge -1 > xf86-input-mouse). I think it can be related with the packages compilation > order. It's already in ewarn, people should really read this. (;
Created attachment 186760 [details] Xorg Xserver 1.5.3 Stabilization List v6 Arches, please stabilize this final list. (Yes, for real) I've added a specific version on x11-proto/renderproto. The upgrade guide url is here : http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml Do your magic. Thanks :)
Created attachment 186984 [details] Xorg Xserver 1.5.3 Stabilization List v6 with version numbers At the request of rangerpb, here's the v6 list, sorted alphabetically and with proper version numbers. Arch Teams, please proceed :) Thanks
(In reply to comment #101) > Created an attachment (id=186984) [edit] > Xorg Xserver 1.5.3 Stabilization List v6 with version numbers > > At the request of rangerpb, here's the v6 list, sorted alphabetically and with > proper version numbers. > > Arch Teams, please proceed :) > > Thanks > Hm, bake a fresh stable chroot. Put that list in package.keywords, emerge -av xorg-server, find missing deps: =x11-drivers/xf86-video-voodoo-1.2.0 =x11-drivers/xf86-video-mach64-6.8.0 =x11-drivers/xf86-video-sis-0.10.0 You want those versions or newer on amd64?
(In reply to comment #102) > You want those versions or newer on amd64? Go with the latest version that builds... Thanks
ppc done; I marked the following stable (remember we use a subset of available input and video drivers) media-libs/mesa-7.3-r1 x11-apps/mesa-progs-7.3 x11-apps/rgb-1.0.3 x11-apps/xauth-1.0.3 x11-apps/xev-1.0.3 x11-apps/xinit-1.0.8-r4 x11-apps/xkbcomp-1.0.5 x11-apps/xrandr-1.2.3 x11-apps/xvinfo-1.0.2 x11-base/xorg-server-1.5.3-r5 x11-drivers/linuxwacom-0.8.2 x11-drivers/xf86-input-acecad-1.3.0 x11-drivers/xf86-input-aiptek-1.2.0 x11-drivers/xf86-input-evdev-2.1.3 x11-drivers/xf86-input-joystick-1.4.0 x11-drivers/xf86-input-keyboard-1.3.2 x11-drivers/xf86-input-mouse-1.4.0 x11-drivers/xf86-input-synaptics-1.0.0 x11-drivers/xf86-input-tslib-0.0.5-r1 x11-drivers/xf86-input-void-1.2.0 x11-drivers/xf86-video-ati-6.12.1-r1 x11-drivers/xf86-video-chips-1.2.1 x11-drivers/xf86-video-dummy-0.3.1 x11-drivers/xf86-video-fbdev-0.4.0 x11-drivers/xf86-video-glint-1.2.2 x11-drivers/xf86-video-mga-1.4.9 x11-drivers/xf86-video-nv-2.1.12 x11-drivers/xf86-video-r128-6.8.0 x11-drivers/xf86-video-radeonhd-1.2.3 x11-drivers/xf86-video-savage-2.2.1 x11-drivers/xf86-video-tdfx-1.4.1 x11-drivers/xf86-video-trident-1.3.1 x11-drivers/xf86-video-xgi-1.5.0 x11-libs/libdrm-2.4.5 x11-libs/libpciaccess-0.10.5 x11-libs/libSM-1.1.0 x11-libs/libX11-1.1.5 x11-libs/libXau-1.0.4 x11-libs/libXaw-1.0.5 x11-libs/libXext-1.0.4 x11-libs/libXfont-1.3.4 x11-libs/libXft-2.1.13 x11-libs/libXi-1.2.1 x11-libs/libXinerama-1.0.3 x11-libs/libxkbfile-1.0.5 x11-libs/libXmu-1.0.4 x11-libs/libXrandr-1.2.3 x11-libs/libXrender-0.9.4 x11-libs/libXScrnSaver-1.1.3 x11-libs/libXv-1.0.4 x11-libs/libXxf86dga-1.0.2 x11-libs/libXxf86vm-1.0.2 x11-libs/pixman-0.14.0-r1 x11-libs/tslib-1.0-r1 x11-libs/xtrans-1.2.3 x11-misc/rendercheck-1.3 x11-misc/util-macros-1.2.1 x11-misc/xcompmgr-1.1.4 x11-misc/xinput-1.4.0 x11-misc/xkeyboard-config-1.5 x11-misc/xtermcontrol-2.9 x11-proto/dri2proto-1.99.3 x11-proto/glproto-1.4.9 x11-proto/inputproto-1.5.0 x11-proto/printproto-1.0.4 x11-proto/randrproto-1.2.2 x11-proto/renderproto-0.9.3 x11-proto/xextproto-7.0.4 x11-proto/xf86dgaproto-2.0.3 x11-proto/xf86driproto-2.0.4 x11-proto/xproto-7.0.14 x11-terms/xterm-242 x11-wm/twm-1.0.4 x11-proto/xcalibrateproto-0.1_pre20081210 x11-libs/libXCalibrate-0.1_pre20081207
ppc64 done: did the following: media-libs/mesa-7.3-r1 x11-apps/mesa-progs-7.3 x11-apps/rgb-1.0.3 x11-apps/xauth-1.0.3 x11-apps/xev-1.0.3 x11-apps/xinit-1.0.8-r4 x11-apps/xkbcomp-1.0.5 x11-apps/xrandr-1.2.3 x11-base/xorg-server-1.5.3-r5 x11-drivers/linuxwacom-0.8.2 x11-drivers/xf86-input-acecad-1.3.0 x11-drivers/xf86-input-aiptek-1.2.0 x11-drivers/xf86-input-evdev-2.1.3 x11-drivers/xf86-input-joystick-1.4.0 x11-drivers/xf86-input-keyboard-1.3.2 x11-drivers/xf86-input-mouse-1.4.0 x11-drivers/xf86-input-synaptics-1.0.0 x11-drivers/xf86-input-tslib-0.0.5-r1 x11-drivers/xf86-input-void-1.2.0 x11-drivers/xf86-video-ati-6.12.1-r1 x11-drivers/xf86-video-dummy-0.3.1 x11-drivers/xf86-video-fbdev-0.4.0 x11-drivers/xf86-video-mga-1.4.9 x11-drivers/xf86-video-nv-2.1.12 x11-drivers/xf86-video-r128-6.8.0 x11-drivers/xf86-video-radeonhd-1.2.3 x11-drivers/xf86-video-xgi-1.5.0 x11-libs/libdrm-2.4.5 x11-libs/libpciaccess-0.10.5 x11-libs/libSM-1.1.0 x11-libs/libX11-1.1.5 x11-libs/libXau-1.0.4 x11-libs/libXaw-1.0.5 x11-libs/libXext-1.0.4 x11-libs/libXfont-1.3.4 x11-libs/libXft-2.1.13 x11-libs/libXi-1.2.1 x11-libs/libXinerama-1.0.3 x11-libs/libxkbfile-1.0.5 x11-libs/libXmu-1.0.4 x11-libs/libXrandr-1.2.3 x11-libs/libXrender-0.9.4 x11-libs/libXScrnSaver-1.1.3 x11-libs/libXv-1.0.4 x11-libs/libXxf86vm-1.0.2 x11-libs/pixman-0.14.0-r1 x11-libs/tslib-1.0-r1 x11-libs/xtrans-1.2.3 x11-misc/driconf-0.9.1 x11-misc/transset-0.1_pre20040821 x11-misc/util-macros-1.2.1 x11-misc/xcompmgr-1.1.4 x11-misc/xinput-1.4.0 x11-misc/xkeyboard-config-1.5 x11-proto/dri2proto-1.99.3 x11-proto/inputproto-1.5.0 x11-proto/printproto-1.0.4 x11-proto/randrproto-1.2.2 x11-proto/renderproto-0.9.3 x11-proto/xextproto-7.0.4 x11-proto/xf86driproto-2.0.4 x11-proto/xproto-7.0.14 x11-proto/xproxymanagementprotocol-1.0.2 x11-terms/xterm-242 x11-wm/twm-1.0.4 x11-proto/xcalibrateproto-0.1_pre20081210 x11-libs/libXCalibrate-0.1_pre20081207
Removed ppc/ppc64 from the CC list.
(In reply to comment #103) > (In reply to comment #102) > > You want those versions or newer on amd64? > > Go with the latest version that builds... > > Thanks > Ok, thx. "the list" and above mentioned packages (latest versions) all compile in a stable amd64 chroot. That is, "list v6 with version numbers" and: =x11-drivers/xf86-video-voodoo-1.2.1 =x11-drivers/xf86-video-mach64-6.8.0 =x11-drivers/xf86-video-sis-0.10.1 Either maekke or Tester are going to mark these stable because I will not get to it this weekend for amd64. aside, I hope the news item can get published *before* amd64 marks it stable ;)
The list is incomplete.. A bunch of program in x11-apps/* has a built_with_use x11-libs/libXaw xprint, since the new libXaw no longer has xprint support, the -r1 versions of those packages should be added to the list too and stabilized. And ppc/ppc64 should be called back too..
(In reply to comment #108) > The list is incomplete.. Indeed, I'll complete the list ASAP, but please don't let this hold the stabilization back. It's been delayed long enough. Thanks for the heads up
@Arches who have not yet stabilized Xorg 1.5.3, please make sure to stabilize the X utilities in bug #264982 first. Thank you :)
Created attachment 187389 [details] Xorg Xserver 1.5.3 Stabilization List v7 with version numbers The previous list was incomplete, here is an updated one (as used for amd64)
amd64 is done..
(In reply to comment #112) > amd64 is done.. the following dependencies are still masked (some of them dependent of my hardware) while trying to emerge the recently unmasked ebuild in "amd64" : x11-libs/libpciaccess ~amd64 x11-libs/libXrender ~amd64 x11-proto/xextproto ~amd64 x11-libs/libXau ~amd64 x11-proto/xproto ~amd64 x11-libs/libXext ~amd64 x11-proto/inputproto ~amd64 x11-misc/xkeyboard-config ~amd64 x11-libs/xtrans ~amd64 x11-libs/libX11 ~amd64 x11-proto/xf86driproto ~amd64 x11-libs/libXxf86vm ~amd64 x11-proto/randrproto ~amd64 x11-libs/libXfont ~amd64 x11-proto/renderproto ~amd64 x11-drivers/xf86-video-radeonhd ~amd64 x11-drivers/xf86-input-keyboard ~amd64 x11-drivers/xf86-video-mach64 ~amd64 x11-drivers/xf86-input-mouse ~amd64
(In reply to comment #113) > (In reply to comment #112) > > amd64 is done.. > > the following dependencies are still masked (some of them dependent of my > hardware) while trying to emerge the recently unmasked ebuild in "amd64" : Sync again in an hour or two. CVS being what it is (ie, crap), it's very likely you didn't get all of the keyworded packages in one go.
(In reply to comment #114) > Sync again in an hour or two. CVS being what it is (ie, crap), it's very likely > you didn't get all of the keyworded packages in one go. > So, why didn't Gentoo move to something else ? (yes, I know, completely off-topic here)
> So, why didn't Gentoo move to something else ? (yes, I know, completely > off-topic here) We are in the process of moving, see the gentoo-scm mailing list: http://archives.gentoo.org/gentoo-scm/
x86 stable
IIRC, xf86-video-radeonhd-1.2.3 contains a regression that causes r5xx-family radeon GPUs to freeze on suspend resume when DRI is enabled. No bug ticket upstream, but I was involved in discovering it. The fix is in 1.2.4; I recommend all arches that plan to (or already did) mark a version of radeonhd stable do so for 1.2.4 only.
sparc stable for: =media-libs/mesa-7.3-r1 =x11-apps/mesa-progs-7.3 =x11-apps/rgb-1.0.3 =x11-apps/xauth-1.0.3 =x11-apps/xev-1.0.3 =x11-apps/xinit-1.0.8-r4 =x11-apps/xkbcomp-1.0.5 =x11-apps/xrandr-1.2.3 =x11-base/xorg-server-1.5.3-r5 =x11-drivers/xf86-input-acecad-1.3.0 =x11-drivers/xf86-input-aiptek-1.2.0 =x11-drivers/xf86-input-evdev-2.1.3 =x11-drivers/xf86-input-joystick-1.4.0 =x11-drivers/xf86-input-keyboard-1.3.2 =x11-drivers/xf86-input-mouse-1.4.0 =x11-drivers/xf86-input-void-1.2.0 =x11-drivers/xf86-video-ati-6.12.1-r1 =x11-drivers/xf86-video-mach64-6.8.0 =x11-drivers/xf86-video-r128-6.8.0 =x11-drivers/xf86-video-dummy-0.3.1 =x11-drivers/xf86-video-fbdev-0.4.0 =x11-drivers/xf86-video-mga-1.4.9 =x11-drivers/xf86-video-sunffb-1.2.0 =x11-drivers/xf86-video-tdfx-1.4.1 =x11-drivers/xf86-video-voodoo-1.2.1 =x11-libs/libdrm-2.4.5 =x11-libs/libpciaccess-0.10.5 =x11-libs/libSM-1.1.0 =x11-libs/libX11-1.1.5 =x11-libs/libXau-1.0.4 =x11-libs/libXaw-1.0.5 =x11-libs/libXext-1.0.4 =x11-libs/libXfont-1.3.4 =x11-libs/libXft-2.1.13 =x11-libs/libXi-1.2.1 =x11-libs/libXinerama-1.0.3 =x11-libs/libxkbfile-1.0.5 =x11-libs/libXmu-1.0.4 =x11-libs/libXrandr-1.2.3 =x11-libs/libXrender-0.9.4 =x11-libs/libXScrnSaver-1.1.3 =x11-libs/libXv-1.0.4 =x11-libs/libXxf86vm-1.0.2 =x11-libs/pixman-0.14.0-r1 =x11-libs/tslib-1.0-r1 =x11-libs/xtrans-1.2.3 =x11-misc/util-macros-1.2.1 =x11-misc/xcompmgr-1.1.4 =x11-misc/xinput-1.4.0 =x11-misc/xkeyboard-config-1.5 =x11-proto/dri2proto-1.99.3 =x11-proto/inputproto-1.5.0 =x11-proto/printproto-1.0.4 =x11-proto/randrproto-1.2.2 =x11-proto/renderproto-0.9.3 =x11-proto/xextproto-7.0.4 =x11-proto/xf86driproto-2.0.4 =x11-proto/xproto-7.0.14 =x11-terms/xterm-242 =x11-wm/twm-1.0.4 =x11-libs/libXCalibrate-0.1_pre20081207 =x11-proto/xcalibrateproto-0.1_pre20081210 =x11-drivers/xf86-input-mutouch-1.2.1 =x11-drivers/xf86-input-hyperpen-1.2.0 =x11-drivers/xf86-input-fpit-1.2.0 =x11-drivers/xf86-input-dynapro-1.1.2 =x11-drivers/xf86-input-summa-1.2.0 =x11-drivers/xf86-video-v4l-0.2.0 =x11-drivers/xf86-input-elographics-1.2.2 =x11-drivers/xf86-input-citron-2.2.1 =x11-drivers/xf86-video-sisusb-0.9.0 =x11-drivers/xf86-input-microtouch-1.2.0 =x11-drivers/xf86-input-jamstudio-1.2.0 =x11-drivers/xf86-input-tek4957-1.2.0 =x11-drivers/xf86-input-magellan-1.2.0 =x11-drivers/xf86-input-calcomp-1.1.2 =x11-drivers/xf86-input-elo2300-1.1.2 =x11-drivers/xf86-input-penmount-1.3.0 =x11-drivers/xf86-input-dmc-1.1.2 =x11-drivers/xf86-input-digitaledge-1.1.1 =x11-drivers/xf86-input-spaceorb-1.1.1 =x11-drivers/xf86-input-palmax-1.2.0 =x11-drivers/xf86-video-savage-2.2.1 =x11-drivers/xf86-video-glint-1.2.1 =x11-drivers/xf86-video-sunleo-1.2.0 =x11-drivers/xf86-input-tslib-0.0.5-r1 And I keyworded these ~sparc since they were not keyworded before: =x11-misc/driconf-0.9.1 =x11-misc/rendercheck-1.3 =x11-misc/transset-0.1_pre20040821 =x11-misc/xtermcontrol-2.9 I'll mark them stable in 30 days, unless you think they are urgent (they have no rdeps)
(In reply to comment #119) > I'll mark them stable in 30 days, unless you think they are urgent (they have > no rdeps) Nah, 30 days is fine. It doesn't really matter. Do as you wish :) Thanks!
I think =net-misc/vnc-4.1.3-r2 stabilization needs to block this bug, as well as depend on it. ( bug 264897 ). The current stable vnc depends on ~x11-base/xorg-server-1.3.0.0, which results in a mess of blockers when trying to upgrade.
ia64/sh stable
Stable for HPPA. Looks like it's ready to be RESOLVED as FIXED.
Hi all, When the metapackage xorg-x11 will be stabilized? It seems like there are no blocking issues to do it. BR, Mike.
Let's indeed close this bug FIXED now. We'll take care of alpha somewhere else. Thanks to all who tested the stabilization list. Cheers
(In reply to comment #125) > Let's indeed close this bug FIXED now. We'll take care of alpha somewhere else. What about ARM? ARM still has 1.3.0.0-r6 as the stable version.
Indeed, I forgot about arm. Let's just keep this bug closed, we'll just bother too many folks. We can open a new one for arm if needs be. Thanks
