I got from Puppy Linux forum and when used with Puppy precise 5.7.1 everything works except the shutdown button . Anyone have any idea where I would look to fix this?
There's a menu entry to "exit" fluxbox which will, well, exit fluxbox and you'll either return to the desktop manager (loginscreen) or a virtual terminal (linux textshell) or be left with an unmanaged desktop (if you started fluxbox from eg. an xterm)
I'm not aware that fluxbox would abstract a system halt/poweroff (which also differs depending on whether you're running sysV or systemd)
=> screenshot?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not experienced at all in what you discuss except to say that if I use the exit option on Fluxboxe's menu the computer drops to a terminal from which I can enter "poweroff" and it will shut off normally . However if I use Puppy's menu I get a choice of 6 buttons ,5 of which work in Fluxbox but the "shutoff" does nothing now in Fluxbox but works fine in other window managers .
I think what's happening is probably the wrong command is being sent (perhaps exit instead of poweroff) .Where in the code might I find what command is being sent so that I may change it please or at least start investigating it?
Last edit: Ty Tower 2016-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However if I use Puppy's menu
Then why do you report it here???
Ie. what makes you believe it would be a bug in fluxbox if the gui provided by puppy linux doesn't shut down that distro?
Or that fluxbox devs could tell you about internals of puppy linux?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Come on now , stop trying to shirk the issue and protect the distro . I have made it clear what is happening and what I seek .
Instead of trying to avoid the issue, how about you guide me to the section of the code that controls this .Simple enough request isn't it ?.
The puppy menu without Fluxbox works fine and needs no fixing
The puppy menu with JWM for instance works fine and needs no fixing
The puppy menu with Fluxbox does not work and needs fixing
Last edit: Ty Tower 2016-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, you have not. Not the least. That's the problem, okey?
I don't even know what "button" you're talking about and there's no code to poweroff the system in fluxbox.
I'd say puppy tries to kill the WM and fails, thus stalls the shutdown.
Could be because of bug #713 ie. the missing WM_Sn selection, but that's absolutely not sure.
Could just as much be that puppy tries to access JWM -that's unknown.
=> It's absolutely required to know what puppy tries to do in order to say why it fails.
There's no "code section in fluxbox" which you could fix, because fluxbox does not control the system poweroff - there's no such protocol and it's not "normal" either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
// prepares fluxbox for a shutdown. when x_wants_down is != 0 we assume that
// the xserver is about to shutdown or is in the midst of shutting down
// already. trying to cleanup over a shaky xserver connection is pointless and
// might lead to hangups.
void Fluxbox::shutdown(int x_wants_down) {
if (m_state.shutdown)
return;
And this in main.cc
case SIGHUP:
// xinit sends HUP when it wants to go down. there is no point in
// restoring anything in the screens / workspaces, the connection
// to the xserver might drop any moment
if (fluxbox.get()) { fluxbox->shutdown(1); }
break;
You are having me on and trying to mislead me . Clearly if two window managers (JWM and ICE) can get it right and yours does not then the problem is in yours.
How about you take the time to look before you repeatedly send useless posts back to me .
If its too hard for you pass it on . Don't feed this garbage back
Last edit: Ty Tower 2016-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest to file a bug against the puppy menu to work with fluxbox. If the puppy menu developer then figures unexpected behavior or missing features in fluxbox, he should certainly file a bug on this. Currently you're just poking around in the dark and no, I can't help you here at all.
Yes well quite rightly so as you are offering no help whatever and refuse to look.
This clearly is not a bug in Puppy. All the other window managers work well with Puppy so that does not cut it.
You close the issue if you want . You will be denying a possible fix to the real developers of Fluxbox and it is a shame that you are representing them here . However that is there choice and again I suggest you refer this to them.
I have filed my disgust on the opinion page and will leave it at that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Believe it or not, I'm actually trying to help you, but in order to know what fails, one better starts at teh beginning, ie. "what does puppy yell on this occasion" - any other approach is voodo.
Identify problem
Identify cause
Ficure solution
You're trying to skip step two based on a false assuption that the windowmanager would power off the system. If any, the Desktop manager (the thing that creates the login screen) would do. But again: start at puppy: what does it try to do? Then it's time to look at how fluxbox would react and why it would fail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nah Rubbish
Tossed it in the bin anyway . When I click on a window heading to choose an option the "kill" option which stops the process has gone in Fluxbox . Its there in both other window manager options .
Pity , I rather liked the smaller darker screens but it just does not work properly as yet.
Don't bother posting afgain . I'm gone!
Believe it or not, I'm actually trying to help you, but in order to know what fails, one better starts at teh beginning, ie. "what does puppy yell on this occasion" - any other approach is voodo.
Identify problem
Identify cause
Ficure solution
You're trying to skip step two based on a false assuption that the windowmanager would power off the system. If any, the Desktop manager (the thing that creates the login screen) would do. But again: start at puppy: what does it try to do? Then it's time to look at how fluxbox would react and why it would fail.
Status: pending-invalid Group: v1.3.7 Created: Tue Jul 05, 2016 11:00 PM UTC by Ty Tower Last Updated: Thu Jul 07, 2016 11:48 AM UTC Owner: nobody
I got from Puppy Linux forum and when used with Puppy precise 5.7.1 everything works except the shutdown button . Anyone have any idea where I would look to fix this?
This is about fluxbox exit/restarting w/o letting the session go and/or unmapping windows etc., ie. the "restart" item in the fluxbox menu and or the restart command via fluxbox-remote as well as "don't try to talk to the x server while that is currently going away.
This will end fluxbox and nothing else. The term "shutdown" in the code is maybe misleading, but it does not refer to a system poweroff or similar.
Iff you (or xinit) SIGHUP fluxbox, it will terminate w/o doing some cleanup - that's it.
I suggest to file a bug against the puppy menu to work with fluxbox. If the puppy menu developer then figures unexpected behavior or missing features in fluxbox, he should certainly file a bug on this. Currently you're just poking around in the dark and no, I can't help you here at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is now as official as it gets, i hope you will accept the answer, even if you don't like it but sometimes there is "reality" and sometimes there is "whishful thinking" and both do not always match.
Yes well quite rightly so as you are offering no help whatever and refuse to look.
thomas took time to read your issue, understand your issue, and pointed you to the right place where the actual problem is: the text file, which gets parsed to the menu you are clicking it, is not generated by fluxbox. $someone / $somescript is generating a .fluxbox/menu file which contains a line which reads something like this [exec] (shutdown) {xyz}. fluxbox will gladly show this entry as shutdown to the user, but fluxbox is not responsible for what the xyz program actually does.
whatever fluxbox is calling it's internal variables (like "godmode" or "shutdown" or "getmoney") does not matter: fluxbox is not responsible for what the program xyz does when it is triggered by a menu-entry labeled as shutdown. also, it does not matter if all the other window-managers or desktop-environments offered by puppy-linux "work": someone misconfigured the shutdown labeled menu-entry. again: this is nothing anyone here at fluxbox OR a helping hand can fix. only those creating the menu can fix this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The wmpoweroff script (checked slacko) tries (after killing the shell) to SIGKILL the pgrep for the current window manager which is supposed to be stored in /etc/windowmanager and afterwards hardcodes jwm, openbox and icewm for killing (the script is btw. horrible and wonky and should desperately be rewritten. Also SIGKILL should certainly NOT be the initial signal)
Given the linked thread, it does not seem as if fluxbox is already fully supported and rather hand-started (thus omitting the generic kill call for /etc/windowmanager very likey being empty)
This is a matter of downstream configuration (and I'm not aware that major WMs would expose the feature by default - they typically offer it on failing NEWTM client pings)
And on a personal comment:
I usually refrain from commenting on bug reporting users. I see them as - very welcome, but pure - indication of problems and not necessarily as useful assistance (while that's of course great), but the behavior of this bugs reporter is about the worst thing I've ever encountered in 20 years.
No idea, no skills, not the least intention - let alone any movement - to cooperate but an insulting and arrogant tone (which I generally respect in case the user is insightfully right) repeating his nonsense claims.
I personally hope that he will never bother to try using fluxbox or anything else that I work on and I'd quite frankly like to see him blacklisted for moderation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
He hid this post as well he should . I made the comment that the programmers of this program do not fix issues but rather protect their work with a claim that it could not possibly be wrong . Well it is wrong as he admits above . I know german arrogance when I see it and if you are not German or Austrian or something very close to it then you descend from one . Fix the bloody problem MORON
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may know "german arrogance" but apparently have severe defects regarding the english language.
My last post confirmed exactly my initial and all further assumptions.
The wmpoweroff script as used by puppy linux tries to kill a series of hardcoded window manager
processes. Fluxbox is not among them. Therefore it's absolutely no wonder that the wmpoweroff script is ineffective for it, but works on others ("stunningly" those listed)
Either alter the script (which is NOT provided by fluxbox, but by puppy linux) or ensure to "echo fluxbox > /etc/windowmanager" (which does NOT refer to soem WM protocol, but is a setting of the distribution) so that puppy knows what to kill.
This has nothing to do with fluxbox. Neither fluxbox nor any other windowmanager powers down the system. This is entirely a "bug" in the wmpoweroff script (which, maybe I need to repeat this, is NOT provided by fluxbox), simply not supporting "fluxbox" as string.
Nothing, NOT A SINGLE THING, you posted in this entire report is even remotely based on facts. NOTHING.
Please use MS Windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I see someone finally looked into exactly what was causing the problem . Or so they say . So stupid is a label with two faces . I doubt the explanation given is in fact correct so I won't be wasting my time checking it . Fluxbox should be called "Flushbox" Throw it down the thunderbox.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
since .pet files are just tarballs + a md5-checksum, i took the freedom to extract both .pet files and compare the content. let's see the attached picture: the only file that got changed was the Shutdown file. all other files kept the same (except the .spec file describing the content of the .pet file)
http://murga-linux.com/puppy/viewtopic.php?p=911167#911167
What shutdown button?
There's a menu entry to "exit" fluxbox which will, well, exit fluxbox and you'll either return to the desktop manager (loginscreen) or a virtual terminal (linux textshell) or be left with an unmanaged desktop (if you started fluxbox from eg. an xterm)
I'm not aware that fluxbox would abstract a system halt/poweroff (which also differs depending on whether you're running sysV or systemd)
=> screenshot?
I am not experienced at all in what you discuss except to say that if I use the exit option on Fluxboxe's menu the computer drops to a terminal from which I can enter "poweroff" and it will shut off normally . However if I use Puppy's menu I get a choice of 6 buttons ,5 of which work in Fluxbox but the "shutoff" does nothing now in Fluxbox but works fine in other window managers .
I think what's happening is probably the wrong command is being sent (perhaps exit instead of poweroff) .Where in the code might I find what command is being sent so that I may change it please or at least start investigating it?
Last edit: Ty Tower 2016-07-07
Come on now , stop trying to shirk the issue and protect the distro . I have made it clear what is happening and what I seek .
Instead of trying to avoid the issue, how about you guide me to the section of the code that controls this .Simple enough request isn't it ?.
The puppy menu without Fluxbox works fine and needs no fixing
The puppy menu with JWM for instance works fine and needs no fixing
The puppy menu with Fluxbox does not work and needs fixing
Last edit: Ty Tower 2016-07-07
No, you have not. Not the least. That's the problem, okey?
I don't even know what "button" you're talking about and there's no code to poweroff the system in fluxbox.
I'd say puppy tries to kill the WM and fails, thus stalls the shutdown.
Could be because of bug #713 ie. the missing WM_Sn selection, but that's absolutely not sure.
Could just as much be that puppy tries to access JWM -that's unknown.
=> It's absolutely required to know what puppy tries to do in order to say why it fails.
There's no "code section in fluxbox" which you could fix, because fluxbox does not control the system poweroff - there's no such protocol and it's not "normal" either.
And I suppose this in fluxbox.cc has nothing to do with it?
/// restarts fluxbox
void Fluxbox::restart(const char *prog) {
shutdown(); m_state.restarting = true; if (prog && *prog != '\0') { m_restart_argument = prog; }}
// prepares fluxbox for a shutdown. when x_wants_down is != 0 we assume that
// the xserver is about to shutdown or is in the midst of shutting down
// already. trying to cleanup over a shaky xserver connection is pointless and
// might lead to hangups.
void Fluxbox::shutdown(int x_wants_down) {
if (m_state.shutdown)
return;
And this in main.cc
case SIGHUP:
// xinit sends HUP when it wants to go down. there is no point in
// restoring anything in the screens / workspaces, the connection
// to the xserver might drop any moment
if (fluxbox.get()) { fluxbox->shutdown(1); }
break;
You are having me on and trying to mislead me . Clearly if two window managers (JWM and ICE) can get it right and yours does not then the problem is in yours.
How about you take the time to look before you repeatedly send useless posts back to me .
If its too hard for you pass it on . Don't feed this garbage back
Last edit: Ty Tower 2016-07-07
On Thu, 07 Jul 2016 11:48:41 +0000
"Thomas Luebking" baghira-style@users.sf.net wrote:
--
yahoo tytower@yahoo.com
Yes well quite rightly so as you are offering no help whatever and refuse to look.
This clearly is not a bug in Puppy. All the other window managers work well with Puppy so that does not cut it.
You close the issue if you want . You will be denying a possible fix to the real developers of Fluxbox and it is a shame that you are representing them here . However that is there choice and again I suggest you refer this to them.
I have filed my disgust on the opinion page and will leave it at that.
Believe it or not, I'm actually trying to help you, but in order to know what fails, one better starts at teh beginning, ie. "what does puppy yell on this occasion" - any other approach is voodo.
You're trying to skip step two based on a false assuption that the windowmanager would power off the system. If any, the Desktop manager (the thing that creates the login screen) would do. But again: start at puppy: what does it try to do? Then it's time to look at how fluxbox would react and why it would fail.
Nah Rubbish
Tossed it in the bin anyway . When I click on a window heading to choose an option the "kill" option which stops the process has gone in Fluxbox . Its there in both other window manager options .
Pity , I rather liked the smaller darker screens but it just does not work properly as yet.
Don't bother posting afgain . I'm gone!
On Fri, 08 Jul 2016 11:34:26 +0000
"Thomas Luebking" baghira-style@users.sf.net wrote:
--
Ty Tower tytower@yahoo.com
Related
Bugs:
#1147seems puppy uses a script "wmpoweroff" for this job. I suggest you attach it here, since it shall tell what puppy is trying to do.
This is about fluxbox exit/restarting w/o letting the session go and/or unmapping windows etc., ie. the "restart" item in the fluxbox menu and or the restart command via fluxbox-remote as well as "don't try to talk to the x server while that is currently going away.
This will end fluxbox and nothing else. The term "shutdown" in the code is maybe misleading, but it does not refer to a system poweroff or similar.
Iff you (or xinit) SIGHUP fluxbox, it will terminate w/o doing some cleanup - that's it.
I suggest to file a bug against the puppy menu to work with fluxbox. If the puppy menu developer then figures unexpected behavior or missing features in fluxbox, he should certainly file a bug on this. Currently you're just poking around in the dark and no, I can't help you here at all.
this is now as official as it gets, i hope you will accept the answer, even if you don't like it but sometimes there is "reality" and sometimes there is "whishful thinking" and both do not always match.
thomas took time to read your issue, understand your issue, and pointed you to the right place where the actual problem is: the text file, which gets parsed to the menu you are clicking it, is not generated by fluxbox. $someone / $somescript is generating a .fluxbox/menu file which contains a line which reads something like this
[exec] (shutdown) {xyz}. fluxbox will gladly show this entry asshutdownto the user, but fluxbox is not responsible for what thexyzprogram actually does.whatever fluxbox is calling it's internal variables (like "godmode" or "shutdown" or "getmoney") does not matter: fluxbox is not responsible for what the program
xyzdoes when it is triggered by a menu-entry labeled asshutdown. also, it does not matter if all the other window-managers or desktop-environments offered by puppy-linux "work": someone misconfigured theshutdownlabeled menu-entry. again: this is nothing anyone here at fluxbox OR a helping hand can fix. only those creating the menu can fix this.Addendum:
The wmpoweroff script (checked slacko) tries (after killing the shell) to SIGKILL the pgrep for the current window manager which is supposed to be stored in /etc/windowmanager and afterwards hardcodes jwm, openbox and icewm for killing (the script is btw. horrible and wonky and should desperately be rewritten. Also SIGKILL should certainly NOT be the initial signal)
Given the linked thread, it does not seem as if fluxbox is already fully supported and rather hand-started (thus omitting the generic kill call for /etc/windowmanager very likey being empty)
As a second note:
fluxbox "of course" offers a function to kill the current window, see
http://fluxbox.org/help/man-fluxbox-keys.php
as well as the ability to add such to the window menu, see
http://fluxbox.org/help/man-fluxbox-menu.php
This is a matter of downstream configuration (and I'm not aware that major WMs would expose the feature by default - they typically offer it on failing NEWTM client pings)
And on a personal comment:
I usually refrain from commenting on bug reporting users. I see them as - very welcome, but pure - indication of problems and not necessarily as useful assistance (while that's of course great), but the behavior of this bugs reporter is about the worst thing I've ever encountered in 20 years.
No idea, no skills, not the least intention - let alone any movement - to cooperate but an insulting and arrogant tone (which I generally respect in case the user is insightfully right) repeating his nonsense claims.
I personally hope that he will never bother to try using fluxbox or anything else that I work on and I'd quite frankly like to see him blacklisted for moderation.
He hid this post as well he should . I made the comment that the programmers of this program do not fix issues but rather protect their work with a claim that it could not possibly be wrong . Well it is wrong as he admits above . I know german arrogance when I see it and if you are not German or Austrian or something very close to it then you descend from one . Fix the bloody problem MORON
good luck with that attitude in life.
How stupid exactly are you?
You may know "german arrogance" but apparently have severe defects regarding the english language.
My last post confirmed exactly my initial and all further assumptions.
The wmpoweroff script as used by puppy linux tries to kill a series of hardcoded window manager
processes. Fluxbox is not among them. Therefore it's absolutely no wonder that the wmpoweroff script is ineffective for it, but works on others ("stunningly" those listed)
Either alter the script (which is NOT provided by fluxbox, but by puppy linux) or ensure to "echo fluxbox > /etc/windowmanager" (which does NOT refer to soem WM protocol, but is a setting of the distribution) so that puppy knows what to kill.
This has nothing to do with fluxbox. Neither fluxbox nor any other windowmanager powers down the system. This is entirely a "bug" in the wmpoweroff script (which, maybe I need to repeat this, is NOT provided by fluxbox), simply not supporting "fluxbox" as string.
Nothing, NOT A SINGLE THING, you posted in this entire report is even remotely based on facts. NOTHING.
Please use MS Windows.
Well I see someone finally looked into exactly what was causing the problem . Or so they say . So stupid is a label with two faces . I doubt the explanation given is in fact correct so I won't be wasting my time checking it . Fluxbox should be called "Flushbox" Throw it down the thunderbox.
so, what do we have here:
the version of fluxbox-1.3.7 back from 2016-06: http://smokey01.com/Oldyeller/pets/fluxbox-1.3.7-i486.pet
and the new version with some fixes in it: http://smokey01.com/Oldyeller/fluxbox-1.3.7-i486.pet
since .pet files are just tarballs + a md5-checksum, i took the freedom to extract both .pet files and compare the content. let's see the attached picture: the only file that got changed was the Shutdown file. all other files kept the same (except the .spec file describing the content of the .pet file)
so, lets see about the fix:
this file is not part of what fluxbox provides, check here http://git.fluxbox.org/fluxbox.git/tree/
and now, for good, just go away and stay there. far away from a keyboard, i hope.