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.

Bluetooth A2DP stereo on Asus Eee PC

Since I fixed my Dial-Up Network setup issues, I was quite happy with my Asus Eee PC 901 Bluetooth capabilities. It works with my BT mouse and tethers with my cellphone over BT as well.

The next I wanted to use my Plantronics Voyager 855 stereo headset, but quickly found out the required A2DP stereo profile is not supported by the standard AzureBT Bluetooth application, shipped with EeePC 901. There are instructions on the Net to make A2DP work with many Linux media players, like xine & mplayer, but those involve installing the BlueZ stack (like I explained in the other post) and configuring ALSA output for it.

I guess, I'll leave it for later to make it work, when I have more free time (is there such thing, as more free time?)...

Back from MontaVista Vision 2008

I'm back from MontaVista Vision 2008 Embedded Linux Developers Conference. It was the second Vision Conference and I think this time it was better than the last one.

It has been interesting 2.5 days in downtown San Francisco (even though I didn't have time to peek my nose out of the hotel). But there is almost nothing to report - it was good overall, but nothing too specific to single out.

I liked the remote debugging session by one of the MontaVista guys, where he demonstrated techniques to remotely access the EVM/test-board on the testbench over the serial/ppp/telnet, power it on/off, reboot and even monitor it with a network camera.

Another interesting moment happened to me when I suddenly became perceived as an OpenEmbedded Guru (which I'm not - I'm still learning), when we were discussing different approaches to system builds during one of the birds-of-a-feather sessions and I happened to have the most successful and in-depth experience with OE out of the whole audience. Mind you, it was a Corporate Conference, hence not many people from the community. Contrary to the Embedded Linux Conference, which I attended in April, where there were many people from the community, including the OpenEmbedded one.