Re: [gentoo-user] Default settings in /etc/rc.conf
On Monday 06 Feb 2012 05:10:45 Michael Orlitzky wrote: On 02/05/2012 03:01 PM, Alan McKinnon wrote: You cannot trust the commented examples in rc.conf to be the defaults. I reckon they are just that - typical examples. If you search through rc.conf for the word default you find quite a few cases where the text says what the default is and the example is something different. In other words, the default is, um, not actually documented anywhere. This is a bit of a fail actually as you now have to fiddle with settings, make them this, reboot, make them that, reboot, see what the difference is. Sloppy maintenance if you ask me. I'd advise you to file a bug (feature request) asking for the defaults to be clearly documented where someone other than the principle dev can find them. You guys already did this thread: http://archives.gentoo.org/gentoo-user/msg_513fd0fbcdf0fc95f5561684e80301f8 .xml It is both sloppy and unnecessarily confusing that some apps config files have the default settings commented out and others not. This is getting more complicated when some of these settings are optional. Of course, when commented out an optional setting is not a default - but how would the unsuspecting user know that? My workaround is to explicitly set any settings that I know I need/want set, but that makes it difficult for me to answer what the default settings are (unless devs comments say so). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Change in ethernet .config layout kernel 3.2.1, affects oldconfig
On Monday 06 Feb 2012 05:47:53 Walter Dnes wrote: Heads up... the network ethernet device drivers aettings are laid out differently in 3.2.1, and make oldconfig misses a few items. The new layout route goes like so... Device Drivers --- [*] Network device support --- [*] Ethernet driver support --- This brings you to a menu by manufacturer. The drivers are no longer divided by speed. make oldconfig misses a few items. I ended up writing down my settings in 3.0.6 and manually adding them to 3.2.1 when running make oldconfig. Hmm ... I'm almost sure I *only* used oldconfig from 3.0.6 to 3.2.1-gentoo-r2 and didn't have such a problem. I remember noticing that the tree of options changed and afterwards went into make menuconfig to see if anything was missed out, but I did not make any changes there (AFAIR). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Change in ethernet .config layout kernel 3.2.1, affects oldconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06.02.2012 10:46, Mick wrote: On Monday 06 Feb 2012 05:47:53 Walter Dnes wrote: Heads up... the network ethernet device drivers aettings are laid out differently in 3.2.1, and make oldconfig misses a few items. The new layout route goes like so... Device Drivers --- [*] Network device support --- [*] Ethernet driver support --- This brings you to a menu by manufacturer. The drivers are no longer divided by speed. make oldconfig misses a few items. I ended up writing down my settings in 3.0.6 and manually adding them to 3.2.1 when running make oldconfig. Hmm ... I'm almost sure I *only* used oldconfig from 3.0.6 to 3.2.1-gentoo-r2 and didn't have such a problem. I remember noticing that the tree of options changed and afterwards went into make menuconfig to see if anything was missed out, but I did not make any changes there (AFAIR). If I recall it correctly, for me most drivers were enabled by default after making oldconfig. I later changed it back to just what I need(TM) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPL6y1AAoJEJwwOFaNFkYc0AEH/23Q2vK91EG3BtxVRV1c6pqS omoc3wLTKmkJXQl1u179b+mD8Ag0hg1T6EwiWhLCOi2OG5T7KTXlN2sm+ggU4o8w WIQMsCKFqG3kG0bldOGV4Uk/duuYP37mlH9LSqt3NPA8xxY/lV3RFHrMHBQQxa+t p85gW6Ctg+dACGyksebplNjQapyFvRUBHp8xPK2Kvrwgw/CRZAIwzr+k5HzXCfHq Fg5/kl4qf5jLb5JIYtH3qNn4SoGueCtv3MlrfcNNbaQZq9L4zVCSWwFxhoyKMORb qZGF2p8W0bJ3gGZh6Ha6YFOeu+HlaO+uSs2WT8mtpz07vT5BsaaZd7NLTT5h8UY= =cnDJ -END PGP SIGNATURE-
[gentoo-user] HEADS UP - postfix-2.9.0 is broken
Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix And after re-emerging postfix-2.8.8 I couldn't do /etc/init.d/postfix restart since openrc was thinking it's still running. Since it was urgent I rebooted my system. Does anybody where openrc stores the info that a daemon is running? Thanks, Helmut.
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06.02.2012 12:06, Helmut Jarausch wrote: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix And after re-emerging postfix-2.8.8 I couldn't do /etc/init.d/postfix restart since openrc was thinking it's still running. Since it was urgent I rebooted my system. Does anybody where openrc stores the info that a daemon is running? Thanks, Helmut. Hi, as far, as I know it is searching for a pid-file. Many start-up-scripts also have a zap option If you run /etc/init.d/startup-script zap it resets the status to stopped. I don't know, if postfix has that option though. So long.. Hinnerk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPL7g8AAoJEJwwOFaNFkYcgPIH/1MVjvN6ra8smBiGFQHZbTvI lCIVSYt6/Vkogjd93K03y7eKPobuEV+IaNWnNmB2pSHgAzg9M1yHEytqCWLo+Ska 8ixuPHea8NMl3gJYxsFAvcAnTZpH2xFlIw5IvY5XLHZ8pOrZ2oWdQsrFZu9DvYae I8BNoJsgqiobd/K1HqG+pFs1BKeyh8+bXZKx34/SbatEcKArVvGsEYukb8ebZcxx ZcB+vld/1bWCo34XehzA8SVsoC0cKMi93Pj+YLcW9W2U5AVSRnPx/pcG1LY4fpyA c44g4iMS7t3dcYo5isMWvj1LILq90UrhLYNEvsDXzETdz1z72qAOaU56rA7dBio= =j/Pl -END PGP SIGNATURE-
Re: [gentoo-user] Warning about old init scripts when updating dev-db/mysql-init-scripts-2.0_pre1-r2
On 2012-02-05 3:06 PM, Alan McKinnon alan.mckin...@gmail.com wrote:
In your shoes what I would be doing now is backup your entire mysql
install (everything listed in equery files mysql), delete the package
(emerge -C) and remerge mysql.
Then check if starting and stopping works correctly. I suspect you'll
find it will. Now you just need to diff these new files with your
backups and find differences.
Yes, this is sort of the long way round but you're not having much luck
asking anyone seen this before?, so now it's time to bring out the
big guns
Well, I'd much prefer some more basic troubleshooting first...
I've asked for some kind soul/souls to share their init scripts so I can
compare - but I guess I couldg go first... here is the contents of
/etc/init.d/mysql:
#!/sbin/runscript
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/dev-db/mysql-init-scripts/files/mysql-5.1.53-init.d,v
1.1 2011/01/13 20:06:06 robbat2 Exp $
depend() {
use net.lo
# localmount needed for $basedir
need localmount
}
get_config() {
my_print_defaults --config-file=$1 mysqld |
sed -n -e s/^--$2=//p
}
mysql_svcname() {
local ebextra=
case ${SVCNAME} in
mysql*) ;;
*) ebextra= (mysql) ;;
esac
echo ${SVCNAME}${ebextra}
}
start() {
# Check for old conf.d variables that mean migration was not
yet done.
local varlist=${!mysql_slot_*} ${!MYSQL_BLOG_PID_FILE*}
${!STOPTIMEOUT*}
varlist=${varlist// /}
# Yes, MYSQL_INIT_I_KNOW_WHAT_I_AM_DOING is a hidden variable.
# It does have a use in testing, as it is possible to build a
config file
# that works with both the old and new init scripts simulateously.
if [ -n ${varlist} -a -z
${MYSQL_INIT_I_KNOW_WHAT_I_AM_DOING} ]; then
eerror You have not updated your conf.d for the new
mysql-init-scripts-2 revamp.
eerror Not proceeding because it may be dangerous.
return 1
fi
# Now we can startup
ebegin Starting $(mysql_svcname)
MY_CNF=${MY_CNF:-/etc/${SVCNAME}/my.cnf}
if [ ! -r ${MY_CNF} ] ; then
eerror Cannot read the configuration file \`${MY_CNF}'
return 1
fi
# tail -n1 is critical as these we only want the last instance
of the option
local basedir=$(get_config ${MY_CNF} basedir | tail -n1)
local datadir=$(get_config ${MY_CNF} datadir | tail -n1)
local pidfile=$(get_config ${MY_CNF} pid-file | tail -n1)
local socket=$(get_config ${MY_CNF} socket | tail -n1)
if [ ! -d ${datadir} ] ; then
eerror MySQL datadir \`${datadir}' is empty or invalid
eerror Please check your config file \`${MY_CNF}'
return 1
fi
if [ ! -d ${datadir}/mysql ] ; then
eerror You don't appear to have the mysql database
installed yet.
eerror Please run /usr/bin/mysql_install_db to have
this done...
return 1
fi
local piddir=${pidfile%/*}
if [ ! -d $piddir ] ; then
mkdir $piddir \
chown mysql $piddir
rc=$?
if [ $rc -ne 0 ]; then
eerror Directory $piddir for pidfile does not
exist and cannot be created
return 1
fi
fi
local startup_timeout=${STARTUP_TIMEOUT:-900}
local startup_early_timeout=${STARTUP_EARLY_TIMEOUT:-1000}
local tmpnice=${NICE:+--nicelevel }${NICE}
local tmpionice=${IONICE:+--ionice }${IONICE}
start-stop-daemon \
${DEBUG/*/--verbose} \
--start \
--exec ${basedir}/sbin/mysqld \
--pidfile ${pidfile} \
--background \
--wait ${startup_early_timeout} \
${tmpnice} \
${tmpionice} \
-- --defaults-file=${MY_CNF} ${MY_ARGS}
local ret=$?
if [ ${ret} -ne 0 ] ; then
eend ${ret}
return ${ret}
fi
ewaitfile ${startup_timeout} ${socket}
eend $? || return 1
save_options pidfile ${pidfile}
save_options basedir ${basedir}
}
stop() {
ebegin Stopping $(mysql_svcname)
local pidfile=$(get_options pidfile)
local basedir=$(get_options basedir)
local stop_timeout=${STOP_TIMEOUT:-120}
start-stop-daemon \
${DEBUG/*/--verbose} \
--stop \
--exec ${basedir}/sbin/mysqld \
Re: [gentoo-user] Warning about old init scripts when updating dev-db/mysql-init-scripts-2.0_pre1-r2
On Mon, 06 Feb 2012 07:03:19 -0500
Tanstaafl tansta...@libertytrek.org wrote:
On 2012-02-05 3:06 PM, Alan McKinnon alan.mckin...@gmail.com wrote:
In your shoes what I would be doing now is backup your entire mysql
install (everything listed in equery files mysql), delete the
package (emerge -C) and remerge mysql.
Then check if starting and stopping works correctly. I suspect
you'll find it will. Now you just need to diff these new files with
your backups and find differences.
Yes, this is sort of the long way round but you're not having much
luck asking anyone seen this before?, so now it's time to bring
out the big guns
Well, I'd much prefer some more basic troubleshooting first...
I've asked for some kind soul/souls to share their init scripts so I
can compare - but I guess I couldg go first... here is the contents
of /etc/init.d/mysql:
#!/sbin/runscript
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/dev-db/mysql-init-scripts/files/mysql-5.1.53-init.d,v
1.1 2011/01/13 20:06:06 robbat2 Exp $
depend() {
use net.lo
# localmount needed for $basedir
need localmount
}
get_config() {
my_print_defaults --config-file=$1 mysqld |
sed -n -e s/^--$2=//p
}
mysql_svcname() {
local ebextra=
case ${SVCNAME} in
mysql*) ;;
*) ebextra= (mysql) ;;
esac
echo ${SVCNAME}${ebextra}
}
start() {
# Check for old conf.d variables that mean migration was not
yet done.
local varlist=${!mysql_slot_*} ${!MYSQL_BLOG_PID_FILE*}
${!STOPTIMEOUT*}
varlist=${varlist// /}
# Yes, MYSQL_INIT_I_KNOW_WHAT_I_AM_DOING is a hidden
variable. # It does have a use in testing, as it is possible to build
a config file
# that works with both the old and new init scripts
simulateously. if [ -n ${varlist} -a -z
${MYSQL_INIT_I_KNOW_WHAT_I_AM_DOING} ]; then
eerror You have not updated your conf.d for the new
mysql-init-scripts-2 revamp.
eerror Not proceeding because it may be dangerous.
return 1
fi
# Now we can startup
ebegin Starting $(mysql_svcname)
MY_CNF=${MY_CNF:-/etc/${SVCNAME}/my.cnf}
if [ ! -r ${MY_CNF} ] ; then
eerror Cannot read the configuration file
\`${MY_CNF}' return 1
fi
# tail -n1 is critical as these we only want the last
instance of the option
local basedir=$(get_config ${MY_CNF} basedir | tail -n1)
local datadir=$(get_config ${MY_CNF} datadir | tail -n1)
local pidfile=$(get_config ${MY_CNF} pid-file | tail -n1)
local socket=$(get_config ${MY_CNF} socket | tail -n1)
if [ ! -d ${datadir} ] ; then
eerror MySQL datadir \`${datadir}' is empty or
invalid eerror Please check your config file \`${MY_CNF}'
return 1
fi
if [ ! -d ${datadir}/mysql ] ; then
eerror You don't appear to have the mysql database
installed yet.
eerror Please run /usr/bin/mysql_install_db to have
this done...
return 1
fi
local piddir=${pidfile%/*}
if [ ! -d $piddir ] ; then
mkdir $piddir \
chown mysql $piddir
rc=$?
if [ $rc -ne 0 ]; then
eerror Directory $piddir for pidfile does
not exist and cannot be created
return 1
fi
fi
local startup_timeout=${STARTUP_TIMEOUT:-900}
local startup_early_timeout=${STARTUP_EARLY_TIMEOUT:-1000}
local tmpnice=${NICE:+--nicelevel }${NICE}
local tmpionice=${IONICE:+--ionice }${IONICE}
start-stop-daemon \
${DEBUG/*/--verbose} \
--start \
--exec ${basedir}/sbin/mysqld \
--pidfile ${pidfile} \
--background \
--wait ${startup_early_timeout} \
${tmpnice} \
${tmpionice} \
-- --defaults-file=${MY_CNF} ${MY_ARGS}
local ret=$?
if [ ${ret} -ne 0 ] ; then
eend ${ret}
return ${ret}
fi
ewaitfile ${startup_timeout} ${socket}
eend $? || return 1
save_options pidfile ${pidfile}
save_options basedir ${basedir}
}
stop() {
ebegin Stopping $(mysql_svcname)
local pidfile=$(get_options pidfile)
local basedir=$(get_options basedir)
local stop_timeout=${STOP_TIMEOUT:-120}
start-stop-daemon \
${DEBUG/*/--verbose} \
--stop \
[gentoo-user] Re: HEADS UP - postfix-2.9.0 is broken
On Mon, 06 Feb 2012 12:23:40 +0100, Hinnerk van Bruinehsen wrote: If you run /etc/init.d/startup-script zap it resets the status to stopped. I don't know, if postfix has that option though. Doesn't work in this case. Simply killing the postfix daemons manually however does. The problem can also simply be fixed by editing the daemon_directory setting in /etc/postfix/main.cf. The version number is still funny though. -h
[gentoo-user] Genkernel 3.4.24 broken?
I was just compiling my kernel using genkernel, and it seems genkernel 3.4.24 is broken. I have specified INSTALL=YES in /etc/genkernel.conf; the installtion does not happen, instead awk throws an error saying failed to read /var/tmp/genkernel/random decimal number/grub.map no such file or directory. -- Nilesh Govindrajan http://nileshgr.com
Re: [gentoo-user] firefox-9.0 won't compile
Am 06.02.2012 05:56, schrieb Michael Mol: On Fri, Feb 3, 2012 at 8:52 PM, Grant emailgr...@gmail.com wrote: Does anyone have any ideas on this? I just completed an emerge -e world so I don't think anything needs to be re-emerged. Everything compiles fine except for gcc-4.5.3-r1 (I'm on gcc-4.3.4) and firefox-9.0: /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp: In function 'void* MapAlignedPages(size_t, size_t)': /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp:243: error: pointer of type 'void *' used in arithmetic /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp:243: error: pointer of type 'void *' used in arithmetic That looks like a change in how the compiler treats bad code, or the introduction of bad code in an updated version of Firefox. The compiler can't sanely do pointer arithmetic without knowing the pointer type. Looks like the version you're compiling with throws an error on that. Are using anything like -Werror and/or -Wall in your CFLAGS? Yes, enabling --Wno-pointer-arith should help. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] firefox-9.0 won't compile
At first glance firefox uses the arithmetic pointer and Wno-pointer-arith lifts warnings or errors when used. This is what gcc says : error: pointer of type 'void *' used in arithmetic What it gives without this flag and Is there a particular reason for using this one ? Regards, On Mon, Feb 6, 2012 at 2:39 PM, Florian Philipp li...@binarywings.netwrote: Am 06.02.2012 05:56, schrieb Michael Mol: On Fri, Feb 3, 2012 at 8:52 PM, Grant emailgr...@gmail.com wrote: Does anyone have any ideas on this? I just completed an emerge -e world so I don't think anything needs to be re-emerged. Everything compiles fine except for gcc-4.5.3-r1 (I'm on gcc-4.3.4) and firefox-9.0: /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp: In function 'void* MapAlignedPages(size_t, size_t)': /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp:243: error: pointer of type 'void *' used in arithmetic /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp:243: error: pointer of type 'void *' used in arithmetic That looks like a change in how the compiler treats bad code, or the introduction of bad code in an updated version of Firefox. The compiler can't sanely do pointer arithmetic without knowing the pointer type. Looks like the version you're compiling with throws an error on that. Are using anything like -Werror and/or -Wall in your CFLAGS? Yes, enabling --Wno-pointer-arith should help. Regards, Florian Philipp
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Mon, Feb 6, 2012 at 5:06 AM, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix Maybe a side-effect of bug 401911 https://bugs.gentoo.org/show_bug.cgi?id=401911 BTW postfix 2.9.0 also fails to emerge if USE=vda because it tried to apply the patch for 2.8.5. (patch for 2.9.0 has not yet been released)
Re: [gentoo-user] Change in ethernet .config layout kernel 3.2.1, affects oldconfig
Mick wrote: On Monday 06 Feb 2012 05:47:53 Walter Dnes wrote: Heads up... the network ethernet device drivers aettings are laid out differently in 3.2.1, and make oldconfig misses a few items. The new layout route goes like so... Device Drivers --- [*] Network device support --- [*] Ethernet driver support --- This brings you to a menu by manufacturer. The drivers are no longer divided by speed. make oldconfig misses a few items. I ended up writing down my settings in 3.0.6 and manually adding them to 3.2.1 when running make oldconfig. Hmm ... I'm almost sure I *only* used oldconfig from 3.0.6 to 3.2.1-gentoo-r2 and didn't have such a problem. I remember noticing that the tree of options changed and afterwards went into make menuconfig to see if anything was missed out, but I did not make any changes there (AFAIR). I just went from 3.1.5 to 3.2.2 and it worked fine here. I know, different versions but it may help narrow down when things break. If it is broke. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
[gentoo-user] OT: SeAndroid build on a Gentoo System?
Hello, Has anyone built or installed SE-android onto a Sumsung Nexus (or similar) cell phone, using a Gentoo development environment? http://www.linuxfordevices.com/c/a/News/SE-Android-publicly-released/?kc=LNXDEVNL012612 http://selinuxproject.org/page/SEAndroid curiously, James
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
Am 06.02.2012 16:42, schrieb Paul Hartman: On Mon, Feb 6, 2012 at 5:06 AM, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix Maybe a side-effect of bug 401911 https://bugs.gentoo.org/show_bug.cgi?id=401911 BTW postfix 2.9.0 also fails to emerge if USE=vda because it tried to apply the patch for 2.8.5. (patch for 2.9.0 has not yet been released) I also rolled back to 2.8.8 for now ... 2.9.0 was working already, -r1 messed things up and after that even 2.9.0 didn't work again! Cleaning up for now and masked =2.9.0 for a start.
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. -- #163933
Re: [gentoo-user] Change in ethernet .config layout kernel 3.2.1, affects oldconfig
On Mon, Feb 6, 2012 at 8:11 AM, Dale rdalek1...@gmail.com wrote: Mick wrote: On Monday 06 Feb 2012 05:47:53 Walter Dnes wrote: Heads up... the network ethernet device drivers aettings are laid out differently in 3.2.1, and make oldconfig misses a few items. The new layout route goes like so... Device Drivers --- [*] Network device support --- [*] Ethernet driver support --- This brings you to a menu by manufacturer. The drivers are no longer divided by speed. make oldconfig misses a few items. I ended up writing down my settings in 3.0.6 and manually adding them to 3.2.1 when running make oldconfig. Hmm ... I'm almost sure I *only* used oldconfig from 3.0.6 to 3.2.1-gentoo-r2 and didn't have such a problem. I remember noticing that the tree of options changed and afterwards went into make menuconfig to see if anything was missed out, but I did not make any changes there (AFAIR). I just went from 3.1.5 to 3.2.2 and it worked fine here. I know, different versions but it may help narrow down when things break. If it is broke. ;-) Dale No problems here, but... 1) Yes, all my old network adapters were chosen correctly 2) ALL manufacturers were enabled unnecessarily 3) Interestingly, it seems that nearly every NIC coming after the last one of mine was also selected even though they hadn't been previously. So, while _I_ wouldn't say make oldconfig is broken, I _would_ say make oldconfig is broken. ;-) - Mark
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ...
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Mon, Feb 6, 2012 at 12:29 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ... So, to avoid this, when upgrading from 2.9.0-r1 to 2.9.0-r1, one should stop postfix, do the upgrade, and then start postfix again? that's how I read it. Alternately, copy the old init script prior to upgrade, use that script to bring postfix down, and use the new script to bring postfix up? -- :wq
[gentoo-user] hwclock -- sysclock and the ntp-client
Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer Is there anything else which I have to tweak to acchieve what I want? Thank you very much in advance for any help! Best regards, mcc PS: I need a correct hwclock since I want to wake the system via the hwclock.
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
BTW postfix 2.9.0 also fails to emerge if USE=vda because it tried to apply the patch for 2.8.5. (patch for 2.9.0 has not yet been released) And it also fails to start if have maps in hash format and emerge with USE=-berkdb. Luckily the error messages are informative enough... but let's say that a word of caution in the emerge message would have been welcomed. andrea
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
Am Montag, 6. Februar 2012, 12:47:45 schrieb Michael Mol: On Mon, Feb 6, 2012 at 12:29 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ... So, to avoid this, when upgrading from 2.9.0-r1 to 2.9.0-r1, one should stop postfix, do the upgrade, and then start postfix again? that's how I read it. Alternately, copy the old init script prior to upgrade, use that script to bring postfix down, and use the new script to bring postfix up? I just upgraded and did /etc/init.d/postfix restart and it worked. -- #163933
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Mon, Feb 6, 2012 at 1:00 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Montag, 6. Februar 2012, 12:47:45 schrieb Michael Mol: On Mon, Feb 6, 2012 at 12:29 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ... So, to avoid this, when upgrading from 2.9.0-r1 to 2.9.0-r1, one should stop postfix, do the upgrade, and then start postfix again? that's how I read it. Alternately, copy the old init script prior to upgrade, use that script to bring postfix down, and use the new script to bring postfix up? I just upgraded and did /etc/init.d/postfix restart and it worked. You reported success with 2.9.0. People are reporting difficulties with 2.9.0-r1. Two different versions, or so I assumed. -- :wq
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Mon, Feb 6, 2012 at 12:00 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Montag, 6. Februar 2012, 12:47:45 schrieb Michael Mol: On Mon, Feb 6, 2012 at 12:29 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ... So, to avoid this, when upgrading from 2.9.0-r1 to 2.9.0-r1, one should stop postfix, do the upgrade, and then start postfix again? that's how I read it. Alternately, copy the old init script prior to upgrade, use that script to bring postfix down, and use the new script to bring postfix up? I just upgraded and did /etc/init.d/postfix restart and it worked. The installation path was changed without an ebuild version number bump, so if you installed before that change, it would have had the same path as the old version.
Re: [gentoo-user] firefox-9.0 won't compile
At first glance firefox uses the arithmetic pointer and Wno-pointer-arith lifts warnings or errors when used. This is what gcc says : error: pointer of type 'void *' used in arithmetic What it gives without this flag and Is there a particular reason for using this one ? I'm having trouble following. I'm using: CFLAGS=-march=native -O2 -pipe Should I try with different flags? - Grant Does anyone have any ideas on this? I just completed an emerge -e world so I don't think anything needs to be re-emerged. Everything compiles fine except for gcc-4.5.3-r1 (I'm on gcc-4.3.4) and firefox-9.0: /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp: In function 'void* MapAlignedPages(size_t, size_t)': /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp:243: error: pointer of type 'void *' used in arithmetic /var/tmp/portage/www-client/firefox-9.0/work/mozilla-release/js/src/jsgcchunk.cpp:243: error: pointer of type 'void *' used in arithmetic That looks like a change in how the compiler treats bad code, or the introduction of bad code in an updated version of Firefox. The compiler can't sanely do pointer arithmetic without knowing the pointer type. Looks like the version you're compiling with throws an error on that. Are using anything like -Werror and/or -Wall in your CFLAGS? Yes, enabling --Wno-pointer-arith should help. Regards, Florian Philipp
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq
Re: [gentoo-user] /etc/mtab
I was just going over the Baselayout and OpenRC Migration Guide: http://www.gentoo.org/doc/en/openrc-migration.xml and I'm not sure how to make sure my /etc/mtab is set up according to the instructions: Previously, the initial rootfs entry was removed from /etc/mtab, and only the real root / entry was present. The duplicate rootfs item was actually added back during shutdown. In OpenRC, both entries must be present for full support of initramfs and tmpfs-on-root. This also means that less writing is required during shutdown. My systems have different /etc/mtab files but here is one: rootfs / rootfs rw 0 0 /dev/root / ext3 rw,noatime,errors=continue,barrier=1,data=ordered 0 0 proc /proc proc rw,relatime 0 0 rc-svcdir /lib/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 usbfs /proc/bus/usb usbfs rw,noexec,nosuid,devmode=0664,devgid=85 0 0 Should I change anything? I don't see a problem. The portion you quoted says exactly what mtab should contain, and your mtab does contain it. Your mtab looks correct to me. In what way do you believe that it is not? I just didn't understand the part about mtab in the Baselayout and OpenRC Migration Guide: http://www.gentoo.org/doc/en/openrc-migration.xml Thanks for checking it for me. - Grant
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
Am Montag, 6. Februar 2012, 12:05:38 schrieb Paul Hartman: On Mon, Feb 6, 2012 at 12:00 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Montag, 6. Februar 2012, 12:47:45 schrieb Michael Mol: On Mon, Feb 6, 2012 at 12:29 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ... So, to avoid this, when upgrading from 2.9.0-r1 to 2.9.0-r1, one should stop postfix, do the upgrade, and then start postfix again? that's how I read it. Alternately, copy the old init script prior to upgrade, use that script to bring postfix down, and use the new script to bring postfix up? I just upgraded and did /etc/init.d/postfix restart and it worked. The installation path was changed without an ebuild version number bump, so if you installed before that change, it would have had the same path as the old version. there was something about libexec when I ran cfg-update: /etc/postfix/main.cf:daemon_directory = /usr/libexec/postfix -- #163933
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
Michael Mol mike...@gmail.com [12-02-06 19:20]: On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq Hi Michael, thank you for your reply. I set the configuration as mentioned above and booted twice with about five minutes wait. The commands were executed within seconds, yes. All hardware clocks drifts, but this is not the problem. The problem is that the hardware clock is not set to the system time in contradiction to what I think the comments in the config are saying. How can I fix that? Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer Is there anything else which I have to tweak to acchieve what I want? Thank you very much in advance for any help! Best regards, mcc PS: I need a correct hwclock since I want to wake the system via the hwclock. I ran into some issues when I rebooted and I had to set both clock_systohc clock_hctosys to yes. That worked for me at least. One sets the BIOS at shutdown and the other loads from the BIOS when rebooting. Yours may need something else but if nothing else works, try that. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
On Mon, Feb 6, 2012 at 1:39 PM, meino.cra...@gmx.de wrote: Michael Mol mike...@gmail.com [12-02-06 19:20]: On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq Hi Michael, thank you for your reply. I set the configuration as mentioned above and booted twice with about five minutes wait. The commands were executed within seconds, yes. All hardware clocks drifts, but this is not the problem. The problem is that the hardware clock is not set to the system time in contradiction to what I think the comments in the config are saying. How can I fix that? I don't really know. Are you sure that rtc0 corresponds to your hardware clock device? Does setting clock_hctosys to YES have any effect? Is this in some kind of virtual-machine or hypervised environment where something may be blocking the OS from setting the hardware clock? -- :wq
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
On Mon, Feb 6, 2012 at 1:46 PM, Dale rdalek1...@gmail.com wrote: meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer Is there anything else which I have to tweak to acchieve what I want? Thank you very much in advance for any help! Best regards, mcc PS: I need a correct hwclock since I want to wake the system via the hwclock. I ran into some issues when I rebooted and I had to set both clock_systohc clock_hctosys to yes. That worked for me at least. One sets the BIOS at shutdown and the other loads from the BIOS when rebooting. Yours may need something else but if nothing else works, try that. I think he's trying to depend on the kernel keeping the hw clock in sync with the sw clock, and that part's not working for some reason. It's a reasonable thing to desire, since an unplanned or ungraceful shutdown could miss the sw-to-hw step. -- :wq
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
Am 06.02.2012 19:39, schrieb meino.cra...@gmx.de: Michael Mol mike...@gmail.com [12-02-06 19:20]: On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq Hi Michael, thank you for your reply. I set the configuration as mentioned above and booted twice with about five minutes wait. The commands were executed within seconds, yes. All hardware clocks drifts, but this is not the problem. The problem is that the hardware clock is not set to the system time in contradiction to what I think the comments in the config are saying. How can I fix that? Thank you very much in advance for any help! Best regards, mcc Is your RTC driver compiled into the kernel? The httosys function of the kernel takes place before any modules can be loaded and will fail if your CMOS clock driver is a module. Activating clock_hctosys in /etc/conf.d/hwclock should solve this as it takes place later in the boot process. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
[gentoo-user] Out of memory during GCC compile
I'm trying to compile GCC on a remote system with 192MB RAM. It's completed successfully before but now it uses up all RAM. The compile doesn't stop but it must be thrashing. I have MAKEOPTS=-j1 in /etc/make.conf. Am I jeopardizing my HD by letting it swap on the compile right now? I've ordered an upgrade to the max of 512MB. I've stopped all processes using up memory that I don't need including X. Is there anything else I can do to get through the compile with 192MB RAM? - Grant
[gentoo-user] Re: Out of memory during GCC compile
On 06/02/12 23:33, Grant wrote: I'm trying to compile GCC on a remote system with 192MB RAM. It's completed successfully before but now it uses up all RAM. The compile doesn't stop but it must be thrashing. I have MAKEOPTS=-j1 in /etc/make.conf. Am I jeopardizing my HD by letting it swap on the compile right now? I've ordered an upgrade to the max of 512MB. I've stopped all processes using up memory that I don't need including X. Is there anything else I can do to get through the compile with 192MB RAM? Lowering optimization helps a lot (CFLAGS in make.conf). For example -O1 or -Os instead of the standard -O2.
Re: [gentoo-user] Out of memory during GCC compile
On Mon, Feb 6, 2012 at 3:33 PM, Grant emailgr...@gmail.com wrote: I'm trying to compile GCC on a remote system with 192MB RAM. It's completed successfully before but now it uses up all RAM. The compile doesn't stop but it must be thrashing. I have MAKEOPTS=-j1 in /etc/make.conf. Am I jeopardizing my HD by letting it swap on the compile right now? I've ordered an upgrade to the max of 512MB. I've stopped all processes using up memory that I don't need including X. Is there anything else I can do to get through the compile with 192MB RAM? Use -O0. Don't enable debugging. I think GCC has some switches to control memory usage/heap limits. You might want to try those and set them to something low like 16MB, it probably uses as much as it can by default.
Re: [gentoo-user] Out of memory during GCC compile
V Mon, 6 Feb 2012 13:33:21 -0800 Grant emailgr...@gmail.com napsáno: I'm trying to compile GCC on a remote system with 192MB RAM. It's completed successfully before but now it uses up all RAM. The compile doesn't stop but it must be thrashing. I have MAKEOPTS=-j1 in /etc/make.conf. Am I jeopardizing my HD by letting it swap on the compile right now? I've ordered an upgrade to the max of 512MB. I've stopped all processes using up memory that I don't need including X. Is there anything else I can do to get through the compile with 192MB RAM? - Grant If you use -pipe as CFLAG remove it. If not just try lower flags as mentioned (-O0).
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
Michael Mol mike...@gmail.com [12-02-06 19:56]: On Mon, Feb 6, 2012 at 1:39 PM, meino.cra...@gmx.de wrote: Michael Mol mike...@gmail.com [12-02-06 19:20]: On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq Hi Michael, thank you for your reply. I set the configuration as mentioned above and booted twice with about five minutes wait. The commands were executed within seconds, yes. All hardware clocks drifts, but this is not the problem. The problem is that the hardware clock is not set to the system time in contradiction to what I think the comments in the config are saying. How can I fix that? I don't really know. Are you sure that rtc0 corresponds to your hardware clock device? Does setting clock_hctosys to YES have any effect? Is this in some kind of virtual-machine or hypervised environment where something may be blocking the OS from setting the hardware clock? -- :wq It is set lrwxrwxrwx 1 root root 4 2012-02-07 00:52 /dev/rtc - rtc0 crwxrwx--- 1 root audio 254, 0 2012-02-07 00:52 /dev/rtc0 and it is the only device of its kind. As I wrote I am using ntp_client for setting my system time while booting up. So reagrdless wheter I am setting clock_hctosys I am alway getting the correct system time later in the bootprocess via ntp.
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
Florian Philipp li...@binarywings.net [12-02-06 20:00]: Am 06.02.2012 19:39, schrieb meino.cra...@gmx.de: Michael Mol mike...@gmail.com [12-02-06 19:20]: On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq Hi Michael, thank you for your reply. I set the configuration as mentioned above and booted twice with about five minutes wait. The commands were executed within seconds, yes. All hardware clocks drifts, but this is not the problem. The problem is that the hardware clock is not set to the system time in contradiction to what I think the comments in the config are saying. How can I fix that? Thank you very much in advance for any help! Best regards, mcc Is your RTC driver compiled into the kernel? The httosys function of the kernel takes place before any modules can be loaded and will fail if your CMOS clock driver is a module. Activating clock_hctosys in /etc/conf.d/hwclock should solve this as it takes place later in the boot process. Regards, Florian Philipp As I wrote the kernel is configured CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 so there is no module, the functionality is compiled into the kernel. And as I wrote I am using the ntp_client to set the system time via ntp/ntp_client later in the boot process to get the correct system time.
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
meino.cra...@gmx.de wrote: As I wrote the kernel is configured CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 so there is no module, the functionality is compiled into the kernel. And as I wrote I am using the ntp_client to set the system time via ntp/ntp_client later in the boot process to get the correct system time. When I built my new rig, I had to use chrony to set my clock for a good long while. For some reason, ntp just plain failed. After ntp had several updates and bug fixes, I tried it again and it now works fine. Could be that maybe something is buggy and affects your system, similar to the way it did on mine, and you need to either back up a few versions, run unstable if you are not already or as I did, try chrony for a while until ntp gets fixed. I never did figure out why ntp failed on me. I do know my clock was awful without something keeping it on track. If you choose to use chrony, I'd be glad to share my config and help you set it up. I think I still got the commands to finds the closest time server and stuff. It about runs with default settings tho. Dale :-) :-) P. S. Here is the info: chrony.conf ! Use the exclamation mark to comment lines and not the # key. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 driftfile /etc/chrony.drift logdir /var/log/chrony log measurements statistics tracking rtc You may not want the last line. It logs a LOT. I used it for testing. Note: Use ! to comment instead of #. Weird. Command to find closest servers: # A good way to get servers for your machine is: # netselect -s 3 pool.ntp.org # netselect -s 3 0.gentoo.pool.ntp.org Just pick the ones with the least delay. Now I'm gone. -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
On Feb 6, 2012 7:00 PM, meino.cra...@gmx.de wrote: Michael Mol mike...@gmail.com [12-02-06 19:56]: On Mon, Feb 6, 2012 at 1:39 PM, meino.cra...@gmx.de wrote: Michael Mol mike...@gmail.com [12-02-06 19:20]: On Mon, Feb 6, 2012 at 12:51 PM, meino.cra...@gmx.de wrote: Hi, to get the correct system time I use ntp-client in the boot process. Furthermore in /etc/conf.d/hwclock I set: # Set CLOCK to UTC if your Hardware Clock is set to UTC (also known as # Greenwich Mean Time). If that clock is set to the local time, then # set CLOCK to local. Note that if you dual boot with Windows, then # you should set it to local. clock=UTC # If you want to set the Hardware Clock to the current System Time # (software clock) during shutdown, then say YES here. # You normally don't need to do this if you run a ntp daemon. clock_systohc=YES # If you want to set the system time to the current hardware clock # during bootup, then say YES here. You do not need this if you are # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. # Also, be aware that if you set this to NO, the system time will # never be saved to the hardware clock unless you set # clock_systohc=YES above. clock_hctosys=NO # If you wish to pass any other arguments to hwclock during bootup, # you may do so here. Alpha users may wish to use --arc or --srm here. clock_args= In the kernel config file I had set: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE=rtc0 I would exspect that after a reboot of the system which system time is correctly set via ntp-client that the hwclock and system time only differ in a small amount of time. But: solfire:/home/mccramerhwclock Mon Feb 6 19:05:11 2012 -0.172569 seconds solfire:/home/mccramerdate Mon Feb 6 18:49:37 CET 2012 solfire:/home/mccramer I don't know the CET tz, but I can see that the minutes don't match up. I assume you rand the two commands within seconds of each other. Is this true immediately after bootup, or does it take a while to get that far off? It could be that your hardware clock is drifting, and the system won't reset it until it goes to shutdown. -- :wq Hi Michael, thank you for your reply. I set the configuration as mentioned above and booted twice with about five minutes wait. The commands were executed within seconds, yes. All hardware clocks drifts, but this is not the problem. The problem is that the hardware clock is not set to the system time in contradiction to what I think the comments in the config are saying. How can I fix that? I don't really know. Are you sure that rtc0 corresponds to your hardware clock device? Does setting clock_hctosys to YES have any effect? Is this in some kind of virtual-machine or hypervised environment where something may be blocking the OS from setting the hardware clock? -- :wq It is set lrwxrwxrwx 1 root root 4 2012-02-07 00:52 /dev/rtc - rtc0 crwxrwx--- 1 root audio 254, 0 2012-02-07 00:52 /dev/rtc0 and it is the only device of its kind. As I wrote I am using ntp_client for setting my system time while booting up. So reagrdless wheter I am setting clock_hctosys I am alway getting the correct system time later in the bootprocess via ntp. Sure. My question was more geared toward specifically obtaining information about your hardware clock, which you probed with the hwclock command. You insist your hardware clock isn't being updated, but I have insufficient data to verify that, or even get a feel for the behavior of your system. *Obviously* all hardware clocks drift, but I was wondering if your hardware clock was drifting notably rapidly. I don't know at what interval the hardware clock would normally be updated by the kernel, or what constitutes 'continuous' in that context. Timestamps along with the commands and for notable events, such as when ntpclient ran during bootup and when the system shut down, would be useful.
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
On Tuesday 07 February 2012 00:23:43 Dale wrote: Note: Use ! to comment instead of #. Weird. Command to find closest servers: You don't have to. Chrony's convention is to use # for its own comments and ! for assignments you want to comment out. Just a convention though. Use either at will. -- Rgds Peter Linux Counter 5290, 1994-04-23
[gentoo-user] Quick and dirty install of google chrome binary package
I tried and liked google chrome for a few months until I got tired of the multi-hour compile every week or so. The chrome-binary ebuild was removed a while ago, I'm guessing because of library version conflicts, but I dunno for sure. Anyway, I wanted to try a recent version of chrome without spending all day compiling it on this dusty old x86 machine, so I improvised this easy workaround: First, you need x11-libs/libXScrnSaver and app-arch/rpm2targz already installed. Next, download the appropriate rpm package from www.google/chrome. #cd /tmp (or whatever staging area you prefer, but do it as root) #rpmunpack /path/to/your/downloaded/google-chrome-whatever.rpm #mv google-whatever/opt/google /opt (the actual chrome binaries) (Note: you don't need the etc or usr/bin parts of the archive, so delete the whole /tmp/google-whatever directory now.) Make the symlink /usr/bin/google-chrome - /opt/google/chrome/google-chrome When you run google-chrome you will likely see an error for missing libpng12.so.0, which gentoo has replaced with more recent versions like libpng14 or libpng15. If you see that error, here is a very quick and easy fix: #ebuild /usr/portage/media-libs/libpng/libpng-1.2.46.ebuild compile That step will build (but not install) libpng12, so you won't disturb any of your existing packages. The newly built library you need is now waiting for you here: /var/tmp/portage/media-libs/libpng-1.2.46/work/libpng-1.2.46/.libs/ Now copy libpng12.so.0.46.0 to /opt/google/chrome and rename it (or symlink it) to libpng12.so.0, because that is what chrome looks for. Complain here if you have problems :)
Re: [gentoo-user] Quick and dirty install of google chrome binary package
On 6 February 2012 21:42, walt w41...@gmail.com wrote: I tried and liked google chrome for a few months until I got tired of the multi-hour compile every week or so. The chrome-binary ebuild was removed a while ago, I'm guessing because of library version conflicts, but I dunno for sure. Anyway, I wanted to try a recent version of chrome without spending all day compiling it on this dusty old x86 machine, so I improvised this easy workaround: First, you need x11-libs/libXScrnSaver and app-arch/rpm2targz already installed. Next, download the appropriate rpm package from www.google/chrome. #cd /tmp (or whatever staging area you prefer, but do it as root) #rpmunpack /path/to/your/downloaded/google-chrome-whatever.rpm #mv google-whatever/opt/google /opt (the actual chrome binaries) (Note: you don't need the etc or usr/bin parts of the archive, so delete the whole /tmp/google-whatever directory now.) Make the symlink /usr/bin/google-chrome - /opt/google/chrome/google-chrome When you run google-chrome you will likely see an error for missing libpng12.so.0, which gentoo has replaced with more recent versions like libpng14 or libpng15. If you see that error, here is a very quick and easy fix: #ebuild /usr/portage/media-libs/libpng/libpng-1.2.46.ebuild compile That step will build (but not install) libpng12, so you won't disturb any of your existing packages. The newly built library you need is now waiting for you here: /var/tmp/portage/media-libs/libpng-1.2.46/work/libpng-1.2.46/.libs/ Now copy libpng12.so.0.46.0 to /opt/google/chrome and rename it (or symlink it) to libpng12.so.0, because that is what chrome looks for. Complain here if you have problems :) you seem to have missed a very simple way to do all this: emerge google-chrome JOB = DONE
Re: [gentoo-user] hwclock -- sysclock and the ntp-client
Peter Humphrey wrote: On Tuesday 07 February 2012 00:23:43 Dale wrote: Note: Use ! to comment instead of #. Weird. Command to find closest servers: You don't have to. Chrony's convention is to use # for its own comments and ! for assignments you want to comment out. Just a convention though. Use either at will. -- Rgds Peter Linux Counter 5290, 1994-04-23 Good to know. To the best of my knowledge, this is the only program I have ever ran into that said to use ! instead of # for comments. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Quick and dirty install of google chrome binary package
On Feb 7, 2012 9:46 AM, walt w41...@gmail.com wrote: I tried and liked google chrome for a few months until I got tired of the multi-hour compile every week or so. The chrome-binary ebuild was removed a while ago, I'm guessing because of library version conflicts, but I dunno for sure. Anyway, I wanted to try a recent version of chrome without spending all day compiling it on this dusty old x86 machine, so I improvised this easy workaround: First, you need x11-libs/libXScrnSaver and app-arch/rpm2targz already installed. Next, download the appropriate rpm package from www.google/chrome. #cd /tmp (or whatever staging area you prefer, but do it as root) #rpmunpack /path/to/your/downloaded/google-chrome-whatever.rpm #mv google-whatever/opt/google /opt (the actual chrome binaries) (Note: you don't need the etc or usr/bin parts of the archive, so delete the whole /tmp/google-whatever directory now.) Make the symlink /usr/bin/google-chrome - /opt/google/chrome/google-chrome When you run google-chrome you will likely see an error for missing libpng12.so.0, which gentoo has replaced with more recent versions like libpng14 or libpng15. If you see that error, here is a very quick and easy fix: #ebuild /usr/portage/media-libs/libpng/libpng-1.2.46.ebuild compile That step will build (but not install) libpng12, so you won't disturb any of your existing packages. The newly built library you need is now waiting for you here: /var/tmp/portage/media-libs/libpng-1.2.46/work/libpng-1.2.46/.libs/ Now copy libpng12.so.0.46.0 to /opt/google/chrome and rename it (or symlink it) to libpng12.so.0, because that is what chrome looks for. Complain here if you have problems :) The steps seems to be simple enough to be made into a custom ebuild, don't you think so? ;-) Rgds,
[gentoo-user] Re: gcc-4.5.3-r1 fails to compile with internal compiler error
I can't seem to get gcc-4.5.3-r1 to compile. I tried twice and it failed at the exact same point both times. The build log doesn't mention a segfault. Does anyone know how to fix this? I was able to compile gcc-4.3.3 a short while ago. /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/gcc/config/i386/i386.md: In function 'internal_dfa_insn_code': /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/gcc/config/i386/i386.md:360:1: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. make[3]: *** [insn-attrtab.o] Error 1 make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build' make: *** [bootstrap-lean] Error 2 emake failed - Grant I get the same error trying to recompile gcc-4.3.4 which is currently installed and was emerged successfully about a week ago. I'll file a bug? - Grant Fixed! It may have been changing my locale from POSIX to UTF8 or maybe some kernel changes I made. - Grant
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Tue, Feb 7, 2012 at 01:05, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Feb 6, 2012 at 12:00 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Montag, 6. Februar 2012, 12:47:45 schrieb Michael Mol: On Mon, Feb 6, 2012 at 12:29 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 06.02.2012 18:08, schrieb Volker Armin Hemmann: Am Montag, 6. Februar 2012, 12:06:41 schrieb Helmut Jarausch: Hi, beware of installing postfix-2.9.0 When started it tries to access /usr/lib/postfix but files have been installed into /usr/libexec/postfix postfix 2.9.0 works fine for me. But I also run cfg-update after the update and made sure to merge the ._ file correctly. Yep, same here for postfix 2.9.0-r1 now. Had to kill the master-process manually ... this sorted things out in the end ... So, to avoid this, when upgrading from 2.9.0-r1 to 2.9.0-r1, one should stop postfix, do the upgrade, and then start postfix again? that's how I read it. Alternately, copy the old init script prior to upgrade, use that script to bring postfix down, and use the new script to bring postfix up? I just upgraded and did /etc/init.d/postfix restart and it worked. The installation path was changed without an ebuild version number bump, so if you installed before that change, it would have had the same path as the old version. S... I'm still on 2.8.7. Is it safe to upgrade to 2.9.0-r1 ? Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Tue, Feb 07, 2012 at 01:58:33PM +0700, Pandu Poluan wrote:
S... I'm still on 2.8.7. Is it safe to upgrade to 2.9.0-r1 ?
Yes, it should be OK as long as you run etc-update/dispatch-conf/similar
after the upgrade. Postfix daemons now live under /usr/libexec/postfix
(not under /usr/lib{,64)/postfix). Adjust your main.cf accordingly.
I'll add a warning to the ebuild.
--
Eray Aslan e...@gentoo.org
Re: [gentoo-user] HEADS UP - postfix-2.9.0 is broken
On Mon, Feb 06, 2012 at 06:51:51PM +0100, Andrea Conti wrote: Luckily the error messages are informative enough... but let's say that a word of caution in the emerge message would have been welcomed. There is a warning printed if you emerged without the berkdb flag when you upgraded from postfix-2.9. Please let me know if it did not work for you. -- Eray Aslan e...@gentoo.org
