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

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

[rpjday]

   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.

rday

Re: worth adding a "git"-versioned of i2c-tools to oe-core?

[Alexander Kanavin]

On 07/31/2017 01:41 PM, rpjday@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.

Alex

Re: worth adding a "git"-versioned of i2c-tools to oe-core?

[Richard Purdie]

On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
> On 07/31/2017 01:41 PM, rpjday@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

Re: worth adding a "git"-versioned of i2c-tools to oe-core?

[rpjday]

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

> On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>> On 07/31/2017 01:41 PM, rpjday@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

Re: 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@crashcourse.ca wrote:
> 
> Quoting Richard Purdie <richard.purdie@linuxfoundation.org>:
> 
> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
> >>On 07/31/2017 01:41 PM, rpjday@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

Re: worth adding a "git"-versioned of i2c-tools to oe-core?

[Maxin B. John]

Hi,
On Mon, Jul 31, 2017 at 03:50:17PM +0300, Maxin B. John wrote:
> Hi,
> 
> On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpjday@crashcourse.ca wrote:
> > 
<snip>
> > 
> >   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

Sorry, I meant to use the most recent version (we already have the latest released verion - 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

Re: worth adding a "git"-versioned of i2c-tools to oe-core?

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 2377 bytes --]



On 7/31/17 4:15 AM, rpjday@crashcourse.ca wrote:
> 
> Quoting Richard Purdie <richard.purdie@linuxfoundation.org>:
> 
>> On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>>> On 07/31/2017 01:41 PM, rpjday@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
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: 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@intel.com> wrote:
> Hi,
>
> On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpjday@crashcourse.ca wrote:
>>
>> Quoting Richard Purdie <richard.purdie@linuxfoundation.org>:
>>
>> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>> >>On 07/31/2017 01:41 PM, rpjday@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: worth adding a "git"-versioned of i2c-tools to oe-core?

[Alexander Kanavin]

On 07/31/2017 09:57 PM, Khem Raj wrote:

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

Also, if the patch is non-trivial, there is a risk it will be dropped 
from Yocto in the future, if rebasing it to a newer upstream release is 
difficult and requires specialist knowledge. It's best if upstream 
maintainers take it.

Alex