I have a Wheezy netinstall with openbox, and have this issue I hope someone can help me with:
+ boot to tty, log in (no Window Manager is running)
+ close the laptop lid, the machine suspends OK
Does not work:
+ run startx (openbox)
+ close the laptop lid, suspend does not trigger
When I open the lid again I get the notification: "power manager, not authorized".
+ Enabled verbose debug messages for pm-utils  and no errors are logged to /var/log/pm-suspend.log, darn.
+ Checked that I don't have HAL installed, as it interferes with pm-utils (per same the link ).
The post  indicates that authorization is handled via consolekit and session manager, but the "exec ck-launch-session" line answer in that post did not help.
When I run "exec ck-launch-session openbox-session" it drops me back to a login prompt (openbox-session reports that the $DISPLAY environment variable is unset even though it is)
~$ echo $DISPLAY :0.0
The only way I can suspend at the moment is with "sudo pm-suspend", and that gets tedious quickly. I could add myself to sudoers without password for pm-suspend, but I would prefer to get this working how it is intended (TM). Any ideas?
Signed, perplexed monkey
Hey guys, I've finally been able to read up on this thread @woodape keeps telling me about. After reading through the thread and updating my understanding of the program a bit, I think I can help contribute now haha.
I'm liking the direction this is taking and am keen to play with the modified code 8)
To make things easier I am going to update the original post to point to the GitHub repository woodape set up, to make getting new versions easier O:)
Edit: had a quick look at the new look of this menu and, oh my hat, great work!
Updated the original post with the latest from woodape (Load/Kill menus).
I am enjoying how the scope and ideas for this is changing so rapidly, this is fun
Edit: No - the Load/Kill toggling in the menus replace the disabled menu items (with batteries included IMO)
Oh my hat I wish I had a whole day to play around with this - will be back in a day or two O:)
Wow this is amazing... everyone seems to dig this pipemenu
The Load/Kill toggling is much nicer than the sub-menus, kudos @woodape for adding all of that! It is working well here. (Noted the rename to .conkyrc - thumbs up)
It got a bit confusing for a moment because I think we all had a different idea of how we organise our conky configs. This new mechanism of Loading configs satisfies both use-cases (single or combined running configs). Wonderful!
I am excited to go through the code and learn what has changed, still out of town and doubt I will get a moment today, but looking forward to it! I will update the OP with this code above, and for learning sake: mapping string formats by key-value pairs is available for Python 2 and up
What an interesting idea, thank you Sector11 - adding conky's to the list of running instances for combine layouts? hmmm, I will think on this while I drive home from work...
In the mean time I am imagining adding two menu items, to kill all conky's and another toggle-option that determines if running instances are killed first when a new conky is run.
This way you can click through multiple configs in any order to combine layouts (but would require some extra logic to preserve any session.log entries)
Conky Switcher --------------> Config 1 Config 2 Config 3 -------- kill all [x] Combine Mode
I will see if I can steal some time this weekend to play around with this idea - will be out of my home-town until Sunday. O:)
Solarized theme for rxvt
! -------------------------------------- ! Solarized URxvt colors ! http://ethanschoonover.com/solarized ! $base03: #002b36; ! $base02: #073642; ! $base01: #586e75; ! $base00: #657b83; ! $base0: #839496; ! $base1: #93a1a1; ! $base2: #eee8d5; ! $base3: #fdf6e3; ! $yellow: #b58900; ! $orange: #cb4b16; ! $red: #dc322f; ! $magenta: #d33682; ! $violet: #6c71c4; ! $blue: #268bd2; ! $cyan: #2aa198; ! $green: #859900; URxvt.background: #002b36 URxvt.foreground: #839496 URxvt.colorBD: #93a1a1 URxvt.cursorColor: #93a1a1 ! URxvt.throughColor: #8080f0 URxvt.highlightColor: #eee8d5 ! Black (not tango) + DarkGrey *color0: #000000 *color8: #657b83 ! DarkRed + Red *color1: #dc322f *color9: #dc322f ! DarkGreen + Green *color2: #859900 *color10: #859900 ! DarkYellow + Yellow *color3: #b58900 *color11: #b58900 ! DarkBlue + Blue *color4: #268bd2 *color12: #268bd2 ! DarkMagenta + Magenta *color5: #d33682 *color13: #d33682 !DarkCyan + Cyan (both not tango) *color6: #2aa198 *color14: #2aa198 ! LightGrey + White *color7: #eee8d5 *color15: #fdf6e3 ! --------------------------------------
As I understand distributed workflow, you Fork one of the Bunsen Lab repositories, commit your changes to your Fork and create a Pull Request. Your changes can then be looked over and merged into the BL repository. It is a good practice to make changes in branches too.
The alternative is if you are given write permission to the BL repo and commit there directly. This is an older workflow dating back to the days of centralized source control, and does tend to trip one up and people can step on each other's changes. Of course this is at the discretion of the repo owners
Still running CrunchBang but playing with ideas for BunsenLabs.
Nice touch on the mono-spaced switcher font and border-less terminal. A very grabbing desktop
I found an hdd that is at least 10 years old. A 60gb ide drive from when 60 gb was a "good" size. It came with a pentium 3 box (my first "real" computer). The drive was mounted with an ide-usb adaptor and a bunch of relics found. Amognst them were my dog and an Ubuntu 7.04 iso.
(and I decided to go full bloat on my arch and got cinnamon to remind me of the good'ol gnome2 days)
edit: Here's the drive, and some dust.
edit2: It's very, very, noisy.
It's fun finding these digital time-capsules isn't it As a side-note and superfluous fact, my first real pc was a 486 DX2 ]:D
I thought this was pretty clever, and I just had to share the fun
BABY(1) BABY(1) NAME baby -- create new process from two parents SYNOPSIS baby -sex [m|f] [-name name] DESCRIPTION baby is initiated when one parent process polls another server process through a socket connection in the BSD version or through pipes in the System V implementation. baby runs at low priority for approximately forty weeks and then terminates with a heavy system load. Most systems require constant monitoring when baby reaches its final stages of exe- cution. Older implementations of baby did not require both initiating processes to be present at the time of completion. In those versions the initiating process which was not present was awakened and notified of the results upon completion. It has since been determined that the presence of both parent processes result in a generally lower system load at com- pletion, and thus current versions of baby expect both parent processes to be active dur- ing the final stages. Successful completion of baby results in the creation and naming of a new process. Parent processes then broadcast messages to all other processes, local and remote, informing them of their new status. OPTIONS -sex define the gender of the created process -name assign the name name to the new process EXAMPLES baby -sex f -name Jacqueline completed successfully on July 9, 1992 at 9:11pm. Jacqueline's vital statistics: 8 pounds 3 oz, 20 inches, long dark hair. The parent process, Kim Dunbar, is reportedly doing fine. SEE ALSO cigar(6), dump(5), cry(3). BUGS Despite its complexity, baby only knows one signal, SIGCHLD, (or SIGCLD in the System V implementation), which it uses to contact the parent processes. One or both parent pro- cesses must then inspect the baby process to determine the cause of the signal. The sleep(1) command may not work as expected on either parent process for some time afterward, as each new instance of baby sends intermittent signals to the parent processes which must be handled by the parents immediately. A baby process will frequently dump core, requiring either or both parent processes to clean up after it. Despite the reams of available documentation on invoking and maintaining baby, most parent processes are overwhelmed. AUTHORS From a man page by Joe Beck, <firstname.lastname@example.org>.