[OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[rpjday at crashcourse.ca]

Quoting Richard Purdie <richard.purdie at linuxfoundation.org>:

> On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>> On 07/31/2017 01:41 PM, rpjday at crashcourse.ca wrote:
>> >
>> >
>> >    given that some significant changes have been made to i2c-tools
>> > since
>> > version 3.1.2, is it worth adding a git-versioned recipe of that
>> > to 
>> > oe-core,
>> > and using DEFAULT_PREFERENCE to force people to select it if they
>> > want it?
>> > in particular, the code base has been restructured, and a new
>> > utility,
>> > "i2ctransfer", has been added.
>> It's better to ask the upstream to make a new release.
>>
>> We've had dual git/release recipes in the past, and they were all an 
>> utter failure. In the sense, that only one version of the recipe was 
>> maintained, and the other was completely neglected.
>
> Going forward we may accept patches using this instead:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass
>
> Cheers,
>
> Richard

   well, here's a possible conundrum ... in that same package (i2c-tools),
there appears to be an *obvious* flaw in that the "eeprog" utility uses a
sleep that is far too short for proper operation, as described here:

https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html

there is a link to a patch on that page that simply cranks up a few sleep
calls from 10usec to 5msec, which apparently solves the problem. i've been
involved in a discussion on the i2c-tools mailing list about this very
issue after i tripped over it, but there seems to be little enthusiasm on
that list for "fixing" this -- i was told that people use the kernel driver
instead and access via /sys rather than calling "eeprog".

   so, from my perspective, this should definitely be fixed so that "eeprog"
functions properly, but it's not clear upstream is all that interested in it.
what would the protocol be here?

rday