On 2013-01-03 14:26, José Manuel Santamaría Lema wrote:
> 0m23.2s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmp1Ho66d',
> 'eatmydata',
> 'tmp/scripts/post_purge_manual_cleanup']
that's a noop except for ipopd and uw-imapd
> So I must ask: are you sure your piuparts setup is ok?
yes :-)
and verified that the bug is still reproducible
But these "creates stuff in /root/" bugs are sometimes damned
heisenbugs ...
I'm currently running 3.6-trunk-amd64 - what kernel are you using?
WTF is this (found in the prerm script)?
if [ ! -f "$HOME/.odbc.ini" ]; then
REMOVE_ODBC_INI=true
fi
odbcinst -u -s -l -n VOS || true
# The previous odbcinst command may create the file $HOME/.odbc.ini
# if it didn't exist previously, leaving unowned files after removing
# the package, so we remove the .odbc.ini if it's neccesary, see:
# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677286
if [ -n "$REMOVE_ODBC_INI" ]; then
rm -f $HOME/.odbc.ini
fi
You cannot rely on $HOME !
If you have something that messes around in /root,
set HOME to a temporary directory:
INSTDIR=`mktemp -d`
HOME=$INSTDIR stupid-command-messing-around-in-slash-root
if [ -n $INSTDIR ]; then rm -rf $INSTDIR; fi
If you have something that does not respect $HOME, fix it.
And odbcinst is such an insanity:
# HOME=/fooo odbcinst -u -s -l -n VOS
odbcinst: DSN removed (if it existed at all). ODBC_BOTH_DSN was used as the
search path.
# dd if=/dev/urandom of=/root/.odbc.ini count=1
# HOME=/fooo odbcinst -u -s -l -n VOS
odbcinst: SQLRemoveDSNFromIni failed with Unable to find component name.
Andreas
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
