This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
On Wed, Dec 25, 2013 at 10:08 AM, ken gebser@mousecar.com wrote:
This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
Yes, known to happen to some (or many?) users.
https://www.centos.org/forums/viewtopic.php?f=19&t=43984
You can find a workaround in that forum thread.
Akemi
On 12/25/2013 01:42 PM Akemi Yagi wrote:
On Wed, Dec 25, 2013 at 10:08 AM, ken gebser@mousecar.com wrote:
This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
Yes, known to happen to some (or many?) users.
https://www.centos.org/forums/viewtopic.php?f=19&t=43984
You can find a workaround in that forum thread.
Akemi
Thanks, Akemi... and Ned. That worked!
I'm guessing google's spiders didn't get to that forum because it didn't come up in my search... or maybe it was after the third page or something. How did you come to know about this?
Thanks again, peeps.
On Thu, Dec 26, 2013 at 5:44 AM, ken gebser@mousecar.com wrote:
On 12/25/2013 01:42 PM Akemi Yagi wrote:
https://www.centos.org/forums/viewtopic.php?f=19&t=43984
You can find a workaround in that forum thread.
Thanks, Akemi... and Ned. That worked!
I'm guessing google's spiders didn't get to that forum because it didn't come up in my search... or maybe it was after the third page or something. How did you come to know about this?
Well.. I am "toracat" in that forum thread. :-D
Also, this issue was talked about on this very mailing list. Please see :
http://lists.centos.org/pipermail/centos/2013-December/139325.html
Akemi
On 12/26/2013 08:56 AM Akemi Yagi wrote:
On Thu, Dec 26, 2013 at 5:44 AM, ken gebser@mousecar.com wrote:
On 12/25/2013 01:42 PM Akemi Yagi wrote:
https://www.centos.org/forums/viewtopic.php?f=19&t=43984
You can find a workaround in that forum thread.
Thanks, Akemi... and Ned. That worked!
I'm guessing google's spiders didn't get to that forum because it didn't come up in my search... or maybe it was after the third page or something. How did you come to know about this?
Well.. I am "toracat" in that forum thread. :-D
Also, this issue was talked about on this very mailing list. Please see :
http://lists.centos.org/pipermail/centos/2013-December/139325.html
So it was. I'm going to forgive myself for missing it then though. The subject line was a little vague and the thread started out talking about a calendar app called lightning, which, since I don't use, so had no problem with, and am, pivotally, thoroughly ignorant about, I ignored. So, yeah, I recall seeing that and then hot dropping the entire thread into the bit bucket. :\ But it's impossible to read everything, right?
I note there now too that it was this list's esteemed member, Johnny Hughes, who posted the solution, in fact a better one (quite possibly) than the one on the centos forum previously cited: rather than specifying "firefox" in Preferences directly, the previously-mentioned "open-browser.sh" script/wrapper is specified. I just tried this and it does work also. And there is again coolness in the universe. :)
tnx++
On 25/12/13 18:08, ken wrote:
This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
I'm having a problem with Thunderbird's links but not quite the same. I click on a link in a email & it actually loads it in Chrome but then it freezes the whole machine. I can launch a terminal via Ctrl-Alt-F2 but can't get a prompt in order to actually do anything.
My only recourse is a hard reboot via the mains plug.
This has happened for the last few updates. If you get any joy from the Thunderbird people, please let me know.
Cheers,
Phil.
On 12/25/2013 09:09 PM Phil Dobbin wrote:
On 25/12/13 18:08, ken wrote:
This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
I'm having a problem with Thunderbird's links but not quite the same. I click on a link in a email & it actually loads it in Chrome but then it freezes the whole machine. I can launch a terminal via Ctrl-Alt-F2 but can't get a prompt in order to actually do anything.
My only recourse is a hard reboot via the mains plug.
This has happened for the last few updates. If you get any joy from the Thunderbird people, please let me know.
Cheers,
Phil.
In the reading I did trying to resolve my issue, I ran across a few conversations about your situation. Because it had to do with chrome and so not my situation at all, I don't remember the details, just that the chrome install might have greedily set some system variable which it shouldn't have and that this screwed up some things. Google for it and you should find others' experiences and perhaps also somebody's solution.
hth, ken
On 26/12/13 13:53, ken wrote:
On 12/25/2013 09:09 PM Phil Dobbin wrote:
On 25/12/13 18:08, ken wrote:
This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
I'm having a problem with Thunderbird's links but not quite the same. I click on a link in a email & it actually loads it in Chrome but then it freezes the whole machine. I can launch a terminal via Ctrl-Alt-F2 but can't get a prompt in order to actually do anything.
My only recourse is a hard reboot via the mains plug.
This has happened for the last few updates. If you get any joy from the Thunderbird people, please let me know.
Cheers,
Phil.In the reading I did trying to resolve my issue, I ran across a few conversations about your situation. Because it had to do with chrome and so not my situation at all, I don't remember the details, just that the chrome install might have greedily set some system variable which it shouldn't have and that this screwed up some things. Google for it and you should find others' experiences and perhaps also somebody's solution.
Thanks, Ken.
It's also happening now with Firefox as well (in fact, Firefox is virtually unusable) so I suspect there is something happening with either this machine or the OS.
Cheers,
Phil...
On 12/26/2013 12:03 PM, Phil Dobbin wrote:
On 26/12/13 13:53, ken wrote:
On 12/25/2013 09:09 PM Phil Dobbin wrote:
On 25/12/13 18:08, ken wrote:
This worked fine for years until I updated firefox and thunderbird recently. Now, however, when I click on a link in an email in thunderbird, rather than open the indicated webpage in firefox, nothing at all happens.
network.protocol-handler.app.http in tbird's about:config specifies the executable /usr/lib/thunderbird/open-browser.sh and running the latter at the CLI with a URL as an arg does work as expected: the spec'd URL is loaded into firefox. So I suspect a bug in tbird.
Anyone else having this problem?
I'm having a problem with Thunderbird's links but not quite the same. I click on a link in a email & it actually loads it in Chrome but then it freezes the whole machine. I can launch a terminal via Ctrl-Alt-F2 but can't get a prompt in order to actually do anything.
My only recourse is a hard reboot via the mains plug.
This has happened for the last few updates. If you get any joy from the Thunderbird people, please let me know.
Cheers,
Phil.In the reading I did trying to resolve my issue, I ran across a few conversations about your situation. Because it had to do with chrome and so not my situation at all, I don't remember the details, just that the chrome install might have greedily set some system variable which it shouldn't have and that this screwed up some things. Google for it and you should find others' experiences and perhaps also somebody's solution.
Thanks, Ken.
It's also happening now with Firefox as well (in fact, Firefox is virtually unusable) so I suspect there is something happening with either this machine or the OS.
Are you running the proprietary NVIDIA driver? (either the one from elrepo OR manually building from the NVIDIA site)
If so, the recent xorg-x11-server updates require that you rebuild (or reinstall) the drivers as those drivers replace some xorg files and if you do not reinstall it can freeze the system or crash X.
On 12/30/2013, Johnny Hughes wrote:
On 12/26/2013 12:03 PM, Phil Dobbin wrote:
It's also happening now with Firefox as well (in fact, Firefox is virtually unusable) so I suspect there is something happening with either this machine or the OS.
Are you running the proprietary NVIDIA driver? (either the one from elrepo OR manually building from the NVIDIA site)
If so, the recent xorg-x11-server updates require that you rebuild (or reinstall) the drivers as those drivers replace some xorg files and if you do not reinstall it can freeze the system or crash X.
Another thing you can do if you are using the NVIDIA drivers is add the following to /etc/X11/xorg.conf:
ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules" FontPath "/usr/share/fonts/default/Type1"
See http://elrepo.org/bugs/view.php?id=425 for more details.
By fixing the xorg.conf file, you do not have to worry about this problem re-occurring next time xorg gets upgraded.
This issue drove me crazy for about 2 weeks until I realized that the wrong drivers were getting loaded.
HTH
Regards,
Tom me@tdiehl.org Spamtrap address me123@tdiehl.org
On Tue, Dec 31, 2013 at 5:54 AM, me@tdiehl.org wrote:
On 12/30/2013, Johnny Hughes wrote:
If so, the recent xorg-x11-server updates require that you rebuild (or reinstall) the drivers as those drivers replace some xorg files and if you do not reinstall it can freeze the system or crash X.
Another thing you can do if you are using the NVIDIA drivers is add the following to /etc/X11/xorg.conf:
ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules" FontPath "/usr/share/fonts/default/Type1"
See http://elrepo.org/bugs/view.php?id=425 for more details.
By fixing the xorg.conf file, you do not have to worry about this problem re-occurring next time xorg gets upgraded.
In case it is not obvious, I'd like to add a note here. If you are using ELRepo's Nvidia driver, you do _not_ have to do anything as the referenced issue has been taken care of in there. Quoting Phil Perry from that bug report (comment 3338):
"You are correct that the file /usr/lib64/xorg/modules/extensions/libglx.so is indeed from the distro package xorg-x11-server-Xorg. We DO NOT replace that file as if we did every time the distro package xorg-x11-server-Xorg gets updated the NVIDIA drivers will break. This is the way the NVIDIA proprietary installer does it and it's the WRONG way."
This is yet another reason you want to use the ELRepo's Nvidia package ! :-)
Akemi
On Tue, 31 Dec 2013, Akemi Yagi wrote:
On Tue, Dec 31, 2013 at 5:54 AM, me@tdiehl.org wrote:
On 12/30/2013, Johnny Hughes wrote:
If so, the recent xorg-x11-server updates require that you rebuild (or reinstall) the drivers as those drivers replace some xorg files and if you do not reinstall it can freeze the system or crash X.
Another thing you can do if you are using the NVIDIA drivers is add the following to /etc/X11/xorg.conf:
ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules" FontPath "/usr/share/fonts/default/Type1"
See http://elrepo.org/bugs/view.php?id=425 for more details.
By fixing the xorg.conf file, you do not have to worry about this problem re-occurring next time xorg gets upgraded.
In case it is not obvious, I'd like to add a note here. If you are using ELRepo's Nvidia driver, you do _not_ have to do anything as the referenced issue has been taken care of in there. Quoting Phil Perry from that bug report (comment 3338):
"You are correct that the file /usr/lib64/xorg/modules/extensions/libglx.so is indeed from the distro package xorg-x11-server-Xorg. We DO NOT replace that file as if we did every time the distro package xorg-x11-server-Xorg gets updated the NVIDIA drivers will break. This is the way the NVIDIA proprietary installer does it and it's the WRONG way."
I have used the EL-Repo Nvidia package since I loaded C6 on this machine in the early days of 6.0. Are you saying that I did not have to modify the xorg.conf? The only way I could get it to load the Nvidia driver without reinstalling, was to make the changes noted in the above referenced bug.
Please clarify what you mean.
Regards,
On 01/01/14 16:26, me@tdiehl.org wrote:
On Tue, 31 Dec 2013, Akemi Yagi wrote:
On Tue, Dec 31, 2013 at 5:54 AM, me@tdiehl.org wrote:
On 12/30/2013, Johnny Hughes wrote:
If so, the recent xorg-x11-server updates require that you rebuild (or reinstall) the drivers as those drivers replace some xorg files and if you do not reinstall it can freeze the system or crash X.
Another thing you can do if you are using the NVIDIA drivers is add the following to /etc/X11/xorg.conf:
ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules" FontPath "/usr/share/fonts/default/Type1"
See http://elrepo.org/bugs/view.php?id=425 for more details.
By fixing the xorg.conf file, you do not have to worry about this problem re-occurring next time xorg gets upgraded.
In case it is not obvious, I'd like to add a note here. If you are using ELRepo's Nvidia driver, you do _not_ have to do anything as the referenced issue has been taken care of in there. Quoting Phil Perry from that bug report (comment 3338):
"You are correct that the file /usr/lib64/xorg/modules/extensions/libglx.so is indeed from the distro package xorg-x11-server-Xorg. We DO NOT replace that file as if we did every time the distro package xorg-x11-server-Xorg gets updated the NVIDIA drivers will break. This is the way the NVIDIA proprietary installer does it and it's the WRONG way."
I have used the EL-Repo Nvidia package since I loaded C6 on this machine in the early days of 6.0. Are you saying that I did not have to modify the xorg.conf? The only way I could get it to load the Nvidia driver without reinstalling, was to make the changes noted in the above referenced bug.
Please clarify what you mean.
Regards,
That's correct - you shouldn't have to modify anything - the package should take care of everything for you. With one caveat - the package was designed against a clean system and there is no way we can account for every possibility so it is possible that some users may have modified their systems in such a way that we had not envisaged or accounted for. This has happened, and with feedback from users we have been able to continually improve the packages to account for some of these situations.
To give you an idea what the package does; first any existing xorg.conf is backed up and removed and then a clean xorg.conf is freshly created with the necessary "Files" section including the correct path to the nvidia libs. The driver is then enabled and (on el6) the necessary steps are taken to disable the nouveau driver. This should give all users a basic working installation and subsequent updates should not break this.
Some of this has evolved over time and all might not have been in place when you first installed the driver if you've been using the packages since the initial release of 6.0 - it's been a process of ongoing development.
But the intention is always for the packages to operate in a seamless fashion - install, update, forget; other than any special user-specific configurations you may need to make to support things such as multiple displays etc. If the packages aren't operating as designed then please file a bug and we will investigate and fix any issues. WRT the bug above, I was unable to replicate the issue and it was my understanding the issue was caused by not rebooting after updating the drivers.
So to clarify, on a fresh install of EL6, installing the correct nvidia drivers for your device from elrepo followed by a reboot should leave you with a fully working system.
-
Akemi Yagi -
Johnny Hughes -
ken -
me＠tdiehl.org -
Ned Slider -
Phil Dobbin