Hey, everyone. So, it's time for pre-release testing again!
I know this didn't work perfectly for Alpha, but I've got together with releng and tightened up processes and it should be better for Beta. So: right now, here:
http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Beta.RC2/Live/
you will find live images for all of the desktop spins (KDE, XFCE, LXDE, Desktop) for RC2 of Fedora 14 Beta. I have tested them, and all four at least boot in a VM, so they're not completely broken like some of the Alpha images :) I also tested KDE and Desktop on bare metal, and I think Christoph has LXDE booted on bare metal right now, so we're pretty sure these are working at a basic level. You won't be wasting a download :)
So with these spins we need to fill out these tables:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
As you can see, I've made a start on this already, but there's many tests to fill out. We absolutely need to fill out all the Alpha and Beta tests for each spin. It would be great to also do the Final tests, as this gives us a head start on identifying and fixing blocker issues for the final release.
If people could do some of these tests over the next few days (by Wednesday) that would be awesome. Also note that I'm running a session at FUDCon Zurich this afternoon where we'll hopefully be able to get together and fill out some of the table, so if you're at FUDCon, come out to my session at 2pm :)
Hello, While it may not be what was asked for, there is a problem with the i686 gnome desktop one. When I boot it, wait for the desktop to appear and then try and launch the orca screen reader http://live.gnome.org/Orca (press alt+f2 for run and then type orca and press enter) orca fails to load.
Unfortunately as I rely on orca for output from the system I cannot see any error message when I launch orca from gnome-terminal. However I can say the following, I know the sound and text to speech chain is working from orca as when I give the command "orca -t" from gnome-terminal orca will go through its text based set up questions providing speech output. Even after doing the text based set up and logging out and back in orca still fails to load.
This is a severe accessibility issue.
As I said, being unable to see I cannot get the error message so cannot proceed with working out the cause, however if someone could try launching orca (without any options) from gnome-terminal and give me the output, I can try and find out the cause.
Michael Whapples
On -10/01/37 20:59, Adam Williamson wrote:
Hey, everyone. So, it's time for pre-release testing again!
I know this didn't work perfectly for Alpha, but I've got together with releng and tightened up processes and it should be better for Beta. So: right now, here:
http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Beta.RC2/Live/
you will find live images for all of the desktop spins (KDE, XFCE, LXDE, Desktop) for RC2 of Fedora 14 Beta. I have tested them, and all four at least boot in a VM, so they're not completely broken like some of the Alpha images :) I also tested KDE and Desktop on bare metal, and I think Christoph has LXDE booted on bare metal right now, so we're pretty sure these are working at a basic level. You won't be wasting a download :)
So with these spins we need to fill out these tables:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
As you can see, I've made a start on this already, but there's many tests to fill out. We absolutely need to fill out all the Alpha and Beta tests for each spin. It would be great to also do the Final tests, as this gives us a head start on identifying and fixing blocker issues for the final release.
If people could do some of these tests over the next few days (by Wednesday) that would be awesome. Also note that I'm running a session at FUDCon Zurich this afternoon where we'll hopefully be able to get together and fill out some of the table, so if you're at FUDCon, come out to my session at 2pm :)
On Sun, 2010-09-19 at 23:57 +0100, Michael Whapples wrote:
Hello, While it may not be what was asked for, there is a problem with the i686 gnome desktop one. When I boot it, wait for the desktop to appear and then try and launch the orca screen reader http://live.gnome.org/Orca (press alt+f2 for run and then type orca and press enter) orca fails to load.
Unfortunately as I rely on orca for output from the system I cannot see any error message when I launch orca from gnome-terminal. However I can say the following, I know the sound and text to speech chain is working from orca as when I give the command "orca -t" from gnome-terminal orca will go through its text based set up questions providing speech output. Even after doing the text based set up and logging out and back in orca still fails to load.
This is a severe accessibility issue.
As I said, being unable to see I cannot get the error message so cannot proceed with working out the cause, however if someone could try launching orca (without any options) from gnome-terminal and give me the output, I can try and find out the cause.
Thanks for reporting this. I agree entirely, this is clearly a major issue for anyone who relies on Orca. Unfortunately we don't capture accessibility stuff in the release criteria right now, which is an omission we should fix and I'm sorry about that.
The error I get trying to run orca from a terminal is a Python traceback:
[adamw@vaioz live]$ orca Gtk-Message: Failed to load module "atk-bridge": libatk-bridge.so: cannot open shared object file: No such file or directory
(orca:31286): Bonobo-WARNING **: Bonobo must be initialized before use Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/orca/orca.py", line 2205, in main init(pyatspi.Registry) File "/usr/lib64/python2.7/site-packages/orca/orca.py", line 1618, in init "object:children-changed") File "/usr/lib/python2.7/site-packages/pyatspi/registry.py", line 269, in registerEventListener self._set_default_registry () File "/usr/lib/python2.7/site-packages/pyatspi/registry.py", line 163, in _set_default_registry self._set_registry (MAIN_LOOP_GLIB) File "/usr/lib/python2.7/site-packages/pyatspi/registry.py", line 134, in _set_registry cache = AccessibleCache (app_name) File "/usr/lib/python2.7/site-packages/pyatspi/cache.py", line 326, in __init__ self._manager = DesktopCacheManager (self) File "/usr/lib/python2.7/site-packages/pyatspi/cache.py", line 87, in __init__ bus = SyncAccessibilityBus (registry.Registry()) File "/usr/lib/python2.7/site-packages/pyatspi/busutils/bus.py", line 163, in __new__ _bus.BusConnection.__new__ (cls, _get_accessibility_bus_address(), None) File "/usr/lib/python2.7/site-packages/pyatspi/busutils/bus.py", line 30, in _get_accessibility_bus_address from Xlib import display, Xatom ImportError: No module named Xlib
looks like it may wind up being a dependency issue, if the Xlib module is available somehow; if not, it means orca needs rewriting in some way, or the module got renamed, or the module hasn't been rebuilt for Python 2.7, or something like that. I will file a bug, mark it as NTH for Beta RC3, and investigate. Thanks.
Hello, The traceback I think is to do with a change in dependencies between at-spi and the newer at-spi on dbus (at-spi2). On my debian system (using at-spi 1.30.1) I just tried to do the import causing the import error and got that error (orca works fine on this debian system). I then had a look for the package and found the debian package python-xlib and once installed the import works fine. Not being very familiar with the fedora packages I am unsure of the fedora package name but the debian package says the homepage for the package is http://python-xlib.sf.net.
While I think its not causing the traceback, I am concerned by the GTK warning about being unable to load the atk-bridge module, as I understand it this will break accessibility. Did this module get moved with the at-spi2 change?
Michael Whapples On -10/01/37 20:59, Adam Williamson wrote:
On Sun, 2010-09-19 at 23:57 +0100, Michael Whapples wrote:
Hello, While it may not be what was asked for, there is a problem with the i686 gnome desktop one. When I boot it, wait for the desktop to appear and then try and launch the orca screen reader http://live.gnome.org/Orca (press alt+f2 for run and then type orca and press enter) orca fails to load.
Unfortunately as I rely on orca for output from the system I cannot see any error message when I launch orca from gnome-terminal. However I can say the following, I know the sound and text to speech chain is working from orca as when I give the command "orca -t" from gnome-terminal orca will go through its text based set up questions providing speech output. Even after doing the text based set up and logging out and back in orca still fails to load.
This is a severe accessibility issue.
As I said, being unable to see I cannot get the error message so cannot proceed with working out the cause, however if someone could try launching orca (without any options) from gnome-terminal and give me the output, I can try and find out the cause.
Thanks for reporting this. I agree entirely, this is clearly a major issue for anyone who relies on Orca. Unfortunately we don't capture accessibility stuff in the release criteria right now, which is an omission we should fix and I'm sorry about that.
The error I get trying to run orca from a terminal is a Python traceback:
[adamw@vaioz live]$ orca Gtk-Message: Failed to load module "atk-bridge": libatk-bridge.so: cannot open shared object file: No such file or directory
(orca:31286): Bonobo-WARNING **: Bonobo must be initialized before use Traceback (most recent call last): File "<string>", line 1, in<module> File "/usr/lib64/python2.7/site-packages/orca/orca.py", line 2205, in main init(pyatspi.Registry) File "/usr/lib64/python2.7/site-packages/orca/orca.py", line 1618, in init "object:children-changed") File "/usr/lib/python2.7/site-packages/pyatspi/registry.py", line 269, in registerEventListener self._set_default_registry () File "/usr/lib/python2.7/site-packages/pyatspi/registry.py", line 163, in _set_default_registry self._set_registry (MAIN_LOOP_GLIB) File "/usr/lib/python2.7/site-packages/pyatspi/registry.py", line 134, in _set_registry cache = AccessibleCache (app_name) File "/usr/lib/python2.7/site-packages/pyatspi/cache.py", line 326, in __init__ self._manager = DesktopCacheManager (self) File "/usr/lib/python2.7/site-packages/pyatspi/cache.py", line 87, in __init__ bus = SyncAccessibilityBus (registry.Registry()) File "/usr/lib/python2.7/site-packages/pyatspi/busutils/bus.py", line 163, in __new__ _bus.BusConnection.__new__ (cls, _get_accessibility_bus_address(), None) File "/usr/lib/python2.7/site-packages/pyatspi/busutils/bus.py", line 30, in _get_accessibility_bus_address from Xlib import display, Xatom ImportError: No module named Xlib
looks like it may wind up being a dependency issue, if the Xlib module is available somehow; if not, it means orca needs rewriting in some way, or the module got renamed, or the module hasn't been rebuilt for Python 2.7, or something like that. I will file a bug, mark it as NTH for Beta RC3, and investigate. Thanks.
On Mon, 2010-09-20 at 13:47 +0100, Michael Whapples wrote:
Hello, The traceback I think is to do with a change in dependencies between at-spi and the newer at-spi on dbus (at-spi2). On my debian system (using at-spi 1.30.1) I just tried to do the import causing the import error and got that error (orca works fine on this debian system). I then had a look for the package and found the debian package python-xlib and once installed the import works fine. Not being very familiar with the fedora packages I am unsure of the fedora package name but the debian package says the homepage for the package is http://python-xlib.sf.net.
While I think its not causing the traceback, I am concerned by the GTK warning about being unable to load the atk-bridge module, as I understand it this will break accessibility. Did this module get moved with the at-spi2 change?
There's an update which fixes the dependency issue:
https://admin.fedoraproject.org/updates/pyatspi-0.3.91-2.fc14
are you able to test this and see if Orca behaves as it should now? Thanks!
I haven't managed to test out the specific package as to prepare a system while orca is broken is a bit hard, but I can confirm just installing python-xlib (I did the command: yum --assumeyes python-xlib) does allow orca to run.
However I think there is still a problem somewhere in the accessibility chain as orca isn't reporting any information on what has focus, etc. As I said the GTK warning you mentioned does concern me, if atk-bridge cannot be found then GTK is not going to be providing information to at-spi (that's my understanding). Someone on the orca list has suggested setting a gconf key (/desktop/gnome/interface/at-spi-dbus to true so that GTK knows to use that version of atk-bridge.
As a side question, is it possible for me to SSH or something like that, into the live environment so I possibly can get some of this information on my own and not have to enter commands just hoping I have typed it correct?
Michael Whapples On -10/01/37 20:59, Adam Williamson wrote:
On Mon, 2010-09-20 at 13:47 +0100, Michael Whapples wrote:
Hello, The traceback I think is to do with a change in dependencies between at-spi and the newer at-spi on dbus (at-spi2). On my debian system (using at-spi 1.30.1) I just tried to do the import causing the import error and got that error (orca works fine on this debian system). I then had a look for the package and found the debian package python-xlib and once installed the import works fine. Not being very familiar with the fedora packages I am unsure of the fedora package name but the debian package says the homepage for the package is http://python-xlib.sf.net.
While I think its not causing the traceback, I am concerned by the GTK warning about being unable to load the atk-bridge module, as I understand it this will break accessibility. Did this module get moved with the at-spi2 change?
There's an update which fixes the dependency issue:
https://admin.fedoraproject.org/updates/pyatspi-0.3.91-2.fc14
are you able to test this and see if Orca behaves as it should now? Thanks!
On Tue, Sep 21, 2010 at 15:51:09 +0100, Michael Whapples mwhapples@aim.com wrote:
As a side question, is it possible for me to SSH or something like that, into the live environment so I possibly can get some of this information on my own and not have to enter commands just hoping I have typed it correct?
I doubt the ssh server would be running by default. Maybe boot into level 3, try starting the ssh service. (I am not sure which spins have sshd installed.)
On Tue, 2010-09-21 at 15:51 +0100, Michael Whapples wrote:
I haven't managed to test out the specific package as to prepare a system while orca is broken is a bit hard, but I can confirm just installing python-xlib (I did the command: yum --assumeyes python-xlib) does allow orca to run.
However I think there is still a problem somewhere in the accessibility chain as orca isn't reporting any information on what has focus, etc. As I said the GTK warning you mentioned does concern me, if atk-bridge cannot be found then GTK is not going to be providing information to at-spi (that's my understanding). Someone on the orca list has suggested setting a gconf key (/desktop/gnome/interface/at-spi-dbus to true so that GTK knows to use that version of atk-bridge.
I'm definitely worried about this too. It also points up the fact that we have no accessibility release criteria, which is a bad omission, we should add some. Would you be available for an off-list discussion to educate me in a11y stuff so I can write up some criteria?
In RC3, with the orca dependency fixed, orca does run, and we're down to just one warning at the console on the desktop spin when starting any GNOME app. I'll investigate that as much as I can when I'm done with desktop validation testing.
As a side question, is it possible for me to SSH or something like that, into the live environment so I possibly can get some of this information on my own and not have to enter commands just hoping I have typed it correct?
As Bruno says, I think sshd is not running by default. You'd have to bring the network up and start sshd before you could connect, I'm afraid.
On Tue, Sep 21, 2010 at 4:42 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2010-09-21 at 15:51 +0100, Michael Whapples wrote:
I haven't managed to test out the specific package as to prepare a system while orca is broken is a bit hard, but I can confirm just installing python-xlib (I did the command: yum --assumeyes python-xlib) does allow orca to run.
However I think there is still a problem somewhere in the accessibility chain as orca isn't reporting any information on what has focus, etc. As I said the GTK warning you mentioned does concern me, if atk-bridge cannot be found then GTK is not going to be providing information to at-spi (that's my understanding). Someone on the orca list has suggested setting a gconf key (/desktop/gnome/interface/at-spi-dbus to true so that GTK knows to use that version of atk-bridge.
I'm definitely worried about this too. It also points up the fact that we have no accessibility release criteria, which is a bad omission, we should add some. Would you be available for an off-list discussion to educate me in a11y stuff so I can write up some criteria?
I think from a couple of bug reports I've seen that some of the accessibility (not sure how much, to what extent or what desktops) has been broken for 2-3 releases.
In RC3, with the orca dependency fixed, orca does run, and we're down to just one warning at the console on the desktop spin when starting any GNOME app. I'll investigate that as much as I can when I'm done with desktop validation testing.
As a side question, is it possible for me to SSH or something like that, into the live environment so I possibly can get some of this information on my own and not have to enter commands just hoping I have typed it correct?
As Bruno says, I think sshd is not running by default. You'd have to bring the network up and start sshd before you could connect, I'm afraid.
Its definitely not running by default but I think the firewall rules allow it by default so you shouldn't have to change those.
Peter
Hello, Yes I would be OK with an off list discussion to help you get to grips with certain parts of the A11Y stuff. Probably email is the best way to contact me, but if you want a more instant system like skype or IM, then I'm in the UK to give you an idea of timezone (we're currently on BST not GMT).
Michael Whapples On -10/01/37 20:59, Adam Williamson wrote:
On Tue, 2010-09-21 at 15:51 +0100, Michael Whapples wrote:
I haven't managed to test out the specific package as to prepare a system while orca is broken is a bit hard, but I can confirm just installing python-xlib (I did the command: yum --assumeyes python-xlib) does allow orca to run.
However I think there is still a problem somewhere in the accessibility chain as orca isn't reporting any information on what has focus, etc. As I said the GTK warning you mentioned does concern me, if atk-bridge cannot be found then GTK is not going to be providing information to at-spi (that's my understanding). Someone on the orca list has suggested setting a gconf key (/desktop/gnome/interface/at-spi-dbus to true so that GTK knows to use that version of atk-bridge.
I'm definitely worried about this too. It also points up the fact that we have no accessibility release criteria, which is a bad omission, we should add some. Would you be available for an off-list discussion to educate me in a11y stuff so I can write up some criteria?
In RC3, with the orca dependency fixed, orca does run, and we're down to just one warning at the console on the desktop spin when starting any GNOME app. I'll investigate that as much as I can when I'm done with desktop validation testing.
As a side question, is it possible for me to SSH or something like that, into the live environment so I possibly can get some of this information on my own and not have to enter commands just hoping I have typed it correct?
As Bruno says, I think sshd is not running by default. You'd have to bring the network up and start sshd before you could connect, I'm afraid.
desktop@lists.fedoraproject.org