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

[Andre McCurdy]

On Mon, Jul 31, 2017 at 5:50 AM, Maxin B. John <maxin.john at intel.com> wrote:
> 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.

If upstream isn't interesting in a fix then "Inappropriate [upstream
not interested in fix]" or "Inappropriate [upstream is dead]" would be
better tags.

>> rday
>
> Best Regards,
> Maxin
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core