Re: [OE-core] 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [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  wrote:
> Hi,
>
> On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpj...@crashcourse.ca wrote:
>>
>> Quoting Richard Purdie :
>>
>> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>> >>On 07/31/2017 01:41 PM, rpj...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Khem Raj]

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



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] 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, rpj...@crashcourse.ca wrote:
> > 

> > 
> >   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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [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, rpj...@crashcourse.ca wrote:
> 
> Quoting Richard Purdie :
> 
> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
> >>On 07/31/2017 01:41 PM, rpj...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[rpjday]

Quoting Richard Purdie :


On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:

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


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] 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, rpj...@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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Alexander Kanavin]

On 07/31/2017 01:41 PM, rpj...@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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[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

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core