However, I still think that available packages be capable of being built using the defined processes should anyone want to (a) built there own image; or (b) make changes to and build the specific package
Thus,I still think my original post is valid and hopefully will be addressed at some time even if it is less relevant to me,

Further to my previous comment, I have already suggested in a separate post (can't find it right now), that instead of the git://git.openwrt.org/15.05/openwrt.git repository as referenced in https://wiki.onion.io/Tutorials/Cross-Compile, that the repository of the official Omega release(s) be made available.

That way, anyone could make their own images with any desired modifications (e.g. additional packages, fewer packages, patches to kernel and/or packages etc.) and know that at least what they are building is close to (give or take any changes they have made) to the official release.

fair enough @Kit-Bishop, i thought you were just trying to compile i2c-tools.
can't help you with compilation yet as I haven't tried setting up a buildroot yet. intend to get to that soon as I'm hitting limitations with stock i2c-tools and need to go to writing code in C.

Hi @Kit-Bishop, I'm not sure why, but I'm not getting the build error when I tried setting up a clean build environment to compile i2c-tools, so i'm not sure what's causing your error. Are you compiling in a clean environment or was it from before?

@Andrei-Railean: Just out of curiosity, what kind of limitation are you hitting on the i2c-tools? Perhaps it could be some thing we can add to our I2C libraries.

@Boken-Lin Hmm. Not sure why I am seeing the build error and you are not.
However, as explained above, it's not a big deal for me since I don't actually need to build i2c-tools. I just had it included in the packages to be built when building a system image for interest sake.

I don't have any specific issues with it, just playing around when I hit the build problem. Since I don't actually need it, I just disabled it in the image build.

Could possibly have been caused by other things I was doing with the building at the time. When I have time to spare, I may try re-installing a clean OpenWrt build system and see if I get the problem again.

If all is Ok for you, don't spend too much time on this issue since it is not important for me.

Hi @Boken-Lin, the main limitation of i2c-tools for me is that the binary i2cget cannot read more than 16 bits in one go - i need to read 24 bits, for example. The fact that it's endianness cannot be controlled is a bit of an inconvenience, but can be worked around.

I am yet to interact with i2c via python, mainly because py-smbus parts of i2c-tools are not compiled and not available for install via opkg. Hence my need to get my hands dirty with buildroot and compilation.

Hi @Andrei-Railean
The Onion I2C C library has a read function that can specify the number of bytes to be read from the bus, and put them all in an array.

A Python wrapper of the library is in the works, but there are some higher priority packages and features I'm working on right now.
If you're interested in helping with the Python wrapper, take a look at the github repo: https://github.com/OnionIoT/i2c-exp-driver

The Python wrappers for the OLED, Servo, and Relay Expansions were done by creating extension modules using the method outlined here.
However, it might be easier using the ctypes method

In any case, let me know if you're interested and we can talk further.