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

[Khem Raj]

On 7/31/17 4:15 AM, rpjday at crashcourse.ca wrote:
> 
> 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?

usually, sending it upstream at same time when its proposed here for OE
is best. Then you can discuss it with upstream on sides, if upstream
does not want a patch, that creates some maintenance debt for future
upgrades but such is life.

> 
> rday
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170731/1b597ca8/attachment-0002.sig>