Recipe parsing issues and proxy settings

I guess it's a slow news day (or week)... From my OpenEmbedded-related work come 2 emails to the oe-dev mailing list:

1. One of the recent commits from Mamona developers, which is supposed to be isolated to their distribution, breaks bitbake's parsing for me and probably for other people. Apparently, bitbake parses through all the recipes in the tree (unless masked by BBMASK, I presume) regardless of whether the recipe is used by the current machine/distro configuration. So, if the recipe has parsing errors (like missing .inc file in this example), it will break for all the other people using the latest tree. Mental note to myself - when making changes to recipes, destined to public tree, make sure bitbake can at least parse them w/o errors... BTW, the issue got resolved quickly by good people of Mamona and I got a chance to chat with them on #oe IRC.

2. Trying to use OpenEmbedded in the corporate environment may be a painful experience. Most of the time it involves bypassing or working from behind a very strict firewall using some sort of proxy server. In many cases HTTP/FTP proxy is well established and employees are familiar with its settings. Same cannot be said for other types of transports, e.g. version control systems, like CVS, subversion and git. But it's an entirely different topic for some other time.
Anyway, on Linux/Unix systems it is standard to set http_proxy and ftp_proxy environment variables to point to respective proxy servers for corresponding type of network traffic. Those variables are used by most of the network applications, like browsers, fetchers and alike. Unfortunately, with the recent environment filtering feature in bitbake, those standard proxy setup variables are being filtered out and none of the sources can be fetched from behind a firewall/proxy. Hence, my proposal to add http_proxy and ftp_proxy variables to the white list.