| Summary: | Xcleints don't get started when using fvwm | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wolfgang Denk <wd> | ||||||
| Component: | switchdesk | Assignee: | Than Ngo <than> | ||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 21 | CC: | hdegoede, than | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-12-02 02:35:34 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
The problem is still present in FC17. The problem is still present in FC18. This bug is present since F15, even though I submitted a patch that fixes it. What exactly is necessary that anybody picks that up and applies it? The quality of Fedora is degrading from release to release - with F18 it has reached the limit of being unusable. The fact that nobody cares at all about bug reports is extremely frustrating. Still present in F19. OK, so this bug is not TWO YEARS and FIVE RELEASES old, and I even provided a patch that fixes it. HELLO? IS ANYBODY LISTENING?!?!?!?!?! We are approaching 4 years lifetime of a bug where a patch has been submitted. Shame on Fedora QA! Hi Wolfgang, sorry for delay! i'm now working on it. i have tried to reproduce this issue on my local machine with following steps: 1. switchdesk fvwm 2. start X server with startx from text console. FVWM session starts fine for me. I cannot reproduce your problem. Could you please provide more infos? how did you start Xserver? Thanks (In reply to Ngo Than from comment #7) > Hi Wolfgang, sorry for delay! i'm now working on it. Wonderful. > i have tried to reproduce this issue on my local machine with following > steps: > > 1. switchdesk fvwm > 2. start X server with startx from text console. Well, this is definitely not the standard way to start a graphical login under Fedora... > FVWM session starts fine for me. I cannot reproduce your problem. > > > Could you please provide more infos? how did you start Xserver? Log out completely from the system. At the GDM login screen, select FVWM session instead of the standard Gnome session, then provide your login credentials. i will test it next week if i can reproduce this issue. thanks for your infos again. Hi Wolfgang, I've tried to reproduce your problem, but things work fine for me. Can you provide some more details please. What I've done is: 1) install fvwm 2) restart gdm (which graphical login manager are you using ?) 3) Select fvwm session, login, get fvwm Looking at your patch the problem seems to be that you have a .Xclients-* file which you want to get executed instead of just executing the /usr/bin/fvwm binary, is that correct ? And how does switchdesk fit into the whole picture ? Now a days most graphical login managers just look for available sessions in /usr/share/xsession/*.desktop and then execute the one chosen by the user during login. Regards, Hans Hi Again, Looking a bit deeper it seems that the changes which you add to Xclients.fvwm are already part of Xclients.toplevel and that should get installed as ~/.Xclients, where as Xclients.fvwm should get installed as ~/.Xclients-default making Xclients.fvwm execute ~/.Xclients-default would lead to a loop where ~/.Xclients-default keeps excuting itself. So your patch does not seem to be correct. Regards, Hans (In reply to Hans de Goede from comment #10) Dear Hans, thanks for looking intot his... > What I've done is: > > 1) install fvwm > 2) restart gdm (which graphical login manager are you using ?) > 3) Select fvwm session, login, get fvwm I'm running a standard installation, so yes, it's gdm. > Looking at your patch the problem seems to be that you have a .Xclients-* > file which you want to get executed instead of just executing the > /usr/bin/fvwm binary, is that correct ? Correct. Just running fvwm is pretty boring, as it will start only the empty desktop environment. Traditionally I have all kinds of applications preconfigured in .Xclients-*, so they get automagically started when I log in. > And how does switchdesk fit into the whole picture ? Now a days most > graphical login managers just look for available sessions in > /usr/share/xsession/*.desktop and then execute the one chosen by the user > during login. I don't know. Yes, I do have a /usr/share/xsessions/fvwm.desktop on my system, but I don't see how that would help to start a user-configurable set of default applications on the FVWM desktop? Best regards, Wolfgang Denk (In reply to Hans de Goede from comment #11) Dear Hans, > Looking a bit deeper it seems that the changes which you add to > Xclients.fvwm are already part of Xclients.toplevel and that should get Obviously /usr/share/switchdesk/Xclients.toplevel does not come into play for some reason. Without my patch, only the commands in /usr/share/switchdesk/Xclients.fvwm are executed, no attempt is made to execute any ~/.Xclients-* file > installed as ~/.Xclients, where as Xclients.fvwm should get installed as > ~/.Xclients-default making Xclients.fvwm execute ~/.Xclients-default would > lead to a loop where ~/.Xclients-default keeps excuting itself. So your > patch does not seem to be correct. "Should get installed as ~/.Xclients" ... yes, this is the case: -> cmp /usr/share/switchdesk/Xclients.toplevel ~/.Xclients ; echo RC=$? RC=0 But this does not help anything. If my patch is not correct - then what is the right way to have the commands in ~/.Xclients-default (resp. ~/.Xclients-$HOSTNAME$DISPLAY) executed automatically when I login? Thanks in advance, Wolfgang Hi Wolfgang, How exactly are you starting fvwm. You are using a graphical login, correct ? Which display manager are you using ? And which session do you select inside the display manager ? And what is the contents of your ~/.Xclients (identical to Xclients.toplevel, right ?) and ~/.Xclients-default files ? Regards, Hans Created attachment 1085473 [details]
Shortened version of ~/.Xclients-default
(In reply to Hans de Goede from comment #14) Dear Hans, > How exactly are you starting fvwm. You are using a graphical login, correct? Correct. > Which display manager are you using ? I use gdm > And which session do you select inside the display manager ? I select "fvwm" > And what is the contents of your ~/.Xclients (identical to > Xclients.toplevel, right ?) Yes, they are identical. > and ~/.Xclients-default files ? See attachment - this is a shortened version only, but for the test it is sufficient to see xload and xclock starting. Thanks for your help! Wolfgang Hi, (In reply to Wolfgang Denk from comment #16) > (In reply to Hans de Goede from comment #14) > > Dear Hans, > > > How exactly are you starting fvwm. You are using a graphical login, correct? > > Correct. > > > Which display manager are you using ? > > I use gdm > > > And which session do you select inside the display manager ? > > I select "fvwm" > > > And what is the contents of your ~/.Xclients (identical to > > Xclients.toplevel, right ?) > > Yes, they are identical. > > > and ~/.Xclients-default files ? > > See attachment - this is a shortened version only, but for the test it > is sufficient to see xload and xclock starting. Ok, see this is different from the patched /usr/share/switchdesk/Xclients.fvwm you've attached to this bug, and switchdesk will install that as ~/.Xclients-default, so I think that this bug is no longer accurate. I think that at point in time switchdesk may have installed /usr/share/switchdesk/Xclients.fvwm as ~/.Xclients, causing your problem, but since it now installs /usr/share/switchdesk/Xclients.toplevel, and since that does exactly the thing you are adding in your patch I believe that everything works as it should now, and this bug can be closed. Regards, Hans (In reply to Hans de Goede from comment #17) Dear Hans, > Ok, see this is different from the patched > /usr/share/switchdesk/Xclients.fvwm you've attached to this bug, and > switchdesk will install that as ~/.Xclients-default, so I think that this > bug is no longer accurate. You write "switchdesk will install that as ~/.Xclients-default' - when would it do that? Do I have to manually run any special command for that? > I think that at point in time switchdesk may have installed > /usr/share/switchdesk/Xclients.fvwm as ~/.Xclients, causing your problem, > but since it now installs /usr/share/switchdesk/Xclients.toplevel, and > since that does exactly the thing you are adding in your patch I believe > that everything works as it should now, and this bug can be closed. Hm... I just installed fvwm and switchdesk on a virgin system, and after logging into the fvwm sessin I get just the plain standard fvwm menu, and there are no ~/.Xclients* files at all. Best regards, Wolfgang (In reply to Wolfgang Denk from comment #18) > Hm... I just installed fvwm and switchdesk on a virgin system, and > after logging into the fvwm sessin I get just the plain standard fvwm > menu, and there are no ~/.Xclients* files at all. Right, if you want to have ~/.Xclients files (instead of relying on the command defined in /usr/share/xsessions/fvwm.desktop) you need to run switchdesk once and select fvwm there. Regards, Hans This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 505475 [details] Patch to /usr/share/switchdesk/Xclients.fvwm Description of problem: When using switchdesk to start a fvwm session, the user defined Xclients don;t get started. Version-Release number of selected component (if applicable): switchdesk-4.0.9-8.fc15.2.noarch How reproducible: always (and has been so for several releases; sorry, I was too lazy to report it earlier) Steps to Reproduce: 1. Define some actions in your $HOME/.Xclients-default file 2. Start a new fvwm session Actual results: None of the defined Xclients gets started. Expected results: Actions defined in exec $HOME/.Xclients-$HOSTNAME$DISPLAY resp. in $HOME/.Xclients-default should be executed. Additional info: It seems that neither /usr/share/switchdesk/Xclients.fvwm nor any other file check for the existence of any .Xclients* files. The attached patch fixes the problem for me.