abrt 1.0.0 detected a crash. backtrace ----- Summary: TBbe67add7 xauth.py:46:__init__:XauthError: ~/.Xauthority: [Errno 2] No such file or directory: '/home/pierre/.Xauthority' Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/gtktrayicon.py", line 114, in on_realize xdisplay = self.get_xdisplay() File "/usr/lib64/python2.6/site-packages/gtktrayicon.py", line 161, in get_xdisplay xdisplay = Xdisplay.Display(name) File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 85, in __init__ self.display = _BaseDisplay(display) File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 67, in __init__ apply(protocol.display.Display.__init__, (self, ) + args, keys) File "/usr/lib/python2.6/site-packages/Xlib/protocol/display.py", line 53, in __init__ name, host, displayno) File "/usr/lib/python2.6/site-packages/Xlib/support/connect.py", line 96, in get_auth return mod.get_auth(sock, dname, host, dno) File "/usr/lib/python2.6/site-packages/Xlib/support/unix_connect.py", line 100, in new_get_auth au = xauth.Xauthority() File "/usr/lib/python2.6/site-packages/Xlib/xauth.py", line 46, in __init__ raise error.XauthError('~/.Xauthority: %s' % err) XauthError: ~/.Xauthority: [Errno 2] No such file or directory: '/home/pierre/.Xauthority' Local variables in innermost frame: self: <Xlib.xauth.Xauthority instance at 0x2be8170> err: [Errno 2] No such file or directory: '/home/pierre/.Xauthority' filename: /home/pierre/.Xauthority cmdline: /usr/bin/python -OO /usr/bin/gmixer -d component: gmixer executable: /usr/bin/gmixer kernel: 2.6.31.9-174.fc12.x86_64 package: gmixer-1.3-11.fc12 uuid: be67add7
Created attachment 381731 [details] File: backtrace
What version of python-xlib are you using?, if it's 0.14-5 try updating to 0.14-6 from updates-testing.
it was 0.14-5 I updated to 0.14-6 from updates-testing. It still crashes. I should add that I'm running Fedora LXDE spin freshly installed and updated. GMixer crashes upon login.
I can't reproduce the error here.
I'm getting exactly the same error. Creating an .Xauthority-file with mkxauth -c did not work as the file is gone again after reboot.
The first thing that comes to my mind is the recent SLIM update. Could somebody please downgrade SLIM to see if they have an ~/.Xauthority again?
I've got the same problem. Also fresh install of Fedora LXDE spin. Problem first appeared after making several updates.
Same issue, resolves with mkauth -c, however gone after reboot, wondering if this has soemthing to do with policykit authentication?
So can somebody please test what I suggested in comment 6? "yum downgrade slim" should do.
Created attachment 386653 [details] Here is a script to get the program running atleast while the bug is worked out. On startup if you run this from console it will start the applet *temporary workaround*
Solution Enjoy!: copy and paste this as root from console echo mkxauth -c >> /etc/X11/xinit/xinitrc.d/localuser.sh
This is a workaround and not a solution. If there is something wrong with the latest slim update (or elsewhere), we need to track this down properly instead of working around the problem. Making changes in global config files that later need to be reverted are particularly bad.
Actually i doubt any reversion should be necessary, it is in the correct init script as far as commands do. I've asked for a response from QA, if anything they should consider making it a permanent fix/patch as such.
However seeing as there are doubts about the solution posted above i have left it as text rather than make a script to modify the localuser init .sh
Hi! I downgraded from slim.i686 0:1.3.1-9.fc12 to slim.i686 0:1.3.1-8.fc12. And the gmixer started normal this system start! Unfortunately, openbox crashes now. Abrt says it is a duplicate of 555141. I sent backtrace and coredump. Until that downgrade every start of my system the gmixer crashed, but abrt counts 10times 551305 and 11times this bug. Possibly 551305 is a duplicate of this bug. I will perform some reboots to find out whether it was luck or slim-update caused the problem.
The openbox crash did not happen again it is likely not related to the slim version.
Adi, you are right, we should talk about your suggestion with QA first. Julianm thanks for your feedback. Reassigning to slim and adjusting the bug summary.
Sorry, accidentally hit the return key.
1.3.1-8.fc12 and 1.3.1-9.fc12 differ only by a couple of patches (coming from Debian) which fix #544024 . Downgrading SLIM is not an option. I had slim-1.3.1-9.fc12 installed for a while but I never had this problem. I have the LXDE spin installed on a EEE and it's working without problems.
(In reply to comment #19) > 1.3.1-8.fc12 and 1.3.1-9.fc12 differ only by a couple of patches (coming from > Debian) which fix #544024 . Right, and as you can see these also heavily affect the creation of Xauthority, but I have no idea what exactly goes wrong there. > Downgrading SLIM is not an option. Of course not, it was only for testing. > I had slim-1.3.1-9.fc12 installed for a while but I never had this problem. Did you check if you actually had an /.Xauthority? BTW: Are you trying to say that you are not using SLIM? IMO maintainers should actively use their own packages. > have the LXDE spin installed on a EEE and it's working without problems. Including all updates? For me this is reproducible: If I upgrade and restart slim, I have no Xauthority, if I downgrade again and restart it's back.
*** Bug 560212 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > (In reply to comment #19) > > 1.3.1-8.fc12 and 1.3.1-9.fc12 differ only by a couple of patches (coming from > > Debian) which fix #544024 . > > Right, and as you can see these also heavily affect the creation of Xauthority, > but I have no idea what exactly goes wrong there. Me too. > > > Downgrading SLIM is not an option. > > Of course not, it was only for testing. > > > I had slim-1.3.1-9.fc12 installed for a while but I never had this problem. > > Did you check if you actually had an /.Xauthority? > BTW: Are you trying to say that you are not using SLIM? IMO maintainers should > actively use their own packages. I forgot to add "on this system". JFYI: I used slim before and after the patch on my workstation, although with XMonad which means no weird pythonic systray applets. Since I switched back to a full Desktop Environment (with its own display manager) Slim now runs only on the EEE (with the LXDE spin). So, yes, I'm still using it (not directly since my mom uses that machine, but she's quite susceptible to malfunctioning things). Please don't jump to conclusions without knowing the full picture, it's not polite behaviour. > > > have the LXDE spin installed on a EEE and it's working without problems. > > Including all updates? [snip] Not all updates but slim-1.3.1-9 is installed. Anyway, I can reproduce it now (I didn't run it with '-d', nor I even noticed if it crashed at startup-time since abrt never ever gave me a warning -- weird --). I will double-check the Debian patch and, eventually, work with gdb tomorrow.
I decided to revert some parts of Debian's patch. I quickly tested it on the EEE and looks like slim is working now.
slim-1.3.1-10.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/slim-1.3.1-10.fc11
slim-1.3.1-10.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/slim-1.3.1-10.fc12
Please note that this is a temporary fix since it partially reverts the security fix for CVE-2009-1756 .
Does this mean that it makes session hijacking possible again? IMO this is worse then a crashing gmixer.
Nope, mcookie generation is still properly randomized but instead of using popen() to call xauth, I switched it back to call system() instead. Anyway, I am not going to push this update to stable util I properly fix this issue. There *is* something broken with Debian's approach since the .Xauthority file isn't created and this needs a more in-depth look (and I am not an X11 expert).
Another alternative is to *temporarily* patch gmixer and don't make it look for ~/.Xauthority until I sort this thing out.
Created attachment 388611 [details] patch to ignore non-existens (BEWARE don't know what happens else...) (In reply to comment #29) > Another alternative is to *temporarily* patch gmixer and don't make it look for > ~/.Xauthority until I sort this thing out. gmixer does not explicitely look for the file. It's python-zlib, that crashes. I have a patch, that silently ignores the non-existence of the file and anything *should* run, but I know too less about python-zlib, to see what exactly happens after not-crashing. If you feel crazy enought, test it ;)
Sorry, python-xlib not zlib.
*** Bug 563747 has been marked as a duplicate of this bug. ***
Comment ----- This problem presents itself at start-up. Every start up.
*** Bug 603910 has been marked as a duplicate of this bug. ***
Package: gmixer-1.3-15.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. Boot up 2. 3.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I can't reproduce this issue on regular Fedora 13 installation, slim-0:1.3.1-10.fc13.x86_64. I'll try the LXDE spin. Yorvyk, what Slim version are you using?
(In reply to comment #37) > I can't reproduce this issue on regular Fedora 13 installation, > slim-0:1.3.1-10.fc13.x86_64. > I'll try the LXDE spin. > > Yorvyk, > what Slim version are you using? Name : slim Arch : i686 Version : 1.3.2 Release : 1.fc13
(In reply to comment #38) Just updated to:- Name : slim Arch : i686 Version : 1.3.2 Release : 2.fc13 Still get the same problem on boot.
I just asked upstream to help on this: https://sourceforge.net/tracker/?func=detail&aid=3057898&group_id=10350&atid=110350 I'm unsure, if it is possible to set reasonable default values, when there is no Xauthority or do something different in its absence...
Upstream made a suggestion, that might fix this, so hopefully that works. Yorvyk or anyone else, who can reproduce this: Could you please try version 0.15-0.3.rc1.fc13 from koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2444246
(In reply to comment #41) > Upstream made a suggestion, that might fix this, so hopefully that works. > > Yorvyk or anyone else, who can reproduce this: > Could you please try version 0.15-0.3.rc1.fc13 from koji: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2444246 > This appears to have solved the problem.
(In reply to comment #42) > (In reply to comment #41) > > Could you please try version 0.15-0.3.rc1.fc13 from koji: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2444246 > > > This appears to have solved the problem. Great, then this can be fixed in python-xlib. Commited to git and waiting for maintainer review: http://pkgs.fedoraproject.org/gitweb/?p=python-xlib.git;a=commitdiff;h=dc280988c0e3456afa83a90cc749ac36fda17152
I'm cool with the patch. What do you need from me? If you have the privs to do a build go for it. -jef
(In reply to comment #44) > I'm cool with the patch. What do you need from me? If you have the privs to do > a build go for it. That was all I needed. Update on the way.
python-xlib-0.15-0.3.rc1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/python-xlib-0.15-0.3.rc1.fc14
python-xlib-0.15-0.3.rc1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/python-xlib-0.15-0.3.rc1.fc13
python-xlib-0.15-0.3.rc1.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/python-xlib-0.15-0.3.rc1.fc12
python-xlib-0.15-0.3.rc1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update python-xlib'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/python-xlib-0.15-0.3.rc1.fc12
python-xlib-0.15-0.3.rc1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
python-xlib-0.15-0.3.rc1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
python-xlib-0.15-0.3.rc1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.