Re: [gentoo-user] recent trouble with wicd and systemd (non-global ctrl_ifname)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/13 04:26, Bruce Hill wrote: On Thu, Dec 12, 2013 at 08:05:14PM -0500, gottl...@nyu.edu wrote: thanks but I had done that and the command is simply /usr/sbin/wicd --no-daemon Perhaps relevant is Type=dbus Canek points out that wicd has had no new releases. Perhaps I should switch to networkmanager. I will try that tomorrow. Thank you both, allan Again, I haven't looked at the thread, and don't use systemd, either, but wicd needs to start in daemon. wicd - wireless connection daemon implementation This is probably related to how systemd handles services - instead of starting processes in daemon mode, it remains as a forground task on a detached session of systemd, so that anything that comes out through STDOUT/STDERR gets picked up and routed through journald. At a guess, anyway - i've only dabbled with it infrequently for work :) - -- wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKsGoEACgkQGYlqHeQRhkwLOAD/Uv5a4nYt33QrrKwMGm4qFyE+ 9CwGIDkoQMykvn1FlwIA/R4Q9KIlJ+QOpy5tBshN+1hhpDIZ4pvO5Oh48+t4sI/C =gYt+ -END PGP SIGNATURE-
Re: [gentoo-user] [gnome3 stable] Not as bad as I expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/13 12:10, walt wrote: I've been preparing for gnome3 for many months by running it in a virtualbox gentoo-guest machine. I missed a very important gnome3 feature by doing it that way :( The gnome-shell desktop has a 'gestures-based' feature, which exposes the favorites menu if you move the mouse pointer *very* quickly to the left upper corner of the screen. Who knew? Well, I didn't know until yesterday because virtualbox allows the mouse pointer to slide right off of the guest window onto my real desktop without notifying the guest machine, apparently. Anyway, the active-left-upper-corner feature saves me one annoying extra mouse-click when launching the apps I use all day long. That one extra mouse-click was a major gnome3 bug for me, but now it's just a virtual bug :) For us old gnome2 farts who don't know where to begin with gnome3, I'd suggest installing two gnome-shell extensions that may save you many hours of bewilderment: First, the settings center extension, which exposes several important sub-menus that are otherwise nearly impossible to find. Second, the system-monitor extension, which replaces the multiload gnome-panel applet that I can't live without. The gnome extension website offers several 'system-monitor' applets, but the one I'm now using is the one written by 'darkxst'. So happy :) I strongly suggest emerging the 'alacarte' and 'gnome-tweak-tool' packages from gnome-extra. They are not installed by default when emerging 'gnome', but I couldn't use gnome without them. Happy to answer any gnome3 questions if I can. Just for reference, I don't think the hot-corner issue a bug but a result of how it operates. If i'm not mistaken, the hot corner has to be activated by the mouse cursor actually hitting the corner. With the typical way the virtual machine works, with the mouse not actually 'entering' the environment, it's almost impossible to hit the corner properly as it transitions seamlessly between the guest and the host. Two ways to address this are to use the virtual machine in fullscreen mode (meaning that the corner really is the corner) or to have the virtual machine fully capture the mouse (requiring it to be released by use of the 'host' key (generally Right-CTRL). If you can, give it a try and let me know if it works :) - -- wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKsHNkACgkQGYlqHeQRhkyWyAD/c3+6+9nBp91dqs+2dSbfIBQI jb87kVZQDn6jwYhwDPEA/iBMVOa1sn4ZK4V/HBWYTKM7LyDpsTdCoXZQF5v/LO/t =ILCN -END PGP SIGNATURE-
Re: [gentoo-user] [OT] What's happened to BOINC recently?
On Tue, 10 Dec 2013 15:56:13 + Peter Humphrey pe...@prh.myzen.co.uk wrote: Hi list, Recently I've been finding that BOINC has just stopped. It doesn't show up in ps -ax and I can't see anything helpful in its logs. Every time I query its status I get this, which is new: $ /etc/init.d/boinc status /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuacct/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied mkdir: cannot create directory ‘/sys/fs/cgroup/openrc/boinc’: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuacct/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied mkdir: cannot create directory ‘/sys/fs/cgroup/openrc/boinc’: Permission denied * status: started FYI I got these errors simply when I queried the status of a service as a normal user, rather than root, but the final status line was still correct IIRC (on systemd now though, can't verify). Was on hardened at the time, if that matters. - Khumba I installed BOINC from the ebuild, not by getting it from berkeley.edu. The only changes I've made are to install its data directory under my home directory (/home/prh/boinc), added myself to the boinc group and chown'd everything to prh:prh. I had tried keeping the default user, group and directory but I found it easier to do it this way. Can anyone shed any light on this?
[gentoo-user] Re: [gnome3 stable] Not as bad as I expected
On 12/14/2013 12:54 AM, wraeth wrote: On 14/12/13 12:10, walt wrote: The gnome-shell desktop has a 'gestures-based' feature, which exposes the favorites menu if you move the mouse pointer *very* quickly to the left upper corner of the screen. Who knew? Well, I didn't know until yesterday because virtualbox allows the mouse pointer to slide right off of the guest window onto my real desktop without notifying the guest machine, apparently. If i'm not mistaken, the hot corner has to be activated by the mouse cursor actually hitting the corner. With the typical way the virtual machine works, with the mouse not actually 'entering' the environment, it's almost impossible to hit the corner properly as it transitions seamlessly between the guest and the host. Two ways to address this are to use the virtual machine in fullscreen mode (meaning that the corner really is the corner) or to have the virtual machine fully capture the mouse (requiring it to be released by use of the 'host' key (generally Right-CTRL). If you can, give it a try and let me know if it works :) Unfortunately it doesn't work for me. Sees like it should though.
Re: [gentoo-user] recent trouble with wicd and systemd (non-global ctrl_ifname)
On Fri, Dec 13 2013, gottl...@nyu.edu wrote: On Fri, Dec 13 2013, Bruce Hill wrote: On Thu, Dec 12, 2013 at 08:05:14PM -0500, gottl...@nyu.edu wrote: thanks but I had done that and the command is simply /usr/sbin/wicd --no-daemon Perhaps relevant is Type=dbus Canek points out that wicd has had no new releases. Perhaps I should switch to networkmanager. I will try that tomorrow. Thank you both, allan Again, I haven't looked at the thread, and don't use systemd, either, but wicd needs to start in daemon. wicd - wireless connection daemon implementation I didn't write that service file; it came with wice. So I believe it is correct. Also it works perfectly on my backup system. I certainly can try again with the --no-daemon removed and will do so this weekend. thanks for your help. allan Removing --no-daemon did not fix the problem. allan
Re: [gentoo-user] Re: Routine update wants to install 3 version of Ruby + 50 others
On 12/11/2013 02:47 AM, Hans de Graaff wrote: During a transition period like this, various upstreams release a bunch of crap with circular or conflicting dependencies that happen to work on their machines because nobody is using a real package manager. The fact that it works as well as it does is a miracle. If you don't want all three versions of Ruby on your machine, try setting e.g. RUBY_TARGETS=ruby19. It probably won't work, but that's because some package has troublesome dependencies, not because we're handling it wrong. It should work (I have some machines with that setting). Two things to keep in mind: you are now off the default settings, so you will need to manage new ruby targets yourself. You will also still get the ruby20 core installed for the moment due to weird dependency issues with some packages. This will get rectified when we add ruby20 to the default RUBY_TARGETS. If anything needs ruby, you get whatever version of ruby it wants (say, 1.9). But then the next time you emerge -puDN world, you pull in dev-lang/ruby-2.0 in a different slot. But ruby-2.0 needs rdoc, rake, and json with USE=ruby_targets_ruby20. Down the rabbit hole we go =) I did finally get RUBY_TARGETS=ruby19 working but I had to package.mask ruby-2.0 first.
[gentoo-user] A quick and easy set of eix extension scripts for you holiday present.
I have found some of the tools of portage a little opaque and confusing. Once I found eix, I put together a little set of shell scripts to make lists of the packages in portage. The script 'makeeixall' goes through and does an eix update and then generates a set of lists of packages: all, installed, new (not installed) and updates. The script 'eixall' and its aliases 'eixupdate' 'eixnew' and 'eixinst' grep the associated lists and print matches to the standard out. You will need to make the '/usr/local/tmp' directory or point EIXDIR to some other location. -- #!/bin/bash # script to create a database of packages for quick reference # 27 June 2013 version to make system-wide db # 05 Aug 2013 add downgrades to the eixupdate listing EIXDIR=/usr/local/tmp EIXALL=$EIXDIR/eix-all.txt EIXINST=$EIXDIR/eix-installed.txt EIXUPD=$EIXDIR/eix-updates.txt EIXNEW=$EIXDIR/eix-new.txt # first: get rid of the old db rm $EIXALL # second: have EIX update its binary db eix-update # third: run through the categories and build the eix-all text file echo -n Prepping files: all... cd /usr/portage cat profiles/categories | while read dname do eix --care -c -x -C $dname done $EIXALL # fourth: make some utility text databases # the installed packages echo -n install... grep -F '[I]' $EIXALL $EIXINST # the upgradeable packages # be careful to append the downgrades echo -n updates... grep -F '[U]' $EIXALL $EIXUPD grep -F '[D]' $EIXALL $EIXUPD grep -F '[UD]' $EIXALL $EIXUPD # these files are also installed, append to inst file cat $EIXUPD $EIXINST # the new uninstalled packages echo not-installed (new) grep -F '[N]' $EIXALL $EIXNEW # fifth: make the text file readable by anyone chmod 0444 /usr/local/tmp/eix*.txt exit 0 --- The script 'eixall' is for searching the outputs of 'makeeixall' #!/bin/bash # script to search a database of packages for quick reference (see makeeixall) # 27 June 2013 version 1: to use system-wide db EIXDIR=/usr/local/tmp EIXALL=$EIXDIR/eix-all.txt EIXINST=$EIXDIR/eix-installed.txt EIXUPD=$EIXDIR/eix-updates.txt EIXNEW=$EIXDIR/eix-new.txt # first: do we have an argument to search for? if [ $# -eq 0 ] then echo usage: $0 [grep-options] pattern exit 1 fi # second: find out which database we want to search EIXNAME=`basename $0` case $EIXNAME in eixall ) EIXDB=$EIXALL ;; eixinst ) EIXDB=$EIXINST ;; eixupdates ) EIXDB=$EIXUPD ;; eixnew ) EIXDB=$EIXNEW ;; * ) echo usage: $0 [grep-options] pattern exit 1 ;; esac # third: is the database in existence and readable? if [ ! -r $EIXDB ] then#no - run makeixall to make dbs sudo -E makeeixall fi # third: do the search grep $@ $EIXDB exit $? -- Once eixall is in place, symlink the script to the aliases. - cd /usr/local/bin ln -s eixall eixnew ln -s eixall eixinst ln -s eixall eixupdate --- Typical usage would be: 1.emerge --sync 2.makeeixall 3.eixupdates . | less and then do whatever to update your packages. These scrips written by me are placed in the public domain, enjoy! Gregory Wolfe Woodbury14 Dec 2013 redwo...@gmail.com
Re: [gentoo-user] Something is pulling in gnome-base
On Fri, Dec 13, 2013 at 04:44:27PM +, Mick wrote emerge -uatDv world brought up the original: Calculating dependencies... done! [nomerge ] net-im/pidgin-2.10.7-r5 USE=dbus gstreamer gtk ncurses nls spell xscreensaver (-aqua) -debug -doc -eds -gadu -gnutls -groupwise -idn - meanwhile -mxit -networkmanager -perl -prediction -python -sasl -silc -tcl -tk -zephyr -zeroconf PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python2_7 [nomerge ] media-plugins/gst-plugins-gconf-0.10.31:0.10 [ebuild U ] gnome-base/gconf-3.2.6-r1:2 [2.32.4-r1:2] USE=introspection ldap policykit -debug -gtk -orbit% PYTHON_TARGETS=python2_7%* -python2_6% 0 kB unless I add media-plugins/gst-plugins-gconf and gnome-base/gconf in package.mask Out of sheer curiousity, what needs gnome-base/gconf? To find out... equery d gnome-base/gconf -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Something is pulling in gnome-base
On Sat, 14 Dec 2013 19:52:57 -0500 Walter Dnes waltd...@waltdnes.org wrote: On Fri, Dec 13, 2013 at 04:44:27PM +, Mick wrote [nomerge ] net-im/pidgin-2.10.7-r5 [nomerge ] media-plugins/gst-plugins-gconf-0.10.31:0.10 [ebuild U ] gnome-base/gconf-3.2.6-r1:2 [2.32.4-r1:2] Out of sheer curiousity, what needs gnome-base/gconf? The output tells you; pidgin needs gst-plugins-gconf, which needs gconf. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-user] Re: A quick and easy set of eix extension scripts for you holiday present.
Greg Woodbury redwolfe at gmail.com writes: I have found some of the tools of portage a little opaque and confusing. bugs.gentoo.org is a place where issues can be posted, and patches offered up. ymmv, James
[gentoo-user] nvidia-drivers 325.15 removal
It looks to me as if the removal of nvidia-drivers-325.15 was a mistake, but I've got a lot going on in the meat world right now, and I don't want to file a bug if I've simply gotten confused. I run mostly stable amd64. I have 325.15 installed, and nothing regarding nvidia-drivers in /etc/portage/package/accept_keywords, so I *think* 325.15 was the latest stable and shouldn't have been removed for being old. The removal makes portage want to downgrade the package for me. I see in the changelog: 14 Dec 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.15.ebuild: Old. [...] 02 Nov 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.08.ebuild, nvidia-drivers-325.15.ebuild: Stable for AMD64 x86 too. Could someone confirm or set me straight?
