Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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 an attachment (id=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] [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
> 

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 an attachment (id=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 an attachment (id=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] [details]
> 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 an attachment (id=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 an attachment (id=186696) [details]
Xorg Xserver 1.5.3 Stabilization List v5

Created an attachment (id=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 an attachment (id=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 an attachment (id=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] [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
> 

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 an attachment (id=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