Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On Sunday 05 Jan 2014 16:15:31 Alan McKinnon wrote: Golden rule: When updating perl or python and a version change occurs, take note and always run perl-cleaner or python-updater afterwards. Sage advice indeed. And if you're really paranoid, run python-updater before perl-cleaner in case the way portage operates has been affected. Well, it may make no difference really but that's what I do. -- Regards Peter
[gentoo-user] updating old box: segfaults with python
Greetings,
yesterday I started to upgrade an older gentoo server at a customer. It
has only been updated now and then as they tend to save money and rarely
contact me ...
I recommended to at least apply the stuff mentioned in the GLSAs ... and
applied some updates today (remote, via ssh).
Today glibc failed to merge:
Installing (2 of 3) sys-libs/glibc-2.17
* Defaulting /etc/host.conf:multi to on
/usr/lib/portage/bin/phase-functions.sh: Zeile 87: 26924
Speicherzugriffsfehler ${PORTAGE_PYTHON:-/usr/bin/python}
${PORTAGE_BIN_PATH}/filter-bash-environment.py ${filtered_vars}
* ERROR: sys-libs/glibc-2.11.3::gentoo failed (prerm phase):
* filter-bash-environment.py failed
*
* Call stack:
*ebuild.sh, line 480: Called __preprocess_ebuild_env
* phase-functions.sh, line 156: Called __filter_readonly_variables
'--filter-features' '--filter-locale' '--filter-path' '--filter-sandbox'
* phase-functions.sh, line 137: Called die
* The specific snippet of code:
* ${PORTAGE_PYTHON:-/usr/bin/python}
${PORTAGE_BIN_PATH}/filter-bash-environment.py ${filtered_vars} ||
die filter-bash-environment.py failed
*
* If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.11.3::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.11.3::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/environment'.
* Working directory: '/usr/lib/portage/pym'
* S: '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/work/glibc-2.11.3'
/usr/lib/portage/bin/isolated-functions.sh: Zeile 109: 27001
Speicherzugriffsfehler $PORTAGE_BIN_PATH/ebuild-ipc exit 1
But it seems that this is the consequence of problems with python.
There are various versions installed:
# eselect python list
Available Python interpreters:
[1] python2.4
[2] python2.5
[3] python2.6
[4] python2.7 *
[5] python3.1
[6] python3.3
But I get segfaults (german: Speicherzugriffsfehler) for all of them:
mail ~ # python2.7
Speicherzugriffsfehler
mail ~ # python3.1
Speicherzugriffsfehler
mail ~ # python3.3
Speicherzugriffsfehler
dmesg shows lines:
awk[28527]: segfault at 579e ip 579e sp bfc3006c error 4 in
gawk[8048000+4c000]
awk[28531]: segfault at 579e ip 579e sp bff3c8ec error 4 in
gawk[8048000+4c000]
find[28706]: segfault at 579e ip 579e sp bff21c3c error 4 in
find[8048000+21000]
find[28707]: segfault at 579e ip 579e sp bff42c9c error 4 in
find[8048000+21000]
find[28708]: segfault at 579e ip 579e sp bfe1a4ac error 4 in
find[8048000+21000]
find[28714]: segfault at 579e ip 579e sp bf82cb5c error 4 in
find[8048000+21000]
find[28715]: segfault at 579e ip 579e sp bfa0ef3c error 4 in
find[8048000+21000]
find[28716]: segfault at 579e ip 579e sp bfa4c4cc error 4 in
find[8048000+21000]
find[28720]: segfault at 579e ip 579e sp bfa1c83c error 4 in
find[8048000+21000]
find[28721]: segfault at 579e ip 579e sp bfcf9fbc error 4 in
find[8048000+21000]
eix[28731]: segfault at 579e ip 579e sp bfc028ec error 4 in
eix[8048000+114000]
python2.7[28732]: segfault at 579e ip 579e sp bfa1c9fc error 4 in
python2.7[8048000+1000]
python2.7[28733]: segfault at 579e ip 579e sp bf8a2c0c error 4 in
python2.7[8048000+1000]
python2.7[28746]: segfault at 579e ip 579e sp bfeb392c error 4 in
python2.7[8048000+1000]
python2.7[28747]: segfault at 579e ip 579e sp bfbfcd4c error 4 in
python2.7[8048000+1000]
python2.7[28749]: segfault at 579e ip 579e sp bfa1b71c error 4 in
python2.7[8048000+1000]
python2.7[28757]: segfault at 579e ip 579e sp bfeb8b0c error 4 in
python2.7[8048000+1000]
python2.7[28762]: segfault at 579e ip 579e sp bfeb479c error 4 in
python2.7[8048000+1000]
This leads to not being able to emerge something :-(
What can I do? quickpkg some python-version and copy over?
(sidenote: 32bit box ...)
I would like to avoid to have to drive there so it would be great to be
able to fix that from here, via ssh.
Thanks for any help, Stefan
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 11:28:36 Stefan G. Weichinger wrote:
Greetings,
yesterday I started to upgrade an older gentoo server at a customer. It
has only been updated now and then as they tend to save money and rarely
contact me ...
I recommended to at least apply the stuff mentioned in the GLSAs ... and
applied some updates today (remote, via ssh).
Today glibc failed to merge:
Installing (2 of 3) sys-libs/glibc-2.17
* Defaulting /etc/host.conf:multi to on
/usr/lib/portage/bin/phase-functions.sh: Zeile 87: 26924
Speicherzugriffsfehler ${PORTAGE_PYTHON:-/usr/bin/python}
${PORTAGE_BIN_PATH}/filter-bash-environment.py ${filtered_vars}
* ERROR: sys-libs/glibc-2.11.3::gentoo failed (prerm phase):
* filter-bash-environment.py failed
*
* Call stack:
*ebuild.sh, line 480: Called __preprocess_ebuild_env
* phase-functions.sh, line 156: Called __filter_readonly_variables
'--filter-features' '--filter-locale' '--filter-path' '--filter-sandbox'
* phase-functions.sh, line 137: Called die
* The specific snippet of code:
*${PORTAGE_PYTHON:-/usr/bin/python}
${PORTAGE_BIN_PATH}/filter-bash-environment.py ${filtered_vars} ||
die filter-bash-environment.py failed
*
* If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.11.3::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.11.3::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/environment'.
* Working directory: '/usr/lib/portage/pym'
* S: '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/work/glibc-2.11.3'
/usr/lib/portage/bin/isolated-functions.sh: Zeile 109: 27001
Speicherzugriffsfehler $PORTAGE_BIN_PATH/ebuild-ipc exit 1
But it seems that this is the consequence of problems with python.
There are various versions installed:
# eselect python list
Available Python interpreters:
[1] python2.4
[2] python2.5
[3] python2.6
[4] python2.7 *
[5] python3.1
[6] python3.3
But I get segfaults (german: Speicherzugriffsfehler) for all of them:
mail ~ # python2.7
Speicherzugriffsfehler
mail ~ # python3.1
Speicherzugriffsfehler
mail ~ # python3.3
Speicherzugriffsfehler
dmesg shows lines:
awk[28527]: segfault at 579e ip 579e sp bfc3006c error 4 in
gawk[8048000+4c000]
awk[28531]: segfault at 579e ip 579e sp bff3c8ec error 4 in
gawk[8048000+4c000]
find[28706]: segfault at 579e ip 579e sp bff21c3c error 4 in
find[8048000+21000]
find[28707]: segfault at 579e ip 579e sp bff42c9c error 4 in
find[8048000+21000]
find[28708]: segfault at 579e ip 579e sp bfe1a4ac error 4 in
find[8048000+21000]
find[28714]: segfault at 579e ip 579e sp bf82cb5c error 4 in
find[8048000+21000]
find[28715]: segfault at 579e ip 579e sp bfa0ef3c error 4 in
find[8048000+21000]
find[28716]: segfault at 579e ip 579e sp bfa4c4cc error 4 in
find[8048000+21000]
find[28720]: segfault at 579e ip 579e sp bfa1c83c error 4 in
find[8048000+21000]
find[28721]: segfault at 579e ip 579e sp bfcf9fbc error 4 in
find[8048000+21000]
eix[28731]: segfault at 579e ip 579e sp bfc028ec error 4 in
eix[8048000+114000]
python2.7[28732]: segfault at 579e ip 579e sp bfa1c9fc error 4 in
python2.7[8048000+1000]
python2.7[28733]: segfault at 579e ip 579e sp bf8a2c0c error 4 in
python2.7[8048000+1000]
python2.7[28746]: segfault at 579e ip 579e sp bfeb392c error 4 in
python2.7[8048000+1000]
python2.7[28747]: segfault at 579e ip 579e sp bfbfcd4c error 4 in
python2.7[8048000+1000]
python2.7[28749]: segfault at 579e ip 579e sp bfa1b71c error 4 in
python2.7[8048000+1000]
python2.7[28757]: segfault at 579e ip 579e sp bfeb8b0c error 4 in
python2.7[8048000+1000]
python2.7[28762]: segfault at 579e ip 579e sp bfeb479c error 4 in
python2.7[8048000+1000]
This leads to not being able to emerge something :-(
What can I do? quickpkg some python-version and copy over?
(sidenote: 32bit box ...)
I would like to avoid to have to drive there so it would be great to be
able to fix that from here, via ssh.
Thanks for any help, Stefan
The segfaults look scary and could point to hardware fault. I'd run a backup
of any useful data to start with.
Then run 'python-updater' to rebuild any packages that had their links broken.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 11:39:03 Stefan G. Weichinger wrote: Am 08.01.2014 12:28, schrieb Stefan G. Weichinger: What can I do? quickpkg some python-version and copy over? (sidenote: 32bit box ...) I assume it should be glibc repaired, right? Activated some 32bit-chroot here and building glibc-2.17-package now. How to apply that without emerge? googling ... In case things are really badly borked: http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml Then you can use emerge --buildpkg to create a binary package locally, and scp it to the remote machine where you can use --usepkg or --usepkgonly. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 12:45, schrieb Mick:
The segfaults look scary and could point to hardware fault. I'd
run a backup of any useful data to start with.
sure, backups ran late night ... and non-python-stuff seems to work ok
so far
Then run 'python-updater' to rebuild any packages that had their
links broken.
That does not run. Already tried it.
# python-updater
/usr/sbin/python-updater: Zeile 146: 28887 Speicherzugriffsfehler
/usr/bin/portageq has_version / ${1}
/usr/sbin/python-updater: Zeile 146: 2 Speicherzugriffsfehler
/usr/bin/portageq has_version / ${1}
* Python 2 and Python 3 not installed
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 12:53, schrieb Mick: In case things are really badly borked: http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml Then you can use emerge --buildpkg to create a binary package locally, and scp it to the remote machine where you can use --usepkg or --usepkgonly. Thanks for the pointer. Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc Still getting segfaults with the replaced emerge-command :-(
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 12:28, schrieb Stefan G. Weichinger: What can I do? quickpkg some python-version and copy over? (sidenote: 32bit box ...) I assume it should be glibc repaired, right? Activated some 32bit-chroot here and building glibc-2.17-package now. How to apply that without emerge? googling ...
Re: [gentoo-user] disable numlock on netbook
On Sunday 05 Jan 2014 21:41:46 Alan McKinnon wrote: I have Gentoo on a first gen Acer Aspire One. The teeny keyboard doesn't have a numpad, it's simulated by using the right-hand bunch of keys and you engage it with Fn-F11 It's recently started booting up with the numpad on which is annoying at first login as my username is not a3an0 The Num LED is also off at this stage. There used to be a way to set numlock on or off in baselayout/openrc but now I can't find it. grep -r numlock /etc returns nothing relevant, and /etc/init.d/numlock is to enable it with no function to disable it (I have this script disable in default runlevel) How is this done these days? Should I call setleds in rc.local somewhere? It used to be part of the rc scripts. I have this in my list, but my gentoo installation is rather old: # rc-update -s -v | grep numlock numlock | You could check if it is enabled on any runlevel and if yes, then 'rc-update delete numlock' should get rid of it. Of course if it is not enabled then I would be also perplexed how we are supposed to manage it these days. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote: Thanks for the pointer. Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc Still getting segfaults with the replaced emerge-command :-( This does not look good. Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD for you to connect to it remotely and then chroot into the borked installation to essentially reinstall the required packages with a functional portage and toolchain from the LiveCD? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 12:06:47 Mick wrote: On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote: Thanks for the pointer. Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc Still getting segfaults with the replaced emerge-command :-( This does not look good. Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD for you to connect to it remotely and then chroot into the borked installation to essentially reinstall the required packages with a functional portage and toolchain from the LiveCD? Another idea, in case you have a fs corruption: if awk/gawk segfaults can you use a binary package from your local machine to see if the segfault goes away? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Questions about History file
Hi all, I routinely am logged into a server with multiple consoles (I log in with one (the same) regular user, then su - to root). This morning I tried to grep roots .bash_history for a command I ran some time ago, and it wasn't there. I know I ran it, so I'd like to configure my bash history so this doesn't happen again. Thinking about it a bit, the first issue I see is... when I am running multiple consoles, each one having been started by first logging in as my normal user, then su - to root, how does this affect the .bash_history file? It seems like there would be a collision of some kind, maybe result in the last one to log out 'winning' (that .bash_history is the one that is saved/stored) or something? Maybe... would it be possible to use different regular users, then when each one does the su - to root, have it create a separate .bash_history file based on the original username? That would be perfect. I was also considering something like setting HISTSIZE=###, then adding something to the logrotate.conf file to start rotating the history file, so I don't lose anything - but I'm not sure if that would even work. So, I'm interested in how others do this... especially on a system that has multiple users managing it. Thx... Charles
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 13:06, schrieb Mick: On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote: Thanks for the pointer. Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc Still getting segfaults with the replaced emerge-command :-( This does not look good. Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD for you to connect to it remotely and then chroot into the borked installation to essentially reinstall the required packages with a functional portage and toolchain from the LiveCD? maybe ... *but* I think I got something done: pulled in python-2.7.5-r3.tbz2 from http://tinderbox.dev.gentoo.org ... and untarred it ... didn't help. Then glibc-2.16.0.tbz2 ... and now python-updater and eix and emerge ... don't segfault anymore. I will now re-emerge glibc and python etc ... right? Thanks!
Re: [gentoo-user] Re: Confusion about slot conflict
On Monday 06 Jan 2014 21:35:41 Alan McKinnon wrote: On 06/01/2014 19:58, »Q« wrote: I had exactly the same weirdness after 1.6.8 was stabilized. I waited a few hours, re-synced the tree, and then updated without any warnings about blocks; the old libpng was unmerged and 1.6.8 was merged automagically as one would expect. I don't know what caused the problem or what fixed it. Ah, that explains it. I last synced 3 days ago Obviously, updating libpng in the tree was a two stage process, with a longer than expected delay between them. Or maybe a bug the dev didn't anticipate showed up right away and needed fixing. You and fortitude both sync'ed in this middle period and got hit by the bug. I'm having a similar problem on my local LAN server, an Atom box. I sync daily, and I've just synced again to make sure (31000 files, yet again, nearly all in metadata). The Atom's packages directory is NFS-mounted in a 32-bit chroot on my workstation, which does all the compiling work and then the Atom installs from packages. For several days I've been finding that the Atom box throws up the libpng error whereas the chroot doesn't want to upgrade anything. I've checked that /etc/portage/* is identical except for make.conf, which has to differ in proxy names, rsync hosts and a couple of other details. There's no ACCEPT_KEYWORDS entry in either make.conf. The packages that portage complains of are all at the same versions on the two boxes. I can't see a way out of this, other than forcing a libpng update on the atom. Any further thoughts anyone? I'm almost sure I'm overlooking something but in my present befuddled state I can't see what. -- Regards Peter
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 12:10:41 Stefan G. Weichinger wrote: Am 08.01.2014 13:06, schrieb Mick: On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote: Thanks for the pointer. Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc Still getting segfaults with the replaced emerge-command :-( This does not look good. Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD for you to connect to it remotely and then chroot into the borked installation to essentially reinstall the required packages with a functional portage and toolchain from the LiveCD? maybe ... *but* I think I got something done: pulled in python-2.7.5-r3.tbz2 from http://tinderbox.dev.gentoo.org ... and untarred it ... didn't help. Then glibc-2.16.0.tbz2 ... and now python-updater and eix and emerge ... don't segfault anymore. I will now re-emerge glibc and python etc ... right? Thanks! I don't know if I am stating the obvious but just in case: Have a look here and set up your --python2 to reflect what you have installed. You may need to go at it in steps between versions. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 13:33:20 Mick wrote: On Wednesday 08 Jan 2014 12:10:41 Stefan G. Weichinger wrote: Am 08.01.2014 13:06, schrieb Mick: On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote: Thanks for the pointer. Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc Still getting segfaults with the replaced emerge-command :-( This does not look good. Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD for you to connect to it remotely and then chroot into the borked installation to essentially reinstall the required packages with a functional portage and toolchain from the LiveCD? maybe ... *but* I think I got something done: pulled in python-2.7.5-r3.tbz2 from http://tinderbox.dev.gentoo.org ... and untarred it ... didn't help. Then glibc-2.16.0.tbz2 ... and now python-updater and eix and emerge ... don't segfault anymore. I will now re-emerge glibc and python etc ... right? Thanks! I don't know if I am stating the obvious but just in case: Have a look here and set up your --python2 to reflect what you have installed. You may need to go at it in steps between versions. Oops! Pulled the trigger too fast - sorry: http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Questions about History file
On Wed, Jan 08, 2014 at 07:10:10AM -0500, Tanstaafl wrote: Hi all, I routinely am logged into a server with multiple consoles (I log in with one (the same) regular user, then su - to root). This morning I tried to grep roots .bash_history for a command I ran some time ago, and it wasn't there. I know I ran it, so I'd like to configure my bash history so this doesn't happen again. Thinking about it a bit, the first issue I see is... when I am running multiple consoles, each one having been started by first logging in as my normal user, then su - to root, how does this affect the .bash_history file? It seems like there would be a collision of some kind, maybe result in the last one to log out 'winning' (that .bash_history is the one that is saved/stored) or something? Maybe... would it be possible to use different regular users, then when each one does the su - to root, have it create a separate .bash_history file based on the original username? That would be perfect. I was also considering something like setting HISTSIZE=###, then adding something to the logrotate.conf file to start rotating the history file, so I don't lose anything - but I'm not sure if that would even work. So, I'm interested in how others do this... especially on a system that has multiple users managing it. Thx... Charles Long ago living in a country far away on computers long since abandoned, some friendly sysadmin helped me set this up. For quite some time this has been on my TO-DO wishlist, so your query caused me to search the internet: http://mywiki.wooledge.org/BashFAQ/088 Hope this helps you and I both append our history for all open terminals. Bruce -- List replies preferred. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 14:36, schrieb Mick: I don't know if I am stating the obvious but just in case: Have a look here and set up your --python2 to reflect what you have installed. You may need to go at it in steps between versions. Oops! Pulled the trigger too fast - sorry: http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml Yep. I tried to install glibc-2.17 again and it failed again. Re-applied the 2.16-tarball ... python-3.3.2-r2 emerged fine, I assume I should also re-emerge dev-lang/python:2.7 ?
Re: [gentoo-user] Questions about History file
On 08/01/2014 14:10, Tanstaafl wrote: Hi all, I routinely am logged into a server with multiple consoles (I log in with one (the same) regular user, then su - to root). This morning I tried to grep roots .bash_history for a command I ran some time ago, and it wasn't there. I know I ran it, so I'd like to configure my bash history so this doesn't happen again. Thinking about it a bit, the first issue I see is... when I am running multiple consoles, each one having been started by first logging in as my normal user, then su - to root, how does this affect the .bash_history file? It seems like there would be a collision of some kind, maybe result in the last one to log out 'winning' (that .bash_history is the one that is saved/stored) or something? Maybe... would it be possible to use different regular users, then when each one does the su - to root, have it create a separate .bash_history file based on the original username? That would be perfect. I was also considering something like setting HISTSIZE=###, then adding something to the logrotate.conf file to start rotating the history file, so I don't lose anything - but I'm not sure if that would even work. So, I'm interested in how others do this... especially on a system that has multiple users managing it. Thx... Charles Most important thing is to understand that a shell history file is intended as a nice convenience for users. When the shell runs, it keep a history of that session in RAM, and when the shell exits properly it simple appends the list to the history file. It is just that simple, but of course there's no guarantees at all. Two sessions don't exit at exactly the same time, so as far as I know it's simple fs mechanisms that prevent clobbering. If a command that should be in history isn't, then it's that the session has not yet closed, it does without exiting properly, or the command was run 500 commands ago. I don't know of any bash mechanism to easily create and use different history files depending on which user did the su. You would probably have to concoct a custom wrapper script for this. I do know that once, long ago, I tried to get bash to do proper command logging for our general-purpose gateway hosts that have 500+ users. It was a nightmare and I eventually concluded that history, logging and such things are 100% the province of the user and not the sysadmin. It just caused way more trouble than it solved. I suspect what you are looking for is very much in the same category. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] updating old box: segfaults with python
On Wed, 08 Jan 2014 12:54:09 +0100, Stefan G. Weichinger wrote:
# python-updater
/usr/sbin/python-updater: Zeile 146: 28887 Speicherzugriffsfehler
/usr/bin/portageq has_version / ${1}
/usr/sbin/python-updater: Zeile 146: 2 Speicherzugriffsfehler
/usr/bin/portageq has_version / ${1}
* Python 2 and Python 3 not installed
Is eselect python pointing to valid python 2 and 3 versions? Can you run
python2 and python3 in a terminal?
--
Neil Bothwick
When told the reason for Daylight Saving time the old Indian said...
Only a white man would believe that you could cut a foot off the top of a
blanket And sew it to the bottom of a blanket and have a longer blanket.
signature.asc
Description: PGP signature
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 17:20, schrieb Neil Bothwick:
On Wed, 08 Jan 2014 12:54:09 +0100, Stefan G. Weichinger wrote:
# python-updater /usr/sbin/python-updater: Zeile 146: 28887
Speicherzugriffsfehler /usr/bin/portageq has_version / ${1}
/usr/sbin/python-updater: Zeile 146: 2
Speicherzugriffsfehler /usr/bin/portageq has_version / ${1} *
Python 2 and Python 3 not installed
Is eselect python pointing to valid python 2 and 3 versions? Can
you run python2 and python3 in a terminal?
Yes, since untaring glibc-2.16.
glibc-2.17 does not emerge --- it fails and leaves me with the
segfaults ... only fix so far is unpacking that 2.16-tarball
http://tinderbox.dev.gentoo.org/default-linux/x86/sys-libs/ only has
2.16 ... portage on the given system thinks 2.17 is installed so I
can't (re-)emerge 2.16 because downgrading is not supported.
I don't want to keep it this way as it isn't really consistent ... so
I should find out why glibc-2.17 does not install, right?
trying emerge -B glibc for now ... step by step.
[gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
I just updated glibc to 2.1.17, and got the following error at the very end of the emerge: /usr/bin/python2.7: relocation error: /lib64/libresolv.so.2: symbol __sendmmsg, version GLIBC_PRIVATE not defined in file libc.so.6 with lin k time reference Is this something to worry about?
Re: [gentoo-user] updating old box: segfaults with python
Am 08.01.2014 17:41, schrieb Stefan G. Weichinger:
trying emerge -B glibc for now ... step by step.
emerge -B : success
emerge -K: same failure
The unpacking of glibc seems to somehow break python while emerge still
runs ... at least that is my impression.
Manually unpacking the 2.17-tarball does not fix python ...
So I am back with the manual glibc-2.16 ... and have the correctly built
glibc-2.17.tbz2 as well.
So how to fix that?
Use another python? Right now I have:
# eselect python list
Available Python interpreters:
[1] python2.4
[2] python2.5
[3] python2.6
[4] python2.7 *
[5] python3.1
[6] python3.2
[7] python3.3
In make.conf:
PYTHON_TARGETS=python2_6 python2_7 python3_2
PYTHON_SINGLE_TARGET=python2_7
I assume I could get rid of some releases ... but currently I am
hesitating ;-)
2.7.5-r3 and 3.2.5-r3 rebuilt fine here today.
used python-3.2 now ... next failure to install the tbz2
What do I get?
-
Installing (1 of 1) sys-libs/glibc-2.17
* Defaulting /etc/host.conf:multi to on
* ERROR: sys-libs/glibc-2.17::gentoo failed (prerm phase):
* eutils.eclass could not be found by inherit()
*
* Call stack:
* ebuild.sh, line 545: Called source
'/var/db/pkg/sys-libs/glibc-2.17/glibc-2.17.ebuild'
* glibc-2.17.ebuild, line 5: Called inherit 'eutils' 'versionator'
'toolchain-funcs' 'flag-o-matic' 'gnuconfig' 'multilib' 'systemd'
'unpacker' 'multiprocessing'
* ebuild.sh, line 257: Called die
* The specific snippet of code:
* [[ -z ${location} ]] die ${1}.eclass could not be found by
inherit()
*
* If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.17::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.17::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.17/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.17/temp/die.env'.
* Working directory: '/usr/lib/portage/pym'
* S: '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.17/work/glibc-2.17'
/usr/lib/portage/bin/isolated-functions.sh: Zeile 109: 17558
Speicherzugriffsfehler $PORTAGE_BIN_PATH/ebuild-ipc exit 1
* The ebuild phase 'prerm' has exited unexpectedly. This type of behavior
* is known to be triggered by things such as failed variable assignments
* (bug #190128) or bad substitution errors (bug #200313). Normally, before
* exiting, bash should have displayed an error message above. If bash did
* not produce an error message above, it's possible that the ebuild has
* called `exit` when it should have called `die` instead. This behavior
* may also be triggered by a corrupt bash binary or a hardware problem
* such as memory or cpu malfunction. If the problem is not reproducible or
* it appears to occur randomly, then it is likely to be triggered by a
* hardware problem. If you suspect a hardware problem then you should try
* some basic hardware diagnostics such as memtest. Please do not report
* this as a bug unless it is consistently reproducible and you are sure
* that your bash binary and hardware are functioning properly.
* QA Notice: ECLASS 'eutils' inherited illegally in sys-libs/glibc-2.17
* ERROR: sys-libs/glibc-2.17::gentoo failed:
* eutils.eclass could not be found by inherit()
*
* Call stack:
* misc-functions.sh, line 17: Called source
'/usr/lib/portage/bin/ebuild.sh'
* ebuild.sh, line 545: Called source
'/var/db/pkg/sys-libs/glibc-2.17/glibc-2.17.ebuild'
* glibc-2.17.ebuild, line 5: Called inherit 'eutils' 'versionator'
'toolchain-funcs' 'flag-o-matic' 'gnuconfig' 'multilib' 'systemd'
'unpacker' 'multiprocessing'
* ebuild.sh, line 257: Called die
* The specific snippet of code:
* [[ -z ${location} ]] die ${1}.eclass could not be found by
inherit()
*
... and way more.
I tried to remove /var/db/pkg/sys-libs/glibc-2.17/environment.bz2 ...
didn't help.
Looking forward to some clever suggestions ;-)
Stefan
Re: [gentoo-user] Question re: dovecot + filesystem permissions for vmail dirs
On 2014-01-08 12:35 AM, J. Roeleveld jo...@antarean.org wrote: Tanstaafl tansta...@libertytrek.org wrote: Current permissions are: Virtual domain dirs: /var/vmail/example1.com 777 /var/vmail/example2.com 777 Do yourself a favour and reconsider the above 777 really carefully. I have never needed to set anything wide open like that. Thanks - figured that, and I will, but like I said... I want to do this right the first time, because I'll have to do a bit of work on my backups to keep everything the same and prevent rsnapshot from resyncing the entire mailstore.
Re: [gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
On 2014-01-08 11:54 AM, Tanstaafl tansta...@libertytrek.org wrote: I just updated glibc to 2.1.17, and got the following error at the very end of the emerge: /usr/bin/python2.7: relocation error: /lib64/libresolv.so.2: symbol __sendmmsg, version GLIBC_PRIVATE not defined in file libc.so.6 with lin k time reference Is this something to worry about? After some googling... Could this have anything to do with the fact that I don't have either of these set in /etc/portage/make.comf: PYTHON_TARGETS=python2_7 python3_3 PYTHON_SINGLE_TARGET=python2_7 ? Just added them and am remerging glibc... sill see what happens...
Re: [gentoo-user] Chmod Failed
On Sun, 29 Dec 2013 19:23:41 +0800 Oli o...@kernelpanic.ch wrote:
Had a similar issue not too long ago. It was down to a block error
on the hard drive. After a full check and repair, it worked well.
On host system could install dbus without problem.
siefke ~ $ su -c emerge -pqv =sys-apps/dbus-1.6.12::gentoo
Passwort:
[ebuild R ] sys-apps/dbus-1.6.12 USE=-X -debug -doc (-selinux)
-static-libs -systemd {-test}
But in chroot want not install. I has read something about grub must installed
i have but nothing changed.
ks3374456 portage # emerge --info =sys-apps/dbus-1.6.12::gentoo
Portage 2.2.7 (default/linux/x86/13.0, gcc-4.7.3, glibc-2.16.0,
3.10.9--grs-ipv6-64 i686)
=
System Settings
=
System uname:
Linux-3.10.9--grs-ipv6-64-i686-Intel-R-_Atom-TM-_CPU_N2800_@_1.86GHz-with-gentoo-2.2
KiB Mem: 2021976 total,401612 free
KiB Swap:2096124 total, 2093284 free
Timestamp of tree: Tue, 07 Jan 2014 21:30:01 +
ld GNU ld (GNU Binutils) 2.23.1
ccache version 3.1.9 [enabled]
app-shells/bash: 4.2_p45
dev-lang/python: 2.7.5-r3, 3.3.2-r2
dev-util/ccache: 3.1.9
dev-util/pkgconfig: 0.28
sys-apps/baselayout: 2.2
sys-apps/openrc: 0.12.4
sys-apps/sandbox: 2.6-r1
sys-devel/autoconf: 2.69
sys-devel/automake: 1.13.4
sys-devel/binutils: 2.23.1
sys-devel/gcc:4.7.3-r1
sys-devel/gcc-config: 1.7.3
sys-devel/libtool:2.4.2
sys-devel/make: 3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc: 2.16.0
Repositories: gentoo
ACCEPT_KEYWORDS=x86
ACCEPT_LICENSE=* -@EULA
CBUILD=i686-pc-linux-gnu
CFLAGS=-O2 -march=i686 -pipe
CHOST=i686-pc-linux-gnu
CONFIG_PROTECT=/etc /usr/share/easy-rsa
CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/gconf
/etc/gentoo-release /etc/php/apache2-php5.5/ext-active/
/etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo
CXXFLAGS=-O2 -march=i686 -pipe
DISTDIR=/usr/portage/distfiles
FCFLAGS=-O2 -march=i686 -pipe
FEATURES=assume-digests binpkg-logs buildpkg ccache config-protect-if-modified
distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned
sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans
userfetch userpriv usersandbox usersync
FFLAGS=-O2 -march=i686 -pipe
GENTOO_MIRRORS=http://distfiles.gentoo.org;
LANG=de_DE.UTF-8
LDFLAGS=-Wl,-O1 -Wl,--as-needed
MAKEOPTS=-j4
PKGDIR=/usr/portage/packages
PORTAGE_CONFIGROOT=/
PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times
--omit-dir-times --compress --force --whole-file --delete --stats
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages
PORTAGE_TMPDIR=/var/tmp
PORTDIR=/usr/portage
PORTDIR_OVERLAY=
USE=X acl alsa berkdb bindist bzip2 cdr cli cracklib crypt cxx dri dvd fortran
gdbm gtk iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pcre python
readline session sse sse2 sse3 ssl ssse3 tcpd truetype unicode x86 zlib
ABI_X86=32 ALSA_CARDS=hda_intel APACHE2_MODULES=authn_core authz_core
socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm
authn_default authn_file authz_dbm authz_default authz_groupfile authz_host
authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir
disk_cache env expires ext_filter file_cache filter headers include info
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling
status unique_id userdir usertrack vhost_alias CALLIGRA_FEATURES=kexi words
flow plan sheets stage tables krita karbon braindump author CAMERAS=ptp2
COLLECTD_PLUGINS=df interface irq load memory rrdtool swap syslog
ELIBC=glibc GPSD_PROTOCOLS=ashtech aivdm earthmate evermore fv18 garmin
garmin
txt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore
rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx
INPUT_DEVICES=evdev void synaptics KERNEL=linux LCD_DEVICES=bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text
LIBREOFFICE_EXTENSIONS=presenter-console presenter-minimizer LINGUAS=de en
ar fr OFFICE_IMPLEMENTATION=libreoffice PHP_TARGETS=php5-5
PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python3_3 python2_7
RUBY_TARGETS=ruby20 ruby19 USERLAND=GNU VIDEO_CARDS=intel
XTABLES_ADDONS=quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface
geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac
delude chaos account
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL,
PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
When try install bin package come same mistake. Chmod Failed. I understand it
not.
Can someone help, or
[gentoo-user] Re: updating old box: segfaults with python
On 2014-01-08, Stefan G. Weichinger li...@xunil.at wrote: Looking forward to some clever suggestions ;-) Well, I'd start by running memtest86 overnight just to eliminate the possibility of marginal memory. But, if memory serves, this is a remote server at a customer site -- so that may not be a viable option. -- Grant Edwards grant.b.edwardsYow! ... the MYSTERIANS are at in here with my CORDUROY gmail.comSOAP DISH!!
Re: [gentoo-user] disable numlock on netbook
On 01/05/2014 01:41 PM, Alan McKinnon wrote: I have Gentoo on a first gen Acer Aspire One. The teeny keyboard doesn't have a numpad, it's simulated by using the right-hand bunch of keys and you engage it with Fn-F11 It's recently started booting up with the numpad on which is annoying at first login as my username is not a3an0 The Num LED is also off at this stage. There used to be a way to set numlock on or off in baselayout/openrc but now I can't find it. grep -r numlock /etc returns nothing relevant, and /etc/init.d/numlock is to enable it with no function to disable it (I have this script disable in default runlevel) How is this done these days? Should I call setleds in rc.local somewhere? Are you booting into X? If you are try x11-misc/numlockx. I think all you have to do is use `numlockx off` and it should turn it off. I had to do that for my laptop, same problem. Dan
Re: [gentoo-user] Questions about History file
Bruce Hill da...@happypenguincomputers.com wrote: On Wed, Jan 08, 2014 at 07:10:10AM -0500, Tanstaafl wrote: Hi all, I routinely am logged into a server with multiple consoles (I log in with one (the same) regular user, then su - to root). This morning I tried to grep roots .bash_history for a command I ran some time ago, and it wasn't there. I know I ran it, so I'd like to configure my bash history so this doesn't happen again. Thinking about it a bit, the first issue I see is... when I am running multiple consoles, each one having been started by first logging in as my normal user, then su - to root, how does this affect the .bash_history file? It seems like there would be a collision of some kind, maybe result in the last one to log out 'winning' (that .bash_history is the one that is saved/stored) or something? Maybe... would it be possible to use different regular users, then when each one does the su - to root, have it create a separate .bash_history file based on the original username? That would be perfect. I was also considering something like setting HISTSIZE=###, then adding something to the logrotate.conf file to start rotating the history file, so I don't lose anything - but I'm not sure if that would even work. So, I'm interested in how others do this... especially on a system that has multiple users managing it. Thx... Charles Long ago living in a country far away on computers long since abandoned, some friendly sysadmin helped me set this up. For quite some time this has been on my TO-DO wishlist, so your query caused me to search the internet: http://mywiki.wooledge.org/BashFAQ/088 Hope this helps you and I both append our history for all open terminals. Thanks, I thought history was always appended,but now I know. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Questions about History file
http://mywiki.wooledge.org/BashFAQ/088 The advice here to use awk to compress log files seems a bit dated. Bash now allows you to set in .bashrc: export HISTCONTROL=erasedups I don't know that there's an ultimate answer to history management. Personally, for years I have had my prompt set to show the history number of the current command, so I can look up on the screen and just enter !505 to reuse a previous comment. I reality, I never use this, but a terminal wouldn't feel like a terminal, for me now, without having numbered prompts up the screen. More practically I tend to use tmux and open new panes for each task or task group, keeping task sets short and closing the pane when I've done that little job (or sub-job). This allows Bash itself to manage its history more efficiently. If I need to use a previous command and ctrl-R doesn't easily find it, I tend to just `history | grep hint` to find it. I also set HISTSIZE and HISTFILESIZE to 900, so to maximise the number of previous commands available to me by typing only a three digit !321. Stroller.
Re: [gentoo-user] Re: updating old box: segfaults with python
Am 08.01.2014 19:47, schrieb Grant Edwards: On 2014-01-08, Stefan G. Weichinger li...@xunil.at wrote: Looking forward to some clever suggestions ;-) Well, I'd start by running memtest86 overnight just to eliminate the possibility of marginal memory. But, if memory serves, this is a remote server at a customer site -- so that may not be a viable option. Sure. Good suggestion. I would do that if I had physical access to the server ... for now I don't. And I assume the box would behave much more problematic if the memory was faulty. So far it is only related to this python/glibc-issue. I emerge dozens of other packages without a problem in the last few hours. Thanks anyway ... if I have to run memtest and you were right I will let you know ;-) S
Re: [gentoo-user] Chmod Failed
Hello, i has found the problem. That was the kernel with gresecurity patch. I has read that can give trouble and now i change kernel and dbus is installed. Thanks for help Nice Day Silvio
[gentoo-user] media-libs/harfbuzz-0.9.23::gentoo failed (compile phase)
tried to merge libreoffice-bin, and the dependency failed to compile. Any ideas what might be the problem or how to solve that?! http://pastebin.com/raw.php?i=dwMcutSq Tamer
Re: [gentoo-user] media-libs/harfbuzz-0.9.23::gentoo failed (compile phase)
On Thu, 09 Jan 2014 03:06:05 +0100 Tamer Higazi th9...@googlemail.com wrote: tried to merge libreoffice-bin, and the dependency failed to compile. Any ideas what might be the problem or how to solve that?! http://pastebin.com/raw.php?i=dwMcutSq Can you attach that to https://bugs.gentoo.org/show_bug.cgi?id=497562 so the maintainers can resolve this? You can CC yourself on that bug to keep track of its resolution. -- 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
Re: [gentoo-user] updating old box: segfaults with python
On Wednesday 08 Jan 2014 14:37:00 Stefan G. Weichinger wrote: Am 08.01.2014 14:36, schrieb Mick: I don't know if I am stating the obvious but just in case: Have a look here and set up your --python2 to reflect what you have installed. You may need to go at it in steps between versions. Oops! Pulled the trigger too fast - sorry: http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml Yep. I tried to install glibc-2.17 again and it failed again. Re-applied the 2.16-tarball ... python-3.3.2-r2 emerged fine, I assume I should also re-emerge dev-lang/python:2.7 ? If dev-lang/python:2.7 does not allow you to emerge glibc then use eselect to switch --python2 to an older python available in that box and try emerging glibc with that. You may have to repeat this until successful (hopefully) with dev-lang/python:2.7. I don't know if you would need to update glibc in smaller steps (I can't recall how many versions were there in between) but this can be a painful process. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
