Re: [gentoo-user] Problem with script calling OOCalc on amd64
On 19 March 2010 08:42, Mick michaelkintz...@gmail.com wrote: Is there some bash incantation I can use then with OOo compiled from source, to keep the terminal open until I close OOo? I guess something like this might do the trick: while pgrep ooffice /dev/null; do sleep 1; done Although I'm not at my Gentoo box at the moment to test. The version of pgrep on this Debian box doesn't have a -q option, hence the redirect to devnull.
Re: [gentoo-user] Problem with script calling OOCalc on amd64
On 16 March 2010 12:41, Mick michaelkintz...@gmail.com wrote: Hi All, I have run into a problem which I cannot explain. I am trying to run this script in a amd64 installation: xterm -fg green -bg black -e 'gpg Personal/data.ods.gpg oocalc \ Personal/data.ods; shred --remove -z -v DATA/data.ods' On a x86 system, oocalc launches, I use the file and when I close it shred removes it. On the amd64 system, the file is shredded as soon as it is opened. This is what happens: I get something similar with firefox: if it's the first instance, it will block until I terminate firefox; but if there's already a firefox running, it'll send a open this URL command to the other instance, and close this new one. I'm not sure if OOo is the same, but I'd recommend giving it a try.
Re: [gentoo-user] problem with install-x86-minimal-20091103
On 10/12/2009, Joshua Murphy poiso...@gmail.com wrote: One note about sysresccd, while I do nearly all of my installs from it (working from a likely out of date copy, so unsure how much this still applies) anymore, I've run across a small issue between its use of zsh and emerging some packages. Most recently, it bit me while getting one of the dependencies to nfs-progs built so my new system would be able to get to my portage tree share on its own after the reboot. This bug (closed as RESOLVED - INVALID, since it's not actually a bug with Gentoo in the eyes of the Devs): http://bugs.gentoo.org/show_bug.cgi?id=271942 details it further and gives a couple options on fixing it, should you run into it at all. It's probably worth mentioning this on the New eselesct module for /bin/sh bug: https://bugs.gentoo.org/show_bug.cgi?id=214817 If there are things that break when /bin/sh is not bash, then it's worth noting them, and probably fixing the root cause too. :)
Re: [gentoo-user] Broken binary and revdep-rebuild doesn't find it.
On 09/03/2009, Nikos Chantziaras rea...@arcor.de wrote: rea...@gentoo ~ $ ldd /usr/lib64/NX/bin/* | grep not found libXcomp.so.3 = not found libXcompext.so.3 = not found libXcompshad.so.3 = not found libXcomp.so.3 = not found So today's update of glibc seems to have broken those binaries. However, running revdep-rebuilt doesn't find the breakage: * Dynamic linking on your system is consistent... All done. Which package owns those files? Run equery belongs $file on each of them to find out. If you don't have equery, install sys-app/gentoolkit. If the broken files don't belong to any particular package(s), then how did they get there to start with? You might also like to try emerge --depclean; I recommend running that with --pretend first though, and checking the list. I hope that helps (and that it's not too late). :)
Re: [gentoo-user] accessing a bash
On 05/02/2009, Jon Hardcastle jd_hardcas...@yahoo.com wrote: Hey guys.. random Linux question. If i have a bash process running on my machine that i am not 'attatched' to is there anyway to access it and see what it is doing short of just killing it? Take a look at app-misc/screen. Although you do need to remember to start things inside a screen to begin with.
Re: [gentoo-user] How to run dhclient on the background
On 23/11/2008, damian [EMAIL PROTECTED] wrote: Hello, When I boot my computer I don't want to wait for the dhcp client (in my case dhclient) to acquire a lease to continue the booting process. Instead, I would like that the client could be run in the background (as a daemon) right after it is invoked. Reading through the man pages of dhclient it seems like I need to pass the -nw flag to the client. However. I can't find how to do this. Any help is welcomed. It seems like I'm the only one with this issue (I don't think so) because I can't find in the internet information about this. Thanks in advance, Damian. Hi Damian I had a similar problem with my machine when I first started using Gentoo, but I then discovered sys-apps/netplug. Install that and all should be well. You might want to check your RC_NET_STRICT_CHECKING variable (in /etc/conf.d/rc) is the way you want it, but otherwise there isn't any extra configuration required. I realise you've already got your original problem sorted, but hopefully this helps others. Dan
Re: [gentoo-user] tools currently available for update of etc files after updates
On 14/11/2008, John covici [EMAIL PROTECTED] wrote: An eix on both dispatch-conf and etc-update yield no matches -- where can they be found? They both belong to sys-apps/portage on my systems: [EMAIL PROTECTED] ~ $ qfile dispatch-conf sys-apps/portage (/usr/sbin/dispatch-conf) sys-apps/portage (/usr/lib64/portage/bin/dispatch-conf) [EMAIL PROTECTED] ~ $ qfile etc-update sys-apps/portage (/usr/sbin/etc-update) sys-apps/portage (/usr/lib64/portage/bin/etc-update) [EMAIL PROTECTED] ~ $ Dan
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On 12/11/2008, Volker Armin Hemmann [EMAIL PROTECTED] wrote: as root: lspci Why as root? I get exactly the same output when I run it as my own user as when I run it as root. Or have I got my system set up different to everyone else? Dan
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On 13/11/2008, Jorge Peixoto de Morais Neto
[EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 7:05 PM, Dan Wallis [EMAIL PROTECTED] wrote:
On 12/11/2008, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
as root: lspci
Why as root? I get exactly the same output when I run it as my own
user as when I run it as root. Or have I got my system set up
different to everyone else?
$ lspci
bash: lspci: command not found
echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws:/usr/games/bin
At least in my system, the lspci binary resides in /usr/sbin, which is
not in ${PATH}
So you should either call lspci as root or issue the explicit command
/usr/sbin/lspci
Yes, I do have that directory in my PATH.
That said, if you want to use the -v flag of lspci (for extra
verbosity), you should be root, or you will see some fields filled
with access denied
Thanks for the tip; I didn't know about the verbose flag. It looks
like that'll come in useful when I do my next build in a few weeks.
Thanks
Dan
Re: [gentoo-user] How to fix a hefty (emerge) blocking problem
On 12/11/2008, Harry Putnam [EMAIL PROTECTED] wrote: I've allowed my desktop OS to become somewhat outdated. And I haven't followed all the recent changes to gentoo, so of course I am a little baffled by what appears to a real mess of overlapping dependencies or something causing 16 different blocking problems. The output of emerge -vuDNp shows a message saying I might be able solve some of the problem with masking but that appears to be only one small part of the blocking. I've included below some long output from: emerge -vuDNpt world (to show the interdependence's) (sorry but this is some 600 lines long) Possibly some other flags to emerge would be more helpful. If so please tell me and I'll post that as well. This output seems a little overwhelming but I hope someone who is used to deciphering such output will take time to look at it and maybe see how I can get started straightening it out. First a short look at the blocking lines: = * = * = * = * = * = * = grep blocking outfile [blocks b ] x11-drivers/xf86-video-nsc (x11-drivers/xf86-video-nsc is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-vga (x11-drivers/xf86-video-vga is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-imstt (x11-drivers/xf86-video-imstt is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-cyrix (x11-drivers/xf86-video-cyrix is blocking x11-base/xorg-server-1.5.2) [blocks b ]sys-libs/ss (sys-libs/ss is blocking sys-libs/e2fsprogs-libs-1.41.3) [blocks b ] sys-libs/e2fsprogs-libs (sys-libs/e2fsprogs-libs is blocking sys-libs/com_err-1.40.11, sys-libs/ss-1.40.11) [blocks b ] sys-libs/com_err (sys-libs/com_err is blocking sys-libs/e2fsprogs-libs-1.41.3) [blocks b ] sys-fs/e2fsprogs-1.41 (sys-fs/e2fsprogs-1.41 is blocking sys-libs/e2fsprogs-libs-1.41.3) [blocks b ] x11-base/xorg-server-1.5 (x11-base/xorg-server-1.5 is blocking x11-libs/libpciaccess-0.10.5) [blocks b ]dev-python/pygtk-2.13 (dev-python/pygtk-2.13 is blocking dev-python/pygobject-2.15.4) [blocks B ]dev-python/pygtk-2.13 (dev-python/pygtk-2.13 is blocking dev-python/pygobject-2.15.4) [blocks B ] =sys-fs/udev-126 (=sys-fs/udev-126 is blocking sys-fs/cryptsetup-1.0.6) [blocks B ] =kde-base/kdebase-3.5* (=kde-base/kdebase-3.5* is blocking kde-base/kdeprint-3.5.10) [blocks B ] kde-base/kdeprint:3.5 (kde-base/kdeprint:3.5 is blocking kde-base/kdebase-3.5.9-r4) [blocks B ] =x11-libs/qt-4.4.0_alpha:4 (=x11-libs/qt-4.4.0_alpha:4 is blocking x11-libs/qt-qt3support-4.4.2, x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2, x11-libs/qt-assistant-4.4.2, x11-libs/qt-xmlpatterns-4.4.2, x11-libs/qt-sql-4.4.2, x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2, x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2, x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2) [blocks B ] kde-base/kdebase (kde-base/kdebase is blocking kde-base/kdelibs-3.5.10-r2) The blocks regarding sys-fs/e2fsprogs, sys-libs/e2fsprogs-libs, sys-libs/ss and sys-libs/com_err were discussed recently on this list. Basically you need to: emerge -f e2fsprogs e2fsprogs-libs emerge -C com_err ss e2fsprogs emerge -1 e2fsprogs I'm not sure about the others, but fixing these should get you closer to an up-to-date system. :) Dan
Re: [gentoo-user] sshd won't restart on remote system
On 12/11/2008, Grant [EMAIL PROTECTED] wrote: After updating to the latest stable x86 openssh and merging config files on my remote system, I get: # /etc/init.d/sshd restart * Stopping sshd ... [ !! ] There is nothing in /var/log/sshd/current. Does anyone know what I should do? You could stop the sshd process manually with kill or similar (I use htop). (Careful though, you don't want to kill your current session, just the daemon listening for new connections!) Then you can zap the service and start it as normal. Or you could reboot the host, and (assuming it's in your default run-level) sshd will start on boot. Dan
Re: [gentoo-user] Smartd
On 24/10/2008, Jon Hardcastle [EMAIL PROTECTED] wrote: I want the drives to be checked by smartd also. I just hoped there was a way of getting smartd to wait alittle longer after waking the drive up. Could you generate some disk activity on the disk(s) just prior to the scheduled check(s)? I realise this isn't a solution, but more of a work-around. Dan
Re: [gentoo-user] gimp doc
On 22/10/2008, Andrew Gaydenko [EMAIL PROTECTED] wrote: There are two packages related to gimp doc: app-doc/gimp-user-manual-2.0 app-doc/gimp-help-2.4.2 Interestingly, USE=doc emerge gimp pulls in neither of these packages. I would have expected it to have required at least one of them. Should this be raised as a bug on the bugzilla? Dan
