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

[Maxin B. John]

Hi,

On Mon, Jul 31, 2017 at 07:15:23AM -0400, 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".

dl.lm-sensors.org has been down for a while and doesn't show any positive signs that
it will be back in near future. One possibility will be to use the unofficial mirrors
listed below and upgrade to version 3.1.2

1. https://fossies.org/linux/misc/
2. http://jdelvare.nerim.net/mirror/i2c-tools/

>   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?

Since this genuinely fixes an error, we should be able to include this patch with:
"Inappropriate [bug workaround]" status. 

> rday

Best Regards,
Maxin