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.
Portage 184.108.40.206 (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
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
CFLAGS="-O2 -march=athlon64 -msse3 -ffast-math -ftracer -fprefetch-loop-arrays -pipe -fforce-addr -ftree-vectorize"
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"
FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed"
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-*"
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 attachment 129123 [details]
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 attachment 136358 [details, diff]
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).