I can confirm this as of yesterday,
noticeable when completion is missing, or CDPATH isn't working :)

$bash --version
GNU bash, version 4.1.9(2)-release (x86_64-unknown-linux-gnu)
[..]

$pacman -Qi bash
Name : bash
Version : 4.1.009-2
[..]
Architecture : x86_64
Build Date : Sun 28 Nov 2010 06:52:04 PM EET
Install Date : Sun 28 Nov 2010 09:38:10 PM EET
[..]

Could you test if 4.1.009-3 fixes the problem for you? I'd also be interested in how you reproduce it. For me bash never sourced /etc/bash.bashrc on its own. That's why we manually source it on /etc/profile. It's strange that the latter didn't work for you.

Just updated, seems fine now
thanks :)

I didnt reproduce it, it was there. Most noticeable bash completion wasnt working.
line 30 of /etc/bash.bashrc shows:
/etc/bash.bashrc:30:[ -r /etc/bash_completion ] && . /etc/bash_completion

and it's only sourced from there.
no bash_completion -> no /etc/bash.bashrc or no sourcing of it.

/etc/bash.bashrc is sourced from /etc/profile :
/etc/profile:19:if test "$PS1" && test "$BASH" && test -r /etc/bash.bashrc; then
/etc/profile:20: . /etc/bash.bashrc

so it's sourced everytime

EDIT:
oh, that's what you said :P
I dont think baash sources it by default, but it was always sourced in the default /etc/profile

> Could you test if 4.1.009-3 fixes the problem for you? I'd also be interested in how
> you reproduce it. For me bash never sourced /etc/bash.bashrc > on its own.
> That's why we manually source it on /etc/profile. It's strange that the latter didn't
> work for you.
Hi,
I thought /etc/profile should be only sourced for login-shells, where as a normal bash sources /etc/bash.bashrc. As you can see below this happened and happens again with 4.1.009-3, at least for me.
i created a completely empty account, and no file out of "/etc/profile /etc/profile.bash /etc/bash.bashrc" sources anything else.

This is what i get:

4.1.009-1

21:41 root:~$ /bin/login
Guido login: horst
Password:
etc_profile.bash
etc_profile
-bash-4.1$ bash
etc_bash.bashrc
[horst@Guido ~]$

4.1.009-2

21:43 root:~$ /bin/login
Guido login: horst
Password:
etc_profile
-bash-4.1$ bash
bash-4.1$

4.1.009-3

-bash-4.1# login
Guido login: horst
Password:
etc_profile.bash <- (was moved to /etc/profile.bash.pacsave during the update (why?))
etc_profile
-bash-4.1$ bash
etc_bash.bashrc
[horst@Guido ~]$

I might add that the handling of the config-files was pretty inconsistent. The new /etc/profile was installed as /etc/profile.pacnew, /etc/bash.bashrc was simply overwritten and /etc/profile.bash was moved away.

I have a bug that seems related. The cause is that /etc/profile.bash was present in bash 4.1.009-1 and removed since 4.1.009-2

The very annoying consequence for me is that ~/.bash_profile isn't parsed by bash when running :
[root@m50vn ~]# su calimero -l -c "bash -l -c '/tmp/test.sh'"

And /tmp/test.sh contains just echo $GTK_IM_MODULE, which is exported in the ~/.bashrc of user calimero.

It's annoying because my X session is run using x:5:once:/bin/su calimero -l -c "/bin/bash --login -c startx &>/dev/null" in /etc/inittab.
Now, my X session doesn't have the environment variables of my bashrc (since 4.1.009-2 and the profile.bash file deletion) !

If I take /etc/profile.bash from the bash 4.1.009-1 package and copy it to /etc it works again.
Could you revert the deletion of profile.bash, Pierre ?
Thanks !

I no longer call /etc/profile.$shell from /etc/profile (part of the filesystem package). This never really worked and caused some trouble. It was also some kind of duplication.

I double-checked : my bashrc isn't parsed when running su calimero -l -c "bash -l -c '/tmp/test.sh'" (test.sh containing echo $GTK_IM_MODULE that is exported in calimero user's ~/.bashrc)

It would be good to put /etc/profile.bash back in the bash package to solve this, or to do anything else solving this if you prefer...
If the package goes to core like this, people using startx in inittab will have their custom XCompose keys not working in GTK apps, among other things.

PS: note that on the #bash IRC channel, they told me that using bash -l -c 'command' should parse bashrc before running the command, that is the documented behaviour. Any other behaviour in this case is a bug.

This works fine for me. Make sure to place your export above the line that contains "[ -z "$PS1" ] && return" in ~/.bashrc.

This seems to be "fixed" for me. Any opinion from the actual Bash maintainers about this?

I'll add a works for me with 4.1.009-3...