Re: solution to the problem of orca and gecko not working in non-gnome environment
Hi, I would prefer to fix it in debian's directory structure and not in iceweasel package. It should be possible to use an upstream firefox without recompiling it under debian when using xfce etc. Just my two cents. MfG. Halim -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311170703.GA27880@gentoo.local
Re: solution to the problem of orca and gecko not working in non-gnome environment
It's reported as Mozilla bug under #743580, but seems like Multiarch is a Debian invention and a Debian only problem for now. So debian-accessibility list looks like the best place to develop a solution to this bug. The workaround with ln -s was posted on orca list quite a while ago [2]. The first thing to check would be iceweasel sources. It's easy to fix the problem in Debian sources, worse with upstream firefox. I don't know about any bug report to iceweasel, maybe it's time for one. When iceweasel is fixed, firefox should bother us much less. Python developers also reported a problem with accessing multiarch triplet in an efficient way [3]. Jarek [1] https://bugzilla.mozilla.org/show_bug.cgi?id=743580 [2] https://mail.gnome.org/archives/orca-list/2013-September/msg6.html [3] https://groups.google.com/forum/#!topic/linux.debian.maint.python/Zq3-oOes0eE W dniu 2014-03-10 00:14, Jason White pisze: I think I've found it with a quick search of the Mozilla repository. mozilla/accessible/src/atk/Platform.cpp, line 81: 81 #if defined(LINUX) defined(__x86_64__) 82 libPath.Append(:/usr/lib64:/usr/lib); If you change line 82 to libPath.Append(:/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu); and rebuild Mozilla, it might work. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531d810c.8050...@poczta.onet.pl
solution to the problem of orca and gecko not working in non-gnome environment
In my XFCE environment, It appears that the problem is occurring from a Gtk module import path issue. I coppied the /usr/lib/x86_64-linux-gnu/gtk-2.0/modules directory to /usr/lib/gtk-2.0 and things work for me in the Mozilla apps. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394384383.31203.92360033.63a56...@webmail.messagingengine.com
Re: solution to the problem of orca and gecko not working in non-gnome environment
I think I've found it with a quick search of the Mozilla repository. mozilla/accessible/src/atk/Platform.cpp, line 81: 81 #if defined(LINUX) defined(__x86_64__) 82 libPath.Append(:/usr/lib64:/usr/lib); If you change line 82 to libPath.Append(:/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu); and rebuild Mozilla, it might work. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140309231427.ga7...@jdc.jasonjgw.net
Re: solution to the problem of orca and gecko not working in non-gnome environment
Jason White ja...@jasonjgw.net (2014-03-10): I think I've found it with a quick search of the Mozilla repository. mozilla/accessible/src/atk/Platform.cpp, line 81: 81 #if defined(LINUX) defined(__x86_64__) 82 libPath.Append(:/usr/lib64:/usr/lib); If you change line 82 to libPath.Append(:/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu); and rebuild Mozilla, it might work. I think that's a very good catch indeed. There are a few other places where one can find /usr/lib in *.ccp files in iceweasel, but most of them are debug directories, or paths below /usr/lib/mozilla/. I suspect it would be nice to have a placeholder/#define somewhere so that the proper multiarch directory can be injected from debian/rules; depending on how easily I can reproduce the issue, I'll try and get a working patch and submit the bug report against iceweasel. Mraw, KiBi. signature.asc Description: Digital signature
Re: solution to the problem of orca and gecko not working in non-gnome environment
On Sun, Mar 9, 2014, at 07:21 PM, Cyril Brulebois wrote: Jason White ja...@jasonjgw.net (2014-03-10): I think I've found it with a quick search of the Mozilla repository. mozilla/accessible/src/atk/Platform.cpp, line 81: 81 #if defined(LINUX) defined(__x86_64__) 82 libPath.Append(:/usr/lib64:/usr/lib); If you change line 82 to libPath.Append(:/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu); and rebuild Mozilla, it might work. I think that's a very good catch indeed. There are a few other places where one can find /usr/lib in *.ccp files in iceweasel, but most of them are debug directories, or paths below /usr/lib/mozilla/. I suspect it would be nice to have a placeholder/#define somewhere so that the proper multiarch directory can be injected from debian/rules; depending on how easily I can reproduce the issue, I'll try and get a working patch and submit the bug report against iceweasel. I appreciate all the helpful replies so far. The thing that seems so puzzling to me is why this problem does not occur when running in gnome shell. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394408040.12662.92454065.4a116...@webmail.messagingengine.com
Re: solution to the problem of orca and gecko not working in non-gnome environment
On Mon, Mar 10, 2014 at 10:34:00AM EST, am_d...@fastmail.fm wrote: On Sun, Mar 9, 2014, at 07:21 PM, Cyril Brulebois wrote: Jason White ja...@jasonjgw.net (2014-03-10): I think I've found it with a quick search of the Mozilla repository. mozilla/accessible/src/atk/Platform.cpp, line 81: 81 #if defined(LINUX) defined(__x86_64__) 82 libPath.Append(:/usr/lib64:/usr/lib); If you change line 82 to libPath.Append(:/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu); and rebuild Mozilla, it might work. I think that's a very good catch indeed. There are a few other places where one can find /usr/lib in *.ccp files in iceweasel, but most of them are debug directories, or paths below /usr/lib/mozilla/. I suspect it would be nice to have a placeholder/#define somewhere so that the proper multiarch directory can be injected from debian/rules; depending on how easily I can reproduce the issue, I'll try and get a working patch and submit the bug report against iceweasel. I appreciate all the helpful replies so far. The thing that seems so puzzling to me is why this problem does not occur when running in gnome shell. Things work properly in GNOME shell because gnome-settings-daemon in conjunction with libatk-adaptor does something to inject the recommended GTK modules into the environment of GTK apps that get launched. I am not sure how this is done, probably an X setting or property somewhere. Libatk-adaptor doesn't *do* anything as such, but it provides a .desktop file that lives in /usr/lib/gnome-settings-daemon-3.0/gtk-modules that gets read by gnome-settings-daemon and acted upon. Luke -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140310002115.GA22610@acapella
