Bugzilla Bug 190128

hasq is no longer a part of bash resulting in many hasq commands not found, not
sure if it is just an alias drop or what happened.

Reproducible: Always




Portage 2.1.3.7 (default-linux/amd64/2007.0, gcc-4.2.1, glibc-2.6.1-r0,
2.6.23-rc3 x86_64)
=================================================================
System uname: 2.6.23-rc3 x86_64 AMD Athlon(tm) 64 Processor 3800+
Gentoo Base System release 1.12.10
Timestamp of tree: Sat, 25 Aug 2007 03:30:01 +0000
ccache version 2.4 [disabled]
dev-lang/python:     2.4.4-r4, 2.5.1-r2
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17.50.0.18
sys-devel/gcc-config: 1.4.0
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -msse3 -ffast-math -ftracer -fprefetch-loop-arrays
-pipe -fforce-addr -ftree-vectorize"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=athlon64 -msse3 -ffast-math -ftracer
-fprefetch-loop-arrays -pipe -fforce-addr -ftree-vectorize"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans
userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LC_ALL="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/home/gentoo"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext X a52 aac acpi alsa amd64 amr amrweb berkdb bitmap-fonts
branding bzip2 cdr cli cpudetection cracklib crypt cups dbus dri dvd dvdr
dvdread encode ffmpeg firefox gdm gif gnome gtk hal iconv jpeg mad mmx mmxext
moznopango mp3 ncurses networkmanager nptl nptlonly nsplugin nss ogg opengl pam
pcre perl pic png python readline sdl session spell sse sse2 sse3 ssl svg tcpd
tiff truetype-fonts type1-fonts unicode vorbis x264 xinerama xorg xv xvid zlib"
ALSA_CARDS="atiixp atiixp-modem" ALSA_PCM_PLUGINS="adpcm alaw copy dshare
dsnoop extplug file hooks ladspa lfloat linear meter mulaw multi null rate
route share shm" ELIBC="glibc" INPUT_DEVICES="mouse keyboard synaptics"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="radeon fglrx"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LINGUAS, MAKEOPTS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

It seems like there's come kind of problem with nested "source" statements.
I've masked bash-3.2_p25 to prevent others from hitting this.

Looks like this is caused by bash32-020, as bash-3.2_p19 works fine while
bash-3.2_p20 shows this error.

Created an attachment (id=129123) [details]
test script

Anyway this bug can seriously damage system... if one will be upgrading
packages. I made out to damage udev, hald & nvidia-drivers. Pretty hard to get
to know what is going on as for instance udev was clearing
/proc/sys/kernel/hotplug :)

*** Bug 190166 has been marked as a duplicate of this bug. ***

*** Bug 190375 has been marked as a duplicate of this bug. ***

*** Bug 191565 has been marked as a duplicate of this bug. ***

*** Bug 191981 has been marked as a duplicate of this bug. ***

considering the bash change is standards compliant, i think we need to put
together a new "source" function that basically weeds out readonly variables
from the file based on the active environment before sourcing it

Created an attachment (id=136358) [details]
use egrep to filter out readonly variables

This patch seems to work. The readonly variables are filtered out by egrep when
the environment is saved. This solution is pretty simple. It would probably be
a little more complex to implement a safe "source" function.

doing it at the save step should probably be fine for most uses

implementing source wouldnt be terribly hard, but if you already have stuff in
place to do it at saving ...

In bash-3.2_p25.ebuild I've added a blocker for <sys-apps/portage-2.1.4_rc1 so
that we can unmask bash-3.2_p25 and emerge will automatically adjust the merge
order such that portage is upgraded before bash.

I've left bash-3.2_p25 in package.mask for the time being, until
portage-2.1.4_rc1 has had more testing.

(In reply to comment #11)
> doing it at the save step should probably be fine for most uses
> 
> implementing source wouldnt be terribly hard, but if you already have stuff in
> place to do it at saving ...
Doing it at *just* the save step means that further extensions of readonly vars
in the portage env can cause new breakages, and means you're slightly screwed
with the collection of vdb envs that are already out there.

You're going to need the filtering at the reload level imo, not just saving
(think this bug proves out why save filtering alone isn't enough).