[gentoo-user] Re: Load average in make
Nilesh Govindrajan m...@nileshgr.com writes: My question is which load average it checks? I'm assuming it checks for the 15 minute average? I certainly don't know much about C, but from me grepping the source of make, it seems that job.c does getloadavg (load, 1). Moreover man getloadavg says that the '1' there means to put the 1 minute load average into 'load'. hth, -- Nico.
[gentoo-user] Re: Where does sudo get the PATH ?
Nicolas Richard theonewiththeevill...@yahoo.fr writes: I don't understand where sudo finds the value for the PATH env variable. Finally, I found where the problem lied. Recall that my problem was the following : I had a path in `sudo env | grep ^PATH' which did not seem to originate from any config file in /etc or /root (the path pointing to texlive/2011). And indeed, it was set at compile time, using --with-secure-path : $ sudo sudo -V | head -2 Sudo version 1.8.5p2 Configure options: --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-zlib=system --with-secure-path=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin:/usr/local/texlive/2011/bin/i386-linux --with-editor=/usr/libexec/editor --with-env-editor --without-insults --without-all-insults --with-ldap_conf_file=/etc/ldap.conf.sudo --with-ldap --enable-nls --with-pam --without-skey --without-selinux --without-opie --without-linux-audit --with-timedir=/var/db/sudo --with-plugindir=/usr/lib/sudo --docdir=/usr/share/doc/sudo-1.8.5_p2 In the ebuild, I find the following comment : # FIXME: secure_path is a compile time setting. using ROOTPATH # is not perfect, env-update may invalidate this, but until it # is available as a sudoers setting this will have to do. I'm not sure I understand this comment because adding the following line in /etc/sudoers : Defaults secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin does what I expect it to do : override the PATH variable. Maybe the comment is simply outdated ? Thanks to those who tried to help me here and also to Nicolas George who pointed me in the direction of `secure_path' which I had somehow overlooked in the manpages. -- Nicolas.
[gentoo-user] Re: Where does sudo get the PATH ?
Pandu Poluan pa...@poluan.info writes: Maybe it's building the PATH not explicitly... something like : PATH=$PATH;/usr/local/texlive/$SOME_VARIABLE/and/so/forth Try grepping for texlive/\$ I tried, but the results are always pointing to the (correct) 2012 version. I paste the result hereunder just in case, but I'm pretty sure there's nothing interesting in there. (btw, there are errors because of missing targets for some symlinks, hence the redirection) youngfrog@geodiff-mac3 /etc $ sudo grep -R 'texlive' * 2 /dev/null csh.env:setenv INFOPATH '/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/4.5.4/info:/usr/share/binutils-data/i686-pc-linux-gnu/2.22/info:/usr/share/info/emacs-24:/usr/local/texlive/2012/texmf/doc/info' csh.env:setenv MANPATH '/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.5.4/man:/usr/share/binutils-data/i686-pc-linux-gnu/2.22/man:/etc/java-config/system-vm/man/:/usr/local/texlive/2012/texmf/doc/man' csh.env:setenv PATH '/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux' csh.env:setenv ROOTPATH '/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/local/texlive/2012/bin/i386-linux' env.d/99texlive:PATH=/usr/local/texlive/2012/bin/i386-linux env.d/99texlive:ROOTPATH=/usr/local/texlive/2012/bin/i386-linux env.d/99texlive:MANPATH=/usr/local/texlive/2012/texmf/doc/man env.d/99texlive:INFOPATH=/usr/local/texlive/2012/texmf/doc/info environment:PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/local/texlive/2012/bin/i386-linux:/root/bin portage/profile/package.provided:app-text/texlive-core-2011-r5 portage/profile/package.provided:dev-texlive/texlive-basic-2011-r1 portage/profile/package.provided:dev-texlive/texlive-documentation-base-2011 portage/profile/package.provided:dev-texlive/texlive-fontsextra-2011 portage/profile/package.provided:dev-texlive/texlive-fontsrecommended-2011 portage/profile/package.provided:dev-texlive/texlive-fontutils-2011 portage/profile/package.provided:dev-texlive/texlive-genericextra-2011 portage/profile/package.provided:dev-texlive/texlive-genericrecommanded-2011 portage/profile/package.provided:dev-texlive/texlive-genericrecommended-2011 portage/profile/package.provided:dev-texlive/texlive-latex-2011 portage/profile/package.provided:dev-texlive/texlive-latexextra-2011-r2 portage/profile/package.provided:dev-texlive/texlive-latexrecommended-2011 portage/profile/package.provided:dev-texlive/texlive-pictures-2011 portage/profile/package.provided:dev-texlive/texlive-pstricks-2011 portage/profile/package.provided:dev-texlive/texlive-science-2011 portage/profile/package.provided:dev-texlive/texlive-texinfo-2011 portage/profile/package.provided:# dev-texlive/texlive-latex3-2011 portage/profile/package.provided:# dev-texlive/texlive-fontsextra-2011 portage/profile/package.provided:# dev-texlive/texlive-latexextra-2011 portage/profile/package.provided:# dev-texlive/texlive-pictures-2011 portage/profile/package.provided:# dev-texlive/texlive-science-2011 portage/profile/package.provided:# dev-texlive/texlive-xetex-2011 portage/profile/package.provided:# dev-texlive/texlive-luatex-2011 prelink.conf:-h /usr/local/texlive/2012/bin/i386-linux/ profile.env:export INFOPATH='/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/4.5.4/info:/usr/share/binutils-data/i686-pc-linux-gnu/2.22/info:/usr/share/info/emacs-24:/usr/local/texlive/2012/texmf/doc/info' profile.env:export MANPATH='/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.5.4/man:/usr/share/binutils-data/i686-pc-linux-gnu/2.22/man:/etc/java-config/system-vm/man/:/usr/local/texlive/2012/texmf/doc/man' profile.env:export PATH='/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux' profile.env:export ROOTPATH='/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/local/texlive/2012/bin/i386-linux' -- N.
[gentoo-user] Re: Where does sudo get the PATH ?
Joost Roeleveld jo...@antarean.org writes:
On Wednesday, October 10, 2012 04:57:50 PM Nicolas Richard wrote:
In my homedir:
.bash_profile loads .bashrc
.bashrc says export PATH=~/bin/overrideglobal:${PATH}:~/bin (and
defines some aliases)
Does it load any global default?
No. Here are the full files, omitting comments and empty lines :
youngfrog@geodiff-mac3 ~ $ grep -vH '^#\|^$' .bashrc .bash_profile
.bashrc:export PATH=~/bin/overrideglobal:${PATH}:~/bin
.bashrc:if [[ $- != *i* ]] ; then
.bashrc:# Shell is non-interactive. Be done now!
.bashrc:return
.bashrc:fi
.bashrc:UPDATEGITREPO=~/TeX/ ~/BSSM/2011/notes-de-conf/ ~/org/ ~/BSSM/2012
.bashrc:export UPDATEGITREPO
.bashrc:alias ll=ls -lA
.bashrc:alias l=ls -CF
.bashrc:alias cp=cp -i
.bashrc:alias rm=rm -i
.bashrc:alias mv=mv -i
.bash_profile:[[ -f ~/.bashrc ]] . ~/.bashrc
In other words, what is in the environment when you are normally
logged in?
Ok, I thought my original post contained it. In fact that was part of my
original post :
youngfrog@geodiff-mac3 ~ $ bash -c 'echo $PATH'
~/bin/overrideglobal:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux:~/bin
and I forgot to mention that it was the same as :
youngfrog@geodiff-mac3 ~ $ env | grep ^PATH
PATH=~/bin/overrideglobal:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux:~/bin
and yet the same as :
youngfrog@geodiff-mac3 ~ $ echo $PATH
~/bin/overrideglobal:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux:~/bin
Thanks for trying btw. I certainly did something really stupid to set
the path the first time, but can't see where.
N.
[gentoo-user] Re: Where does sudo get the PATH ?
Pandu Poluan pa...@poluan.info writes: A bit desperate, but try : grep -R texlive/2011 /etc/* I tried that already youngfrog@geodiff-mac3 ~ $ sudo grep -r texlive/2011 /etc youngfrog@geodiff-mac3 ~ $ sudo grep -r texlive/2011 ~root /root/.bash_history:cd /usr/local/texlive/2011 /root/.bash_history:grep texlive/2011 * -r /root/.bash_history:grep texlive/2011 . -r /root/.bash_history:grep texlive/2011 .* -r -- N.
[gentoo-user] Re: Where does sudo get the PATH ?
Joost == J Roeleveld jo...@antarean.org writes:
Joost And, what is in the .bash_profile and .bashrc files in your
Joost homedir and in root's homedir?
In my homedir:
.bash_profile loads .bashrc
.bashrc says export PATH=~/bin/overrideglobal:${PATH}:~/bin (and
defines some aliases)
In root's: I have no such files.
Maybe it would be less distracting if I don't use a shell at all :
youngfrog@geodiff-mac3 ~ $ sudo -i env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/local/texlive/2012/bin/i386-linux:/root/bin
youngfrog@geodiff-mac3 ~ $ sudo env | grep ^PATH
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin:/usr/local/texlive/2011/bin/i386-linux
Joost What do you get with echo $PATH when not using sudo?
You mean, when I'm logged in as root ? Then it's the same as when using
sudo -i.
N.
[gentoo-user] Re: Where does sudo get the PATH ?
Joost == J Roeleveld jo...@antarean.org writes: Joost Nicolas Richard theonewiththeevill...@yahoo.fr wrote: Here is the output of the relevant (at least I thought they were) commands. Can somebody explain to me why I still have /usr/local/texlive/*2011*/bin/i386-linux in the first sudo output youngfrog@geodiff-mac3 ~ $ sudo bash -c 'echo $PATH' /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin:/usr/local/texlive/2011/bin/i386-linux youngfrog@geodiff-mac3 ~ $ grep -v '^#\|^$' /etc/environment PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/local/texlive/2012/bin/i386-linux:/root/bin Joost I can see several /usr/local/... paths in your Joost /etc/environment. Hello Joost, Yes, I see them too, but they are pointing to the more recent 2012 release of texlive, not the older 2011 one. What I don't understand is where /sudo/ finds the environment when called without the -i option (and in particular, that entry for texlive 2011). The manpage seems to say that it simply uses the current environment (quoting the manpage : Note, however, that the actual PATH environment variable is not modified and is passed unchanged to the program that sudo executes.) but that does not seem right. -- N.
[gentoo-user] Where does sudo get the PATH ?
Hi everybody, I don't understand where sudo finds the value for the PATH env variable. Here is the output of the relevant (at least I thought they were) commands. Can somebody explain to me why I still have /usr/local/texlive/*2011*/bin/i386-linux in the first sudo output ? I don't get it, and did not find anything in the man page of sudo. Thanks in advance for your help. youngfrog@geodiff-mac3 ~ $ bash -c 'echo $PATH' ~/bin/overrideglobal:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux:~/bin youngfrog@geodiff-mac3 ~ $ source /etc/profile youngfrog@geodiff-mac3 ~ $ bash -c 'echo $PATH' /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin:/usr/local/texlive/2012/bin/i386-linux youngfrog@geodiff-mac3 ~ $ sudo bash -c 'echo $PATH' /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin:/usr/local/texlive/2011/bin/i386-linux youngfrog@geodiff-mac3 ~ $ sudo -i bash -c 'echo $PATH' /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/local/texlive/2012/bin/i386-linux:/root/bin youngfrog@geodiff-mac3 ~ $ sudo grep -r texlive/2011 /etc youngfrog@geodiff-mac3 ~ $ sudo grep -r texlive/2011 ~root /root/.bash_history:cd /usr/local/texlive/2011 /root/.bash_history:grep texlive/2011 * -r /root/.bash_history:grep texlive/2011 . -r /root/.bash_history:grep texlive/2011 .* -r youngfrog@geodiff-mac3 ~ $ grep -v '^#\|^$' /etc/environment PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/local/texlive/2012/bin/i386-linux:/root/bin -- N.R.
[gentoo-user] Re: How to verify stable system after fsck corrections
Le 01/06/10 13:04, Neil Bothwick a écrit : equery check --only-failures '*' Note: the local option --only-failures seems not available in the current stable version of gentoolkit. Note that it will show failures on any files that have been modified since installation, such as configuration and data files, so you'll have to check these manually, but if a library or executable shows up you almost certainly have a problem. I ran it and many .la files are found. I guess this is because of 'lafilefixer', and they should not be considered as corrupted. Nicolas.
[gentoo-user] Re: language
Le 03/04/10 09:34, Roger Cahn a écrit : (process:5573): Gtk-WARNING**: locale not supported by C library. Using the fallback 'C' locale. Any similar message if you simple run gedit ? What's the output of locale -a, and of locale ? Btw, did you need to install/modify anything to get the projector working ? -- Nico.
[gentoo-user] Re: how to git-bisect in a portage-compatible way ?
Hm. I'm not sure what you are asking. It was unclear, but you answered the question indirectly. Thanks, Nico.
[gentoo-user] Re: how to git-bisect in a portage-compatible way ?
Le 10/03/10 17:08, walt a écrit : On 03/10/2010 03:03 AM, Nicolas Richard wrote: So the general question is : if I want to use git-bisect (I have never done that before, but today is a good time to try), It's a great tool and easy to use once you've learned the basic steps. You can ask here if you need help with it. I have to agree, it's quite a nice tool. Unfortunately the bug is a bit unpredictable (random crash which requires a reboot) and I found out that the version I thought was good (2.4.11) was in fact bad, and that I probably had been lucky not to encounter a crash for some days. Moreover, releases of libdrm prior to 2.4.11 are incompatible with my current xf86-xorg-intel (while writing this and looking at gitk, I notice that there are a few commits which should be compatible. I'll try these later.) What is weird is that if I use older versions, I feel it crashes less often than with new versions. I have in mind two things two try: * bisecting another package, e.g. xf86-xorg-intel or even the kernel. * instead of trying to find a commit which does not have the bug, find one which has a related but different bug. I mean, the crash is not always the same, sometimes I can still access the console, sometimes I just have to reboot, sometimes the kernel crashes too... maybe I can find a commit for which the bug behaves differently. Let me stop being off topic for a few seconds, and ask a real question about git-bisect : imagine there are two bugs : bug A is a known bug, present in version 2.4.11 but corrected in 2.4.18, and bug B is another bug which I'm trying to bisect. Problem : they have the same effect (let's say : a crash) and I want to fix bug A because it might hide bug B. Assuming that the patch which fixes bug A can be applied to the files of versions 2.4.11-2.4.18, is it possible to bisect these modified versions ? What I can imagine is : do a normal git-bisect session, but each time apply the patch before ./configure'ing. That sounds ok, but is it ? And if yes, what's the correct way to tell git to put the changes induced by one commit on the current head ? (I hope I'm being clear and not mixing the terms, here). When you configure the git test package, use the --prefix=/usr/local flag so that the test library gets installed in /usr/local/lib, and /usr/local/include, etc. I followed your advice (/usr/local is actually the default location for libdrm) and it worked quite nice because it is easy to track the files installed by the package within /usr/local... maybe this is not true for more complicated packages ? Then, to test the new library, just change the /usr/lib/libdrm symlink to point at /usr/local/lib/libdrm.so.whatever. Actually, it seems that the system first looks in /usr/local/lib before /usr/lib, so it was probably unnecessary to modify the symlinks (noticed it at the end). -- Nico.
[gentoo-user] how to git-bisect in a portage-compatible way ?
Hello, Background info : I'm experiencing a bug and found out that the bug doesn't appear with libdrm-2.4.11 (I kept an ebuild for this one in /usr/local/portage/...), but it does occur with libdrm-2.4.13 (not sure about the version numbers anymore, and I have yet to try 2.4.12, too, but that's not the question) So the general question is : if I want to use git-bisect (I have never done that before, but today is a good time to try), I guess it means I'll have to build libdrm outside portage : if so, once I'm finished with hunting the bug, how to go back to the situation where portage does everything for me ? Some more precise questions : - before I begin, should I first unmerge libdrm ? - once I finished with bisecting, should I reemerge libdrm ? Will portage overwrite files it may need to overwrite ? what about orphanned files (if any) ? I looked at the documentation list on gentoo.org, I did find a section entitled Non-portage maintained software, but this is not what I'm looking for. Where else should I look at ? thanks for your comments Nicolas.
